PR96125 shows a bug when we try to use an MMA built-in within a function
that uses #pragma target/attribute target to enable power10 code generation
and the -mcpu= command line option is pre-power10.
The problem is that we only initialize built-ins once, fairly early, when
the command line
On 2020/7/9 06:43, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 08, 2020 at 11:19:21AM +0800, luoxhu wrote:
>> For extracting high part element from DImode register like:
>>
>> {%1:SF=unspec[r122:DI>>0x20#0] 86;clobber scratch;}
>>
>> split it before reload with "and mask" to avoid
on 2020/7/9 上午10:48, Kewen.Lin via Gcc-patches wrote:
> Hi Richi,
>
> on 2020/7/8 下午10:45, Richard Biener wrote:
>> This followup removes vect_verify_datarefs_alignment and its
>> premature cancellation of vectorization leaving the actual
>> decision whether alignment is supported to the
"If the placeholder is the decltype(auto) type-specifier, T shall be the
placeholder alone." but we weren't detecting "const decltype(auto)".
I've just expanded the existing diagnostic detecting "decltype(auto) &"
and similar.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hi Richi,
on 2020/7/8 下午10:45, Richard Biener wrote:
> This followup removes vect_verify_datarefs_alignment and its
> premature cancellation of vectorization leaving the actual
> decision whether alignment is supported to the functions
> deciding whether we can vectorize a load or store.
>
>
Greetings yet again,
It would be greatly appreciated if you could look at this patch when you
have a minute.
--Doug
On 6/17/20 2:14 PM, Douglas B Rupp wrote:
Greetings again,
Could you please look at this patch when convenient?
--Doug
On 6/1/20 10:13 AM, Douglas B Rupp wrote:
Greetings,
On Wed, Jul 08, 2020 at 10:55:59AM -0500, will schmidt wrote:
> On Tue, 2020-06-30 at 18:39 -0500, Segher Boessenkool wrote:
> > On Tue, Jun 30, 2020 at 12:57:45PM -0500, will schmidt wrote:
> > > Add support for the vmsumudm instruction and tie it into the
> > > vec_msum
> > > built-in to
Hi Carl,
On Tue, Jul 07, 2020 at 04:19:33PM -0700, Carl Love wrote:
> I have fixed the issues you mentioned in version 2. I also rebased the
> patch onto the latest mainline. This resulted in having to change
> FUTURE to P10 everywhere.
Yeah, that is painful. I took the brunt of it, I should
GCC has gotten better at detecting conflicts between various
attributes but it still doesn't do a perfect job of detecting
similar problems due to mismatches between contradictory
arguments to the same attribute. For example,
__attribute ((alloc_size (1))) void* allocate (size_t, size_t);
Hello Jakub,
Thank you again for detailed feedback. I had few questions.
On Wed, Jul 8, 2020 at 4:42 PM Jakub Jelinek wrote:
> On Wed, Jul 08, 2020 at 03:30:35PM -0400, y2s1982 wrote:
> > +ompd_rc_t
> > +ompd_get_omp_version (ompd_address_space_handle_t *address_space,
> > +
On Wed, Jul 08, 2020 at 11:39:56AM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > I am not happy about what is considered "a complex loop" here.
> For early exit, which may cause and *next* unrolled iterations may be
> not executed, then unroll may be not benifit.
Yes, and it can well
Hi!
On Wed, Jul 08, 2020 at 11:19:21AM +0800, luoxhu wrote:
> For extracting high part element from DImode register like:
>
> {%1:SF=unspec[r122:DI>>0x20#0] 86;clobber scratch;}
>
> split it before reload with "and mask" to avoid generating shift right
> 32 bit then shift left 32 bit. This
On Wed, Jul 08, 2020 at 03:30:35PM -0400, y2s1982 wrote:
> +ompd_rc_t
> +ompd_get_omp_version (ompd_address_space_handle_t *address_space,
> + ompd_word_t *omp_version)
> +{
> + if (omp_version == NULL)
> +return ompd_rc_bad_input;
> + if (address_space == NULL)
> +
Ping.
On Wed, Jun 24, 2020 at 07:27:14PM -0400, Marek Polacek via Gcc-patches wrote:
> This is an ICE-on-invalid but I've been seeing it when reducing
> various testcases, so it's more important for me than usually.
>
> splice_late_return_type now checks that if we've seen a late return
> type,
On Fri, Jul 03, 2020 at 05:24:34PM -0400, Jason Merrill via Gcc-patches wrote:
> On 6/22/20 10:09 PM, Marek Polacek wrote:
> > convert_like issues errors about bad_p conversions at the beginning
> > of the function, but in the ck_ref_bind case, it only issues them
> > after we've called
Will:
>
> >
> > @@ -5701,3 +5716,55 @@
> >"TARGET_POWER10"
> >" %x0,%x1"
> >[(set_attr "type" "vecfloat")])
> > +
> > +;; VSX mask manipulation instructions
> > +;;;(define_expand "vec_mtvsrbm"
> > +;;; [(set (match_operand:V16QI 0 "altivec_register_operand" "=v")
> > +;;;
[PATCH 5/6] rs6000, Add vector splat builtin support
--
V4 Fixes:
Rebased on mainline. Changed FUTURE to P10.
define_predicate "s32bit_cint_operand" removed unnecessary cast in
definition.
Changed define_expand "xxsplti32dx_v4si" to use "0" for
[PATCH 6/6] rs6000 Add vector blend, permute builtin support
--
V4 Fixes:
Rebased on mainline. Changed FUTURE to P10.
-
v3 fixes:
Replace spaces with tabs in ChangeLog description.
Fix implementation comments for define_expand "xxpermx" in file
On Wed, 2020-07-08 at 09:22 -0700, Carl Love wrote:
> Will, Segher:
>
> I fixed up the patch based on Will's comments. I thought I had made
> and committed the fixes that Will caught, but no Sorry about
> that. I will get this right yet.
>
> Carl Love
>
[PATCH 4/6] rs6000, Add vector shift double builtin support
--
V4 Fixes:
Rebased on mainline. Changed FUTURE to P10.
Changed SLDB_LR to SLDB_lr
Changed error ("argument 3 must be in the range 0 to 7"); to
error ("argument 3 must be a constant in
On Tue, Jul 7, 2020 at 2:52 AM Kito Cheng wrote:
> gcc/ChangeLog:
> * gcc/config/riscv/riscv.md (): New.
> (TP_REGNUM): Ditto.
> * doc/extend.texi (Target Builtins): Add RISC-V built-in section.
> Document __builtin_thread_pointer.
> gcc/testsuite/ChangeLog:
>
[PATCH 3/6] rs6000, Add vector replace builtin support
--
V4 Fixes:
Rebased on mainline. Changed FUTURE to P10 in code and ChangeLog.
Set DEBUG to 0 in vec-replace-word-runnable.c test program.
Fixed too long lines in ChangeLog.
[PATCH 1/6] rs6000, Update support for vec_extract
-
V4 changes
rebased onto mainline 7/2/2020
Add iterator name to Change log
---
V3 changes
Redo ChangeLog for code move.
Replace spaces with tabs in ChangeLog.
Replaced
[PATCH 2/6] rs6000 Add vector insert builtin support
V4 changes
Rebased on mainline. Changed FUTURE to P10 as needed.
V3 changes
Replace spaces with of tabs in ChangeLog
Ditto in gcc/config/rs6000/vsx.md.
Updated
Segher:
The following is version 4 of the series of patches for the permute
class operations. Per your request, I will send each patch as a reply
to this message so they are all in the same thread in your email box.
Patches 1, 2,3 and 4 just have minor fixes per your earlier comments.
Le 03/06/2020 à 22:24, Jeff Law a écrit :
> On Wed, 2020-06-03 at 21:56 +0200, Romain Naour wrote:
>> Hi Jeff,
>>
>> Le 03/06/2020 à 20:33, Jeff Law a écrit :
>>> On Thu, 2020-05-21 at 17:35 +0200, Romain Naour via Gcc-patches wrote:
As reported by several Buildroot users [1][2][3], the gcc
On Tue, Jul 7, 2020 at 12:28 AM Kito Cheng wrote:
> gcc/ChangeLog:
> * config/riscv/riscv-sr.c (riscv_remove_unneeded_save_restore_calls):
> Abort if any arguments on stack.
> gcc/testsuite/ChangeLog
> * gcc.target/riscv/save-restore-9.c: New.
Looks good to me.
Jim
This patch adds Address Space Information function implementations as
defined in section 5.5.4 of OpenMP API Specification 5.0.
2020-07-08 Tony Sim
libgomp/ChangeLog:
* Makefile.am (libgompd_la_OBJECTS): Add ompd-addr.c.
* Makefile.in: Regenerate.
* ompd-addr.c: New
Committed as obvious. Check whether the target of a legacy ASSIGN statement
is a parameter and reject if this is the case.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
PR fortran/96085 - ICE in gfc_finish_var_decl, at fortran/trans-decl.c:694
Legacy ASSIGN requires a scalar integer
On 7/8/20 7:35 PM, Kwok Cheung Yeung wrote:
> (Resent with CC to gcc-patches)
>
> Hello
>
>> I tried out the patch with one test-case and -pie -fPIC/-fpic already
>> seems to works, so perhaps we could have at least one test-case
>> exercising this in libgomp? That sounds easier to do than the
On Wed, Jul 08, 2020 at 02:02:44PM -0400, y2s1982 wrote:
> + ret = gompd_callbacks.free_memory (handle);
> + return ret;
You could here just
return gompd_callbacks.free_memory (handle);
No need to bother with ret variable.
Ok with that fixed, no need to repost.
Jakub
Hello
On Wed, Jul 8, 2020 at 5:08 AM Jakub Jelinek wrote:
> On Tue, Jul 07, 2020 at 02:52:37PM -0400, y2s1982 . via Gcc-patches wrote:
> > I have re-read the documentation trying to find a different solution.
> > In particular, ompd_device_initialize states that
> > ompd_device_t kind,
This patch adds OMPD functions defined in 5.5.2 of the OpenMP 5.0 API
documentation. It adds per-process and per-device functions, defines
related handle data types. It also introduces ompd-types.h to Makefile.
2020-07-08 Tony Sim
libgomp/ChangeLog:
* Makefile.am
(Resent with CC to gcc-patches)
Hello
> I tried out the patch with one test-case and -pie -fPIC/-fpic already
> seems to works, so perhaps we could have at least one test-case
> exercising this in libgomp? That sounds easier to do than the
> shared-lib test-case.
I've created a simple
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 17:28
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH 6/6] aarch64: Fix BTI support in libitm
>
> sjlj.S did not have the GNU property note markup and the BTI c
> instructions
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 17:28
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH 5/6] aarch64: Fix BTI support in libgcc
>
> lse.S did not have the GNU property note markup and the BTI c
> instructions
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 17:27
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH 2/6] aarch64: Add missing ACLE support for PAC-RET
>
> Define the __ARM_FEATURE_PAC_DEFAULT feature test
> macro when
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 17:26
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH 1/6] aarch64: Add missing ACLE support for BTI
>
> Define the __ARM_FEATURE_BTI_DEFAULT feature test
> macro when BTI branch
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 17:27
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH 4/6] aarch64: Fix noexecstack note in libgcc
>
> lse.S did not have GNU stack note, this may cause missing
> PT_GNU_STACK in
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 17:27
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH 3/6] aarch64: Fix noexecstack note in libitm
>
> sjlj.S only had the note on Linux, but it is supposed
> to have it on
On 05/06/20 17:29 -0700, Thomas Rodgers wrote:
Add support for -
atomic wait/notify_one/notify_all
counting_semaphore
binary_semaphore
latch
* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: Regenerate.
*
sjlj.S did not have the GNU property note markup and the BTI c
instructions that are necessary when it is built with branch
protection.
The notes are only added when libitm is built with branch
protection, because old linkers mishandle the note (merge
them incorrectly or emit warnings), the BTI
lse.S did not have GNU stack note, this may cause missing
PT_GNU_STACK in binaries on Linux and FreeBSD.
libgcc/ChangeLog:
2020-07-08 Szabolcs Nagy
* config/aarch64/lse.S: Add stack note.
---
libgcc/config/aarch64/lse.S | 4
1 file changed, 4 insertions(+)
diff --git
sjlj.S only had the note on Linux, but it is supposed
to have it on FreeBSD too.
libitm/ChangeLog:
2020-07-08 Szabolcs Nagy
* config/aarch64/sjlj.S: Add stack note if __FreeBSD__ is defined.
---
Note: this is a minor change to make the asm consistent with
gcc code generation (which
lse.S did not have the GNU property note markup and the BTI c
instructions that are necessary when it is built with branch
protection.
The notes are only added when libgcc is built with branch
protection, because old linkers mishandle the note (merge
them incorrectly or emit warnings), the BTI
Define the __ARM_FEATURE_BTI_DEFAULT feature test
macro when BTI branch protection is enabled.
gcc/ChangeLog:
2020-07-08 Szabolcs Nagy
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add
__ARM_FEATURE_BTI_DEFAULT support.
---
gcc/config/aarch64/aarch64-c.c | 3
Define the __ARM_FEATURE_PAC_DEFAULT feature test
macro when PAC-RET branch protection is enabled.
gcc/ChangeLog:
2020-07-08 Szabolcs Nagy
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add
__ARM_FEATURE_PAC_DEFAULT support.
---
Note: i expect to push this patch
Some asm files in target libraries were not branch protected
and gcc missed preprocessor macros when it is generating
branch protection code (which is needed to fix the asm files).
Szabolcs Nagy (6):
aarch64: Add missing ACLE support for BTI
aarch64: Add missing ACLE support for PAC-RET
Will, Segher:
I fixed up the patch based on Will's comments. I thought I had made
and committed the fixes that Will caught, but no Sorry about
that. I will get this right yet.
Carl Love
---
Version 4
vec_mtvsrbm
On Tue, 2020-06-30 at 18:39 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jun 30, 2020 at 12:57:45PM -0500, will schmidt wrote:
> > Add support for the vmsumudm instruction and tie it into the
> > vec_msum
> > built-in to support the variants of that built-in using vector
> > _int128
> -Original Message-
> From: Szabolcs Nagy
> Sent: 08 July 2020 16:48
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; fwei...@redhat.com; Richard Earnshaw
> ; Daniel Kiss
> Subject: Re: [PATCH 2/4] aarch64: fix __builtin_eh_return with pac-ret
> [PR94891]
>
> The 07/08/2020
The 07/08/2020 13:24, Kyrylo Tkachov wrote:
> Hi Szabolcs,
> > The 06/05/2020 17:51, Szabolcs Nagy wrote:
> > > --- a/gcc/config/aarch64/aarch64.c
> > > +++ b/gcc/config/aarch64/aarch64.c
> > > @@ -6954,6 +6954,10 @@ aarch64_return_address_signing_enabled (void)
> > >/* This function should
On Tue, 2020-07-07 at 16:19 -0700, Carl Love wrote:
> Segher:
>
> I have fixed the issues you mentioned in version 2. I also rebased the
> patch onto the latest mainline. This resulted in having to change
> FUTURE to P10 everywhere.
>
> I reran regression testing on Power 9 with no regression
On Wed, Jul 8, 2020 at 10:53 AM Eric Botcazou wrote:
>
> [Sorry for dropping the ball here]
>
> > But GCC does not see the reverse storage order in mymemcpy so
> > it happily folds the memcpy inside it, inlines the result and then?
>
> You're right, this breaks, hence the following alternative:
The C compiler switch -Wparentheses causes the warning suggest
parentheses around '&&' within '||'.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* socket.c [_WIN32] (__gnat_minus_500ms): Parentheses around &&
operations. Remove notes about TN in comment.diff --git
For an allocator in the subtype mark case, the constraints of the subtype
must be checked against the designated subtype, except in the case where
the No_Initialization flag is set on the allocator node.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch4.adb
This disables the warning that is given by the C compiler when it is
compiling the generic implementation of the backtrace facility used
on some platforms.
This happens when a positive frame level is requested, which can be
problematic in the general case. But this implementation is known to
They are mostly warnings on unused parameters, useless variables, casts
between integer and pointers of different size, or missing or incorrect
prototypes. There is also an improper checking of a return value.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* adaint.h
This freezing issue shows that Freeze_Expression does not fully control
the placement of freeze nodes produced by an expression coming from the
Actions list of various constructs, here an N_And_Then node, because it
does not check whether the entity being frozen, for example a type, is
really
Now that Interfaces.C also defined long_long and unsigned_long_long,
make definitions in Interfaces.C.Extensions subtypes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/i-cexten.ads (long_long, unsigned_long_long): Now
subtypes of Interfaces.C types.
Aspect Relaxed_Initialization has been prototyped for ordinary
subprograms and then SPARK RM 6.10 allowed it for generic subprograms as
well.
This is mostly straightforward to implement, except when 'Result appears
in the aspect expression for a generic function. When instantiated in a
wrapper
Problem: Expression functions that have class-wide pre/post conditions
which call functions that are themselves expression functions refer to
entities from a specification that isn't theirs.
Solution: When creating the class-wide clone of the function that has
the class-wide condition, update its
The implementation of static expression functions exhibited various
problems when compiling with the switches -gnatd.F (SPARK mode) or
-gnatc. Use of those switches could lead to errors on legal calls to
static expression functions (such as the calls being flagged as not
static), plus the
This documents the implementation choice made for byte-packed array
types, where we let the code generator deal with them if the type is
composite and use the manipulation routines of the front-end if the
type is discrete.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
*
This commit lets users know what the expected and actual size are when
conflicting representation clauses are present.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch13.adb (Analyze_Record_Representation_Clause,
Check_Record_Representation_Clause): Add
Iterator filters can appear in loop parameter specifications and in
iterator specifications, and determine which elements of some domain of
iteration are to be used in a loop, aggregate ,or quantified expression.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* par.adb
This recently introduced procedure is responsible for narrowing the
type of operations done originally in Universal_Integer, rewriting
them into operations done in Integer or Long_Long_Integer.
This changes the procedure to use the base type instead of the first
subtype for these two integer
GNAT does not reject specifying aspect Inline twice (once via an aspect
and once via a pragma).
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_prag.adb (Process_Inline): Check for duplicate
pragma+aspect Inline. Minor code cleanup.
This patch checks RM-3.2.4(14.2/4), which requires Predicate_Failure to
be specified only on a subtype with a previous predicate specification
(for Static_Predicate or Dynamic_Predicate). We apply the same rule to
the GNAT-specific Predicate aspect.
Tested on x86_64-pc-linux-gnu, committed on
This prevents the freezing mechanism from putting a node inside the
subprogram body generated for a predicate function, which can for
example happen for a function referenced in the predicate.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* freeze.adb (In_Expanded_Body):
Routine Safe_To_Capture_Value was written to capture just the "value",
which only made sense for assignable entities. However, it was later
employed to capture other properties, e.g. the value being [non-]null or
valid. Those properties can be captured for non-assignable entities as
well, e.g.
When analysing aspect Yield we were adding a minimum decoration to the
annotated entity by setting its kind to E_Function/E_Procedure. This
kind was then correctly reset to E_Generic_Function/E_Generic_Procedure
after all aspects has been analysed.
It seems cleaner to set this kind once and
The final version of SPARK RM 6.10 allows the Relaxed_Initialization
status of subprogram parameters (and function result) to be controlled
by an optional boolean expressions, e.g.:
function F (Arg : Integer) return Integer
with Relaxed_Initialization => (Arg => True, F'Result);
Tested on
This fixes a couple of quirks in the output generated by the -gnatR switch
for derived untagged types with discriminants:
1. in normal mode, it would display both the hidden and the visible
discriminants, which results in overlapping components,
2. in JSON mode, it would display only
Optimization that repaces
if expression then
return true;
else
return false;
end if;
with
return expression;
is now trivially extended to detect True/False prefixed by Standard.
Found while investigating excessive validity checks.
Tested on x86_64-pc-linux-gnu,
This patch fixes a bug where if we have "subtype S is T with Predicate
=> ...", and T is a private type whose full type is derived from another
private type, then the predicate of S is not checked.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch13.adb
Dmitrij Pochepko writes:
> Hi,
>
> thank you for looking into this.
>
> I prepared new patch with all your comments addressed.
Thanks, looks good, just a couple of minor things:
> @@ -20090,6 +20092,62 @@ aarch64_evpc_trn (struct expand_vec_perm_d *d)
>return true;
> }
>
> +/* Try to
This followup removes vect_verify_datarefs_alignment and its
premature cancellation of vectorization leaving the actual
decision whether alignment is supported to the functions
deciding whether we can vectorize a load or store.
I'll see whether to find a suitable machine to test
Matthew Malcomson writes:
> With suggestions applied.
> Testing with `-mabi=ilp32` found a bug around the trampoline
> initialisation where the new larger size of the trampoline caused a
> different execution path of `emit_block_move` which ICE'd on the
> pre-existing `ptr_mode` address.
OK,
On Wed, Jul 08, 2020 at 03:10:14PM +0100, Richard Sandiford wrote:
> gcc/
> PR target/95726
> * config/aarch64/aarch64.c (aarch64_attribute_table): Add
> "Advanced SIMD type".
> * config/aarch64/aarch64-builtins.c: Include stringpool.h and
> attribs.h.
>
This is a release branch version of r11-1741-g:31427b974ed7b7dd54e2.
The trunk version of the patch made GNU and Advanced SIMD vectors
distinct (but inter-convertible) in all cases. However, the
traditional behaviour is that the types are distinct in template
arguments but not otherwise.
On Tue, Jul 7, 2020 at 9:20 PM Richard Sandiford
wrote:
>
> [Sorry, been sitting on this patch for a while and just realised
> I never sent it.]
>
> This is yet another PR caused by constant integer rtxes not storing
> a mode. We were calling REDUCE_BIT_FIELD on a constant integer that
> didn't
On Tue, Jul 7, 2020 at 12:03 PM bin.cheng via Gcc-patches
wrote:
>
> Hi,
> This is a followup fix for PR95638 which changed the way post order numbers
> are maintained for
> partition graph. It missed one case that when SCC of reduction partition is
> broken by runtime
> alias checks, we do
Forwarding to fort...@gcc.gnu.org as suggested by Dominique d'Humieres.
On Sun, Jul 5, 2020 at 9:29 PM Yichao Yu wrote:
>
> > I think this remapping should happen with `file-prefix-map` but
> > shouldn't with `debug-prefix-map` (though if it happens for both it's
> > also not too bad) and I
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 Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-10.1.0.sv.po', has
On Mon, 29 Jun 2020, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 10 branch is in regression and documentation fixing mode.
>
> We're close to two months after the GCC 10.1 release which means
> a first bugfix release is about to happen. The plan is to release
> mid July and I am
On 5/13/20 7:53 PM, Joseph Myers wrote:
See the issues
I filed athttps://github.com/AdaCore/git-hooks/issues for the existing
custom GCC changes and the pull request
https://github.com/AdaCore/git-hooks/pull/12 to bring in implementations
of many of those features (not sure if it covers
Hi Szabolcs,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Szabolcs Nagy
> Sent: 26 June 2020 15:49
> To: gcc-patches@gcc.gnu.org
> Cc: fwei...@redhat.com; Richard Earnshaw ;
> Daniel Kiss
> Subject: Re: [PATCH 2/4] aarch64: fix __builtin_eh_return with pac-ret
> [PR94891]
>
> -Original Message-
> From: Gcc-patches On Behalf Of
> Szabolcs Nagy
> Sent: 26 June 2020 15:44
> To: gcc-patches@gcc.gnu.org
> Cc: fwei...@redhat.com; Richard Earnshaw ;
> Daniel Kiss
> Subject: Re: [PATCH 1/4] aarch64: fix return address access with pac
> [PR94891][PR94791]
>
> The
"Kewen.Lin" writes:
> Hi,
>
> This patch is derived from the review of vector with length patch series.
> The length-based partial vector approach doesn't support reduction so far,
> so we would like to disable vectorization with partial vectors explicitly
> for it in vectorizable_condition.
"Kewen.Lin" writes:
> Hi,
>
> As Richard S. suggested in the review of vector with length patch
> series, we can use one message on "partial vectors" instead of
> "fully with masking". This patch is to update the dumping string
> and related test cases.
>
> Bootstrapped/regtested on
"Kewen.Lin" writes:
>> […]
>>> I tested the updated patch with this releasing, LOOP_VINFO_PEELING_FOR_GAPS
>>> part looks fine, but LOOP_VINFO_PEELING_FOR_ALIGNMENT caused one case to
>>> fail at execution during vect-partial-vector-usage=2. So far the patch
>>> doesn't handle any niters_skip
---
htdocs/codingconventions.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index a08ddcbb..c0377315 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -752,7 +752,7 @@ outside
Richard Biener writes:
> This moves querying the alignment support scheme from load/store
> transform time to get_load_store_type where we should know best
> what alignment constraints we actually need. This should make
> verify_data_ref_alignment obsolete which prematurely disqualifies
> all
This moves querying the alignment support scheme from load/store
transform time to get_load_store_type where we should know best
what alignment constraints we actually need. This should make
verify_data_ref_alignment obsolete which prematurely disqualifies
all vectorization IMHO.
Bootstrap /
On Wed, Jul 08, 2020 at 12:21:57PM +0200, Thomas Schwinge wrote:
> Andrew and I are currently trying to sort out zero-length array sections
> behavior in the OpenACC context. From that fell out a testcase that I
> created to learn/verify (some of?) the OpenMP behavior. OK to push?
>
>
> Oh,
Hi Jakub!
Andrew and I are currently trying to sort out zero-length array sections
behavior in the OpenACC context. From that fell out a testcase that I
created to learn/verify (some of?) the OpenMP behavior. OK to push?
Oh, and any thought on this:
int dev = omp_get_default_device();
On Tue, Jul 07, 2020 at 02:52:37PM -0400, y2s1982 . via Gcc-patches wrote:
> I have re-read the documentation trying to find a different solution.
> In particular, ompd_device_initialize states that
> ompd_device_t kind, ompd_size_t sizeof_id, and void *id represents
> a device identifier. To dig
[Sorry for dropping the ball here]
> But GCC does not see the reverse storage order in mymemcpy so
> it happily folds the memcpy inside it, inlines the result and then?
You're right, this breaks, hence the following alternative: either we prevent
inlining from happening, or we declare that this
On 07/07/2020 13:43, Christophe Lyon wrote:
Hi,
On Mon, 6 Jul 2020 at 16:31, Andre Vieira (lists)
wrote:
On 30/06/2020 14:50, Andre Vieira (lists) wrote:
On 29/06/2020 11:15, Christophe Lyon wrote:
On Mon, 29 Jun 2020 at 10:56, Andre Vieira (lists)
wrote:
On 23/06/2020 21:52,
1 - 100 of 105 matches
Mail list logo
