On Fri, Dec 2, 2022 at 7:37 AM Alexandre Oliva via Gcc-patches
wrote:
>
> On Dec 1, 2022, Jason Merrill wrote:
>
> > Once we see g*, starred is set. Then we see %:, and it sees that as a
> > zero-length switch, which because starred is still set, matches any and all
> > command-line options. S
On Fri, Dec 2, 2022 at 8:43 AM Richard Biener
wrote:
>
> On Fri, Dec 2, 2022 at 1:23 AM Zopolis0 wrote:
> >
> > > But that looks like the correct thing to do.
> >
> > It's not. The patch I reverted changes it so that no matter what,
> > void_list_node = build_tree_list (NULL_TREE, void_type_node)
On Fri, Dec 2, 2022 at 1:23 AM Zopolis0 wrote:
>
> > But that looks like the correct thing to do.
>
> It's not. The patch I reverted changes it so that no matter what,
> void_list_node = build_tree_list (NULL_TREE, void_type_node);.
>
> Before, each front-end set it in their own way, but they all
I tried turning -Wnarrowing back on earlier this year, but
unfortunately it didn't work due to triggering a bunch of new errors.
This patch silences at least some of them, but there will still be
more left even after applying it. (When compiling with clang,
technically the warning flag is -Wc++11-n
Hi,
The following test:
#include "arm_sve.h"
svint8_t
test_s8(int8_t *x)
{
return svld1rq_s8 (svptrue_b8 (), &x[0]);
}
ICE's with -march=armv8.2-a+sve -O1 -fno-tree-ccp -fno-tree-forwprop:
during GIMPLE pass: fre
pr107920.c: In function ‘test_s8’:
pr107920.c:7:1: internal compiler error: in ex
On Fri, 2 Dec 2022, Richard Biener wrote:
> On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
>
> > On 2022-12-01 11:42, Kees Cook wrote:
> > > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> > >> '-Wstrict-flex-arrays'
> > >> Warn about inproper usages of flexible array members ac
On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
> On 2022-12-01 11:42, Kees Cook wrote:
> > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> >> '-Wstrict-flex-arrays'
> >> Warn about inproper usages of flexible array members according to
> >> the LEVEL of the 'strict_flex_arr
On Thu, 1 Dec 2022, Tamar Christina wrote:
> > > +/* Check to see if the supplied comparison in PTEST can be performed as a
> > > + bit-test-and-branch instead. VAL must contain the original tree
> > > + expression of the non-zero operand which will be used to rewrite the
> > > + comparison
Hi,
For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI so that these instructions can be generated in a 32-bit environment. Also
it removes TARGET_64BIT check for these instructions.
The inst
The following adds a --param to limit the depth of unswitched loop
nests. One can use --param max-unswitch-depth=1 to disable unswitching
of outer loops (the innermost loop will then be unswitched).
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107946
On Fri, Dec 2, 2022 at 5:26 AM liuhongt wrote:
>
> After supporting extendbfsf2_1, ix86_expand_fast_convert_bf_to_sf can
> be improved with pslld either.
> CONST_INT_P is not handled since constant shift can be optimized off.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for t
On Dec 1, 2022, Jason Merrill wrote:
> Once we see g*, starred is set. Then we see %:, and it sees that as a
> zero-length switch, which because starred is still set, matches any and all
> command-line options. So targets that use such a spec accept all options in
> the driver, while ones that
On Fri, Dec 2, 2022 at 12:30 AM Sandra Loosemore
wrote:
>
> On 12/1/22 20:29, Eric Gallager via Gcc-patches wrote:
> > A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
> > Tested by doing `./configure --help` in the gcc subdirec
Hi Nilsson,
在 2022/12/2 10:49, Hans-Peter Nilsson 写道:
> On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote:
>
>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>> index 92bda1a7e14..9823eccbe68 100644
>> --- a/gcc/doc/tm.texi
>> +++ b/gcc/doc/tm.texi
>> @@ -7094,6 +7094,15 @@ the @code{POLY_
On 12/1/22 20:29, Eric Gallager via Gcc-patches wrote:
A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Tested by doing `./configure --help` in the gcc subdirectory and
noting that the "(or later)" made it into the output. OK for t
After supporting extendbfsf2_1, ix86_expand_fast_convert_bf_to_sf can
be improved with pslld either.
CONST_INT_P is not handled since constant shift can be optimized off.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386-expand.cc
A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Tested by doing `./configure --help` in the gcc subdirectory and
noting that the "(or later)" made it into the output. OK for trunk?
gcc/ChangeLog:
PR bootstrap/59447
* confi
On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote:
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index 92bda1a7e14..9823eccbe68 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -7094,6 +7094,15 @@ the @code{POLY_VALUE_MIN}, @code{POLY_VALUE_MAX} and
> implementation returns
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
BR,
Jeff(Jiufu)
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
>
> BR,
> Jeff (Jiufu)
>
>
> Jiufu Guo via Gcc-patches writes:
>
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4456-g0b737090a69624.
gcc/analyzer/ChangeLog:
PR analyzer/107948
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): Fold (0 - VAL) to -VAL.
* region-model.cc (regi
Tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4455-g5cb7d28dcfb11a.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/string-ops-concat-pair.c: New test.
* gcc.dg/analyzer/string-ops-dup.c: New test.
Signed-off-by: David Malcolm
---
.../gcc.dg/analyzer/string-ops-concat-pair.c
On 02/12/2022 00:05, Martin Liška wrote:
> On 11/11/22 06:21, Jørgen Kvalsvik wrote:
>> From: Jørgen Kvalsvik
>>
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is particu
> the "all in one go" approach that you seem to have attempted (?)
I did do all the patches in one go onto master, but for rebases and
bisects I did apply them on various baselines. See
https://github.com/Zopolis4/gcj-branches, where all the branches
labellled newplan/year-month-day will have the
In response to the testing thing, one critical issue is that these
patches aren't entirely functional (see the second point of my
original message), so I can't test yet. I'll check once I can though.
> But that looks like the correct thing to do.
It's not. The patch I reverted changes it so that no matter what,
void_list_node = build_tree_list (NULL_TREE, void_type_node);.
Before, each front-end set it in their own way, but they all set it
via void_list_node = build_tree_list (NULL_TREE, void
On 2022-12-01 18:19, Kees Cook wrote:
On Thu, Dec 01, 2022 at 10:27:41PM +, Qing Zhao wrote:
Hi, Sid,
Thanks a lot for the input.
After more thinking based on your and Kees’ comments, I have the following
thought:
1. -fstrict-flex-arrays=level should control both GCC code gen and warning
On Thu, Dec 01, 2022 at 10:27:41PM +, Qing Zhao wrote:
> Hi, Sid,
>
> Thanks a lot for the input.
>
> After more thinking based on your and Kees’ comments, I have the following
> thought:
>
> 1. -fstrict-flex-arrays=level should control both GCC code gen and warnings
> consistently;
> 2. W
Hi, Sid,
Thanks a lot for the input.
After more thinking based on your and Kees’ comments, I have the following
thought:
1. -fstrict-flex-arrays=level should control both GCC code gen and warnings
consistently;
2. We need warnings specifically for -fstrict-flex-arrays=level to report any
misu
On 12/1/22 15:57, Patrick Palka wrote:
Here the two BOUND_TEMPLATE_TEMPLATE_PARMs written as C end
up having the same TYPE_CANONICAL since the ctp_table (which interns the
canonical form of a template type parameter) doesn't set the
comparing_specializations flag which controls how PARM_DECLs fro
On 12/1/22 14:51, Patrick Palka wrote:
On Thu, 1 Dec 2022, Jason Merrill wrote:
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the correspond
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
> They are ./gcc/testsuite/gcc.dg/cpp/warn-redefined.c and
> ./gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c
>
> These two cases redefine the __TIME__ macro when using the option
> '-Wbuiltin-macro-redefined'.
>
> I think I shoud add a test to
Here the two BOUND_TEMPLATE_TEMPLATE_PARMs written as C end
up having the same TYPE_CANONICAL since the ctp_table (which interns the
canonical form of a template type parameter) doesn't set the
comparing_specializations flag which controls how PARM_DECLs from
different DECL_CONTEXTs compare equal.
Dear all,
we did not properly handle the case of insufficient array-valued
FIELD when trying to simplify UNPACK and could run into a NULL
pointer dereference. The fix is obvious.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 0ff50e73c6fce52263b9530daffe6743c1fc9b2c Mo
On 12/2/2022 3:07 AM, Joseph Myers wrote:
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
On 12/2/2022 1:01 AM, Joseph Myers wrote:
On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
b/gcc/testsuite/gcc.dg/builtin-redefine.c
i
On Thu, 1 Dec 2022, Jason Merrill wrote:
> On 12/1/22 11:37, Patrick Palka wrote:
> > When defining a explicit specialization of a constrained member template
> > (of a class template) such as f and g in the below testcase, the
> > DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partial
On 2022-12-01 11:42, Kees Cook wrote:
On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints ar
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
>
> On 12/2/2022 1:01 AM, Joseph Myers wrote:
> > On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
> >
> > > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > b/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > index 882b2210992..
On Thu, 1 Dec 2022, Joshi, Tejas Sanjay wrote:
> I have addressed all your comments in this revised patch, PFA and inlined
> below.
Thank you. Honza, please let me know if any further input is needed
from my side. For reference, here's how insn-automata.o table sizes
look with this patch (top
Richard,
Can you submit this patch for me while I sort out git write access?
On 11/18/22 07:57, Richard Biener wrote:
On Fri, Nov 11, 2022 at 3:28 AM Michael Collison wrote:
This patches transforms ((x & 0x1) == 0) ? y : z y -into
(-(typeof(y))(x & 0x1) & z) y, where op is a '^' or a '|'. I
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, November 14, 2022 9:59 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH 2/2]AArch64 Perform more late
On 12/2/2022 1:01 AM, Joseph Myers wrote:
On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
b/gcc/testsuite/gcc.dg/builtin-redefine.c
index 882b2210992..9d5b42252ee 100644
--- a/gcc/testsuite/gcc.dg/builtin-redefine.c
+++ b/gcc/testsu
On 12/1/22 05:32, Jakub Jelinek wrote:
On Wed, Nov 30, 2022 at 01:52:08PM -0500, Jason Merrill wrote:
It looks like we're already deducing the type for the underlying S variable
in cp_convert_omp_range_for, we just aren't updating the types of the
individual bindings.
You're right. With this
Hi all,
With these previous patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606586.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606587.html
we enabled the MVE overloaded _Generic associations to handle more
scalar types, however at PR 107515 we found a new regress
On 01/12/2022 16:12, Richard Sandiford wrote:
> Alex Coplan via Gcc-patches writes:
> > Hi,
> >
> > This patch fixes a type confusion bug in varasm.cc:assemble_variable.
> > The problem is that the current code calls:
> >
> > sect = get_variable_section (decl, false);
> >
> > and then accesses s
Richard,
What’s your opinion on this?
Do we need one separate warning option to report the misuse of flexible array
member only?
Or we just combine such warnings into -Warray-bounds when it combines with
-fstrict-flex-arrays?
Thanks.
Qing
> On Dec 1, 2022, at 12:18 PM, Kees Cook wrote:
>
>
On Thu, Dec 01, 2022 at 05:04:02PM +, Qing Zhao wrote:
>
>
> > On Dec 1, 2022, at 11:42 AM, Kees Cook wrote:
> >
> > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> >> '-Wstrict-flex-arrays'
> >> Warn about inproper usages of flexible array members according to
> >> the
> On Dec 1, 2022, at 11:42 AM, Kees Cook wrote:
>
> On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
>> '-Wstrict-flex-arrays'
>> Warn about inproper usages of flexible array members according to
>> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
>> the
On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
> b/gcc/testsuite/gcc.dg/builtin-redefine.c
> index 882b2210992..9d5b42252ee 100644
> --- a/gcc/testsuite/gcc.dg/builtin-redefine.c
> +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c
> @@ -7
On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > Thanks, David.
> > > Since we're not in phase 1 anymore, do we need an approval before
> > > I
> > > merge like last
A recent change only initializes the regs.how[] during Dwarf unwinding
which resulted in an uninitialized offset used in return address signing
and random failures during unwinding. The fix is to use REG_SAVED_OFFSET
as the state where the return address signing bit is valid, and if the
state is R
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
Under the old logic for validate_switches, once suffix or starred got set,
they stayed set for all later switches found in the spec. So for e.g.
%{g*:%{%:debug-level-gt(0):
Once we see g*, starred is set. Then we see %:, and it sees that as a
Hi,
I hadn't received any reply so I had implemented various ways to do this (about
8 of them in fact).
The conclusion is that no, we cannot emit one big RTL for the final instruction
immediately.
The reason that all comparisons in the AArch64 backend expand to separate CC
compares, and
separa
On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> '-Wstrict-flex-arrays'
> Warn about inproper usages of flexible array members according to
> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
> the trailing array field of a structure if it's available,
>
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints are carried over
from the original template
> > +/* Check to see if the supplied comparison in PTEST can be performed as a
> > + bit-test-and-branch instead. VAL must contain the original tree
> > + expression of the non-zero operand which will be used to rewrite the
> > + comparison in PTEST.
> > +
> > + Returns TRUE if operation s
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, November 14, 2022 9:59 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64 Perform more late folding of reg moves
> and shift
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, November 18, 2022 9:30 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH]AArch64 Fix vector re-interpretation between partial
> SIMD mo
Alex Coplan via Gcc-patches writes:
> Hi,
>
> This patch fixes a type confusion bug in varasm.cc:assemble_variable.
> The problem is that the current code calls:
>
> sect = get_variable_section (decl, false);
>
> and then accesses sect->named.name without checking whether the section
> is in fac
LGTM, and committed to trunk!
On Tue, Nov 29, 2022 at 4:54 PM Kito Cheng wrote:
>
> > >>> Yeah, I personally want to support RVV intrinsics in GCC13. As RVV
> > >>> intrinsic is going to release soon next week.
> > >>
> > >> OK, that's fine with me -- I was leaning that way, and I think Jeff only
LGMT, and as we discussed in another patch[1], I support RVV related
stuff to keep merge for this moment
and we agreed that it is not ideal but acceptable, so committed to trunku :)
[1]
https://patchwork.ozlabs.org/project/gcc/patch/20221128141406.242953-1-juzhe.zh...@rivai.ai/
On Tue, Nov 29, 2
On 01/12/2022 13:45, Andrew Stubbs wrote:
P.S. If you want to split the patch into the GCN bits and the bits that
depend on metadirectives then we can apply the first part to mainline
right away.
So this is the OG12-specific part (including metadirective and dynamic
context selectors) of the
Hi,
This patch fixes a type confusion bug in varasm.cc:assemble_variable.
The problem is that the current code calls:
sect = get_variable_section (decl, false);
and then accesses sect->named.name without checking whether the section
is in fact a named section. In the surrounding else clause, w
On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > Thanks, David.
> > Since we're not in phase 1 anymore, do we need an approval before I
> > merge like last year or can I merge immediately?
>
> I think it counts as a bug fix and
On Thu, Dec 1, 2022 at 10:33 AM Martin Liška wrote:
>
> The object is already included in OBJS (libbackend.a), thus
> we don't need it.
>
> Noticed while using partial linking for libbackend.a.
>
> Ready to be installed?
Looks obvious?
OK.
> Thanks,
> Martin
>
> gcc/cp/ChangeLog:
>
> *
On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> Thanks, David.
> Since we're not in phase 1 anymore, do we need an approval before I
> merge like last year or can I merge immediately?
I think it counts as a bug fix and thus you can go ahead and merge
(assuming you've done the usual test
On 11/11/22 06:21, Jørgen Kvalsvik wrote:
> From: Jørgen Kvalsvik
>
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive
Thanks, David.
Since we're not in phase 1 anymore, do we need an approval before I
merge like last year or can I merge immediately?
I also have many other patches (all in jit) that I need to prepare and
post to this mailing list.
What do you think?
On Thu, 2022-12-01 at 09:28 -0500, David Malcolm
On 01/12/2022 14:35, Paul-Antoine Arras wrote:
I believe this patch addresses your comments regarding the GCN bits.
The new builtins are consistent with the LLVM naming convention (lower
case, canonical name). For gfx803, I also kept '__fiji__' to be
consistent with -march=fiji.
Is it OK for
Hi Andrew, all,
On 01/12/2022 13:45, Andrew Stubbs wrote:
On 01/12/2022 11:10, Paul-Antoine Arras wrote:
+ if
(TARGET_FIJI) \
+ builtin_define
("__FIJI__"); \
+ else if
(TARGET_VEGA10
On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit wrote:
> Hi.
> This fixes bug 107770.
> Thanks for the review.
Thanks, the patch looks good to me.
Dave
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html
May I please ping this one? Thanks!
I have also re-attached the rebased patch here.
-Lewis
On Wed, Oct 12, 2022 at 06:37:50PM -0400, Lewis Hyatt wrote:
> Hello-
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/59
On Thu, Dec 01, 2022 at 01:35:38PM +, Andrew Stubbs wrote:
> > Maybe better add -ffat-lto-objects to dg-additional-options and drop
> > the dg-skip-if (if it works with that, for all similar tests)?
>
> The tests are already run with -ffat-lto-objects and the test still fails
> (pattern found
From: Eric Botcazou
This is necessary for unconstrained allocators with qualified expression.
gcc/ada/
* gcc-interface/trans.cc (get_storage_model_access): Strip any type
conversion around the node before looking into it.
Tested on x86_64-pc-linux-gnu, committed on master.
---
From: Steve Baird
Ada 2022 requires that an Aggregate aspect specification shall specify a
a name for at least one of Add_Named, Add_Unnamed, or Assign_Indexed.
Enforce this rule.
gcc/ada/
* sem_ch13.adb
(Validate_Aspect_Aggregate): Reject illegal case where none of
Add_
From: Eric Botcazou
gcc/ada/
* doc/gnat_ugn/gnat_and_program_execution.rst (Non-Symbolic
Traceback): Add compilation line.
(Symbolic Traceback): Remove obsolete stuff.
* doc/gnat_ugn/gnat_utility_programs.rst (gnatsymbolize): Adjust.
* gnat_ugn.texi: Regen
From: Gary Dismukes
When an Address attribute applies to an object that is a dereference of
an access value whose type has aspect Designated_Storage_Model, the
attribute will now be treated as having the address type associated
with the Storage_Model_Type of the access type's associated Storage_M
From: Ronan Desplanques
gcc/ada/
* lib-xref.adb (Generate_Reference): Fix misphrasing in comment.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/lib-xref.adb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/lib-xref.adb b/gcc/ada/lib-xref.ad
From: Ronan Desplanques
This patch fixes a few minor issues in the GNAT library section of
the reference manual.
gcc/ada/
* doc/gnat_rm/the_gnat_library.rst: Fix minor issues.
* gnat_rm.texi: Regenerate.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/doc/gnat
From: Josue Nava Bello
Minor updates to conf.py (comments, indentation)
gcc/ada/
* doc/share/conf.py: minor updates
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/doc/share/conf.py | 100 +++---
1 file changed, 72 insertions(+), 28 del
After the recent patches to improve / tidy up MVE tests and patterns,
a few more tests need to be updated (replacing spaces with tabs).
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.target/arm/simd/mve-compare-1.c: Update.
* gcc.target/arm/simd/mve-compare-scalar-1.c: Upda
On 30/11/2022 15:37, Jakub Jelinek wrote:
On Wed, Nov 30, 2022 at 03:17:30PM +, Andrew Stubbs wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-16.c
@@ -0,0 +1,89 @@
+/* { dg-require-effective-target vect_simd_clones } */
+/* { dg-additional-options "-fopenmp-simd -fdump-t
On 01/12/2022 11:10, Paul-Antoine Arras wrote:
+ if (TARGET_FIJI)
\
+ builtin_define ("__FIJI__"); \
+ else if (TARGET_VEGA10)
\
+
On 2022-12-01 15:10, Jiufu Guo via Gcc-patches wrote:
Hi Kewen,
在 12/1/22 2:11 PM, Kewen.Lin 写道:
on 2022/12/1 13:35, Jiufu Guo wrote:
Hi Kewen,
Thanks for your quick and insight review!
在 12/1/22 1:17 PM, Kewen.Lin 写道:
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
Hi,
This patch just use
Hi!
On 2022-11-30T23:18:06+1100, Zopolis0 via Gcc-patches
wrote:
> However, patches 14-19 do need an explanation, as proven by multiple
> reviews simply asking why I had made them. I'll send follow up
> messages to those.
Well, (at least for some of them) re-work rather than explanations. ;-)
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2022/11/24 17:24, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> As the test case in PR107412 shows, we can fold IFN .LEN_{LOAD,
>>> STORE} into normal vector load/store if the given length is known
>>> to be equal to the length of the who
Hi Kwok,
On 30/11/2022 19:50, Kwok Cheung Yeung wrote:
Hello PA,
--- libgomp/config/gcn/selector.c
+++ libgomp/config/gcn/selector.c
@@ -36,7 +36,7 @@ GOMP_evaluate_current_device (const char *kind,
const char *arch,
if (kind && strcmp (kind, "gpu") != 0)
return false;
- if (arch &
Hi!
On 2022-09-14T15:34:10+0200, Richard Biener via Gcc-patches
wrote:
> On Wed, Aug 24, 2022 at 2:22 PM wrote:
>> --- /dev/null
>> +++ b/gcc/rust/Make-lang.in
>> +# TODO: possibly find a way to ensure C++11 compilation level here?
>> +RUST_CXXFLAGS = -std=c++11 -Wno-unused-parameter -Werror=o
Wilco Dijkstra writes:
> Hi Richard,
>
>> Just to make sure I understand: isn't it really just MOVN? I would have
>> expected a 32-bit MOVZ to be equivalent to (and add no capabilities over)
>> a 64-bit MOVZ.
>
> The 32-bit MOVZ immediates are equivalent, MOVN never overlaps, and
> MOVI has some
On Wed, Nov 30, 2022 at 01:52:08PM -0500, Jason Merrill wrote:
> It looks like we're already deducing the type for the underlying S variable
> in cp_convert_omp_range_for, we just aren't updating the types of the
> individual bindings.
You're right. With this patch (still incremental against the
The patches allow less instructions to be used in stack allocation
and deallocation if save-restore enabled, and also make the stack
manipulation codes more readable.
Fei Gao (3):
RISC-V: add a new parameter in riscv_first_stack_step.
RISC-V: optimize stack manipulation in save-restore
RIS
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_first_stack_step): make codes more
readable.
(riscv_expand_epilogue): likewise.
---
gcc/config/riscv/riscv.cc | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/confi
frame->total_size to remaining_size conversion is done as an independent patch
without
functionality change as per review comment.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_first_stack_step): add a new function
parameter remaining_size.
(riscv_compute_frame_info): adapt new
The stack that save-restore reserves is not well accumulated in stack
allocation and deallocation.
This patch allows less instructions to be used in stack allocation and
deallocation if save-restore enabled.
before patch:
bar:
callt0,__riscv_save_4
addisp,sp,-64
...
Hi.
Noticed during building of libbackend.a with the LTO partial linking.
The function release_body is called even if clone_of is a clone
of a another function and thus it shares tree declaration. We should
preserve it in that situation.
Patch can bootstrap on x86_64-linux-gnu and survives regre
The following changes the predicate representation to record the
value of a predicate with an empty set of AND predicates. That's
necessary to properly represent the conservative fallback for the
def vs use predicates. Since simplification now can result in
such an empty set this distinction beco
The object is already included in OBJS (libbackend.a), thus
we don't need it.
Noticed while using partial linking for libbackend.a.
Ready to be installed?
Thanks,
Martin
gcc/cp/ChangeLog:
* Make-lang.in: Remove extra object dependency.
---
gcc/cp/Make-lang.in | 2 +-
1 file changed, 1
The following makes sure to honor the backedge processing logic
that forces VARYING there.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107935
* tree-ssa-sccvn.cc (visit_phi): Honor forced VARYING on
backedges.
* gcc.dg/torture
Hi Segher,
在 11/28/22 10:18 PM, Segher Boessenkool 写道:
> On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
>>> On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
on 2022/10/26 19:40, Jiufu Guo wrote:
for "li/lis + oris/xoris", I interpreted
Hi,
For constant C:
If '(c & 0x8000ULL) == 0x8000ULL' or say:
32(1) || 16(x) || 1(1) || 15(x), using "li; xoris" would be ok.
If '(c & 0x80008000ULL) == 0x8000ULL' or say:
32(0) || 1(1) || 15(x) || 1(0) || 15(x), we could use "li; oris" to
build constant 'C'.
1 - 100 of 103 matches
Mail list logo
