> Ok. For the branch please wait until after 4.9.2 is out.
4.9.2 being out, I applied this to the branch.
> Ok. For the branch please wait until after 4.9.2 is out.
Thanks! Committed to trunk.
On Wed, Oct 29, 2014 at 6:24 AM, DJ Delorie wrote:
>
>> Looks ok to me, but can you add a testcase please?
>>
>> Also check if 4.9 is affected.
>
> Sorry for the delay, this finally made it back to the top of my to-do
> list. Testcase included which fails without and passes with this
> patch. 4.
> Looks ok to me, but can you add a testcase please?
>
> Also check if 4.9 is affected.
Sorry for the delay, this finally made it back to the top of my to-do
list. Testcase included which fails without and passes with this
patch. 4.9 is affected and the same patch fixes it. Tested on
rx-elf,
Hi,
On Tue, 17 Jun 2014 10:08:33, Richard Biener wrote:
> On Tue, Jun 17, 2014 at 4:08 AM, DJ Delorie wrote:
>>
>>> Looks ok to me, but can you add a testcase please?
>>
>> I have a testcase, but if -flto the testcase doesn't include *any*
>> definition of the test function, just all the LTO dat
On Tue, Jun 17, 2014 at 4:08 AM, DJ Delorie wrote:
>
>> Looks ok to me, but can you add a testcase please?
>
> I have a testcase, but if -flto the testcase doesn't include *any*
> definition of the test function, just all the LTO data. Is this
> normal?
Without -ffat-lto-objects yes, this is nor
> Looks ok to me, but can you add a testcase please?
I have a testcase, but if -flto the testcase doesn't include *any*
definition of the test function, just all the LTO data. Is this
normal?
> Also check if 4.9 is affected.
It is... same fix works, though.
On Wed, Jun 11, 2014 at 11:35 PM, DJ Delorie wrote:
>
> If the combined bitfields are exactly the size of the mode, the logic
> for detecting range overflow is flawed - it calculates an ending
> "position" that's the position of the first bit in the next field.
>
> In the case of "short" for examp
If the combined bitfields are exactly the size of the mode, the logic
for detecting range overflow is flawed - it calculates an ending
"position" that's the position of the first bit in the next field.
In the case of "short" for example, you get "16 > 15" without this
patch (comparing size to pos
