Jonathan Wakely | 29 Aug 16:16 2014
Picon

Typedef for iterators denoting positions to insert/erase

In the new std::string implementation I'm using the following typedef:

#if __cplusplus < 201103L
      typedef iterator __pos_iterator;
#else
      typedef const_iterator __pos_iterator;
#endif

This can then be used to avoid littering the rest of the file with preprocessor
conditionals like:

      iterator
#if __cplusplus >= 201103L
      erase(const_iterator __first, const_iterator __last) noexcept
#else
      erase(iterator __first, iterator __last)
#endif
      {
      ...
      }

Is this worth doing in the other containers too?

I'm undecided whether it's clearer to read the preprocessor condition
or a declaration with the non-standard __pos_iterator type, but I
think I'd prefer to use the new type. Any other opinions?

Jonathan Wakely | 28 Aug 17:46 2014
Picon

[patch] Adjust comments in testsuite/ext/random/

The tests for the non-standard distributions have bogus standard
references. [rand.concept.dist] comes from an old C++0x draft, and the
[rand.dist.ext.*] labels are entirely fictional because obviously
non-standard extensions are not in the standard.

Tested x86_64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 30 KiB
Jonathan Wakely | 27 Aug 19:50 2014
Picon

[patch] Only configure libstdc++-v3/python dir for hosted builds

Currently a freestanding build installs the Python GDB hooks as
${libdir}/libstdc*-gdb.py (with a literal * character in the filename)
because there is no libstdc++.so library file and the wildcard doesn't
get expanded (see the install-data-local target in the
libstdc++-v3/python/Makefile.am file).

I don't see any reason to install any Python files for a freestanding
build, the pretty printers and type printers are only useful for types
defined in the hosted library, so this just disables the entire
directory.

Is there any reason not to do this?
Attachment (patch.txt): text/x-patch, 848 bytes
Jonathan Wakely | 27 Aug 19:33 2014
Picon

[patch] libstdc++/62159 install missing freestanding headers for C++11

C++11 adds several more headers to the minimum requirements for a
freestanding implementation.

Tested x86_64-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 2552 bytes
Jonathan Wakely | 27 Aug 15:00 2014
Picon

Add --disable-libstdcxx-hosted as alias for --disable-hosted-libstdcxx ?

I've now twice bootstrapped GCC with --disable-libstdcxx-hosted which
is ignored, because it should have been --disable-hosted-libstdcxx.

Given that most of our other configure options are of the form
--enable-libstdcxx-foo does it make sense to support both forms?

It's probably not very important, as the users who need to do
freestanding builds probably remember how to do it, unlike me :)

David Kastrup | 27 Aug 12:21 2014
Picon
Picon

Experience with g++ 4.8 and -frepo?


Hi, I've tried compiling a larger application with the -frepo option on
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
with matching libstdc++-4.8-dev and when configuring/compiling with
-frepo I get (after collect repeatedly recompiling and relinking)

collect: relinking
./out/../../flower/out/library.a(file-path.o): In function
`_M_insert_dispatch<__gnu_cxx::__normal_iterator<const std::basic_string<char>*,
std::vector<std::basic_string<char> > > >':
/usr/include/c++/4.8/bits/stl_vector.h:1291: undefined reference to `void
std::vector<std::string, std::allocator<std::string>
>::_M_range_insert<__gnu_cxx::__normal_iterator<std::string const*,
std::vector<std::string, std::allocator<std::string> > >
>(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string,
std::allocator<std::string> > >, __gnu_cxx::__normal_iterator<std::string const*,
std::vector<std::string, std::allocator<std::string> > >,
__gnu_cxx::__normal_iterator<std::string const*, std::vector<std::string,
std::allocator<std::string> > >, std::forward_iterator_tag)'
./out/../../flower/out/library.a(polynomial.o): In function
`__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<double*, std::vector<double> >,
std::less<double> >':
/usr/include/c++/4.8/bits/stl_algo.h:2294: undefined reference to `void
std::__move_median_to_first<__gnu_cxx::__normal_iterator<double*, std::vector<double,
std::allocator<double> > >, std::less<double> >(__gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, __gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, __gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, __gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, std::less<double>)'
./out/../../flower/out/library.a(polynomial.o): In function
(Continue reading)

John David Anglin | 27 Aug 01:21 2014
Picon

[committed] Update 4.8 baseline symbols on hppa-linux

Attached is an update to the baseline symbols on hppa-linux to fix the  
abi test failure
in the current 4.8 tree.

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

2014-08-26  John David Anglin  <danglin <at> gcc.gnu.org>

	* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.

Index: config/abi/post/hppa-linux-gnu/baseline_symbols.txt
===================================================================
--- config/abi/post/hppa-linux-gnu/baseline_symbols.txt	(revision 214400)
+++ config/abi/post/hppa-linux-gnu/baseline_symbols.txt	(working copy)
 <at>  <at>  -400,6 +400,7  <at>  <at> 
 FUNC:_ZNKSt15basic_streambufIwSt11char_traitsIwEE6getlocEv <at>  <at> GLIBCXX_3.4
 FUNC:_ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv <at>  <at> GLIBCXX_3.4
 FUNC:_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv <at>  <at> GLIBCXX_3.4
+FUNC:_ZNKSt17bad_function_call4whatEv <at>  <at> GLIBCXX_3.4.18
 FUNC:_ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv <at>  <at> GLIBCXX_3.4
 FUNC:_ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE5rdbufEv <at>  <at> GLIBCXX_3.4
 FUNC:_ZNKSt18basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv <at>  <at> GLIBCXX_3.4
 <at>  <at>  -587,6 +588,8  <at>  <at> 
 FUNC:_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewm <at>  <at> GLIBCXX_3.4
 FUNC:_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewx <at>  <at> GLIBCXX_3.4
 FUNC:_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewy <at>  <at> GLIBCXX_3.4
(Continue reading)

Jonathan Wakely | 26 Aug 14:31 2014
Picon

[patch] Update C++11 library implementation status for 4.8 branch

Committed to the 4.8 branch.
Attachment (patch.txt): text/x-patch, 24 KiB
Florian Goth | 19 Aug 16:54 2014
Picon
Picon

[Ping][Patch] Speedup Riemann Zeta

Hi all,
in my attempt to get to know the handling within this list and 
how patches are dealt within gcc,
I posted a while ago this patch here

https://gcc.gnu.org/ml/libstdc++/2014-08/msg00033.html

Anything wrong with it?
I would like to learn which guidelines I have to respect,
before I try to get the larger patches for the Polylog function into libstdc++.

Thanks for your time,
Florian.

Václav Zeman | 18 Aug 21:00 2014
Picon

Re: init_priority attribute and libstdc++

On 18.8.2014 13:25, Jonathan Wakely wrote:
> I'm on my phone so can't send plain text mail to the list, or check the
> code, but I'm pretty sure the answer is 101
> 
> Anything lower than that is reserved for the implementation so libstdc++
> would use that. Nothing in string or vector needs dynamic init anyway IIRC

Some paths of my library's initialization might try to print warnings or
errors. I have hit a SIGSEGV with the following test case, which uses
std::cerr:

~~~~
#include <iostream>

struct S1
{
    S1() { std::cerr << __FUNCTION__ << "\n"; }
} static s1 __attribute__ ((__init_priority__ (65535/2)));

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

The stack trace is

~~~~
#0  0x00007ffff7b6a559 in std::ostream::sentry::sentry(std::ostream&) ()
(Continue reading)

Jonathan Wakely | 15 Aug 17:51 2014
Picon

[patch] libstdc++/62159 add missing headers for freestanding implementation

This seems to fix PR 62159, in that I can now include all the required
headers in a C++11 program using a compiler built with
--disable-libstdcxx-hosted, but 'make check' doesn't do anything for
freestanding builds - should I be doing anything else to test it?

Attachment (patch.txt): text/x-patch, 1760 bytes

Gmane