gcc-6-branch test failures: g++ c-c++-common/asan/pr59063-2.c
Good day -
Attempts to build latest GCC gcc-6-branch version from SVN ( Revision
260441 ), with the GCC 6.4.1 from the last time I built it ( git
commit starting '4f2cbe2' ), now fail in 'make check' , on a Linux
x86_64 host (RHEL 7.5, glibc 2.17) :
When 'pr59063-2.c' is built with the '-static-libasan' option and
WITHOUT any '-lasan' option being the first DT_NEEDED shared library,
(ie. being the FIRST -l option)
then the program produced emits the message:
'==$pid==ASan runtime does not come first in initial library list; \
you should either link runtime to your application or manually preload \
it with LD_PRELOAD.
' .
Then all tests that run that program fail.
So, if I modify gcc/testsuite/lib/asan-dg.exp to add '-lasan' as the
first '-l' argument, OR I set libasan to be preloaded, the program loads,
but coredumps, as shown in this gdb session:
Reading symbols from ./pr59063-2.exe...done.
(gdb) b sigaction
Breakpoint 1 at 0x42d800: file
../../.././libsanitizer/asan/asan_interceptors.cc, line 287.
(gdb) b real_sigaction
Breakpoint 2 at 0x4ac710: file
../../.././libsanitizer/asan/asan_interceptors.cc, line 297.
(gdb) c
The program is not being run.
(gdb) run
Starting program: /tmp/pr59063-2.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Breakpoint 2, __sanitizer::real_sigaction (signum=11, act=0x7fffe230,
oldact=0x0) at ../../.././libsanitizer/asan/asan_interceptors.cc:297
297 (struct sigaction *)oldact);
(gdb) n
Breakpoint 1, __interceptor_sigaction (signum=11, act=0x7fffe230,
oldact=0x0) at ../../.././libsanitizer/asan/asan_interceptors.cc:287
287 struct sigaction *oldact) {
(gdb)
288 if (!IsDeadlySignal(signum) ||
common_flags()->allow_user_segv_handler) {
(gdb)
289 return REAL(sigaction)(signum, act, oldact);
(gdb)
292 }
(gdb)
289 return REAL(sigaction)(signum, act, oldact);
(gdb)
292 }
(gdb)
289 return REAL(sigaction)(signum, act, oldact);
(gdb)
0x in ?? ()
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) where
#0 0x in ?? ()
#1 0x004d02a2 in __sanitizer::MaybeInstallSigaction (signum=11,
handler=0x4c6880 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at
../../.././libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:178
#2 0x004d0603 in __sanitizer::InstallDeadlySignalHandlers
(handler=0x4c6880 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at
../../.././libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:187
#3 0x004cd50d in __asan::AsanInitInternal () at
../../.././libsanitizer/asan/asan_rtl.cc:502
#4 0x77de8d83 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#5 0x77dda0ba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0001 in ?? ()
#7 0x7fffe5ab in ?? ()
#8 0x in ?? ()
(gdb)
It appears that the '__interception::PTR_TO_REAL' mechanism
REAL(sigaction) is using to resolve address of sigaction is
being foxed by the fact that libasan.a is statically linked,
AND the libasan.so is also linked to, but hardly any
symbols are resolved to it.
When I remove '-static-libasan', and supply only '-lasan',
in the build command line generated by asan-dg.exp,
the test compiles and runs fine .
I am not using libasan for my project, just trying to build
latest GCC 6.4.1 with latest retpoline backports & bugfixes
into a version that passes its test suite, and I noticed this
problem - this is the main 'unexpected failure' source .
I guess I should class this an 'unexpected but don't care' failure ?
I just thought I should let the GCC developers know .
Thanks & Best Regards,
Jason
'
Re: gcc-6-branch test failures: g++ c-c++-common/asan/pr59063-2.c
To me it looks like the definition of 'real_sigaction'
in 'asan_interceptors.cc' is actually going to
recursively call itself - so I tried patching
libsanitizer:
{BEGIN PATCH:
Index: asan/asan_interceptors.cc
===
--- asan/asan_interceptors.cc (revision 260441)
+++ asan/asan_interceptors.cc (working copy)
@@ -293,8 +293,8 @@
namespace __sanitizer {
int real_sigaction(int signum, const void *act, void *oldact) {
- return REAL(sigaction)(signum, (const struct sigaction *)act,
- (struct sigaction *)oldact);
+ return ::sigaction(signum, (const struct sigaction *)act,
+ (struct sigaction *)oldact);
}
} // namespace __sanitizer
Index: sanitizer_common/sanitizer_common_interceptors.inc
===
--- sanitizer_common/sanitizer_common_interceptors.inc (revision 260441)
+++ sanitizer_common/sanitizer_common_interceptors.inc (working copy)
@@ -2446,7 +2446,7 @@
INTERCEPTOR(uptr, ptrace, int request, int pid, void *addr, void *data) {
void *ctx;
COMMON_INTERCEPTOR_ENTER(ctx, ptrace, request, pid, addr, data);
- __sanitizer_iovec local_iovec;
+ __sanitizer_iovec local_iovec {};
if (data) {
if (request == ptrace_setregs)
END PATCH}
The second patch line removes a warning about local_iovec being
used uninitialized.
With the patch applied, the program does not coredump
and shows more what is going on:
$ ./pr59063-2.exe
==5898==Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING.
==5898==ASan shadow was supposed to be located in the
[0x7fff7000-0x10007fff7fff] range.
==5898==Process memory map follows:
0x0040-0x00522000 /tmp/pr59063-2.exe
0x00721000-0x00723000 /tmp/pr59063-2.exe
0x00723000-0x00726000 /tmp/pr59063-2.exe
0x00726000-0x01398000
0x7fff7000-0x8fff7000
0x8fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
0x6000-0x6400
0x6400-0x64003000
0x7f05baec2000-0x7f05bb566000
0x7f05bb566000-0x7f05bb72f000 /usr/lib64/libc-2.17.so
0x7f05bb72f000-0x7f05bb92f000 /usr/lib64/libc-2.17.so
0x7f05bb92f000-0x7f05bb933000 /usr/lib64/libc-2.17.so
0x7f05bb933000-0x7f05bb935000 /usr/lib64/libc-2.17.so
0x7f05bb935000-0x7f05bb93a000
0x7f05bb93a000-0x7f05bb95
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bb95-0x7f05bbb4f000
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb4f000-0x7f05bbb5
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb5-0x7f05bbb51000
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb51000-0x7f05bbb69000 /usr/lib64/libpthread-2.17.so
0x7f05bbb69000-0x7f05bbd68000 /usr/lib64/libpthread-2.17.so
0x7f05bbd68000-0x7f05bbd69000 /usr/lib64/libpthread-2.17.so
0x7f05bbd69000-0x7f05bbd6a000 /usr/lib64/libpthread-2.17.so
0x7f05bbd6a000-0x7f05bbd6e000
0x7f05bbd6e000-0x7f05bbd7 /usr/lib64/libdl-2.17.so
0x7f05bbd7-0x7f05bbf7 /usr/lib64/libdl-2.17.so
0x7f05bbf7-0x7f05bbf71000 /usr/lib64/libdl-2.17.so
0x7f05bbf71000-0x7f05bbf72000 /usr/lib64/libdl-2.17.so
0x7f05bbf72000-0x7f05bbf79000 /usr/lib64/librt-2.17.so
0x7f05bbf79000-0x7f05bc178000 /usr/lib64/librt-2.17.so
0x7f05bc178000-0x7f05bc179000 /usr/lib64/librt-2.17.so
0x7f05bc179000-0x7f05bc17a000 /usr/lib64/librt-2.17.so
0x7f05bc17a000-0x7f05bc27b000 /usr/lib64/libm-2.17.so
0x7f05bc27b000-0x7f05bc47a000 /usr/lib64/libm-2.17.so
0x7f05bc47a000-0x7f05bc47b000 /usr/lib64/libm-2.17.so
0x7f05bc47b000-0x7f05bc47c000 /usr/lib64/libm-2.17.so
0x7f05bc47c000-0x7f05bc5f6000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc5f6000-0x7f05bc7f6000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc7f6000-0x7f05bc80
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc80-0x7f05bc802000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc802000-0x7f05bc806000
0x7f05bc806000-0x7f05bc92f000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bc92f000-0x7f05bcb2e000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bcb2e000-0x7f05bcb31000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/
Bin Cheng appointed Loop Optimizer co-maintainer
I am pleased to announce that the GCC Steering Committee has appointed Bin Cheng as Loop Optimizer co-maintainer. Please join me in congratulating Bin on his new role. Bin, please update your listing in the MAINTAINERS file. Happy hacking! David
Let's stay in touch!
Welcome http://youpic.com?utm_content=Email&utm_campaign=Email%20marketing&utm_source=SendGrid&utm_term=Email%20marketing&utm_medium=Email Hello YouPic Community! We need your help. Due to the recent tragedy in Manchester, we have decided to bring our community together and show every day life in Manchester. As we all know, photography has a way of telling a great story without words. Whether you are a resident in Manchester or there on vacation, we want to create a photo series "Life in Manchester". We want to show that the world is still standing strong and kindness continues to fill the air. We will choose 20 photos and of course credit each of them. We look forward to seeing your photos. Lets make this happen! Don't forget to hashtag #lovemanchester Deadline: Sunday Take me to YouPic http://youpic.com/?utm_content=Email&utm_campaign=Email%20marketing&utm_source=SendGrid&utm_term=Email%20marketing&utm_medium=Email Sent with ♥ from YouPic Holtermansgatan 1, 41129 Gothenburg, Sweden Unsubscribe https://youpic.com/settings?utm_content=Email&utm_campaign=Email%20marketing&utm_source=SendGrid&utm_term=Email%20marketing&utm_medium=Email
Re: wrong comment in gcc/testsuite/gcc.c-torture/compile/simd-5.c
On 05/02/2018 04:49 AM, Christian Groessler wrote:
> Hi,
>
> --- a/gcc/testsuite/gcc.c-torture/compile/simd-5.c
> +++ b/gcc/testsuite/gcc.c-torture/compile/simd-5.c
> @@ -6,7 +6,7 @@ main(){
> vector64 int a = {1, -1};
> vector64 int b = {2, -2};
> c = -a + b*b*(-1LL);
> -/* c is now {5, 3} */
> +/* c is now {-5, -3} */
Thanks. Fixed.
jeff
Generating gimple assign stmt that changes sign
Hi, I am looking to introduce ABSU_EXPR and that would create: unsigned short res = ABSU_EXPR (short); Note that the argument is signed and result is unsigned. As per the review, I have a match.pd entry to generate this as: (simplify (abs (convert @0)) (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))) (convert (absu @0 Now when gimplifying the converted tree, how do we tell that ABSU_EXPR will take a signed arg and return unsigned. I will have other match.pd entries so this will be generated while in gimple.passes too. Should I add new functions in gimple.[h|c] for this. Is there any examples I can refer to. Conversion expressions seems to be the only place where sign can change in gimple assignment but they are very specific. Thanks, Kugan
Re: Generating gimple assign stmt that changes sign
On 05/21/2018 04:50 PM, Kugan Vivekanandarajah wrote: > Hi, > > I am looking to introduce ABSU_EXPR and that would create: > > unsigned short res = ABSU_EXPR (short); > > Note that the argument is signed and result is unsigned. As per the > review, I have a match.pd entry to generate this as: > (simplify (abs (convert @0)) > (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))) > (convert (absu @0 > > > Now when gimplifying the converted tree, how do we tell that ABSU_EXPR > will take a signed arg and return unsigned. I will have other match.pd > entries so this will be generated while in gimple.passes too. Should I > add new functions in gimple.[h|c] for this. > > Is there any examples I can refer to. Conversion expressions seems to > be the only place where sign can change in gimple assignment but they > are very specific. What's the value in representing ABSU vs a standard ABS followed by a conversion? You'll certainly want to do verification of the type signedness in the gimple verifier. In general the source and destination types have to be the same. Conversions are the obvious exception. There's a few other nodes that have more complex type rules (MEM_REF, COND_EXPR and a few others). But I don't think they're necessarily going to be helpful. jeff
Re: Generating gimple assign stmt that changes sign
Hi Jeff, Thanks for the prompt reply. On 22 May 2018 at 09:10, Jeff Law wrote: > On 05/21/2018 04:50 PM, Kugan Vivekanandarajah wrote: >> Hi, >> >> I am looking to introduce ABSU_EXPR and that would create: >> >> unsigned short res = ABSU_EXPR (short); >> >> Note that the argument is signed and result is unsigned. As per the >> review, I have a match.pd entry to generate this as: >> (simplify (abs (convert @0)) >> (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))) >> (convert (absu @0 >> >> >> Now when gimplifying the converted tree, how do we tell that ABSU_EXPR >> will take a signed arg and return unsigned. I will have other match.pd >> entries so this will be generated while in gimple.passes too. Should I >> add new functions in gimple.[h|c] for this. >> >> Is there any examples I can refer to. Conversion expressions seems to >> be the only place where sign can change in gimple assignment but they >> are very specific. > What's the value in representing ABSU vs a standard ABS followed by a > conversion? It is based on PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946. Specifically, comment 13. > > You'll certainly want to do verification of the type signedness in the > gimple verifier. I am doing it and it is failing now. > > In general the source and destination types have to be the same. > Conversions are the obvious exception. There's a few other nodes that > have more complex type rules (MEM_REF, COND_EXPR and a few others). But > I don't think they're necessarily going to be helpful. Thanks, Kugan > > jeff
Re: Generating gimple assign stmt that changes sign
On Tue, 22 May 2018, Kugan Vivekanandarajah wrote: Hi, I am looking to introduce ABSU_EXPR and that would create: unsigned short res = ABSU_EXPR (short); Note that the argument is signed and result is unsigned. As per the review, I have a match.pd entry to generate this as: (simplify (abs (convert @0)) (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))) (convert (absu @0 Not sure, but we may want a few more restrictions on this transformation. Now when gimplifying the converted tree, how do we tell that ABSU_EXPR will take a signed arg and return unsigned. I will have other match.pd entries so this will be generated while in gimple.passes too. Should I add new functions in gimple.[h|c] for this. Is there any examples I can refer to. Conversion expressions seems to be the only place where sign can change in gimple assignment but they are very specific. You'll probably want to patch genmatch.c (near get_operand_type maybe?) so it doesn't try to guess that the type of absu is the same as its argument. You can also specify a type in transformations, look for :utype or :etype in match.pd. -- Marc Glisse
