The test uses target_clones, that requires ifunc support.
Tested on GNU/Linux/x86_64, Solaris/x86 (thanks Rainer), and with a
cross to x86_64-elf. Approved by Rainer in the PR. I'm checking it in,
trunk only for now.
for gcc/testsuite/ChangeLog
PR target/107304
* gcc.target
Hi,
As PR104024 shows, the option -mpower10-fusion isn't guarded by
-mcpu=power10, it causes compiler to fuse for some patterns
even without power10 support and then causes ICE unexpectedly,
this patch is to simply unmask it without power10 support, not
emit any warnings as this option is undocume
Hi,
Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
if fun->decl is not null but no cgraph node is available for it.
As PR105818 shows, this could cause unexpected consequence. For
the case in PR105818, when parsing bar decl in function foo, the
cfun is the function structure for f
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603350.html
BR,
Kewen
on 2022/10/12 16:12, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
> handle option pow
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,
and also a much clear logic for save-restore stack manipulation.
before patch:
b
Hi Adrian,
> On 28 Nov 2022, at 20:44, Iain Sandoe wrote:
>> Bootstrapping and running the testsuite on x86_64 was successfull. No
>> regression occured.
>
> This looks resonable to me, as said in the PR. I’d like to test a little
> wider with some larger
> codebases, if you could bear with
On Wed, Nov 30, 2022 at 9:44 AM Richard Biener
wrote:
>
> On Tue, Nov 29, 2022 at 11:05 AM Manolis Tsamis
> wrote:
> >
> > When using SWAR (SIMD in a register) techniques a comparison operation
> > within
> > such a register can be made by using a combination of shifts, bitwise and
> > and
> >
On 29/11/2022 18:26, Tobias Burnus wrote:
Hi PA, hi Andrew, hi Jakub, hi all,
On 29.11.22 16:56, Paul-Antoine Arras wrote:
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, [...]
I think this should be documented somewhere. We have
https://gcc.gnu.org/on
Hi!
r13-254-gdd3c7873a61019e9 added an optimization for {a, +, a} (x-1),
but as can be seen on the following testcase, the way it is written
where chrec_fold_multiply is called with type doesn't work for pointers:
res = build_int_cst (TREE_TYPE (x), 1);
res = chrec_fold_p
Hi!
The r13-1100-gacb1e6f43dc2bbedd124 change added match.pd narrowing
of left shifts, and while I believe the C++ FE calls the warning on unfolded
trees, the C FE folds them and so left shifts where integral promotion
happened and so were done in int type will be usually narrowed back to
char/sig
Excerpts from Jakub Jelinek via Gcc-patches's message of November 11, 2022
10:09 am:
> Hi!
>
> Here is the floating point division fold_range implementation,
> as I wrote in the last mail, we could outline some of the common parts
> into static methods with descriptive names and share them betwee
On Wed, 30 Nov 2022, Jakub Jelinek wrote:
> Hi!
>
> r13-254-gdd3c7873a61019e9 added an optimization for {a, +, a} (x-1),
> but as can be seen on the following testcase, the way it is written
> where chrec_fold_multiply is called with type doesn't work for pointers:
> res = build_int_
On 30.11.22 10:43, Andrew Stubbs wrote:
On 29/11/2022 18:26, Tobias Burnus wrote:
On 29.11.22 16:56, Paul-Antoine Arras wrote:
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, [...]
PA committed that patch as
https://gcc.gnu.org/r13-4403-g1fd508744eccd
We fail to simplify
((_145 != 0B) AND (_531 == 2) AND (_109 == 0))
OR ((NOT (_145 != 0B)) AND (_531 == 2) AND (_109 == 0))
OR ((NOT (_531 == 2)) AND (_109 == 0))
because the existing simplification of !A && B || A && B is implemented
too simplistic. The following re-imple
The following dumps the edge a use is uninitialized in a PHI.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-uninit.cc (find_uninit_use): Dump the edge for a
PHI node.
---
gcc/tree-ssa-uninit.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
The testcase from the PR at -O2 shows
((_277 == 2) AND (_79 == 0))
OR ((NOT (_277 == 0)) AND (NOT (_277 > 2)) AND (NOT (_277 == 2)) AND (_79
== 0))
OR ((NOT (pretmp_300 == 255)) AND (_277 == 0) AND (NOT (_277 > 2)) AND (NOT
(_277 == 2)) AND (_79 == 0))
which we fail to simplify. Th
> * Each patch should have its own explanation of what it is doing and why,
> in the message body (not in an attachment). Just the commit summary line
> and ChangeLog entries aren't enough, we need the actual substantive commit
> message explaining the patch.
The thing is, most of the patches do
These two patches (posting as a "partial series" to avoid too much
duplication) comprise bug fixes for map clause expansion and a new version
of the patch to support OpenMP 5.0+ "declare mapper" directives for
C++. Hopefully previous review comments for the latter have been
adequately addressed.
T
This is a new version of the patch to support OpenMP 5.0 "declare mapper"
functionality for C++. As with the previously-posted version, arrays
of structs whose elements would be mapped via a user-defined mapper
remain unsupported.
(Previous versions were posted here:
https://gcc.gnu.org/piperma
This patch fixes some cases for OpenACC and OpenMP where map clauses were
being expanded (adding firstprivate_pointer, attach/detach nodes, and so
forth) unnecessarily, after the "OpenMP/OpenACC: Rework clause expansion
and nested struct handling" patch (approved but not yet committed):
https://
On Wed, 2022-11-30 at 23:18 +1100, Zopolis0 via Gcc-patches wrote:
> 20-43 and 47 are just applying treewide changes that Java missed out
> on
Add something like "adapt Java frontend for r11-1234 change" then. So
the reviewer can take a look at https://gcc.gnu.org/r11-1234 and review
the change m
Resending with the typo in the mailing list address fixed...
On Wed, 30 Nov 2022 at 12:31, Jonathan Wakely wrote:
>
> On Tue, 29 Nov 2022 at 21:41, Björn Schäpers wrote:
> >
> > From: Björn Schäpers
> >
> > Not providing an error handler results in a nullpointer dereference when
> > an error occ
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
>
>
>
> On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
>>
>>
>>
>> On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++
>> wrote:
>>>
>>> Good catch, then we also need this patch.
>>
>>
>> Is it worth printing an error? If we can
On Wed, Nov 30, 2022 at 9:59 AM Manolis Tsamis wrote:
>
> On Wed, Nov 30, 2022 at 9:44 AM Richard Biener
> wrote:
> >
> > On Tue, Nov 29, 2022 at 11:05 AM Manolis Tsamis
> > wrote:
> > >
> > > When using SWAR (SIMD in a register) techniques a comparison operation
> > > within
> > > such a regi
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, November 30, 2022 1:19 PM
> To: Manolis Tsamis
> Cc: gcc-patches@gcc.gnu.org; Philipp Tomsich ;
> Tamar Christina ;
> jiangning@amperecomputing.com; Christoph Muellner
>
> Subject: Re: [PATCH v2] Add pattern to convert ve
On Fri, Nov 11, 2022 at 3:02 PM Richard Biener
wrote:
>
> On Mon, Oct 10, 2022 at 5:32 PM Gaius Mulley via Gcc-patches
> wrote:
> >
> >
> > Here are the latest modula-2 front end patches for review.
> > The status of the patches and their contents are also contained at:
> >
> >https://splendi
Fixes:
gcc/fortran/parse.cc:5782:32: warning: for loop has empty body [-Wempty-body]
gcc/fortran/ChangeLog:
* parse.cc (parse_omp_structured_block): Remove extra semicolon.
---
gcc/fortran/parse.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/parse.cc b
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Wednesday, November 30, 2022 1:24 PM
> To: Richard Biener ; Manolis Tsamis
>
> Cc: gcc-patches@gcc.gnu.org; Philipp Tomsich ;
> jiangning@ampere
gcc/ChangeLog:
* tree-switch-conversion.cc (bit_test_cluster::emit): Remove
dead variable bt_range.
---
gcc/tree-switch-conversion.cc | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/tree-switch-conversion.cc b/gcc/tree-switch-conversion.cc
index 83ba1c1ca03..1d75d7c7fc7 1
On 11/29/22 03:37, Hongtao Liu wrote:
> On Mon, Nov 28, 2022 at 10:40 PM Martin Liška wrote:
>>
>> On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
>>>2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced
>>> several
>>> target hooks(Many thanks to their work) so other backends
Hi, this is the 2nd version for this patch.
Per our discussion, I made the following change compared to the first
version:
1. The level of -Warray-bounds will NOT control how a trailing array
is considered as a flex array member anymore. Only the level of
-fstrict-flex-arrays will contro
'-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,
otherwise according to the LEVEL of the option
'-fstrict-fl
On 09/09/2022 15:31, Jakub Jelinek wrote:
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -1074,13 +1076,19 @@ if_convertible_stmt_p (gimple *stmt,
vec refs)
tree fndecl = gimple_call_fndecl (stmt);
if (fndecl)
{
+ /* We can vectorize some builtins and
Hi all,
This patch adds or fixes support for various AMD 'isa' and 'arch' trait
selectors, so as to be consistent with LLVM. It also adds test cases
checking all supported AMD ISAs are properly recognised when used in a
'metadirective' construct.
This patch is closely related to
https://gcc
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-tree-optimized" } */
> +/* { dg-addi
On Tue, Nov 29, 2022 at 11:05:33PM +0100, Jakub Jelinek wrote:
> On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
> > > --- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
> > > +0100
> > > +++ gcc/testsuite/g++.dg/gomp/for-21.C2022-11-29 13:06:59.038410557
>
Hi,
This patch fixes an ICE with using `continue' on a named label in an
unrolled loop statement.
Continue labels in an unrolled loop require a unique label per
iteration. Previously this used the Statement body node for each
unrolled iteration to generate a new entry in the label hash table.
Th
From: Andrew Pinski
The problem here is the code which handles {"a"} is supposed
to handle the case where the is something after the string but
it only handles the case where there is another string so
we go down the other path and error out saying "excess elements
in struct initializer" even tho
From: Andrew Pinski
So char arrays are not the only type that be initialized from {"a"}.
We can have wchar_t (L"") and char16_t (u"") types too. So let's
print out the type of the array instead of just saying char.
Note in the testsuite I used regex . to match '[' and ']' as
I could not figure o
On Wed, Nov 30, 2022 at 09:18:14AM -0800, apinski--- via Gcc-patches wrote:
> gcc/c/ChangeLog:
>
> PR c/107926
> * c-typeck.cc (process_init_element):
> Move the ceck for string cst until
> after the error message.
Just a ChangeLog nit, not a patch review for which I defer
Hi all,
According to the architecture pseudocode the FEAT_MOPS sequences overwrite the
NZCV flags
as part of their operation, so GCC needs to model that in the relevant RTL
patterns.
For the testcase:
void g();
void foo (int a, size_t N, char *__restrict__ in,
char *__restrict__ out)
{
On 30/11/22 14:07, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++
wrote:
Good catch, then we also need this patch.
Is it worth printing an err
clang by default rejects the input casts with:
error: invalid use of a cast in a inline asm context requiring an
lvalue: remove the cast or build with -fheinous-gnu-extensions
And even with -fheinous-gnu-extensions clang still throws an warning
and also states that this option might be remove
On 30/11/22 14:07, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++
wrote:
Good catch, then we also need this patch.
Is it worth printing an err
On Wed, 30 Nov 2022, Zopolis0 via Gcc-patches wrote:
> > * Each patch should have its own explanation of what it is doing and why,
> > in the message body (not in an attachment). Just the commit summary line
> > and ChangeLog entries aren't enough, we need the actual substantive commit
> > messag
This was found building 64-bit openssh package.
Committed to active branches.
Dave
---
Fix addvdi3 and subvdi3 patterns
While most PA 2.0 instructions support both 32 and 64-bit traps
and conditions, the addi and subi instructions only support 32-bit
traps and conditions. Thus, we need to force
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 && strcmp (arch, "gcn") != 0)
+ if (arch && (strcmp (arc
On 11/30/22 10:51, Jakub Jelinek wrote:
On Tue, Nov 29, 2022 at 11:05:33PM +0100, Jakub Jelinek wrote:
On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
--- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
+0100
+++ gcc/testsuite/g++.dg/gomp/for-21.C 2022
On 11/30/22 03:51, Iain Sandoe wrote:
Hi Adrian,
On 28 Nov 2022, at 20:44, Iain Sandoe wrote:
Bootstrapping and running the testsuite on x86_64 was successfull. No
regression occured.
This looks resonable to me, as said in the PR. I’d like to test a little wider
with some larger
codeba
One could (for a manual test) always change libbacktrace to call the callback.
Or invoke it on a platform where libbacktrace can't figure out the executable
path on its own, like currently windows.
As for an automated test, I have no idea how to enforce that, without changing
the code to be te
David: PING
On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher wrote:
> Hi.
> This fixes bug 107770.
> Thanks for the review.
On Tue, Nov 29, 2022 at 4:10 PM Ian Lance Taylor wrote:
>
> On Tue, Nov 29, 2022 at 9:54 AM wrote:
> >
> > From: Sören Tempel
> >
> > On glibc, there are two versions of strerror_r: An XSI-compliant and a
> > GNU-specific version. The latter is only available on glibc. In order
> > to avoid dupl
Hi,
This patch was applied to mainline back in August, but was held back
from backporting until after 12.2 release to allow some more time for
testing. There are no further regressions been found, so have
backported to the releases/gcc-12 branch.
Bootstrapped and regression tested on x86_64-linu
Hi,
This patch synchronizes the documentation between lang.opt and gdc.texi.
Tested by building and checking pdf/info/man/html pages, and committed
to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* gdc.texi: Update gdc option documentation.
* lang.opt (frevert=intpromote): Cor
Hi,
This patch separates indexes at the end of the gdc documentation into an
Options index and Keyword index, as per documentation manuals in other
front-ends.
Tested by building and checking pdf/info/man/html pages, and committed
to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* gdc.
Hi,
This patch sorts out the include directories for building the gdc docs -
we don't need to include anything from the toplevel docs directory.
The html output directory has also been renamed from /d/ to /gdc/ to
make it clearer that this is vendor-specific documentation.
Tested by building and
Hi,
This adds an initial body of documentation for the D front-end - other
than the existing documentation for command-line usage/the man page.
Documentation covers code generation choices specific to GNU D - what
attributes are supported, intrinsics, pragmas, predefined versions,
language extens
Hi Gerald,
Excerpts from Gerald Pfeifer's message of November 29, 2022 9:21 pm:
> Hi Iain,
>
> On Tue, 29 Nov 2022, Iain Buclaw via Gcc-patches wrote:
>> This looks obvious, however I don't know how things are generated for
>> the online documentation site in order to say this won't cause any
>>
On Wed, 30 Nov 2022 00:37:17 PST (-0800), gao...@eswincomputing.com wrote:
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,
and also a m
Hi!
On Wed, Nov 30, 2022 at 09:18:15AM -0800, apinski--- via Gcc-patches wrote:
> Note in the testsuite I used regex . to match '[' and ']' as
> I could not figure out how many '\' I needed.
Don't use double quotes then :-) Inside double quotes all of command
substitution, variable substitution,
On Nov 30 2022, Segher Boessenkool wrote:
> char u[1] = { "x", "x" }; /* { dg-error {excess elements in 'char[1]'
> initializer} } */
That won't work, as '[1]' is a bracket expression only matching '1'.
You'll need {... 'char\[1\]' ...}.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerp
Hi!
On Wed, Nov 30, 2022 at 03:16:25PM -0300, Adhemerval Zanella via Gcc-patches
wrote:
> clang by default rejects the input casts with:
>
> error: invalid use of a cast in a inline asm context requiring an
> lvalue: remove the cast or build with -fheinous-gnu-extensions
>
> And even with -
On Thu, Dec 01, 2022 at 12:17:30AM +0100, Andreas Schwab wrote:
> On Nov 30 2022, Segher Boessenkool wrote:
>
> > char u[1] = { "x", "x" }; /* { dg-error {excess elements in 'char[1]'
> > initializer} } */
>
> That won't work, as '[1]' is a bracket expression only matching '1'.
> You'll need {..
Hi,
This patch just uses sext_hwi to replace the expression like:
((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
Bootstrap & regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
* config/rs6000/rs6000.cc (num_insns_constant_gpr): Use s
Hi,
This patch is just using a more readable pattern for "rldicl x,x,0,32"
to clean high 32bits.
Old pattern looks like: r118:DI=zero_extend(r120:DI#0)
new pattern looks like: r118:DI=r120:DI&0x
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeL
Hi,
Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked from
two "define_split"s where the target operand is limited to gpc_reg_operand or
int_reg_operand, then the operand must be REG_P.
And in rs6000_emit_set_const/rs6000_emit_set_long_const, to create temp rtx,
it is usin
Date: Thu, 01 Dec 2022 09:48:06 +0800
In-Reply-To: <20221128171950.gn25...@gate.crashing.org> (Segher Boessenkool's
message of "Mon, 28 Nov 2022 11:19:50 -0600")
Message-ID: <7e4jufyjvt@pike.rch.stglabs.ibm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Segher Boessenko
Date: Thu, 01 Dec 2022 09:51:32 +0800
In-Reply-To: <20221125144309.gg25...@gate.crashing.org> (Segher Boessenkool's
message of "Fri, 25 Nov 2022 08:43:09 -0600")
Message-ID: <7ewn7bx55n@pike.rch.stglabs.ibm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Segher Boessenko
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4424-g45a75fd3d31265.
gcc/analyzer/ChangeLog:
PR analyzer/107928
* sm-fd.cc (fd_state_machine::on_bind): Handle m_constant_fd in
the "success" outcome.
(fd_state_machine::on_connec
Consider -fanalyzer on:
#include
int32_t arr[10];
void int_arr_write_element_after_end_far(int32_t x)
{
arr[100] = x;
}
Trunk x86_64: https://godbolt.org/z/7GqEcYGq6
Currently we emit:
: In function 'int_arr_write_element_after_end_far':
:7:12: warning: buffer overflow [CWE-787] [-Wanalyze
Consider -fanalyzer on:
#include
int32_t arr[10];
void int_arr_write_element_after_end_off_by_one(int32_t x)
{
arr[10] = x;
}
Trunk x86_64: https://godbolt.org/z/17zn3qYY4
Currently we emit:
: In function 'int_arr_write_element_after_end_off_by_one':
:7:11: warning: buffer overflow [CWE-78
Convert out-of-bounds class hierarchy from:
pending_diagnostic
out_of_bounds
past_the_end
buffer_overflow (*)
buffer_over_read (*)
buffer_underwrite (*)
buffer_under_read (*)
symbolic_past_the_end
symbolic_buffer_overflow (*)
symbolic_buffer_
This patch tweaks the wording of -Wanalyzer-out-of-bounds:
* use the spellings/terminology of CWE:
* replace "underread" with "under-read", as per:
https://cwe.mitre.org/data/definitions/127.html
* replace "overread" with "over-read" as per:
https://cwe.mitre.org/data/definitions/126
The region-creation event at the start of...
: In function 'int_arr_write_element_after_end_off_by_one':
:14:11: warning: buffer overflow [CWE-787] [-Wanalyzer-out-of-bounds]
14 | arr[10] = x;
| ^~~
event 1
|
| 10 | int32_t arr[10];
| | ^~~
|
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4425-gb82b361af888a1.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add analyzer/bounds-checking.o.
gcc/analyzer/ChangeLog:
* bounds-checking.cc: New file, taken from region-model.cc.
* r
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4431-geaaf97b6147095.
gcc/analyzer/ChangeLog:
PR analyzer/106626
* bounds-checking.cc
(symbolic_past_the_end::describe_final_event): Delete, moving to
symbolic_buffer_overflow::des
Hi,
Currently patchable area is at the wrong place on AArch64. It is placed
immediately after function label, before .cfi_startproc. This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
modifies aarch64_print_patchable_function_entry to avoid placing
patchable area be
On 2022-12-01 06:50 Palmer Dabbelt wrote:
>
>On Wed, 30 Nov 2022 00:37:17 PST (-0800), gao...@eswincomputing.com wrote:
>> 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 a
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
> Hi,
>
> Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked
> from
> two "define_split"s where the target operand is limited to gpc_reg_operand or
> int_reg_operand, then the operand must be REG_P.
> And in rs6000_emit_set_co
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The first is an actual bug: remove_contract_attributes was only keeping one
attribute. The second just helps flow analysis in optimizers and static
analyzers.
gcc/cp/ChangeLog:
* contracts.cc (remove_contract_attributes): Actually
As implied in
gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html,
gcc provides -Wno-builtin-macro-redefined to suppress warning when
redefining builtin macro. However, at that time, there was no
scenario for __LINE__ macro.
But, when we try to build a live-patch, we compare sections by using
Hi Kewen,
在 12/1/22 11:31 AM, Kewen.Lin 写道:
> Hi Jeff,
>
> on 2022/12/1 09:36, Jiufu Guo wrote:
>> Hi,
>>
>> Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked
>> from
>> two "define_split"s where the target operand is limited to gpc_reg_operand or
>> int_reg_operand, t
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
> Hi,
>
> This patch just uses sext_hwi to replace the expression like:
> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>
> Bootstrap & regtest pass on ppc64{,le}.
> Is this ok for trunk?
You didn't say it clearly but I guesse
on 2022/12/1 13:17, Kewen.Lin via Gcc-patches wrote:
> Hi Jeff,
>
> on 2022/12/1 09:36, Jiufu Guo wrote:
>> Hi,
>>
>> This patch just uses sext_hwi to replace the expression like:
>> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>>
>> Bootstrap & regtest pass on ppc64{,le}.
>
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 uses sext_hwi to replace the expression like:
>> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>>
>> Bootstr
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 uses sext_hwi to replace the expression like:
>>> ((value & 0xf..f) ^ 0x80..0)
;; if reg/mem op
(define_insn_reservation "slm_sseishft_3" 2
(and (eq_attr "cpu" "slm")
(and (eq_attr "type" "sseishft")
(not (match_operand 2 "immediate_operand"
"slm-complex, slm-all-eu")
in slm.md it will check operands[2] for type sseishft, but for
extendbfsf2_1 the
Hi Kewen,
在 12/1/22 1:30 PM, Kewen.Lin 写道:
> on 2022/12/1 13:17, Kewen.Lin via Gcc-patches wrote:
>> Hi Jeff,
>>
>> on 2022/12/1 09:36, Jiufu Guo wrote:
>>> Hi,
>>>
>>> This patch just uses sext_hwi to replace the expression like:
>>> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000
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 uses sext_hwi to replac
On Thu, Dec 1, 2022 at 12:26 AM Segher Boessenkool
wrote:
>
> Hi!
>
> On Wed, Nov 30, 2022 at 03:16:25PM -0300, Adhemerval Zanella via Gcc-patches
> wrote:
> > clang by default rejects the input casts with:
> >
> > error: invalid use of a cast in a inline asm context requiring an
> > lvalue:
90 matches
Mail list logo
