[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

2009-11-03 Thread cfairles at gcc dot gnu dot org 


--- Comment #4 from cfairles at gcc dot gnu dot org  2009-11-03 15:26 
---
See also:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#887


-- 


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

[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

2009-11-03 Thread cfairles at gcc dot gnu dot org 


--- Comment #3 from cfairles at gcc dot gnu dot org  2009-11-03 13:58 
---
Yes, I'm alive! Starting to get back into the GCC swing of things.

Ok,  and  and clocks. Its a bit of a tricky
situation, reading current standard draft and other related docs (i.e. posix)
to get myself back up to speed. In my preliminary investigations there seems to
be some issues in assuming what "epoch" means when using gthreads and what we
assume is a "known" clock.

I think condition_variable is more correct than mutex using system_clock as its
"known" clock. Currently mutex doesn't attempt "sync" unknown clocks to a known
clock in its *_until/for functions like condition_variable. This could
potentially be an issue for gthread implementations (and posix implementations
for that matter) where the epoch for system_clock, monotonic and high_res
clocks are all different (let alone user-defined clocks).

So, in condition_variable at least, the assumption is the system_clock epoch
(system_clock::time_point()) == gthread's expected epoch.

Taking the assumption that system_clock::time_point() == gthread's epoch, in
mutex, it erroneously assumes that monotic_clock::time_point() ==
system_clock::time_point() but a quick reading of the POSIX docs shows:

"For [the monotonic] clock, the value returned by clock_gettime() represents
the amount of time (in seconds and nanoseconds) since an unspecified point in
the past (for example, system start-up time, or the Epoch)."
(http://www.opengroup.org/onlinepubs/009695399/functions/clock_gettime.html)

For the POSIX gthread_cond* implementation, the POSIX standard suggests that,
if Clock Selection is available you should set the appropriate condition
attribute (ex. pthread_condattr_setclock if available).

For mutexes (from pthread_mutex_timedlock), 
"If the Timers option is supported, the timeout shall be based on the
CLOCK_REALTIME clock; if the Timers option is not supported, the timeout shall
be based on the system clock as returned by the time() function."

This almost exactly describes system_clock other than the fact that it might
use gettimeofday before using time() (i.e. std::time()), which is still
realative to the POSIX epoch so I think thats ok ... for posix gthreads impl.

Long story short, using monotonic_clock as a "known" clock in *mutex* is almost
certainly incorrect since, in POSIX, its absolute value is meaningless (epoch
is arbitrary). It would be more correct to sync the monotonic_clock to
system_clock like condition_varaible does.

30.2.4p4 says implementations should use a monotonic clock for the *_for
functions that take a relative time. Unfortunately, gthreads (and its POSIX
impl) use absolute time and assumes times are relative to the POSIX epoch.

Let me do a bit more research and poke Howard H. again for some clarification
on this before moving forward.

Chris


-- 


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

[Bug libstdc++/41530] [c++0x] Cannot move-construct std::tuple from a different type of std::tuple

2009-10-28 Thread cfairles at gcc dot gnu dot org 


--- Comment #7 from cfairles at gcc dot gnu dot org  2009-10-28 16:23 
---
Should be marked as fixed no?


-- 


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

[Bug libstdc++/41530] [c++0x] Cannot move-construct std::tuple from a different type of std::tuple

2009-10-01 Thread cfairles at gcc dot gnu dot org 


--- Comment #2 from cfairles at gcc dot gnu dot org  2009-10-01 22:52 
---
(In reply to comment #1)
> Thanks for the PR and the patch, which indeed makes sense to me (also regtests
> fine). Before committing the change, let's wait a bit in case Chris F has some
> comments...
> 

Looks good to me.


-- 


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

gcc-bugs@gcc.gnu.org

2009-06-02 Thread cfairles at gcc dot gnu dot org 


--- Comment #5 from cfairles at gcc dot gnu dot org  2009-06-03 02:47 
---
Agreed. Changed to diagnostic from link-error.


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|link-failure|diagnostic


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

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

2009-01-16 Thread cfairles at gcc dot gnu dot org 


--- Comment #4 from cfairles at gcc dot gnu dot org  2009-01-17 00:03 
---
*** Bug 38889 has been marked as a duplicate of this bug. ***


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug libstdc++/38889] [C++0x] std::bind doesn't work

2009-01-16 Thread cfairles at gcc dot gnu dot org 


--- Comment #2 from cfairles at gcc dot gnu dot org  2009-01-17 00:03 
---


*** This bug has been marked as a duplicate of 35569 ***


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/38713] New: [c++0x] ICE: Segmentation fault in auto function when decltype uses parameter pack expansion

2009-01-02 Thread cfairles at gcc dot gnu dot org 
Could probably reduce this further:

template struct Y {}; 

template struct X {}; 

template
int g(Y) { return 0; } 

template 
auto foo(F f, Y t, X) -> decltype(f(g(t)...))
{ return f(g(t)...); }

void bar(int) { }

int main() { 
  Y y;
  foo(bar, y, X<0>()); //line 16
}

Compile with -std=c++0x gives:

seg.cpp:16: internal compiler error: Segmentation fault


-- 
   Summary: [c++0x] ICE: Segmentation fault in auto function when
decltype uses parameter pack expansion
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/38712] New: [c++0x] ICE: Segmentation fault in auto function when decltype uses parameter pack expansion

2009-01-02 Thread cfairles at gcc dot gnu dot org 
Could probably reduce this further:

template struct Y {}; 

template struct X {}; 

template
int g(Y) { return 0; } 

template 
auto foo(F f, Y t, X) -> decltype(f(g(t)...))
{ return f(g(t)...); }

void bar(int) { }

int main() { 
  Y y;
  foo(bar, y, X<0>()); //line 16
}

Compile with -std=c++0x gives:

seg.cpp:16: internal compiler error: Segmentation fault


-- 
   Summary: [c++0x] ICE: Segmentation fault in auto function when
decltype uses parameter pack expansion
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/38684] [c++0x] ICE using initializer_list ctor in derived class

2008-12-31 Thread cfairles at gcc dot gnu dot org 


--- Comment #3 from cfairles at gcc dot gnu dot org  2009-01-01 02:28 
---
Templates aren't required, slightly reduced testcase:

#include 

struct Y {};

struct X : Y { 
  X(std::initializer_list) {}
}; 

struct A { 
  X v;
};

int main() {
  A a{ {1,2,3} };
}


-- 


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

[Bug libstdc++/38684] New: [c++0x] ICE using initializer_list ctor in derived class

2008-12-31 Thread cfairles at gcc dot gnu dot org 
#include 

struct Y {};

template struct X : Y { 
  X(std::initializer_list) {}
}; 

struct A { 
  X v;
};

int main() {
  A a{ {1,2,3} };
}

Compiling with -std=c++0x gives:
internal compiler error: in process_init_constructor_record, at
cp/typeck2.c:987

This compiles w/o ice or error if X does not derive from Y.


-- 
   Summary: [c++0x] ICE using initializer_list ctor in derived class
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug target/38617] ICE passing fixed point to function

2008-12-24 Thread cfairles at gcc dot gnu dot org 


--- Comment #6 from cfairles at gcc dot gnu dot org  2008-12-24 17:33 
---
(In reply to comment #5)
> Subject: Re:  ICE passing fixed point to function
>
> If they didn't configure with that option the compiler should give 
> sensible errors rather than ICEs.
> 
> I don't know which is the case here.
> 

Configured with: ../gcc/configure --disable-multilib --enable-clock-gettime=rt
--program-suffix=44 --enable-languages=c,c++

That is, no --enable-fixed-point.


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |target


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

[Bug c++/38617] ICE passing fixed point to function

2008-12-24 Thread cfairles at gcc dot gnu dot org 


--- Comment #4 from cfairles at gcc dot gnu dot org  2008-12-24 16:44 
---
(In reply to comment #3)
> What are fixed point types?

http://gcc.gnu.org/wiki/FixedPointArithmetic


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |c++


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

[Bug c++/38617] ICE passing fixed floating point to function template

2008-12-24 Thread cfairles at gcc dot gnu dot org 


--- Comment #1 from cfairles at gcc dot gnu dot org  2008-12-24 12:00 
---
cc'ing andrew


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug c++/38617] New: ICE passing fixed floating point to function template

2008-12-24 Thread cfairles at gcc dot gnu dot org 
template
void foo(T) { } // 2

int main()
{
  foo(0r); // 6
}

Gives:

fixed.cpp: In function 'void foo(T) [with T = ]':
fixed.cpp:6:   instantiated from here
fixed.cpp:2: internal compiler error: in classify_argument, at
config/i386/i386.c:5123


Chris


-- 
   Summary: ICE passing fixed floating point to function template
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/38597] [c++0x] ICE when function type given as argument to auto return type function

2008-12-21 Thread cfairles at gcc dot gnu dot org 


--- Comment #3 from cfairles at gcc dot gnu dot org  2008-12-21 14:22 
---
Hmm, also note that:

template
auto f(T,U) -> decltype(T() + U())
{ return T() + U(); }

void g(){}

int main() { f(2,3.4,&g); }

works, as in errors out with 
no matching function for call to 'f(int, double, void (*)())'

Wait wait, this also ICE's

template
auto f(T,U) -> decltype(T() + U())
{ return T() + U(); }

template void g(T){}

int main() { g(f); }

so its not that its an extra argument... its that your trying to resolve the
type T in the g() call from a function ptr that has an auto return type.


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[c++0x] ICE when function   |[c++0x] ICE when function
   |type given as extra argument|type given as argument to
   |to auto return type function|auto return type function


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

[Bug c++/38597] [c++0x] ICE when function type given as extra argument to auto return type function

2008-12-21 Thread cfairles at gcc dot gnu dot org 


--- Comment #2 from cfairles at gcc dot gnu dot org  2008-12-21 14:14 
---
fixing summary, this has to do with function ptr types

template
auto f(T,U) -> decltype(T() + U())
{ return T() + U(); }

f(1,2,&f); 

does the same for example.


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[c++0x] ICE when too many   |[c++0x] ICE when function
   |arguments given to auto |type given as extra argument
   |return type function|to auto return type function


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

[Bug c++/38597] [c++0x] ICE when too many arguments given to auto return type function

2008-12-21 Thread cfairles at gcc dot gnu dot org 


--- Comment #1 from cfairles at gcc dot gnu dot org  2008-12-21 14:00 
---
cc'ing Jason


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug c++/38597] New: [c++0x] ICE when too many arguments given to auto return type function

2008-12-21 Thread cfairles at gcc dot gnu dot org 
template
auto f(T,U) -> decltype(T() + U())
{ return T() + U(); }

int main() { f(2,f,3.4); }

Compiled with -std=c++0x gives,

ICE: in arg_assoc_type, at cp/name-lookup.c:4738


-- 
   Summary: [c++0x] ICE when too many arguments given to auto return
type function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org


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

[Bug c++/38489] [c++0x] ICE in digest_init_r, at cp/typeck2.c:821 on "auto t = 0r;" (fixed fp)

2008-12-12 Thread cfairles at gcc dot gnu dot org 


--- Comment #1 from cfairles at gcc dot gnu dot org  2008-12-12 15:59 
---
cc'ing Jason


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug c++/38489] New: [c++0x] ICE in digest_init_r, at cp/typeck2.c:821 on "auto t = 0r;" (fixed fp)

2008-12-11 Thread cfairles at gcc dot gnu dot org 
int main() {
  auto t = 0r;
}

Compile with -std=c++0x

error: fixed-point constants are a GCC extension
In function 'int main(int, char**)':
internal compiler error: in digest_init_r, at cp/typeck2.c:821


-- 
   Summary: [c++0x] ICE in digest_init_r, at cp/typeck2.c:821 on
"auto t = 0r;" (fixed fp)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: error-recovery
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/38265] STL treats explicit constructors as converting constructors

2008-11-25 Thread cfairles at gcc dot gnu dot org 


--- Comment #1 from cfairles at gcc dot gnu dot org  2008-11-25 19:34 
---
GCC 4.4.0 also accepts this code as does Comeau 4.3.10.1.


-- 


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

[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585

2008-11-18 Thread cfairles at gcc dot gnu dot org 


--- Comment #6 from cfairles at gcc dot gnu dot org  2008-11-18 17:53 
---
Even more reduced:

template class W> 
struct A{};

template
struct B{};

int main() { A a; }


-- 


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

[Bug c++/37911] Operator= called on a non constructed object.

2008-10-24 Thread cfairles at gcc dot gnu dot org 


--- Comment #1 from cfairles at gcc dot gnu dot org  2008-10-24 16:06 
---
I haven't double checked the standard but this looks like undefined behavior. 


-- 


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

[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction

2008-10-24 Thread cfairles at gcc dot gnu dot org 


--- Comment #4 from cfairles at gcc dot gnu dot org  2008-10-24 11:46 
---
Adding error-recovery since 2nd testcase does print out sane error msg before
ICE.


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||error-recovery


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

[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction

2008-10-08 Thread cfairles at gcc dot gnu dot org 


--- Comment #3 from cfairles at gcc dot gnu dot org  2008-10-08 14:06 
---
changed summary to something more specific


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE on variadic template|[c++0x] ICE in
   |function|get_innermost_template_args
   ||at cp/pt.c:516 during
   ||variadic function overload
   ||deduction


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

[Bug c++/37737] ICE on variadic template function

2008-10-05 Thread cfairles at gcc dot gnu dot org 


--- Comment #2 from cfairles at gcc dot gnu dot org  2008-10-05 12:09 
---
I believe these are both ice-on-invalid code.


-- 

cfairles at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code


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

[Bug c++/37737] ICE on variadic template function

2008-10-05 Thread cfairles at gcc dot gnu dot org 


--- Comment #1 from cfairles at gcc dot gnu dot org  2008-10-05 12:02 
---
This variant also ice's in same place but issues error first:

ice2.cpp:
template
void f()
{
  f();
}

template<>
void f() { }

int main()
{
  f();
}

ice2.cpp:8: error: template-id ‘f<>’ for ‘void f()’ does not match any template
declaration
ice2.cpp: In function ‘void f() [with U = char, T = ]’:
ice2.cpp:12:   instantiated from here
ice2.cpp:4: internal compiler error: tree check: accessed elt 1 of tree_vec
with 0 elts in get_innermost_template_args, at cp/pt.c:516

(note: both compiled with -std=c++0x)


-- 


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

[Bug c++/37737] New: ICE on variadic template function

2008-10-05 Thread cfairles at gcc dot gnu dot org 
The following snippet ICE's:

void f() { }

template
void f(){ f(); }

int main()
{ 
  f();
}


tree check: 
accessed elt 1 of tree_vec with 0 elts in get_innermost_template_args
at cp/pt.c:516

Is this ice-on-valid or will f<>() not be picked up by the non-template
function?


-- 
   Summary: ICE on variadic template function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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