A question about detecting array bounds for case Warray-bounds-3.c
Hi,
For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an invalid
C program, because the last iterations of all the loops cause the access of
arrays is beyond the max size of corresponding array declarations. The
condition of checking upper bound should be "<" rather than "<=".
Right now, GCC compiler doesn't report any warning messages for this case,
should it be a bug in both test case and compiler?
But looking at http://gcc.gnu.org/PR31227 , it seems this test case is
designed to be like this on purpose. Anybody can explain about this?
The case is like below,
/* { dg-do compile } */
/* { dg-options "-O2 -Warray-bounds" } */
/* based on PR 31227 */
struct S
{
const char *abday[7];
const char *day[7];
const char *abmon[12];
const char *mon[12];
const char *am_pm[2];
};
...
for (cnt = 0; cnt <= 7; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->abday[cnt] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt <= 14; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->day[cnt - 7] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt <= 26; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->abmon[cnt - 14] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt <= 38; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->mon[cnt - 26] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt <= 40; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->am_pm[cnt - 38] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
Thanks,
-Jiangning
[pph] Merge from trunk
Lawrence, This merge brings the testsuite validation script. You can use it after builds with: $ cd $ /contrib/testsuite-management/validate_failures.py It will tell you what new failures you have in the build. Tested on x86_64. Committed to branch. Diego.
Re: C++11 no longer experimental
On 21 September 2011 19:34, Jonathan Wakely wrote: > libstdc++ manual still refers to C++ 200x! ... which I already have a patch for, before someone reports it to Bugzilla :)
Re: Volatile qualification on pointer and data
David Brown schrieb: On 21/09/2011 15:57, Ian Lance Taylor wrote: David Brown writes: On 21/09/2011 10:21, Paulo J. Matos wrote: On 21/09/11 08:03, David Brown wrote: Asking to read it by a volatile read does not change the nature of "foo" - the compiler can still implement it as a compile-time constant. But since I am accessing the data through the pointer and the pointer qualifies the data as volatile, shouldn't the compiler avoid this kind of optimization for reads through the pointer? My thought is that the nature of "foo" is independent of how it is accessed. On the other hand, some uses of a variable will affect its implementation - if you take the address of "foo" and pass that on to an external function or data, then the compiler would have to generate "foo" in memory (but in read-only memory, and it can still assume its value does not change). So I am not sure what the "correct" behaviour is here - I merely ask the question. Fortunately, this situation is not going to occur in real code. I think your description is supported by the standard. However, I also think that gcc should endeavor to fully honor the volatile qualifier in all cases, because that is least surprising to the programmer. This is not a case where we should let optimization override the programmer's desire; by using volatile, the programmer has explicitly told us that they do not want any optimization to occur. ACK. That makes sense - the principle of least surprise. And since this situation would not occur in real code (at least, not code that is expected to do something useful other than test the compiler's code generation), there is no harm in making sub-optimal object code. Are there any warning flags for "programmer doing something technically legal but logically daft", that could be triggered by such cases? :-) The combination of const and volatile can be reasonable in real world code. One example is a special function register (SFR) that is read-only but can be altered by hardware. Second example is a lookup table that can be changed after building the software, e.g. you have some calibration data that has to be drawn from the environment (drift of sensors, inductivity of motor windings, offset of actors, etc). In such a case you want to read the data from the lookup table in, say, .rodata. By no means you want the compiler to insert/propagate known values from the lookup table to immediate operands in instructions. That's exacly what "const volatile" does. Johann
Re: C++11 no longer experimental
On 21 September 2011 19:25, Joe Buck wrote: > On Wed, Sep 21, 2011 at 11:07:07AM -0700, Jonathan Wakely wrote: >> On 21 September 2011 19:00, Jonathan Wakely wrote: >> > On 21 September 2011 18:51, Nathan Ridge wrote: >> >> >> >> Now that the C++11 standard has been officially voted in, there is nothing >> >> "experimental" about it any more. >> > >> > I thought the "experimental" refers to GCC's support, not the standard's >> > status. >> >> The page you linked to even makes that clear: >> >> "Important: because the ISO C++0x draft is still evolving, GCC's >> support for C++0x is *experimental*. No attempt will be made to >> maintain backward compatibility with implementations of C++0x features >> that do not reflect the final C++0x standard." > > No, the page now claims something that is incorrect. The C++0x draft is > no longer evolving. C++11 is an official standard now. Yes, but that wasn't my point. The "experimental" never referred to the status of C++0x/C++11, it referred to the support in GCC. The subject and original suggestion of this thread are based on the premise that because C++11 is official something about GCC (except documentation) has changed. > It is still the case that the *GCC support for the standard* has to be > considered experimental, which means that it's not yet possible to freeze > the ABI and provide the same level of backward compatibility as is > provided for C++98. Exactly. > Still, the page needs an update. Sure, *all* our pages referring to C++0x need an update, and the libstdc++ manual still refers to C++ 200x! But let's not change the macro and break all the code that does: #if defined(__GXX_EXPERIMENTAL_CXX0X__) || __cplusplus >= someval As James said, when it's no longer experimental the __cplusplus macro's value will change (possible now that we *finally* set it correctly for -std=c++98) and also the option to enable it should be -std=c++11 / -std=gnu++11
Re: C++11 no longer experimental
On Wed, Sep 21, 2011 at 11:07:07AM -0700, Jonathan Wakely wrote: > On 21 September 2011 19:00, Jonathan Wakely wrote: > > On 21 September 2011 18:51, Nathan Ridge wrote: > >> > >> Now that the C++11 standard has been officially voted in, there is nothing > >> "experimental" about it any more. > > > > I thought the "experimental" refers to GCC's support, not the standard's > > status. > > The page you linked to even makes that clear: > > "Important: because the ISO C++0x draft is still evolving, GCC's > support for C++0x is *experimental*. No attempt will be made to > maintain backward compatibility with implementations of C++0x features > that do not reflect the final C++0x standard." No, the page now claims something that is incorrect. The C++0x draft is no longer evolving. C++11 is an official standard now. It is still the case that the *GCC support for the standard* has to be considered experimental, which means that it's not yet possible to freeze the ABI and provide the same level of backward compatibility as is provided for C++98. Still, the page needs an update.
Re: new C++11 features in GCC 4.7
On 21 September 2011 18:53, Nathan Ridge wrote: > > I'm wondering, are there are other new C++11 features planned > for GCC 4.7 besides "Extended friend declarations" and "Explicit > virtual overrides" (which are marked as already implemented at > http://gcc.gnu.org/projects/cxx0x.html)? There are some library changes already done, as documented at http://gcc.gnu.org/gcc-4.7/changes.html I hope to do some more allocator work for 4.7 in other containers and for debug + parallel modes. Keep an eye on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114 to see if alias-declarations get done in time.
Re: C++11 no longer experimental
On 21 September 2011 19:00, Jonathan Wakely wrote: > On 21 September 2011 18:51, Nathan Ridge wrote: >> >> Now that the C++11 standard has been officially voted in, there is nothing >> "experimental" about it any more. > > I thought the "experimental" refers to GCC's support, not the standard's > status. The page you linked to even makes that clear: "Important: because the ISO C++0x draft is still evolving, GCC's support for C++0x is *experimental*. No attempt will be made to maintain backward compatibility with implementations of C++0x features that do not reflect the final C++0x standard." i.e. the experimental implies GCC's implementation and supported feature set are not stable yet. And that's still true, not all features are implemented, and something might have to change incompatibly to support the full C++11 feature set. So I think it's inappropriate to remove the experimental label until we're ready to make some of guarantee of stability and that anything that works with G++ 4.7 will continue to work. I don't think we're at that stage yet, because there are "accepts-invalid" bugs in our current C++11 support, and they could be fixed first.
Re: C++11 no longer experimental
On 21 September 2011 18:51, Nathan Ridge wrote: > > Now that the C++11 standard has been officially voted in, there is nothing > "experimental" about it any more. I thought the "experimental" refers to GCC's support, not the standard's status. GCC's support didn't magically change when the standard was made official. (Arguably the support *is* good enough to not be labelled experimental, but that change should be made because GCC's support is good enough, not because C++11 is official.)
Re: C++11 no longer experimental
On Wed, Sep 21, 2011 at 10:51 AM, Nathan Ridge wrote: > > Hello, > > Now that the C++11 standard has been officially voted in, there is nothing > "experimental" about it any more. > > Would it be possible to remove the warning about GCC's C++11 support > being experimental from http://gcc.gnu.org/projects/cxx0x.html, and > to modify the __GXX_EXPERIMENTAL_CXX0X__ macro to be just > __GXX_CXX0X__ (or even better, __GXX_CXX11__)? > > Thanks, > Nate "Experimental" isn't really the right word anymore, and when GCC has essentially full support of C++11 we'll want to update __cplusplus (I hope!). I don't know how worthwhile it is to introduce a third name for testing the level of C++11 support in the interim. -- James
new C++11 features in GCC 4.7
Hi, I'm wondering, are there are other new C++11 features planned for GCC 4.7 besides "Extended friend declarations" and "Explicit virtual overrides" (which are marked as already implemented at http://gcc.gnu.org/projects/cxx0x.html)? Thanks, Nate
C++11 no longer experimental
Hello, Now that the C++11 standard has been officially voted in, there is nothing "experimental" about it any more. Would it be possible to remove the warning about GCC's C++11 support being experimental from http://gcc.gnu.org/projects/cxx0x.html, and to modify the __GXX_EXPERIMENTAL_CXX0X__ macro to be just __GXX_CXX0X__ (or even better, __GXX_CXX11__)? Thanks, Nate
Re: Volatile qualification on pointer and data
On 21/09/11 15:21, David Brown wrote: And since this situation would not occur in real code (at least, not code that is expected to do something useful other than test the compiler's code generation), there is no harm in making sub-optimal object code. Actually the reason why I noticed this is because one of our engineers told that GCC stopped generating instructions for certain operations when he moved from GCC45 to GCC46. This code is real code. Cheers, -- PMatos
Re: Volatile qualification on pointer and data
On 21/09/2011 15:57, Ian Lance Taylor wrote: David Brown writes: On 21/09/2011 10:21, Paulo J. Matos wrote: On 21/09/11 08:03, David Brown wrote: Asking to read it by a volatile read does not change the nature of "foo" - the compiler can still implement it as a compile-time constant. But since I am accessing the data through the pointer and the pointer qualifies the data as volatile, shouldn't the compiler avoid this kind of optimization for reads through the pointer? My thought is that the nature of "foo" is independent of how it is accessed. On the other hand, some uses of a variable will affect its implementation - if you take the address of "foo" and pass that on to an external function or data, then the compiler would have to generate "foo" in memory (but in read-only memory, and it can still assume its value does not change). So I am not sure what the "correct" behaviour is here - I merely ask the question. Fortunately, this situation is not going to occur in real code. I think your description is supported by the standard. However, I also think that gcc should endeavor to fully honor the volatile qualifier in all cases, because that is least surprising to the programmer. This is not a case where we should let optimization override the programmer's desire; by using volatile, the programmer has explicitly told us that they do not want any optimization to occur. That makes sense - the principle of least surprise. And since this situation would not occur in real code (at least, not code that is expected to do something useful other than test the compiler's code generation), there is no harm in making sub-optimal object code. Are there any warning flags for "programmer doing something technically legal but logically daft", that could be triggered by such cases? :-)
Re: Volatile qualification on pointer and data
David Brown writes: > On 21/09/2011 10:21, Paulo J. Matos wrote: >> On 21/09/11 08:03, David Brown wrote: >>> Asking to read it by a volatile read does not >>> change the nature of "foo" - the compiler can still implement it as a >>> compile-time constant. >> >> But since I am accessing the data through the pointer and the pointer >> qualifies the data as volatile, shouldn't the compiler avoid this kind >> of optimization for reads through the pointer? >> > > My thought is that the nature of "foo" is independent of how it is > accessed. On the other hand, some uses of a variable will affect its > implementation - if you take the address of "foo" and pass that on to > an external function or data, then the compiler would have to generate > "foo" in memory (but in read-only memory, and it can still assume its > value does not change). So I am not sure what the "correct" behaviour > is here - I merely ask the question. > > Fortunately, this situation is not going to occur in real code. I think your description is supported by the standard. However, I also think that gcc should endeavor to fully honor the volatile qualifier in all cases, because that is least surprising to the programmer. This is not a case where we should let optimization override the programmer's desire; by using volatile, the programmer has explicitly told us that they do not want any optimization to occur. Ian
Re: Volatile qualification on pointer and data
On 21/09/2011 10:21, Paulo J. Matos wrote: On 21/09/11 08:03, David Brown wrote: Asking to read it by a volatile read does not change the nature of "foo" - the compiler can still implement it as a compile-time constant. But since I am accessing the data through the pointer and the pointer qualifies the data as volatile, shouldn't the compiler avoid this kind of optimization for reads through the pointer? My thought is that the nature of "foo" is independent of how it is accessed. On the other hand, some uses of a variable will affect its implementation - if you take the address of "foo" and pass that on to an external function or data, then the compiler would have to generate "foo" in memory (but in read-only memory, and it can still assume its value does not change). So I am not sure what the "correct" behaviour is here - I merely ask the question. Fortunately, this situation is not going to occur in real code. It still is a regression from GCC45, however it might be considered a feature instead of a bug as I already mentioned to Ian.
Re: Volatile qualification on pointer and data
On 21/09/11 08:03, David Brown wrote: Asking to read it by a volatile read does not change the nature of "foo" - the compiler can still implement it as a compile-time constant. But since I am accessing the data through the pointer and the pointer qualifies the data as volatile, shouldn't the compiler avoid this kind of optimization for reads through the pointer? It still is a regression from GCC45, however it might be considered a feature instead of a bug as I already mentioned to Ian. -- PMatos
Re: Volatile qualification on pointer and data
On 20/09/11 17:35, Ian Lance Taylor wrote: I agree that this looks like a bug. Please file a bug report marked as a regression. Ian Thanks. Reported as 50472 even though I am just reading Davids post and he is convincing me that this might not be a bug after all, however, it is still behaving differently than GCC45 but you might then consider it a feature instead of a bug. -- PMatos
Re: Volatile qualification on pointer and data
On 20/09/2011 18:35, Ian Lance Taylor wrote:
"Paulo J. Matos" writes:
The following code:
static const unsigned int foo = 1;
unsigned int test( void )
{
const volatile unsigned int *bar =&foo;
return ( *bar );
}
in GCC45 works as expected:
$test:
ld AL,#foo ;; AL is return register
bra 0,X ;; end function
in GCC46:
$test:
ld AL,0
bra 0,X
This is worrying because qualifying the data as volatile should be
enough to prevent these sort of optimizations. It did until GCC46.
I agree that this looks like a bug. Please file a bug report marked as
a regression.
Ian
Are you sure about that? In the declaration of "bar", the "const" part
is just a promise to the compiler that the code won't try to change the
data pointed to by bar. But when "foo" is defined as "const", that
tells the compiler that foo cannot change, and being "static" and
non-volatile, the compiler then knows everything about foo and can
eliminate it in the code. Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant. So the compiler does it's best to generate code
for a volatile read of an immediate constant.
David
