Ricardo Telichevesky | 31 Jul 11:04 2014

Compiler warning


     Hope this is the right place to ask this question. Is there any way to set -Wxxxx flags to detect the following situation:

     unsigned int x = 1015625426; // a billion


     size_t numBytes = x * sizeof(double);

... the result is 3830033872 when I should have written instead something like:

        unsigned int x = 1015625426; // a billion


        size_t numBytes = x;
        numBytes *= sizeof(double);

.. that way the result would be the correct 8125003408. I guess that the precision of any particular
operation depends exclusively on its operands, not the left hand side result, the most obvious novice
mistake is writing double oneThird =  1/3 => oneThird gets 0. The problem is I have this type of 
situation all over a large code base, and when compiling for 64 bits would be nice to have a warning like:

warning: potential overflow computing numBytes (64-bit) as a product of two 32-bit unsigned integers...
or anything that remotely resembles it, so I could find where it might happen in the code. I found the
-ftrapv option, would catch the problem at runtime, but I want to fix the problem before I 
run into runtime problems. Also, I guess the same problem might happen (less likely) if you're adding two
32-bit integers or subtracting them... Maybe there is already some option, but I cannot find it.

(Continue reading)

Zifei Tong | 30 Jul 16:42 2014

[PATCH] libstdc++: add _GLIBCXX_ macro prefix in atexit_thread.cc


I found an issue that the __cxa_thread_atexit_impl() function never called by
__cxa_thread_atexit() even with newest glibc which have __cxa_thread_atexit_impl

It turns out that the code tried to use macro HAVE___CXA_THREAD_ATEXIT_IMPL, but
not _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL which is defined in bits/c++config.h
(generated from autoconf scripts).

This patch adds the missing macro prefix.


2014-07-29  Zifei Tong <zifeitong <at> gmail.com>
  * libsupc++/atexit_thread.cc: add _GLIBCXX_ macro prefix

 libstdc++-v3/libsupc++/atexit_thread.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/libsupc++/atexit_thread.cc b/libstdc++-v3/libsupc++/atexit_thread.cc
index db20200..dff08e9 100644
--- a/libstdc++-v3/libsupc++/atexit_thread.cc
+++ b/libstdc++-v3/libsupc++/atexit_thread.cc
 <at>  <at>  -26,7 +26,7  <at>  <at> 
 #include <new>
 #include "bits/gthr.h"

(Continue reading)

Uros Bizjak | 25 Jul 08:51 2014

[PATCH] Update libstdc++ baseline_symbols.txt for alpha-linux


2014-07-25  Uros Bizjak  <ubizjak <at> gmail.com>

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

Tested on alphaev68-linux-gnu and committed to mainline SVN.

Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt
--- config/abi/post/alpha-linux-gnu/baseline_symbols.txt	(revision 213019)
+++ config/abi/post/alpha-linux-gnu/baseline_symbols.txt	(working copy)
 <at>  <at>  -1355,6 +1355,8  <at>  <at> 
 FUNC:_ZNSt11range_errorD0Ev <at>  <at> GLIBCXX_3.4
 FUNC:_ZNSt11range_errorD1Ev <at>  <at> GLIBCXX_3.4
 FUNC:_ZNSt11range_errorD2Ev <at>  <at> GLIBCXX_3.4.15
+FUNC:_ZNSt11regex_errorC1ENSt15regex_constants10error_typeE <at>  <at> GLIBCXX_3.4.20
+FUNC:_ZNSt11regex_errorC2ENSt15regex_constants10error_typeE <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZNSt11regex_errorD0Ev <at>  <at> GLIBCXX_3.4.15
 FUNC:_ZNSt11regex_errorD1Ev <at>  <at> GLIBCXX_3.4.15
 FUNC:_ZNSt11regex_errorD2Ev <at>  <at> GLIBCXX_3.4.15
 <at>  <at>  -2460,6 +2462,7  <at>  <at> 
 FUNC:_ZSt22__throw_overflow_errorPKc <at>  <at> GLIBCXX_3.4
 FUNC:_ZSt23__throw_underflow_errorPKc <at>  <at> GLIBCXX_3.4
 FUNC:_ZSt24__throw_invalid_argumentPKc <at>  <at> GLIBCXX_3.4
+FUNC:_ZSt24__throw_out_of_range_fmtPKcz <at>  <at> GLIBCXX_3.4.20
 FUNC:_ZSt25__throw_bad_function_callv <at>  <at> GLIBCXX_3.4.14
(Continue reading)

Diego Novillo | 24 Jul 14:10 2014

GNU Tools Cauldron 2014 - Slides for presentations

If you made a presentation at this year's Cauldron and are
allowed to share your slides, please add them to the wiki
in the slides and notes section:


If you don't have access to GCC's wiki, you can create your own
user. If that does not work, let me know and I'll upload the
slides for you.

Sessions were recorded on video. We will be publishing them from
the GNU Tools Google+ page when they are available.

Thanks. Diego.

Ed Smith-Rowland | 19 Jul 17:17 2014

Status of C++11 patches...


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?


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

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

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

Saturday, 19th July 2014, 7.30pm to 10.30pm
Murray Edwards College
University of Cambridge
Huntingdon Road
Cambridge CB3 0DF.

Sunday evening, Post Conference Networking

The Regal
38-39 St Andrews Street
Cambridge CB2 3AR

I have updated the wiki with this and other useful local


(Continue reading)

Jonathan Wakely | 14 Jul 16:21 2014

[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

[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

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 
    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)