Re: Notes of the libgcc-math BOF at the summit.

On Fri, Jun 30, 2006 at 02:57:19PM +0200, Richard Guenther wrote:
>Issues of providing both standard conforming and target optimized
>math runtimes for GCC were discussed.

Thanks for posting this.  Since I wasn't able to attend the summit this
year, I really appreciate seeing summaries like this.

cgf

warning: .../O0g.gch: not used because `__NO_INLINE__' not defined

Hi all, hi Benjamin,

I'm currently seeing this warning during the build:

/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/stdtr1c++.h:30:25: 
warning:

/home/paolo/Gcc/svn-dirs/trunk-build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch: 
not used because `__NO_INLINE__' not defined

any idea what's going wrong?

Besides, likely also related to recent changes to the build system, I'm 
seeing the following kind of errors upon 'make clean' in the v3 build 
dir, it seems 'rm' is attempted on completely unrelated system dirs:

make[1]: Entering directory 
`/home/paolo/Gcc/svn-dirs/trunk-build/i686-pc-linux-gnu/libstdc++-v3/include'
test -z "./i686-pc-linux-gnu/bits/stdc++.h 
./i686-pc-linux-gnu/bits/stdtr1c++.h ./i686-pc-linux-gnu/bits/extc++.h 
/*" || rm -f ./i686-pc-linux-gnu/bits/stdc++.h 
./i686-pc-linux-gnu/bits/stdtr1c++.h ./i686-pc-linux-gnu/bits/extc++.h /*
rm: cannot remove `/bin': Is a directory
rm: cannot remove `/boot': Is a directory
...
(many more, all the system dirs under /)

Paolo.

Re: warning: .../O0g.gch: not used because `__NO_INLINE__' not defined

>
/home/paolo/Gcc/svn-dirs/trunk-build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch: 
> not used because `__NO_INLINE__' not defined
> 
> any idea what's going wrong?

-Winvalid-pch is complaining about this pch, since it is the debug pch
(ie compiled with -O0).  The next pch is selected in this case (the one
with -O2).

I'll turn off -Winvalid pch when building, I guess, and look at the rest of this stuff.

-benjamin

[v3] fix make clean for pch

Ooops. I forgot about the clean rules when doing the multi-pch patch.

tested x86/linux

-benjamin

2006-07-05  Benjamin Kosnik  <bkoz <at> redhat.com>

	* include/Makefile.am (pch_output): New.
	(clean-local): Use it.
	* include/Makefile.in: Regenerate.

Index: include/Makefile.am
===================================================================
--- include/Makefile.am	(revision 115216)
+++ include/Makefile.am	(working copy)
 <at>  <at>  -779,6 +779,7  <at>  <at> 
 pch3_source = ${glibcxx_srcdir}/include/precompiled/extc++.h
 
 pch_input = ${pch1_input} ${pch2_input} ${pch3_input}
+pch_output = ${pch1_output_builddir} ${pch2_output_builddir} ${pch3_output_builddir}
 PCHFLAGS=-Winvalid-pch -Wno-deprecated -x c++-header $(CXXFLAGS)
 if GLIBCXX_BUILD_PCH
 pch_build = ${pch_input}
 <at>  <at>  -1171,8 +1172,12  <at>  <at> 
 	  $(INSTALL_DATA) $$file $(DESTDIR)${pch2_output_installdir}; done
 
 # By adding these files here, automake will remove them for 'make clean'

Re: warning: .../O0g.gch: not used because `__NO_INLINE__' not defined

> -Winvalid-pch is complaining about this pch, since it is the debug pch
> (ie compiled with -O0).  The next pch is selected in this case (the one
> with -O2).

However, this warning is harmless. I don't see how this could trigger a
build failure because even 

make WERROR="-Werror" 

doesn't apply here. If possible, we want to keep -Winvalid-pch in the
flags when creating PCH files. 

The other bit in your message was an omission, now fixed.

-benjamin

Re: warning: .../O0g.gch: not used because `__NO_INLINE__' not defined

Benjamin Kosnik wrote:

>>-Winvalid-pch is complaining about this pch, since it is the debug pch
>>(ie compiled with -O0).  The next pch is selected in this case (the one
>>with -O2).
>>    
>>
>However, this warning is harmless. I don't see how this could trigger a
>build failure because even 
>
>make WERROR="-Werror" 
>
>doesn't apply here. If possible, we want to keep -Winvalid-pch in the
>flags when creating PCH files.
>
Ok with me Benjamin. Out of curiosity, why this problem did not exist 
some time ago? (the warning is of course triggered when doing make 
clean; make and I would have noticed...)

>The other bit in your message was an omission, now fixed.
>  
>
I saw the patch, thanks a lot.

Paolo.

[Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

Hi,

Attached is a patch against the TR1 shared_ptr<> libstdcxx_so_7-branch
that removes the need for the lock in the weak_ptr to shared_ptr
assignment and implements it using an atomic built-in instead.

As a possible solution to the issue of the availability of atomic
operations, I've been discussing the use of an additional boolean
template parameter specifying whether thread safety is needed. This
defaults to false, so existing single-threaded code should compile and
run as usual.

The shared_ptr<T, true> specialisation, however, will only compile if
atomic compare-and-swap is present.

I've also attached a preliminary test case that exercises the changed
section of code using a couple of threads and checking for consistency
of the reference counter. This passes on my SMP x86 system.

I'm not expecting this to be committed yet, I'm mostly after people's
opinions on the following:

1) The template argument approach. If this gets the go-ahead, I plan to
use it in my changes to list<> and the slist<> extension, and in the
other containers, of which I've not created lock-free versions yet. Yes,
it's non-standard, yes, if the standard adds its own template arguments,
we're probably screwed. I don't consider that a likely scenario, though.
What do you think?

2) The test case. Right now, it just tries to provoke potential race

Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

Hi Phillip,

>As a possible solution to the issue of the availability of atomic
>operations, I've been discussing the use of an additional boolean
>template parameter specifying whether thread safety is needed. This
>defaults to false, so existing single-threaded code should compile and
>run as usual.
>  
>
In principle, we could maybe do that for tr1, but I don't think that 
adding template parameters is the way to go, because a conforming 
implementation of a standard facility is not allowed to do that and, 
note, tr1::shared_ptr is already in the draft of C++0x... I would 
suggest hiding it in a base class, or something similar (like we are 
doing for the extension allocators). That is not going to be feasible 
for anything already implemented, part of the current standard, because 
of ABI-issues, of course.

About the more general issue of making good use of all the atomic 
builtins, when available, I don't think we have in place a fully general 
solution. Probably, apart from the "always safe" platforms (i.e., 
powerpc, alpha, ia64, s390), missing compiler support to easily detect 
when the facility is actually available at compile time we have to leave 
the choice to the user who knows what is doing...

Paolo.

Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

Phillip Jordan wrote:

> 2) The test case. Right now, it just tries to provoke potential race
> conditions by running the code in questions as possible in each
> thread.
> This is obviously a stochastic approach an may give false positives.
> I'm
> not aware of any other useful tests to perform to check for thread
> safety, other than maybe formal verification, which doesn't seem to be
> anywhere near mature enough. Tips from the gurus would be appreciated,
> as I need similar, but more complex test cases for the lock-free
> containers.

In addition to your test, you might consider something along the lines of

http://www.boost.org/libs/smart_ptr/test/weak_ptr_mt_test.cpp

It's still a probabilistic approach, but with a slightly better coverage of 
the possible races.

> - Specific to the shared_ptr, I'll probably put back the lock for the
> shared_ptr<T, false> specialisation when __GTHREADS is defined, in
> case
> any existing code relies on it being there. (despite the standard or
> documentation not saying anything about thread safety)

The standard doesn't say anything about thread safety because in its present 
form it has no notion of multiple threads, but tr1::shared_ptr is intended 
to be thread safe. If the next standard is made thread-aware - and this is 
very likely to happen - tr1::shared_ptr will be described as offering the 

Re: [Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

Peter Dimov wrote:

> The standard doesn't say anything about thread safety because in its 
> present form it has no notion of multiple threads, but tr1::shared_ptr 
> is intended to be thread safe. If the next standard is made 
> thread-aware - and this is very likely to happen - tr1::shared_ptr 
> will be described as offering the same level of thread safety as most 
> C++ types (multiple reads to the same instance OK, multiple writes to 
> distinct instances OK.)

Thanks Peter. Therefore, Philip, it seems to me that, given what we 
currently have available from the compiler, a possible design would 
involve a base class adding a three-valued template parameter and 
defaulting to thread-safe and locks (atomics only when 
_GLIBCXX_ATOMIC_BUILTINS).

The same class, would be also usable by itself, and the user would be 
allowed to specify (for performance) thread-unsafe behavior or lockfree 
via the additional template parameter.

Paolo.