[Bug c++/71035] New: GNU does not give error on declaration of non literal type in template function

[Judy.Ward at intel dot com]

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

Bug ID: 71035
   Summary: GNU does not give error on declaration of non literal
type in template function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Judy.Ward at intel dot com
  Target Milestone: ---

Both EDG and Clang give an error on the code below.

GNU only gives an error if call() is not a template function (see -DERROR
below) or if call() is used in a way that requires it to be constexpr (i.e. in
a static_assert).

I think this should be an error.

struct C
{
   C(); // constructor is not declared constexpr
};

#ifdef ERROR
#else
template 
#endif
constexpr void call()
{
   C c;
}

int main() {
#ifdef ERROR
   call();
#else
   call();
#endif
   return 0;
}

[Bug c++/71035] GNU does not give error on declaration of non literal type in template function

[Judy.Ward at intel dot com]

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

--- Comment #2 from Judy Ward  ---
Yes I have a beta copy of EDG 
4.11 which has relaxed constexpr and they give an error. Unfortunately some
Boost code (I think inadvertently) relies on not giving a diagnostic.

Yes I see your point that this is really a QOI issue but GNU does seem
inconsistent and EDG will have to emulate that inconsistency.

Thanks
Judy

> On May 9, 2016, at 7:38 PM, msebor at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71035
> 
> Martin Sebor  changed:
> 
>   What|Removed |Added
> 
>   Keywords||accepts-invalid
> Status|UNCONFIRMED |NEW
>   Last reconfirmed||2016-05-09
> CC||msebor at gcc dot gnu.org
> Ever confirmed|0   |1
>  Known to fail||4.9.3, 5.3.0, 6.1.0
>   Severity|normal  |enhancement
> 
> --- Comment #1 from Martin Sebor  ---
> Hi Judy!
> 
> I'll take a stab at this -- let me know if I missed something.  I agree that
> similarly to the non-template case, (in the absence of a valid explicit
> specialization) diagnosing the constexpr function template below would be
> useful, even though in p5 and p6 of [dcl.constexpr], the standard leaves both
> cases as a matter of QoI:
> 
> -6-  If the instantiated template specialization of a constexpr function
> template o member function of a class template would fail to satisfy the
> requirements for a constexpr function or constexpr constructor, that
> specialization is still a constexpr function or constexpr constructor, even
> though a call to such a function cannot appear in a constant expression.  If 
> no
> specialization of the template would satisfy the requirements for a constexpr
> function or constexpr constructor when considered as a non-template function 
> or
> constructor, the template is ill-formed; no diagnostic required.
> 
> (I read the last sentence as referring to implicit specializations of the
> template definition, not explicit ones with valid definitions.)
> 
> Thus, I'm inclined to view this bug not as a defect but an enhancement 
> request.
> Let me know if you disagree.
> 
> Clang is more strict than GCC here by issuing the optional diagnostic.
> 
> My copy of EDG (version 4.10) rejects the program because it doesn't fully
> implement the C++ 14 rules: a) it doesn't recognize void as a literal type, 
> and
> b) it doesn't allow statements in constexpr functions.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/81950] New: _GLIBCXX17 macro not used consistently

[Judy.Ward at intel dot com]

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

Bug ID: 81950
   Summary: _GLIBCXX17 macro not used consistently
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Judy.Ward at intel dot com
  Target Milestone: ---

The macro _GLIBCXX17_INLINE is used in most places in the headers to represent
the need for the c++17 inline variable feature. This makes it useful to
compilers (like the Intel compiler) which does not yet have support for this
feature.

However there is one place where this macro is not used - line 366 of utility,
i.e.:
   inline constexpr in_place_t in_place{};

should be:

  _GLIBCXX17 constexpr in_place_t in_place{};

Please fix.

thanks

[Bug libstdc++/81950] _GLIBCXX17_INLINEmacro not used consistently

[Judy.Ward at intel dot com]

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

Judy Ward  changed:

   What|Removed |Added

Summary|_GLIBCXX17 macro not used   |_GLIBCXX17_INLINEmacro not
   |consistently|used consistently

--- Comment #1 from Judy Ward  ---

In the comment above I meant to say the line should be changed to:

_GLIBCXX17_INLINE constexpr in_place_t in_place{};