Re: thread_local broken in gcc 4.8 ?

[Jakub Jelinek]

On Mon, Jan 06, 2014 at 03:53:13PM +1000, Conrad S wrote:
> According to http://gcc.gnu.org/gcc-4.8/cxx0x_status.html
> the keyword "thread_local" is supported in gcc 4.8 when using -std=c++11

Bugs should be reported to http://gcc.gnu.org/bugzilla/

> file foo.hpp:
> class foo {
>   public:
>   inline  foo() {}
>   inline ~foo() {}
>   inline double bar() { return 123.456; }
>   };
> 
> 
> file a.cpp:
> #include "foo.hpp"
> thread_local foo foo_instance;
> 
> 
> file b.cpp:
> #include "foo.hpp"
> extern thread_local foo foo_instance;
> 
> int main(int argc, char** argv) {
>   double bar = foo_instance.bar();
>   return 0;
>   }

Apparently this got fixed/made latent on the trunk by
http://gcc.gnu.org/r199577 , but it isn't clear if that was an intentional
bugfix somewhere; in any case the patch doesn't look to be backportable.

Wonder if the ctor is really trivial it wouldn't be better to treat it as
not needing dynamic initialization, rather than trying to initialize it
dynamically.

So, please file this into bugzilla.

Jakub

Re: thread_local broken in gcc 4.8 ?

[Conrad S]

On Mon, Jan 6, 2014 at 6:25 PM, Jakub Jelinek  wrote:
> Wonder if the ctor is really trivial it wouldn't be better to treat it as
> not needing dynamic initialization, rather than trying to initialize it
> dynamically.

This is actually a reduced case scenario.
In the original case the constructor is not trivial.

> So, please file this into bugzilla.

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

Re: Finding a relevant place for a custom GCC pass

[Richard Biener]

Sandeep K Chaudhary  wrote:
>Thanks for the reply Marc !
>
>If I place my pass before ccp then I guess I have to implement the
>means to perform calculations on my own so that it can duplicate the
>functionality of ccp, right? I will also look at the source code to
>see if I can modify the source code directly. Is pass_ccp in
>tree-ssa-ccp.c the correct one to look at? Please let me know.

Yes. You want to look at the il before substitute_and_fold together with the 
ccp lattice.

Richard.

>Yes, I have tried the second option you suggested. It's not convenient
>for my purpose.
>
>Thanks and regards,
>Sandeep.
>
>On Sun, Jan 5, 2014 at 10:24 PM, Marc Glisse 
>wrote:
>> On Sun, 5 Jan 2014, Sandeep K Chaudhary wrote:
>>
>>> Hi guys,
>>>
>>> I want to write a pass which can find the calculations performed on
>>> the right hand side of each statement. In the below example -
>>>
>>>VAR1 = 1;
>>>VAR1++;
>>>VAR1 = VAR1 + 5;
>>>
>>> I want to be able to capture the equivalent statements i.e.
>>>
>>> VAR1 = 1;
>>> VAR1 = 2;
>>> VAR1 = 7;
>>>
>>> To achieve this, I dumped various intermediate files using
>>> "-fdump-tree-all'. I looked at all of them manually and found that
>>> either the statements are non-evaluated (during initial stages) or
>>> they are completely optimized, hence losing the intermediate
>>> assignment calculations (during later stages). There is no pass
>which
>>> generates dumps related to the intermediate assignment calculations.
>>>
>>> I am not able to understand where I should aim to place my pass in
>>> order to achieve the above mentioned functionality. Initially, I had
>>> thought of writing IPA pass but I looked at 'copyprop' and
>'forwprop'
>>> dumps and saw that everything is optimized to the last statement. I
>am
>>> not able to understand how a pass should be placed between GIMPLE
>>> stage and later stages so that intermediate calculations such as the
>>> ones mentioned above in the example, can be captured. Please provide
>>> suggestions and help regarding this.
>>
>>
>> Short answer: you can't.
>>
>> You can either have your passe before ccp, and duplicate the
>functionality
>> of ccp, or you can hack the ccp pass to insert your code in it, but I
>doubt
>> there is a suitable plugin hook for that, so you may have to edit
>gcc's
>> source code directly.
>>
>> If you compile with -g and look at debug statements, the information
>is not
>> completely lost after the pass that optimizes this to just VAR1 = 7,
>but it
>> still wouldn't be convenient to use that for your purpose.
>>
>> --
>> Marc Glisse

Re: Remove spam in GCC mailing list

[Ian Lance Taylor]

On Sun, Jan 5, 2014 at 9:10 PM, Christopher Faylor
 wrote:
> On Sat, Dec 28, 2013 at 08:40:07PM +0900, Tae Wong wrote:
>>You want to send a mail to python-dev at python dot org.
>>
>>The spam still exists in gcc-bugs mailing list:
>>
>>There's no reason that the gcc-bugs mailing list can post bug reports 
>>directly.
>>
>>Please delete spam messages from gcc-bugs.
>
> These messages are, AFAIK, pointless.  I'm not aware of anyone working
> as a spam removal service.  I am one of the admins for gcc.gnu.org and I
> sure as @#$* am not paid enough to do this.  I do spend a lot of my time
> trying to make sure that spam doesn't get through and that's the limit
> of what I'm willing to do.
>
> I'd think that a lot of this thread (especially the launchpad part)
> is off-topic for this mailing list.

As Jonathan Wakely suggested, I think that "Tae Wong" is a spammer,
and is adding links to these messages in hopes of boosting their
ranking numbers.  Either that, or he or she is trying to remove these
links because they are now detected as spam and are decreasing the
ranking of the web pages they mention.

Ian

Four times faster printf %e

[Povilas Kanapickas]

Hello,

I have a proof-of-concept implementation of floating-point printf()
which is 4 to 6 times faster than the glibc printf() in common use cases
while producing exactly the same output (including rounding, etc.). I
would like to contribute it to stdlibc++ as an implementation of
floating-point num_put facet.

Contributing this directly to glibc may look like a better idea.
However, in light of this comment in locale_facets.tcc[1] and since my
implementation happens to be in C++, I decided to ask here first.

If you are interested, please read on :-)

The printf() implementation in glibc is comparatively inefficient since
the internal scaling computations are always lossless. In some common
cases only limited precision is enough. Also, since arbitrary precision
library is used and the precision is not known beforehand, there are
very few inlining opportunities.

The approach that I've taken is to perform the computation in fixed
precision that is sufficient to represent usable number of digits (e.g.
96-bits are used for double and 64-bits for float). The computation is
imprecise, which makes correct rounding impossible. Fortunately we can
estimate the upper bound of an error in the final value that we extract
the digits from. Then, if we see that our value is so close to the
rounding boundary that the error is sufficient to affect the rounding
decision, we abort and use the regular, exact printf() instead.

It's easily seen that the above approach is valid only if the requested
precision* is sufficiently small. This issue is solved by checking the
precision and using the libc printf() if it is too large. Fortunately,
most of the time the requested precision is not much larger than
DBL_DECIMAL_DIG, so the faster formatter is still usable.

* - here 'precision' is the total number of sequested significant digits.

Unfortunately the faster formatter can actually be slower in cases when
it detects that it doesn't have enough precision only in the rounding
step. This is solved by using smaller than internal precision in the
initial check. For example, in the current implementation we process
requests with at most 21 digits of precision and assume that the
internal precision is 24 digits. This means that libc printf() is called
in the rounding step only in 0.1% cases, which doesn't impact the
overall performance a lot.

Here is the actual performance comparison on Intel Wolfdale (64bit
mode). The number is number of seconds that the program spent in user
mode. In both cases there were 20m doubles roughly exponentially
distributed in the quoted ranges. The null_* cases are equivalent to the
regular ones except that the call to formatting function is omitted.

* 1e-30 .. 1e30, -1e-30 .. -1e30

 cftime: 4.01
 libc  time: 16.93
 null_cf   time: 0.58
 null_libc time: 1.06

* 1e-300 .. 1e300, -1e-300 .. -1e300

 cftime: 4.37
 libc  time: 26.71
 null_cf   time: 0.59
 null_libc time: 1.02

I've tested 1 billion conversions of positive and negative numbers in
1e-300..1e300 range to verify that the conversion is roughly correct.
There were no failed cases. As far as I see there are no fundamental
problems with the approach, thus even if some failures are detected in
the future, it should be possible to solve them by adjusting the
internal parameters or increasing precision. A throughout mathematical
investigation should be done to verify correctness though.

The code is here: https://github.com/p12tic/floatfmt

The Makefile contains some documentation.

* 'make test' produces speed results
* 'make testout' produces several files for output comparison

I would like to stress that all of this is proof-of-concept. The code is
not pretty or well documented and there are a lot of quirks and bugs
that I didn't bother to fix yet. I've tested only double precision
numbers, only the format "%.17e" and only on 64bit x86 host.

Are stdlibc++ mainainers interested in the idea? The implementation
could be adapted to include a version that uses an arbitrary precision
arithmetic library, so that the dependency on printf() could be removed
entirely along with the support code.

If the answer to the above question is yes, then should I prepare a
patch myself or would someone from the GCC developers adapt my idea?
Please have in mind that I'm new to GCC stdlib development so it may
take some time until I have a patch that satisfies the internal library
standards. It may also take some developers' time too to explain me the
"accepted way of doing things" :-)

Regards,
Povilas

[1]: libstdc++-v3/include/bits/locale_facets.tcc:

// The following code uses vsnprintf (or vsprintf(), when
// _GLIBCXX_USE_C99 is not defined) to convert floating point values
// for insertion into a stream.  An optimization would be to replace
// them with code that works directly on a wide buffer and then use
// __pad to do the padding.  It would be good to replace them anyway
// to gain back the efficiency that C++ provides by knowing u

gcc buildbot?

[Philippe Baril Lecavalier]

Hi,

Is anyone working on an implementation of buildbot 
for GCC?

I have been experimenting with buildbot lately, and I would be glad to
help in providing it. If there is interest, I could have a prototype and
a detailed proposal ready in a few days. It could serve GCC, binutils
and some important libraries as well.

Cheers,

Philippe Baril Lecavalier

Re: Four times faster printf %e

[Jonathan Wakely]

On 6 January 2014 20:54, Povilas Kanapickas wrote:
>
> I have a proof-of-concept implementation of floating-point printf()
> which is 4 to 6 times faster than the glibc printf() in common use cases
> while producing exactly the same output (including rounding, etc.). I
> would like to contribute it to stdlibc++ as an implementation of
> floating-point num_put facet.

Thanks for your interest in contributing to libstdc++ (N.B. it's not
called stdlibc++!)

The project has its own mailing list at libstd...@gcc.gnu.org so if
you want to reach the maintainers you should discuss it on that list.
If you want to contribute then the first step is to read
http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
in particular the legal prerequisites.

Re: Four times faster printf %e

[Povilas Kanapickas]

On 01/06/2014 11:04 PM, Jonathan Wakely wrote:
> On 6 January 2014 20:54, Povilas Kanapickas wrote:
>>
>> I have a proof-of-concept implementation of floating-point printf()
>> which is 4 to 6 times faster than the glibc printf() in common use cases
>> while producing exactly the same output (including rounding, etc.). I
>> would like to contribute it to stdlibc++ as an implementation of
>> floating-point num_put facet.
> 
> Thanks for your interest in contributing to libstdc++ (N.B. it's not
> called stdlibc++!)
> 
> The project has its own mailing list at libstd...@gcc.gnu.org so if
> you want to reach the maintainers you should discuss it on that list.
> If you want to contribute then the first step is to read
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
> in particular the legal prerequisites.
> 

Thanks, I've sent the same email (modulo the stdlibc++ issue :-) ) to
the libstdc++ list.

Regards,
Povilas