Jonathan Wakely | 12 Dec 16:10 2014
Picon

[patch] libstdc++/64241 fix std::make_exception_ptr() for -fno-exceptions

It's not clear to me that std::make_exception_ptr() is actually useful
with -fno-exceptions, but we might as well return something
well-defined rather than garbage that might crash the program.

Tested x86_64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 2321 bytes
Tim Shen | 11 Dec 09:27 2014
Picon

[Patch, libstdc++/64239] Fix regex_iterator copying

As discussed in Bugzilla.

Bootstrapped and tested.

Is it Ok to backport it to 4.9 branch, with _M_in_iterator kept unused?

Thanks! :)

-- 
Regards,
Tim Shen
commit 18c4399589b414c79c6e85ab91f7a95f2fcad829
Author: timshen <timshen <at> google.com>
Date:   Wed Dec 10 21:30:13 2014 -0800

    	PR libstdc++/64239
    	* include/bits/regex.h (match_results<>::match_results,
    	match_results<>::operator=, match_results<>::position,
    	match_results<>::swap): Remove match_results::_M_in_iterator.
    	Fix ctor/assign/swap.
    	* include/bits/regex.tcc: (__regex_algo_impl<>,
    	regex_iterator<>::operator++): Set match_results::_M_begin as
    	"start position".
    	* testsuite/28_regex/iterators/regex_iterator/char/
    	string_position_01.cc: Test cases.

diff --git a/libstdc++-v3/include/bits/regex.h b/libstdc++-v3/include/bits/regex.h
index cb6bc93..3afec37 100644
(Continue reading)

Jonathan Wakely | 10 Dec 02:37 2014
Picon

[patch] std::regex: Implement LWG DR 2329 and DR 2332

Two defect reports that protect against dangerous uses of std::regex
involving dangling references to temporaries:
http://cplusplus.github.io/LWG/lwg-defects.html#2329
http://cplusplus.github.io/LWG/lwg-defects.html#2332

Tested x86_64-linux & powerpc64-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 9 KiB
Jonathan Wakely | 9 Dec 16:19 2014
Picon

Micro-optimisation in <ext/rope.h> ?

What's this for?

#ifdef __EXCEPTIONS
      _Rope_self_destruct_ptr() : _M_ptr(0) { };
#else
      _Rope_self_destruct_ptr() { };
#endif

Are we really just trying to avoid setting a pointer to zero for the
case where the object won't get destroyed by stack-unwinding?

<ext/ropeimpl.h> seems to do the same:

#if !defined(__GC) && defined(__EXCEPTIONS)
    __forest[__i] = 0;
#endif

In the interests of simplicity I think we should just zero those
pointers even when exceptions are disabled. And the default
constructor could just be removed, it isn't used anywhere!

I'll try to remember to come back to this in stage1 next year.

Jonathan Wakely | 7 Dec 01:10 2014
Picon

[wwwdocs] Move -Wodr and -Wsuggest-final-{methods,types} items to C++ section.

The items on these new warnings are listed under libstdc++, but should
be under C++.

Committed to CVS.

Attachment (patch.txt): text/x-patch, 2013 bytes
Jonathan Wakely | 6 Dec 17:20 2014
Picon

Deprecating std::has_trivial_xxx traits

Now that we have std::is_trivially_constructible etc. we should
deprecate and then remove the non-standard std::has_trivial_destructor
traits.

Any objections to adding that to the release notes and adding the
_GLIBCXX_DEPRECATED attribute to the traits?

tckosvic | 6 Dec 16:37 2014
Picon

shared library -Wl command line option

GCC Group, 
I'm not a heavyweight programmer just an engineer hacker but I've found an
issue. I am working with nasa GMAT orbital mechanics code.  Code is  *.cpp 

I have a line of code as below in a make file:

SHARED_LIB_FLAGS = -shared -Wl

I now get error message:

g++: error: unrecognized command line option ‘-Wl’          That kills the
compilation.  I've tried with both gcc48 and gcc49.

This code compiled previously in older version.  I've updated my openSUSE
several times since last compiling but it did compile with some older but
unknown version of gcc.
I don't know what this option does and whether I can delete it.
I though I'd ask experienced people before I deleted it and perhaps going
off astray.

Thank, Tom Kosvic

--
View this message in context: http://gcc.1065356.n5.nabble.com/shared-library-Wl-command-line-option-tp1098667.html
Sent from the gcc - libstdc++ mailing list archive at Nabble.com.

Tim Shen | 3 Dec 18:41 2014
Picon

[Patch, libstdc++/64140] Fix unmatched prefix in regex

Bootstrapped and tested.

Thanks!

-- 
Regards,
Tim Shen
commit 942a5f8e5f4fc4af4f1a18f15b529166e9bdd3ac
Author: timshen <timshen <at> google.com>
Date:   Wed Dec 3 09:36:04 2014 -0800

    	PR libstdc++/64140
    	* include/bits/regex.tcc (regex_iterator<>::operator++): Update
    	prefix.matched after modifying prefix.first.
    	* testsuite/28_regex/iterators/regex_iterator/char/64140.cc: New
    	testcase.

diff --git a/libstdc++-v3/include/bits/regex.tcc b/libstdc++-v3/include/bits/regex.tcc
index 94cbbfa..9692402 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
 <at>  <at>  -569,7 +569,9  <at>  <at>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
 				   | regex_constants::match_continuous))
 		    {
 		      _GLIBCXX_DEBUG_ASSERT(_M_match[0].matched);
-		      _M_match.at(_M_match.size()).first = __prefix_first;
+		      auto& __prefix = _M_match.at(_M_match.size());
+		      __prefix.first = __prefix_first;
(Continue reading)

Kyrill Tkachov | 28 Nov 12:32 2014

How to prune tests that are too large for a tiny memory model in libstdc++?

Hi all,

I'm seeing some relocation truncation failures in the libstdc++ 
testsuite where the test
is too large to fit into the memory model. In the gcc testsuite we mark 
these tests as unsupported
using something like the below fragment in gcc-dg.exp

if { [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $text]
           && [check_effective_target_tiny] } {
         return "::unsupported::memory full"
}

Where would I go about adding similar logic in the libstdc++ tesuite 
.exp files?
I can't find similar pruning infrastructure there...

Thanks,
Kyrill

Luke Allardyce | 24 Nov 11:06 2014
Picon

Should basic_filebuf rely on posix behavior (on Windows)?

Behind the scenes, basic_filebuf uses the posix functions read and
lseek64 to read and seek the file.

This causes an issue on Windows when attempting to seek a text mode
file using a value returned by an earlier call to pubseekoff due to
the way Windows implements the functions.

For files opened in text mode on Windows, read will return the number
of bytes copied to the buffer after converting \r\n to \n (it also
appends an additional \n to the end of the file). _lseeki64 (which is
how mingw-w64 redirects calls to lseek64) however returns the absolute
file position without end of line conversion.

On a call to pubseekoff (i.e. seekoff), basic_filebuf computes the
return value using the remaining characters in the buffer and the file
position as returned by lseek64. For text files on Windows this will
be off by one for each unconsumed newline in the buffer due to the
issue outlined above.

As far as I can make out posix doesn't mention text mode for posix
file descriptors, so I'm assuming the Windows implementation of read
is incorrect as presumably the function should just copy raw bytes;
text / binary file distinction is limited to FILEs and calls to fread
/ fseek / ftell etc..

Even if it were compliant however, this would mean that no end of line
conversion would be performed, which in turn means that basic_filebuf
probably shouldn't be using the posix functions for files opened in
text mode in the first place if intends to support endline conversion
for text files on Windows.
(Continue reading)

François Dumont | 22 Nov 23:15 2014
Picon

Problem with messages test ?

Hello

     I realized that the fr_FR locale was not installed on my system, 
fr_FR.utf8 is but tests are checking exactly for fr_FR. So I installed 
it and test:

22_locale/messages/members/char/2.cc

     is failing. This test rely on some translations files to be 
installed for testing purpose. It looks like they are not anymore. I 
remember that there have been some modifications done to the build 
script, can it explain the regression ? Does anyone can confirm it ?

Thanks

François


Gmane