[Bug c++/114909] False positive diagnostic from -Wdangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909 --- Comment #2 from Oleg Smolsky --- It seems like an unreasonable stretch to connect a `string` temporary to the returned `Json` reference. The types are not related and so that guess looks overly aggressive... The surgical workaround should work, thanks! I hope it does not generate a Clang warning. Let me check that :)
[Bug c++/114909] New: False positive diagnostic from -Wdangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909
Bug ID: 114909
Summary: False positive diagnostic from -Wdangling-reference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oleg at smolsky dot net
Target Milestone: ---
struct string {
string(const char *);
};
struct Json {
int size() const;
};
const Json &fn1(const Json &obj, const string &key);
int Test1(const Json &arg)
{
// warning: possibly dangling reference to a temporary
[-Wdangling-reference]
const Json &jv = fn1(arg, "something");
return jv.size();
}
const Json &fn2(const Json &obj);
int Test2(const Json &arg)
{
// all good
const Json &jv = fn2(arg);
return jv.size();
}
[Bug c++/103499] New: C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
Bug ID: 103499
Summary: C++20 modules error: invalid use of non-static member
function
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oleg at smolsky dot net
Target Milestone: ---
There seems to be a bug when exporting a class hierarchy from a module. Here is
the GCC11 output:
/opt/gcc-11/bin/g++ -std=c++20 -fmodules-ts -c -o main.o main.cpp
main.cpp: In function ‘int main()’:
main.cpp:6:12: error: invalid use of non-static member function ‘virtual
Derived@task::~Derived()’
6 | delete p;
$ cat task.cpp
export module task;
#include "b.h"
#include "d.h"
$ cat b.h
#pragma once
export struct Base {
virtual ~Base() = default;
void DoStuff();
};
$ cat d.h
#include "b.h"
export struct Derived : Base {
~Derived();
};
$ cat main.cpp
import task;
int main() {
auto p = new Derived;
p->DoStuff();
delete p;
}
[Bug libstdc++/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 --- Comment #20 from Oleg Smolsky --- Hey Jonathan, here is the output: Read of size 4 at 0x7d045008 by main thread (mutexes: write M2344, write M132): #0 _M_add_ref_lock /gcc48/include/c++/4.8.x-google/bits/shared_ptr_base.h:236 (exe+0x00d0ae09) #1 my code (a) Previous atomic write of size 4 at 0x7d045008 by thread T21 (mutexes: write M4016): #0 __tsan_atomic32_fetch_add ??:0 (libtsan.so.0+0xd3e5) #1 __exchange_and_add_dispatch /mnt/project/granite/toolchains/elixir/rvbd-gcc48/include/c++/4.8.x-google/ext/atomicity.h:49 (exe+0x003d7738) #2 handle_event() .../gcc48/include/c++/4.8.x-google/bits/shared_ptr_base.h:546 ( this is my code (b) (a) string x = config()->iscsi().dc_initiator().name(); this thing very quickly copies a shared_ptr instance, dereferences it, gets to a sub-object, gets a field and then destructs. (b) is a shared_ptr copy too, but it is obscured by heavy inlining
[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 --- Comment #12 from Oleg Smolsky --- Hey Kostya, should I try suppressing the report using the function name? Would it work in optimized builds that have inlining?
[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #9 from Oleg Smolsky ---
So, let me see if I understand. The case in question is _M_add_ref_lock() :
template<>
inline void
_Sp_counted_base<_S_atomic>::
_M_add_ref_lock()
{
// Perform lock-free add-if-not-zero operation.
_Atomic_word __count = _M_use_count; < the read
do
{
if (__count == 0)
__throw_bad_weak_ptr();
// Replace the current counter value with the old value + 1, as
// long as it's not changed meanwhile.
}
while (!__atomic_compare_exchange_n(&_M_use_count, &__count, __count + 1,
true, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED));
}
The read is flagged by TSan because it is non-atomic. So, it seems that no
amount of recompilation is going to work here... unless the recompiled actually
redefines _Atomic_word to an atomic.
Or am I missing something here?
[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 --- Comment #2 from Oleg Smolsky --- Unfortunately, I cannot repro with Clang (we use gcc48 with sysroot, and I failed to get Clang to latch onto that STL. It only discovers the system's STL) I can try to come up with a minimal test case... Yet, I cannot imagine that the following would ever work with TSan: typedef int _Atomic_word; I imagine, you'd need to "color" reading sites or change the type to std::atomic. Is this right?
[Bug sanitizer/59215] New: tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 Bug ID: 59215 Summary: tsan: warning in shared_ptr_base.h Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: oleg at smolsky dot net CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org I just got what appears to be a false positive in GCC's own implementation of shared_ptr ref counts: Read of size 4 by thread T21: #0 _M_add_ref_lock ...gcc/include/c++/4.8.x-google/bits/shared_ptr_base.h:236 Previous atomic write of size 4 by main thread: #0 __tsan_atomic32_fetch_add ??:0 (libtsan.so.0+0xd3e5) #1 __exchange_and_add_dispatch ...gcc/include/c++/4.8.x-google/ext/atomicity.h:49 The atomic write is obvious - it's an "up ref". The read, however, should have just worked as the variable is (well, is supposed to be) atomic. I don't get it... is the tool missing the atomic manipulation? Or is the library missing the correct annotation? I'm leaning towards the latter: in ...gcc/include/c++/4.8.x-google/x86_64-unknown-linux/bits/atomic_word.h typedef int _Atomic_word; Should this be std::atomic ?
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 Oleg Smolsky changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Oleg Smolsky --- A TSan variant also works when the setrlimit() call is omitted.
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #14 from Oleg Smolsky --- The ASan issue was due to the memory limit applied via setrlimit(). The virtual size (in this -fPIC -pie build) is really huge and so memory allocations were failing. I'll confirm the TSan case in a bit. Thank you Kostya!
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #13 from Oleg Smolsky --- Created attachment 30875 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30875&action=edit another stack ASAN_OPTIONS=malloc_context_size=1 gets me passed the initial issue, but the code gets stuck here: __asan::asan_malloc strerror __sanitizer::MmapFixedOrDie
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #7 from Oleg Smolsky --- Created attachment 30874 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30874&action=edit full stack Here is the full stack. It comes from the very same spot in my app. As for the minimal repro - that's problematic. I extracted the same regex into a minimal program and it works correctly. I am guessing there is something about conditional re-entrancy: __asan::asan_malloc ... strerror ... asan_free ... std::__debug::vector boost::re_detail::basic_char_set
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #11 from Oleg Smolsky --- Sure. The verbose thing does not yield much: ==1236== Parsed ASAN_OPTIONS: verbosity=1 ==1236== AddressSanitizer: libc interceptors initialized || `[0x10007fff8000, 0x7fff]` || HighMem|| || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || || `[0x8fff7000, 0x02008fff6fff]` || ShadowGap || || `[0x7fff8000, 0x8fff6fff]` || LowShadow || || `[0x, 0x7fff7fff]` || LowMem || MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00 0x02008fff6fff red_zone=16 malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 7fff8000 ==1236== Installed the sigaction for signal 11 ==1236== T0: stack [0x7fff22a4,0x7fff2344) size 0xa0; local=0x7fff2343e3bc ==1236== AddressSanitizer Init done
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #9 from Oleg Smolsky --- Hold on, I don't get the "more memory" bit. This happens very early, before anything else of merit. Also, it turns out that this isn't a deadlock, the main thread is spinning inside asan code. USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND osmolsky 54012 69.9 0.1 18253895480 223896 pts/82 R+ 11:35 3:37 dc/dc So, what do you suggest I try?
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #5 from Oleg Smolsky --- BTW, I get an identical deadlock with ASan: #0 0x7fe631504ae9 in syscall () from /lib64/libc.so.6 #1 0x7fe63363ddc0 in __sanitizer::internal_sched_yield () at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_linux.cc:138 #2 0x7fe63362d521 in __sanitizer::StaticSpinMutex::LockSlow (this=this@entry=0x7fe635bb29c0 <__sanitizer::depot>) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_mutex.h:49 #3 0x7fe63363fef4 in Lock (this=0x7fe635bb29c0 <__sanitizer::depot>) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_mutex.h:30 #4 GenericScopedLock (mu=0x7fe635bb29c0 <__sanitizer::depot>, this=) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_mutex.h:83 #5 allocDesc (size=2) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:90 #6 __sanitizer::StackDepotPut (stack=stack@entry=0x7fff79d77100, size=2) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:169 #7 0x7fe63362c3c0 in __asan::Allocate (size=size@entry=49, alignment=, alignment@entry=8, stack=stack@entry=0x7fff79d770f0, alloc_type=alloc_type@entry=__asan::FROM_MALLOC) at ../../../../gcc48-google/libsanitizer/asan/asan_allocator2.cc:386 #8 0x7fe63362cf02 in __asan::asan_malloc (size=size@entry=49, stack=stack@entry=0x7fff79d770f0) at ../../../../gcc48-google/libsanitizer/asan/asan_allocator2.cc:599 #9 0x7fe633638fa3 in __interceptor_malloc (size=49) at ../../../../gcc48-google/libsanitizer/asan/asan_malloc_linux.cc:72 #10 0x7fe63144fdb9 in _nl_make_l10nflist () from /lib64/libc.so.6 #11 0x7fe63144e0c5 in _nl_find_domain () from /lib64/libc.so.6 #12 0x7fe63144d9b0 in __dcigettext () from /lib64/libc.so.6 #13 0x7fe6314a0a38 in strerror_r () from /lib64/libc.so.6 #14 0x7fe6314a093e in strerror () from /lib64/libc.so.6 #15 0x7fe63362ef42 in __interceptor_strerror (errnum=)
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #4 from Oleg Smolsky --- Also, I've just extracted the regex call into a tiny test app and there is no deadlock... so, it is a bit puzzling...
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #3 from Oleg Smolsky --- Hey Kostya, unfortunately I have no way to check that. This happens in our product code I cannot built it with Clang.
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #1 from Oleg Smolsky --- I wonder if I just need to merge this: http://llvm.org/viewvc/llvm-project?view=revision&revision=187978
[Bug sanitizer/58465] New: TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 Bug ID: 58465 Summary: TSan deadlock in a single-threaded program Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: oleg at smolsky dot net CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 30859 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30859&action=edit the full stack Just got a deadlock in a single-theaded program. It appears to be stuck in __tsan::user_realloc that is called from strerror_r, which is intercepted after the initial call to "operator new". The full stack is attached.
[Bug c++/58317] Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317
--- Comment #3 from Oleg Smolsky ---
Also, clang gives a warning:
struct A {
int f() const { return 1000; }
A(int arg) : member(arg) { }
int member;
};
namespace {
int func(const A &a)
{
return a.f();
}
}
int main() {
A a(func(a)); // warning: variable 'a' is uninitialized when used
// within its own initialization
// [-Wuninitialized]
return a.member;
}
[Bug c++/58317] Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317
--- Comment #2 from Oleg Smolsky ---
Hey Jonathan, here is a simpler and more natural way to rewrite your example:
struct A {
static int f() { return 0; }
A(int) { }
};
int main() {
A a(A::f()); // it is static!
}
So, do you happen do have a reference to the Standard? Or is it one of the
things that are not mentioned explicitly?
[Bug c++/58317] New: Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317
Bug ID: 58317
Summary: Calling a method while preparing to call the
constructor should be illegal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oleg at smolsky dot net
struct Thing {
Thing(int);
int f();
};
void test() {
Thing instance(instance.f());
}
The aforementioned code is idiotic and should not compile. Yet it does with gcc
4.8:
/bin/x86_64-unknown-linux-g++ -Wall -c bug.cc
[Bug libstdc++/55028] _GLIBCXX_DEBUG is broken when using v7 namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028 --- Comment #4 from oleg at smolsky dot net 2012-10-30 15:09:49 UTC --- Created attachment 28578 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28578 exports Here is a patch that addresses the issue. IE my tests and apps link now.
[Bug libstdc++/55028] _GLIBCXX_DEBUG is broken when using v7 namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028 --- Comment #3 from oleg at smolsky dot net 2012-10-24 18:36:44 UTC --- Can this be debugged by hacking installed libstdc++ headers? If so, could you point to what needs exporting/testing please?
[Bug c++/55028] New: _GLIBCXX_DEBUG is broken when using v7 namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
Bug #: 55028
Summary: _GLIBCXX_DEBUG is broken when using v7 namespace
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@smolsky.net
I've just hit an issue when using _GLIBCXX_DEBUG together with gcc 4.7.2 built
using --enable-symvers=gnu-versioned-namespace flag. The issue is specific to
unordered_mulimap and can be reproduced using the following:
struct MyType
{
};
#if 1
using MyMap = std::multimap;// works
#else
using MyMap = std::unordered_multimap; // fails to link
#endif
MyMap m;
m.insert({"blah"}, new MyType});
The latter variant fails to link with the following message:
misc/libmisc.a(statmgr.o): In function
`__gnu_debug::_Safe_unordered_container_base::~_Safe_unordered_container_base()':
statmgr.cc:(.text._ZN11__gnu_debug30_Safe_unordered_container_baseD2Ev[_ZN11__gnu_debug30_Safe_unordered_container_baseD5Ev]+0x15):
undefined reference to
`__gnu_debug::_Safe_unordered_container_base::_M_detach_all()'
The compiler was configured as follows:
Configured with: ../gcc-4.7.2/configure --prefix=/opt/gcc-4.7-v7
--enable-languages=c,c++,lto --with-mpfr=/opt/gcc-4.6-rbt
--with-cloog=/opt/gcc-4.6-rbt --with-mpc=/opt/gcc-4.6-rbt
--with-gmp=/opt/gcc-4.6-rbt --with-system-zlib --disable-multilib --enable-lto
--with-build-config=bootstrap-lto --with-fpmath=sse --enable-build-with-cxx
--enable-gold=yes --enable-cloog-backend=isl --disable-cloog-version-check
--enable-symvers=gnu-versioned-namespace CFLAGS=-O3 CXXFLAGS=-O3
Thread model: posix
gcc version 4.7.2 (GCC)
[Bug libstdc++/54259] Regression in move construction for std::pair
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259 --- Comment #3 from oleg at smolsky dot net 2012-08-14 21:09:03 UTC --- Thank you Jonathan. The workaround works on all three compilers and I can move forward.
[Bug libstdc++/54259] Regression in move construction for std::pair
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259 --- Comment #1 from oleg at smolsky dot net 2012-08-14 16:27:35 UTC --- Created attachment 28015 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28015 minimal expressive test case Compiles correctly in g++ 4.6.3, 4.8/Trunk and VS2010/sp1.
[Bug libstdc++/54259] New: Regression in move construction for std::pair
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259 Bug #: 54259 Summary: Regression in move construction for std::pair Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: o...@smolsky.net I've just attempted to move my project from g++ v4.6.3 to v4.7.1 and hit an issue when using move semantics. I have a templated class LockGuard that is move-constructable and not copyable. This is accomplished (in the conventional C++98 way) by making the copy constructor "private". The code creates an instance of std::pair<..., LockGuard<...>> and returns it to the caller. The code compiles and runs on g++ 4.6.3 and VS2010/sp1, yet g++ 4.7.1 emits a bunch of errors (below). The point, as far as I can tell, is that it wants to call the copy constructor which is private. I can fix the issue by explicitly removing the copy constructor: LockGuard(const LockGuard &) = delete; Could someone clarify if this behavior is conforming to the standard? Normally I would not worry about such a thing, but VS2010 does not understand "= delete" specs and the behavior appears to be a breaking change w.r.t. copy constructor invocations... (well, breaking is too strong a word as move constructors and rvalue references are new, but I am sure you see what I mean)
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #39 from oleg at smolsky dot net 2012-03-06 19:39:03 UTC --- Hmm... funky. I can reproduce the issue on a newer Intel machine: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU L5410 @ 2.33GHz stepping: 6 cpu MHz : 2327.445 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 $ time ./test41 real0m6.270s user0m6.268s sys 0m0.000s $ time ./test44 real0m5.524s user0m5.523s sys 0m0.000s $ time ./test46 real0m11.721s user0m11.718s sys 0m0.001s P.S. the middle one is made using g++ (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6). The rest are original binaries made a couple of days ago.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #37 from oleg at smolsky dot net 2012-03-06 16:34:27 UTC --- Hey Jakub, is this smaller example digestable? http://gcc.gnu.org/bugzilla/attachment.cgi?id=26814 The asm output is straightforward, but I obviously have no clue about how complex the corresponding compiler's internal state is...
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #36 from oleg at smolsky dot net 2012-03-03 02:59:11 UTC --- Here is the code emitted by g++ 4.6.3 for smaller_test.cpp (attached to the bug) unsigned int test_constant<> proc near mov r9d, cs:iterations xor r8d, r8d xor eax, eax testr9d, r9d jle short locret_400552 db 66h, 66h, 66h nop db 66h, 66h nop loc_400528: xor ecx, ecx xor edx, edx testesi, esi jle short loc_40054E loc_400530: add edx, 0Ah add dl, [rdi+rcx] add rcx, 1 cmp esi, ecx jg short loc_400530 movsx edx, dl loc_400541: add r8d, 1 add eax, edx cmp r8d, r9d jnz short loc_400528 rep retn loc_40054E: xor edx, edx jmp short loc_400541 locret_400552: rep retn
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #35 from oleg at smolsky dot net 2012-03-03 02:45:15 UTC --- Here is a smaller version. BTW, I've noticed another regression in optimization in v4.1 when using a const global...
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #34 from oleg at smolsky dot net 2012-03-03 02:19:21 UTC --- OK, here are some benchmark numbers for the test compiled verbatim with g++41/g++463 -O2: $ time ./test41 rv=4243767296 real0m6.063s user0m6.058s sys 0m0.001s $ time ./test46 rv=4243767296 real0m11.425s user0m11.415s sys 0m0.003s $ time ./test46-fast #(ie built it with -DFAST_VER) rv=4243767296 real0m11.389s user0m11.383s sys 0m0.003s Let me see how the sample can be digested further down...
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #31 from oleg at smolsky dot net 2012-03-02 08:21:41 UTC --- I don't think there is a need to actually check the result in this benchmarkable fragment, so that will reduce the code a little. The only thing that I was hitting is about fooling/forcing the compiler not to discard the intermediate result and actually perform every calculation and iteration :) Let me try do digest this further. I'll also get you a result from our production compiler (v4.1 that emits the fastest code)
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #29 from oleg at smolsky dot net 2012-03-02 00:54:53 UTC --- Is it possible to target this to 4.7? These optimization issues result in benchmarcably slower code...
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #26 from oleg at smolsky dot net 2012-01-10 18:06:28 UTC --- Could someone toggle the state assign a milestone please?
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #23 from oleg at smolsky dot net 2011-10-24 21:11:21 UTC --- Here is the source preprocessed for gcc47. The test exhibits the slowdown mentioned in comment 11.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #21 from oleg at smolsky dot net 2011-10-24 19:48:57 UTC --- OK, just in case, here is my current test.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #19 from oleg at smolsky dot net 2011-10-24 18:33:23 UTC --- Also note that Bugzilla has quietly replaced an older attachment, test.cpp, with a new one without adding a comment...
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #17 from oleg at smolsky dot net 2011-10-24 18:27:31 UTC --- Created attachment 25595 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25595 test.cpp.144t.optimized --- Comment #18 from oleg at smolsky dot net 2011-10-24 18:27:31 UTC --- Created attachment 25596 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25596 test.s
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #16 from oleg at smolsky dot net 2011-10-24 18:27:28 UTC --- $ /work/tools/gcc47/bin/g++ -v Using built-in specs. COLLECT_GCC=/work/tools/gcc47/bin/g++ COLLECT_LTO_WRAPPER=/work/tools/gcc47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/work/tools/gcc47 --enable-languages=c,c++ --with-system-zlib --with-mpfr=/work/tools/mpfr24 --with-gmp=/work/tools/gmp --with-mpc=/work/tools/mpc LD_LIBRARY_PATH=/work/tools/mpfr/lib24:/work/tools/gmp/lib:/work/tools/mpc/lib Thread model: posix gcc version 4.7.0 20111001 (experimental) (GCC) The test case, test.cpp was compiled with this command: /work/tools/gcc47/bin/g++ -I. -g -O3 -static-libstdc++ -static-libgcc -march=nativetest.cpp -o test
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #13 from oleg at smolsky dot net 2011-09-15 16:53:26 UTC --- David, it looks like we are seeing different things with v4.7... See my comment 11 - I am still observing the slowdown. Do you have access to v4.1 and v4.6? Could you try reproducing my test please?
