On 02/21/2018 06:03 PM, Martin Sebor wrote:
On 02/13/2018 11:33 AM, Jason Merrill wrote:
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor <mse...@gmail.com> wrote:
On 02/13/2018 07:47 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor <mse...@gmail.com> wrote:
I really don't think it's helpful to try to force noreturn
to match between the primary and its specializations.
I continue to disagree.
Can you explain what use case you are concerned about that isn't
already handled by the warning about noreturn function returning?
A specialization that forgot [[noreturn]] and therefore doesn't get
the desired warning.
For reference, the cases I consider important are:
1) "Unimplemented" primary template declared noreturn that throws
or exits but whose specializations return a useful value and
make use of attribute malloc (or one of the other blacklisted
attributes).
2) The converse of (1). A primary that returns a useful malloc
like value and some of whose specializations are not/cannot
be meaningfully implemented and are declared noreturn.
Right, but I still disagree with this use of noreturn, and therefore
don't consider these cases important.
Defining template specializations that differ from the primary
template in their implementation is idiomatic (analogous to
defining overloads or overridden virtual functions).
In any event, I am mainly interested in fixing the two bugs
(one a P1 regression). If you consider changing the warning
aspect of the patch a condition of accepting the fix please let
me know. Removing the noreturn keyword from the whitelist is
trivial.
Please do.
Attached is an updated patch with this change and with
the TREE_HAS_VOLATILE bit split up between types and functions.
I've also removed warn_unused_result from the blacklist (see
below).
Bootstrapped on x864_64, regression test is in progress.
Martin
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
Hmm, that's odd. Why is that?
It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below. Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.
template <class T>
int __attribute__ ((warn_unused_result)) f (T) { return 0; }
template <>
int __attribute__ ((noreturn)) f<int> (int) { throw 0; }
void fi () { f (0); }
I continue to disagree with this use of attribute noreturn.
+ /* Merge the function-has-side-effects bit. */
+ if (TREE_THIS_VOLATILE (newdecl))
+ TREE_THIS_VOLATILE (olddecl) = 1;
+
+ if (merge_attr)
TREE_THIS_VOLATILE means attribute noreturn, not whether the function
has side-effects; it should be handled in the blocks controlled by
merge_attr.
Jason
