> -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 for asan interceptors fr
Hi All,
Recent libhwasan updates[1] intercept various string and memory functions.
These functions have checking in them, which means there's no need to
inline the checking.
This patch marks said functions as intercepted, and adjusts a testcase
to handle the difference. It also looks for HWASAN
Hi All,
With recent updates to hwasan runtime libraries, the error reporting for
this particular check is has been reworked.
I would question why it has lost this message. To me it looks strange
that num_descriptions_printed is incremented whenever we call
PrintHeapOrGlobalCandidate whether that
Hi!
On Sat, Jan 27, 2024 at 08:53:42AM +0100, Jakub Jelinek wrote:
> The following testcase ends up with SIGFPE in __divmodbitint4.
> The problem is a thinko in my attempt to implement Knuth's algorithm.
Here is an updated version of the patch, the libgcc part is the same,
but I've added a new te
The following fixes a wrong pattern that didn't match the behavior
of the original fold_widened_comparison in that get_unwidened
returned a constant always in the wider type. But here we're
using (int) 4294967295u without the conversion applied. Fixed
by doing as earlier in the pattern - matching
On Wed, Jan 31, 2024 at 02:17:00PM +, Tamar Christina wrote:
> gcc/ChangeLog:
>
> PR sanitizer/112644
> * asan.h (asan_intercepted_p): Incercept memset, memmove, memcpy and
> memcmp.
> * builtins.cc (expand_builtin): Include HWASAN when checking for
> builtin inli
On Wed, Jan 31, 2024 at 02:18:53PM +, Tamar Christina wrote:
> gcc/testsuite/ChangeLog:
>
> PR sanitizer/112644
> * c-c++-common/hwasan/hwasan-thread-clears-stack.c: Update testcase.
LGTM.
Jakub
On 31/01/2024 13:58, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30 Jan 2024, Andre Vieira wrote:
This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
>
>
> On 31/01/2024 13:58, Richard Biener wrote:
> > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
> >
> >>
> >>
> >> On 31/01/2024 12:13, Richard Biener wrote:
> >>> On Wed, 31 Jan 2024, Richard Biener wrote:
> >>>
> On Tue, 30 Jan 2024,
Richard Biener writes:
> On Wed, Jan 31, 2024 at 4:46 AM Vladimir Mezentsev
> wrote:
>>
>> Hi,
>>
>> I asked in https://sourceware.org/bugzilla/show_bug.cgi?id=31109
>> > I prepared a patch for the releases/gcc-13 branch.
>> > Richard Biener rejected my patch for
>> this branch.
>> > Which
On Wed, Jan 31, 2024 at 01:04:22PM +0100, Richard Biener wrote:
> > Like this, so far just tested on the testcase. Ok for trunk if it passes
> > bootstrap/regtest on top of Jason's patch?
>
> Note we fold all - well, all builtin - calls during gimple lowering.
Internal calls aren't builtin, so t
On 1/31/24 08:55, Richard Biener wrote:
On Wed, Jan 31, 2024 at 2:53 PM Jason Merrill wrote:
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We plan to deprecate -fconcepts-
On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
> On 1/31/24 03:40, Richard Biener wrote:
> > On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
> > >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > We plan to deprecate -fconcepts-t
On 31/01/2024 14:03, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30 Jan 2024, Andre Vieira wrote:
This patch adds stmt
On 1/31/24 13:52, Richard Biener wrote:
On Wed, Jan 31, 2024 at 2:39 PM Jonathan Yong <10wa...@gmail.com> wrote:
Ensure sp variable is long enough by using __UINTPTR_TYPE__ for
rsp.
Attached patch okay? Changes unsigned long to __UINTPTR_TYPE__.
OK.
Thanks, pushed to master branch.
On Tue, Jan 30, 2024 at 06:21:36PM -0800, H.J. Lu wrote:
> Changes in v2:
>
> 1. Check decl non-null before dereferencing it.
> 2. Update PR rtl-optimization/113617 from
Thanks for updating the testcase.
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -7459,16 +7459,46 @@ default_elf_select_rtx
On 31/01/2024 14:35, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 13:58, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
On 31/01/2024 12:13, Richard Biener wrote:
On Wed, 31 Jan 2024, Richard Biener wrote:
On Tue, 30 J
On Wed, Jan 31, 2024 at 8:30 AM Jakub Jelinek wrote:
>
> On Tue, Jan 30, 2024 at 06:21:36PM -0800, H.J. Lu wrote:
> > Changes in v2:
> >
> > 1. Check decl non-null before dereferencing it.
> > 2. Update PR rtl-optimization/113617 from
>
> Thanks for updating the testcase.
>
> > --- a/gcc/varasm.cc
On Wed, Jan 31, 2024 at 08:48:33AM -0800, H.J. Lu wrote:
> Which function (target hook) can I use to generate
>
> .section.data.rel.ro.local,"awG",@progbits,_ZN1AIxE3fooExx,comdat
Just
if (decl)
return get_section (reloc == 1
? ".data.rel.ro.loca
Hi!
On 2018-12-12T11:52:52+, Andrew Stubbs wrote:
> This patch contains the major part of the GCN back-end. [...]
> --- /dev/null
> +++ b/gcc/config/gcn/gcn.h
> +#define FIRST_SGPR_REG 0
> +#define SGPR_REGNO(N)((N)+FIRST_SGPR_REG)
> +#define LAST_SGPR_REG
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here during declaration matching we undesirably consider the two TT{42}
CTAD expressions to be non-equivalent ultimately because for CTAD
placeholder equivalence we compare the TEMPLATE_DECLs (which uses
poin
Thanks!
> Why not just use -latomic unconditionally here?
testsuites of libstdc++ seems to have some tricks to find and link
libatomic.a by using "dg-add-options libatomic", which do nothing for
x86 target. In previous email, we decide not to pollute the current
option, so we add a new libatomic_1
Hi!
On 2018-12-12T11:52:23+, Andrew Stubbs wrote:
> This patch contains the machine description portion of the GCN back-end.
> [...]
> --- /dev/null
> +++ b/gcc/config/gcn/gcn.md
> +;; {{{ Constants and enums
> +
> +; Named registers
> +(define_constants
> + [(FIRST_SGPR_REG0
On 31/01/2024 17:12, Thomas Schwinge wrote:
Hi!
On 2018-12-12T11:52:52+, Andrew Stubbs wrote:
This patch contains the major part of the GCN back-end. [...]
--- /dev/null
+++ b/gcc/config/gcn/gcn.h
+#define FIRST_SGPR_REG 0
+#define SGPR_REGNO(N) ((N)+FIRST_SGPR_REG)
+#defin
avr.cc still had a mix of spaces and TABs for indentation.
This patch uses TABs according to the coding rules.
Applied prior to the creation of the v14 branch so that
master -> v14 back-porting will be easier.
Johann
--
AVR: Tabify avr.cc
gcc/
* config/avr/avr.cc: Tabify.
<>
On Wed, Jan 31, 2024 at 9:10 AM Jakub Jelinek wrote:
>
> On Wed, Jan 31, 2024 at 08:48:33AM -0800, H.J. Lu wrote:
> > Which function (target hook) can I use to generate
> >
> > .section.data.rel.ro.local,"awG",@progbits,_ZN1AIxE3fooExx,comdat
>
> Just
> if (decl)
> return ge
On 31/01/2024 17:21, Thomas Schwinge wrote:
Hi!
On 2018-12-12T11:52:23+, Andrew Stubbs wrote:
This patch contains the machine description portion of the GCN back-end. [...]
--- /dev/null
+++ b/gcc/config/gcn/gcn.md
+;; {{{ Constants and enums
+
+; Named registers
+(define_constants
> Am 31.01.2024 um 16:20 schrieb Jakub Jelinek :
>
> On Wed, Jan 31, 2024 at 01:04:22PM +0100, Richard Biener wrote:
>>> Like this, so far just tested on the testcase. Ok for trunk if it passes
>>> bootstrap/regtest on top of Jason's patch?
>>
>> Note we fold all - well, all builtin - calls
On Tue, Jan 30, 2024 at 06:17:14PM -0800, Andi Kleen wrote:
> - Give error messages for all causes of non sibling call generation
> - Don't override choices of other non sibling call checks with
> must tail. This causes ICEs. The must tail attribute now only
> overrides flag_optimize_sibling_calls
On Wed, Jan 31, 2024 at 09:39:12AM -0800, H.J. Lu wrote:
> GNU binutils has no issues with it:
I know, I meant gcc.
If I try the proposed:
--- gcc/varasm.cc.jj2024-01-30 08:44:43.304175273 +0100
+++ gcc/varasm.cc 2024-01-31 18:45:57.271087170 +0100
@@ -7459,15 +7459,46 @@ default_elf_sel
I replied to bugzilla rather than sending to proper mailing list !
At the same time it looks like you also found the root cause of the
problem Jonathan. Just let me know if you want to deal with it eventually.
François
Forwarded Message
Subject:Re: [Bug libstdc++/90
Hi Prathamesh,
Thanks for the review, I missed that code up above.
I've looking into this and it seems to me at least, that what you have
suggested, is equivalent.
I'll make the change and repost.
Thanks,
Richard
From: Prathamesh Kulkarni
Sent: 30 January 2024 1
When configuring GCC with
--target=TARGET
to build a cross compiler to reproduce a compiler bug, as and collect have
ORIGINAL_AS_FOR_TARGET=""
As the result, many target features are disabled which makes it almost
impossible to reproduce the bug. Without assembler, the GCC build won't
finish a
When configuring GCC with
--target=TARGET
to build a cross compiler to reproduce a compiler bug, as and collect have
ORIGINAL_AS_FOR_TARGET=""
As the result, many target features are disabled which makes it almost
impossible to reproduce the bug. Without assembler, the GCC build won't
finish a
On Wed, Jan 31, 2024 at 07:11:20PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 31, 2024 at 09:39:12AM -0800, H.J. Lu wrote:
> > GNU binutils has no issues with it:
>
> I know, I meant gcc.
> So, it seems get_section handles section purely by name lookup
> and isn't prepared to deal with multiple dif
On 1/31/24 10:55, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We plan to deprecate -fco
Creates new generic vector pipeline file common to all cpu tunes.
Moves all vector related pipelines from generic-ooo to generic-vector-ooo.
Creates new vector crypto related insn reservations.
gcc/ChangeLog:
* config/riscv/generic-ooo.md (generic_ooo): Move reservation
(generic_o
On Wed, Jan 31, 2024 at 02:00:18PM -0500, Jason Merrill wrote:
> On 1/31/24 10:55, Marek Polacek wrote:
> > On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
> > > On 1/31/24 03:40, Richard Biener wrote:
> > > > On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek
> > > > wrote:
> > > > >
On Wed, Jan 31, 2024 at 3:04 PM Rainer Orth
wrote:
>
> Three patches have remained unreviewed for a week or more:
>
> c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html
>
> This one may even be obviou
On 1/31/24 12:12, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here during declaration matching we undesirably consider the two TT{42}
CTAD expressions to be non-equivalent ultimately because for CTAD
placeholder equivalence we co
On 1/31/24 14:07, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 02:00:18PM -0500, Jason Merrill wrote:
On 1/31/24 10:55, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote:
On 1/31/24 03:40, Richard Biener wrote:
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek w
On Wed, Jan 31, 2024 at 2:02 PM Rainer Orth
wrote:
>
> The gcc.target/i386/pr38534-1.c etc. tests FAIL on 32 and 64-bit
> Solaris/x86:
>
> FAIL: gcc.target/i386/pr38534-1.c scan-assembler-not push
> FAIL: gcc.target/i386/pr38534-2.c scan-assembler-not push
> FAIL: gcc.target/i386/pr38534-3.c scan
On Wed, Jan 31, 2024 at 1:57 PM Rainer Orth
wrote:
>
> The gcc.target/i386/no-callee-saved-[12].c tests FAIL on Solaris/x86:
>
> FAIL: gcc.target/i386/no-callee-saved-1.c scan-assembler-not push
> FAIL: gcc.target/i386/no-callee-saved-2.c scan-assembler-not push
>
> In both cases, the test expect
On Wed, Jan 31, 2024 at 10:11 AM Jakub Jelinek wrote:
>
> On Wed, Jan 31, 2024 at 09:39:12AM -0800, H.J. Lu wrote:
> > GNU binutils has no issues with it:
>
> I know, I meant gcc.
> If I try the proposed:
> --- gcc/varasm.cc.jj2024-01-30 08:44:43.304175273 +0100
> +++ gcc/varasm.cc 2024-
On Wed, 24 Jan 2024, Patrick Palka wrote:
> On Wed, 24 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> > > >
> > > > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> > > >
> > > > > On Tue, 23 Jan 2024
Hi Marek,
On 30/01/2024 13:15, Marek Polacek wrote:
> On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote:
> > On 1/25/24 20:36, Marek Polacek wrote:
> > > Better version:
> > >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > Real-world exp
On Tue, Jan 30, 2024 at 06:17:15PM -0800, Andi Kleen wrote:
> This patch implements a clang compatible [[musttail]] attribute for
> returns.
>
> musttail is useful as an alternative to computed goto for interpreters.
> With computed goto the interpreter function usually ends up very big
> which ca
101 - 147 of 147 matches
Mail list logo
