[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Some remarks before the discussion gets out of hand.

Neither Andrew nor me nor other people that may comment here have the power to
approve or reject this change. The people you need to convince are the C/C++ FE
maintainers listed in the MAINTAINERS file. Some of them are also GNU libc
maintainers, thus actual users of the _wur attribute. We are just trying to
make you understand the context in which the decision *made by others* has been
made.

> Casting to void is nowadays the de facto standard to say "I really know what
> I'm doing and I don't care about the return value *here*".  This is way
> better then letting each project invent their all workaround macros and even
> risk doing the wrong thing like the assert you pointed out as wrong.

This cannot be true, because the most heavy users of _wur are the kernel and
glibc, and the de-facto standard to compile those is GCC. 

How can "(void) foo(x)" be clearer than "ignore_unused_result(foo(x))" ?

Perhaps you could ask GNU libc to provide such non-standard macro
"ignore_unused_result" to avoid every project inventing their own.

Instead of '(void)', a patch that provides a __no_warn__ keyword as a
short-hand might be more acceptable (again, you don't have to convince us, just
the FE maintainers).

> So maybe after 10 years it's time to revisit that decision?  It's not that
> the behavior of when warnings are emitted are really set in stone and never
> changed. It pretty much did all this time and we kept adapting to it.

That is not so true, believe me. As someone that has been contributing to GCC
diagnostics for the last 10 years, changing GCC diagnostics ALWAYS breaks
someone's setup and they will be unhappy about it (https://xkcd.com/1172/).

That said, the best strategy to change the defaults is not to argue here in
this PR. The best strategy would be to collect the opinion from the most heavy
users of _wur (that is, GNU libc and the kernel maintainers, not their users
nor random people in their mailing lists), present a patch and argue
convincingly to the FE maintainers that this should change (not because Clang
is using it, but because the people using GCC want it).

> The gcc vs clang vs linters debate and who invented the attribute don't
> belong to this discussion. It's better to discuss why we can't let the
> attribute be actually useful by letting the users to turn it off when they
> know what they are doing.

That way of arguing is self-defeating, I'm sorry to say. The attribute is
actually useful because people are using it, otherwise, you would not even have
noticed that it exists.
>From gcc-bugs-return-488713-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 08:49:39 2015
Return-Path: <gcc-bugs-return-488713-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 86750 invoked by alias); 11 Jun 2015 08:49:38 -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 86696 invoked by uid 48); 11 Jun 2015 08:49:33 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
Date: Thu, 11 Jun 2015 08:49: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
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: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66448-4-b1R9jks1vI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66448-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/msg01045.txt.bz2
Content-length: 1067

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

--- Comment #19 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to Iain Sandoe from comment #18)
> > Could you test it properly on darwin?
>
> $ grep -rH "invalid DW" gcc/testsuite |wc -l
>       0

Confirmed on x86_64-apple-darwin14 with
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto. Thanks.

> OK - so now I have one remaining problem.  The change in my intial patch to
> make the creation of the "extern int __CFConstantStringClassReference" lazily,
> regresses obj-c++ (and, yes, I do care - it's needed to build some interesting
> projects).

Confirmed.

> (we need to move forward to unbreak Darwin bootstrap, so that we don't get
> behind on catching other things - so I'd be inclined to the original patch as
> band-aid, in the interim, if all elase fails)

IMO the priority is to fix the bootstrap and test suite failures. Once this is
done, it will be time to file PR(s) for the remaining issue(s).

Note that pr65809 has been fixed between r224139 (FAIL) and r224288.