Re: Implicit function declarations and GCC 10
* Segher Boessenkool: > Hi Florian, > > On Fri, Jul 05, 2019 at 07:49:21AM +0200, Florian Weimer wrote: >> > We already have an option for that (-Werror=implicit-function-declaration), >> > and it is an error by default with -pedantic-errors already. If you are >> > asking to make it an error by default, I second that; there needs to be a >> > wat to turn it off though. Maybe it should be an error for c99 and later >> > only, anyway? >> >> Yes, it should be an error by default, without any flags. Which is >> gnu11 mode by now, I think. So it's not sufficient to do this for >> c99/c11 mode. > > When I say "c99 and later", of course that includes gnu99 and gnu11. My > point is that we probably shouldn't by default error on this in c90 mode, > since it is a valid construct there, and not extraordinarily harmful. Ah, sorry. Yes, this isn't for c90 mode. I'm less concerned with programmers who set -std=, they can use -Werror=implicit-function-declaration as well if they want. It is really the flag-less default that matters to me. >> >> According to my observations, lack of an error diagnostic has turned >> >> into a major usability issue. For bugs related to pointer truncation, >> >> we could perhaps change the C front end to produce a hard error if an >> >> int value returned from an implicitly declared function is converted to >> >> a pointer. >> > >> > No, if we allow implicit declarations at all, your proposal would error >> > on valid (but improbable :-) ) code. We should only ever give hard >> > errors if we *know* something is wrong. >> >> Yes, it should be valid code on 32-bit targets, which is why it's so >> common. > > It is valid for *all* targets. C11 6.3.2.3/5: > An integer may be converted to any pointer type. Except as previously > specified, the result is implementation-defined, might not be correctly > aligned, might not point to an entity of the referenced type, and might > be a trap representation. > > and GCC documents that implementation-defined behaviour as > A cast from integer to pointer discards most-significant bits if > the pointer representation is smaller than the integer type, > extends according to the signedness of the integer type if the > pointer representation is larger than the integer type, otherwise > the bits are unchanged. What I meant is that this works just fine on 32-bit architectures because there is no truncation involved. >> >> Implicit int we should remove as well. Checking configure scripts for >> >> both issues at the same time would not be much more work. >> > >> > We could enable -Wimplicit-int by default for c99 and later, maybe even >> > its -Werror- version. This conflicts with at least -fms-extensions it, >> > seems, dunno what to do there. >> >> We can keep this a separate discussion if it helps. > > Yes please. Can you make separate PRs? There is essentially no > overlap. I filed PR91092 and PR91093. Thanks, Florian
Re: Doubts regarding the _Dependent_ptr keyword
On Fri, Jul 5, 2019 at 1:08 AM Akshat Garg wrote: > > On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek wrote: >> >> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote: >> > > I think fully guaranteeing this is hard (besides when you use >> > > volatile), we have the very same issue when dealing with >> > > pointer provenance rules, known for years and not fixed >> > > (and I don't see a good way to fix these issues without >> > > sacrifying performance everywhere). >> > > >> > > Good luck ;) >> > >> > Thank you, we will need it! ;-) >> >> Well, luck probably isn't all you need, you'll need some way to represent >> those dependencies in the IL (both GIMPLE and RTL) that would ensure that >> they aren't optimized away, because just hoping that optimization don't mess >> that up or just patching a few optimizations you discover first isn't going >> to be very reliable. Say don't rewrite those into SSA form and represent >> them close to how volatile ptrs are handled at least for the beginning, and >> if there are safe optimizations special case those, rather than allowing all >> optimizations on those and hope it will work out. >> >> Jakub > > I don't understand this statement completely "Say don't rewrite those into > SSA form and represent them close to how volatile ptrs are handled at least > for the beginning, and if there are safe optimizations special case those, > rather than allowing all optimizations on those and hope it will work out.". > Are you saying that we should try to represent dependent ptrs as volatile > ptrs for some places? We should figure out all the places where a check for > volatile ptrs happens and we check for dependent ptrs there also and see if > we can allow the optimization or not. > Am I getting you correctly, please tell? I think Jakub means not to use volatile as is but mimic some of its properties (like we do not rewrite volatile vars into SSA form which fends off most optimizations turing data dependences into crontrol dependences, not all speculation though). I think "fixing" the GIMPLE optimizers to not mess up is possible even with SSA (just a bit tedious and fragile), but real issues will start at the RTL level where you completely lose properties like "this is a [dependent] pointer". Richard. > > -Akshat
Re: Implicit function declarations and GCC 10
On 04/07/2019 12:27, Florian Weimer wrote: > Implicit function declarations were removed from C99, more than twenty > years ago. So far, GCC only warns about them because there were too > many old configure scripts where an error would lead to incorrect > configure check failures. > > I can try to fix the remaining configure scripts in Fedora and submit > the required changes during this summer and fall. > > I would appreciate if GCC 10 refused to declare functions implicitly by > default. +1 > > According to my observations, lack of an error diagnostic has turned > into a major usability issue. For bugs related to pointer truncation, > we could perhaps change the C front end to produce a hard error if an > int value returned from an implicitly declared function is converted to > a pointer. But the other case involves functions defined as returning > _Bool, and the result is used in a boolean context. The x86-64 ABI only > requires that the lowest 8 bits of the return value are defined, so an > implicit int results in int values which incorrectly compare as inqueal > to zero. > > Given that the pointer truncation issue is only slightly more common, > than the _Bool issue, I don't think the diagnostic improvement for > pointers would be very helpful, and we should just transition to errors. > > Implicit int we should remove as well. Checking configure scripts for > both issues at the same time would not be much more work. +1 for making implicit int an error by default. > > Thanks, > Florian >
XOOM Deactivation Request
Dear Customer, Your recent request to update your email (gcc@gcc.gnu.org) associated with your account with Xoom will be processed shortly. If this request was not made by you, you are required to use the button below to stop the request! Cancel Request Why it is Important Helps us protect your security and privacy of our customers. About Us | User Agreement | Privacy Policy | Security | Site Map Copyright © 2018 PayPal.
Re: Implicit function declarations and GCC 10
On Fri, Jul 05, 2019 at 09:15:12AM +0200, Florian Weimer wrote: > * Segher Boessenkool: > > > Hi Florian, > > > > On Fri, Jul 05, 2019 at 07:49:21AM +0200, Florian Weimer wrote: > >> > We already have an option for that > >> > (-Werror=implicit-function-declaration), > >> > and it is an error by default with -pedantic-errors already. If you are > >> > asking to make it an error by default, I second that; there needs to be a > >> > wat to turn it off though. Maybe it should be an error for c99 and later > >> > only, anyway? > >> > >> Yes, it should be an error by default, without any flags. Which is > >> gnu11 mode by now, I think. So it's not sufficient to do this for > >> c99/c11 mode. > > > > When I say "c99 and later", of course that includes gnu99 and gnu11. My > > point is that we probably shouldn't by default error on this in c90 mode, > > since it is a valid construct there, and not extraordinarily harmful. > > Ah, sorry. Yes, this isn't for c90 mode. I'm less concerned with > programmers who set -std=, they can use > -Werror=implicit-function-declaration as well if they want. It is > really the flag-less default that matters to me. Yup. > What I meant is that this works just fine on 32-bit architectures > because there is no truncation involved. You mean "it most likely does what the author intended". Ah. > >> >> Implicit int we should remove as well. Checking configure scripts for > >> >> both issues at the same time would not be much more work. > >> > > >> > We could enable -Wimplicit-int by default for c99 and later, maybe even > >> > its -Werror- version. This conflicts with at least -fms-extensions it, > >> > seems, dunno what to do there. > >> > >> We can keep this a separate discussion if it helps. > > > > Yes please. Can you make separate PRs? There is essentially no > > overlap. > > I filed PR91092 and PR91093. Thanks! Segher
Re: Doubts regarding the _Dependent_ptr keyword
On Fri, 5 Jul, 2019, 4:50 PM Richard Biener, wrote: > On Fri, Jul 5, 2019 at 1:08 AM Akshat Garg wrote: > > > > On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek wrote: > >> > >> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote: > >> > > I think fully guaranteeing this is hard (besides when you use > >> > > volatile), we have the very same issue when dealing with > >> > > pointer provenance rules, known for years and not fixed > >> > > (and I don't see a good way to fix these issues without > >> > > sacrifying performance everywhere). > >> > > > >> > > Good luck ;) > >> > > >> > Thank you, we will need it! ;-) > >> > >> Well, luck probably isn't all you need, you'll need some way to > represent > >> those dependencies in the IL (both GIMPLE and RTL) that would ensure > that > >> they aren't optimized away, because just hoping that optimization don't > mess > >> that up or just patching a few optimizations you discover first isn't > going > >> to be very reliable. Say don't rewrite those into SSA form and > represent > >> them close to how volatile ptrs are handled at least for the beginning, > and > >> if there are safe optimizations special case those, rather than > allowing all > >> optimizations on those and hope it will work out. > >> > >> Jakub > > > > I don't understand this statement completely "Say don't rewrite those > into SSA form and represent them close to how volatile ptrs are handled at > least for the beginning, and if there are safe optimizations special case > those, rather than allowing all optimizations on those and hope it will > work out.". > > Are you saying that we should try to represent dependent ptrs as > volatile ptrs for some places? We should figure out all the places where a > check for volatile ptrs happens and we check for dependent ptrs there also > and see if we can allow the optimization or not. > > Am I getting you correctly, please tell? > > I think Jakub means not to use volatile as is but mimic some of its > properties (like we do not rewrite volatile > vars into SSA form which fends off most optimizations turing data > dependences into crontrol dependences, > not all speculation though). > > I think "fixing" the GIMPLE optimizers to not mess up is possible even > with SSA (just a bit tedious and fragile), > but real issues will start at the RTL level where you completely lose > properties like "this is a [dependent] pointer". > > Richard. > Thank you, Richard and Jakub, both for giving your valuable suggestions and directions. Akshat > > > > > -Akshat >
gcc-8-20190705 is now available
Snapshot gcc-8-20190705 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190705/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 273149 You'll find: gcc-8-20190705.tar.xzComplete GCC SHA256=f6274936faca5ec60ad1b8dde8c222ce12f4906110cc7ecf87634f35c36b SHA1=ed1e8d0b86a951d45cd25f56bbb57b52db3f4e01 Diffs from 8-20190628 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-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.
