"Andre Vieira (lists)" writes:
> [...] The question at hand
> here is, what can the vectorizer use for a specific loop. If we are
> using Advanced SIMD modes then it needs to call an Advanced SIMD clone,
> and if we are using SVE modes then it needs to call an SVE clone. At
> least until we su
> This will run the test only once with -std=c++11. We'll get better coverage
> with dropping the line above and using
>
> /* { dg-do compile { target { tail_call && { c || c++11 } } } } */
>
> but here it may not matter.
The problem is that older C/C++ standards don't support [[]] attributes.
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
>
>
> 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:
> >>>
>
>
>
Sorry again. I just realized you have reverted your patches that's why I can
pass the testing now.
I checkout your latest patch commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
Then I can reproduce the ICE now:
bug.c: In function 'popcount32_uint6
Oh. Sorry. I think I have done the wrong testing with incremental compilation.
With clean trunk, no ICEs now. Just this following FAILs:
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-11.c (test
for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/unop/vfsqrt-run.c (test for e
Maybe I do the wrong testing. Let me use a clean linux environment and try
again.
juzhe.zh...@rivai.ai
From: Edwin Lu
Date: 2024-02-01 14:13
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Robin Dapp; kito.cheng; jeffreyalaw; palmer; vineetg; Patrick O'Neill
Subject: Re: [COMMITTED V3 1/4] RISC-V:
From what I know, if it was a problem with my dfa reservation assert,
it would have ICEd in riscv.cc and not riscv-v.cc. For now I reverted
the changes since I don't want to leave things possibly broken overnight
and not knowing which patch is the root cause. I kicked off another set
of test ru
Hi Juzhe,
I didn't see any ICEs when I tested locally (tested on
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d).
Can you tell me what config you're using?
Edwin
On 1/31/2024 6:57 PM, juzhe.zh...@rivai.ai wrote:
Hi, all.
https://gcc.gnu.org/git/?p=gc
Hi, Monk.
This model doesn't include vector. Will you add vector pipeline in the
followup patches ?
juzhe.zh...@rivai.ai
Add sifive p600 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p650-670.
Add sifive-p650, sifive-p670 for mcpu option will come in separate patches.
gcc/ChangeLog:
* config/riscv/riscv.md: Add "fcvt_i2f", "fcvt_f2i" type
attribute, and in
Thanks, I will push a V2 patch, to fix the typo and add a vector cost model
for p600 series.
About block the div units, I decided to use your suggestion. The P600
series
divider is 4 bits per cycle. So blocking 3-5 cycles is enough.
On Thu, Feb 1, 2024 at 9:50 AM Edwin Lu wrote:
> I recently c
Hi, all.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707
https://gcc.gnu.org/gi
On 1/31/24 15:56, Marek Polacek wrote:
On Wed, Jan 31, 2024 at 02:57:09PM -0500, Jason Merrill wrote:
On 1/31/24 14:44, Alex Coplan wrote:
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:
On 1/31/24 16:03, Patrick Palka wrote:
On Wed, 31 Jan 2024, Jason Merrill wrote:
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 expres
On 1/31/24 18:41, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13/12?
OK.
-- >8 --
We crash in the loop at the end of treat_lvalue_as_rvalue_p for code
like
template
concept Throwable = requires(T x) { throw x; };
because the code assumes that we e
On 1/31/24 21:09, Lewis Hyatt wrote:
On Wed, Jan 31, 2024 at 03:18:01PM -0500, Jason Merrill wrote:
On 1/30/24 21:49, Lewis Hyatt wrote:
On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote:
On 12/5/23 20:52, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105
On Wed, Jan 31, 2024 at 03:18:01PM -0500, Jason Merrill wrote:
> On 1/30/24 21:49, Lewis Hyatt wrote:
> > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote:
> > > On 12/5/23 20:52, Lewis Hyatt wrote:
> > > > Hello-
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
> >
I recently committed changes modifying the scheduling reservations. Some
things may need to be retested with the newly enabled asserts.
Edwin
On 1/31/2024 1:40 AM, Monk Chiang wrote:
Add sifive p600 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p650
On 1/31/2024 12:28 PM, Robin Dapp wrote:
LGTM, thanks.
Regards
Robin
Committed!
Edwin
On 1/25/2024 9:06 AM, Robin Dapp wrote:
/* If we ever encounter an insn without an insn reservation, trip
an assert so we can find and fix this problem. */
-#if 0
+ if (! insn_has_dfa_reservation_p (insn)) {
+print_rtl(stderr, insn);
+fprintf(stderr, "%d", get_attr_type (insn
On 1/25/2024 9:06 AM, Robin Dapp wrote:
Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series
On 1/25/2024 9:06 AM, Robin Dapp wrote:
LGTM, thanks.
Regards
Robin
Committed!
Edwin
On Tue, Jan 30, 2024 at 11:26 PM Kito Cheng wrote:
>
> I realized there is 's' constraint which is defined in GCC generic
> infra[1], and that's kinda what same as the new semantic of 'S' here,
>
> (define_constraint "s"
> "Matches a symbolic integer constant."
> (and (match_test "CONSTANT_P (op
After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return
NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes,
using TImode causes simplify_gen_subreg to return NULL.
This fixes the issue by using DImode instead for the loop. And then we will have
later on the STP/LDP pa
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13/12?
-- >8 --
We crash in the loop at the end of treat_lvalue_as_rvalue_p for code
like
template
concept Throwable = requires(T x) { throw x; };
because the code assumes that we eventually reach sk_function_parms or
sk_try and ba
On Wed, 31 Jan 2024 at 18:18, François Dumont wrote:
> 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.
>
I'll take care of it, t
PR analyzer/113253 reports a case where the analyzer output varied
with and without -g enabled.
The root cause was that debug stmts were in the
FOR_EACH_IMM_USE_FAST list for SSA names, leading to the analyzer's
state purging logic differing between the -g and non-debugging cases,
and thus leading
On 1/31/24 4:43 PM, Vincenzo Palazzo wrote:
> This commit is specifically targeting enhancements in
> Nix support for GCC development. This initiative stems
> from the recognized need within our community for a more
> streamlined and efficient development process when using Nix.
>
> Please not tha
On Wed, 31 Jan 2024 at 19:41, Patrick Palka wrote:
>
> On Wed, 31 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Patrick Palka wrote:
> > >
> > > In v2:
> > >
> > > * Named the template parameters of the forward declaration of pair.
> > > * Added dangling checks for the new tuple and pa
On Wed, 31 Jan 2024, Jakub Jelinek wrote:
> On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote:
> > > > + case RID_RETURN:
> > > > + {
> > > > + bool musttail_p = false;
> > > > + std_attrs = process_stmt_hotness_attribute (std_attrs,
> > > > attrs_loc);
This commit is specifically targeting enhancements in
Nix support for GCC development. This initiative stems
from the recognized need within our community for a more
streamlined and efficient development process when using Nix.
Please not that in this case the Nix tool is used to define
what shoul
Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.
The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL. Avo
I am writing to submit a revision of a patch for consideration to be included
in the mainline GCC repository discussed in [1].
The only change is that this include the following suggestion [2]
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639235.html
[2] https://gcc.gnu.org/piperma
On Wed, 31 Jan 2024, Patrick Palka wrote:
> On Wed, 31 Jan 2024, Jason Merrill wrote:
>
> > 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 und
On Wed, 31 Jan 2024, Jason Merrill wrote:
> 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 n
On Wed, Jan 31, 2024 at 02:57:09PM -0500, Jason Merrill wrote:
> On 1/31/24 14:44, Alex Coplan wrote:
> > 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
On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote:
> 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
Richard Ball writes:
> 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.
The original patch is OK. Checking in the other loop is too early,
Andrew Pinski writes:
> After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return
> NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes,
> using TImode causes simplify_gen_subreg to return NULL.
> This fixes the issue by using DImode instead for the loop. And then we wi
Szabolcs Nagy writes:
> Use aarch64-asm.h in asm code consistently, this was started in
>
> commit c608ada288ced0268c1fd4136f56c34b24d4
> Author: Zac Walker
> CommitDate: 2024-01-23 15:32:30 +
>
> Ifdef `.hidden`, `.type`, and `.size` pseudo-ops for `aarch64-w64-mingw32`
> ta
On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote:
> > > + case RID_RETURN:
> > > + {
> > > + bool musttail_p = false;
> > > + std_attrs = process_stmt_hotness_attribute (std_attrs, attrs_loc);
> > > + if (lookup_attribute ("", "musttail", std_attrs))
> > > + {
> > > +
LGTM, thanks.
Regards
Robin
On Wed, Jan 31, 2024 at 12:16:59PM -0800, Andi Kleen wrote:
> > This results in "error: cannot tail-call: cannot tail-call: other reasons".
> > So the second argument should be "other reasons" only.
>
> Yes will fix those. Thanks.
>
> >
> > I notice that if I don't use -O2 I also get "other reas
> > For compatibility it also detects clang::musttail
>
> FWIW, it's not clear to me we should do this. I don't see a precedent.
It would make existing code just work (as long as they don't use ifdef)
>
> > One problem is that tree-tailcall usually fails when optimization
> > is disabled, whic
On 1/30/24 21:49, Lewis Hyatt wrote:
On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote:
On 12/5/23 20:52, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
There are two related issues here really, a regression since GCC 11 where we
can ICE after restor
> This results in "error: cannot tail-call: cannot tail-call: other reasons".
> So the second argument should be "other reasons" only.
Yes will fix those. Thanks.
>
> I notice that if I don't use -O2 I also get "other reasons". But it should be
> easy-ish to say "cannot tail-call: optimizations
On Tue, Jan 30, 2024 at 06:17:17PM -0800, Andi Kleen wrote:
> Mostly adopted from the existing C musttail plugin tests.
Please add a ChangeLog entry.
> ---
> gcc/testsuite/c-c++-common/musttail1.c | 17
> gcc/testsuite/c-c++-common/musttail2.c | 36 +
> gcc
On 1/31/24 14:44, Alex Coplan wrote:
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
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 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
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, 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 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 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 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 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 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:
> > > > >
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 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
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
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
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
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
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
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
> 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 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
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
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 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
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
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
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
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
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
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 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 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 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 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 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 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 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
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, 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,
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, 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 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
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
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
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 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
> -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
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 s
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 obvious.
testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-
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 sure the
> >>> ta
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-ts in GCC 15 an
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.
1 - 100 of 147 matches
Mail list logo
