Re: RFC: -Wall by default
> "MB" == Miles Bader writes: MB> [Or, perhaps, not "-Wall" perse, but maybe a new option which MB> is a little more conservative, "-Wstandard" or something...] Sure. Making a few more of the -W flags on by default may be OK, depending on the chosen list. It is the idea of turing all possible warning options on by default which is unreasonable. Defaulting to -Wall also fails as a user interface design. -Wall is a nice, short, sweet, easy to type optiong which one readily can add at any time. Forcing one to have to find all of the -Wno-... options to avoid unwanted annoyances, or to the -Wno-all and a set of -Ws which one does want is far more cumbersome. And what if new warning are added. Does anyone really want them *all* on by default as soon as the code lands? If there are some useful warning not already on by default which tend not to false-positive and provide useful, beneficial information when triggered, then it is reasonable to look into starting to default-enable them. Turning *all* of them on willy-nilly is not. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 10:16 AM, James Cloos wrote: >> "MB" == Miles Bader writes: > > MB> [Or, perhaps, not "-Wall" perse, but maybe a new option which > MB> is a little more conservative, "-Wstandard" or something...] > > Sure. Making a few more of the -W flags on by default may be OK, > depending on the chosen list. It is the idea of turing all possible > warning options on by default which is unreasonable. You might want to get your facts straight: -Wall does not turn on all possible warning options. -- Gaby
Switch statement case range
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
in C/C++ case statements?
Best regards,
Rick C. Hodgin
Re: Switch statement case range
On Sun, Apr 8, 2012 at 10:59 AM, Rick Hodgin wrote:
> What are the possibilities of adding a GCC extension to allow:
>
> switch (foo) {
> case 1:
> case 2:
> case 3 to 8:
> case 9:
> default:
> }
>
> in C/C++ case statements?
GCC used to have a range extension for case:
case 3..8
which has been removed. Back to the future?
-- Gaby
Re: Switch statement case range
On Sun, Apr 08, 2012 at 08:59:46AM -0700, Rick Hodgin wrote:
> What are the possibilities of adding a GCC extension to allow:
>
> switch (foo) {
> case 1:
> case 2:
> case 3 to 8:
> case 9:
> default:
> }
This already exists (and is a GNU extension):
switch (foo)
{
case 1:
break;
case 3 ... 8:
break;
default:
break;
}
Marek
Re: Switch statement case range
On 4/8/2012 11:59 AM, Rick Hodgin wrote:
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
in C/C++ case statements?
Best regards,
Rick C. Hodgin
I think there is very little enthusiasm these days for adding
non-standard extensions of this type.
Re: Switch statement case range
Thank you!
I'd like to find out some day exactly how much I _don't_ know. :-)
Best regards,
Rick C. Hodgin
--- On Sun, 4/8/12, Marek Polacek wrote:
> From: Marek Polacek
> Subject: Re: Switch statement case range
> To: "Rick Hodgin"
> Cc: "gcc"
> Date: Sunday, April 8, 2012, 12:05 PM
> On Sun, Apr 08, 2012 at 08:59:46AM
> -0700, Rick Hodgin wrote:
> > What are the possibilities of adding a GCC extension to
> allow:
> >
> > switch (foo) {
> > case 1:
> > case 2:
> > case 3 to 8:
> > case 9:
> > default:
> > }
>
> This already exists (and is a GNU extension):
>
> switch (foo)
> {
> case 1:
> break;
> case 3 ... 8:
> break;
> default:
> break;
> }
>
> Marek
>
Re: Switch statement case range
On Sun, 2012-04-08 at 09:07 -0700, Rick Hodgin wrote: > Thank you! > > I'd like to find out some day exactly how much I _don't_ know. :-) > Knock yourself out ;) http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html Cheers, Oleg
GNU Tools Cauldron 2012 - Hotels and registered presentations
An update on the GNU Tools Cauldron (http://gcc.gnu.org/wiki/cauldron2012) If you are starting to organize your trip, we have added some suggestions about accomodation on the Cauldron page. We have not negotiated special prices with any hotel in Prague. If you need an invitation letter for a visa to the Czech Republic, send your request to tools-cauldron-ad...@googlegroups.com. We have also added a list presentations registered so far. There are already about 24 presentations and BoFs registered, so we may need to run parallel sessions. Remember that we will also be accepting last minute presentations on the first day of the workshop, provided we have enough slots in the schedule. Presenters, please double-check your entries at http://gcc.gnu.org/wiki/cauldron2012. If you find anything missing or wrong, please contact me and I will correct it (or if you have write-access to the wiki, feel free to correct it yourself). If you are thinking about giving a presentation or organizing a BoF, please send mail to tools-cauldron-ad...@googlegroups.com. Your submission should contain the following information: Title: Authors: Abstract: If you intend to participate, but not necessarily present, please let us know as well. Send a message to tools-cauldron-ad...@googlegroups.com stating your intent to participate. We are starting to reach capacity, so contact us sooner rather than later. Thank you.
Re: GNU Tools Cauldron 2012 - Hotels and registered presentations
Hello Diego, I am all set with my plans for Prague, but I have to leave on a flight at 2pm on Wednesday. I hope my presentation can be scheduled consistently with these travel plans? Robert Dewar
Re: Switch statement case range
As comprehensive as that list is (and it is indeed quite impressive), it is yet a small subset I assure you. LOL! :-) I have to be honest ... the more I learn about GCC the more impressed I am. I think it 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 --- On Sun, 4/8/12, Oleg Endo wrote: > From: Oleg Endo > Subject: Re: Switch statement case range > To: "Rick Hodgin" > Cc: "Marek Polacek" , "gcc" > Date: Sunday, April 8, 2012, 12:14 PM > On Sun, 2012-04-08 at 09:07 -0700, > Rick Hodgin wrote: > > Thank you! > > > > I'd like to find out some day exactly how much I > _don't_ know. :-) > > > > Knock yourself out ;) > http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html > > Cheers, > Oleg > >
Re: RFC: -Wall by default
On 07/04/2012 23:58, Gabriel Dos Reis wrote: > On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote: >>> -Wunused-function >>> -Wunused-label >>> -Wunused-value >>> -Wunused-variable >> IMHO we should move the -Wunused ones into -Wextra if we're going to turn on >> -Wall by default. The rest seem pretty reasonable defaults to me. > > Even if we do not turn on -Wall by default, do you think we should > have -Wunused in -Wall? I think they're of limited use, bearing in mind typical C usage patterns, but unless we were upheaving everything anyway, I can't see much reason to change the status quo. cheers, DaveK
Re: i370 port
Hi Paul,
> I put some debugging on here:
>
> op0 = XEXP (operands[0], 0);
> if (GET_CODE (op0) == REG
> || (GET_CODE (op0) == PLUS && GET_CODE (XEXP (op0, 0)) == REG
> && GET_CODE (XEXP (op0, 1)) == CONST_INT
> && (unsigned) INTVAL (XEXP (op0, 1)) < 4096))
> {
> op0 = operands[0];
> fprintf(stderr, \"used as-is\n\");
> }
> else
> {
> op0 = replace_equiv_address (operands[0], copy_to_mode_reg (SImode,
> op0));
> fprintf(stderr, \"replaced\n\");
> }
>
> And I found out that op0 is already being "replaced". Shouldn't this
> replacement eliminate the index register and just have a base
> register, so that I don't need the hack further down?
Well, sure, but this code is just the expander. If you check the
RTL dumps, you'll notice that after the expand step, there will
indeed be just a single base register.
The problem is that RTL optimization steps *after* expand may
modify the generated RTX. In particular reload will do so, and
it will be guided by the constraints to tell it which modifications
are allowed for this insn. If the actual insn pattern (not the
expander) has a generic "m" constraint, reload will feel free to
replace the address with any generally valid address pattern for
the machine, including those that use an index registers, if it
considers this replacement profitable.
This is exactly the reason why you need a constraint letter
that accepts only addresses without index register, instead of
just using plain "m".
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: RFC: -Wall by default
On 8 April 2012 16:16, James Cloos wrote: > > Sure. Making a few more of the -W flags on by default may be OK, > depending on the chosen list. It is the idea of turing all possible > warning options on by default which is unreasonable. Noone's suggested doing that. As Gaby said, -Wall doesn't turn on all warnings. > Defaulting to -Wall also fails as a user interface design. -Wall is > a nice, short, sweet, easy to type optiong which one readily can add > at any time. So is -Wno-all > Forcing one to have to find all of the -Wno-... options > to avoid unwanted annoyances, That applies even if -Wall isn't on by default. People who use -Wall (which means lots of people) still have to use -Wno-xxx to disable the warnings they don't want. Making -Wall on by default doesn't change that. Anyway, GCC prints the option that controls a warning as part of the diagnostic, so it's trivial to find which options control the diagnostics that are annoying you. > or to the -Wno-all and a set of -Ws > which one does want is far more cumbersome. Why is using -Wno-all -Wfoo -Wbar "far more cumbersome" than what you have to do to get the same effect today? i.e. -Wfoo -Wbar Those points apply equally to what we have today and so aren't really relevant to whether -Wall should be on by default or not. > And what if new warning are added. Does anyone really want them *all* > on by default as soon as the code lands? That argument also applies equally to -Wall as it is today, maintainers need to decide if new warnings should be included in -Wall or not, as that affects everyone who uses -Wall (which is a large number of users.) That wouldn't be any different if -Wall was enabled by default. > If there are some useful warning not already on by default which tend > not to false-positive and provide useful, beneficial information when > triggered, then it is reasonable to look into starting to default-enable > them. That's not far from what has been proposed (although -Wall currently contains some warnings that don't fit into that category, so maybe a -Wstandard set would be useful. > Turning *all* of them on willy-nilly is not. Noone's suggesting that. FWIW we do sometimes have to close invalid bugzilla reports that complain about no warning when the user simply failed to use -Wall, or because the code is clearly wrong and they would have been told so if they'd just used -Wall. That does imply that people who don't know what they're doing (and so might benefit most from enabling warnings) aren't aware of -Wall. The people who don't want -Wall (or -Wstandard) enabled are likely to be the ones who know how to use -Wno-all or whatever to get what they want.
Re: RFC: -Wall by default
On 4/8/2012 1:56 PM, Jonathan Wakely wrote: The people who don't want -Wall (or -Wstandard) enabled are likely to be the ones who know how to use -Wno-all or whatever to get what they want. I see no evidence that supports that guess. On the contrary, I would guess that if -Wall is set by default, you will get lots of (probably invalid) complaints of the sort "why is gcc complaining at perfectly correct code", and of course in some cases those will be false positives, so they will be valid complaints.
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar wrote: > On 4/8/2012 1:56 PM, Jonathan Wakely wrote: >> >> The people who don't want -Wall (or >> -Wstandard) enabled are likely to be the ones who know how to use >> -Wno-all or whatever to get what they want. > > > I see no evidence that supports that guess. On the contrary, I > would guess that if -Wall is set by default, so your evidence to the contrary is a guess ;-p > you will get lots > of (probably invalid) complaints of the sort "why is gcc complaining > at perfectly correct code", and of course in some cases those will > be false positives, so they will be valid complaints. >
Re: RFC: -Wall by default
On 8 April 2012 19:51, Robert Dewar wrote: > On 4/8/2012 1:56 PM, Jonathan Wakely wrote: >> >> The people who don't want -Wall (or >> -Wstandard) enabled are likely to be the ones who know how to use >> -Wno-all or whatever to get what they want. > > > I see no evidence that supports that guess. On the contrary, I > would guess that if -Wall is set by default, you will get lots > of (probably invalid) complaints of the sort "why is gcc complaining > at perfectly correct code", and of course in some cases those will > be false positives, so they will be valid complaints. Again, that also applies when people use -Wall today: a false positive is unwanted even if you use -Wall, and those false positives are bugs and so having them in bugzilla is good. For the cases where the warning is valid we're doing the user a service by showing or teaching them that their code is problematic. Having to triage and close invalid bug reports from those users may be a bit tedious but still does them a service by encouraging them to improve their code. So there are positive aspects of both valid and invalid reports caused by enabling -Wall PR 51270 is just one example I happened across today where the reporter says "constness violation is accepted without any warning" then shows that g++ was being invoked without any warning options. At least some users expect to get warnings without having to request them explicitly. GCC doesn't tell you to use -Wall to get diagnostics that weren't printed but could have been, whereas when a diagnostic is issued the relevant option is shown. The option to suppress an unwanted warning is arguably more discoverable than the option to enable a warning that isn't being given. (I say arguably, because you have to know to say -Wno-xxx to suppress the warnings that print -Wxxx)
Re: RFC: -Wall by default
On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote: On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar wrote: On 4/8/2012 1:56 PM, Jonathan Wakely wrote: The people who don't want -Wall (or -Wstandard) enabled are likely to be the ones who know how to use -Wno-all or whatever to get what they want. I see no evidence that supports that guess. On the contrary, I would guess that if -Wall is set by default, so your evidence to the contrary is a guess ;-p Yes, of course, though based to some extent on our experience with warnings that are enabled by default in GNAT, we often get newbie questions that complain about these warnings, it is somewhat inevitable, that if you have people who do not know the language, they will find some quite legitimate warnings puzzling, especially if they are false positives (we really try VERY hard to avoid false positives in the default set of warnings .. to me the trouble with -Wall is that it generates lots of false positives. Now a -Wstandard that is crafted with a different design goal than -Wall (avoid false positives at all costs) would be quite a different matter, and that is why I have supported this approach if anything at all is done. Basically in GNAT we regard it as a bug to work on if a default warning is a false positive (certainly not an attitude that is taken with -Wall, if I am wrong, I have hundreds of bugs to report :-)) Yes, occasionally you get a case that you end up considering SO obscure that you violate this rule, but it is rare.
Re: RFC: -Wall by default
On 4/8/2012 3:37 PM, Jonathan Wakely wrote: Again, that also applies when people use -Wall today: a false positive is unwanted even if you use -Wall, and those false positives are bugs and so having them in bugzilla is good. Do you really want me to file hundreds of bug reports that are for cases of uninitialized variables well known to everyone, and well understood by everyone, and not easy to fix (or would have been fixed long ago)?
Re: RFC: -Wall by default
On 8 April 2012 20:54, Robert Dewar wrote: > On 4/8/2012 3:37 PM, Jonathan Wakely wrote: > >> Again, that also applies when people use -Wall today: a false positive >> is unwanted even if you use -Wall, and those false positives are bugs >> and so having them in bugzilla is good. > > > Do you really want me to file hundreds of bug reports that are for > cases of uninitialized variables well known to everyone, and well > understood by everyone, and not easy to fix (or would have been > fixed long ago)? No, because those are already in bugzilla, and there's a whole wiki page about improving that particular warning. But I'd be just as happy with a -Wstandard (by any name) enabled by default as I would be with -Wall on by default. Only enabling warnings with very little chance of false positives would avoid most of the negative consequences.
Re: RFC: -Wall by default
On 4/8/2012 4:02 PM, Jonathan Wakely wrote: No, because those are already in bugzilla, and there's a whole wiki page about improving that particular warning. Yes, I know, and that page is to me good justification for NOT including this warning in the set that is on by default. But I'd be just as happy with a -Wstandard (by any name) enabled by default as I would be with -Wall on by default. Only enabling warnings with very little chance of false positives would avoid most of the negative consequences. Yes, I think that is the case! That's certainly the philosophy we follow in GNAT. One debatable issue is the following kind of warnings: 1. procedure k is 2.x : integer; | >>> warning: variable "x" is assigned but never read 3. begin 4.x := 2; | >>> warning: useless assignment to "x", value never referenced 5. end; These (not on by default in GNAT by the way) are examples of warnings that most certainly are NOT false positives, but they are examples of warnings about perfectly valid code. That's quite different from a warning like: 1. function l (m : integer) return Boolean is 2. begin 3.if m > 10 then | >>> warning: "return" statement missing following this statement >>> warning: Program_Error may be raised at run time 4. return False; 5.end if; 6. end; Where you definitely have a real bug in the code, and the code is not in any reasonable sense valid (yes, the RM does not make this code illegal, but that's just because it would be too much effort). An interesting third category is: 1. procedure Norm is 2. begin 3.pragma Dummy_Body; | >>> warning: unrecognized pragma "Dummy_Body" 4.null; 5. end; Here the standard mandates ignoring unrecognized pragmas, so the compiler is doing the right thing, and in one sense the above is a false positive, since there is nothing wrong. However, in this case we have the following (highly peculiar) statement in the RM 13 The implementation shall give a warning message for an unrecognized pragma name. (why highly peculiar, becuase in a formal definition of this kind the notion of "warning message" is totally undefined and pretty much undefinable.)
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 2:53 PM, Robert Dewar wrote: > On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote: >> >> On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar wrote: >>> >>> On 4/8/2012 1:56 PM, Jonathan Wakely wrote: The people who don't want -Wall (or -Wstandard) enabled are likely to be the ones who know how to use -Wno-all or whatever to get what they want. >>> >>> >>> >>> I see no evidence that supports that guess. On the contrary, I >>> would guess that if -Wall is set by default, >> >> >> so your evidence to the contrary is a guess ;-p > > > Yes, of course, though based to some extent on our experience > with warnings that are enabled by default in GNAT, we often > get newbie questions that complain about these warnings, it is > somewhat inevitable, that if you have people who do not know the > language, they will find some quite legitimate warnings puzzling, > especially if they are false positives (we really try VERY hard > to avoid false positives in the default set of warnings .. to me > the trouble with -Wall is that it generates lots of false positives. and you do not want to grant the benefit of experience to those of us handling diagnostics requests and also based on what other implementations are doing? > Now a -Wstandard that is crafted with a different design goal than > -Wall (avoid false positives at all costs) would be quite a different > matter, and that is why I have supported this approach if anything > at all is done. Note at the exception of -Wunused (which is disputable) and -Wuninitialized, -Wstandard is essentially -Wall. > > Basically in GNAT we regard it as a bug to work on if a default > warning is a false positive I think I agree with this. I suspect the only difference might be that I do not believe the fix is necessarily to turn them off. > (certainly not an attitude that is > taken with -Wall, if I am wrong, I have hundreds of bugs to > report :-)) Yes, occasionally you get a case that you end up > considering SO obscure that you violate this rule, but it is > rare. -Wall, despite the name, does not turn on all warnings.
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar wrote: > On 4/8/2012 3:37 PM, Jonathan Wakely wrote: > >> Again, that also applies when people use -Wall today: a false positive >> is unwanted even if you use -Wall, and those false positives are bugs >> and so having them in bugzilla is good. > > > Do you really want me to file hundreds of bug reports that are for > cases of uninitialized variables well known to everyone, Yes, unless thy are duplicates. > and well > understood by everyone, and not easy to fix (or would have been > fixed long ago)?
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar wrote: > On 4/8/2012 4:02 PM, Jonathan Wakely wrote: >> But I'd be just as happy with a -Wstandard (by any name) enabled by >> default as I would be with -Wall on by default. Only enabling warnings >> with very little chance of false positives would avoid most of the >> negative consequences. > > > Yes, I think that is the case! That's certainly the philosophy we > follow in GNAT. and I think that is all this is about. I am puzzled we are still arguing...
Re: RFC: -Wall by default
On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote: I think I agree with this. I suspect the only difference might be that I do not believe the fix is necessarily to turn them off. Well there are three possibilities a) fix the false positives, at the possible expense of introducing new false negatives, but most of these warnings are very far from sound anyway (they do not guarantee that code not raising the warning is free from the problem involved). b) remove from -Wstandard c) leave in -Wstandard and live with the false positives I am saying I prefer these alternatives in the order given above. I suspect you agree with this ordering? I use -Wstandard here just as a label for whatever gets turned on by default if a change is made. Whether the new switch with this name is introduced is an orthogonal issue. (certainly not an attitude that is taken with -Wall, if I am wrong, I have hundreds of bugs to report :-)) Yes, occasionally you get a case that you end up considering SO obscure that you violate this rule, but it is rare. -Wall, despite the name, does not turn on all warnings. Yes, I know, what's that got to do with the comment above
Re: RFC: -Wall by default
On 4/8/2012 4:25 PM, Gabriel Dos Reis wrote: On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar wrote: On 4/8/2012 3:37 PM, Jonathan Wakely wrote: Again, that also applies when people use -Wall today: a false positive is unwanted even if you use -Wall, and those false positives are bugs and so having them in bugzilla is good. Do you really want me to file hundreds of bug reports that are for cases of uninitialized variables well known to everyone, Yes, unless thy are duplicates. I think you know these *ARE* duplicates because everyone using -Wall with gcc encounters them frequently! and well understood by everyone, and not easy to fix (or would have been fixed long ago)?
Re: RFC: -Wall by default
On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote: On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar wrote: On 4/8/2012 4:02 PM, Jonathan Wakely wrote: But I'd be just as happy with a -Wstandard (by any name) enabled by default as I would be with -Wall on by default. Only enabling warnings with very little chance of false positives would avoid most of the negative consequences. Yes, I think that is the case! That's certainly the philosophy we follow in GNAT. and I think that is all this is about. I am puzzled we are still arguing... We are discussing. And note that the idea of -Wstandard was certainly not in your original proposal (note the [by now confusing] subject of this thread!)
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 3:28 PM, Robert Dewar wrote: > On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote: > >> I think I agree with this. I suspect the only difference might be that >> I do not believe the fix is necessarily to turn them off. > > > Well there are three possibilities > > a) fix the false positives, at the possible expense of introducing > new false negatives, but most of these warnings are very far from > sound anyway (they do not guarantee that code not raising the warning > is free from the problem involved). > > b) remove from -Wstandard > > c) leave in -Wstandard and live with the false positives > > I am saying I prefer these alternatives in the order given above. > I suspect you agree with this ordering? Yes. > > I use -Wstandard here just as a label for whatever gets turned > on by default if a change is made. Whether the new switch with > this name is introduced is an orthogonal issue. > >> >>> (certainly not an attitude that is >>> taken with -Wall, if I am wrong, I have hundreds of bugs to >>> report :-)) Yes, occasionally you get a case that you end up >>> considering SO obscure that you violate this rule, but it is >>> rare. >> >> >> -Wall, despite the name, does not turn on all warnings. > > > Yes, I know, what's that got to do with the comment above >
Re: RFC: -Wall by default
On Sun, Apr 8, 2012 at 3:29 PM, Robert Dewar wrote: > On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote: >> >> On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar wrote: >>> >>> On 4/8/2012 4:02 PM, Jonathan Wakely wrote: >> >> But I'd be just as happy with a -Wstandard (by any name) enabled by default as I would be with -Wall on by default. Only enabling warnings with very little chance of false positives would avoid most of the negative consequences. >>> >>> >>> >>> Yes, I think that is the case! That's certainly the philosophy we >>> follow in GNAT. >> >> >> and I think that is all this is about. I am puzzled we are still >> arguing... > > > We are discussing. And note that the idea of -Wstandard was certainly > not in your original proposal (note the [by now confusing] subject > of this thread!) no, -Wstandard wasn't in my original proposal. It is the name suggested by Miles for the list I gave Arnaud upon request. -- Gaby
Re: RFC: -Wall by default
On 4/8/2012 4:59 PM, Gabriel Dos Reis wrote: no, -Wstandard wasn't in my original proposal. It is the name suggested by Miles for the list I gave Arnaud upon request. I know that, I can read -:) I am just saying I think this issue still needs discussion (and you were complaining about continuing "arguing", to me btw discussion is American for argument :-))
gcc-4.8-20120408 is now available
Snapshot gcc-4.8-20120408 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120408/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 186227 You'll find: gcc-4.8-20120408.tar.bz2 Complete GCC MD5=715ad3dfd98e3d608b7c4d9c1928ecba SHA1=86b770ccd53f2bb25ba7d7d800715c7468aecf05 Diffs from 4.8-20120401 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Warn if making external references to local stack memory?
Hi
GCC does warn if returning a pointer to a local variable (stack memory).
But there are alot of more cases where GCC could possibly warn,
eg. when references are made to local variables or stack memory.
See this attached example code.
GCC warns for first case, but not the others.
I think all cases can be considered program bugs,
and could trigger a compiler warning I think.
I've found out that the present warning is done in "c-typeck.c",
is this the right place to but additional warnings of this kind too?
Thanks & Best Regards
Fredrik Hederstierna
The example code file
Compiled with "-O2 -W -Wall -Wextra"
---
#include
#include
int * test_ptr;
struct test {
int *ptr;
};
int* test_return_ptr_to_stack_mem(void)
{
int a[100];
// CORRECT WARNING:
// "warning: function returns address of local variable".
// (Checking done in file gcc/c-typeck.c, function c_finish_return()).
return a;
}
void test_set_ptr_to_stack_mem(void)
{
int a[100];
// GIVE WARNING?
// "function returns with external reference to local variable?"
test_ptr = a;
return;
}
void* test_alloc_struct_ptr_to_stack_mem(void)
{
int a[100];
struct test* t = (struct test*)malloc(sizeof(struct test));
// GIVE WARNING?
// "function returns with reference to local variable?"
t->ptr = a;
return t;
}
void* test_alloc_struct_on_stack_mem(void)
{
struct test* t = (struct test*)alloca(sizeof(struct test));
t->ptr = NULL;
// GIVE WARNING?
// "function returns allocation from stack memory?"
return t;
}
int main(void)
{
// GIVES WARNING
int* t1 = test_return_ptr_to_stack_mem();
printf("Stack mem ref test 1: %p\n", t1);
// NO WARNING?
test_set_ptr_to_stack_mem();
printf("Stack mem ref test 2: %d\n", test_ptr[0]);
// NO WARNING?
struct test * t3 = test_alloc_struct_ptr_to_stack_mem();
printf("Stack mem ref test 3: %d\n", t3->ptr[0]);
// NO WARNING?
struct test * t4 = test_alloc_struct_on_stack_mem();
printf("Stack mem ref test 4: %p\n", t4->ptr);
return 0;
}
Re: Missed optimization in PRE?
On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: > On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther > wrote: >> On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: >>> On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther >>> wrote: On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: > On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther > wrote: >> On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng >> wrote: >>> Hi, >>> Following is the tree dump of 094t.pre for a test program. >>> Question is loads of D.5375_12/D.5375_14 are redundant on path >> bb7, bb5, bb6>, >>> but why not lowered into basic block 3, where it is used. >>> >>> BTW, seems no tree pass handles this case currently. >> >> tree-ssa-sink.c should do this. >> > It does not work for me, I will double check and update soon. Well, "should" as in, it's the place to do it. And certainly the pass can sink loads, so this must be a missed optimization. >>> Curiously, it is said explicitly that "We don't want to sink loads from >>> memory." >>> in tree-ssa-sink.c function statement_sink_location, and the condition is >>> >>> if (stmt_ends_bb_p (stmt) >>> || gimple_has_side_effects (stmt) >>> || gimple_has_volatile_ops (stmt) >>> || (gimple_vuse (stmt) && !gimple_vdef (stmt)) >>> <-check load >>> || (cfun->has_local_explicit_reg_vars >>> && TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode)) >>> return false; >>> >>> I haven't found any clue about this decision in ChangeLogs. >> >> Ah, that's probably because usually you want to hoist loads and sink stores, >> separating them (like a scheduler would do). We'd want to restrict sinking >> of loads to sink into not post-dominated regions (thus where they end up >> being executed less times). Hi Richard, I am testing a patch to sink load of memory to proper basic block. Everything goes fine except auto-vectorization, sinking of load sometime corrupts the canonical form of data references. I haven't touched auto-vec before and cannot tell whether it's good or bad to do sink before auto-vec. For example, the slp-cond-1.c : # i_39 = PHI D.5150_5 = i_39 * 2; D.5151_10 = D.5150_5 + 1; D.5153_17 = a[D.5150_5]; D.5154_19 = b[D.5150_5]; if (D.5153_17 >= D.5154_19) goto ; else goto ; : d0_6 = d[D.5150_5];<-this is sunk from bb3 goto ; : e0_8 = e[D.5150_5];<-this is sunk from bb3 : # d0_2 = PHI k[D.5150_5] = d0_2; D.5159_26 = a[D.5151_10]; D.5160_29 = b[D.5151_10]; if (D.5159_26 >= D.5160_29) goto ; else goto ; : d1_11 = d[D.5151_10];<-this is sunk from bb3 goto ; : e1_14 = e[D.5151_10];<-this is sunk from bb3 : ... I will look into auto-vect but not sure how to handle this case. Any comments? Thanks very much. -- Best Regards.
