Hi!
When adding checks in which case not to merge a VIEW_CONVERT_EXPR from
large/huge _BitInt to vector/complex etc., I missed the case of loads.
Those are handled differently later.
Anyway, I think the load case is something we can handle just fine,
so the following patch does that instead of pre
Hi juzhe,
I also thought it’s related to commutive firstly.
Following things make me to do the removal:
1. No tests fails in regression
2. When I write if (a == 2) and if (2 == a), the results are same
3. The vec_duplicate operand is the 5th operand in both cmp and eqne
patter
Hi juzhe,
Yes, for comparison between vector and scalar variable, this patch is not work,
because the scalar is duplicated in loop vectorize pass.
I have not found idea for this situation, so solve vector-imm comparison first.
Thanks for remind this, I will try that patch.
Thanks.
From: 钟居哲
Se
Thanks for your patch! this is generally in good shape, just a few
minor comments :)
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 2135dfde9c8..afe486ba47b 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -6314,6 +6314,18 @@ Permissible values for this parame
Hi all, hi John & Thomas
John David Anglin wrote:
On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
I wonder: shouldn't that cap at 50 threads happen inside libgomp,
generally, instead of per test case and user code (!)?
Per my
understanding, OpenMP 'num_threads' specifies a *desired* number o
Hi!
When looking at PR114175 (although that bug seems to be now a riscv backend
bug), I've noticed that for the TYPE_NO_NAMED_ARGS_STDARG_P functions which
return value through hidden reference, like
#include
struct S { char a[64]; };
int n;
struct S
foo (...)
{
struct S s = {};
va_list ap;
On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote:
> John David Anglin wrote:
> > On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
> > > I wonder: shouldn't that cap at 50 threads happen inside libgomp,
> > > generally, instead of per test case and user code (!)?
>
> > > Per my
> > > un
On 3/1/24 09:44, Jakub Jelinek wrote:
On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote:
John David Anglin wrote:
On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
I wonder: shouldn't that cap at 50 threads happen inside libgomp,
generally, instead of per test case and user code (!)?
From: xuli
Standard vector calling convention variant will only enabled when function
has vector argument or returning value by default, however user may also
want to invoke function without that during a vectorized loop at some situation,
but it will cause a huge performance penalty due to vecto
The following removes the over-broad rejection of patterns for SLP
reductions which is done by removing them from LOOP_VINFO_REDUCTIONS
during pattern detection. That's also insufficient in case the
pattern only appears on the reduction path. Instead this implements
the proper correctness check i
LGTM, thanks :)
On Fri, Mar 1, 2024 at 5:10 PM Li Xu wrote:
>
> From: xuli
>
> Standard vector calling convention variant will only enabled when function
> has vector argument or returning value by default, however user may also
> want to invoke function without that during a vectorized loop at
Hi,
Bootstrapped and tested the gcc-13 backport of this on gcc-12 for
aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu and no regressions.
OK to push to gcc-12 branch?
Kind regards,
Andre Vieira
On 10/11/2023 13:16, Richard Biener wrote:
The following fixes the issue that when SLP stmts ar
Similar as to s390_lcbb, s390_vll, s390_vstl, et al. make use of a
signed vector type for vlbb. Furthermore, a const void pointer seems
more common and an integer for the mask.
For s390_vfi(s,d)b make use of integers for masks, too.
Use unsigned integers for all s390_vlbr/vstbr variants.
Make u
Thanks, I try to send a new version patch next week.
在 2024/2/29 下午2:08, Xi Ruoyao 写道:
On Thu, 2024-02-29 at 09:42 +0800, mengqinggang wrote:
Generate la.tls.desc macro instruction for TLS descriptors model.
la.tls.desc expand to
pcalau12i $a0, %desc_pc_hi20(a)
ld.d $a1, $a0, %desc
On Fri, 1 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> When adding checks in which case not to merge a VIEW_CONVERT_EXPR from
> large/huge _BitInt to vector/complex etc., I missed the case of loads.
> Those are handled differently later.
> Anyway, I think the load case is something we can handle just
On Fri, 1 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> When looking at PR114175 (although that bug seems to be now a riscv backend
> bug), I've noticed that for the TYPE_NO_NAMED_ARGS_STDARG_P functions which
> return value through hidden reference, like
> #include
>
> struct S { char a[64]; };
> i
On Fri, 1 Mar 2024, Andre Vieira (lists) wrote:
> Hi,
>
> Bootstrapped and tested the gcc-13 backport of this on gcc-12 for
> aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu and no regressions.
>
> OK to push to gcc-12 branch?
OK.
Thanks,
Richard.
> Kind regards,
> Andre Vieira
>
> On 10/1
The following avoids creating unsupported VEC_COND_EXPRs as part of
SIMD clone call mask argument setup during vectorization which results
in inefficient decomposing of the operation during vector lowering.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Will push on Monday when arm CI is ha
Hi Han,
in addition to what Juzhe mentioned (and that late-combine is going
to handle such cases) it should be noted that register pressure
should not be the only consideration here. Many uarchs have a higher
latency for register-file-crossing moves. At least without spilling
the vv variant is p
On Thu, 29 Feb 2024, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote:
> > That said, the quick experiment shows this isn't anything for stage4.
>
> The earlier the vector lowering is moved in the pass list, the higher
> are the possibilities that match.pd or
> On Feb 29, 2024, at 21:59, Richard Earnshaw (lists)
> wrote:
>
> On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>>> -Original Message-
>>> From: Maxim Kuvyrkov
>>> Sent: Thursday, February 29, 2024 9:46 AM
>>> To: Andrew Pinski (QUIC)
>>> Cc: Evgeny Karpov ; Andrew Pinski
>>> ; Ric
On 2/29/24 16:28, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively we could update 'DECL_CONTEXT' only for
'make_temporary_var_for_ref_to_temp' in call.cc, as a more targetted
fix, but I felt that this way it'd also fix any other similar issue
On 2/29/24 20:08, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
An implicit instantiation has an initializer depending on whether
DECL_INITIALIZED_P is set (like normal VAR_DECLs) which needs to be
written to ensure that consumers of header mod
On 2/29/24 15:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
For local enums defined in a non-template function or a function template
instantiation it seems we neglect to make the function depend on the enum
definition, which u
It is fine for robots to crawl the wiki pages, but they should perform
actions, generate huge diffs, search/highlight pages or generate
calendars.
---
htdocs/robots.txt | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index 057c5899..36be4d13 100644
---
On 2/29/24 14:17, Patrick Palka wrote:
On Wed, 28 Feb 2024, Jason Merrill wrote:
I wonder about, rather than returning it directly, setting its level to 1 for
the substitution?
Done, that works nicely.
Then I wonder if it would be feasible to give all autos level 0 and adjust it
here? That'
On 2/29/24 07:10, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because we decide to move that
struct { char a[n]; } DW_TAG_structure_type into .debug_types section
/ DW_UT_type DWARF5 unit, but refer from there to a DW_TAG_variable
(created artificially for the array bounds).
Even with
On Fri, Mar 01, 2024 at 08:18:09AM -0500, Jason Merrill wrote:
> On 2/29/24 20:08, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > An implicit instantiation has an initializer depending on whether
> > DECL_INITIALIZED_P is set (
On 29/02/2024 17:56, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote:
>> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we
>> never reach the point where you pick zero. So perhaps I'm worrying about
>> nothing.
>
> If you a
On 3/1/24 08:41, Nathaniel Shead wrote:
On Fri, Mar 01, 2024 at 08:18:09AM -0500, Jason Merrill wrote:
On 2/29/24 20:08, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
An implicit instantiation has an initializer depending on whether
DECL_INIT
On Fri, Mar 01, 2024 at 01:53:08PM +, Richard Earnshaw (lists) wrote:
> On 29/02/2024 17:56, Jakub Jelinek wrote:
> > On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote:
> >> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we
> >> never reach the po
Hi!
On 2024-02-27T20:16:52+0100, Tobias Burnus wrote:
> Minor update for older and more recent changes.
>
> Comments?
> gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update
> Update OpenACC for one new feature (Fortran interface to exisiting
> C/C++ routines).
> --- a/htdocs/gcc-14/ch
Hi Thomas,
Thomas Schwinge wrote:
On 2024-02-27T20:11:30+0100, Tobias Burnus wrote:
The attached patch updates the manual to match OpenACC 3.3
specification for the implemented routines.
But not update references to OpenACC 3.3, too?
As the change is not really visible (except when using F
+ /* Segment load/store permute cost. */
+ const int segment_permute_2;
+ const int segment_permute_4;
+ const int segment_permute_8;
Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-28 05:27
To: juzhe.zh...@rivai.ai; gcc-
On 29/02/2024 15:55, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote:
>>> I tried the above on arm, aarch64 and x86_64 and that seems fine,
>>> including the new testcase you added.
>>>
>>
>> I should mention though, that INIT_CUMULATIVE_ARGS on arm ignores
>
Hi Thiago,
Thanks for this, LGTM but I can't approve this, CC'ing Richard.
Do have a nitpick, in the gcc/testsuite/ChangeLog: remove
'gcc/testsuite' from bullet points 2-4.
Kind regards,
Andre
On 13/01/2024 00:55, Thiago Jung Bauermann wrote:
Since commits 2c3db94d9fd ("c: Turn int-conversi
On 01/03/2024 14:23, Andre Vieira (lists) wrote:
> Hi Thiago,
>
> Thanks for this, LGTM but I can't approve this, CC'ing Richard.
>
> Do have a nitpick, in the gcc/testsuite/ChangeLog: remove 'gcc/testsuite'
> from bullet points 2-4.
>
Yes, this is OK with the change Andre mentioned (your push
On 13/01/2024 20:46, Thiago Jung Bauermann wrote:
> Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
> permerrors") the test fails with errors such as:
>
> FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line
> 32)
> FAIL: gcc.target/arm/acle/cde-mve-error
Ping on this patch set.
Thanks a lot!
Qing
> On Feb 16, 2024, at 14:47, Qing Zhao wrote:
>
> Hi,
>
> This is the 6th version of the patch.
>
> compare with the 5th version, the only difference is:
>
> 1. Add the 6th argument to .ACCESS_WITH_SIZE
> to carry the TYPE of the flexible array.
Does this look reasonable to push? There are lots of other uses of
AM_ENABLE_MULTILIB(, ..) in the tree, but I'll leave others to "fix"
those if needed.
-- >8 --
This seems to be needed to build with --enable-maintainer-mode but I
don't understand why it doesn't fail in the normal build.
libstdc
> 2. When I write if (a == 2) and if (2 == a), the results are
> same
>
> 3. The vec_duplicate operand is the 5th operand in both cmp and
> eqne patterns. I think they are equal.
A comparison with a constant is always canonicalized to have the
constant second, that's why you won't see
On 01/03/2024 04:38, Alexandre Oliva wrote:
> Hello, Matthew,
>
> Thanks for the review.
For closure, Jakub has just pushed a patch to the generic code, so I don't
think we need this now.
R.
>
> On Feb 26, 2024, Matthew Malcomson wrote:
>
>> I think you're right that the AAPCS32 requires al
On 19/02/2024 09:13, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-13?
> Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
>
> Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
Jakub has just pushed a different fix for this, so I don't think we n
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 2/29/24 15:56, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > For local enums defined in a non-template function or a function template
> > instantiation it seems
> + /* Segment load/store permute cost. */
> + const int segment_permute_2;
> + const int segment_permute_4;
> + const int segment_permute_8;
>
> Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8
No idea why I posted that (wrong) version, I used it for
some testing locally. At
Does the text of these new diagnostics look good?
There are of course other ways for a type to be not-formattable (e.g.
the formatter::format member doesn't return the right type or has some
other kind of incorrect signature, or the formatter::parse member isn't
constexpr) but we can't predict/det
This fixes a regression on all active branches.
Tested aarch64-linux.
-- >8 --
I caused a regression with commit r10-908 by adding a constraint to the
non-explicit allocator-extended default constructor, but seemingly
forgot to add an explicit overload with the corresponding constraint.
libst
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 2/29/24 14:17, Patrick Palka wrote:
> > On Wed, 28 Feb 2024, Jason Merrill wrote:
> > > I wonder about, rather than returning it directly, setting its level to 1
> > > for
> > > the substitution?
> >
> > Done, that works nicely.
> >
> > > Then I wond
At the moment there are no extended mnemonics for vclfn(h,l) and vcrnf
defined in the Principles of Operation. Thus, remove the suffix "s"
from the builtins and expanders and introduce a further operand for the
data type.
gcc/ChangeLog:
* config/s390/s390-builtin-types.def: Update to ref
Not very often, but do I keep running into issues (fails, segfaults)
related to testing programs compiled with a GCC without offload
configured and then using the system libraries. - That's equivalent
to having the system compiler (or any offload compiler) and
compiling with -foffload=disable.
Th
On 3/1/24 10:17, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 2/29/24 14:17, Patrick Palka wrote:
On Wed, 28 Feb 2024, Jason Merrill wrote:
I wonder about, rather than returning it directly, setting its level to 1
for
the substitution?
Done, that works nicely.
Then I w
Hi!
installed as r14-9256
> diff --git a/contrib/mklog.py b/contrib/mklog.py
> index d764fb41f99..7d8d554b15e 100755
> --- a/contrib/mklog.py
> +++ b/contrib/mklog.py
> @@ -277,7 +277,7 @@ def generate_changelog(data, no_functions=False,
> fill_pr_titles=False,
> # it used to be
On Fri, 1 Mar 2024, Mark Wielaard wrote:
> It is fine for robots to crawl the wiki pages, but they should perform
> actions, generate huge diffs, search/highlight pages or generate
> calendars.
s/should/should not/ :-)
I see your patch does exactly that - thank you!
Gerald
On 3/1/24 10:00, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 2/29/24 15:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
For local enums defined in a non-template function or a function template
instantiati
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch adds an attribute to the mve md patterns to be able to identify
> predicable MVE instructions and what their predicated and unpredicated
> variants
> are. This attribute is used to encode the icode of the unpredicated variant
> of
> an ins
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch annotates some MVE across lane instructions with a new attribute.
> We use this attribute to let the compiler know that these instructions can be
> safely implicitly predicated when tail predicating if their operands are
> guaranteed to have
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch fixes the erroneous use of a mode attribute without a mode iterator
> in the pattern and removes unused unspecs and iterators.
>
> gcc/ChangeLog:
>
> * config/arm/iterators.md (supf): Remove VMLALDAVXQ_U, VMLALDAVXQ_P_U,
> VMLAL
On 3/1/24 02:55, Jakub Jelinek wrote:
On Thu, Feb 29, 2024 at 12:50:47PM +0100, Jakub Jelinek wrote:
finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for
DECL_DECOMPOSITION_P (expr) to determine if it is
array/struct/vector/complex etc. subobject proxy case vs. structured
binding usi
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch adds support in the target agnostic doloop pass for the detection
> of
> predicated vectorized hardware loops. Arm is currently the only target that
> will make use of this feature.
>
> gcc/ChangeLog:
>
> * df-core.cc (df_bb_regno_o
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch adds support for MVE Tail-Predicated Low Overhead Loops by using
> the
> doloop funcitonality added to support predicated vectorized hardware loops.
>
> gcc/ChangeLog:
>
> * config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change
On 11/01/2024 14:35, Szabolcs Nagy wrote:
> The branch-protection types are target specific, not the same on arm
> and aarch64. This currently affects pac-ret+b-key, but there will be
> a new type on aarch64 that is not relevant for arm.
>
> After the move, change aarch_ identifiers to aarch64_ o
According to IBM Open XL C/C++ for z/OS version 1.1 builtins
- vec_permi
- vec_ctd
- vec_ctsl
- vec_ctul
- vec_ld2f
- vec_st2f
are deprecated. Also deprecate helper builtins vec_ctd_s64 and
vec_ctd_u64.
Furthermore, the overloads of vec_insert which make use of a bool vector
are deprecated, too
On 3/1/24 10:32, Jason Merrill wrote:
On 3/1/24 10:00, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 2/29/24 15:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
For local enums defined in a non-template func
Jakub Jelinek wrote:
As discussed on IRC, I believe not disregarding the capture proxies in
target regions if they shouldn't be shared is always wrong, but also the
gimplify.cc suggestion was incorrect.
The thing is that at the place where the omp_disregard_value_expr call
is done currently for
On Fri, Mar 01, 2024 at 05:19:29PM +0100, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > As discussed on IRC, I believe not disregarding the capture proxies in
> > target regions if they shouldn't be shared is always wrong, but also the
> > gimplify.cc suggestion was incorrect.
> >
> > The thing
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 10:00, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Jason Merrill wrote:
> >
> > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > OK for trunk?
> > > >
> > > > -- >8 --
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 10:32, Jason Merrill wrote:
> > On 3/1/24 10:00, Patrick Palka wrote:
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this loo
This patch unifies help screen messages.
Johann
--
AVR: Overhaul help screen
gcc/
* config/avr/avr.opt: Overhaul help screen.diff --git a/gcc/config/avr/avr.opt b/gcc/config/avr/avr.opt
index ea35b7d5b4e..c3ca8379ee3 100644
--- a/gcc/config/avr/avr.opt
+++ b/gcc/config/avr/avr.opt
@@ -
On Fri, 1 Mar 2024, Patrick Palka wrote:
> On Fri, 1 Mar 2024, Jason Merrill wrote:
>
> > On 3/1/24 10:00, Patrick Palka wrote:
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does th
On Thu, Feb 29, 2024 at 07:30:02PM -0500, Jason Merrill wrote:
> On 2/29/24 19:12, Marek Polacek wrote:
> > On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote:
> >
> > > Hmm, if we're also going to allow the attribute to be applied to a
> > > function,
> > > the name doesn't make so mu
On 3/1/24 11:45, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
This was nearly enough to make things work, except we now ran into
issues with the local TYPE/CONST_DECL copies when streaming the
constexpr version of a function body. It occurred to me that we don't
need to make c
On 3/1/24 12:08, Patrick Palka wrote:
On Fri, 1 Mar 2024, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 3/1/24 10:00, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 2/29/24 15:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu,
On 3/1/24 12:39, Marek Polacek wrote:
On Thu, Feb 29, 2024 at 07:30:02PM -0500, Jason Merrill wrote:
On 2/29/24 19:12, Marek Polacek wrote:
On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote:
Hmm, if we're also going to allow the attribute to be applied to a function,
the name does
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 12:08, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Patrick Palka wrote:
> >
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 3/1/24 10:00, Patrick Palka wrote:
> > > > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > > > >
> > >
Hi Pan,
On 2/28/24 17:23, Li, Pan2 wrote:
>
> Personally I prefer to remove --param=riscv-autovec-preference=none
> and only allow
>
> mrvv-vector-bits, to avoid tricky(maybe) sematic of none preference.
> However, let’s
>
> wait for a while in case there are some comments from others.
>
We are v
The array member of struct SFOO in the ctf-file-scope-1 caused the test
to fail for the BPF target, since BPF does not support dynamic stack
allocation. The array does not need to variable length for the sake of
the test, so make it fixed length instead to allow the test to run
successfully for the
On 3/1/24 11:01, David Faust wrote:
The array member of struct SFOO in the ctf-file-scope-1 caused the test
to fail for the BPF target, since BPF does not support dynamic stack
allocation. The array does not need to variable length for the sake of
the test, so make it fixed length instead to allo
On 3/1/24 13:28, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 3/1/24 12:08, Patrick Palka wrote:
On Fri, 1 Mar 2024, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 3/1/24 10:00, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 2/29/2
On 2/15/24 16:51, Patrick Palka wrote:
On Thu, 15 Feb 2024, Jason Merrill wrote:
Relaxing to pedwarn is fine, but I think it should be on by default, not just
with -pedantic. So it should get a new option.
Ah, like so? I'm not sure about naming the option Wmodules-gmf-contents
vs just Wgmf-
On 2/26/24 15:52, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here during stream-in of the non-exported constexpr var 'a' we call
maybe_register_incomplete_var, which ends up taking the second branch
and pushing {a, NULL_TREE} on
On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote:
> On 3/1/24 12:39, Marek Polacek wrote:
> > @option{-Wdangling-reference} also warns about code like
> > @smallexample
> > @@ -3932,6 +3935,10 @@ struct Span @{
> > as @code{std::span}-like; that is, the class is a non-union class
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 13:28, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Jason Merrill wrote:
> >
> > > On 3/1/24 12:08, Patrick Palka wrote:
> > > > On Fri, 1 Mar 2024, Patrick Palka wrote:
> > > >
> > > > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > > > >
> >
On 3/1/24 14:34, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 3/1/24 13:28, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 3/1/24 12:08, Patrick Palka wrote:
On Fri, 1 Mar 2024, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 3/1/24
On 3/1/24 14:24, Marek Polacek wrote:
On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote:
On 3/1/24 12:39, Marek Polacek wrote:
@option{-Wdangling-reference} also warns about code like
@smallexample
@@ -3932,6 +3935,10 @@ struct Span @{
as @code{std::span}-like; that is, the
Is this OK for trunk?
-- >8 --
I'm seeing errors for --enable-maintainer-mode builds due to incorrectly
regenerating these files. They should be touched by gcc_update so they
aren't regenerated unnecessarily.
contrib/ChangeLog:
* gcc_update: Add more generated files in libcc1, lto-plugi
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 14:24, Marek Polacek wrote:
> > On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote:
> > > On 3/1/24 12:39, Marek Polacek wrote:
> > > >@option{-Wdangling-reference} also warns about code like
> > > >@smallexample
> > > > @@ -3
On 3/1/24 16:23, Patrick Palka wrote:
Sorry for not asking this sooner, but does it matter whether we attach
the attribute to the function type rather than the function declaration?
I noticed e.g. nodiscard gets attached to the decl.
And we document it as a function attribute despite attaching
So one of the broad goals we've had over the last few months has been to
ensure that every insn has a scheduling type and that every insn is
associated with an insn reservation in the scheduler.
This avoids some amazingly bad behavior in the scheduler. I won't go
through the gory details.
I
When adding the new_preheader to the cfg, only the new_preheader's dominator
information is updated. If one of the new basic block's children was part
of the original cfg and adding new_preheader to the cfg introduces another path
to that child, the child's dominator information will not be updated
On 2024-03-01 3:44 a.m., Jakub Jelinek wrote:
Isn't this just that you have 50 in there?
No. It's okay.
The problem is we run out of memory caused by a "ulimit -s 81920" statement
that I had
in .bashrc. The test pass with default stack allocation.
clone(child_stack=0x3191040,
flags=CLONE_V
gcc/ChangeLog:
* doc/extend.texi (__is_bounded_array): New documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5aeb9bdd47a..4c8c0631ca7 100644
--- a/gcc/doc/extend.texi
gcc/ChangeLog:
* doc/extend.texi (__is_reference): New documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 05f864e3dd5..d36707fcdf3 100644
--- a/gcc/doc/extend.texi
+++
gcc/ChangeLog:
* doc/extend.texi (__is_member_pointer): New documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index df2df98567a..08276f734f2 100644
--- a/gcc/doc/extend.texi
gcc/ChangeLog:
* doc/extend.texi (__is_member_object_pointer): New
documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 9361b425ba1..df2df98567a 100644
--- a/gcc/
This patch sorts built-in traits alphabetically for better codebase
consistency and easier future integration of changes.
gcc/ChangeLog:
* doc/extend.texi (Type Traits): Sort built-in traits
alphabetically.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 62
On Fri, Mar 1, 2024 at 4:07 AM Robin Dapp wrote:
>
> Hi Han,
>
> in addition to what Juzhe mentioned (and that late-combine is going
> to handle such cases) it should be noted that register pressure
> should not be the only consideration here. Many uarchs have a higher
> latency for register-file
gcc/ChangeLog:
* doc/extend.texi (__is_function): New documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 4c8c0631ca7..8ad88516c04 100644
--- a/gcc/doc/extend.texi
+++ b
gcc/ChangeLog:
* doc/extend.texi (__is_member_function_pointer): New
documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8ad88516c04..9361b425ba1 100644
--- a/gc
gcc/ChangeLog:
* doc/extend.texi (__remove_pointer): New documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fb2614176e5..1705ed93934 100644
--- a/gcc/doc/extend.texi
++
gcc/ChangeLog:
* doc/extend.texi (__is_object): New documentation.
Signed-off-by: Ken Matsui
---
gcc/doc/extend.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 08276f734f2..05f864e3dd5 100644
--- a/gcc/doc/extend.texi
+++ b/g
1 - 100 of 112 matches
Mail list logo
