Hey all, I've just tried building Trunk from branches/google/main/ and
got the following failure in libsanitizer:
In file included from
/mnt/test/rvbd-root-gcc49/usr/include/features.h:356:0,
from /mnt/test/rvbd-root-gcc49/usr/include/arpa/inet.h:22,
from
../
Hey all, this thread started on the libstdc++ list where I asked a
couple of questions about patching std::string for C++11 compliance. I
have figured how to do that and it yields a library that only works in
the C++11 mode. This is not an issue here as we deploy a versioned
runtime into a spec
On 2013-10-01 09:00, Paul Pluzhnikov wrote:
I'll test trunk breakage with --enable-symvers above, and then
attached patch should fix it.
libstdc++-v3/ChangeLog:
2013-10-01 Paul Pluzhnikov
* src/c++11/snprintf_lite.cc: Add missing
_GLIBCXX_{BEGIN,END}_NAMESPACE_VERSION
Thanks. Th
On 2013-10-01 08:49, Paul Pluzhnikov wrote:
I've attached the fill log.
How was this GCC configured?
Hey Paul, thanks for the quick reply. Here is how the final compiler is
configured (it's an intel-to-intel sysroot'd cross-compiler):
../gcc48-google/configure \
--prefix=%{PREFIX} -
Hey all, hey Paul, it looks like the code branches/google/gcc-4_8 does
not compile any more:
../../../../../gcc48-google/libstdc++-v3/src/c++11/snprintf_lite.cc: In
function 'int __gnu_cxx::__concat_size_t(char*, std::size_t, std::size_t)':
../../../../../gcc48-google/libstdc++-v3/src/c++11/snp
Hey all, I've just built gcc 4.8 with
--enable-symvers=gnu-versioned-namespace and compilation of a small test
fails with the following:
In file included from /work/opt/gcc-4.8/include/c++/4.8.0/array:324:0,
from /work/opt/gcc-4.8/include/c++/4.8.0/tuple:39,
fr
Hi, below is a patch for Bug 55028. My tests link now, yet, more symbols
may need to be exposed...
Could someone check please?
Thanks!
Oleg.
--- abi/pre/gnu-versioned-namespace.ver (revision 192953)
+++ abi/pre/gnu-versioned-namespace.ver (working copy)
@@ -116,6 +116,13 @@
_ZN11__gnu_debug19_
On 2012-04-11 01:50, Vincent Lefevre wrote:
On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
Maybe -Wstandard isn't the best name though, as "standard" usually
means something quite specific
Nice work! The only think is that you didn't enable WPO/LTCG on VC++
builds, so that test is a little skewed...
On 2012/1/18 20:35, willus.com wrote:
Hello,
For those who might be interested, I've recently benchmarked gcc 4.6.3
(and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here:
ht
Sure. I've just attached it to the bug.
On 2011/8/24 14:56, Xinliang David Li wrote:
Thanks.
Can you make the test case a standalone preprocessed file (using -E)?
David
On Wed, Aug 24, 2011 at 2:26 PM, Oleg Smolsky wrote:
On 2011/8/24 13:02, Xinliang David Li wrote:
On 2011/8/23
On 2011/8/24 13:02, Xinliang David Li wrote:
On 2011/8/23 11:38, Xinliang David Li wrote:
Partial register stall happens when there is a 32bit register read
followed by a partial register write. In your case, the stall probably
happens in the next iteration when 'add eax, 0Ah' executes, so your
On 2011/8/23 11:38, Xinliang David Li wrote:
Partial register stall happens when there is a 32bit register read
followed by a partial register write. In your case, the stall probably
happens in the next iteration when 'add eax, 0Ah' executes, so your
manual patch does not work. Try change
add a
Hey Andrew,
On 2011/8/22 18:37, Andrew Pinski wrote:
On Mon, Aug 22, 2011 at 6:34 PM, Oleg Smolsky wrote:
On 2011/8/22 18:09, Oleg Smolsky wrote:
Both compilers fully inline the templated function and the emitted code
looks very similar. I am puzzled as to why one of these loops is
On 2011/8/22 18:09, Oleg Smolsky wrote:
Both compilers fully inline the templated function and the emitted
code looks very similar. I am puzzled as to why one of these loops is
significantly slower than the other. I've attached disassembled
listings - perhaps someone could have a look p
or instance set
--param large-function-insns=1
--param large-unit-insns=2
David
On Mon, Aug 1, 2011 at 11:43 AM, Oleg Smolsky wrote:
On 2011/7/29 14:07, Xinliang David Li wrote:
Profiling tools are your best friend here. If you don't have access to
any, the least you can do is to bu
Hi Benjamin,
On 2011/7/30 06:22, Benjamin Redelings I wrote:
I had some performance degradation with 4.6 as well.
However, I was able to cure it by using -finline-limit=800 or 1000 I
think. However, this lead to a code size increase. Were the old
higher-performance binaries larger?
Yes, th
011 at 10:56 AM, Oleg Smolsky
wrote:
Hi there, I have compiled and run a set of C++ benchmarks on a CentOS4/64
box using the following compilers:
a) g++4.1 that is available for this distro (GCC version 4.1.2 20071124
(Red Hat 4.1.2-42)
b) g++4.6 that I built (stock version 4.6.1)
The
17 matches
Mail list logo
