On 12/18/2017 05:27 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote:
Your warning is about restrict and argument overlap, what does it have to do
with unprototyped calls? Nothing. There is no restrict in that case, and
it isn't handled as builtin if it
On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote:
> > Your warning is about restrict and argument overlap, what does it have to do
> > with unprototyped calls? Nothing. There is no restrict in that case, and
> > it isn't handled as builtin if it doesn't match the builtin's prototype.
On 12/18/2017 04:41 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote:
On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
It isn't optimized either way. In fact, the only indication
of a problem in
On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote:
> On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
> > On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
> > > It isn't optimized either way. In fact, the only indication
> > > of a problem in the code below is the new
On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
It isn't optimized either way. In fact, the only indication
of a problem in the code below is the new -Wrestrict warning:
So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0,
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
> It isn't optimized either way. In fact, the only indication
> of a problem in the code below is the new -Wrestrict warning:
So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0, 0UL);
on targets where size_t is unsigned
On 12/18/2017 11:32 AM, Bernd Edlinger wrote:
Hi Martin,
In all cases all the information necessary to detect and diagnose
or even avoid the problem is available. In fact, one might argue
that optimizing such calls (expanding them inline) would be
preferable to doing nothing and allowing the
Hi Martin,
> In all cases all the information necessary to detect and diagnose
> or even avoid the problem is available. In fact, one might argue
> that optimizing such calls (expanding them inline) would be
> preferable to doing nothing and allowing the undefined behavior
> to cause a bug at
On 12/18/2017 10:45 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote:
On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with
On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote:
> On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
> > On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
> > > On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > > > I'm not entirely up to speed with this code, but this one seemed
On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
> On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > I'm not entirely up to speed with this code, but this one seemed
> > sufficiently
> > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> > Otherwise, go with
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
Otherwise, go with maxobjsize.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Thanks for
On Mon, Dec 18, 2017 at 09:36:46AM -0700, Jeff Law wrote:
> On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > I'm not entirely up to speed with this code, but this one seemed
> > sufficiently
> > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> > Otherwise, go with
On 12/18/2017 08:10 AM, Marek Polacek wrote:
> I'm not entirely up to speed with this code, but this one seemed sufficiently
> obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> Otherwise, go with maxobjsize.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
>
15 matches
Mail list logo
