[Bug libstdc++/63746] i/o fragmentation inside basic_filebuf::xsputn

[pawel_sikora at zoho dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746

--- Comment #8 from Pawel Sikora  ---
hi,

nice to see a final gcc fix.

gl, pawel.

[Bug c/89909] false positive for for -Wunreachable-code.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89909

Pawel Sikora  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Pawel Sikora  ---
(In reply to Andrew Pinski from comment #1)
> I think the warning is correct, the first if (0) will never be executed.

ack, i've missed the line number.

[Bug c/89909] New: false positive for for -Wunreachable-code.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89909

Bug ID: 89909
   Summary: false positive for for -Wunreachable-code.
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

#include 

void foo( int i ) {
char const* j = nullptr;

switch ( i ) {

if ( 0 ) {
case 1:
j = "one";
}
if ( 0 ) {
case 2:
j = "two";
}
{
std::printf( "%s\n", j );
return;
}

default:
std::puts( "unknown" );
};
}

int main() {
foo( 0 );
foo( 1 );
foo( 2 );
foo( 3 );
return 0;
}


// g++ (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
% g++ t.cpp -Wall -Wunreachable-code -o t && ./t
t.cpp: In function ‘void foo(int)’:
t.cpp:8:9: warning: statement will never be executed [-Wswitch-unreachable]
 if ( 0 ) {
 ^~
unknown
one
two
unknown

[Bug c++/83345] c++1z produces an infinite recursion (c++1y works fine).

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83345

--- Comment #2 from Pawel Sikora  ---
(In reply to Jonathan Wakely from comment #1)
> I think that's the expected behaviour in C++17. The return statement in the
> conversion operator no longer constructs an object in C++17, it calls the
> conversion operator again.
> 
> This will fix it:
> 
> operator ref_proxy_t( void )
> {
> return ref_proxy_t( static_cast(*this) );
> }

thanks for clarification. is there any list of such breaking changes for c++17?

[Bug c++/83345] New: c++1z produces an infinite recursion (c++1y works fine).

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83345

Bug ID: 83345
   Summary: c++1z produces an infinite recursion (c++1y works
fine).
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

% g++ bug.cpp -std=c++1y -Wall -Wextra && ./a.out; echo $?
0

% g++ bug.cpp -std=c++1z -Wall -Wextra && ./a.out; echo $?
zsh: segmentation fault (core dumped)  ./a.out
139


% cat bug.cpp 
struct NullType {};

struct ICondition
{
virtual ~ICondition() {}
};

template < class Arg1 = NullType >
struct ConditionRefProxy
{
ConditionRefProxy( const ICondition& ) {}
};

template < class Arg1 = NullType >
struct AndGroup : ICondition
{
typedef ConditionRefProxy< Arg1 > ref_proxy_t;

operator ref_proxy_t( void )
{
return ref_proxy_t( *this );
}

};

int main()
{
typedef AndGroup< NullType > A;
A a;
a.operator A::ref_proxy_t();
}

[Bug libstdc++/83077] New: sso-string @ gnu-versioned-namespace.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077

Bug ID: 83077
   Summary: sso-string @ gnu-versioned-namespace.
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

hi,
i'm using the -std=c++1y and i'd like to use sso-string implementation with
std::__7:: (gnu-versioned-namespace). i don't need a dual-abi. i'd like just a
single-new-abi. afaics in the gcc-7.2.0/libstdc++-v3/acinclude.m4 this isn't
possible.

[Bug c++/78119] wrong diagnostic pointer for -Werror=ignored-qualifiers

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78119

Pawel Sikora  changed:

   What|Removed |Added

  Known to work||7.1.1
  Known to fail||6.3.1

--- Comment #2 from Pawel Sikora  ---
% cat t.cpp 
typedef void* Y;
struct X {
const Y get() const;
};
% ~/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ t.cpp -Wall
-Wextra -c
t.cpp:3:19: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
 const Y get() const;
   ^

[Bug sanitizer/77963] inconsistent (false?) leaks detection.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77963

--- Comment #2 from Pawel Sikora  ---
(In reply to Kostya Serebryany from comment #1)
> lsan does not work with ptrace. 
> There is https://github.com/google/sanitizers/issues/728 for it. 
> We don't have plans to fix it, but the change I sent for review yesterday 
> causes lsan to complain loudly instead of producing false reports. 

this change clarify the situation with shiny message but doesn't help to much
in the real development scenario. under gdb/strace session the process will
terminate with exit code 1 and may breaks application flow due to unexpected
exit code of the child process. in such case i need to setup manually for debug
session the ASAN_OPTIONS=detect_leaks=0 to workaround the lsan die(). it would
be better to omit the die() in such case (no ptrace-available).

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

--- Comment #12 from Pawel Sikora  ---
(In reply to Maxim Ostapenko from comment #11)
> Created attachment 39882 [details]
> Untested fix
> 
> Untested fix (works for me with attached testcase).
> 

this fix works for me. thanks.

[Bug sanitizer/78878] New: stacktrace engine can't use compressed/separated debug info for extracting symbols.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78878

Bug ID: 78878
   Summary: stacktrace engine can't use compressed/separated debug
info for extracting symbols.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
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
  Target Milestone: ---

Created attachment 40384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40384=edit
testcase

hi,

i've noticed that compressed debuginfo (or externally accessible via
.gnu_debuglink section) is not used for decorating sanitizer stacktrace.


e.g.:

=
==6290==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f4d243840ce in operator new(unsigned long)
(/lib64/liblsan.so.0+0xe0ce)
#1 0x400693  (/home/pawels/bugs/mem-leak/m+0x400693)
#2 0x40069f  (/home/pawels/bugs/mem-leak/m+0x40069f)
#3 0x7f4d23728400 in __libc_start_main (/lib64/libc.so.6+0x20400)


without compression/debuglink the stacktrace is more readable:

=
==6318==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7efe533370ce in operator new(unsigned long)
(/lib64/liblsan.so.0+0xe0ce)
#1 0x400693 in leak() /home/pawels/bugs/mem-leak/m.cpp:4
#2 0x40069f in main /home/pawels/bugs/mem-leak/m.cpp:8
#3 0x7efe526db400 in __libc_start_main (/lib64/libc.so.6+0x20400)

[Bug lto/78129] New: -Werror=suggest-final-types leads to -ENOSPC.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129

Bug ID: 78129
   Summary: -Werror=suggest-final-types leads to -ENOSPC.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

the -Werror=suggest-final-types doesn't remove *.ltrans*.o files from /tmp on
linking failure. for tmpfs based /tmp this is a major problem.

[Bug c++/78119] New: wrong diagnostic pointer for -Werror=ignored-qualifiers

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78119

Bug ID: 78119
   Summary: wrong diagnostic pointer for
-Werror=ignored-qualifiers
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

gcc points to the wrong 'const' in error message, e.g.:


error: type qualifiers ignored on function return type
[-Werror=ignored-qualifiers]

 const HMESSAGE YamiReplyMsg::get() const {
^

[Bug middle-end/34212] spurious warning: value computed is not used

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212

Pawel Sikora  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.2.1
 Resolution|--- |FIXED
  Known to fail||

--- Comment #15 from Pawel Sikora  ---
gcc-6.2.1

[Bug tree-optimization/42195] missed xnor optimization.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42195

Pawel Sikora  changed:

   What|Removed |Added

  Known to fail||7.0

--- Comment #2 from Pawel Sikora  ---
bool xnor_1(bool, bool) (bool x, bool y)
{
  bool _3;

  :
  _3 = x_1(D) == y_2(D);
  return _3;

}

bool xnor_2(bool, bool) (bool x, bool y)
{
  bool _1;
  bool _4;

  :
  _1 = ~y_2(D);
  _4 = _1 ^ x_3(D);
  return _4;

}

[Bug plugins/46577] cp-tree.h: c-common.h/hard-reg-set.h needs to be installed into plugin directory.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46577

Pawel Sikora  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Pawel Sikora  ---
comment #1

[Bug c++/52231] [missed optimization/diagnostics] address-of-reference

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231

Pawel Sikora  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.2.1, 7.0
 Resolution|--- |FIXED

--- Comment #8 from Pawel Sikora  ---
s% ~/src/gcc-install/usr/local/bin/g++ pr52231.cpp -c -O2 -Wall -Wextra
-fdump-tree-optimized -fdiagnostics-color=never
pr52231.cpp: In function 'void bar()':
pr52231.cpp:7:17: warning: the compiler can assume that the address of 'a' will
never be NULL [-Waddress]
 if (  == 0 )// <== useless stmt (not diagnosed/not
optimized)
  ~~~^~~~

[Bug other/52609] -Wstrict-aliasing / missed diagnostics

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52609

Pawel Sikora  changed:

   What|Removed |Added

  Known to fail||7.0

--- Comment #5 from Pawel Sikora  ---
still missed diagnostics for bug2():

pr52609.c: In function ‘bug1’:
pr52609.c:6:9: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
 return *(float*)([0]); // warning.
 ^~

[Bug libstdc++/63746] i/o fragmentation inside basic_filebuf::xsputn

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746

Pawel Sikora  changed:

   What|Removed |Added

  Known to fail||4.9.2, 5.4.1, 6.2.1

--- Comment #2 from Pawel Sikora  ---
ping. could you review/apply attached trivial patch?

[Bug c++/54548] unclear error message for ambiguous type lookup.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54548

Pawel Sikora  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||5.4.1
 Resolution|--- |FIXED

--- Comment #1 from Pawel Sikora  ---
pr54548.cpp: In function 'int main()':
pr54548.cpp:6:13: error: expected type-specifier before 'X'
 new X();
 ^

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

--- Comment #9 from Pawel Sikora  ---
(In reply to Maxim Ostapenko from comment #8)

> Hm, perhaps environment issue. What version of Glibc do you use?

glibc-2.23.1-10.fc24.x86_64

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

--- Comment #7 from Pawel Sikora  ---
(In reply to Maxim Ostapenko from comment #6)
> The attached testcase works for me with current trunk GCC:
> 
> max@max:/tmp/bug$ make
> rm -f m *.so
> ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address
> s.cpp -shared -o s.so -fPIC
> ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address
> m.cpp -o m
> max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64 ./m 
> initializing library...
> done.
> thread started.
> max@max:/tmp/bug$ echo $?
> 0


strange, i've tested gcc-trunk and it locks in the same way as 6.2.1.


~/src/gcc-install/usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/pawels/src/gcc-install/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/home/pawels/src/gcc-install/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/pawels/src/gcc/configure --with-arch=x86-64
--with-linker-hash-style=gnu --disable-multilib --disable-nls --disable-libssp
--disable-libgomp --disable-libquadmath --disable-libitm --disable-libcilkrts
--disable-libvtv --disable-liboffloadmic --disable-libmpx --enable-tls
--enable-libstdcxx-allocator=new --enable-extern-template
--enable-libstdcxx-time=rt --enable-libstdcxx-threads
--disable-libstdcxx-dual-abi --enable-libstdcxx-filesystem-ts=no
--enable-symvers=gnu-versioned-namespace --disable-libstdcxx-pch --enable-lto
--enable-plugin --enable-c99 --enable-long-long --enable-linux-futex
--enable-threads=posix --enable-shared --with-pic --enable-gold
--enable-__cxa_atexit --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-checking=release --with-long-double-128
--disable-cld --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161025 (experimental) (GCC) 

~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address
-Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto s.cpp -shared -o
s.so -fPIC -pthread
~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address
-Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto m.cpp -o m -ldl

[pawels@pawels]~/src/bug% ./m
initializing library...
^C

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

--- Comment #4 from Pawel Sikora  ---
(In reply to Pawel Sikora from comment #3)
> (In reply to Kostya Serebryany from comment #2)
> > Is -flto important here?
> > Does this happen with clang? (does not happen for me)
> > Does this happen if you use statically linked asan (-static-libasan)?
> 

> ad2). with static libasan testcase works.

correction (there was a bug in my testing). so, static asan doesn't start.

g++ -fuse-ld=gold -g2 -Og -fsanitize=address -static-libasan s.cpp -shared -o
s.so -fPIC -pthread
g++ -fuse-ld=gold -g2 -Og -fsanitize=address -static-libasan m.cpp -o m -ldl
[pawels@pawels]~/src/bug% ./m
./s.so: undefined symbol: __asan_option_detect_stack_use_after_return

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

--- Comment #3 from Pawel Sikora  ---
(In reply to Kostya Serebryany from comment #2)
> Is -flto important here?
> Does this happen with clang? (does not happen for me)
> Does this happen if you use statically linked asan (-static-libasan)?

ad1). lto isn't important.
ad2). with static libasan testcase works.
ad3). i can't verify with clang on fedora 24 due to linking error:

clang++ -fuse-ld=gold -g2 -O -fsanitize=address s.cpp -shared -o s.so -fPIC
clang++ -fuse-ld=gold -g2 -O -fsanitize=address m.cpp -o m
/usr/bin/ld.gold: error: cannot open
/usr/bin/../lib64/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a: No such file
or directory
/usr/bin/ld.gold: error: cannot open
/usr/bin/../lib64/clang/3.8.0/lib/linux/libclang_rt.asan_cxx-x86_64.a: No such
file or directory
m.cpp:5: error: undefined reference to '__asan_init'
m.cpp:5: error: undefined reference to '__asan_version_mismatch_check_v6'
m.cpp:5: error: undefined reference to '__asan_register_globals'
m.cpp:5: error: undefined reference to '__asan_unregister_globals'

[Bug sanitizer/77982] deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

--- Comment #1 from Pawel Sikora  ---
Created attachment 39842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39842=edit
reduced testcase.

% gdb ./m
GNU gdb (GDB) Fedora 7.11.1-86.fc24


(gdb) r
Starting program: /home/pawels/src/bug/m 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
initializing library...
[New Thread 0x734ff700 (LWP 26786)]
^C
Thread 1 "m" received signal SIGINT, Interrupt.
__sanitizer::internal_sched_yield () at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:304
304 }


(gdb) thread apply all bt

Thread 2 (Thread 0x734ff700 (LWP 26786)):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x75baea76 in __GI___pthread_mutex_lock (mutex=0x77ffd908
<_rtld_local+2312>) at ../nptl/pthread_mutex_lock.c:115
#2  0x77deb6da in tls_get_addr_tail (ti=0x77163b30,
dtv=0x6120bed0, the_map=0x77ff7658) at dl-tls.c:765
#3  0x76e68f4b in __interceptor___tls_get_addr (arg=0x77163b30) at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4207
#4  0x76f21ec4 in __lsan::DisabledInThisThread () at
../../../../libsanitizer/lsan/lsan_common.cc:33
#5  0x76e62815 in __asan::Allocator::Allocate (this=0x77166d20
<__asan::instance>, size=, alignment=,
stack=0x734fe430, alloc_type=, 
can_fill=) at
../../../../libsanitizer/asan/asan_allocator.cc:449
#6  0x76efe1d1 in __interceptor_realloc (ptr=0x0, size=32) at
../../../../libsanitizer/asan/asan_malloc_linux.cc:83
#7  0x75bae035 in pthread_getattr_np (thread_id=,
attr=attr@entry=0x734fed90) at pthread_getattr_np.c:161
#8  0x76f179fd in __sanitizer::GetThreadStackTopAndBottom
(at_initialization=at_initialization@entry=false,
stack_top=stack_top@entry=0x734fee18,
stack_bottom=stack_bottom@entry=0x734fee20)
at ../../../../libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:112
#9  0x76f17f5e in __sanitizer::GetThreadStackAndTls (main=, stk_addr=stk_addr@entry=0x77f88020,
stk_size=stk_size@entry=0x77f88028, tls_addr=tls_addr@entry=0x77f88030, 
tls_size=tls_size@entry=0x734fee70) at
../../../../libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:388
#10 0x76f0b675 in __asan::AsanThread::SetThreadStackAndTls
(this=this@entry=0x77f88000) at
../../../../libsanitizer/asan/asan_thread.cc:197
#11 0x76f0b8a2 in __asan::AsanThread::Init
(this=this@entry=0x77f88000) at
../../../../libsanitizer/asan/asan_thread.cc:153
#12 0x76f0ba68 in __asan::AsanThread::ThreadStart (this=0x77f88000,
os_id=26786, signal_thread_is_registered=0x7fffc428) at
../../../../libsanitizer/asan/asan_thread.cc:166
#13 0x75bac5ca in start_thread (arg=0x734ff700) at
pthread_create.c:333
#14 0x762cff6d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x77fcf780 (LWP 26778)):
#0  __sanitizer::internal_sched_yield () at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:304
#1  0x76e685c5 in __interceptor_pthread_create (thread=0x7fffccb0,
attr=, start_routine=0x77fdbb60 , arg=0x0)
at ../../../../libsanitizer/asan/asan_interceptors.cc:256
#2  0x77fdbc02 in startPolling () at s.cpp:19
#3  0x77de8d8a in call_init (l=, argc=argc@entry=1,
argv=argv@entry=0x7fffdb88, env=env@entry=0x7fffdb98) at dl-init.c:72
#4  0x77de8e9b in call_init (env=0x7fffdb98, argv=0x7fffdb88,
argc=1, l=) at dl-init.c:30
#5  _dl_init (main_map=main_map@entry=0x61a1f280, argc=1,
argv=0x7fffdb88, env=0x7fffdb98) at dl-init.c:120
#6  0x77deda91 in dl_open_worker (a=a@entry=0x7fffcfb0) at
dl-open.c:564
#7  0x77de8c34 in _dl_catch_error
(objname=objname@entry=0x7fffcfa0,
errstring=errstring@entry=0x7fffcfa8,
mallocedp=mallocedp@entry=0x7fffcf9f, 
operate=operate@entry=0x77ded640 ,
args=args@entry=0x7fffcfb0) at dl-error.c:187
#8  0x77decfe9 in _dl_open (file=0x400900 "./s.so", mode=-2147483647,
caller_dlopen=0x76e7e454 <__interceptor_dlopen(char const*, int)+116>,
nsid=-2, argc=, argv=, 
env=0x7fffdb98) at dl-open.c:649
#9  0x75fc9f09 in dlopen_doit (a=a@entry=0x7fffd1e0) at dlopen.c:66
#10 0x77de8c34 in _dl_catch_error (objname=0x773848b0
, errstring=0x773848b8
, mallocedp=0x773848a8
, 
operate=0x75fc9eb0 , args=0x7fffd1e0) at
dl-error.c:187
#11 0x75fca591 in _dlerror_run (operate=operate@entry=0x75fc9eb0
, args=args@entry=0x7fffd1e0) at dlerror.c:163
#12 0x75fc9fa2 in __dlopen (file=, mode=)
at dlopen.c:87
#13 0x76e7e454 in __interceptor_dlopen (filename=0x400900 "./s.so",
flag=1) at

[Bug lto/78034] undefined reference during LTO linking.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78034

--- Comment #5 from Pawel Sikora  ---
(In reply to Andrew Pinski from comment #3)
> Also why are you using inline-asm here?  Why can't you use the SSE
> intrinsics?

it's a 3rd-party crypto library which works for me with gcc-4.9.
now with gcc-6.2 i've disabled this asm magic with -DCRYPTOPP_DISABLE_X86ASM.
case closed :)

[Bug lto/78034] undefined reference during LTO linking.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78034

Pawel Sikora  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Pawel Sikora  ---
sorry, invalid bug. lto is not a problem here.

[Bug lto/78034] New: undefined reference during LTO linking.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78034

Bug ID: 78034
   Summary: undefined reference during LTO linking.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

Created attachment 39834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39834=edit
testcase

% make
rm -f *.o *.a
g++ -m32 -Og -flto -fuse-ld=gold -g0 -march=pentium4 integer.cpp -c
gcc-ar -rv libinteger.a integer.o
/usr/bin/ar: creating libinteger.a
a - integer.o
g++ -m32 -Og -flto -fuse-ld=gold -g0 -march=pentium4 test.cpp -o test -L.
-linteger
/tmp/ccAeSuk8.ltrans0.ltrans.o::function SSE2_Multiply4(unsigned
int*, unsigned int const*, unsigned int const*): error: undefined reference to
'LMul2'
collect2: error: ld returned 1 exit status



the 'LMul2' is an assembly label generated by macro-hell.
without -flto it links fine.

[Bug sanitizer/77982] New: deadlock in asan thread initialization/interception.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982

Bug ID: 77982
   Summary: deadlock in asan thread initialization/interception.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
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
  Target Milestone: ---

hi,

afaics there's a lock scenario in asan initialization code.

my application uses dlopen() to load shared lib which creates a thread at the
global initialization stage (in details, the static version of libusb linked in
a shared lib creates a thread for usb polling). this thread creation is
intercepted by asan and stuck in endless loop:

255├>while (atomic_load(_registered, memory_order_acquire) == 0)
256│   internal_sched_yield();

Thread 1 (Thread 0x7f4aee0937c0 (LWP 17702)):
#0  __sanitizer::internal_sched_yield () at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:304
#1  0x7f4aefafe075 in __interceptor_pthread_create (thread=0x7f4ae0ede718
, attr=, start_routine=0x7f4ae0d17285
, arg=0x0) at ../../../../libsanitizer/as
an/asan_interceptors.cc:256
#2  0x7f4ae0d1734c in my_init () from
/home/pawels/ssd/dvm/gcc-6/cmake-debug-x86_64-gnu-linux/bin64/libhesapi.so
#3  0x7f4af0a77d8a in call_init (l=, argc=argc@entry=2,
argv=argv@entry=0x7ffd27a16478, env=env@entry=0x7ffd27a16490) at dl-init.c:72
#4  0x7f4af0a77e9b in call_init (env=0x7ffd27a16490, argv=0x7ffd27a16478,
argc=2, l=) at dl-init.c:30
#5  _dl_init (main_map=main_map@entry=0x61a14a80, argc=2,
argv=0x7ffd27a16478, env=0x7ffd27a16490) at dl-init.c:120
#6  0x7f4af0a7ca91 in dl_open_worker (a=a@entry=0x7ffd27a13e60) at
dl-open.c:564
#7  0x7f4af0a77c34 in _dl_catch_error
(objname=objname@entry=0x7ffd27a13e50,
errstring=errstring@entry=0x7ffd27a13e58,
mallocedp=mallocedp@entry=0x7ffd27a13e4f, operate=operate@entry=0x7f4af0a7c640
, args=args@entry=0x7ffd27a13e60) at dl-error.c:187
#8  0x7f4af0a7bfe9 in _dl_open (file=0x61006358
"/home/pawels/ssd/dvm/gcc-6/cmake-debug-x86_64-gnu-linux/bin64/libBoardDetector.so",
mode=-2147483391, caller_dlopen=0x7f4aefb12e65 <__interceptor_dlopen(c
har const*, int)+101>, nsid=-2, argc=, argv=,
env=0x7ffd27a16490) at dl-open.c:649
#9  0x7f4aef57df09 in dlopen_doit (a=a@entry=0x7ffd27a14090) at dlopen.c:66
#10 0x7f4af0a77c34 in _dl_catch_error (objname=0x7f4af00131b0
<alloc_memory_for_dlsym+16>, errstring=0x7f4af00131b8
<alloc_memory_for_dlsym+24>, mallocedp=0x7f4af00131a8
<alloc_memory_for_dlsym+8>, operate=0
x7f4aef57deb0 , args=0x7ffd27a14090) at dl-error.c:187
#11 0x7f4aef57e591 in _dlerror_run (operate=operate@entry=0x7f4aef57deb0
, args=args@entry=0x7ffd27a14090) at dlerror.c:163
#12 0x7f4aef57dfa2 in __dlopen (file=, mode=)
at dlopen.c:87
#13 0x7f4aefb12e65 in __interceptor_dlopen (filename=0x61006358
"/home/pawels/ssd/dvm/gcc-6/cmake-debug-x86_64-gnu-linux/bin64/libBoardDetector.so",
flag=flag@entry=257) at ../../../../libsanitizer/sanit
izer_common/sanitizer_common_interceptors.inc:4968
#14 0x7f4af0b7d1e7 in au::system::openLibrary (libname=...) at
../sources/au/auSystemUnix.cpp:69


from the others side, the asan thread initialization stuck on the internal
libc/libdl mutex:

/usr/src/debug/glibc-2.23-81-g2eda04e/elf/dl-tls.c

765├>  __rtld_lock_lock_recursive (GL(dl_load_lock));

[Switching to thread 6 (Thread 0x7f4ae0b6c700 (LWP 17707))]
(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7f4aee823a76 in __GI___pthread_mutex_lock (mutex=0x7f4af0c8c908
<_rtld_local+2312>) at ../nptl/pthread_mutex_lock.c:115
#2  0x7f4af0a7a6da in tls_get_addr_tail (ti=0x7f4aefdf1b78,
dtv=0x61308c50, the_map=0x7f4af0c8a878) at dl-tls.c:765
#3  0x7f4aefafe9cb in __interceptor___tls_get_addr (arg=0x7f4aefdf1b78) at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4207
#4  0x7f4aefbb0b34 in __lsan::DisabledInThisThread () at
../../../../libsanitizer/lsan/lsan_common.cc:33
#5  0x7f4aefaf8515 in __asan::Allocator::Allocate (this=0x7f4aefdf5620
<__asan::instance>, size=, alignment=,
stack=0x7f4ae0b6b430, alloc_type=, can_fill=) at ../../../../libsanitizer/asan/asan_allocator.cc:449
#6  0x7f4aefb8f062 in __interceptor_realloc (ptr=ptr@entry=0x0,
size=size@entry=32) at ../../../../libsanitizer/asan/asan_malloc_linux.cc:83
#7  0x7f4aee823035 in pthread_getattr_np (thread_id=,
attr=attr@entry=0x7f4ae0b6bd70) at pthread_getattr_np.c:161
#8  0x7f4aefba6eed in __sanitizer::GetThreadStackTopAndBottom
(at_initialization=at_initialization@entry=false,
stack_top=stack_top@entry=0x7f4ae0b6bdf0,
stack_bottom=stack_bottom@entry

[Bug sanitizer/77963] New: inconsistent (false?) leaks detection.

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77963

Bug ID: 77963
   Summary: inconsistent (false?) leaks detection.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
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
  Target Milestone: ---

Created attachment 39800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39800=edit
testcase

hi,

i've observed that running application under gdb/ltrace/strace reports strange
memory leaks, e.g:

% make
g++ -Wall -g2 s.cpp -fsanitize=address -Og -shared -fPIC -o s.so -lboost_thread
g++ -Wall -g2 m.cpp -fsanitize=address -Og -o m ./s.so -ldl

[pawels@pawels]~/ssd/leaks% ./m; echo $?
0

[pawels@pawels]~/ssd/leaks% ltrace ./m  
__asan_init(1, 0x7ffddcdce888, 0x7ffddcdce898, 0x7f833ad36540) 
  = 0
__libc_start_main([ "./m" ] 
__asan_init(1, 0x7ffddcdce888, 0x7ffddcdce898, 0) = 0
__asan_version_mismatch_check_v6(1, 0x7ffddcdce888, 0x7ffddcdce898, 0) = 0
__asan_register_globals(0x601080, 2, 0x7ffddcdce898, 0) = 0
dlopen("./s.so", 1) = 0x7f833cbabb18
dlsym(0x7f833cbabb18, "foo") = 0x7f833b7e4d20
dlclose(0x7f833cbabb18) = 0
__asan_unregister_globals(0x601080, 2, 0, 1) = 0x80078140

=
==4777==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 440 byte(s) in 1 object(s) allocated from:
#0 0x7f833baaeea0 in operator new(unsigned long)
(/lib64/libasan.so.3+0xc7ea0)
#1 0x7f833a33a83d in boost::detail::make_external_thread_data()
(/lib64/libboost_thread.so.1.60.0+0x1283d)

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f833baaeea0 in operator new(unsigned long)
(/lib64/libasan.so.3+0xc7ea0)
#1 0x7f833a33a9e9 in boost::detail::make_external_thread_data()
(/lib64/libboost_thread.so.1.60.0+0x129e9)

SUMMARY: AddressSanitizer: 464 byte(s) leaked in 2 allocation(s).
+++ exited (status 1) +++

[Bug libstdc++/77794] New: libstdc++ doesn't bootstrap with ./cofnigure --enable-symvers=gnu-versioned-namespace

[pawel_sikora at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77794

Bug ID: 77794
   Summary: libstdc++ doesn't bootstrap with ./cofnigure
--enable-symvers=gnu-versioned-namespace
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
  Target Milestone: ---

Created attachment 39724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39724=edit
buildlog

hi, the recent 6.2-svn bootstrap fails on libstdc++. compressed buildlog
attached.