On 11/22/24 5:44 PM, Jakub Jelinek wrote:
Hi!
We aren't the master repository for the sanitizers and clearly upstream
introduces various extensions in the code.
All we care about is whether it builds and works fine with GCC, so
-pedantic flag is of no use to us, only maybe to upstream if they
On Thu, Nov 21, 2024 at 05:21:27PM -0800, Andrew Pinski wrote:
> While compiling libsanitizer for aarch64-linux-gnu, I noticed the new warning:
> ```
> ../../../../libsanitizer/asan/asan_interceptors.cpp: In function ‘char*
> ___interceptor_strcpy(char*, const char*)’:
> ../../../../libsanitizer/a
Jakub Jelinek writes:
> Hi!
>
> When gcc is built with -mbranch-protection=standard, running sanitized
> programs doesn't work properly on bti enabled kernels.
>
> This has been fixed upstream with
> https://github.com/llvm/llvm-project/pull/84061
>
> The following patch cherry picks that from ups
On 4/4/24 14:22, Jakub Jelinek wrote:
> On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote:
>> On 4/4/24 13:38, Ilya Leoshkevich wrote:
>>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>>>
>>>
>>> libsanitizer/ChangeLog:
>>>
>>> * sanitizer_common/sanitizer_lin
On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote:
> On 4/4/24 13:38, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
> >
> >
> > libsanitizer/ChangeLog:
> >
> > * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
> >
On 4/4/24 13:38, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> libsanitizer/ChangeLog:
>
> * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
> Do not mention MSan and DFSan, which are not supported by GCC.
Ok, Thank
Hi Jakub,
> On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
>> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>>
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
>> FAIL: c-c++-
On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
> FAIL: c-c++-common/asan/swapco
Thanks for quick reply!
If it's an inappropriate patch for GCC, should I try to send it to Yocto then?
Alibek.
On Tue, Feb 6, 2024 at 8:53 AM Alibek Omarov wrote:
>
> Some libtool versions require --tag to be set and won't run compiler
> without it, throwing an `unable to infer tagged configuration` error.
>
> I'm not sure whether it's a good idea to tag assembly files as a C source,
> but it helps to avoi
> -Original Message-
> From: Andrew Pinski
> Sent: Monday, January 29, 2024 9:55 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com;
> do...@redhat.com; k...@google.com; dvyu...@google.com
> Subject: Re: [PATCH][libsanitizer]: Sync fixes
On Mon, Jan 29, 2024 at 7:04 AM Tamar Christina wrote:
>
> Hi All,
>
> This cherry-picks and squashes the differences between commits
>
> d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
> from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relev
On Mon, Jan 29, 2024 at 03:03:46PM +, Tamar Christina wrote:
> Hi All,
>
> This cherry-picks and squashes the differences between commits
>
> d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
> from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the chan
On Wed, Jan 17, 2024 at 09:17:09AM +0100, Daniel Cederman wrote:
> On 2024-01-16 15:44, Jakub Jelinek wrote:
> > On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> > > When GCC is configured with --enable-target-optspace the compiler
> > > generates
> > > a memcpy call in the Symbo
On 2024-01-16 15:44, Jakub Jelinek wrote:
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
When GCC is configured with --enable-target-optspace the compiler generates
a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
when compiling for SPARC V8. Add HAVE_AS_
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> When GCC is configured with --enable-target-optspace the compiler generates
> a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
> when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
> call
On 1/2/24 06:56, Andreas Schwab wrote:
All new (tsan) tests are working as expected.
* configure.tgt (riscv64-*-linux*): Enable LSan and TSan.
OK
Jeff
On Tue, Nov 28, 2023 at 02:16:11PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> >>> But will they accept a patch to check a macro never set anywhere in and
> >>> irrelevant to LLVM? That's why I kept all in one patch, to be GCC-local.
> >>
> >> I meant the patch would be gcc local.
> >> But, for lat
Hi Jakub,
>>> But will they accept a patch to check a macro never set anywhere in and
>>> irrelevant to LLVM? That's why I kept all in one patch, to be GCC-local.
>>
>> I meant the patch would be gcc local.
>> But, for later we need only the changes to the imported files be in one
>> commit, not
Hi Jakub,
>> But will they accept a patch to check a macro never set anywhere in and
>> irrelevant to LLVM? That's why I kept all in one patch, to be GCC-local.
>
> I meant the patch would be gcc local.
> But, for later we need only the changes to the imported files be in one
> commit, not others
On Mon, Nov 27, 2023 at 02:20:25PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> >> 2023-11-23 Rainer Orth
> >>
> >>libsanitizer:
> >>PR libsanitizer/112563
> >>* configure.ac (libsanitizer_cv_as_sym_assign): Check for
> >>assembler symbol assignment support.
> >>* configure, c
Hi Jakub,
>> 2023-11-23 Rainer Orth
>>
>> libsanitizer:
>> PR libsanitizer/112563
>> * configure.ac (libsanitizer_cv_as_sym_assign): Check for
>> assembler symbol assignment support.
>> * configure, config.h.in: Regenerate.
>> * sanitizer_common/sanitizer_redefine
On Mon, Nov 27, 2023 at 01:56:46PM +0100, Rainer Orth wrote:
> The recent libsanitizer import broke the build on Solaris/SPARC with the
> native as:
>
> /usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
> "__sanitizer_internal_memset" is used but not defined
> /usr/ccs/bin/as:
> ${target} in there shouldn't be what user specified, but what config.sub
> canonicalized it to.
> And
> ./config.sub x86_64-linux; ./config.sub loongarch64-linux
> x86_64-pc-linux-gnu
> loongarch64-unknown-linux-gnu
> so I really don't see why you want to change it.
OK, I see. Thanks.
Yujie
On Thu, Nov 16, 2023 at 04:01:13PM +0800, Yang Yujie wrote:
> libsanitizer/ChangeLog:
>
> * configure.tgt: allow loongarch64-linux-*.
${target} in there shouldn't be what user specified, but what config.sub
canonicalized it to.
And
./config.sub x86_64-linux; ./config.sub loongarch64-linux
x
On Mon, Aug 07, 2023 at 11:13:10AM +0200, Rainer Orth wrote:
> As detailed in LLVM Issue #57624
> (https://github.com/llvm/llvm-project/issues/57624), a patch to
> sanitizer_internal_defs.h broke SPARC stacktraces in the sanitizers.
> The issue has now been fixed upstream (https://reviews.llvm.org/
On Thu, Apr 27, 2023 at 12:03 AM Martin Liška wrote:
>
> On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> > cherry-pick:
>
> Can you please wait a few days before it? I'm going to merge again
> in the near future after https://reviews.llvm.org/D144073 got handled.
Sure.
> Martin
>
> >
> > 0555
On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> cherry-pick:
Can you please wait a few days before it? I'm going to merge again
in the near future after https://reviews.llvm.org/D144073 got handled.
Martin
>
> 05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
>
> *
On Tue, Jan 31, 2023 at 02:39:54PM -0800, H.J. Lu wrote:
> cherry-pick:
>
> 742bcbf685bc compiler-rt/lib: Add .Linterceptor_sigsetjmp
>
> PR sanitizer/108106
> * hwasan/hwasan_setjmp_x86_64.S (__interceptor_setjmp): Jump
> to .Linterceptor_sigsetjmp instead of __interceptor_sigs
On Fri, Dec 16, 2022 at 01:31:32PM -0800, H.J. Lu via Gcc-patches wrote:
> Add an internal alias to __interceptor_sigsetjmp to avoid R_X86_64_PC32
> relocation for "jmp __interceptor_sigsetjmp" with old assemblers.
I think the patch is ok, but because libsanitizer is just downstream
from sanitizer
On Tue, Jan 17, 2023 at 9:58 AM Rainer Orth
wrote:
>
> When using GNU ld on Solaris, a large number of asan tests SEGV, while
> Solaris ld is fine. This happens inside the __tls_get_addr interceptor,
> which is highly glibc-specific. Therefore this patch disables that
> interceptor.
>
> Posted
Hans-Peter Nilsson 于2023年1月11日周三 08:53写道：
>
> On Fri, 6 Jan 2023, YunQiang Su wrote:
>
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
> > when build libsanitizer in LLVM. Thus
> >FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
> > instead of
> >FIRST_32
On Fri, 6 Jan 2023, YunQiang Su wrote:
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
> when build libsanitizer in LLVM. Thus
>FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
> instead of
>FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
> in
On Tue, Oct 18, 2022 at 11:39:25AM +0200, Florian Weimer via Gcc-patches wrote:
> libsanitizer/
>
> * configure.ac (check for necessary platform features):
I'd use (sanitizer_supported) or (SANITIZER_SUPPORTED) above instead,
that is what is what is being determined by the test.
> In
OK!
Thanks!
在 2022/8/31 下午1:54, Xi Ruoyao 写道:
The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan
On 7/29/22 08:38, Dimitrije Milosevic wrote:
> Thanks Martin! I'm sending out the output from git format-patch as an
> attachment to this email.
You're welcome, pushed as r13-1909-g1efeaf99bd8bdf.
Cheers,
Martin
t: Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from
upstream
On 7/28/22 15:43, Dimitrije Milosevic wrote:
> |Gentle ping, requiring someone to push the change. :)|
Sure, I can do that, but please attach output of (git format-patch) as an
attachment
to an email. The current e
On 7/28/22 15:43, Dimitrije Milosevic wrote:
> |Gentle ping, requiring someone to push the change. :)|
Sure, I can do that, but please attach output of (git format-patch) as an
attachment
to an email. The current email has a weird format I can directly apply with git
am.
Cheers,
Martin
Gentle ping, requiring someone to push the change. :)
From: Dimitrije Milosevic
Sent: Monday, July 25, 2022 8:55 AM
To: gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic ; xry...@xry111.site
Subject: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from
upstream
2bfb0fcb51510f22723
LGTM. Requiring permission to push.
> +const unsigned struct_kernel_stat_sz =
> + SANITIZER_ANDROID
> + ? FIRST_32_SECOND_64(104, 128)
> + : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
These values matches sizeof(struct stat) on gcc230, so should be
correct:
xr
On Fri, Jul 22, 2022 at 11:29 AM Rainer Orth
wrote:
>
> The libsanitizer build has been broken on Solaris 11.3 by the latest
> import. An upstream patch to fix this has now been committed:
>
> [sanitizer_common] Support Solaris < 11.4 in GetStaticTlsBoundary
> https://reviews.llvm
On 7/21/22 12:18, Richard Biener wrote:
> Can you also push this to active branches please?
Sure, I've just done that.
Cheers,
Martin
On Mon, Jul 11, 2022 at 10:05 PM Martin Liška wrote:
>
> I'm going to push the following cherry-pick which fixes libasan
> build with top-of-tree glibc.
Can you also push this to active branches please?
> Martin
>
> 9cf13067cb5088626ba7ee1ec4c42ec59c7995a0 [sanitizer] Remove #include
> to reso
Again, please send patch as plain text.
On Fri, 2022-07-01 at 08:18 +, Dimitrije Milosevic wrote:
> When we use cross toolchains, in which the GCC libraries are not
> installed within a designated system root, the shared sanitizer
> libraries link against libstdc++.so* within the same librarie
On Thu, May 5, 2022 at 2:02 PM H.J. Lu wrote:
>
> cherry-pick:
>
> b226894d475b [sanitizer] [sanitizer] Correct GetTls for x32
> ---
> libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libsanitizer/sanitizer_common/sanitizer_lin
On Thu, May 5, 2022 at 11:28 AM Martin Liška wrote:
>
> On 5/5/22 18:21, H.J. Lu wrote:
> > On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
> >>
> >> On 5/5/22 01:07, H.J. Lu wrote:
> >>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>
> Hello.
>
> I'm going to do mer
On 5/5/22 18:21, H.J. Lu wrote:
> On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>>
>> On 5/5/22 01:07, H.J. Lu wrote:
>>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
Hello.
I'm going to do merge from upstream.
Patch can bootstrap on x86_64-linux-gnu and s
On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>
> On 5/5/22 01:07, H.J. Lu wrote:
> > On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> I'm going to do merge from upstream.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression
> >> tests. I've
On 5/5/22 01:07, H.J. Lu wrote:
> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>>
>> Hello.
>>
>> I'm going to do merge from upstream.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests. I've also tested on ppc64le-linux-gnu and verified the ABI.
>>
>> The onl
On 12/22/21 22:09, Azat Khuzhin via Gcc-patches wrote:
So what is the right way here?
- migrate all tests
- write test only for setbuffer()
- do not add any tests, since they are covered in llvm repo
Hello.
Yes, we don't automatically sync sanitizer tests when we merge from master.
Historicall
On Wed, Dec 22, 2021 at 10:02:02PM +0100, Bernhard Reutner-Fischer wrote:
> You should state how you tested the patch. Please refer to
> https://gcc.gnu.org/contribute.html#testing
I though about this, but when gcc syncs changes with upstream [1], it
does not syncs tests, even though they were the
On Wed, 22 Dec 2021 23:50:39 +0300
Azat Khuzhin wrote:
> Thanks!
you're welcome.
You should state how you tested the patch. Please refer to
https://gcc.gnu.org/contribute.html#testing
thanks,
On Wed, Dec 22, 2021 at 09:41:06PM +0100, Bernhard Reutner-Fischer wrote:
> On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
> wrote:
> >- COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, mode);
> >+ COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, size);
> > REAL(setb
On Wed, Dec 22, 2021 at 09:41:06PM +0100, Bernhard Reutner-Fischer wrote:
> On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
> wrote:
> >Fixes: b667dd7017a ("Libsanitizer merge from trunk r368656.")
> >Refs: https://reviews.llvm.org/D116176
> >---
> > .../sanitizer_common/sanitizer_
On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
wrote:
>Fixes: b667dd7017a ("Libsanitizer merge from trunk r368656.")
>Refs: https://reviews.llvm.org/D116176
>---
> .../sanitizer_common/sanitizer_common_interceptors.inc | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions
On Tue, Nov 30, 2021 at 06:20:09AM -0800, H.J. Lu via Gcc-patches wrote:
> Use SSE, instead of AVX, to save and restore XMM registers to support
> processors without AVX. The affected codes are unused in upstream since
>
> https://github.com/llvm/llvm-project/commit/66d4ce7e26a5
>
> and will be
On Wed, 17 Nov 2021, Jakub Jelinek wrote:
> On Mon, Nov 08, 2021 at 08:50:41AM +0100, Gerald Pfeifer wrote:
> > This is the first part I committed on Friday, the second will
> > follow today.
>
> Here is an alternative to the patch changing a file imported from
> compiler-rt upstream, so that we
On Thu, 4 Nov 2021, H.J. Lu wrote:
>> Ok. But please after committing mention the revision in
>> libsanitizer/LOCAL_PATCHES.
> include and libsanitizer should use 2 separate patches. The
> libsanitizer patch should be in libsanitizer/LOCAL_PATCHES.
Okay, thanks.
This is the first part I commit
On 11/5/21 16:29, Jakub Jelinek wrote:
On Fri, Nov 05, 2021 at 04:25:53PM +0100, Martin Liška wrote:
On 11/5/21 16:22, H.J. Lu wrote:
Should we add __extension__ here?
I tried doing that but it didn't help me with the warning.
Maybe I did something wrong?
Works for me just fine say on:
void
On Fri, Nov 5, 2021 at 8:25 AM Martin Liška wrote:
>
> On 11/5/21 16:22, H.J. Lu wrote:
> > Should we add __extension__ here?
>
> I tried doing that but it didn't help me with the warning.
> Maybe I did something wrong?
[hjl@gnu-cfl-2 tmp]$ cat y.cc
#include
#define uptr uintptr_t
# define GE
On Fri, Nov 05, 2021 at 04:25:53PM +0100, Martin Liška wrote:
> On 11/5/21 16:22, H.J. Lu wrote:
> > Should we add __extension__ here?
>
> I tried doing that but it didn't help me with the warning.
> Maybe I did something wrong?
Works for me just fine say on:
void foo ()
{
int a = ({ int d = 1;
On 11/5/21 16:22, H.J. Lu wrote:
Should we add __extension__ here?
I tried doing that but it didn't help me with the warning.
Maybe I did something wrong?
Cheers,
Martin
On Fri, Nov 5, 2021 at 8:00 AM Martin Liška wrote:
>
> The code uses intentionally braced-groups within expressions:
>
> ({\
Should we add __extension__ here?
>uptr pc;\
>asm("lea 0(%%rip), %0" : "=r"(pc)); \
>
On 11/4/21 13:37, Jakub Jelinek wrote:
On Thu, Nov 04, 2021 at 01:25:43PM +0100, Martin Liška wrote:
diff --git a/libsanitizer/asan/asan_mapping.h b/libsanitizer/asan/asan_mapping.h
index 4b0037fced3..e5a7f2007ae 100644
--- a/libsanitizer/asan/asan_mapping.h
+++ b/libsanitizer/asan/asan_mapping.
On Thu, Nov 04, 2021 at 01:25:43PM +0100, Martin Liška wrote:
> diff --git a/libsanitizer/asan/asan_mapping.h
> b/libsanitizer/asan/asan_mapping.h
> index 4b0037fced3..e5a7f2007ae 100644
> --- a/libsanitizer/asan/asan_mapping.h
> +++ b/libsanitizer/asan/asan_mapping.h
> @@ -165,7 +165,7 @@ static
On Thu, Nov 4, 2021 at 1:20 AM Jakub Jelinek wrote:
>
> On Thu, Nov 04, 2021 at 06:43:26AM +0100, Gerald Pfeifer wrote:
> > On Tue, 2 Nov 2021, H.J. Lu wrote:
> > > On Tue, Nov 2, 2021 at 5:11 AM Jakub Jelinek wrote:
> > >> include/md5.h is a header we have control over, can't we just add to it
>
On Thu, Nov 04, 2021 at 06:43:26AM +0100, Gerald Pfeifer wrote:
> On Tue, 2 Nov 2021, H.J. Lu wrote:
> > On Tue, Nov 2, 2021 at 5:11 AM Jakub Jelinek wrote:
> >> include/md5.h is a header we have control over, can't we just add to it
> >> something like:
> >> #ifdef USE_SYSTEM_MD5
> >> #include_ne
On Tue, 2 Nov 2021, H.J. Lu wrote:
> On Tue, Nov 2, 2021 at 5:11 AM Jakub Jelinek wrote:
>> include/md5.h is a header we have control over, can't we just add to it
>> something like:
>> #ifdef USE_SYSTEM_MD5
>> #include_next
>> #else
>> Current header content
>> #endif
>> and arrange for that mac
On Tue, Nov 2, 2021 at 5:11 AM Jakub Jelinek wrote:
>
> On Tue, Nov 02, 2021 at 05:02:12AM -0700, H.J. Lu wrote:
> > > On Sat, Oct 30, 2021 at 10:54 PM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > sanitizer_platform_limits_freebsd.cpp must include from the OS,
> > > > not include/md5.h i
On Tue, Nov 02, 2021 at 05:02:12AM -0700, H.J. Lu wrote:
> > On Sat, Oct 30, 2021 at 10:54 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > sanitizer_platform_limits_freebsd.cpp must include from the OS,
> > > not include/md5.h in GCC source tree which is included by libbacktrace
> > > support.
On Tue, Nov 2, 2021 at 2:14 AM Richard Biener
wrote:
>
> On Sat, Oct 30, 2021 at 10:54 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > sanitizer_platform_limits_freebsd.cpp must include from the OS,
> > not include/md5.h in GCC source tree which is included by libbacktrace
> > support. Disable libb
On Sat, Oct 30, 2021 at 10:54 PM H.J. Lu via Gcc-patches
wrote:
>
> sanitizer_platform_limits_freebsd.cpp must include from the OS,
> not include/md5.h in GCC source tree which is included by libbacktrace
> support. Disable libbacktrace on sanitizer_platform_limits_freebsd.cpp
> to avoid include
On Wed, Oct 6, 2021 at 11:25 AM H.J. Lu wrote:
>
> commit 9069eb28d45baaa8baf5e3790b03b0e2cc5b49b3
> Author: Igor Tsimbalist
> Date: Fri Nov 17 22:34:50 2017 +0100
>
> Enable building libsanitizer with Intel CET
>
> libsanitizer/
> * acinclude.m4: Add enable.m4 and cet.m4.
>
* Tamar Christina via Gcc-patches:
> Hi All,
>
> libsanitizer: Guard cyclades inclusion in sanitizer
>
> The Linux kernel has removed the interface to cyclades from
> the latest kernel headers[1] due to them being orphaned for the
> past 13 years.
Nit: The commit subject doesn't match the patch b
On Thu, May 20, 2021 at 11:49:03AM +0100, Tamar Christina wrote:
> libsanitizer: Guard cyclades inclusion in sanitizer
>
> The Linux kernel has removed the interface to cyclades from
> the latest kernel headers[1] due to them being orphaned for the
> past 13 years.
>
> libsanitizer uses this head
On Thu, May 13, 2021 at 1:01 PM H.J. Lu wrote:
>
> On Thu, May 13, 2021 at 10:27 AM Martin Liška wrote:
> >
> > On 5/13/21 5:54 PM, H.J. Lu wrote:
> > > On Thu, May 13, 2021 at 09:28:01AM +0200, Martin Liška wrote:
> > >> I'm planning to do merge from master twice a year.
> > >> This merge was te
On Thu, May 13, 2021 at 10:27 AM Martin Liška wrote:
>
> On 5/13/21 5:54 PM, H.J. Lu wrote:
> > On Thu, May 13, 2021 at 09:28:01AM +0200, Martin Liška wrote:
> >> I'm planning to do merge from master twice a year.
> >> This merge was tested on x86_64-linux-gnu and ppc64le-linux-gnu
> >> and surviv
On 5/13/21 5:54 PM, H.J. Lu wrote:
On Thu, May 13, 2021 at 09:28:01AM +0200, Martin Liška wrote:
I'm planning to do merge from master twice a year.
This merge was tested on x86_64-linux-gnu and ppc64le-linux-gnu
and survives regression tests.
Pushed to master.
Thanks,
Martin
Merged revision: f
On Thu, May 13, 2021 at 09:28:01AM +0200, Martin Liška wrote:
> I'm planning to do merge from master twice a year.
> This merge was tested on x86_64-linux-gnu and ppc64le-linux-gnu
> and survives regression tests.
>
> Pushed to master.
> Thanks,
> Martin
>
> Merged revision: f58e0513dd95944b81ce7
On 11/20/20 8:44 AM, Vyacheslav Barinov wrote:
Hello,
Okay, I proposed this check to upstream [1] and it has already been
accepted.
Hello.
Great. Please commit it to the llvm-project upstream and I'll make then
the patch cherry-pick.
We can either apply the fix or postpone it until next syn
Hello,
Okay, I proposed this check to upstream [1] and it has already been
accepted. We can either apply the fix or postpone it until next sync with
upstream.
Anyway the bug doesn't seem so bad if we were the only team who faced it during
all this time.
Best Regards,
Vyacheslav Barinov
[1]: htt
On 11/19/20 12:28 PM, Slava Barinov via Gcc-patches wrote:
Null pointer in path argument leads to SIGSEGV in interceptor.
Hello.
I can't see we ever had the null check in master. I don't this it was lost
during a merge from master.
Why do we need the hunk?
Thanks,
Martin
libsanitizer/Chang
On 10/20/20 10:09 AM, Tobias Burnus wrote:
On 10/19/20 9:39 AM, Tobias Burnus wrote:
Filled as https://bugs.llvm.org/show_bug.cgi?id=47896
That issue was fixed. What's the proper way to apply this patch? Simply
committing the attached patch* or is there more required?
We normally do only a c
On 10/19/20 9:39 AM, Tobias Burnus wrote:
Filled as https://bugs.llvm.org/show_bug.cgi?id=47896
That issue was fixed. What's the proper way to apply this patch? Simply
committing the attached patch* or is there more required?
Tobias
*Namely, from LLVM: git diff 51ff04567b2f8d06b2062bd3ed72eab
On 10/19/20 9:11 AM, Martin Liška wrote:
The change was introduced in the upstream commit:
https://github.com/llvm/llvm-project/commit/5813fca1076089c835de737834955a0fe7eb3898
Please create a LLVM bugzilla entry where you can mention that
Filled as https://bugs.llvm.org/show_bug.cgi?id=47896
On 10/19/20 9:04 AM, Tobias Burnus wrote:
Hi Martin,
Hello.
this patch caused here a build fail:
gcc-mainline/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cpp:490:39:
error: 'NT_X86_XSTATE' was not declared in this scope
It turned out that the used GLIBC of the cross
Hi Jakub,
>> fair enough. What about the gcc-9 branch by then? I expect there will
>> be at least one more release from that one, too?
>
> Ok, but please do it in order (i.e. trunk, then 10+9+8 (if you want 8 too)).
that's been the plan: I want to avoid older releases to have fixes
missing in n
On Thu, Jul 16, 2020 at 10:44:21AM +0200, Rainer Orth wrote:
> Hi Jakub,
>
> >> I may still be mistaken, but all this suggests that Linux might be
> >> playing games with ESP and UESP, while Solaris and NetBSD (see below)
> >> keep them separate, but in the end UESP is the register to use.
> >
> >
Hi Jakub,
>> I may still be mistaken, but all this suggests that Linux might be
>> playing games with ESP and UESP, while Solaris and NetBSD (see below)
>> keep them separate, but in the end UESP is the register to use.
>
> I think what matters more is
> kernel/signal.c and ia32/ia32_signal.c doin
On Wed, Jul 15, 2020 at 03:06:18PM +0200, Rainer Orth wrote:
> I must admit I missed that in that terrible nested maze of #ifdef's
> compiler-rt uses.
>
> > I mean, while the ifndef/define change is guarded by #if SANITIZER_SOLARIS,
> > the last changed line is not. I'm afraid I don't know if
> >
Hi Jakub,
> On Tue, Jul 14, 2020 at 02:32:57PM +0200, Rainer Orth wrote:
>> The latest Solaris 11.4/x86 update uncovered a libsanitizer bug that
>> caused one test to FAIL for 32-bit:
>>
>> +FAIL: c-c++-common/asan/null-deref-1.c -O0 output pattern test
>> +FAIL: c-c++-common/asan/null-deref-1
On Tue, Jul 14, 2020 at 02:32:57PM +0200, Rainer Orth wrote:
> The latest Solaris 11.4/x86 update uncovered a libsanitizer bug that
> caused one test to FAIL for 32-bit:
>
> +FAIL: c-c++-common/asan/null-deref-1.c -O0 output pattern test
> +FAIL: c-c++-common/asan/null-deref-1.c -O1 output p
On Tue, Jun 9, 2020 at 9:16 PM Martin Liška wrote:
>
> On 6/9/20 6:32 PM, Richard Biener wrote:
> > On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
> >>
> >> On 6/8/20 4:53 PM, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> Thank you for the report. It's caused by fact that LLVM switch in
> >>> 4
On 6/9/20 6:32 PM, Richard Biener wrote:
On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
On 6/8/20 4:53 PM, Martin Liška wrote:
Hi.
Thank you for the report. It's caused by fact that LLVM switch in 4d474e078ac7
to c++14. So that I suggest to use gnu++14.
Patch can bootstrap on x86_64-li
On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
>
> On 6/8/20 4:53 PM, Martin Liška wrote:
> > Hi.
> >
> > Thank you for the report. It's caused by fact that LLVM switch in
> > 4d474e078ac7
> > to c++14. So that I suggest to use gnu++14.
> >
> > Patch can bootstrap on x86_64-linux-gnu and sur
On 6/8/20 4:53 PM, Martin Liška wrote:
Hi.
Thank you for the report. It's caused by fact that LLVM switch in 4d474e078ac7
to c++14. So that I suggest to use gnu++14.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I also verified that abidiff is equal for all libsanitizer
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cpp:1880:12: warning:
binary constants are a C++14 feature or GCC extension
1880 | case 0b10'010: // c.lwsp (rd != x0)
|^~~~
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cpp:1880:16: warning:
missing
On 23.01.20 21:09, Jeff Law wrote:
On Wed, 2020-01-22 at 22:23 +0100, Andreas Tobler wrote:
Hi all,
I'm digginig out old patches and I want to complete the libasan support
for FreeBSD x86_64. The below one was not that obvious when you have
been away for the past years.
In the last import the
On 23.01.20 21:09, Jeff Law wrote:
On Wed, 2020-01-22 at 22:23 +0100, Andreas Tobler wrote:
Hi all,
I'm digginig out old patches and I want to complete the libasan support
for FreeBSD x86_64. The below one was not that obvious when you have
been away for the past years.
In the last import the
On Wed, 2020-01-22 at 22:23 +0100, Andreas Tobler wrote:
> Hi all,
>
> I'm digginig out old patches and I want to complete the libasan support
> for FreeBSD x86_64. The below one was not that obvious when you have
> been away for the past years.
>
> In the last import the sanitizer_platform_lim
1 - 100 of 134 matches
Mail list logo
