On Fri, Feb 10, 2023 at 3:38 AM Andrew MacLeod wrote:
>
>
> The change for 108356 allowed the cache to scan the dominator trees when
> it was attempting a lookup rather than using the local value. I
> inadvertantly changed the external interface to also do this, so all the
> GORI queries via rang
On Fri, Feb 10, 2023 at 2:47 AM Andrew Pinski via Gcc-patches
wrote:
>
> In simple_dce_from_worklist, we were removing an inline-asm which had a vdef.
> We should not be removing inline-asm which have a vdef as this code
> does not check to the store.
> This fixes that oversight. This was a latent
On Fri, Feb 10, 2023 at 1:02 AM Andrew MacLeod via Gcc-patches
wrote:
>
> I was about to ping on this, and then found it in my drafts.. Doh!
>
>
> get_range_global() can invoke tree.cc::nonnull_arg_p() if the item being
> queried is a pointer and a parameter. This routine assumes the context
> is
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vaadd_vv-1.C: New test.
* g++.target/riscv/rvv/base/vaadd_vv-2.C: New test.
* g++.target/riscv/rvv/base/vaadd_vv-3.C: New test.
* g++.target/riscv/rvv/base/vaadd_vv_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vaaddu_vv-1.C: New test.
* g++.target/riscv/rvv/base/vaaddu_vv-2.C: New test.
* g++.target/riscv/rvv/base/vaaddu_vv-3.C: New test.
* g++.target/riscv/rvv/base/vaaddu_vv_mu-1.C: New test.
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vasub_vv-1.C: New test.
* g++.target/riscv/rvv/base/vasub_vv-2.C: New test.
* g++.target/riscv/rvv/base/vasub_vv-3.C: New test.
* g++.target/riscv/rvv/base/vasub_vv_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vasubu_vv-1.C: New test.
* g++.target/riscv/rvv/base/vasubu_vv-2.C: New test.
* g++.target/riscv/rvv/base/vasubu_vv-3.C: New test.
* g++.target/riscv/rvv/base/vasubu_vv_mu-1.C: New test.
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vsmul_vv-1.C: New test.
* g++.target/riscv/rvv/base/vsmul_vv-2.C: New test.
* g++.target/riscv/rvv/base/vsmul_vv-3.C: New test.
* g++.target/riscv/rvv/base/vsmul_vv_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vssra_vv-1.C: New test.
* g++.target/riscv/rvv/base/vssra_vv-2.C: New test.
* g++.target/riscv/rvv/base/vssra_vv-3.C: New test.
* g++.target/riscv/rvv/base/vssra_vv_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vssra_vx-1.C: New test.
* g++.target/riscv/rvv/base/vssra_vx-2.C: New test.
* g++.target/riscv/rvv/base/vssra_vx-3.C: New test.
* g++.target/riscv/rvv/base/vssra_vx_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vssrl_vv-1.C: New test.
* g++.target/riscv/rvv/base/vssrl_vv-2.C: New test.
* g++.target/riscv/rvv/base/vssrl_vv-3.C: New test.
* g++.target/riscv/rvv/base/vssrl_vv_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vssrl_vx-1.C: New test.
* g++.target/riscv/rvv/base/vssrl_vx-2.C: New test.
* g++.target/riscv/rvv/base/vssrl_vx-3.C: New test.
* g++.target/riscv/rvv/base/vssrl_vx_mu-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/binop_vx_constraint-122.c: New test.
* gcc.target/riscv/rvv/base/vaadd_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vaadd_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vaadd_vv-3.c: New test.
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vaaddu_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vaaddu_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vaaddu_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vaaddu_vv_m-1.c: New test.
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vasub_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vasub_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vasub_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vasub_vv_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vasubu_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vasubu_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vasubu_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vasubu_vv_m-1.c: New test.
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vsmul_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vsmul_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vsmul_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vsmul_vv_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vssra_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vssra_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vssra_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vssra_vv_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vssra_vx-1.c: New test.
* gcc.target/riscv/rvv/base/vssra_vx-2.c: New test.
* gcc.target/riscv/rvv/base/vssra_vx-3.c: New test.
* gcc.target/riscv/rvv/base/vssra_vx_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vssrl_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vssrl_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vssrl_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vssrl_vv_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vssrl_vx-1.c: New test.
* gcc.target/riscv/rvv/base/vssrl_vx-2.c: New test.
* gcc.target/riscv/rvv/base/vssrl_vx-3.c: New test.
* gcc.target/riscv/rvv/base/vssrl_vx_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (class sat_op): New class.
(class vnclip): Ditto.
(BASE): Ditto.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
* config/riscv/riscv-vector-builtins-functions.def (vaadd)
The problem here is that aarch64_expand_setmem does not change the alignment
for strict alignment case.
This is version 4 of the fix, major changes from the last version is fixing
the way store pairs are handled which allows handling of storing 2 SI mode
at a time.
This also adds a testcase to show
Resend this patch...
v4: Update per comments.
v3: rename altivec_vmrghb_direct_le to altivec_vmrglb_direct_le to match
the actual output ASM vmrglb. Likewise for all similar xxx_direct_le
patterns.
v2: Split the direct pattern to be and le with same RTL but different insn.
The native RTL expressi
The change for 108356 allowed the cache to scan the dominator trees when
it was attempting a lookup rather than using the local value. I
inadvertantly changed the external interface to also do this, so all the
GORI queries via range_on_edge of the cache could also do lookups in
this mode.
In simple_dce_from_worklist, we were removing an inline-asm which had a vdef.
We should not be removing inline-asm which have a vdef as this code
does not check to the store.
This fixes that oversight. This was a latent bug exposed recently
by both VRP and removal of stores to static starting to us
On Thu, 9 Feb 2023, Jason Merrill wrote:
> On 2/9/23 09:36, Patrick Palka wrote:
> > On Sun, 5 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/3/23 15:51, Patrick Palka wrote:
> > > > On Mon, 30 Jan 2023, Jason Merrill wrote:
> > > >
> > > > > On 1/27/23 17:02, Patrick Palka wrote:
> > > > > > Thi
WG14 has agreed to allow conversions (explicit and implicit) from null
pointer constants to nullptr_t; update GCC's nullptr_t implementation
to match.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-convert.cc (c_convert): Allow conversion of a null pointer
co
I was about to ping on this, and then found it in my drafts.. Doh!
get_range_global() can invoke tree.cc::nonnull_arg_p() if the item being
queried is a pointer and a parameter. This routine assumes the context
is CFUN, and this is not always true.
This patch simply adds a function context
On 2/8/23 18:15, Marek Polacek wrote:
On Wed, Feb 08, 2023 at 04:00:25PM -0800, Jason Merrill wrote:
On 2/8/23 13:01, Marek Polacek wrote:
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x
On 2/9/23 09:36, Patrick Palka wrote:
On Sun, 5 Feb 2023, Jason Merrill wrote:
On 2/3/23 15:51, Patrick Palka wrote:
On Mon, 30 Jan 2023, Jason Merrill wrote:
On 1/27/23 17:02, Patrick Palka wrote:
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization ba
Please verify your identity by visiting Cash Support using your Cash App
PR analyzer/108733 reports various false positives in qemu from
-Wanalyzer-use-of-uninitialized-value with __attribute__((cleanup))
at -O1 and above.
Root cause is that the state-purging code was failing to treat:
_25 = MEM[(void * *)&val];
as a usage of "val", leading to it erroneously purging
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vmv_v_x_rv32-1.c: New test.
* gcc.target/riscv/rvv/base/vmv_v_x_rv32-2.c: New test.
* gcc.target/riscv/rvv/base/vmv_v_x_rv32-3.c: New test.
* gcc.target/riscv/rvv/base/vmv_v_x_rv64-1.c: New te
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vmv_v_v-1.c: New test.
* gcc.target/riscv/rvv/base/vmv_v_v-2.c: New test.
* gcc.target/riscv/rvv/base/vmv_v_v-3.c: New test.
* gcc.target/riscv/rvv/base/vmv_v_v_tu-1.c: New test.
* gcc
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vncvt_x-1.c: New test.
* gcc.target/riscv/rvv/base/vncvt_x-2.c: New test.
* gcc.target/riscv/rvv/base/vncvt_x-3.c: New test.
* gcc.target/riscv/rvv/base/vncvt_x_m-1.c: New test.
* gcc.
This is another try to solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
The patch was successfully bootstrapped (--enable-languages=all) and
tested on x86, x86-64, aarch64
commit 1ad898d18904ac68432ba9b8ffa2b083d007cc2d
Author: Vladimir N. Makarov
Date: Thu Feb 9 15:18:48 2023 -0500
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wbr): Remove unused constraint.
* config/riscv/predicates.md: Fix move operand predicate.
* config/riscv/riscv-vector-builtins-bases.cc (class vnshift): New
class.
(class vncvt_x): Ditto.
(c
Hello
I've ported my patch for supporting the OpenMP 5.1 'present' modifier
and committed it to the devel/omp/gcc-12 development branch:
229b705862c openmp: Add support for the 'present' modifier
Tested with offloading on amdgcn and nvptx.
Kwok
Dear all,
the attached trivial and obvious patch replaces an internal error
on encountering an invalid kind in a character conversion by a
regular error recovery.
Pushed after regtesting on x86_64-pc-linux-gnu as
r13-5760-ga618b45ac41cf480f54c4fa4014aed6218931290
Thanks,
Harald
From a618b45ac41
This patch introduces instruction patterns for complex number operations
in the GCN machine description. These patterns are cmul, cmul_conj,
vec_addsub, vec_fmaddsub, vec_fmsubadd, cadd90, cadd270, cmla and cmls
(cmla_conj and cmls_conj were not found to be favorable to implement).
As a side ef
On Thu, Feb 9, 2023 at 11:10 AM Palmer Dabbelt wrote:
>
> On Thu, 09 Feb 2023 01:48:25 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> > PR target/108723
> > * gcc.target/riscv/shorten-memrefs-1.c: Adjust patterns to skip
> > over cfi directives.
> > * gcc.target/riscv/shorten-memrefs-2.c: Likewise.
On Thu, 09 Feb 2023 01:48:25 PST (-0800), gcc-patches@gcc.gnu.org wrote:
PR target/108723
* gcc.target/riscv/shorten-memrefs-1.c: Adjust patterns to skip
over cfi directives.
* gcc.target/riscv/shorten-memrefs-2.c: Likewise.
* gcc.target/riscv/shorten-memrefs-3.c: Likewise.
* gcc.target/riscv/sho
On Thu, 9 Feb 2023, Patrick Palka wrote:
> When substituting into sizeof(expr), tsubst_copy_and_build elides
> substitution into the operand if args is NULL_TREE, and instead
> considers the TREE_TYPE of the operand. But here the (templated)
> operand is a TEMPLATE_ID_EXPR with empty TREE_TYPE, s
When substituting into sizeof(expr), tsubst_copy_and_build elides
substitution into the operand if args is NULL_TREE, and instead
considers the TREE_TYPE of the operand. But here the (templated)
operand is a TEMPLATE_ID_EXPR with empty TREE_TYPE, so we can't elide
substitution in this case.
Contr
In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide
the Y::Y(const Y&) call used to initialize o.c. So store_init_value
-> cxx_constant_init must constexpr-evaluate the call to Y::Y(const Y&)
in cxx_eval_call_expression. It's a trivial function, so we do the
"Shortcut trivial cons
On Sun, 5 Feb 2023, Jason Merrill wrote:
> On 2/3/23 15:51, Patrick Palka wrote:
> > On Mon, 30 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/27/23 17:02, Patrick Palka wrote:
> > > > This PR illustrates that __builtin_is_constant_evaluated currently acts
> > > > as an optimization barrier for ou
Hi All,
This replaces the custom division hook with just an implementation through
add_highpart. For NEON we implement the add highpart (Addition + extraction of
the upper highpart of the register in the same precision) as ADD + LSR.
This representation allows us to easily optimize the sequence
Hi All,
As discussed in the ticket, this replaces the approach for optimizing the
div by bitmask operation from a hook into optabs implemented through
add_highpart.
In order to be able to use this we need to check whether the current precision
has enough bits to do the operation without any of th
On Thu, Feb 09, 2023 at 02:40:57PM +, Qing Zhao wrote:
> So, the major question here is:
>
> in addition to the C99 standard flexible array member [ ], shall we include
> [0], [1] or even [4] into this extension, and treat the structure with a
> trailing [0], [1], or [4] embedded into anoth
On Thu, Feb 9, 2023 at 4:43 PM Jakub Jelinek wrote:
>
> On Thu, Feb 09, 2023 at 07:30:52AM -0800, H.J. Lu wrote:
> > On Thu, Feb 9, 2023 at 4:12 AM Jakub Jelinek wrote:
> > > get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
> > > and just sets stuff up based on CPUID leaf
Hi!
Martin Liska mentioned that porting_to.html doesn't mention
the C++ excess precision changes. Not really sure if porting_to
should document those, but I think changes.html certainly should.
And perhaps porting_to could have some examples and link to this
spot in changes.
Ok for wwwdocs?
---
Hi!
The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.
Now, as reported, the testcase compiles fine, but
On Thu, Feb 09, 2023 at 10:15:22AM +0800, Xionghu Luo wrote:
> Thanks Kewen!
> Ping this again @Segher.
> Maybe we could also merge this patch if no objections from Segher as
> several reviews and tests taken on this already...
Please send the patch as the head of its own thread, not as a reply d
On Thu, Feb 09, 2023 at 07:30:52AM -0800, H.J. Lu wrote:
> On Thu, Feb 9, 2023 at 4:12 AM Jakub Jelinek wrote:
> > get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
> > and just sets stuff up based on CPUID leaf 1, or some extended ones,
> > so I wonder why are we calling i
On Thu, Feb 9, 2023 at 4:12 AM Jakub Jelinek wrote:
>
> Hi!
>
> get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
> and just sets stuff up based on CPUID leaf 1, or some extended ones,
> so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
> and not for a
On Thu, Feb 9, 2023 at 12:07 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Feb 8, 2023 at 8:14 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > In simple_dce_from_worklist, we were removing an inline-asm which had a vdef
> > (due to clobbering memory) but not unlinking the statement's vde
On Thu, Feb 09, 2023 at 03:46:35PM +0100, Tobias Burnus wrote:
> I think the test coverage should be sufficient. Any further test idea?
> Otherwise, I would commit it now.
LGTM, thanks.
Jakub
Updated patch. Changes: the canonic(al) and the if/else(if) cosmetic
formatting changes.
Testcases: Additionally, I checked for the value of a zero-loop trip in
libgomp.fortran/non-rectangular-loop-1.f90 and added lastprivate to all
of .../non-rectangular-loop-{3,4}.f90 (unless the loop-iteration
> On Feb 8, 2023, at 6:18 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Feb 8, 2023, at 2:09 PM, Joseph Myers wrote:
>>
>> On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
>>
>>> But I noticed that “flexible_array_type_p” later was moved from FE to
>>> middle-end and put into tre
When the set of candidates becomes very large then repeated
bit checks on it during the build of an actual chain can become
slow because of the O(n) nature of bitmap tests. The following
switches the candidates bitmaps to the tree representation before
building the chains to get O(log n) amortized
The following does low-hanging optimizations, combining bitmap
test and set and removing redundant operations.
This shaves off half of the testcase compile time.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
PR target/108738
* config/i386/i386-feature
On Thu, Feb 9, 2023 at 10:57 AM Jakub Jelinek wrote:
>
> On Thu, Feb 09, 2023 at 09:16:17AM +0100, Richard Biener via Gcc-patches
> wrote:
> > On Wed, Feb 8, 2023 at 10:15 PM Andrew Pinski via Gcc-patches
> > wrote:
> > >
> > > The same problem as PR 88739 has crept in but
> > > this time in mat
> On Feb 9, 2023, at 5:35 AM, Richard Biener wrote:
>
> On Wed, 8 Feb 2023, Qing Zhao wrote:
>
>>
>>
>>> On Feb 7, 2023, at 6:37 PM, Joseph Myers wrote:
>>>
>>> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>>>
Then, this routine (flexible_array_type_p) is mainly for diagnosti
Just a quick heads-up to avoid duplication of work: we have a series
queued up for later this week (right now, SPEC2017 is still running
for QA purposes) that adds if-conversion support and converts that
into Zicond operations.
It doesn't have much overlap (except handling the "zicond" flag), as
we
Hi!
get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
and just sets stuff up based on CPUID leaf 1, or some extended ones,
so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
and not for all other CPUs too? I think various programs in the wild
which are
Hi!
On 2022-01-13T14:53:16+, Hafiz Abid Qadeer wrote:
> [...]
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/allocate-4.f90
> + use omp_lib
Pushed to devel/omp/gcc-12 branch
commit 7e1963a4e6ac97b6629c1e9e858ae28487f518cf
"'gfortran.dg/gomp/allocate-4.f90' -> 'libgomp.fortran/allo
Hi!
On 2022-05-06T21:20:48+0800, Chung-Lin Tang wrote:
> [...]
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/uses_allocators-1.c
> +#include
Etc.
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/uses_allocators-1.f90
> + use omp_lib
Etc.
Pushed to devel/omp/gcc-12 branch
Hi!
On 2022-03-08T11:30:59+, Hafiz Abid Qadeer wrote:
> From: Andrew Stubbs
>
> [...]
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/alloc-pinned-1.c
> @@ -0,0 +1,28 @@
> +/* { dg-do run } */
Pushed to devel/omp/gcc-12 branch
commit 9c0ffa3776a135a69697253a0bd75ebf9b9d0150
"'c-c++
From: yulong
[DO NOT MERGE]
Until 'ZiCond' extension is frozen/ratified and final version number is
determined, this patch should not be merged upstream. This commit uses
version 1.0 as in the documentation.
This commit adds support for the latest draft of RISC-V Integer Conditional
(ZiCond) ex
From: yulong
*** WAIT FOR SPECIFICATION FREEZE ***
This is an implementation for unratified and not frozen RISC-V extension
and not intended to be merged for now.
The intent to submit this patchset is to synchronize with the implementation
of binutils about the ZiCond extension.
This patchset ad
On 2/9/23 11:43, Gerald Pfeifer wrote:
> On Thu, 9 Feb 2023, Martin Liška wrote:
>> Document that the function does not work correctly for old VIA
>> processors.
>
> Thanks for doing this, Martin!
>
>> +Caveat: The built-in function does not work correctly on old VIA
>> +processors (Centaur fami
On Thu, 9 Feb 2023, Martin Liška wrote:
> Document that the function does not work correctly for old VIA
> processors.
Thanks for doing this, Martin!
> +Caveat: The built-in function does not work correctly on old VIA
> +processors (Centaur family).
Maybe say "This built-in function...", though
Document that the function does not work correctly for old
VIA processors.
Ready to be installed?
Thanks,
Martin
PR target/100758
gcc/ChangeLog:
* doc/extend.texi: Document that the function
does not work correctly for old VIA processors.
---
gcc/doc/extend.texi | 3 +++
On Wed, 8 Feb 2023, Qing Zhao wrote:
>
>
> > On Feb 7, 2023, at 6:37 PM, Joseph Myers wrote:
> >
> > On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
> >
> >> Then, this routine (flexible_array_type_p) is mainly for diagnostic
> >> purpose.
> >> It cannot be used to determine whether the
On Thu, Feb 09, 2023 at 11:16:39AM +0100, Tobias Burnus wrote:
> Any further comments before I commit it?
> OpenMP: Parse align clause in allocate directive in C/C++
>
> gcc/c/ChangeLog:
>
> * c-parser.cc (c_parser_omp_allocate): Parse align
> clause and check for restrictions.
>
> g
Updated patch included. Changes:
* Removed xfail for C++
* For C, I updated the comment as suggested.
* For C++: I updated/extended the FIXME comment and added the 'align'
check (the simple version as first suggested; I did not went for the one
which supports some templates.)
Any further comme
On Thu, Feb 09, 2023 at 09:16:17AM +0100, Richard Biener via Gcc-patches wrote:
> On Wed, Feb 8, 2023 at 10:15 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > The same problem as PR 88739 has crept in but
> > this time in match.pd when simplifying bit_field_ref of
> > an bit_insert. That is we a
PR target/108723
* gcc.target/riscv/shorten-memrefs-1.c: Adjust patterns to skip
over cfi directives.
* gcc.target/riscv/shorten-memrefs-2.c: Likewise.
* gcc.target/riscv/shorten-memrefs-3.c: Likewise.
* gcc.target/riscv/shorten-memrefs-4.c: Likewise.
* gcc.target/riscv/shorten-memrefs-5.c: Likewis
On Thu, Feb 09, 2023 at 09:56:09AM +0100, Tobias Burnus wrote:
> Found by chance recently; I thought about a couple of ways to handle it
> but then settled to the proposed solution.
>
> OK for mainline?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfs
(Updated to fix -m32 build, otherwise unchanged.)
Any other comments?
On 07.02.23 23:51, Thomas Schwinge wrote:
On 2023-02-06T12:52:11+0100, Tobias Burnus wrote:
Seems as if I missed a GOMP_MAP_TO_PSET issue before. As nvptx is
XFAILed before, I only found it when testing on AMDGCN.
For an
Found by chance recently; I thought about a couple of ways to handle it
but then settled to the proposed solution.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsfüh
Hi!
Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct
DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that
change we haven't emitted it at all for a while and after some time
started emitting incorrect locus, in particular the location of } closing
On Mon, Feb 6, 2023 at 4:27 PM Andreas Schwab via Gcc-patches
wrote:
>
> The -funwind-tables and -fasynchronous-unwind-tables options are relevant
> for the output pass, so they need to be passed through by the LTO wrapper.
> Otherwise, dwarf2out_assembly_start may output a ".cfi_sections
> .debug
On Wed, Feb 8, 2023 at 10:15 PM Andrew Pinski via Gcc-patches
wrote:
>
> The same problem as PR 88739 has crept in but
> this time in match.pd when simplifying bit_field_ref of
> an bit_insert. That is we are generating a BIT_FIELD_REF
> of a non-mode-precision integral type.
>
> OK? Bootstrapped
On Wed, Feb 8, 2023 at 8:14 PM Andrew Pinski via Gcc-patches
wrote:
>
> In simple_dce_from_worklist, we were removing an inline-asm which had a vdef
> (due to clobbering memory) but not unlinking the statement's vdef.
> This fixes that oversight. This was a latent bug exposed recently
> by both VR
86 matches
Mail list logo
