Jeff Law writes:
> On 09/03/2015 02:39 AM, Richard Sandiford wrote:
>> so for now how about just turning -Wmaybe-uninitialized into
>> a warning for this function? The patch will mean that it becomes
>> a warning even if someone turns off warnings on the command line,
>> but I don't think that's
On 09/03/2015 02:39 AM, Richard Sandiford wrote:
It sounds like Jeff has a much more radical rewrite in mind,
Certainly not anything on the immediate horizon. The amount of block
copying that'd be needed to isolate the jump threading path would be
significant.
I do wonder if we should be lo
Rainer Orth writes:
> Richard Sandiford writes:
>> Jeff Law writes:
>>> On 08/05/2015 08:18 AM, Richard Sandiford wrote:
Building some targets results in a warning about orig_dup[i] potentially
being used uninitialised. I think the warning is fair, since it isn't
obvious that the
Richard Sandiford writes:
> Jeff Law writes:
>> On 08/05/2015 08:18 AM, Richard Sandiford wrote:
>>> Building some targets results in a warning about orig_dup[i] potentially
>>> being used uninitialised. I think the warning is fair, since it isn't
>>> obvious that the reog_data-based loop bound
On 08/13/2015 02:29 PM, Richard Sandiford wrote:
Jeff Law writes:
On 08/05/2015 08:18 AM, Richard Sandiford wrote:
Building some targets results in a warning about orig_dup[i] potentially
being used uninitialised. I think the warning is fair, since it isn't
obvious that the reog_data-based lo
Jeff Law writes:
> On 08/05/2015 08:18 AM, Richard Sandiford wrote:
>> Building some targets results in a warning about orig_dup[i] potentially
>> being used uninitialised. I think the warning is fair, since it isn't
>> obvious that the reog_data-based loop bound remains unchanged between:
>>
>>
On 08/05/2015 08:18 AM, Richard Sandiford wrote:
Building some targets results in a warning about orig_dup[i] potentially
being used uninitialised. I think the warning is fair, since it isn't
obvious that the reog_data-based loop bound remains unchanged between:
for (i = 0; i < recog_data.n_
On 08/05/2015 11:32 AM, Richard Sandiford wrote:
and I don't see how GCC could prove that eliminate_regs_1 doesn't
modify the value of recog_data.n_dups between the two loops.
eliminate_regs_1 calls functions like plus_constant that are defined
outside the TU and that certainly aren't pure/const.
Jeff Law writes:
> On 08/05/2015 08:18 AM, Richard Sandiford wrote:
>> Building some targets results in a warning about orig_dup[i] potentially
>> being used uninitialised. I think the warning is fair, since it isn't
>> obvious that the reog_data-based loop bound remains unchanged between:
>>
>>
On 08/05/2015 08:18 AM, Richard Sandiford wrote:
Building some targets results in a warning about orig_dup[i] potentially
being used uninitialised. I think the warning is fair, since it isn't
obvious that the reog_data-based loop bound remains unchanged between:
for (i = 0; i < recog_data.n_
Building some targets results in a warning about orig_dup[i] potentially
being used uninitialised. I think the warning is fair, since it isn't
obvious that the reog_data-based loop bound remains unchanged between:
for (i = 0; i < recog_data.n_dups; i++)
orig_dup[i] = *recog_data.dup_loc[i];
11 matches
Mail list logo
