On Sun, May 16, 2021 at 7:35 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> While rewriting part of PHI-OPT to use match-and-simplify,
> I ran into a bug where this pattern in match.pd would hit
> and would produce invalid gimple; a shift of a pointer type.
>
> This just disable
On Sun, May 16, 2021 at 8:53 PM Joern Rennecke
wrote:
>
> For architectures with likely spilled register classes, neither
> register allocator is guaranteed
> to succeed when using optimization. If you have just a few files to
> compile, you can try
> by hand which compiler options will succeed a
On Sun, May 16, 2021 at 11:12 PM Joern Rennecke
wrote:
>
> braced_list_to_string creates a host string, so it's not suitable when
> e.g. the host
> has 8 bit chars, but the target has 16 bit chars.
>
> The attached patch checks if host and target char sizes are different
> and in that case
> fall
On Fri, May 14, 2021 at 2:23 AM Martin Sebor via Gcc-patches
wrote:
>
> On 5/13/21 1:26 PM, Jason Merrill via Gcc-patches wrote:
> > Ping.
> >
> > On 5/1/21 12:29 PM, Jason Merrill wrote:
> >> Like my recent patch to add ovl_range and lkp_range in the C++ front end,
> >> this patch adds the tsi_ra
On Fri, 14 May 2021, Xionghu Luo wrote:
> Hi Richi,
>
> On 2021/4/21 19:54, Richard Biener wrote:
> > On Tue, 20 Apr 2021, Xionghu Luo wrote:
> >
> >>
> >>
> >> On 2021/4/15 19:34, Richard Biener wrote:
> >>> On Thu, 15 Apr 2021, Xionghu Luo wrote:
> >>>
> Thanks,
>
> On 2021/4/14
Hi,
So this is my second attempt at finding a way to improve how we generate
the vector IV's and teach the vectorizer to share them between main loop
and epilogues. On IRC we discussed my idea to use the loop's control_iv,
but that was a terrible idea and I quickly threw it in the bin. The mai
On Sun, 16 May 2021 at 22:01, Martin Sebor wrote:
> I think it's very helpful to provide this sort of detail. Just as
> a matter of readability, the new error message
>
>"wrong number of alternatives in operand %d, %d, expected %d"
>
> would be improved by avoiding the two consecutive %d's,
On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
wrote:
>
> On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
> > On 2021-05-14 15:15, Richard Biener wrote:
> >> On May 14, 2021 4:52:56 AM GMT+02:00, Jiufu Guo
> >> wrote:
> >>> As discussed in the PR, Richard mentioned the method to
>
On Fri, May 14, 2021 at 10:27 AM Hongtao Liu wrote:
>
> On Thu, May 13, 2021 at 7:52 PM Richard Sandiford
> wrote:
> >
> > Jakub Jelinek writes:
> > > On Thu, May 13, 2021 at 12:32:26PM +0100, Richard Sandiford wrote:
> > >> Jakub Jelinek writes:
> > >> > On Thu, May 13, 2021 at 11:43:19AM +020
On Thu, May 13, 2021 at 8:28 AM Andreas Krebbel via Gcc-patches
wrote:
>
> v1 -> v2: build_reference_type_for_mode and build_pointer_type_for_mode now
> pick pointer mode if
> MODE argument is VOIDmode.
>
> Bootstrapped and regression tested on x86_64 and s390x.
>
> Ok for mainline and GCC 11?
T
Early *PING* - and I fixed a wording issue in my patch.
OK? Suggestions?
Tobias
On 14.05.21 00:06, Tobias Burnus wrote:
Document this new flag, added in
https://gcc.gnu.org/g:2a1586401a21dcd43e0f904bb6eec26c8b2f366b
+ https://gcc.gnu.org/onlinedocs/gcc/Nvidia-PTX-Options.html#index-mptx
Any
On Mon, 17 May 2021 at 08:36, Richard Biener wrote:
>
> On Sun, May 16, 2021 at 8:53 PM Joern Rennecke
> wrote:
> >
> > For architectures with likely spilled register classes, neither
> > register allocator is guaranteed
> > to succeed when using optimization. If you have just a few files to
> >
On Thu, May 13, 2021 at 9:04 AM Kewen.Lin wrote:
>
> Hi!
>
> >>> But in the end the vector code shouldn't end up worse than the
> >>> scalar code with respect to IVs - the cases where it would should
> >>> be already costed. So I wonder if you have specific examples
> >>> where things go worse en
On Thu, May 13, 2021 at 11:43 AM Hongtao Liu via Gcc-patches
wrote:
>
> Hi:
> When arg0 is same as arg1 in __builtin_ia32_pcmpgtw,
> gimple_build (&stmts, GT_EXPR, cmp_type, arg0, arg1) will simplify the
> comparison to vector constant 0, no stmts is generated, which causes
> ICE in gsi_insert_b
On Thu, May 13, 2021 at 1:49 PM Martin Liška wrote:
>
> Hello.
>
> In g:3835aa0eb90292d652dd6b200f302f3cac7e643f, I changed logic that the output
> -flto=foo argument is taken from IL file command lines. However, it should be
> also
> merged with linker command line. One can use -flto for compila
On 5/17/21 10:49 AM, Tobias Burnus wrote:
> Early *PING* - and I fixed a wording issue in my patch.
>
> OK? Suggestions?
>
LGTM, thanks.
- Tom
> Tobias
>
> On 14.05.21 00:06, Tobias Burnus wrote:
>> Document this new flag, added in
>> https://gcc.gnu.org/g:2a1586401a21dcd43e0f904bb6eec26c8b2f
On Wed, 12 May 2021, Martin Sebor wrote:
> On 5/7/21 4:21 AM, Richard Biener via Gcc-patches wrote:
> > On Fri, May 7, 2021 at 12:17 PM Richard Biener wrote:
> >>
> >> canonicalize_constructor_val was setting TREE_ADDRESSABLE on bases
> >> of ADDR_EXPRs but that's futile when we're dealing with C
on 2021/5/17 下午4:55, Richard Biener wrote:
> On Thu, May 13, 2021 at 9:04 AM Kewen.Lin wrote:
>>
>> Hi!
>>
> But in the end the vector code shouldn't end up worse than the
> scalar code with respect to IVs - the cases where it would should
> be already costed. So I wonder if you have
On Wed, 12 May 2021 at 10:24, Richard Biener wrote:
>
> On Wed, 12 May 2021, Bernd Edlinger wrote:
>
> > Hi,
> >
> > this fixes another regression from my previous patch.
> >
> >
> > Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> > Is it OK for trunk?
>
> OK.
>
> Richard.
>
Hi,
As the new
On Mon, May 17, 2021 at 5:01 PM Richard Biener
wrote:
>
> On Thu, May 13, 2021 at 11:43 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > Hi:
> > When arg0 is same as arg1 in __builtin_ia32_pcmpgtw,
> > gimple_build (&stmts, GT_EXPR, cmp_type, arg0, arg1) will simplify the
> > comparison to vecto
ping?
On Fri, 30 Apr 2021 at 16:22, Christophe Lyon
wrote:
>
> ping?
>
> On Wed, 21 Apr 2021 at 22:48, Christophe Lyon
> wrote:
> >
> > The acle/saturation.c test uses __[su]sat() and
> > __saturation_occurred() intrinsics but __[su]sat() are defined in
> > acle.h if __ARM_FEATURE_SAT true, whil
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
> wrote:
> >
> > Vector right shifts by immediate use vshr, while right shifts by
> > vectors instead use vneg and vshl.
> >
> > This patch adds the corresponding scan-assembler
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
> wrote:
> >
> > Use a template macro to factorize the existing test functions.
> >
> > This patch also adds a version to check subtraction with __fp16 type.
> >
> > 2021-04-26
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
> wrote:
> >
> > Support for vadd has been present for a while, but it was lacking a
> > test.
> >
> > 2021-04-22 Christophe Lyon
> >
> > gcc/testsuite/
> > *
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
> wrote:
> >
> > This patch adds a test for the scalar mode of vadd, precisely noting
> > that we do not yet use the T2 variants of vadd, which take a scalar as
> > final argume
ping?
On Wed, 5 May 2021 at 16:08, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 15:41, Christophe Lyon
> wrote:
> >
> > On Tue, 4 May 2021 at 13:29, Andre Vieira (lists)
> > wrote:
> > >
> > > Hi Christophe,
> > >
> > > On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > > > Si
ping?
On Wed, 5 May 2021 at 16:09, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 19:03, Christophe Lyon
> wrote:
> >
> > On Tue, 4 May 2021 at 15:43, Christophe Lyon
> > wrote:
> > >
> > > On Tue, 4 May 2021 at 13:48, Andre Vieira (lists)
> > > wrote:
> > > >
> > > > It would be good to a
ping?
On Fri, 30 Apr 2021 at 16:09, Christophe Lyon
wrote:
>
> This patch enables MVE vld2/vst2 instructions for auto-vectorization.
> We move the existing expanders from neon.md and enable them for MVE,
> calling the respective emitter.
>
> 2021-03-12 Christophe Lyon
>
> gcc/
>
ping?
On Tue, 4 May 2021 at 16:57, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 14:03, Andre Vieira (lists)
> wrote:
> >
> > Hi Christophe,
> >
> > The series LGTM but you'll need the approval of an arm port maintainer
> > before committing. I only did code-review, did not try to build/run t
Hongtao Liu via Gcc-patches writes:
> On Fri, May 14, 2021 at 10:27 AM Hongtao Liu wrote:
>>
>> On Thu, May 13, 2021 at 7:52 PM Richard Sandiford
>> wrote:
>> >
>> > Jakub Jelinek writes:
>> > > On Thu, May 13, 2021 at 12:32:26PM +0100, Richard Sandiford wrote:
>> > >> Jakub Jelinek writes:
>>
Joern Rennecke writes:
> On Sun, 16 May 2021 at 22:01, Martin Sebor wrote:
> > I think it's very helpful to provide this sort of detail. Just as
>> a matter of readability, the new error message
>>
>>"wrong number of alternatives in operand %d, %d, expected %d"
>>
>> would be improved by av
On 16 May 2021 20:21:13 CEST, Joern Rennecke
wrote:
>The attached patch adds a new option -fretry-compilation that allows
>you to specify a list - or
>lists - of options to use for a compilation retry, which is
>implemented in the compiler driver.
That's gross ;)
+If the compiler fails, retry
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 21 April 2021 21:48
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] testsuite/arm: Fix and rename arm_qbit_ok into
> arm_sat_ok effective-target
>
> The acle/saturation.c test uses __[su]sa
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 17 May 2021 10:54
> To: gcc Patches
> Subject: Re: [PATCH] testsuite/arm: Improve mve-vshr.c
>
> ping?
>
> On Mon, 10 May 2021 at 13:22, Christophe Lyon
> wrote:
> >
> > Ping?
> >
> > On T
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 17 May 2021 10:54
> To: gcc Patches
> Subject: Re: [PATCH] testsuite/arm: Factorize and increase coverage in mve-
> sub_1.c
>
> ping?
>
> On Mon, 10 May 2021 at 13:22, Christophe Lyon
> wr
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 17 May 2021 10:54
> To: gcc Patches
> Subject: Re: [PATCH] testsuite/arm: Add mve-vadd-1.c test
>
> ping?
>
> On Mon, 10 May 2021 at 13:22, Christophe Lyon
> wrote:
> >
> > Ping?
> >
> > O
OK for mainline?
It is an ice-on-invalid; does a GCC 11 backport nonetheless make sense?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
OpenMP/Fortran: Reject nonin
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 17 May 2021 10:54
> To: gcc Patches
> Subject: Re: [PATCH] testsuite/arm: Add mve-vadd-scalar-1.c test
>
> ping?
>
> On Mon, 10 May 2021 at 13:22, Christophe Lyon
> wrote:
> >
> > Ping?
>
On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> As the PR shows, we ICE shortly after expanding nonsecure calls for
> Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands,
> the expander (arm.md:nonsecure_call_internal) moves the callee's address
> to a registe
On 14.05.21 10:51, Tobias Burnus wrote:
OG11 = devel/omp/gcc-11, a branch with some OpenMP/OpenACC/offload
patches
which are not yet on mainline. Additionally, patches in this area are
cherry-picked from mainline
Changes since last email (cherry pick, merge, post-cherry-pick fix):
0b8439a602c
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 05 May 2021 15:08
> To: Andre Simoes Dias Vieira
> Cc: gcc Patches
> Subject: Re: [PATCH 6/9] arm: Auto-vectorization for MVE: vcmp
>
> On Tue, 4 May 2021 at 15:41, Christophe Lyon
> wrote
On Mon, May 17, 2021 at 12:27:22PM +0200, Tobias Burnus wrote:
> OK for mainline?
> It is an ice-on-invalid; does a GCC 11 backport nonetheless make sense?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 05 May 2021 15:09
> To: Andre Simoes Dias Vieira
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 7/9] arm: Auto-vectorization for MVE: add __fp16
> support to VCMP
>
> On Tue, 4 May 2021
Hello.
As mentioned at the beginning of https://gcc.gnu.org/install/old.html:
"Note most of this information is out of date and superseded by the previous
chapters of this manual."
The installation page is deprecated for 20 years now.
Does it make sense to remove it?
Thanks,
Martin
gcc/Change
On Mon, May 17, 2021 at 10:55 AM Joern Rennecke
wrote:
>
> On Mon, 17 May 2021 at 08:36, Richard Biener
> wrote:
> >
> > On Sun, May 16, 2021 at 8:53 PM Joern Rennecke
> > wrote:
> > >
> > > For architectures with likely spilled register classes, neither
> > > register allocator is guaranteed
>
This allows the Doxygen PDF to be built using lualatex instead of
pdflatex, which solves a problem with pdflatex running out of memory
sometimes. This is done by adding a --latex_cmd option to the
run_doxygen script, which then sets the specified command in the
generated user.cfg file used by Doxyg
The current diagnostic assumes the reference binding fails because the
reference is non-const, but it can also fail if the rvalue is volatile.
Use the current diagnostic for non-const cases, and a modified
diagnostic otherwise.
gcc/cp/ChangeLog:
PR c++/100635
* call.c (convert_li
On AIX, stat will store inodes in 32bit even when using LARGE_FILES.
If the inode is larger, it will return -1 in st_ino.
Thus, in incpath.c when comparing include directories, if several
of them have 64bit inodes, they will be considered as duplicated.
gcc/ChangeLog:
2021-05-06 Clément Chigot
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
(riscv_subset_list::parsing_subset_version): Properly parse the letter
'p' in '-march'.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-12.c: New.
* gcc.target/riscv/attribute-19.c: New.
---
gcc/common/co
On 5/14/21 11:26 PM, Julian Brown wrote:
> This patch reworks indirect struct handling in gimplify.c (i.e. for struct
> components mapped with "mystruct->a[0:n]", "mystruct->b", etc.), for
> both OpenACC and OpenMP. The key observation leading to these changes
> was that component mappings of refe
On Mon, 17 May 2021 at 12:35, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 05 May 2021 15:08
> > To: Andre Simoes Dias Vieira
> > Cc: gcc Patches
> > Subject: Re: [PATCH 6/9] arm: Auto-vectorization f
Hi Julian,
On 2021/5/15 5:27 AM, Julian Brown wrote:
GCC currently raises a parse error for indirect accesses to struct
members, where the base of the access is a reference to a pointer.
This patch fixes that case.
gcc/cp/
* semantics.c (finish_omp_clauses): Handle components of refer
On 2021/5/11 4:57 PM, Julian Brown wrote:
This work-in-progress patch tries to get
GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like
GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups
to be processed by build_struct_group/build_struct_comp_map. I think
that's import
It is only defined for i386 and everyone uses the default:
#define MAX_BITSIZE_MODE_ANY_INT (64*BITS_PER_UNIT)
Whatever problems we had before, they have been fixed now.
* config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed.
---
gcc/config/i386/i386-modes.def | 15 +++---
Changes in the v3 patches:
1. Split the TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE changes
into the generic part and the x86 part.
1. Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memm
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memmset.
PR middle-end/90773
* builtins.c (builtin_memset_read_str): Call
targetm.read_memset_value.
(builtin_memset_g
To avoid stack realignment, use SCRATCH_SSE_REG to copy data from one
memory location to another.
gcc/
* config/i386/i386-expand.c (ix86_expand_vector_move): Use
SCRATCH_SSE_REG to copy data from one memory location to
another.
gcc/testsuite/
* gcc.target/i386/eh
1. Make ix86_expand_vector_init_duplicate global to duplicate QImode
value to TImode/OImode/XImode.
2. Make ix86_minimum_incoming_stack_boundary global and add an argument
to ignore stack_alignment_estimated.
3. Define SCRATCH_SSE_REG as a scratch register for ix86_gen_memset_value.
4. Add TARGET_R
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/pr72839.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/pr72839.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c
b/gcc/
Also pass -mno-avx to sw-1.c for ia32 since copying data with YMM or ZMM
registers disables shrink-wrapping when the second argument is passed on
stack.
* gcc.target/i386/sw-1.c: Also pass -mno-avx for ia32.
---
gcc/testsuite/gcc.target/i386/sw-1.c | 1 +
1 file changed, 1 insertion(+)
d
PR middle-end/90773
* gcc.target/i386/pr90773-20.c: New test.
* gcc.target/i386/pr90773-21.c: Likewise.
* gcc.target/i386/pr90773-22.c: Likewise.
* gcc.target/i386/pr90773-23.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr90773-20.c | 13 +
gcc
Expect no stack realignment since we no longer realign stack when
copying data.
* gcc.target/i386/incoming-11.c: Expect no stack realignment.
---
gcc/testsuite/gcc.target/i386/incoming-11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/i
* gcc.target/i386/pieces-memcpy-10.c: New test.
* gcc.target/i386/pieces-memcpy-11.c: Likewise.
* gcc.target/i386/pieces-memcpy-12.c: Likewise.
* gcc.target/i386/pieces-memcpy-13.c: Likewise.
* gcc.target/i386/pieces-memcpy-14.c: Likewise.
* gcc.targe
When expanding a constant constructor, don't call expand_constructor if
it is more efficient to load the data from the memory via move by pieces.
gcc/
PR middle-end/90773
* expr.c (expand_expr_real_1): Don't call expand_constructor if
it is more efficient to load the data
We can use TImode/OImode/XImode integers for piecewise move and store.
When vector register is used for piecewise move and store, we don't
increase stack_alignment_needed since vector register spill isn't
required for piecewise move and store. Since stack_realign_needed is
set to true by checking
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/cold-attribute-1.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/cold-attribute-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386
Attached is the updated version of the patch.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to apply?
Recognize popcount also when a double width operation is needed.
2021-01-27 Joern Rennecke
gcc/
* match.pd :
When generating popcount directly fails, try doing it in t
Vector indexing leaves us with ARRAY_REFs of VIEW_CONVERT_EXPRs,
sth which array_at_struct_end_p considers a array-at-struct-end
even when there's an underlying decl visible. The following fixes
the latter.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-05-17 Richard Biener
This rejects a number of vector components that does not fit an 'int'
which is an internal limitation of RTVEC. This requires adjusting
gcc.dg/attr-vector_size.c which checks for much larger
supported vectors. Note that the RTVEC limitation is a host specific
limitation (unless we change this 'in
The constraint check for filesystem::path construction uses
decltype(__is_path_src(declval())) which mean it considers
conversion from an rvalue. When Source is a volatile-qualified type
it cannot use is_path_src(const Unknown&) because a const lvalue
reference can only bind to a non-volatile rval
on s390 a warning test fails:
inline int ATTR ((cold, aligned (8)))
finline_hot_noret_align (int);
inline int ATTR ((warn_unused_result))
finline_hot_noret_align (int);
inline int ATTR ((aligned (4)))
finline_hot_noret_align (int); /* { dg-warning "ignoring attribute
.aligned \\(4\\). beca
On Mon, 17 May 2021 14:12:00 +0200
Bernd Edlinger wrote:
> > */ @@ -8715,19 +8770,26 @@ static tree
> > build_struct_group (struct gimplify_omp_ctx *ctx,
> > enum omp_region_type region_type, enum
> > tree_code code, tree decl, unsigned int *flags, tree c,
> > - ha
On Mon, 17 May 2021 21:07:19 +0800
Chung-Lin Tang wrote:
> Hi Julian,
>
> On 2021/5/15 5:27 AM, Julian Brown wrote:
> > GCC currently raises a parse error for indirect accesses to struct
> > members, where the base of the access is a reference to a pointer.
> > This patch fixes that case.
>
>
When duplicate labes are diagnosed, avoid building a GIMPLE_LABEL.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2021-05-17 Richard Biener
PR c/100625
gcc/c/
* gimple-parser.c (c_parser_gimple_label): Avoid building
a GIMPLE label with NULL label decl.
On 17/05/21 15:02 +0100, Jonathan Wakely wrote:
The constraint check for filesystem::path construction uses
decltype(__is_path_src(declval())) which mean it considers
conversion from an rvalue. When Source is a volatile-qualified type
it cannot use is_path_src(const Unknown&) because a const lva
On Mon, 17 May 2021 21:14:26 +0800
Chung-Lin Tang wrote:
> On 2021/5/11 4:57 PM, Julian Brown wrote:
> > This work-in-progress patch tries to get
> > GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like
> > GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups
> > to be pr
On 5/13/21 4:15 PM, Aldy Hernandez via Gcc-patches wrote:
Both initial_condition_in_loop_num and evolution_part_in_loop_num
can return NULL. This patch exits if either one is NULL. Presumably
this didn't happen before, because adjust_range_with_scev was called
far less frequently than in ranger
On Mon, 17 May 2021 at 11:59, Richard Biener wrote:
> The plan for reload is to axe it similar to CC0 support. Sooner than later,
> but
> give it's still used exclusively by a lot of target means it might
> take some time.
> So for you it's always just -fretry-compilation -m[no-]lra? Given -m
c -I- -I. -Iada/generated -Iada
-Iada/gcc-interface -I../../gcc-trunk-1/gcc/ada
-I../../gcc-trunk-1/gcc/ada/gcc-interface -Iada/libgnat
-I../../gcc-trunk-1/gcc/ada/libgnat
../../gcc-trunk-1/gcc/ada/libgnat/a-chlat1.ads -o ada/libgnat/a-chlat1.o
+===GNAT BUG DET
This fixes two issues with our iterator caching as described in detail
in the PR. Since r12-336 added the __non_propagating_cache class
template as part of P2328, this patch just rewrites the _CachedPosition
partial specialization in terms of this class template.
Tested on x86_64-pc-linux-gnu, do
This makes the in-place constructor of our partial specialization of
__box for already-semiregular types to use direct-non-list-initialization
(in accordance with the specification of the primary template), and
additionally makes its data() member function use std::__addressof.
Tested on x86_64-pc
Hello
This patch fixes the issue where a call to omp_fulfill_event could fail to
trigger the execution of tasks that were dependent on the task whose completion
event is being fulfilled.
This mainly (or can only?) occurs when the thread is external to OpenMP, and all
the barrier threads are
Hi,
[ Tobias, can you test this on volta ? ]
The atomic ops in nvptx.md have memmodel arguments, which are currently
ignored.
Handle these, fixing test-case fails libgomp.c-c++-common/reduction-{5,6}.c
on volta.
Tested libgomp on x86_64-linux with nvptx accelerator.
Any comments?
Thanks,
- To
On Mon, May 17, 2021 at 04:48:03PM +0100, Kwok Cheung Yeung wrote:
> 2021-05-17 Kwok Cheung Yeung
>
> libgomp/
> * task.c (omp_fulfill_event): Call gomp_team_barrier_set_task_pending
> if new tasks generated.
> * testsuite/libgomp.c-c++-common/task-detach-13.c: New.
> --
Tested on x86_64-pc-linux-gnu, does this look OK for 10/11/trunk?
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_Iterator): Befriend
_Sentinel.
(elements_view::_Sentinel::_M_equal): Templatize.
(elements_view::_Sentinel::_
A range being a random access range is not a sufficient condition for
ranges::next(iter, sent) to have constant time complexity; the range
must also have a sized sentinel. This adjusts the memoization condition
for reverse_view accordingly.
Tested on x86_64-pc-linxu-gnu, does this look OK for tru
On Mon, May 17, 2021 at 5:33 PM Joern Rennecke
wrote:
>
> On Mon, 17 May 2021 at 11:59, Richard Biener
> wrote:
>
> > The plan for reload is to axe it similar to CC0 support. Sooner than
> > later, but
> > give it's still used exclusively by a lot of target means it might
> > take some time.
>
Hi Kyrill,
On 27/04/2021 13:47, Kyrylo Tkachov wrote:
> Hi Alex,
>
> > -Original Message-
> > From: Alex Coplan
> > Sent: 27 April 2021 14:14
> > To: gcc-patches@gcc.gnu.org
> > Cc: ni...@redhat.com; Richard Earnshaw ;
> > Ramana Radhakrishnan ; Kyrylo
> > Tkachov
> > Subject: Re: [PATC
> -Original Message-
> From: Alex Coplan
> Sent: 17 May 2021 17:29
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; ni...@redhat.com; Richard Earnshaw
> ; Ramana Radhakrishnan
>
> Subject: Re: [PATCH] arm: Fix ICEs with compare-and-swap and -
> march=armv8-m.base [PR99977]
>
> Hi K
On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
Hi,
As the PR shows, we ICE shortly after expanding nonsecure calls for
Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands,
the expander (arm.md:nonsecure_call_internal) moves the callee's address
to a register (with
On 14/05/21 18:09 +0100, Jonathan Wakely wrote:
On 13/05/21 18:54 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
Please ignore the previous patch. This one removes the need to carry any
extra state in the case of a 'laundered' atomic wait.
libstdc++/ChangeLog:
* include/bits/atomic
On 17/05/21 11:43 -0400, Patrick Palka via Libstdc++ wrote:
This makes the in-place constructor of our partial specialization of
__box for already-semiregular types to use direct-non-list-initialization
(in accordance with the specification of the primary template), and
additionally makes its dat
On 17.05.21 17:49, Tom de Vries wrote:
[ Tobias, can you test this on volta ? ]
Unfortunately, it does not seem to help. On a non-Volta system, it still
works (run time 0.3s) but on a Volta system it fails after 1.5s (abort).
Looking (with an editor) at nvptx-none/lib/mgomp/libgomp.a, I still
On 17/05/21 12:17 -0400, Patrick Palka via Libstdc++ wrote:
A range being a random access range is not a sufficient condition for
ranges::next(iter, sent) to have constant time complexity; the range
must also have a sized sentinel. This adjusts the memoization condition
for reverse_view accordin
On 17/05/21 12:17 -0400, Patrick Palka via Libstdc++ wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for 10/11/trunk?
OK, thanks.
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_Iterator): Befriend
_Sentinel.
(elements
On 17/05/21 11:43 -0400, Patrick Palka via Libstdc++ wrote:
This fixes two issues with our iterator caching as described in detail
in the PR. Since r12-336 added the __non_propagating_cache class
template as part of P2328, this patch just rewrites the _CachedPosition
partial specialization in te
On 5/17/21 6:47 PM, Tobias Burnus wrote:
> On 17.05.21 17:49, Tom de Vries wrote:
>> [ Tobias, can you test this on volta ? ]
>
> Unfortunately, it does not seem to help. On a non-Volta system, it still
> works (run time 0.3s) but on a Volta system it fails after 1.5s (abort).
>
> Looking (with a
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::_S_create): Fix static assert
message.
* testsuite/30_threads/jthread/95989.cc: Re-enable test.
* testsuite/30_threads/jthread/jthread.cc: Do not require
pthread effective target.
* testsuite/30_
On 17/05/21 15:25 +0100, Jonathan Wakely wrote:
On 17/05/21 15:02 +0100, Jonathan Wakely wrote:
The constraint check for filesystem::path construction uses
decltype(__is_path_src(declval())) which mean it considers
conversion from an rvalue. When Source is a volatile-qualified type
it cannot us
On 12/05/21 17:16 +0100, Jonathan Wakely wrote:
On 12/05/21 18:51 +0300, Antony Polukhin via Libstdc++ wrote:
ср, 12 мая 2021 г. в 18:38, Antony Polukhin :
ср, 12 мая 2021 г. в 17:44, Jonathan Wakely :
On 12/05/21 12:58 +0300, Antony Polukhin wrote:
>ср, 12 мая 2021 г. в 12:18, Jonathan Wake
1 - 100 of 137 matches
Mail list logo
