This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/58884] OPTIONAL warning when a temprary value is created and not used.


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

--- Comment #4 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
I think there is a misunderstanding here...

These patches, when I submit them, will add a new warning option.  It is not
appropriate to add this to the normal "unused-value" warning because the
situation being diagnosed has a side effect that is important.  In fact you do
not want to see this warning in almost all circumstances.  It becomes important
only when enforcing -very- pedantic stylistic rules and when abusing the
definition of the prefix and postfix operators in C++.  I repeat -- this is a
warning option you do -not- want to turn on under normal circumstances.  It is
also inappropriate to conflate this diagnostic with the usual 'unused value'
diagnostic; they are -not- equivalent.  On the other hand, under rare
circumstances, this option could provide vital information.

The patches, again when submitted, document the problem in several places.  The
most important is in the gimplify module where the postix operator is converted
to a prefix operator under certain specific conditions.  This transformation is
-not- under the control of any optimization option; it is -always- done. 
Situations where you could change this so that you -can- control this
optimization, which I am -not- recommending, need to be identified first and
would stress the optimization system in ways it has not been stressed before. 
The patches, when submitted, would add that identification capability.  Before
actually changing the code generator, there should be an investigation of what
impact the change would have.  These patches, when submitted, would provide
that information.  All the other places where this situation can be identified
simply ignore the problem.  Part of the patch set, when submitted, will include
adding diagnostics in those places.

That brings us back to comment 2.  This is a new option and it adds at least
one and possibly more than one diagnostic messages that will need translation. 
While I can figure out what the English text of these messages should be, I am
aware that changes to the message translation infrastructure should be made
when the new messages are added.  I am -not- conversant with that procedure.  I
am looking for directions on how to add new messages into the translation
infrastructure.  I want to provide the information needed to start the
translation process as part of the patch submission.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]