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 w
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(con
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
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_p
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?
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
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
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'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465
Oleg Smolsky changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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.
Than
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:
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
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||
|| `[0x02
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 %
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/libsaniti
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...
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.
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
: 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/bugzi
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));
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 happ
: 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
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.
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?
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
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.
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.
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
Prio
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
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
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:iter
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...
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
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
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...
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?
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.
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.
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...
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
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
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
42 matches
Mail list logo
