[Bug c++/82745] New: Fails to warn on narrowing conversion when using make_unique

["helge at penne dot no" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 82745
           Summary: Fails to warn on narrowing conversion when using
                    make_unique
           Product: gcc
           Version: 7.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: helge at penne dot no
  Target Milestone: ---

Created attachment 42486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42486&action=edit
Example code

I may possibly have found a bug with some serious implications for developers
wanting to write secure code.  I would expect the attached program to produce a
compiler warning about the narrowing conversion in make_unique, but it does
not.  Compiler options were "-Wall -Wextra -Wconversion -pedantic"

Removing the comment on the line doing the equivalent construction with
unique_ptr and new will produce the expected warning.

Some digging around seems to imply that this is probably not just a problem
with make_unique, but perhaps a problem with perfect forwardning
(std::forward?) in general.  The following discussion in the standards forum
might indicate a problem in the language definition itself, but I would still
expect the compiler to warn about this:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/yt3eizKwGjI

The gcc -v options says:
GNU C++14 (GCC) version 7.1.0 (x86_64-gcc710-linux-gnu)
        compiled by GNU C version 7.1.0, GMP version 6.0.0, MPFR version 3.1.1,
MPC version 1.0.1, isl version none

Warnings on narrowning conversions are quite important when writing secure
code, and this bug is therefore rather serious.

I could always refactor the code base to use my own variant of make_unique that
uses move semantics instead of perfect forwarding and gain security at the
expense of some runtime perfomance, but if perfect forwarding is the problem
then that is not going to be enough.

Or perhaps I have missed something.  In fact, I would prefer to be wrong rather
than right in this case.  If this is something that I can fix in my own code
then that is far preferable to the compiler or languge being broken.  

Best regards,
H. Penne