Hello,
On Fri, Oct 14 2022, Martin Liška wrote:
> On 10/14/22 08:12, Richard Biener wrote:
>> On Fri, Oct 14, 2022 at 12:54 AM Eric Botcazou via Gcc-patches
>> wrote:
>>>
Not a fan as it could potentially hide a real issue, but I don't really
have a better solution.
>>>
>>> Thanks.
>>>
On 10/14/22 08:12, Richard Biener wrote:
> On Fri, Oct 14, 2022 at 12:54 AM Eric Botcazou via Gcc-patches
> wrote:
>>
>>> Not a fan as it could potentially hide a real issue, but I don't really
>>> have a better solution.
>>
>> Thanks.
>>
>>> I pondered suggesting "access" affect type identity,
On Fri, Oct 14, 2022 at 12:54 AM Eric Botcazou via Gcc-patches
wrote:
>
> > Not a fan as it could potentially hide a real issue, but I don't really
> > have a better solution.
>
> Thanks.
>
> > I pondered suggesting "access" affect type identity, but the cases where
> > that's really important
> Not a fan as it could potentially hide a real issue, but I don't really
> have a better solution.
Thanks.
> I pondered suggesting "access" affect type identity, but the cases where
> that's really important are probably better handled by the "fn spec"
> attribute, leaving "access" strictly
On 10/13/22 06:06, Eric Botcazou via Gcc-patches wrote:
Hi,
if you compile the attached testcase with -O2 -fno-inline -Wall, you get:
In function 'process_array3':
cc1: warning: 'process_array4' accessing 4 bytes in a region of size 3 [-
Wstringop-overflow=]
cc1: note: referencing argument 1
Hi,
if you compile the attached testcase with -O2 -fno-inline -Wall, you get:
In function 'process_array3':
cc1: warning: 'process_array4' accessing 4 bytes in a region of size 3 [-
Wstringop-overflow=]
cc1: note: referencing argument 1 of type 'char[4]'
t.c:6:6: note: in a call to function
On Thu, Aug 18, 2022 at 4:46 PM Eric Botcazou wrote:
>
> > Hmm :/ But that means we _should_ force a sign extension but only
> > from ptrofftype_p ()? That is, your test above should maybe read
> >
> >signop sgn = TYPE_SIGN (type);
> >if (ptrofftype_p (type))
> > sgn = SIGNED;
> >
> Hmm :/ But that means we _should_ force a sign extension but only
> from ptrofftype_p ()? That is, your test above should maybe read
>
>signop sgn = TYPE_SIGN (type);
>if (ptrofftype_p (type))
> sgn = SIGNED;
>
> assuming 'type' is the type of lowbnd
Yes, that's essentially
On Thu, Aug 18, 2022 at 9:54 AM Eric Botcazou wrote:
>
> > Meh. OK, eventually would need "indirection" through a wide-int then.
> > Like
> >
> > offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd)))
>
> That would be OK if get_offset_range did the same, but it does not since
> Meh. OK, eventually would need "indirection" through a wide-int then.
> Like
>
> offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd)))
That would be OK if get_offset_range did the same, but it does not since it
forces a sign-extension whatever the sign of a large type:
On Wed, Aug 17, 2022 at 3:38 PM Eric Botcazou wrote:
>
> > Hmm, can we instead do
> >
> > if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd))
> >{
> > const offset_int lb = offset_int::from (lowbnd, SIGNED);
> > ...
> >
> > ?
>
> Apparently not:
>
> In file included from
> Hmm, can we instead do
>
> if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd))
>{
> const offset_int lb = offset_int::from (lowbnd, SIGNED);
> ...
>
> ?
Apparently not:
In file included from /home/eric/cvs/gcc/gcc/coretypes.h:460,
from
On Tue, Aug 16, 2022 at 3:57 PM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> the following bogus warning:
>
> In function 'lto26',
> inlined from 'main' at /home/eric/gnat/bugs/V721-018/b~lto26.adb:237:7:
> lto26.adb:11:13: warning: writing 1 byte into a region of size 0 [-Wstringop-
>
Hi,
the following bogus warning:
In function 'lto26',
inlined from 'main' at /home/eric/gnat/bugs/V721-018/b~lto26.adb:237:7:
lto26.adb:11:13: warning: writing 1 byte into a region of size 0 [-Wstringop-
overflow=]
11 | Set (R, (7, 0, 84, Stream_Element (I), 0, 0, 0), 1);
|
14 matches
Mail list logo
