> On Oct 7, 2024, at 11:22, Jakub Jelinek wrote:
>
> On Mon, Oct 07, 2024 at 03:14:22PM +, Qing Zhao wrote:
>>> Consider the qsort case. My understanding was that the paper is making
>>> typedef int (*cmpfn) (const void *, const void *);
>>> qsort (NULL, 0, 1, (cmpfn) NULL);
>>> valid (but
On Mon, Oct 07, 2024 at 03:14:22PM +, Qing Zhao wrote:
> > Consider the qsort case. My understanding was that the paper is making
> > typedef int (*cmpfn) (const void *, const void *);
> > qsort (NULL, 0, 1, (cmpfn) NULL);
> > valid (but is
> > qsort (NULL, 1, 0, (cmpfn) NULL);
> > still inval
> On Oct 7, 2024, at 10:13, Jakub Jelinek via Gcc wrote:
>
> On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote:
>> * Joseph Myers:
>>
>>> The real question is how to achieve optimal warnings in the absence of the
>>> attribute. Should we have a variant of the nonnull attribute t
* Jakub Jelinek:
> How do you express that with access attribute, which can only have 1
> size argument?
Don't we sometimes use inline functions to handle such special cases?
> For the rest, perhaps we need some nonnull_if_nonzero argument
> which requires that the parameter identified by the fi
On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote:
> * Joseph Myers:
>
> > The real question is how to achieve optimal warnings in the absence of the
> > attribute. Should we have a variant of the nonnull attribute that warns
> > for NULL arguments but without optimizing based on t
On Fri, Oct 4, 2024 at 1:47 PM Sid Maxwell via Gcc wrote:
>
> I haven't found anything in my digging, so I'd like to ask if anyone knows
> of any mechanism in GCC for conducting peephole optimization on generated
> code. I can imagine doing this as a pass over the generated code from
> within the
