[Bug c/25509] can't disable __attribute__((warn_unused_result))

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[ppluzhnikov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot com

--- Comment #28 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
Google ref: b/16983603.

I wouldn't call this bug fixed.

I have just found ~30 bugs in our code, where someone wrote:

  vector<int> v;
  ...
  v.empty();   // v.clear() was intended!

No problem, I'll just add warn_unused_result to vector::empty(), right?

Well, that did expose the 30 bugs above, but unfortunately I can't do that
permanently, because it also exposed this false positive:

   assert(v.empty());

where assert in NDEBUG mode expanded into

  static_cast<void>(v.empty());

and triggered the warning :-(

P.S. Some of the bugs I found were in parts of the code imported from
open-source projects, so it's not a problem that is specific to just Google. If
the assert problem could be addressed, adding warn_unused_result to trunk
libstdc++ would benefit everyone.

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paul Pluzhnikov from comment #28)
> Well, that did expose the 30 bugs above, but unfortunately I can't do that
> permanently, because it also exposed this false positive:
> 
>    assert(v.empty());
> 
> where assert in NDEBUG mode expanded into
> 
>   static_cast<void>(v.empty());

Isn't assert in NDEBUG mode guaranteed to not evaluate its argument? The above
seems to violate that assumption.

In C++ you could do this:

template<typename T>
inline T ignore_result(T x __attribute__((unused)))
{
    return x;
}
extern int foo() __attribute__((warn_unused_result));

int main()
{
   ignore_result(foo());
   return 0;
}

Another alternative is to use #pragma GCC diagnostics push/ignored/pop. Ideally
you could encapsulate that into a macro "ignore_result", but #pragma
diagnostics does not work well in a macro definition yet (I cannot remember the
PR number for this).
>From gcc-bugs-return-458403-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 13 23:48:44 2014
Return-Path: <gcc-bugs-return-458403-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4412 invoked by alias); 13 Aug 2014 23:48:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4333 invoked by uid 48); 13 Aug 2014 23:48:39 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/25509] can't disable __attribute__((warn_unused_result))
Date: Wed, 13 Aug 2014 23:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.1.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-25509-4-HuzNuKDdiW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-25509-4@http.gcc.gnu.org/bugzilla/>
References: <bug-25509-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg00900.txt.bz2
Content-length: 617

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

--- Comment #30 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paul Pluzhnikov from comment #28)
> P.S. Some of the bugs I found were in parts of the code imported from
> open-source projects, so it's not a problem that is specific to just Google.
> If the assert problem could be addressed, adding warn_unused_result to trunk
> libstdc++ would benefit everyone.

That seems a different issue (and it will require convincing different people)
than this one. Can you open a new PR if you really think it is a good idea?
>From gcc-bugs-return-458404-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 14 00:45:53 2014
Return-Path: <gcc-bugs-return-458404-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8258 invoked by alias); 14 Aug 2014 00:45:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8203 invoked by uid 48); 14 Aug 2014 00:45:47 -0000
From: "venkataramanan.kumar at amd dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
Date: Thu, 14 Aug 2014 00:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: lto
X-Bugzilla-Keywords: build, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: venkataramanan.kumar at amd dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62077-4-zhAbSe1csq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62077-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62077-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg00901.txt.bz2
Content-length: 2163

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb077

--- Comment #30 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
(In reply to Venkataramanan from comment #29)
> Hi Richard,
>
> I tried the patch you posted last on GCC patches, on top of GCC 4.9 on
> Aarch64.
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01324.html
>
> I am still getting same number of compare errors.
>
> Now I will try adding --param ggc-min-expand\x100 --param
> ggc-min-heapsize\x131072 to stage2 and stage3 flags.

I am getting more compare errors in Aarch64 machine in this case.
aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi.o differs
aarch64-unknown-linux-gnu/libgcc/_fixxfdi_s.o differs
aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi_s.o differs
aarch64-unknown-linux-gnu/libgcc/_ctors_s.o differs
aarch64-unknown-linux-gnu/libgcc/_floatdixf.o differs
aarch64-unknown-linux-gnu/libgcc/_popcount_tab_s.o differs
aarch64-unknown-linux-gnu/libgcc/_powixf2.o differs
aarch64-unknown-linux-gnu/libgcc/unwind-sjlj.o differs
aarch64-unknown-linux-gnu/libgcc/unwind-sjlj_s.o differs
aarch64-unknown-linux-gnu/libgcc/crtendS.o differs
gcc/sdbout.o differs
gcc/c/c-lang.o differs
gcc/graphite-poly.o differs
gcc/graphite-dependences.o differs
gcc/crtend.o differs
gcc/vmsdbgout.o differs
gcc/hw-doloop.o differs
gcc/graphite-optimize-isl.o differs
gcc/version.o differs
gcc/target-globals.o differs
gcc/graphite-interchange.o differs
gcc/collect2-aix.o differs
gcc/graphite-scop-detection.o differs
gcc/loop-doloop.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/build/min-insn-modes.o differs
gcc/build/version.o differs
gcc/graphite-sese-to-poly.o differs
gcc/insn-peep.o differs
gcc/insn-enums.o differs
gcc/xcoffout.o differs
gcc/crtendS.o differs
libbacktrace/atomic.o differs
libiberty/pic/safe-ctype.o differs
libiberty/pic/getopt.o differs
libiberty/pic/obstack.o differs
libiberty/pic/fnmatch.o differs
libiberty/pic/getopt1.o differs
libiberty/safe-ctype.o differs
libiberty/getopt.o differs
libiberty/obstack.o differs
libiberty/fnmatch.o differs
libiberty/getopt1.o differs


I will try to test the patch on x86_64 machine now.

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

--- Comment #32 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Filipe Brandenburger from comment #31)
> gcc should catch up.

I thought Google employed some capable C/C++ engineers...
>From gcc-bugs-return-488706-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 08:11:33 2015
Return-Path: <gcc-bugs-return-488706-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 115256 invoked by alias); 11 Jun 2015 08:11:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 115221 invoked by uid 48); 11 Jun 2015 08:11:28 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66498] internal compiler error when compiling chrome and webkit
Date: Thu, 11 Jun 2015 08:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66498-4-VgYO9XMzmP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66498-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66498-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01038.txt.bz2
Content-length: 138

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf498

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can't reproduce.

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

--- Comment #33 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #32)
> (In reply to Filipe Brandenburger from comment #31)
> > gcc should catch up.
> 
> I thought Google employed some capable C/C++ engineers...

What I meant is that those engineers, if they exist, could help GCC "catch up"
(whatever that means)... gcc does not develop itself or by magic gnomes, you
know.
>From gcc-bugs-return-488716-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 09:01:42 2015
Return-Path: <gcc-bugs-return-488716-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 101953 invoked by alias); 11 Jun 2015 09:01:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 101888 invoked by uid 48); 11 Jun 2015 09:01:39 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/25509] can't disable __attribute__((warn_unused_result))
Date: Thu, 11 Jun 2015 09:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.1.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-25509-4-AfXhlIvN3g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-25509-4@http.gcc.gnu.org/bugzilla/>
References: <bug-25509-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01048.txt.bz2
Content-length: 837

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

--- Comment #34 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #33)
> (In reply to Manuel López-Ibáñez from comment #32)
> > (In reply to Filipe Brandenburger from comment #31)
> > > gcc should catch up.
> > 
> > I thought Google employed some capable C/C++ engineers...
> 
> What I meant is that those engineers, if they exist, could help GCC "catch
> up" (whatever that means)... gcc does not develop itself or by magic gnomes,
> you know.

Hum, that still sounds worse than it sounded in my mind. Sorry, I'm dense this
morning :) 

Just: help us, we love you, let's make the world a better place together :)

(deleting comments in bugzilla would be helpful sometimes).
>From gcc-bugs-return-488717-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 09:16:41 2015
Return-Path: <gcc-bugs-return-488717-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 64697 invoked by alias); 11 Jun 2015 09:16:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 64673 invoked by uid 48); 11 Jun 2015 09:16:37 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66502] New: SCCVN can't handle PHIs optimistically optimally
Date: Thu, 11 Jun 2015 09:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66502-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01049.txt.bz2
Content-length: 1738

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf502

            Bug ID: 66502
           Summary: SCCVN can't handle PHIs optimistically optimally
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Currently FRE doesn't eliminate redundant IVs like in

int x[1024];
int foo (int a, int s, unsigned int k)
{
  int i = a, j = a;
  int sum = 0;
  do
    {
      sum += x[i];
      sum += x[j];
      i += s;
      j += s;
    }
  while (k--);
  return sum;
}

but it handles the following instead

int foo (int a, int s, unsigned int k)
{
  int i = a, j = a;
  do
    {
      i += s;
      j += j;
      j -= a;
    }
  while (k--);
  return j+i;
}

the difference is whether a PHI node with all but one non-VN_TOP argument
is optimistically value-numbered to that argument or to another PHI node
in the same BB with the same argument in its position (if existing).

If it were not SCCVN then if both PHIs are value-numbered together
value-numbering optimistically to the non-VN_TOP argument could catch
both cases, but only if we allow a questionable lattice-transition
from a final value (the non-VN_TOP argument) to a still optimistic
one (the other PHI nodes result).  That's of course exactly a transition
that we want to avoid because of lattice oscillations (well, if we
allow it in this one direction only and not back it might be fine).

To "fix" SCCVN we'd need to put any such PHI node candidates into the
same SCC and allow that lattice transition.

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[filbranden at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

--- Comment #35 from Filipe Brandenburger <filbranden at google dot com> ---
(In reply to Manuel López-Ibáñez from comments)

Don't worry, I got what you mean...

Though I don't think coming up with code to fix it is the issue here, in
comment #10 a patch was provided (which admittedly I haven't tested personally)
to turn a void cast into a temporary assignment (which I believe would have
been optimized out later in the pipeline) so I wonder why that hasn't really
gone forward...

Cheers,
Filipe
>From gcc-bugs-return-488760-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 13:38:20 2015
Return-Path: <gcc-bugs-return-488760-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 83967 invoked by alias); 11 Jun 2015 13:38:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 83251 invoked by uid 48); 11 Jun 2015 13:38:13 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/66505] -Wno-error=pedantic does not reverse -Werror -Wpedantic
Date: Thu, 11 Jun 2015 13:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: diagnostic, easyhack
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-66505-4-VuYqrwCyLE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66505-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66505-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01092.txt.bz2
Content-length: 1770

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66505

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, easyhack
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-11
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to chrysn from comment #0)
> which indicates that no special-purpose warning exists for the behavior. it
> has been suggested by redi on irc that a `-Wbinary-constants` should be
> introduced (along with other specific labels like imaginary-constants) to
> combat this, and that the relevant code is around libcpp/expr.c:697.

You may do this or you may simply use cpp_pedwarning_with_line (pfile,
CPP_W_PEDANTIC,...). 

Every warning that is conditional on an option should use the appropriate
CPP_W_* flag corresponding to that option. Thus, every warning that is
conditional on CPP_PEDANTIC (pfile) should use CPP_W_PEDANTIC. 

The guidelines available here https://gcc.gnu.org/wiki/DiagnosticsGuidelines
for pedwarn/OPT_Wpedantic also apply to libcpp, but using
cpp_pedwarning/CPP_W_PEDANTIC. In particular, you may use cpp_pedwarning
without CPP_W_PEDANTIC, but you may not use CPP_W_PEDANTIC without
cpp_pedwarning and you may not use CPP_PEDANTIC (pfile) without CPP_W_PEDANTIC.

I see many cases in libcpp that do not follow these rules and they are likely
suffering from the same problem.
>From gcc-bugs-return-488759-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 13:38:12 2015
Return-Path: <gcc-bugs-return-488759-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 83182 invoked by alias); 11 Jun 2015 13:38:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 82982 invoked by uid 48); 11 Jun 2015 13:38:08 -0000
From: "howarth.at.gcc at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32
Date: Thu, 11 Jun 2015 13:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth.at.gcc at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66509-4-p6xOuNIAQe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66509-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66509-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01091.txt.bz2
Content-length: 323

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf509

--- Comment #6 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
A check of a recent build gcc trunk against the GNU assembler from Xcode 6.2
shows the same...

gcc_cv_as_ix86_fildq=no
gcc_cv_as_ix86_filds=no

as the build against Xcode 7's clang-based assembler.

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[ericb at gcc dot gnu dot org]

------- Comment #27 from ericb at gcc dot gnu dot org  2010-08-30 21:09 -------
See:
http://sourceware.org/bugzilla/show_bug.cgi?id=11959
for the glibc side of this bug (namely, fwrite() shouldn't be tagged wur).


-- 

ericb at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ericb at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2010-08-30 15:00 -------
(In reply to comment #25)
> > > gcc currently has no middle option.
> > 
> > Also this attribute is not on by default in glibc so you are asking to  
> > turn on the style based warnings.
> 
> (In reply to comment #24)
> > FIXED in GCC 4.5
> 
> After having waded through this long series of comments, I am left
> wondering just how this got addressed.  Does  --no-warn-unused-result
> mean that fwrite() usage may be cast to void, or that it may be
> treated as if it were a void procedure?  I think it is very reasonable
> to warn if a returned result is not handled.  Casting to void is
> a valid way to handle the result.  I would like warnings when returned
> results are not handled.  What does the fix do?

It simply adds -W[no-]unused-result and completely enables/disables all
unused result warnings.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[bkorb at gnu dot org]

------- Comment #25 from bkorb at gnu dot org  2010-08-30 14:42 -------
> > gcc currently has no middle option.
> 
> Also this attribute is not on by default in glibc so you are asking to  
> turn on the style based warnings.

(In reply to comment #24)
> FIXED in GCC 4.5

After having waded through this long series of comments, I am left
wondering just how this got addressed.  Does  --no-warn-unused-result
mean that fwrite() usage may be cast to void, or that it may be
treated as if it were a void procedure?  I think it is very reasonable
to warn if a returned result is not handled.  Casting to void is
a valid way to handle the result.  I would like warnings when returned
results are not handled.  What does the fix do?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[manu at gcc dot gnu dot org]

------- Comment #24 from manu at gcc dot gnu dot org  2009-07-10 07:29 -------
FIXED in GCC 4.5


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[manu at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]



------- Comment #23 from manu at gcc dot gnu dot org  2009-07-10 07:27 -------
Subject: Bug 25509

Author: manu
Date: Fri Jul 10 07:27:32 2009
New Revision: 149458

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149458
Log:
2009-07-10  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        PR 25509
        PR 40614
        * c.opt (Wunused-result): New.
        * doc/invoke.texi: Document it.
        * c-common.c (c_warn_unused_result): Use it.
testsuite/
        * g++.dg/warn/unused-result1-Werror.c: New.

Added:
    trunk/gcc/testsuite/g++.dg/warn/unused-result1-Werror.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-common.c
    trunk/gcc/c.opt
    trunk/gcc/doc/invoke.texi
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[fche at redhat dot com]

------- Comment #22 from fche at redhat dot com  2008-11-22 18:35 -------
(In reply to comment #21)
> Sent from my iPhone

Good to know.

> > GCC should not be trying to micromanage coding styles - either of  
> > the rest of gnu software or anywhere else, but at least until you
> > clean up every bit of your own code, there should be a way of disabling
> > the warning clutter.
> 
> Why GCC is not micromanaging at all, it just allows the developer of  
> the API to have the warning.  So your complaints here are useless.

What the poster seems to be requesting is another -Wno-unused-FOO flag
to override this warning.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[pinskia at gmail dot com]

------- Comment #21 from pinskia at gmail dot com  2008-11-22 17:17 -------
Subject: Re:  can't disable __attribute__((warn_unused_result))



Sent from my iPhone

On Nov 22, 2008, at 7:42 AM, "thomas at mich dot com" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #20 from thomas at mich dot com  2008-11-22 15:42  
> -------
> There minimally needs to be a way of turning this warning off in GCC.
>
> GCC should not be trying to micromanage coding styles - either of  
> the rest of
> gnu software or anywhere else, but at least until you clean up every  
> bit of
> your own code, there should be a way of disabling the warning clutter.

Why GCC is not micromanaging at all, it just allows the developer of  
the API to have the warning.  So your complaints here are useless.

>
>
> HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL.
>
> I can't even find errors in the pages bilge that now spews out from  
> a normal
> compile.  It might be and probably is appropriate with -Wall turned  
> on.
>
> And I really would like to be able to treat warnings as errors when  
> they are
> legitimate warnings.
>
> For now, I've hexedited cc1 to change the string so it won't be  
> found and have
> to add -Wno-attributes so I don't get errors from things I might need.
>
> I'm getting it even with -Wall turned off (version 4.3.2).  And I  
> still should
> be able to disable it.
>
> Somehow GCC and gnu thinks
>
>    int dummy93857 = fwrite( buf, 1, 1, fp );
>
> is so far superior code to just
>
>    fwrite( buf, 1, 1, fp );
>
> that it now must enforce it on every possible line.

It is not GCC which thinks that, it is the providers of your headers  
for fwriye that thinks that.

>
>
> Sometimes ignoring returns is the right (or better) thing to do  
> instead of
> cluttering up the code.  Not every line of code is critical kernel  
> or system
> code that can introduce security holes.  Not every call needs to  
> have its exact
> behavior on the particular instance carefully monitored.

Again we just provide the author of the Api to say that.

>
>
> The author of the libraries can often make a bad choice.

Yes and you should complain to them instead of us then.

> And there are
> hundreds of instances - maybe 99% of them are good, but the bad ones  
> on common
> functions are causing a great deal of noise.  And there is not a
> pedantic_warn_unused_result (with a -Wunused-result which would  
> promote it),
> which would be perfect for the instances noted here and more easily  
> made.  And
> perhaps even an error_unused_result.
>
> I think it would be easy to argue for the large bodies of code that  
> certain
> functions have return values that are conventionally ignored so  
> should only
> warn at a higher level of checking than ordinary warnings.  Right  
> now I have to
> argue each individual case with the only options to keep it (and the  
> pages of
> new warnings) or remove it (and in the few cases where it might be  
> critical be
> silent).
>
> gcc currently has no middle option.

Also this attribute is not on by default in glibc so you are asking to  
turn on the style based warnings.

>
>
> Sometimes return values are at a point where you can't do anything  
> anyway like
> the exit example.  Somehow, if a printf, or an equivalent fwrite of  
> a formatted
> string to stdout or stderr fails, what do you do?  Errors have both  
> probability
> and criticality.  And there are a lot of highly improbable cases,  
> and lots of
> non-critical sections.  If my CPU is melting down or my memory  
> giving errors, I
> have worse problems.  If the number of parameters doesn't match a  
> function
> declaration, it is likely an error that will cause things to fail  
> 90% of the
> time.   99.99% of the time, f//read/write will return the expected  
> value.  If
> fclose fails, what do you do?  And fwrite won't return the error,  
> fflush might
> (but if it doesn't do a sync(), and writes are cached to a failing  
> disk...).
>
> Perhaps it is because we don't have a finer gradation (an INFO or MAY
> equivalent to the SHOULD/WARNING, MUST/ERROR).  The lack of checking  
> a return,
> at least in the cases where the functions are mainly the side-effect  
> (and if
> fwrite fails, perhaps there should be a signal or exception, and not  
> depend on
> the return code if it is so critical) doesn't reach the threshold of a
> PERMANENTLY ENABLED warning.  It does reach the threshold of the  
> things I
> usually check with -pedantic.  Like signed-unsigned mismatches.   
> Subtle printf
> format errors.  In my later QC checks I do turn everything on and  
> verify every
> line of code.
>
> I would work on adding a pedantic_* (and maybe error_*) set of  
> attributes, but
> until then, leave the choice to the author of the program.  THIS  
> WARNING IS A
> *GOOD* THING, but it doesn't apply to every program or every  
> function, or every
> use of that function.  Many functions are used both in critical and  
> noncritical
> forms, and there are a lot of existing programs that instead of  
> being clear are
> now cluttered.
>
> One of the reasons I don't normally use C++ is the stupidity where I  
> am forced
> to lower the quality of my code because of what it enforces or  
> doesn't enforce
> so instead of a concise function, it will only compile a bloated  
> blob.  This
> warning is something like that.
>
> I write code in C.  I know better what I'm writing that you or the  
> compiler
> does.  I know when errors are critical and or likely at a specific  
> point in my
> code.  And all I want is the choice to either have this (or any  
> other common
> but not critical warning) enabled or disabled.

Someone turned these attributes in your glibc to be on by default so  
again it is not our fault.

>
>
>
> -- 
>
> thomas at mich dot com changed:
>
>           What    |Removed                     |Added
> --- 
> --- 
> ----------------------------------------------------------------------
>                 CC|                            |thomas at mich dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

Re: [Bug c/25509] can't disable __attribute__((warn_unused_result))

[Andrew Thomas Pinski]

Sent from my iPhone

On Nov 22, 2008, at 7:42 AM, "thomas at mich dot com" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #20 from thomas at mich dot com  2008-11-22 15:42  
> -------
> There minimally needs to be a way of turning this warning off in GCC.
>
> GCC should not be trying to micromanage coding styles - either of  
> the rest of
> gnu software or anywhere else, but at least until you clean up every  
> bit of
> your own code, there should be a way of disabling the warning clutter.

Why GCC is not micromanaging at all, it just allows the developer of  
the API to have the warning.  So your complaints here are useless.

>
>
> HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL.
>
> I can't even find errors in the pages bilge that now spews out from  
> a normal
> compile.  It might be and probably is appropriate with -Wall turned  
> on.
>
> And I really would like to be able to treat warnings as errors when  
> they are
> legitimate warnings.
>
> For now, I've hexedited cc1 to change the string so it won't be  
> found and have
> to add -Wno-attributes so I don't get errors from things I might need.
>
> I'm getting it even with -Wall turned off (version 4.3.2).  And I  
> still should
> be able to disable it.
>
> Somehow GCC and gnu thinks
>
>    int dummy93857 = fwrite( buf, 1, 1, fp );
>
> is so far superior code to just
>
>    fwrite( buf, 1, 1, fp );
>
> that it now must enforce it on every possible line.

It is not GCC which thinks that, it is the providers of your headers  
for fwriye that thinks that.

>
>
> Sometimes ignoring returns is the right (or better) thing to do  
> instead of
> cluttering up the code.  Not every line of code is critical kernel  
> or system
> code that can introduce security holes.  Not every call needs to  
> have its exact
> behavior on the particular instance carefully monitored.

Again we just provide the author of the Api to say that.

>
>
> The author of the libraries can often make a bad choice.

Yes and you should complain to them instead of us then.

> And there are
> hundreds of instances - maybe 99% of them are good, but the bad ones  
> on common
> functions are causing a great deal of noise.  And there is not a
> pedantic_warn_unused_result (with a -Wunused-result which would  
> promote it),
> which would be perfect for the instances noted here and more easily  
> made.  And
> perhaps even an error_unused_result.
>
> I think it would be easy to argue for the large bodies of code that  
> certain
> functions have return values that are conventionally ignored so  
> should only
> warn at a higher level of checking than ordinary warnings.  Right  
> now I have to
> argue each individual case with the only options to keep it (and the  
> pages of
> new warnings) or remove it (and in the few cases where it might be  
> critical be
> silent).
>
> gcc currently has no middle option.

Also this attribute is not on by default in glibc so you are asking to  
turn on the style based warnings.

>
>
> Sometimes return values are at a point where you can't do anything  
> anyway like
> the exit example.  Somehow, if a printf, or an equivalent fwrite of  
> a formatted
> string to stdout or stderr fails, what do you do?  Errors have both  
> probability
> and criticality.  And there are a lot of highly improbable cases,  
> and lots of
> non-critical sections.  If my CPU is melting down or my memory  
> giving errors, I
> have worse problems.  If the number of parameters doesn't match a  
> function
> declaration, it is likely an error that will cause things to fail  
> 90% of the
> time.   99.99% of the time, f//read/write will return the expected  
> value.  If
> fclose fails, what do you do?  And fwrite won't return the error,  
> fflush might
> (but if it doesn't do a sync(), and writes are cached to a failing  
> disk...).
>
> Perhaps it is because we don't have a finer gradation (an INFO or MAY
> equivalent to the SHOULD/WARNING, MUST/ERROR).  The lack of checking  
> a return,
> at least in the cases where the functions are mainly the side-effect  
> (and if
> fwrite fails, perhaps there should be a signal or exception, and not  
> depend on
> the return code if it is so critical) doesn't reach the threshold of a
> PERMANENTLY ENABLED warning.  It does reach the threshold of the  
> things I
> usually check with -pedantic.  Like signed-unsigned mismatches.   
> Subtle printf
> format errors.  In my later QC checks I do turn everything on and  
> verify every
> line of code.
>
> I would work on adding a pedantic_* (and maybe error_*) set of  
> attributes, but
> until then, leave the choice to the author of the program.  THIS  
> WARNING IS A
> *GOOD* THING, but it doesn't apply to every program or every  
> function, or every
> use of that function.  Many functions are used both in critical and  
> noncritical
> forms, and there are a lot of existing programs that instead of  
> being clear are
> now cluttered.
>
> One of the reasons I don't normally use C++ is the stupidity where I  
> am forced
> to lower the quality of my code because of what it enforces or  
> doesn't enforce
> so instead of a concise function, it will only compile a bloated  
> blob.  This
> warning is something like that.
>
> I write code in C.  I know better what I'm writing that you or the  
> compiler
> does.  I know when errors are critical and or likely at a specific  
> point in my
> code.  And all I want is the choice to either have this (or any  
> other common
> but not critical warning) enabled or disabled.

Someone turned these attributes in your glibc to be on by default so  
again it is not our fault.

>
>
>
> -- 
>
> thomas at mich dot com changed:
>
>           What    |Removed                     |Added
> --- 
> --- 
> ----------------------------------------------------------------------
>                 CC|                            |thomas at mich dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
>

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[thomas at mich dot com]

------- Comment #20 from thomas at mich dot com  2008-11-22 15:42 -------
There minimally needs to be a way of turning this warning off in GCC.

GCC should not be trying to micromanage coding styles - either of the rest of
gnu software or anywhere else, but at least until you clean up every bit of
your own code, there should be a way of disabling the warning clutter.

HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL.

I can't even find errors in the pages bilge that now spews out from a normal
compile.  It might be and probably is appropriate with -Wall turned on.

And I really would like to be able to treat warnings as errors when they are
legitimate warnings.

For now, I've hexedited cc1 to change the string so it won't be found and have
to add -Wno-attributes so I don't get errors from things I might need.

I'm getting it even with -Wall turned off (version 4.3.2).  And I still should
be able to disable it.

Somehow GCC and gnu thinks

    int dummy93857 = fwrite( buf, 1, 1, fp );

is so far superior code to just

    fwrite( buf, 1, 1, fp );

that it now must enforce it on every possible line.

Sometimes ignoring returns is the right (or better) thing to do instead of
cluttering up the code.  Not every line of code is critical kernel or system
code that can introduce security holes.  Not every call needs to have its exact
behavior on the particular instance carefully monitored.

The author of the libraries can often make a bad choice.  And there are
hundreds of instances - maybe 99% of them are good, but the bad ones on common
functions are causing a great deal of noise.  And there is not a
pedantic_warn_unused_result (with a -Wunused-result which would promote it),
which would be perfect for the instances noted here and more easily made.  And
perhaps even an error_unused_result.

I think it would be easy to argue for the large bodies of code that certain
functions have return values that are conventionally ignored so should only
warn at a higher level of checking than ordinary warnings.  Right now I have to
argue each individual case with the only options to keep it (and the pages of
new warnings) or remove it (and in the few cases where it might be critical be
silent).

gcc currently has no middle option.

Sometimes return values are at a point where you can't do anything anyway like
the exit example.  Somehow, if a printf, or an equivalent fwrite of a formatted
string to stdout or stderr fails, what do you do?  Errors have both probability
and criticality.  And there are a lot of highly improbable cases, and lots of
non-critical sections.  If my CPU is melting down or my memory giving errors, I
have worse problems.  If the number of parameters doesn't match a function
declaration, it is likely an error that will cause things to fail 90% of the
time.   99.99% of the time, f//read/write will return the expected value.  If
fclose fails, what do you do?  And fwrite won't return the error, fflush might
(but if it doesn't do a sync(), and writes are cached to a failing disk...).

Perhaps it is because we don't have a finer gradation (an INFO or MAY
equivalent to the SHOULD/WARNING, MUST/ERROR).  The lack of checking a return,
at least in the cases where the functions are mainly the side-effect (and if
fwrite fails, perhaps there should be a signal or exception, and not depend on
the return code if it is so critical) doesn't reach the threshold of a
PERMANENTLY ENABLED warning.  It does reach the threshold of the things I
usually check with -pedantic.  Like signed-unsigned mismatches.  Subtle printf
format errors.  In my later QC checks I do turn everything on and verify every
line of code.

I would work on adding a pedantic_* (and maybe error_*) set of attributes, but
until then, leave the choice to the author of the program.  THIS WARNING IS A
*GOOD* THING, but it doesn't apply to every program or every function, or every
use of that function.  Many functions are used both in critical and noncritical
forms, and there are a lot of existing programs that instead of being clear are
now cluttered.

One of the reasons I don't normally use C++ is the stupidity where I am forced
to lower the quality of my code because of what it enforces or doesn't enforce
so instead of a concise function, it will only compile a bloated blob.  This
warning is something like that.

I write code in C.  I know better what I'm writing that you or the compiler
does.  I know when errors are critical and or likely at a specific point in my
code.  And all I want is the choice to either have this (or any other common
but not critical warning) enabled or disabled.


-- 

thomas at mich dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas at mich dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[joseph at codesourcery dot com]

------- Comment #19 from joseph at codesourcery dot com  2008-10-17 16:55 -------
Subject: Re:  can't disable __attribute__((warn_unused_result))

On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:

> > In the case of fwrite, for example, the only obvious case where checking 
> > would be useless is if you already are writing an error message before 
> > exiting with error status and so an error writing the error message could 
> > not usefully be reported anywhere and wouldn't lead to a change of exit 
> > status.
> 
> Not really.  The return code of fwrite is not only useless: worse, it gives a
> *false* sense of security.  Stuff can stay in the buffers, only to give errors
> when you do an fflush or an fclose, which do not have the attribute in glibc
> (as of July 2007).
> 
> It is much better to do
> 
>   fwrite (buf, m, n, f);
>   if (fflush (f) != EOF)
>     perror ("write");
>   if (fclose (f) != EOF)
>     perror ("close");
> 
> than checking the return code of fwrite, and that's more or less what coreutils
> does.  Anyway this is OT, because this would be a glibc bug.

Yes, I previously noted this as an alternative valid style in comment#6. 
glibc has chosen to make one style much easier than the other and that's a 
matter for the glibc maintainers, not for GCC to work around glibc.

> Back to the GCC point-of-view, the situation is similar to setting a
> format(printf) attribute on a printf-like function that also has some
> extension.  It would work for some calls, maybe most, but not for all of them. 
> So the solution would be to use -Wno-format, either directly or via #pragma GCC
> diagnostic.  This warning is not mandated by any standard, after all.

Yes, all warnings in GCC should have options to control them as a general 
principle of warning control, but some (such as in this case) would be 
there more for a general principle than because they should actually be 
used.  GNU software should not be working around other GNU software; if 
some GNU software has a problem with attributes used in glibc then in the 
first instance the maintainers of both packages should try to ensure that 
glibc's headers and the other software's coding style work well together.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[bonzini at gnu dot org]

------- Comment #18 from bonzini at gnu dot org  2008-10-17 15:48 -------
> In the case of fwrite, for example, the only obvious case where checking 
> would be useless is if you already are writing an error message before 
> exiting with error status and so an error writing the error message could 
> not usefully be reported anywhere and wouldn't lead to a change of exit 
> status.

Not really.  The return code of fwrite is not only useless: worse, it gives a
*false* sense of security.  Stuff can stay in the buffers, only to give errors
when you do an fflush or an fclose, which do not have the attribute in glibc
(as of July 2007).

It is much better to do

  fwrite (buf, m, n, f);
  if (fflush (f) != EOF)
    perror ("write");
  if (fclose (f) != EOF)
    perror ("close");

than checking the return code of fwrite, and that's more or less what coreutils
does.  Anyway this is OT, because this would be a glibc bug.

Back to the GCC point-of-view, the situation is similar to setting a
format(printf) attribute on a printf-like function that also has some
extension.  It would work for some calls, maybe most, but not for all of them. 
So the solution would be to use -Wno-format, either directly or via #pragma GCC
diagnostic.  This warning is not mandated by any standard, after all.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[joseph at codesourcery dot com]

------- Comment #17 from joseph at codesourcery dot com  2008-10-17 15:31 -------
Subject: Re:  can't disable __attribute__((warn_unused_result))

On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:

> It does not matter if it is a "security" issue; if void-ifying is not an
> acceptable workaround, there must be at the very least a Wno-* option to
> disable it.

The workaround is to change the header declaring the function with the 
attribute.  There isn't an option to disable the error for calling a 
prototyped function with the wrong number of arguments either; if you feel 
you know better than the library author how many arguments the function 
should take for a particular use case in the program, you'll need to 
change the library or conform to the API it specifies.  This attribute is 
giving further information about the API for a function.

In the case of fwrite, for example, the only obvious case where checking 
would be useless is if you already are writing an error message before 
exiting with error status and so an error writing the error message could 
not usefully be reported anywhere and wouldn't lead to a change of exit 
status.  This suggests you might have an xfwrite function that looks at 
the return value and acts on it unless a static flag is set to say the 
program is in the process of exiting with an error.  Coding in the style 
suggested by the library API should be easier than trying to work around 
the API to code in another style.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[bonzini at gnu dot org]

------- Comment #16 from bonzini at gnu dot org  2008-10-17 11:40 -------
It does not matter if it is a "security" issue; if void-ifying is not an
acceptable workaround, there must be at the very least a Wno-* option to
disable it.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |
            Summary|can't voidify               |can't disable
                   |__attribute__((warn_unused_r|__attribute__((warn_unused_r
                   |esult))                     |esult))


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509