Copyright assignment to FSF
Hello, I’m writing to you regarding copyright assignment to FSF related to contributions to GNU GCC. I’m currently working at Inria (French National Institute for computer science). I suppose I need a form for all future changes (I plan to make several separate contributions) and an employer disclaimer. Could you please send me the documents and some instructions on how we handle this process? Best regards, Laurent Thévenoux (http://perso.ens-lyon.fr/laurent.thevenoux/)
GCC 4.9.4 Released
The GNU Compiler Collection version 4.9.4 has been released. GCC 4.9.4 is a bug-fix release from the GCC 4.9 branch containing important fixes for regressions and serious bugs in GCC 4.9.3 with more than 159 bugs fixed since the previous release. This is also the last release from the GCC 4.9 branch, GCC continues to be maintained on the GCC 5 and GCC 6 branches and the development trunk. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 4.9 branch is now closed
After the GCC 4.9.4 release the GCC 4.9 branch is now closed. Please refrain from committing to it from now on. Thanks, Richard.
Re: GCC 4.9.4 Released
Please remove me from this group...' > On Aug 3, 2016, at 3:02 AM, Richard Biener wrote: > > The GNU Compiler Collection version 4.9.4 has been released. > > GCC 4.9.4 is a bug-fix release from the GCC 4.9 branch > containing important fixes for regressions and serious bugs in > GCC 4.9.3 with more than 159 bugs fixed since the previous release. > > This is also the last release from the GCC 4.9 branch, GCC continues > to be maintained on the GCC 5 and GCC 6 branches and the development > trunk. > > This release is available from the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually!
Change of assumptions/behavior with -ftree-vrp in gcc 4.8+?
Hi,
The program listed below seems to invoke optimization behavior that
produces different results pre 4.8 and 4.8+ versions of gcc. Using the
-fno-tree-vrp option makes things consistent again. I make no claim of
an understanding of what this flag really does.
The program is badly written since the first operand to && in the while
loop conditional will cause an invalid array access. I'm assuming that
optimization behavior is unpredictable when the assumption that there
will be no invalid array accesses is broken (and thus execution/output
is untrustworthy), but I am curious as to why there is a change with
4.8+. The only concern I'd have is if this change may somehow affect
other, correctly written code.
# gcc 4.8 produces this:
$ gcc-4.8 -O2 fk2.c && ./a.out
i after loop (array size is 5): 5
found at 5, answer is 0
# pre gcc 4.8 produces this:
$ gcc-4.4 -O2 fk2.c && ./a.out
i after loop (array size is 5): 5
This should be printed.
found at 4, answer is 6
$ gcc-4.6 -O2 fk2.c && ./a.out
i after loop (array size is 5): 5
This should be printed.
found at 4, answer is 6
Program:
#include
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
unsigned int numbers[] = {
10,
9,
8,
7,
6,
};
/* find the element closest to elem */
int main()
{
unsigned int elem = 0;
unsigned int i = 0;
while ((elem < numbers[i]) && (i < ARRAY_SIZE(numbers)))
i++;
printf("i after loop (array size is %lu): %d\n",
ARRAY_SIZE(numbers), i);
if (i == ARRAY_SIZE(numbers)) {
printf("This should be printed.\n");
i--;
}
printf("found at %d, answer is %u\n", i, numbers[i]);
return 0;
}
Thanks,
Vikram
Re: Change of assumptions/behavior with -ftree-vrp in gcc 4.8+?
On Wed, Aug 3, 2016 at 12:06 PM, Vikram Mulukutla
wrote:
> Hi,
>
> The program listed below seems to invoke optimization behavior that produces
> different results pre 4.8 and 4.8+ versions of gcc. Using the -fno-tree-vrp
> option makes things consistent again. I make no claim of an understanding of
> what this flag really does.
>
> The program is badly written since the first operand to && in the while loop
> conditional will cause an invalid array access. I'm assuming that
> optimization behavior is unpredictable when the assumption that there will
> be no invalid array accesses is broken (and thus execution/output is
> untrustworthy), but I am curious as to why there is a change with 4.8+. The
> only concern I'd have is if this change may somehow affect other, correctly
> written code.
>
> # gcc 4.8 produces this:
> $ gcc-4.8 -O2 fk2.c && ./a.out
> i after loop (array size is 5): 5
> found at 5, answer is 0
>
> # pre gcc 4.8 produces this:
> $ gcc-4.4 -O2 fk2.c && ./a.out
> i after loop (array size is 5): 5
> This should be printed.
> found at 4, answer is 6
>
> $ gcc-4.6 -O2 fk2.c && ./a.out
> i after loop (array size is 5): 5
> This should be printed.
> found at 4, answer is 6
>
> Program:
>
> #include
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> unsigned int numbers[] = {
> 10,
> 9,
> 8,
> 7,
> 6,
> };
>
> /* find the element closest to elem */
> int main()
> {
> unsigned int elem = 0;
> unsigned int i = 0;
>
> while ((elem < numbers[i]) && (i < ARRAY_SIZE(numbers)))
> i++;
You are invoking undefined behavior by accessing numbers[5].
Thanks,
Andrew Pinski
>
> printf("i after loop (array size is %lu): %d\n",
> ARRAY_SIZE(numbers), i);
>
> if (i == ARRAY_SIZE(numbers)) {
> printf("This should be printed.\n");
> i--;
> }
>
> printf("found at %d, answer is %u\n", i, numbers[i]);
>
> return 0;
> }
>
> Thanks,
> Vikram
Re: Change of assumptions/behavior with -ftree-vrp in gcc 4.8+?
On Wed, Aug 3, 2016 at 12:10 PM, Andrew Pinski wrote:
> On Wed, Aug 3, 2016 at 12:06 PM, Vikram Mulukutla
> wrote:
>> Hi,
>>
>> The program listed below seems to invoke optimization behavior that produces
>> different results pre 4.8 and 4.8+ versions of gcc. Using the -fno-tree-vrp
>> option makes things consistent again. I make no claim of an understanding of
>> what this flag really does.
>>
>> The program is badly written since the first operand to && in the while loop
>> conditional will cause an invalid array access. I'm assuming that
>> optimization behavior is unpredictable when the assumption that there will
>> be no invalid array accesses is broken (and thus execution/output is
>> untrustworthy), but I am curious as to why there is a change with 4.8+. The
>> only concern I'd have is if this change may somehow affect other, correctly
>> written code.
>>
>> # gcc 4.8 produces this:
>> $ gcc-4.8 -O2 fk2.c && ./a.out
>> i after loop (array size is 5): 5
>> found at 5, answer is 0
>>
>> # pre gcc 4.8 produces this:
>> $ gcc-4.4 -O2 fk2.c && ./a.out
>> i after loop (array size is 5): 5
>> This should be printed.
>> found at 4, answer is 6
>>
>> $ gcc-4.6 -O2 fk2.c && ./a.out
>> i after loop (array size is 5): 5
>> This should be printed.
>> found at 4, answer is 6
>>
>> Program:
>>
>> #include
>>
>> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>>
>> unsigned int numbers[] = {
>> 10,
>> 9,
>> 8,
>> 7,
>> 6,
>> };
>>
>> /* find the element closest to elem */
>> int main()
>> {
>> unsigned int elem = 0;
>> unsigned int i = 0;
>>
>> while ((elem < numbers[i]) && (i < ARRAY_SIZE(numbers)))
>> i++;
>
>
> You are invoking undefined behavior by accessing numbers[5].
That is the defined code will never have wrong behavior happening from VRP.
Thanks,
Andrew Pinski
>
> Thanks,
> Andrew Pinski
>
>>
>> printf("i after loop (array size is %lu): %d\n",
>> ARRAY_SIZE(numbers), i);
>>
>> if (i == ARRAY_SIZE(numbers)) {
>> printf("This should be printed.\n");
>> i--;
>> }
>>
>> printf("found at %d, answer is %u\n", i, numbers[i]);
>>
>> return 0;
>> }
>>
>> Thanks,
>> Vikram
Re: Change of assumptions/behavior with -ftree-vrp in gcc 4.8+?
On 8/3/2016 12:11 PM, Andrew Pinski wrote:
On Wed, Aug 3, 2016 at 12:10 PM, Andrew Pinski wrote:
On Wed, Aug 3, 2016 at 12:06 PM, Vikram Mulukutla
wrote:
Hi,
The program listed below seems to invoke optimization behavior that produces
different results pre 4.8 and 4.8+ versions of gcc. Using the -fno-tree-vrp
option makes things consistent again. I make no claim of an understanding of
what this flag really does.
The program is badly written since the first operand to && in the while loop
conditional will cause an invalid array access. I'm assuming that
optimization behavior is unpredictable when the assumption that there will
be no invalid array accesses is broken (and thus execution/output is
untrustworthy), but I am curious as to why there is a change with 4.8+. The
only concern I'd have is if this change may somehow affect other, correctly
written code.
# gcc 4.8 produces this:
$ gcc-4.8 -O2 fk2.c && ./a.out
i after loop (array size is 5): 5
found at 5, answer is 0
# pre gcc 4.8 produces this:
$ gcc-4.4 -O2 fk2.c && ./a.out
i after loop (array size is 5): 5
This should be printed.
found at 4, answer is 6
$ gcc-4.6 -O2 fk2.c && ./a.out
i after loop (array size is 5): 5
This should be printed.
found at 4, answer is 6
Program:
#include
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
unsigned int numbers[] = {
10,
9,
8,
7,
6,
};
/* find the element closest to elem */
int main()
{
unsigned int elem = 0;
unsigned int i = 0;
while ((elem < numbers[i]) && (i < ARRAY_SIZE(numbers)))
i++;
You are invoking undefined behavior by accessing numbers[5].
That is the defined code will never have wrong behavior happening from VRP.
Thanks, that's all the confirmation that I was looking for.
Thanks,
Vikram
gcc-4.9-20160803 is now available
Snapshot gcc-4.9-20160803 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160803/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 239098 You'll find: gcc-4.9-20160803.tar.bz2 Complete GCC MD5=b3908c0ba48a2c94d3fe4ace1c63e2de SHA1=0a28c89a8a34f39baa5088faee9711ea73e1f751 Diffs from 4.9-20160727 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
