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 "<=".
Rig
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.
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 :)
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
compi
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 no
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.
> >
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
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
>
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 stand
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
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
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__ m
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
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 s
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
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
qual
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 c
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 behav
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
19 matches
Mail list logo
