[Bug c++/66256] noexcept evaluation done before end of class

2016-04-23 Thread mmehlich at semanticdesigns dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66256

Michael Mehlich  changed:

   What|Removed |Added

 CC||mmehlich at semanticdesigns 
dot co
   ||m

--- Comment #1 from Michael Mehlich  ---
I agree, name resolution should consider all declarations in the class,
but apparently gcc does name resolution on the exception specification way too
early.

An example where this causes no error message being created for obviously wrong
code is the swap function in the pair template in the header file
bits/stl_pair.h (for gcc 5.3.0/cygwin), which is declared as
  void
  swap(pair& __p)
  noexcept(noexcept(swap(first, __p.first))
   && noexcept(swap(second, __p.second)))

clang 3.7.1. properly reports an error for the swap in the exception
specification.
BTW: The header file could be fixed easily by adding std:: in front of these
swap occurrences.

[Bug c++/64232] Derived class with implicitly declared assignment operator is std::is_assignable though base class is not std::is_assignable

2014-12-09 Thread mmehlich at semanticdesigns dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64232

--- Comment #2 from Michael Mehlich mmehlich at semanticdesigns dot com ---
My expectation was that the compiler declares the copy assignment operator of Y
as deleted as its base class X is not assignable; std::is_assignable would then
just have to look at the copy constructor for Y and notice that it is deleted,
which would obviously be in the immediate context.
But arguably, 12.8 paragraph 34 item 4 only looks at the copy assignment
operator for X, not whether X can actually be copy-assigned, which - as the
example above shows - may require that the copy constructor for X is not
deleted.
By the way, std::is_nothrow_assign has the same problem (i.e. declaring X(const
X) as throwing, and operator=(X x) as not throwing results in gcc claiming
that the copy assignment operator for Y is not throwing).

[Bug c++/64232] New: Derived class with implicitly declared assignment operator is std::assignable though base class is not std::assignable

2014-12-08 Thread mmehlich at semanticdesigns dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64232

Bug ID: 64232
   Summary: Derived class with implicitly declared assignment
operator is std::assignable though base class is not
std::assignable
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mmehlich at semanticdesigns dot com

Derived class with implicitly declared assignment operator is std::assignable
though the base class is not std::assignable

Code:

#include iostream
#include type_traits

struct X {
X(const X) = delete;
void operator=(X x);
};

struct Y: X {
};

int main()
{
std::cout  std::is_assignableX,X::value  std::endl;
std::cout  std::is_assignableY,Y::value  std::endl;
}

Output:
0
1

[Bug c++/58107] New: missing destructor call after thrown exception in lambda capture

2013-08-08 Thread mmehlich at semanticdesigns dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58107

Bug ID: 58107
   Summary: missing destructor call after thrown exception in
lambda capture
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mmehlich at semanticdesigns dot com

Code:

extern C int printf(const char *,...);

struct A {
A() { printf(A()\n); }
A(const A) { printf(A(const A)\n); }
~A() { printf(~A()\n); }
operator int() const;
};
struct B {
B() { printf(B()\n); }
B(const B) { printf(B(const B)\n); }
~B() { printf(~B()\n); }
operator int() const;
};

int main() {
A a;
B b;
try { auto lll ( [a,c = (throw 7, 9),b]()-int { return a+c+b; } ); // gcc
doesn't destroy copy-captured a...
} catch (...) {
}
};

Compile command line:
  gcc -std=c++1y lambda.cpp -lstdc++

Actual output:
  A()
  B()
  A(const A)
  ~B()
  ~A()

Expected output:
  A()
  B()
  A(const A)
  ~A()
  ~B()
  ~A()

The destructor call for the copy captured a is missing.

[Bug c++/57930] New: missing destructor call after thrown exception in C++11 list initialization

2013-07-18 Thread mmehlich at semanticdesigns dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930

Bug ID: 57930
   Summary: missing destructor call after thrown exception in
C++11 list initialization
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mmehlich at semanticdesigns dot com

In the example below, a subobject of type B is constructed but not destructed
when an exception is thrown during construction of the enclosing object of
type A after subobject of type B has been constructed.

extern C int printf(const char *,...);
struct B {
B(int,int) { printf(CB %p\n,this); }
B(const B) { printf(const CB %pn\n,this); }
B(B) { printf(const CB %pn\n,this); }
~B() { printf(B %p\n,this);  }
};
struct C {
int c;
int c2;
};
struct A {
 struct B b;
 struct C c;
};
A test() {
//const A a1 = { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B
called
//const A a2 = { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B not
called
return { { 1, 2 }, { 3, (throw 9, 4) } } ; // destructor for B not called
};
int main() {
try {
test();
} catch (...) {
}
}

[Bug c++/56702] New: : wrongly considered an alternative token for template argument list using global name specifier

2013-03-23 Thread mmehlich at semanticdesigns dot com 


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



 Bug #: 56702

   Summary: : wrongly considered an alternative token for

template argument list using global name specifier

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mmehl...@semanticdesigns.com





According to 2.5, paragraph 3, second item in list the character sequence

':' in the following example is not a alternative token/digraph,

but  is a separate token. Thus, this should not cause an error.

(Note: This is different from C++98.)



Example code:



class X { };

templatetypename class Y { };



Y::X y;



Command line and gcc 4.7.2 error message:

 cp fail.cpp gcc -std=c++11 test.cpp

test.cpp:4:2: error: '::' cannot begin a template-argument list [-fpermissive]

test.cpp:4:2: note: ':' is an alternate spelling for '['. Insert whitespace

between '' and '::'

test.cpp:4:2: note: (if you use '-fpermissive' G++ will accept your code)

[Bug c++/56506] variadic class template specialization not selected as best match

2013-03-04 Thread mmehlich at semanticdesigns dot com 


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



--- Comment #3 from Michael Mehlich mmehlich at semanticdesigns dot com 
2013-03-04 16:58:45 UTC ---

Considering that based on 14.5.3(5) a template member declaration

  XYZT...,T...::type x;

with T bound to int,bool,char must expand to

  XYZint,bool,char,int, 

  YZint,bool,char,bool, 

  YZint,bool,char,char::type x;

I'd consider it rather counter-intuitive if I cannot get a match as described

in my original message.



Does the standard actually specify how the matching process works in detail

in the presence of variadic templates?  Going through the template section,

I haven't found anything definite that would put light onto this issue

(though I might have missed it).



I can't really understand your because it is not followed by ...;

after all, in XYZT..., U... the parameter pack U is also not immediately

followed by a ..., so why is that case ok but my original one isn't?



It is pretty easy to implement a matcher that successfully matches the case

in the original message, so I don't think the standard has any excuse not to

consider this a successful match, either.  

Notwithstanding that, the standards committee might have decided otherwise.

If so, where does it say so in the standard, resp. how can I conclude this

from what I can find in there?



--

  Michael

[Bug c++/56506] variadic class template specialization not selected as best match

2013-03-02 Thread mmehlich at semanticdesigns dot com 


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



--- Comment #1 from Michael Mehlich mmehlich at semanticdesigns dot com 
2013-03-02 18:55:43 UTC ---

Some more information using a function template instead of a class template:



-- Additional code

templatetypename ... T void foo(YZT...,T...) {

}



int main() {

YZint,bool,char,int yi;

YZint,bool,char,bool yb;

YZint,bool,char,char yc;

foo(yi,yb,yc);

}



-- Error message from gcc 4.7.2:

test.cpp: In function 'int main()':

test.cpp:31:14: error: no matching function for call to 'foo(YZint, bool,

char, int, YZint, bool, char, bool, YZint, bool, char, char)'

test.cpp:31:14: note: candidate is:

test.cpp:15:31: note: templateclass ... T void foo(YZT ..., T...)

test.cpp:15:31: note:   template argument deduction/substitution failed:

test.cpp:31:14: note:   deduced conflicting types for parameter 'T' ('int,

bool, char' and 'int')

test.cpp:31:14: note:   'YZint, bool, char, int' is not derived from 'YZT

..., T'



It looks like the compiler decides to bind T to int when handling the

first argument instead of binding a prefix of T to int.

[Bug c++/56506] New: variadic class template specialization not selected as best match

2013-03-01 Thread mmehlich at semanticdesigns dot com 


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



 Bug #: 56506

   Summary: variadic class template specialization not selected as

best match

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mmehl...@semanticdesigns.com





I'd expect the instantiation of X in the following code to resolve to

the partial specialization, but gcc 4.7.2 seems to instantiate the base

template (causing a compile-time name resolution error).



// Code:

templatetypename ... T struct X { };

templatetypename ... T struct Y { };

templatetypename ... T struct Z { };



templatetypename ... T  struct XYZT...,T... {

typedef int type;

};



XYZint,bool,char,int, 

  YZint,bool,char,bool, 

  YZint,bool,char,char::type x;



// Detailed compiler version information:

gcc -v

Using built-in specs.

COLLECT_GCC=C:\MinGW\bin\gcc.exe

COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe

Target: mingw32

Configured with: ../gcc-4.7.2/configure

--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions

--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry

--enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enabl

e-version-specific-runtime-libs --build=mingw32 --prefix=/mingw

Thread model: win32

gcc version 4.7.2 (GCC)

[Bug c++/52320] New: missing destructor call after thrown exception in initializer

2012-02-20 Thread mmehlich at semanticdesigns dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320

 Bug #: 52320
   Summary: missing destructor call after thrown exception in
initializer
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mmehl...@semanticdesigns.com


The following example has constructors of class A called 4 times but
destructors only 3 times. 

Apparently, if an exception is thrown during the construction of an aggregate
class, the destructors of already constructed data members are not called.

#include iostream

#define FUNCTION_NAME __PRETTY_FUNCTION__

#define TRACE_FUNCTION { std::cout  this  -  FUNCTION_NAME 
std::endl; }

struct A {
A() { TRACE_FUNCTION; }
A(int) { TRACE_FUNCTION; }
A(const A) { TRACE_FUNCTION; }
A operator=(const A) TRACE_FUNCTION;
~A() TRACE_FUNCTION;
};

int main() {
try {
struct X {
A e1[2], e2;
} 
x2[3] = { 1, 2, 3, 4, (0, throw 9, 5), 6 };
} catch (...) {
}
}

Detailed version information:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure
--srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v
--with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static
--enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava
--program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada
--enable-threads=posix --with-arch=i686 --with-tune=generic
--enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4
CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind
--with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)