[Bug c++/48294] New: internal compiler error: in build_noexcept_spec, at cp/except.c:1217

[kyle.kloepper at riverbed dot com]

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

   Summary: internal compiler error: in build_noexcept_spec, at
cp/except.c:1217
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kyle.kloep...@riverbed.com


Alisdair Meredith found a bug with the following code:
struct booleable 
{
bool data;
constexpr explicit operator bool() { return data; } 
};

constexpr booleable truthy_func() { return {true}; }

void funky() noexcept(truthy_func()) {}

int main() 
{
funky();
return 0;
}

VERSION AND ERROR:
[kkloepper@pan scratch]$ g++ -std=c++0x alisdair_bug.cc -o alisdair_bug
alisdair_bug.cc:9:36: internal compiler error: in build_noexcept_spec, at
cp/except.c:1217
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[kkloepper@pan scratch]$ g++ --version
g++ (GCC) 4.6.0 20110112 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[kkloepper@pan scratch]$

[Bug c++/48294] internal compiler error: in build_noexcept_spec, at cp/except.c:1217

[kyle.kloepper at riverbed dot com]

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

--- Comment #1 from Kyle Kloepper  
2011-03-26 11:15:19 UTC ---
This is also an issue in trunk:
[kkloepper@pan scratch]$ g++ -std=c++0x alisdair_bug.cc -o alisdair_bug
alisdair_bug.cc:9:36: internal compiler error: in build_noexcept_spec, at
cp/except.c:1217
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[kkloepper@pan scratch]$ g++ --version
g++ (GCC) 4.7.0 20110326 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[kkloepper@pan scratch]$

[Bug c++/46447] New: std::atomic_flag slower than std::atomic_uchar

[kyle.kloepper at riverbed dot com]

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

   Summary: std::atomic_flag slower than std::atomic_uchar
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kyle.kloep...@riverbed.com


It seems to me that the operations for atomic_flag could be reimplemented with
an atomic_uchar. However it looks as though a atomic_uchar performs those
operations faster.

atomic_flag::test_and_set() took 24.0051 cycles (averaged over 1 trials)
atomic_flag::clear() took 17.0037 cycles (averaged over 1 trials)
atomic_int::operator|=(1) took 20.0046 cycles (averaged over 1 trials)
atomic_int::operator=(0) took 10.2529 cycles (averaged over 1 trials)
atomic_uchar::operator|=(1) took 20.0053 cycles (averaged over 1 trials)
atomic_uchar::operator=(0) took 10.2522 cycles (averaged over 1 trials)
sizeof(aint) = 4 sizeof(auchar) = 1 sizeof(std::atomic_flag) = 1

[Bug libstdc++/46447] std::atomic_flag slower than std::atomic_uchar

[kyle.kloepper at riverbed dot com]

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

--- Comment #2 from Kyle Kloepper  
2010-11-12 18:22:13 UTC ---
Created attachment 22382
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22382
Gzipped tarball of source code used to measure times of atomics.

[Bug libstdc++/46572] New: forward_list nodes are not packed

[kyle.kloepper at riverbed dot com]

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

   Summary: forward_list nodes are not packed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kyle.kloep...@riverbed.com


I was playing around with forward_list and realized that all the list nodes
took up a minimum of 16 bytes (with larger sizes in multiples of 8--I am using
a 64-bit machine). This conflicts with what the standard notes in 23.3.3
paragraph 1:

Note: It is intended that forward_list have zero space or time overhead
relative to a hand-written C-style singly linked list.

If I was implementing a memory space critical linked list I would decorate the
list node struct with packed. This is not possible to do with the internal list
node.

I will upload an example program shortly.

[Bug libstdc++/46572] forward_list nodes are not packed

[kyle.kloepper at riverbed dot com]

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

--- Comment #2 from Kyle Kloepper  
2010-11-19 22:47:47 UTC ---
Created attachment 22464
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22464
Program to print out the size used by forward_list node allocation

[Bug libstdc++/46572] forward_list nodes are not packed

[kyle.kloepper at riverbed dot com]

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

--- Comment #3 from Kyle Kloepper  
2010-11-19 23:01:07 UTC ---
I would read the standard as in inclusive or. But even if you read it as one or
the other, I do not think that in all cases speed would be prefered over space. 

Is there any way to implement something like this:

std::forward_list __attribute((packed));

Such that the packed attribute would propogate to the list nodes?