On July 25, 2015 1:15:21 AM GMT+02:00, Trevor Saunders
wrote:
>
>Another case is
>
>Foo *
>bar()
>{
> #if SHOULD_USE_BAR
> ...
>#else
> return NULL;
>#endif
>}
>
>And somehow your program is setup so bar is only called when
>SHOULD_USE_BAR is defined. In that sort of case it may be convenien
On 07/24/2015 05:15 PM, Trevor Saunders wrote:
Moreover, this warning works in exactly the same cases as
__attribute__((nonnull)) does for function arguments, and so far those
haven't been a source of false positives.
I'm sure I could write one ;-) And given that a FE based version of this
w
On 07/24/2015 04:41 PM, Manuel López-Ibáñez wrote:
On 25 July 2015 at 00:17, Patrick Palka wrote:
On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
wrote:
Is there a PR for this particular test case? I am interested in
improving the uninit analysis for gcc 6 so this potentially seems up
my
On 07/24/2015 04:17 PM, Patrick Palka wrote:
On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
wrote:
On 24 July 2015 at 21:30, Jeff Law wrote:
On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
On 23 July 2015 at 19:43, Jeff Law wrote:
Warning in the front-ends like this can generate
On 07/24/2015 03:55 PM, Manuel López-Ibáñez wrote:
I think it is also a matter of the particular warning and on the
balance of true positives vs. false positives in typical code-bases.
In this case, returning NULL in any code-path from a returns_nonnull
function, even if the path is currently un
On 25 July 2015 at 01:15, Trevor Saunders wrote:
> I'd actually expect reasonable cases to be fairly common. For example
I added it to -Wall, I guess we'll see... not sure how many users of
returns_nonnull are out there.
In all your cases there is no reason to prefer NULL rather than, say,
(T*)
On Fri, Jul 24, 2015 at 11:55:23PM +0200, Manuel López-Ibáñez wrote:
> On 24 July 2015 at 21:30, Jeff Law wrote:
> > On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
> >>
> >> On 23 July 2015 at 19:43, Jeff Law wrote:
> >>>
> >>> Warning in the front-ends like this can generate false positives
On 25 July 2015 at 00:17, Patrick Palka wrote:
> On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
> wrote:
> Is there a PR for this particular test case? I am interested in
> improving the uninit analysis for gcc 6 so this potentially seems up
> my alley.
We do not warn because of the infam
On Fri, Jul 24, 2015 at 5:55 PM, Manuel López-Ibáñez
wrote:
> On 24 July 2015 at 21:30, Jeff Law wrote:
>> On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
>>>
>>> On 23 July 2015 at 19:43, Jeff Law wrote:
Warning in the front-ends like this can generate false positives (such as
On 24 July 2015 at 21:30, Jeff Law wrote:
> On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
>>
>> On 23 July 2015 at 19:43, Jeff Law wrote:
>>>
>>> Warning in the front-ends like this can generate false positives (such as
>>> a
>>> NULL return in an unreachable path and miss cases where the NU
On 07/24/2015 07:45 AM, Manuel López-Ibáñez wrote:
On 23 July 2015 at 19:43, Jeff Law wrote:
Warning in the front-ends like this can generate false positives (such as a
NULL return in an unreachable path and miss cases where the NULL has to be
propagated into the return by later optimizations.
On 07/24/2015 02:06 AM, Bernhard Reutner-Fischer wrote:
Looking at the reduced testcase in that PR, I'm pretty sure its a bogus
reduction.
Yes, the original, smallish test case in comment #4 is different, AFAICS.
Agreed. I should have been a bit more explicit. The test in c#5 is not
a vali
On 23 July 2015 at 19:43, Jeff Law wrote:
> Warning in the front-ends like this can generate false positives (such as a
> NULL return in an unreachable path and miss cases where the NULL has to be
> propagated into the return by later optimizations.
False positives (for the warning as proposed ri
On July 24, 2015 7:30:03 AM GMT+02:00, Jeff Law wrote:
>On 07/23/2015 04:44 PM, Bernhard Reutner-Fischer wrote:
>> On July 23, 2015 7:43:51 PM GMT+02:00, Jeff Law
>wrote:
>>> On 07/22/2015 09:29 AM, Manuel López-Ibáñez wrote:
While looking at PR c/16351, I noticed that all tests proposed for
On 07/23/2015 04:44 PM, Bernhard Reutner-Fischer wrote:
On July 23, 2015 7:43:51 PM GMT+02:00, Jeff Law wrote:
On 07/22/2015 09:29 AM, Manuel López-Ibáñez wrote:
While looking at PR c/16351, I noticed that all tests proposed for
-Wnull-attribute
(https://gcc.gnu.org/ml/gcc-patches/2014-01/msg0
On July 23, 2015 7:43:51 PM GMT+02:00, Jeff Law wrote:
>On 07/22/2015 09:29 AM, Manuel López-Ibáñez wrote:
>> While looking at PR c/16351, I noticed that all tests proposed for
>> -Wnull-attribute
>> (https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01715.html) could be
>> warned from the FEs by simp
On 07/22/2015 09:29 AM, Manuel López-Ibáñez wrote:
While looking at PR c/16351, I noticed that all tests proposed for
-Wnull-attribute
(https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01715.html) could be
warned from the FEs by simply extending the existing Wnonnull.
Bootstrapped and regression te
While looking at PR c/16351, I noticed that all tests proposed for
-Wnull-attribute
(https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01715.html) could be
warned from the FEs by simply extending the existing Wnonnull.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/ChangeLog:
2015
18 matches
Mail list logo
