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:
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
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
;; 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
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) ^
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.
>>
>>
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 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
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,
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
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):
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
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
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
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
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.
*
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];
| | ^~~
|
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:
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 (*)
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
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]
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.
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
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
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
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
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)
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!
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 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
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
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
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
>>
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
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
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:
*
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):
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
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
David: PING
On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher wrote:
> Hi.
> This fixes bug 107770.
> Thanks for the review.
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
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
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
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
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
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
> >
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
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
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
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 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
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
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
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.
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
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" } */
> +/* {
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
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
'-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
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
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
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
> -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 ;
>
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
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:
> >
> >
> -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
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
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
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
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
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):
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:
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.
> * 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
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.
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(-)
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
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
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 =
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
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
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 =
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
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
>
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
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:
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
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
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
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
*
90 matches
Mail list logo
