[Bug c++/36870] New: __has_nothrow_constructor violates the ODR

[Bug c++/36870] New: __has_nothrow_constructor violates the ODR

[sebor at roguewave dot com]

The programs below detect an ODR violation in the libstdc++ implementation
of std::has_nothrow_default_constructor and the __has_nothrow_constructor
built-in compiler trait (hence I'm filing this as a bug in the c++ front
end rather than libstdc++).

$    cat u.cpp \
  && g++ -c -std=gnu++0x -o 1.o u.cpp \
  && g++ -DMAIN -std=gnu++0x u.cpp 1.o \
  && ./a.out
#include <cassert>
#include <type_traits>

struct S { S (); };

bool f ();

#ifdef MAIN

int main ()
{
    assert (std::has_nothrow_default_constructor<S>::value == f ());
}

#else
S::S () { }
bool f () { return std::has_nothrow_default_constructor<S>::value; }
#endif
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_default_constructor<S>::value == f ()' failed.
Aborted


$ cat u.cpp && g++ -c -std=gnu++0x u.cpp && ./a.out
#include <cassert>

struct S { S (); };

bool f ();

int main ()
{
    assert (__has_nothrow_constructor (S) == f ());
}

S::S () { }

bool f () { return __has_nothrow_constructor (S); }
a.out: u.cpp:12: int main(): Assertion
`std::has_nothrow_default_constructor<S>::value == f ()' failed.
Aborted


-- 
           Summary: __has_nothrow_constructor violates the ODR
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-18 20:58 -------
I think this is by designed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2008-07-18 21:10 -------
I'm not sure ;) But I can say that probably when I was playing with testcases I
noticed something going on about this issue and didn't find it meaningless...
Have to think a bit more about this.

Maybe Mark could help me a bit here figuring out what would be needed beyond
the current very simple TREE_NOTHROW on the tree returned by locate_ctor if one
wanted to have the behavior expected by Martin... (thanks in advance!)


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo dot carlini at oracle
                   |                            |dot com, mark at
                   |                            |codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-18 21:17 -------
(In reply to comment #1)
> I think this is by designed.

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099 in fact I knew we tested
this too ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2008-07-18 21:31 -------
gosh, my memory vanishes. Yes, Andrew is right, we have already discussed this.
In my reading of the specifications (I don't think there are important news
here) the compiler may or may not be able to figure out that a special function
doesn't actually throw, depending on the context. In my (I would say, our)
reading of the specifications there is nothing enforcing this ODR rule here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[sebor at roguewave dot com]

------- Comment #5 from sebor at roguewave dot com  2008-07-18 21:47 -------
(In reply to comment #4)

The ODR is important from an ABI standpoint -- imagine a function template
that uses SFINAE and std::has_nothrow_default_constructor<T>::type. Simply
rearranging code or even compiling multiple sources in the same step could
change which overload will be selected, potentially causing an ABI breakage.
The compiler must give the same answer for the same type regardless of the
context. That might mean not considering the body of the function if it
can't be done 100% consistently (e.g., for out-of-line functions).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2008-07-18 21:56 -------
In any case I remain unconvinced that "known not to throw any exceptions" is
the proper way to enforce the requirement.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[sebor at roguewave dot com]

------- Comment #7 from sebor at roguewave dot com  2008-07-18 22:11 -------
FYI: I discussed the wording briefly with Daveed (eccp returns true if and
only if the class has a trivial ctor or the ctor has a throw() spec on it,
for just this reason). We agree that the wording is unclear and should be
tightened up. I plan to bring it up on the reflector and write up an issue
if there's consensus on the intent (I hope you and/or Mark can help give
guidance). That said, IMO, the ODR requirement is orthogonal and beyond
question. I.e., the compiler must return the same result throughout the
same program, although it should be allowed to return a "more correct"
result by doing whatever magic it has at its disposal.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2008-07-18 22:13 -------
I think we can easily fix the issue by checking

  TYPE_RAISES_EXCEPTIONS (TREE_TYPE (t))

instead of TREE_NOTHROW (t)




-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|paolo dot carlini at oracle |
                   |dot com                     |
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-07-18 22:13:22
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2008-07-18 22:17 -------
Thanks Martin. In fact, I think Mark agrees with Daveed on this, I clearly
remember he was unimpressed by the current wording.

If Mark confirms that my Comment #8 is by and large correct I can implement a
behavior very similar to EDG for mainline.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2008-07-18 22:31 -------
More exactly, the idea is replacing:

  TREE_NOTHROW (t)

with

  TYPE_NOTHROW_P (TREE_TYPE (t))


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[mmitchel at gcc dot gnu dot org]

------- Comment #11 from mmitchel at gcc dot gnu dot org  2008-07-18 22:52 -------
Paolo --

I agree; that seems the right fix.  I don't think this should depend on what
the compiler happens to be able to prove about the body of the function; it's
way too unstable in the face of optimization, different platforms, etc.  Unless
the standard gives us some algorithm for computing this, I think we should look
at the declaration and nothing more.

-- Mark


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2008-07-19 00:29 -------
Thanks Mark, will do and submit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo at gcc dot gnu dot org]

------- Comment #13 from paolo at gcc dot gnu dot org  2008-07-21 09:09 -------
Subject: Bug 36870

Author: paolo
Date: Mon Jul 21 09:08:41 2008
New Revision: 138024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138024
Log:
/cp
2008-07-21  Paolo Carlini  <paolo.carlini@oracle.com>

        PR c++/36870
        * semantics.c (classtype_has_nothrow_assign_or_copy_p): Use
        TYPE_NOTHROW_P, not TREE_NOTHROW.
        (trait_expr_value): Likewise.

/testsuite
2008-07-21  Paolo Carlini  <paolo.carlini@oracle.com>

        PR c++/36870
        * g++.dg/ext/has_nothrow_assign_odr.C: New.
        * g++.dg/ext/has_nothrow_copy_odr.C: Likewise.
        * g++.dg/ext/has_nothrow_constructor_odr.C: Likewise.
        * g++.dg/ext/has_nothrow_assign.C: Adjust.
        * g++.dg/ext/has_nothrow_copy.C: Likewise.
        * g++.dg/ext/has_nothrow_constructor.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/ext/has_nothrow_assign_odr.C
    trunk/gcc/testsuite/g++.dg/ext/has_nothrow_constructor_odr.C
    trunk/gcc/testsuite/g++.dg/ext/has_nothrow_copy_odr.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/semantics.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/ext/has_nothrow_assign.C
    trunk/gcc/testsuite/g++.dg/ext/has_nothrow_constructor.C
    trunk/gcc/testsuite/g++.dg/ext/has_nothrow_copy.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870

[Bug c++/36870] __has_nothrow_constructor violates the ODR

[paolo dot carlini at oracle dot com]

------- Comment #14 from paolo dot carlini at oracle dot com  2008-07-21 09:11 -------
Done for mainline (would be 4.4.0).


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870