Ed Smith-Rowland | 19 Jul 17:17 2014
Picon
Picon

Status of C++11 patches...

All,

This is sort of a PING.

Back in March there was a patch for hexfloat that was deferred until 
after stage 1.

Also there was work on codecvt that would really help my renewed 
struggle with filesystem.

What happened to these?

Ed

Linda A. Walsh | 17 Jul 22:29 2014

Recommendation for moving / shifting vector members?

I note that the 'shift' function isn't implemented for the vector
template as for valarray.

But I have a case where I want to use the  vector extensibility to hold
a variable number of items up to some max (something valarray can't do
w/no capacity()/reserve() functionality).

Is there a "memmove" type function or a "shift" type function in the C++
library to work on the valid members of a vector. 

Ex: Elements 0..N-1 => 1->N (nothing extending into the capacity, but just
moving the "valid" members).

I can think of multiple ways to do this in different containers
I.e. manually store indexes into a valarray to represent the
"valid" bounds of the sub members, or using some other container,
but was wondering if the C++ library had some way of doing it.

I'm not sure if memmove on the members is supported or not?
Are they supposed to be contiguous in memory and memmove is
'fine' -- and I'm overthinking this, or is there better
solution?  It seems like moving the backing store of the
container (i.e. memmove), could potentially break the object
paradigm and be unsupported, at least in some cases (if in any?)

Thanks & it sure would have been nice if 'shift' worked on vectors
as well as valarrays... (sigh)...

Jonathan Wakely | 17 Jul 11:34 2014
Picon

Re: [Patch, PR 61061] Add state limit for regex NFA

On 16/07/14 21:46 +0200, Maksymilian A wrote:
>Implementation based on vectors are good idea.  It seems to me that this
>does not solve all problems. I would like to ask about the
>regex_constants::error_type how it's implemented? From the safety point of
>view the most important are error_space, error_stack and error_complexity.
>In documentation I've found
>
>error_complexity - the complexity of an attempted match against a regular
>expression exceeded a pre-set level
>
>How its implemented and where is exactly defined 'pre-set level'? Thanks

error_complexity is not used in our current implementation.

Diego Novillo | 15 Jul 23:04 2014
Picon

GNU Tools Cauldron 2014 - Local information and useful links


Some useful information for the conference this weekend:

Friday, 18th July 2014, 6.30pm to 9pm
The Centre for Computing History
Rene Court
Coldhams Road
Cambridge CB1 3EW
http://www.computinghistory.org.uk/

Saturday, 19th July 2014, 7.30pm to 10.30pm
Murray Edwards College
University of Cambridge
Huntingdon Road
Cambridge CB3 0DF.
http://www.murrayedwards.cam.ac.uk/

Sunday evening, Post Conference Networking

The Regal
38-39 St Andrews Street
Cambridge CB2 3AR
http://www.jdwetherspoon.co.uk/home/pubs/the-regal

I have updated the wiki with this and other useful local
information.

https://gcc.gnu.org/wiki/cauldron2014

Diego.
(Continue reading)

Jonathan Wakely | 14 Jul 16:21 2014
Picon

[patch] Add libstdc++ type printers for class templates

This defines a new style of Python type printer that recognizes
templates and can be used to omit default template arguments from the
typename GDB prints, e.g. showing std::vector<T, std::allocator<T>> as
simply std::vector<T>.  Additionally, T will get processed by the type
recognizers so if it's a standard typedef or template it will also get
displayed in its abbreviated form.

e.g. with current trunk:

Breakpoint 1, main () at p.cc:45
45        std::vector<std::deque<std::list<int>>> nested;
(gdb) whatis nested
type = std::vector<std::deque<std::list<int, std::allocator<int> >,
std::allocator<std::list<int, std::allocator<int> > > >,
std::allocator<std::deque<std::list<int, std::allocator<int> >,
std::allocator<std::list<int, std::allocator<int> > > > > >

and with this patch:

(gdb) whatis nested
type = std::vector<std::deque<std::list<int>>>

N.B. I am not printing spaces between the closing angle brackets. If
people prefer I can put them in, or only do it for C++11 types, so
that copying and pasting types from GDB will always work (if you're
copying a C++11 type then you must be planning to use it with a C++11
compiler, which will handle >> without spaces).

This passes the python testsuite but I'll wait for comments before
committing, in case my use of the GDB API or Python can be improved by
(Continue reading)

Jonathan Wakely | 10 Jul 20:08 2014
Picon

[patch] Fix bug in experimental::any

This fixes the uses-allocator construction in experimental::any and
re-orders the data members so that I can extract the stored value in a
Python printer without having to walk the inheritance hierarchy of a
std::tuple.

The actual pretty printer for any (and string_view and optional) will
follow Real Soon Now.

Tested x86_64-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 4517 bytes
Linda A. Walsh | 10 Jul 14:18 2014

why are calls to libstdc++ being handled by python?

This looks very odd.

I can't believe it is what it appears to be, but I got
"another" core dump (unstable development work),
but unlike any other core dump, this one went back
3x as many frames and had python tracings in it.

Things looked fine (though it is a bit long) until
it got to frames 15, 16, where python error messages
were included.

AFAIK, there is no python in this program -- I thought
it was pure C++ (or bastard C posing as C++)..

Is this even possible?

#0  0x0000003002035849 in __GI_raise (sig=sig <at> entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x0000003002036cd8 in __GI_abort () at abort.c:89
#2  0x0000003002074114 in __libc_message (do_abort=do_abort <at> entry=2,
    fmt=fmt <at> entry=0x300216a220 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x000000300207996e in malloc_printerr (action=3,
    str=0x300216a3e0 "free(): invalid next size (fast)", ptr=<optimized 
out>)
    at malloc.c:4916
#4  0x000000300207a647 in _int_free (av=<optimized out>, p=0x23a23b0,
    have_lock=0) at malloc.c:3772
#5  0x000000000041b3d2 in _M_dispose (__a=..., this=<optimized out>)
    at /usr/include/c++/4.8/bits/basic_string.h:249
(Continue reading)

Jonathan Wakely | 3 Jul 12:35 2014
Picon

Additional headers under include/experimental/

I'm working on parts of the Filesystem TS and think it makes sense to
split it up into separate headers for path, directory utils and the
free functions, then include those from <experimental/filesystem>,
otherwise it's going to be a whopper.

Currently I've created include/experimental/fs_path.h for the path
class, does that seem OK?

Would a new include/experimental/bits directory be better, so that
only official headers required by a TS are in include/experimental?
(That would imply moving string_view.tcc to another directory).

Matthias Klose | 1 Jul 10:40 2014

missing symbols in libstdc++.so.6 built from the 4.9 branch

on some linux architectures there are some symbols missing in libstdc++.so.6
built from the 4.9 branch.  I didn't notice before due to a packaging bug.
affected are ARM32, HPPA, SPARC.

 - ARM32 (build log [1], both soft and hard float) are missing
     __aeabi_atexit <at> CXXABI_ARM_1.3.3
     __aeabi_vec_*

   Can these be ignored?

 - HPPA (build log [2]), is missing all the future_base symbols and
   exception_ptr13exception symbols, current_exception and
   rethrow_exception.

 - SPARC (build log [3]) configured for sparc64-linux-gnu is missing
   symbols in the 32bit multilib build, although these are present
   in a sparc-linux-gnu build. Missing are same ones as in the HPPA
   build, long double 128 related symbols, numeric_limits, and some
   math symbols.

   Looks like more than one issue is involved, I remember that the
   math symbols were already dropped in earlier versions for other
   architectures. The build is configured -with-long-double-128.

Matthias

[1]
https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9&arch=armhf&ver=4.9.0-8&stamp=1403809654
[2]
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.0-9&stamp=1404018503
(Continue reading)

John David Anglin | 30 Jun 16:20 2014
Picon

Missing libstdc++6 symbols on hppa-unknown-linux-gnu

Hi,

The Debian build of gcc-4.9 now checks for expected libstdc++6  
symbols.  This check is
failing on hppa-unknow-linux-gnu.  For detals, see:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.0-9&stamp=1404018503

There are two sets of symbols missing,

- the ones from debian/libstdc++6.symbols.excprop

- all the future_base symbols (in libstdc++6.symbols.common)

These symbols apparently exist on other architectures.  Are we missing  
some hppa specific configuration?

Dave
--
John David Anglin	dave.anglin <at> bell.net

Gerald Pfeifer | 29 Jun 13:48 2014

[wwwdocs,libstdc++] Remove libstdc++/lib3styles.css

We don't use this any more, so let's remove it.

Gerald

2014-06-29  Gerald Pfeifer  <gerald <at> pfeifer.com>

	* lib3styles.css: Remove.
	* index.html: Remove reference to lib3styles.css.

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/libstdc++/index.html,v
retrieving revision 1.38
diff -u -r1.38 index.html
--- index.html	14 Apr 2012 17:10:35 -0000	1.38
+++ index.html	29 Jun 2014 11:43:53 -0000
 <at>  <at>  -2,7 +2,6  <at>  <at> 
 <head>
  <meta name="KEYWORDS" content="libstdc++, homepage, home, g++, libg++, STL" />
  <title>Standard C++ Library v3</title>
- <link rel="StyleSheet" href="lib3styles.css" />
 </head>

 <body>
Index: lib3styles.css
===================================================================
RCS file: lib3styles.css
diff -N lib3styles.css
--- lib3styles.css	4 Apr 2011 17:56:25 -0000	1.2
+++ /dev/null	1 Jan 1970 00:00:00 -0000
(Continue reading)


Gmane