Hi Richard,
> On 22 Aug 2024, at 10:34 pm, Richard Biener
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Aug 21, 2024 at 12:08 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>>> On 20 Aug 2024, at 6:09 pm, Richard Biener
>>> wrote:
>>>
>>> Externa
Am Montag, dem 26.08.2024 um 17:21 -0700 schrieb Kees Cook:
> On Mon, Aug 26, 2024 at 11:01:08PM +0200, Martin Uecker wrote:
> > Am Montag, dem 26.08.2024 um 13:30 -0700 schrieb Kees Cook:
> > > On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> > > > Hi, Martin,
> > > >
> > > > Looks li
> Am 27.08.2024 um 06:12 schrieb Bernd Edlinger :
>
> This new test was reported to be still failing on sparc targets.
> Here the number of DW_AT_ranges dropped to zero.
> The test should pass on this architecture with -Os, -O2 and -O3.
> I tried to improve also different known problematic tar
This new test was reported to be still failing on sparc targets.
Here the number of DW_AT_ranges dropped to zero.
The test should pass on this architecture with -Os, -O2 and -O3.
I tried to improve also different known problematic targets,
where only one subroutine had DW_AT_ranges:
Those are armhf
> You are possibly overwriting src_related_elt - I'd suggest to either break
> here or do the loop below for each found elt?
Changed.
> Do we know that will always succeed?
1) validate_subreg allows subreg for 2 vector modes with same component modes.
2) gen_lowpart in cse.cc is defined as gen_low
For mode2 bigger than 16-bytes, when it can be allocated to FIRST_SSE_REGS,
then it can only be allocated to ALL_SSE_REGS, and it can be tiebale
to all mode1 with smaller size which is available to FIRST_SSE_REGS.
When modes is equal to 16 bytes, exclude non-vector modes(TI/TFmode).
This is need fo
As applied to all AVX10.2 patches, it is caused by vector size warning
mentioned previously.
Thx,
Haochen
> -Original Message-
> From: haochen.jiang
> Sent: Monday, August 26, 2024 11:54 PM
> To: jun.zh...@intel.com; gcc-regress...@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen
Thanks Richard for comments.
> I think you want to use nop_convert here, for sure a truncation or
> extension wouldn't be valid?
Oh, yes, should be nop_convert.
> I think you don't need :c on both the inner plus and the bit_xor here?
Sure, could you please help to explain more about when should
These subroutines will be used in expand_const_vector in a future patch.
Relocate so expand_const_vector can use them.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vector_init_insert_elems): Relocate.
(expand_vector_init_trailing_same_elem): Ditto.
Signed-off-by: Patrick O'Ne
The comment previously here stated that the Wc0/Wc1 cases are handled by
the vi constraint but that is not true for the 0.0 Wc0 case.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_const_insns): Handle 0.0 floating-point
case.
Signed-off-by: Patrick O'Neill
---
Ack'd here:
https
This patch adds some advanced checking to assert that the emitted costs match
emitted patterns for const_vecs.
Flow:
Costing: Insert into hashmap>
Expand: Check for membership in hashmap
-> Not in hashmap: ignore, this wasn't costed
-> In hashmap: Iterate over vec
-> if RTX not in hashmap: I
The corresponding expander (riscv-v.cc:expand_const_vector) matches
const_vec_duplicate_p before const_vec_series_p. Reorder to match this
behavior when calculating costs.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_const_insns): Relocate.
Signed-off-by: Patrick O'Neill
---
Ack'd here
This manifests in RTL that is optimized away which causes runtime failures
in the testsuite. Update all patterns to use a temp result register if required.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Use tmp register if
needed.
Signed-off-by: Patrick O'Neill
Also explicitly disallow CONST_VECTOR_DUPLICATE_P for now.
CONST_VECTOR_DUPLICATE_P was previously disallowed implicitly.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vec_series): Update comment.
(expand_vector_init_insert_elems): Ditto.
(expand_const_vector): Add catc
Currently we assert when encountering a non-duplicate boolean vector.
This patch allows non-duplicate vectors to fall through to the
gcc_unreachable and assert there.
This will be useful when adding a catch-all pattern to emit costs and
handle arbitary vectors.
gcc/ChangeLog:
* config/ri
These cases are handled in the expander
(riscv-v.cc:expand_const_vector). We need the vector builder to detect
these cases so extract that out into a new riscv-v.h header file.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (class rvv_builder): Move to riscv-v.h.
* config/riscv/riscv.cc
Prior to this patch the expander would emit vectors like:
{ 0, 0, 5, 5, 10, 10, ...}
as:
{ 0, 0, 2, 2, 4, 4, ...}
This patch sets the step size to the requested value.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Fix STEP size in
expander.
Signed-off-by: Pat
Constant vectors are currently spilled/loaded from memory often. This series
increases the number of costed patterns via a catch-all pattern and fixes a
variety of bugs I found along the way.
v2 Changelog:
* Landed patch 1/9 from v1 of this patchset.
* Add new valid_vec_immediate_p helper
* Reorde
On Fri, Jul 19, 2024 at 11:08 AM Jeff Law wrote:
>
>
>
> On 7/19/24 2:55 AM, demin.han wrote:
> > Currently, some binops of vector vs double scalar under RV32 can't
> > translated to vf but vfmv+vxx.vv.
> >
> > The cause is that vec_duplicate is also expanded to broadcast for double
> > mode
> >
From: YunQiang Su
We have SHF.fmt and HADD_S/U.fmt with MSA, which can be used for
vector reduc.
For min/max for U8/S8, we can
SHF.B W1, W0, 0xb1 # swap byte inner every half
MIN.B W1, W1, W0
SHF.H W2, W1, 0xb1 # swap half inner every word
MIN.B W2, W2, W1
On Mon, Aug 26, 2024 at 11:01:08PM +0200, Martin Uecker wrote:
> Am Montag, dem 26.08.2024 um 13:30 -0700 schrieb Kees Cook:
> > On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> > > Hi, Martin,
> > >
> > > Looks like that there is some issue when I tried to use the _Generic for
> > >
Ping...
> From: Hans-Peter Nilsson
> Date: Mon, 19 Aug 2024 00:28:30 +0200
>
> As noticed when verifying the dejagnu fix. Tested cris-elf
> with a new newlib that arranges to emit the mentioned
> warning, with/without the update in dejagnu to handle the
> miniscule "in". Ok to commit?
>
> --
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-14.2.
CodeView has two ways of recording struct member functions.
Non-overloaded functions have an LF_ONEMETHOD sub-type in the field
list, which records the name and the function type (LF_MFUNCTION).
Overloaded functions have an LF_METHOD instead, which points to an
LF_METHODLIST, which is an array of l
Record LF_STMEMBER field list subtypes to represent static data members
in structs.
gcc/
* dwarf2codeview.cc (enum cv_leaf_type): Add LF_STMEMBER.
(struct codeview_subtype): Add lf_static_member to union.
(write_lf_fieldlist): Handle LF_STMEMBER.
(add_struct_member)
If a function is in a namespace, create an LF_STRING_ID type for the
name of its parent, and record this in the LF_FUNC_ID type we create
for the function.
gcc/
* dwarf2codeview.cc (enum cf_leaf_type): Add LF_STRING_ID.
(struct codeview_custom_type): Add lf_string_id to union.
If recording the definition of a struct member function, write an
LF_MFUNC_ID type rather than an LF_FUNC_ID. This links directly to the
struct type, rather than to an LF_STRING_ID with its name.
gcc/
* dwarf2codeview.cc (enum cv_leaf_type): Add LF_MFUNC_ID.
(write_lf_mfunc_id): Ne
Run all CodeView names through a new function get_name, which chains
together a DIE's DW_AT_name with that of its parent to create a
C++-style name.
gcc/
* dwarf2codeview.cc (get_name): New function.
(add_enum_forward_def): Call get_name.
(get_type_num_enumeration_type): Ca
Am Montag, dem 26.08.2024 um 13:30 -0700 schrieb Kees Cook:
> On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> > Hi, Martin,
> >
> > Looks like that there is some issue when I tried to use the _Generic for
> > the testing cases, and then I narrowed down to a
> > small testing case tha
Currently the behaviour of Wmissing-field-initializers is inconsistent
between C and C++. The C warning assumes that missing designated
initializers are deliberate, and does not warn. The C++ warning does warn
for missing designated initializers.
This patch changes the behaviour of Wmissing-field
On Mon, Aug 26, 2024 at 07:30:15PM +, Qing Zhao wrote:
> Hi, Martin,
>
> Looks like that there is some issue when I tried to use the _Generic for the
> testing cases, and then I narrowed down to a
> small testing case that shows the problem without any change to GCC.
>
> [opc@qinzhao-ol8u3-x
> On Aug 26, 2024, at 10:40 AM, Michael Matz wrote:
>
> Hello,
>
> On Mon, 26 Aug 2024, Paul Koning wrote:
>
> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> 551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> 552: [--sp] = r37 sp_off = -8 {mo
Am Montag, dem 26.08.2024 um 19:30 + schrieb Qing Zhao:
> Hi, Martin,
>
> Looks like that there is some issue when I tried to use the _Generic for the
> testing cases, and then I narrowed down to a
> small testing case that shows the problem without any change to GCC.
>
> [opc@qinzhao-ol8u3-
On Thu, Aug 22, 2024 at 8:03 AM Qing Zhao wrote:
> > On Aug 21, 2024, at 18:08, Bill Wendling wrote:
> >> For the unary operator __counted_by(PTR), “PTR” must have a counted_by
> >> attribute, if not, there will be a compilation time error.
> >>
> >> Then the user could write the following cod
On Wed, Aug 21, 2024 at 8:43 AM Martin Uecker wrote:
>
> Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao:
> > >
> > > But if we changed it to return a void pointer, we could make this
> > > a compile-time check:
> > >
> > > auto ret = __builtin_get_counted_by(__p->FAM);
> > >
> > > _
Hi, Martin,
Looks like that there is some issue when I tried to use the _Generic for the
testing cases, and then I narrowed down to a
small testing case that shows the problem without any change to GCC.
[opc@qinzhao-ol8u3-x86 gcc]$ cat t1.c
struct annotated {
char b;
int c[];
} *array_annota
On 8/20/24 11:52 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk only?
OK.
-- >8 --
Extending the PR113063 testcase to additionally constant evaluate the <=>
expression causes us to trip over the assert in cxx_eval_call_expression
/
Am 25.08.24 um 18:15 schrieb Denis Chertykov:
Starting to review the patch...
Denis
Great to see you back!
Prior to commenting on the attached new versions of
the overhaul, let me answer Jeff's questions from the
other mail:
On 8/23/24 6:16 AM, Georg-Johann Lay wrote:
This patch overhauls
вс, 25 авг. 2024 г. в 20:15, Denis Chertykov :
>
>
>
> вс, 25 авг. 2024 г. в 17:55, Jeff Law :
>>
>>
>>
>> On 8/23/24 6:20 AM, Richard Biener wrote:
>> > On Fri, Aug 23, 2024 at 2:16 PM Georg-Johann Lay wrote:
>> >>
>> >> This patch overhauls the avr-ifelse mini-pass that optimizes
>> >> two cbran
On 8/24/24 09:13, Tobias Burnus wrote:
+@node Foreign-runtime support for AMD GPUs
+@subsection OpenMP @code{interop} -- Foreign-Runtime Support for AMD GPUs
Em-dash in Texinfo is three dashes with no surrounding spaces. I
believe that the libgomp manual uses the incorrect markup you have he
On 8/26/24 2:34 PM, Iain Sandoe wrote:
Hi Jason,
As the PR notes, we now have two bogus warnings that the single frame
pointer parameter is unused in each of the helper functions.
This started when we began to use start_preparsed_function/finish_function
to wrap the helper function code generat
Hi Jason,
>>As the PR notes, we now have two bogus warnings that the single frame
>>pointer parameter is unused in each of the helper functions.
>>This started when we began to use start_preparsed_function/finish_function
>>to wrap the helper function code generation. I am puzzled a little about
On 8/26/24 10:33 AM, Iain Sandoe wrote:
As the PR notes, we now have two bogus warnings that the single frame
pointer parameter is unused in each of the helper functions.
This started when we began to use start_preparsed_function/finish_function
to wrap the helper function code generation. I am
On 8/26/24 12:49 PM, Simon Martin wrote:
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cut here ===
struct X {};
void g () {
X::X x;
}
=== cut here ===
The problem is that we use %<%T::%D%> to build the error message, whi
On 8/24/24 9:55 AM, Jonathan Wakely wrote:
On Sat, 24 Aug 2024 at 14:14, Jason Merrill wrote:
On 8/23/24 8:41 AM, Jonathan Wakely wrote:
Tested x86_64-linux. OK for trunk?
OK.
I've just noticed that this changes the copyright dates from 2022-2024
to just 2024 (see the excerpts of the patch
On 8/25/24 12:37 PM, Simon Martin wrote:
On 24 Aug 2024, at 23:59, Simon Martin wrote:
On 24 Aug 2024, at 15:13, Jason Merrill wrote:
On 8/23/24 12:44 PM, Simon Martin wrote:
We currently emit an incorrect -Woverloaded-virtual warning upon the
following
test case
=== cut here ===
struct A
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cut here ===
struct X {};
void g () {
X::X x;
}
=== cut here ===
The problem is that we use %<%T::%D%> to build the error message, while
%qE does exactly what we need since we ha
Previously diagnostic_context::report_diagnostic had, after the call to
pp_format (phases 1 and 2 of formatting the message):
m_output_format->on_begin_diagnostic (*diagnostic);
pp_output_formatted_text (this->printer, m_urlifier);
if (m_show_cwe)
print_any_cwe (*diagnostic);
if (m_sho
Add test coverage of "%@" in event messages in a multithreaded
execution path.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3199-g6a1c359e28442c.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-paths-multithreaded-inline-events.c:
In particular, move the classic text output code to a
diagnostic-text.cc (analogous to -json.cc and -sarif.cc).
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3201-g92c5265d22afaa.
gcc/ChangeLog:
* Makefile.in (OBJS-li
In r15-2354-g4d1f71d49e396c I added the ability to use Python to write
tests of SARIF output via a new "run-sarif-pytest" based
on "run-gcov-pytest", with a sarif.py support script in
testsuite/gcc.dg/sarif-output.
This followup patch:
(a) removes the limitation of such tests needing to be in
test
Add selftest coverage for %{ and %} in pretty-print.cc
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3197-g276cc4324b9e8d.
gcc/ChangeLog:
* pretty-print.cc (selftest::test_urls): Make static.
(selftest::test_u
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3196-gb835710328847a.
gcc/ChangeLog:
* json.h: Fix typo in comment about missing INCLUDE_MEMORY.
Signed-off-by: David Malcolm
---
gcc/json.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 8/23/24 07:03, Tobias Burnus wrote:
Add documentation for OpenMP's interoperability routines.
I have only a few copy-editing type comments.
+Implementation remark: In GCC, the Fortran interface differs from the one shown
+below: the function has C binding, @var{interop} is passed by value
On Linux/x86_64,
889f6dd0d8c7317f62578c900c0f662e919786a2 is the first bad commit
commit 889f6dd0d8c7317f62578c900c0f662e919786a2
Author: Mo, Zewei
Date: Mon Aug 26 10:53:50 2024 +0800
AVX10.2: Support minmax instructions
caused
FAIL: gcc.target/i386/avx10_2-minmax-1.c (test for excess e
On Linux/x86_64,
f6fe2962daf7b8d8532c768c3b9eab00f99cce5b is the first bad commit
commit f6fe2962daf7b8d8532c768c3b9eab00f99cce5b
Author: Zhang, Jun
Date: Mon Aug 26 10:53:52 2024 +0800
AVX10.2: Support vector copy instructions
caused
FAIL: gcc.target/i386/avx10_2-vmovd-1.c (test for exc
On Linux/x86_64,
2a046117a8376578337dc385f171e908155782b7 is the first bad commit
commit 2a046117a8376578337dc385f171e908155782b7
Author: Levy Hsu
Date: Mon Aug 26 10:53:41 2024 +0800
AVX10.2: Support convert instructions
caused
FAIL: gcc.target/i386/avx10_2-convert-1.c (test for excess
On Linux/x86_64,
576bd309ded9dfe258023f26924c064a7bf12875 is the first bad commit
commit 576bd309ded9dfe258023f26924c064a7bf12875
Author: Zhang, Jun
Date: Mon Aug 26 10:53:54 2024 +0800
AVX10.2: Support compare instructions
caused
FAIL: gcc.target/i386/avx10_2-compare-1.c (test for exces
On Linux/x86_64,
9023662464ac7a0bbac72d94078ea0845bf99c86 is the first bad commit
commit 9023662464ac7a0bbac72d94078ea0845bf99c86
Author: konglin1
Date: Mon Aug 26 10:53:43 2024 +0800
[PATCH 1/2] AVX10.2: Support BF16 instructions
caused
FAIL: gcc.target/i386/avx10_2-bf16-1.c (test for e
On Linux/x86_64,
af0a06274fce2ca64456f5b13b4bc8ff864a45e4 is the first bad commit
commit af0a06274fce2ca64456f5b13b4bc8ff864a45e4
Author: Haochen Jiang
Date: Mon Aug 26 10:53:39 2024 +0800
[PATCH 2/2] AVX10.2: Support media instructions
caused
FAIL: gcc.target/i386/avx10_2-builtin-2.c (t
On Linux/x86_64,
8db80b2735782d793a83a9ef7eb012d83be7660d is the first bad commit
commit 8db80b2735782d793a83a9ef7eb012d83be7660d
Author: Hongyu Wang
Date: Mon Aug 26 10:53:37 2024 +0800
[PATCH 1/2] AVX10.2: Support media instructions
caused
FAIL: gcc.target/i386/avx10_2-builtin-1.c (tes
Hi!
On Thu, Aug 22, 2024 at 08:48:19PM -0500, Peter Bergner wrote:
> I was a little surprised we didn't have that macro already. Ok, consider
> it changed with your suggestion.
>
> I agree, there probably is code in the backend that currently handles TImode
> that should probably be changed to h
Hi!
On Thu, Aug 22, 2024 at 05:39:36PM +0800, Kewen.Lin wrote:
> > - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
> > + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
> > + || mode == PTImode)
>
> Maybe we can introduce a macro to this file like
>
On Mon, Aug 26, 2024 at 2:44 AM Jeff Law wrote:
>
>
> On 8/20/24 5:41 AM, Richard Biener wrote:
>
> >
> > So the store-merging variant IIRC tracks a single overall source
> > only (unless it was extended and I missed that) and operates at
> > a byte granularity. I did want to extend it to suppor
On 8/26/24 4:26 AM, Simon Martin wrote:
Hi Jason,
On 22 Aug 2024, at 19:28, Jason Merrill wrote:
On 8/22/24 12:51 PM, Simon Martin wrote:
We currently ICE upon the following invalid code, because we don't
check the
number of template parameters in member class template
specializations. This
p
On 8/22/24 7:51 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
After importing a header unit we learn about and setup any header
modules that we transitively depend on. However, this causes
'set_filename' to fail an assertion if we t
On 8/22/24 7:49 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently the handling of include translation is confusing to read,
using a tri-state integer without much clarity on what different states
mean. This patch cleans this u
> -Original Message-
> From: Marc Glisse
> Sent: Monday, August 26, 2024 4:46 AM
> To: Richard Biener
> Cc: Andrew Pinski (QUIC) ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 3/3] Match: Add pattern for `(a ? b : 0) | (a
> ? 0 : c)` into `a ? b : c` [PR103660]
>
> >> --- a/gcc/match
Hello,
On Mon, 26 Aug 2024, Paul Koning wrote:
> >>> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> >>> 551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> >>> 552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
> >>> 554: [--sp] = r116 - r37sp_off = -12 {su
As the PR notes, we now have two bogus warnings that the single frame
pointer parameter is unused in each of the helper functions.
This started when we began to use start_preparsed_function/finish_function
to wrap the helper function code generation. I am puzzled a little about
why the use is not
On 8/23/24 3:49 PM, Arsen Arsenović wrote:
Iain Sandoe writes:
static tree
get_awaitable_var (suspend_point_kind suspend_kind, tree v_type)
{
- static int awn = 0;
+ auto cinfo = get_coroutine_info (current_function_decl);
+ gcc_assert (cinfo);
If the purpose of this is to check for mista
> On Aug 26, 2024, at 10:14 AM, Michael Matz wrote:
>
> Hello,
>
> On Sun, 25 Aug 2024, Jeff Law wrote:
>
>>> 550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
>>> 551: [--sp] = 37sp_off = -4 {pushexthisi_const}
>>> 552: [--sp] = r37 sp_off = -8 {movsi_m
Hello,
On Sun, 25 Aug 2024, Jeff Law wrote:
> >550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
> >551: [--sp] = 37sp_off = -4 {pushexthisi_const}
> >552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
> >554: [--sp] = r116 - r37sp_off = -12 {subsi3}
>
The following avoids removing stmts with defs that might still have
uses in the IL before calling simple_dce_from_worklist which might
remove those as that will wreck debug stmt generation. Instead first
perform use-based DCE and then remove stmts which may have uses in
code that CFG cleanup will
On 8/26/24 4:26 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to allow IMM for the operand 1 of ussub pattern.
Aka .SAT_SUB(x, 22) as the below example.
Form 2:
#define DEF_SAT_U_SUB_IMM_FMT_2(T, IMM) \
T __attribute__((noinline)) \
sat_u_sub_imm##IMM#
On Sat, 24 Aug 2024, Filip Kastl wrote:
> Hi,
>
> bootstrapped and regtested on x86_64-linux. Ok to push?
>
> Cheers,
> Filip Kastl
>
>
> -- 8< --
>
>
> The gen_pow2p function generates (a & -a) == a as a fallback for
> POPCOUNT (a) == 1. Not only is the bitmagic not equivalent to
> POPCOU
On Mon, Aug 26, 2024 at 4:20 AM wrote:
>
> From: Pan Li
>
> This patch would like to support the form 1 of the scalar signed
> integer .SAT_ADD. Aka below example:
>
> Form 1:
> #define DEF_SAT_S_ADD_FMT_1(T, UT, MIN, MAX) \
> T __attribute__((noinline)) \
> sat_s_add_##T#
On Mon, 26 Aug 2024, Bernd Edlinger wrote:
> On 8/26/24 10:31, Richard Biener wrote:
> > On Mon, 26 Aug 2024, Bernd Edlinger wrote:
> >
> >> This recent change triggered various bootsteap-errors, mostly on
> >> x86 targets because line info advance address entries were output
> >> in the wrong se
On 8/26/24 10:31, Richard Biener wrote:
> On Mon, 26 Aug 2024, Bernd Edlinger wrote:
>
>> This recent change triggered various bootsteap-errors, mostly on
>> x86 targets because line info advance address entries were output
>> in the wrong section table.
>> The switch to the wrong line table happe
The following improves forwprop block reachability which I noticed
when debugging PR116460 and what is also noted in the comment. It
avoids processing blocks in natural loops determined unreachable,
thereby making the issue in PR116460 latent.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
SSA forwprop has switch simplification code that calls remove edge
and as side-effect releases dominator info. For a followup we want
to retain that so the following delays removing edges until the end
of the pass. As usual we have to deal with parts of the edge
vanishing due to EH/abnormal pruni
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2339,6 +2339,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (INTEGRAL_TYPE_P (type))
(bit_and @0 @1)))
+/* Fold `(a ? b : 0) | (a ? 0 : c)` into (a ? b : c).
+Handle also ^ and + in replacement of `|`. */
+(for cnd (cond vec_cond)
+ (for op (bit_
Hi,
For the following test (adapted from pr96390.c):
__attribute__((noipa)) int foo () { return 42; }
int bar () __attribute__((alias ("foo")));
int baz () __attribute__((alias ("bar")));
int main ()
{
int n;
#pragma omp target map(from:n)
n = baz ();
return n;
}
Compiling with -fopenm
From: Pan Li
This patch would like to allow IMM for the operand 1 of ussub pattern.
Aka .SAT_SUB(x, 22) as the below example.
Form 2:
#define DEF_SAT_U_SUB_IMM_FMT_2(T, IMM) \
T __attribute__((noinline)) \
sat_u_sub_imm##IMM##_##T##_fmt_2 (T x) \
{
On Mon, Aug 26, 2024 at 9:47 AM wrote:
>
> From: Pan Li
>
> This patch would like to add strict check for imm operand of .SAT_ADD
> matching. We have no type checking for imm operand in previous, which
> may result in unexpected IL to be catched by .SAT_ADD pattern.
>
> We leverage the int_fits_
On Mon, Aug 26, 2024 at 9:34 AM liuhongt wrote:
>
> Also try to handle redundant broadcasts when there's already a
> broadcast to a bigger mode with exactly the same component value.
> For broadcast, component mode needs to be the same.
> For all-zeros/ones, only need to check the bigger mode.
>
>
On Sun, Aug 25, 2024 at 10:28 PM Andrew Pinski wrote:
>
> When expanding popcount used for equal to 1 (or rather
> __builtin_stdc_has_single_bit),
> the wrong mode was bsing used for the mode of the store flags. We were using
> the mode
> of the argument to popcount but since popcount's return v
On Mon, 26 Aug 2024, Aldy Hernandez wrote:
> [I'm slowly coming up to speed here after my absence, so please bear with
> me...]
>
> I suspect there's a few things going on here, both in the forward and
> the backwards threader. For the forward threader, you mention some
> very good points in th
On Mon, 26 Aug 2024, Bernd Edlinger wrote:
> This recent change triggered various bootsteap-errors, mostly on
> x86 targets because line info advance address entries were output
> in the wrong section table.
> The switch to the wrong line table happened in dwarfout_set_ignored_loc.
> It must use t
Hi Jason,
On 22 Aug 2024, at 19:28, Jason Merrill wrote:
> On 8/22/24 12:51 PM, Simon Martin wrote:
>> We currently ICE upon the following invalid code, because we don't
>> check the
>> number of template parameters in member class template
>> specializations. This
>> patch fixes the PR by addi
Remove texinfo statements which are obsolete for a while now.
libgccjit.texi:18: warning: @definfoenclose is obsolete
libgccjit.texi:19: warning: @definfoenclose is obsolete
gcc/jit:
* docs/_build/texinfo/libgccjit.texi: Remove obsolete texinfo
statements.
Signed-off-by: Wilken Gottwalt
From: Pan Li
This patch would like to add strict check for imm operand of .SAT_ADD
matching. We have no type checking for imm operand in previous, which
may result in unexpected IL to be catched by .SAT_ADD pattern.
We leverage the int_fits_type_p here to make sure the imm operand is
a int type
Also try to handle redundant broadcasts when there's already a
broadcast to a bigger mode with exactly the same component value.
For broadcast, component mode needs to be the same.
For all-zeros/ones, only need to check the bigger mode.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} and
For mode2 bigger than 16-bytes, when it can be allocated to FIRST_SSE_REGS,
then it can only be allocated to ALL_SSE_REGS, and it can be tiebale
to all mode1 with smaller size which is available to FIRST_SSE_REGS.
When modes is equal to 16 bytes, exclude non-vector modes(TI/TFmode).
This is need fo
On Mon, 26 Aug 2024, Xi Ruoyao wrote:
> After fixing PR116142 some code started to trigger an ICE with -O3
> -march=znver4. Per Richard Biener who actually made this fix:
>
> "supportable_widening_operation fails at transform time - that's likely
> because vectorizable_reduction "puns" defs to i
95 matches
Mail list logo
