[Bug c++/52748] [C++11] N3276 changes to decltype

2012-08-09 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748

--- Comment #1 from Johan Lundberg  2012-08-09 
08:08:46 UTC ---
confirmed... I agree with this. Among other things it's important for
boost/C++11 interop.

[Bug c++/54316] New: [C++11] move constructor for string_stream

2012-08-18 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316

 Bug #: 54316
   Summary: [C++11] move constructor for string_stream
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lundb...@gmail.com

[Bug c++/54316] [C++11] move constructor for string_stream

2012-08-18 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316

Johan Lundberg  changed:

   What|Removed |Added

 CC||lundberj at gmail dot com
 Depends on||53626

--- Comment #1 from Johan Lundberg  2012-08-18 
18:42:09 UTC ---
std::stringstream should be move constructable but there is no move constructor
declared in include/std/sstream. 

This missing C++11 feature is dependent on basic_ios
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53626#add_comment) but additional
work seem to be required for stringsteam and other dependent classes.

The relevant standard section is 27.8.5 (Class template basic_stringstream).

  regards J. 

//Minimal example:
#include 
#include 
std::stringstream getss(){
   std::stringstream q;
   return std::move(q);
}

compile_testtmp.cpp: In function ‘std::stringstream getss()’:
compile_testtmp.cpp:7:22: error: use of deleted function
‘std::basic_stringstream::basic_stringstream(const
std::basic_stringstream&)’
In file included from compile_testtmp.cpp:2:0:
/usr/include/c++/4.7/sstream:485:11: note:
‘std::basic_stringstream::basic_stringstream(const
std::basic_stringstream&)’ is implicitly deleted because the default
definition would be ill-formed:
/usr/include/c++/4.7/sstream:485:11: error: use of deleted function
‘std::basic_iostream::basic_iostream(const std::basic_iostream&)’
In file included from /usr/include/c++/4.7/sstream:39:0,
 from compile_testtmp.cpp:2:
/usr/include/c++/4.7/istream:789:11: note:
‘std::basic_iostream::basic_iostream(const std::basic_iostream&)’
is implicitly deleted because the default definition would be ill-formed:
/usr/include/c++/4.7/istream:789:11: error: use of deleted function
‘std::basic_istream::basic_istream(const std::basic_istream&)’
/usr/include/c++/4.7/istream:56:11: note:
‘std::basic_istream::basic_istream(const std::basic_istream&)’ is
implicitly deleted because the default definition would be ill-formed:
/usr/include/c++/4.7/istream:56:11: error: use of deleted function
‘std::basic_ios::basic_ios(const std::basic_ios&)’

... and further similar (~50 lines).

[Bug c++/39813] improve __PRETTY_FUNCTION__ for templated methos

2012-08-18 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813

Johan Lundberg  changed:

   What|Removed |Added

 CC||lundberj at gmail dot com

--- Comment #10 from Johan Lundberg  2012-08-18 
18:57:30 UTC ---
I confirm this issue with gcc 4.7.

> g++ outputs:
>   void A::fn() [with T = int]
>   void B::fn() [with T = int]
> 
> I think that the latter should output:
>   void B::fn() [with T = int]

[Bug c++/20313] in diagnostic is confusing

2012-08-18 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313

Johan Lundberg  changed:

   What|Removed |Added

 CC||lundberj at gmail dot com

--- Comment #5 from Johan Lundberg  2012-08-18 
19:07:22 UTC ---
(In reply to comment #4)
> Wow - a blast from the past! FWIW, I still think that the "" is
> confusing. That 4.6 drops one of the messages is an improvement though...

Blast from the past again, gcc 4.7 gives the same result as 4.6

[Bug c++/57758] New: gcc accepts incorrect in-class brace initializers

2013-06-29 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758

Bug ID: 57758
   Summary: gcc accepts incorrect in-class brace initializers
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lundberj at gmail dot com

In summary, having a class member in-class copy-construct from itself (!)
compiles without warning when curly-brace syntax is used.

The result is that the class invariants are never established. The following
code is accepted: 

#include 
struct C{
   C()=delete;
   C(const C& other): x(other.x+1){}
   int x=10;
};
struct D{
   C c0{c0};  // << -- compiles without warning
 //C c1{c1};  // << -- correctly rejected
};
int main(){
   D d;
   std::cout << d.c0.x << std::endl; // prints 1
}

You already get the point. Similarly, these definitions of C also compiles, and
the printed value of x is 0 in both cases.

struct C{
   int x=10;  
   C(float,float){}
};
struct C{
   int x=10;  
};

Using the following definition I get an un-initialized reference: x == 1412476
:

struct C{
   C(const C& other): z(other.z),x(other.x){}
   int z=10;
   int & x{z};
};

This seems like something that would be good to detect.

Using class C{}; is correctly rejected (with 'too many initializers for ‘C’').

[Bug c++/57758] gcc accepts incorrect in-class brace initializers

2013-06-29 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758

--- Comment #2 from Johan Lundberg  ---
Yes. I'm sorry, it's almost word-for-word identical to 48483.

[Bug c++/58929] New: condition_variable does not wait without -pthread

2013-10-30 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929

Bug ID: 58929
   Summary: condition_variable does not wait without -pthread
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lundberj at gmail dot com

A warning would have been helpful for this case of missed -pthread. 
Normally a runtime error is at least generated but the following C++11 code
compiles fine with all warnings enabled, and also executes without run time
errors, but does so incorrectly if -pthread is not given. (wait_for is then
just skipped). 

cheers Johan.

#include 
#include 
#include 
void sleep10(){ // sleeps only of -pthread is used
  std::mutex m;
  std::condition_variable cv;
  std::unique_lock lk(m);
  cv.wait_for(lk,std::chrono::seconds{10}); 
}

[Bug c++/58931] New: condition_variable::wait_until overflowed by large time_point

2013-10-30 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931

Bug ID: 58931
   Summary: condition_variable::wait_until overflowed by large
time_point
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lundberj at gmail dot com

With valid but large steady clock time_points, condition_variable.wait_until
does not sleep at all, but instead continues as if the time was passed. 

Perhaps related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562

Example: 

#include 
#include 
#include 
int main(){
  std::mutex m;
  std::condition_variable cv;
  std::unique_lock lk(m);
  // does not sleep at all:
  cv.wait_until(lk,
 std::chrono::time_point::max());
  // sleeps fine:
  //cv.wait_until(lk,
  //   std::chrono::steady_clock::now()+1*std::chrono::hours{24*365});
}

cheers / Johan -thanks for a great compiler! 

PS.
* I compiled gcc with --enable-libstdcxx-time=yes. Using 64 bit linux 3.5.0
* The bug does not occur with system_clock.
* I used time_point max() to let a worker thread wait when a queue of delayed
events was empty.

[Bug libstdc++/58929] condition_variable does not wait without -pthread

2013-10-31 Thread lundberj at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929

--- Comment #3 from Johan Lundberg  ---
(In reply to Jonathan Wakely from comment #2)
> I suppose we could turn all timed waiting functions into sleeps, and wait()
> into an infinite loop, when libpthread is not linked in, but I'd prefer not
> to add that complexity.

I agree, that sounds too much.

The documentation of -pthread states that it sets flags for the preprocessor in
addition to the linker and at least on my system, _REENTRANT is set by
-pthreads. If that's a canonical way to detect threading support I suggest
checking it in the headers that rely on threading:

#ifndef _REENTRANT
#error "No thread support enabled."
#endif

If there are reasons this is not a good idea so be it.

[Bug c++/55708] New: g++ crashes: constexpr function with reference parameters.

2012-12-15 Thread lundberj at gmail dot com 

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

 Bug #: 55708
   Summary: g++ crashes: constexpr function with reference
parameters.
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lundb...@gmail.com


The following code crashes g++ 4.8-20121209 (and gcc 4.7.2). The issue occurs
with some uses of the result of a constexpr function with reference parameters
(&& or &). 

Both the normal template do_y() and user defoned literal _y() shows exactly the
same problem, via the assert at cp/pt.c:14334. 

Perhaps related: bug 49514, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49514

Full example:

template
struct AA { static constexpr int val = N; };

template
//constexpr unsigned long long mymax(A a,B b){ // <-- compiles 
constexpr unsigned long long mymax(A && a,const B& b){
  return a
constexpr long long operator"" _y() noexcept
{
  return AA<1, mymax(1,2)>::val; // <-- crashes gcc
  // return mymax(1,2);   // <-- compiles
  // return AA<1,2>::val; // <-- compiles
}

template
constexpr unsigned long long do_y() noexcept
{
  return AA<1, mymax(1,2)>::val; <-- crashes gcc
}

int main(){
  return 1_y + do_y() ;  
}

I compiled with g++ -Wall -Wextra file.cpp -std=c++11
Here's the full g++ printout:

In function ‘constexpr long long int operator"" _y()’:
internal compiler error: in tsubst_copy_and_build, at cp/pt.c:14334
   return AA<1, mymax(1,2)>::val;
 ^
0x81a4dc9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:14334
0x81ed922 tsubst_non_call_postfix_expression
../.././gcc/cp/pt.c:13229
0x81a0422 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:13452
0x81a0a99 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:13352
0x81a1439 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:13760
0x81a5c3a fold_non_dependent_expr_sfinae(tree_node*, int)
../.././gcc/cp/pt.c:5081
0x81c48bd convert_nontype_argument
../.././gcc/cp/pt.c:5493
0x81c48bd convert_template_argument
../.././gcc/cp/pt.c:6383
0x81ca30b coerce_template_parms
../.././gcc/cp/pt.c:6722
0x81cc506 lookup_template_class_1
../.././gcc/cp/pt.c:7226
0x81cc506 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:7523
0x82dbc87 finish_template_type(tree_node*, tree_node*, int)
../.././gcc/cp/semantics.c:2791
0x8267f40 cp_parser_template_id
../.././gcc/cp/parser.c:12707
0x826834a cp_parser_class_name
../.././gcc/cp/parser.c:18105
0x825cf49 cp_parser_qualifying_entity
../.././gcc/cp/parser.c:5276
0x825cf49 cp_parser_nested_name_specifier_opt
../.././gcc/cp/parser.c:5007
0x8275975 cp_parser_simple_type_specifier
../.././gcc/cp/parser.c:13882
0x825be2a cp_parser_postfix_expression
../.././gcc/cp/parser.c:5551
0x825e5ab cp_parser_unary_expression
../.././gcc/cp/parser.c:6686
0x825f185 cp_parser_binary_expression
../.././gcc/cp/parser.c:7360