On Fri, 23 Jul 2021, Jeff Law wrote:
>
>
> On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
> > Refine code for V2 according to review comments:
> > * Use if check instead assert, and refine assert
> > * Use better RE check for test case, e.g. (?n)/(?p)
> > * Use better wording for target.
On Thu, Jul 22, 2021 at 8:14 PM Richard Biener
wrote:
>
> On Wed, Jul 21, 2021 at 9:43 AM liuhongt wrote:
> >
> > gcc/ChangeLog:
> >
> > * optabs-query.c (get_best_extraction_insn): Use word_mode for
> > HF field.
> >
> > libgcc/ChangeLog:
> >
> > * config/i386/32/sfp-mach
Hi Segher,
On 7/21/21 1:58 PM, Segher Boessenkool wrote:
On Thu, Jun 17, 2021 at 10:19:07AM -0500, Bill Schmidt wrote:
2021-06-07 Bill Schmidt
gcc/
* config.gcc (extra_objs): Include rs6000-builtins.o and
rs6000-c.o.
The rs6000-c.o part needs an explanation, and probably sh
Hi,
As PR101596 showed, vect_recog_mulhs_pattern uses target_precision to
check the scale_term is expected or not, it could be wrong when the
precision of the actual used new_type larger than target_precision as
shown by the example.
This patch is to use precision of new_type instead of target_pr
Jeff Law writes:
On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE check for test case, e.g. (?n)/(?p)
* Use better wording for target.def
Currently, doloop.xx variable is us
on 2021/7/24 上午12:26, Martin Sebor wrote:
> On 7/23/21 2:41 AM, Kewen.Lin wrote:
>> on 2021/7/22 下午8:56, Richard Biener wrote:
>>> On Tue, Jul 20, 2021 at 4:37
>>> PM Kewen.Lin wrote:
Hi,
This v2 has addressed some review comments/suggestions:
- Use "!=" instead of
on 2021/7/24 上午12:10, Martin Sebor wrote:
> On 7/23/21 2:35 AM, Kewen.Lin wrote:
>> Hi,
>>
>> Comparing to v2, this v3 removed the new CTOR with struct loops *loops
>> as Richi clarified. I'd like to support it in a separated follow up
>> patch by extending the existing CTOR with an optional argum
On Mon, Jul 26, 2021 at 4:49 PM Hongtao Liu wrote:
>
> Correct mail list, please reply under this email.
>
> On Mon, Jul 26, 2021 at 4:47 PM liuhongt wrote:
> >
> > Hi:
> > As decribled in PR, the pinsr instruction has poor throughput in SKX
> > and CLX, which leads to worse performance in vect
On Mon, 26 Jul 2021 03:05:21 PDT (-0700), Andrew Waterman wrote:
On Thu, Jul 22, 2021 at 10:27 AM Palmer Dabbelt wrote:
On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> Could you add a testcase? Otherwise LGTM.
>
> Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp6
This change enables the "t1 != 0" check to be optimized away in this code:
int x1 = 0;
unsigned int x2 = 1;
int main ()
{
int t1 = x1*(1/(x2+x2));
if (t1 != 0) __builtin_abort();
return 0;
}
The change utilizes the VRP framework to propagate the get_nonzero_bits
information from the
On 7/26/21 5:01 PM, Jakub Jelinek wrote:
On Mon, Jul 26, 2021 at 04:57:14PM -0400, Andrew MacLeod wrote:
Handle ASCII and EBCDIC in toupper and tolower ranges.
gcc/
PR tree-optimization/7
* gimple-range-fold.cc (get_letter_range): New.
On Mon, Jul 26, 2021 at 3:56 PM H.J. Lu wrote:
>
> On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
> wrote:
> >
> > "H.J. Lu via Gcc-patches" writes:
> > > On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
> > > wrote:
> > >>
> > >> "H.J. Lu via Gcc-patches" writes:
> > >> > +to avoid stack
On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
> > wrote:
> >>
> >> "H.J. Lu via Gcc-patches" writes:
> >> > +to avoid stack realignment when expanding memset. The default is
> >> > +@code{ge
On Fri, Jul 23, 2021 at 10:27:37AM -0600, Jeff Law wrote:
> On 7/22/2021 7:04 AM, Richard Biener via Gcc-patches wrote:
> >On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
> > wrote:
> >>Gentle ping. Any suggestions would be appreciated.
> >So just to say something - does the existing cod
Hi Tobias,
> > This works as expected with Intel and AOCC, but gives a
> > syntax error with every gfortran tested because of match.c:
> >
> > alloc_opt_list:
> >m = gfc_match (" stat = %v", &tmp);
>
> I think we can simply change that one to %e; the definable
> check should ensure that a
"H.J. Lu via Gcc-patches" writes:
> On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
> wrote:
>>
>> "H.J. Lu via Gcc-patches" writes:
>> > +to avoid stack realignment when expanding memset. The default is
>> > +@code{gen_reg_rtx}.
>> > +@end deftypefn
>> > +
>> > @deftypefn {Target Hook} uns
On 22/07/2021 12:52, Richard Biener wrote:
> On Thu, Jul 22, 2021 at 1:48 PM Jakub Jelinek wrote:
>>
>> On Thu, Jul 22, 2021 at 01:43:49PM +0200, Richard Biener wrote:
>>> So I think we need to get to an agreement between the debug info
>>> producer and consumer here.
>>> Usually the DWARF spec is
On 26/07/2021 10:23 pm, Jakub Jelinek wrote:
On Mon, Jul 26, 2021 at 10:19:35PM +0100, Kwok Cheung Yeung wrote:
In that comment, Deepak says:
So, we decided to keep the target trait static, requiring that the declare
target directive must be explicit and that the function version must be
differ
Hi,
Similar to aarch64, this patch replaces call to builtin by
dereferencing __a in vld1_p64, vld1_s64 and vld1_u64.
The patch changes code-gen for the intrinsic as follows:
Before patch:
vld1.64 {d16}, [r0:64]
vmovr0, r1, d16 @ int
bx lr
After patch:
On Mon, Jul 26, 2021 at 10:19:35PM +0100, Kwok Cheung Yeung wrote:
> > Yes, that is a target variant, but I'm pretty sure we've decided that
> > the target construct added for declare target is actually not a dynamic
> > property. So basically mostly return to the 5.0 wording with clarifications
>
Hello
On 26/07/2021 8:56 pm, Jakub Jelinek wrote:
On Mon, Jul 26, 2021 at 08:28:16PM +0100, Kwok Cheung Yeung wrote:
In Section 1.2.2 of the OpenMP TR10 spec, 'target variant' is defined as:
A version of a device routine that can only be executed as part of a target
region.
Yes, that is a t
On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > +/* Callback routine for store_by_pieces. Read GET_MODE_BITSIZE (MODE)
> > + bytes from constant string DATA + OFFSET and return it as target
> > + constant. If PREV isn't nullptr, it has the
On Mon, Jul 26, 2021 at 04:46:46PM -0400, Michael Meissner wrote:
> On Wed, Jul 14, 2021 at 04:22:06PM -0500, Segher Boessenkool wrote:
> > > --- a/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c
> > > +++ b/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c
> >
> > > -/* { dg-final { scan-assembler-times
On Mon, Jul 26, 2021 at 04:57:14PM -0400, Andrew MacLeod wrote:
> Handle ASCII and EBCDIC in toupper and tolower ranges.
>
> gcc/
> PR tree-optimization/7
> * gimple-range-fold.cc (get_letter_range): New.
> (fold_using_range::range_of_bui
On 7/26/21 4:36 PM, Jakub Jelinek wrote:
On Mon, Jul 26, 2021 at 10:33:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
@@ -835,6 +836,43 @@ fold_using_range::range_of_builtin_ubsan_call (irange &r,
gcall *call,
r.set_varying (type);
}
+// Return TRUE if we recognize the target chara
On Wed, Jul 14, 2021 at 04:22:06PM -0500, Segher Boessenkool wrote:
> > --- a/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c
>
> > -/* { dg-final { scan-assembler-times "addic" 4 } } */
> > -/* { dg-final { scan-assembler-times "subfe" 1 } } */
On Mon, Jul 26, 2021 at 10:33:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > @@ -835,6 +836,43 @@ fold_using_range::range_of_builtin_ubsan_call (irange
> > &r, gcall *call,
> > r.set_varying (type);
> > }
> >
> > +// Return TRUE if we recognize the target character set and return the
On Mon, Jul 26, 2021 at 03:44:28PM -0400, Andrew MacLeod via Gcc-patches wrote:
> I'm testing this... Think this'll work better? we don't support any
> character sets where a space is 32 but it isnt ASCI.. and 64 isnt EBCDIC?
>
> This should handle those 2 sets.. and if is something else, it ba
On Mon, 2021-07-26 at 15:44 -0400, Andrew MacLeod wrote:
> I'm testing this... Think this'll work better? we don't support
> any
> character sets where a space is 32 but it isnt ASCI.. and 64 isnt
> EBCDIC?
Not sure; libcpp has some code for EBCDIC support, but it seems to be
for the host, not
On 7/26/21 3:45 AM, Tobias Burnus wrote:
[snip]
I did say that it mostly works because of:
$ find x86_64-pc-linux-gnu/ -name ISO_Fortran_binding.h
x86_64-pc-linux-gnu/libgfortran/ISO_Fortran_binding.h
x86_64-pc-linux-gnu/32/libgfortran/ISO_Fortran_binding.h
And when looking at the -B lines, I
On Mon, Jul 26, 2021 at 08:28:16PM +0100, Kwok Cheung Yeung wrote:
> In Section 1.2.2 of the OpenMP TR10 spec, 'target variant' is defined as:
>
> A version of a device routine that can only be executed as part of a target
> region.
Yes, that is a target variant, but I'm pretty sure we've decide
I'm testing this... Think this'll work better? we don't support any
character sets where a space is 32 but it isnt ASCI.. and 64 isnt EBCDIC?
This should handle those 2 sets.. and if is something else, it bails.
This seems OK? Im testing it now on x86-64... but dont have an ebcdic
target..
> Before, we had a loop with two iterations that tried "emit_cmov (cond,
> op2, op3)". op2 and op3 can (or even were) If this did not succeed we
> would revert the condition as well as op3 and op3 in-place and try
> again. I found that a bit cumbersome and intended to make this explicit
> b
Hello
Thanks for your reply.
On 26/07/2021 3:29 pm, Jakub Jelinek wrote:
On Fri, Jul 09, 2021 at 12:16:15PM +0100, Kwok Cheung Yeung wrote:
3) In the OpenMP examples (version 5.0.1), section 9.7, the example
metadirective.3.c does not work as expected.
#pragma omp declare target
void exp_pi_d
This patch fixes some false positives from
-Wanalyzer-use-of-uninitialized-value
when returning structs from functions (seen on the Linux kernel).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 3a1d168e9e0e3e38adedf5df393e9f8c075fc755.
gcc/analyzer/ChangeLog:
On 7/2/2021 2:13 AM, Aldy Hernandez wrote:
On 7/2/21 12:20 AM, Jeff Law wrote:
On 6/28/2021 10:21 AM, Aldy Hernandez wrote:
+// Internal construct to help facilitate debugging of solver.
+#define DEBUG_SOLVER getenv("DEBUG")
Shouldn't this really be a property of what pass is using the
Robin Dapp writes:
>> It looks like this is an existing (potential) problem,
>> but default_noce_conversion_profitable_p uses seq_cost, which in turn
>> uses insn_cost. And insn_cost has an optional target hook behind it,
>> which allows for costing based on insn attributes etc. For a true
>> ap
Robin Dapp writes:
> Hi Richard,
>
> thanks for going through the patch set.
>
>> A hash_set might be simpler, given that the code only enters insns
>> for which the bool is false. “rtx_insn *” would be better than rtx.
>
> Right, changed that.
>
>> Do you mean the sets might be removed or that t
On 7/26/21 2:39 PM, David Malcolm wrote:
On Mon, 2021-07-26 at 14:21 -0400, Andrew MacLeod via Gcc-patches
wrote:
Remove lower case characters from the range of to_upper and likewise,
upper case characters from to_lower.
I looked at also only adding the upper case characters for which there
is
"H.J. Lu via Gcc-patches" writes:
> +/* Callback routine for store_by_pieces. Read GET_MODE_BITSIZE (MODE)
> + bytes from constant string DATA + OFFSET and return it as target
> + constant. If PREV isn't nullptr, it has the RTL info from the
> + previous iteration. */
> +
> +rtx
> +builti
On Mon, 2021-07-26 at 14:21 -0400, Andrew MacLeod via Gcc-patches
wrote:
> Remove lower case characters from the range of to_upper and likewise,
> upper case characters from to_lower.
>
> I looked at also only adding the upper case characters for which there
> is a lower_case character in the ran
On 7/25/2021 10:23 AM, Uecker, Martin wrote:
Two arguments are switched for -Wnonnull when
warning about array parameters with bounds > 0
and which are NULL.
This patch corrects the mistake.
Martin
2021-07-25 Martin Uecker
gcc/
* calls.c (maybe_warn_rdwr_sizes): Correct argument
Remove lower case characters from the range of to_upper and likewise,
upper case characters from to_lower.
I looked at also only adding the upper case characters for which there
is a lower_case character in the range, but it seemed of limited use
Given some odd usage patterns we emit. . Inst
Jonathan Wright writes:
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> 74890989cb3045798bf8d0241467eaaf72238297..c4558da7c0f9228ccc5fa2b9c87e8b4690860b47
> 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-si
Aldy Hernandez writes:
> On Mon, Jul 26, 2021 at 4:18 PM Richard Sandiford
> wrote:
>>
>> Aldy Hernandez writes:
>> > This patch replaces the evrp_range_analyzer in the loop versioning code
>> > with an on-demand ranger.
>> >
>> > Everything was pretty straightforward, except that range_of_expr
On Linux/x86_64,
0cbf03689e3e7d9d6002b8e5d159ef3716d0404c is the first bad commit
commit 0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
Author: Tobias Burnus
Date: Mon Jul 26 14:20:46 2021 +0200
PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor
handling
caused
FAIL: gfort
On 23/07/21 19:21 +0100, Jonathan Wakely wrote:
I've been experimenting with this patch, which removes the need to use
std::tuple_element and std::get to access the members of a std::pair
in unordered_{map,multimap}.
I'm in the process of refactoring the header to reduce
header dependencies thr
It was pointed out in PR101598 to be inappropriate, that
ignored Ada decls receive the source line number which was
recorded in the function decl's DECL_SOURCE_LOCATION.
Therefore set all front-end-generated Ada decls with
DECL_IGNORED_P to UNKNOWN_LOCATION.
2021-07-24 Bernd Edlinger
P
Ignored functions decls that are compiled at the start of
the assembly have bogus line numbers until the first .file
directive, as reported in PR101575.
The work around for this issue is to emit a dummy .file
directive when the first function is DECL_IGNORED_P, when
that is not already done, mostl
This fixes a regression which was introduced accidentally with
commit e69ac020372 ("Add line debug info for virtual thunks").
That is certain Ada functions have now a .loc directive which is
probably not how the debug experience of those functions was intended.
Currently those functions stop in t
> On Jul 26, 2021, at 11:09 AM, Martin Jambor wrote:
>
> Hi,
>
>>> So you either need to change build_access_from_expr like I described in
>>> my email
>>
>> Is the following the change you suggested previously:
>>
>> [opc@qinzhao-ol8u3-x86 gcc]$ git diff tree-sra.c
>> diff --git a/gcc/tree-
> > How expensive is the check? If the result is worth caching, perhaps
> > we should have two bitmaps: the existing one, and one that records
> > whether we've checked a particular SSA name.
> >
> > If the check is relatively cheap then that won't be worth it though.
>
> If you're asking about th
Hi,
On Mon, Jul 26 2021, Qing Zhao wrote:
> HI, Martin,
>
> Thank you for the comments and suggestions on tree-sra.c changes.
>
>>> **Compare with the 4th version, the following are the major changes:
>>>
>>> 1. delete the code for handling "grp_to_be_debug_replaced" since they are
>>> not n
Martin,
The following is the patch to fix the issues you raised in the previous email,
let me know if I still miss anything:
Thanks a lot.
Qing
=
From 14524a228b4b41b4eaaa2497455725e075126c2c Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 26 Jul 2021 15:46:59 +
Subject: [PATCH]
On Mon, 26 Jul 2021, Roger Sayle wrote:
The one aspect that's a little odd is that each transform is paired with
a convert@1 variant, using the efficient match machinery to expose any
zero extension to fold-const.c's tree_nonzero_bits functionality.
Copying the first transform for context
+(
On Mon, 2021-07-26 at 21:04 +0530, Ankur Saini wrote:
>
> Here is the latest patch after fixing all the nit picks and issues
> pointed out by everyone.
>
Looks good to me.
Thanks
Dave
Here is the latest patch after fixing all the nit picks and issues pointed out
by everyone.
call_string.patch
Description: Binary data
Thanks you
- Ankur
HI, Martin,
Thank you for the comments and suggestions on tree-sra.c changes.
>> **Compare with the 4th version, the following are the major changes:
>>
>> 1. delete the code for handling "grp_to_be_debug_replaced" since they are
>> not needed per Martin Jambor's suggestion.
>
> sorry if I
On Mon, Jul 26, 2021 at 4:18 PM Richard Sandiford
wrote:
>
> Aldy Hernandez writes:
> > This patch replaces the evrp_range_analyzer in the loop versioning code
> > with an on-demand ranger.
> >
> > Everything was pretty straightforward, except that range_of_expr requires
> > a gimple statement as
On 7/25/2021 7:47 PM, Bin.Cheng wrote:
On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches
wrote:
On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:
Hi,
I ran into a wrong code bug in code with deep template instantiation when
working on sdx::simd.
The root cause as described i
On Mon, 26 Jul 2021, Richard Sandiford wrote:
> >> Sorry, somehow I didn't see Richard's reply. Perhaps a
> >> misconfiguration
> >> on my mail server.
>
> I don't know where the problem lies, but for some reason I've been
> getting rejects when sending messages directly (via reply-all).
Somet
On 7/24/2021 3:44 AM, Roger Sayle wrote:
My apologies for the short delay. Thanks for explaining why these
transforms
don't usually require explicit tests for side-effects (but occasionally do).
This does simplify things; please find attached the shorter revised patch.
This patch has been re
This patch adjusts XORing of ranges where the operands are known to be
equal or not equal.
We should probably do the same thing for the op[12]_range methods.
Tested on x86-64 Linux.
gcc/ChangeLog:
* range-op.cc (operator_bitwise_xor::op1_op2_relation_effect):
New.
---
gcc/range
Fix a small oversight in methods calling the base class fold_range.
Tested on x86-64 Linux.
gcc/ChangeLog:
* range-op.cc (operator_lshift::fold_range): Pass rel to
base class fold_range.
(operator_rshift::fold_range): Same.
---
gcc/range-op.cc | 8
1 file change
On 7/15/2021 1:58 AM, Richard Biener via Gcc-patches wrote:
On Thu, Jul 15, 2021 at 3:54 AM ashimida via Gcc-patches
wrote:
External declarations in ./gcc/toplev.h is no longer used in newest
version of gcc and should be cleaned up to avoid misunderstandings.
OK
gcc/ChangeLog:
On 7/22/2021 4:27 PM, Martin Sebor via Gcc-patches wrote:
Passing a pointer to a built-in function escapes it, which in
turn causes objects pointed to by other potentially aliased
pointers to be assumed to be modified by other built-in calls.
This leads to a class of false negative -Wuninitial
On Fri, Jul 09, 2021 at 12:16:15PM +0100, Kwok Cheung Yeung wrote:
> This is a WIP implementation of metadirectives as defined in the OpenMP 5.0
> spec. I intend to add support for metadirectives as specified in OpenMP 5.1
> later (where the directive can be selected dynamically at runtime), but am
Aldy Hernandez writes:
> This patch replaces the evrp_range_analyzer in the loop versioning code
> with an on-demand ranger.
>
> Everything was pretty straightforward, except that range_of_expr requires
> a gimple statement as context to provide context aware ranges. I didn't see
> a convient pla
Tamar Christina writes:
> Hi,
>
> Sorry It looks like I forgot to ask if OK for backport to GCC 9, 10, 11 after
> some stew.
Yeah, OK for backports too.
Thanks,
Richard
>
> Thanks,
> Tamar
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Thursday, July 22, 2021 7:11 PM
>> T
Xi Ruoyao writes:
> On Fri, 2021-07-23 at 11:18 +0800, Xi Ruoyao wrote:
>> On Fri, 2021-07-23 at 04:21 +0200, Maciej W. Rozycki wrote:
>> > On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote:
>> >
>> > > > > > > The "smallest fix" is simply adding -fno-inline into
>> > > > > > > mips.exp
PING * 2
BTW, this is also needed for:
a) evrp_range_analyzer removal from DOM threader (I have follow-up patches).
b) VRP replacement with evrp along with VRP threader removal (I also
have patches).
Thanks.
Aldy
On Thu, Jul 15, 2021 at 4:57 PM Aldy Hernandez wrote:
>
> As mentioned in my pr
I have now committed José's patch with the two nits fixed
(cf. my on-top patch to which I just replied)
r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
Note:
I have slightly reworded the error message compared to both
the original patch and to my on-top suggestion.
Reason:
When calling a BIN
VRP simplifies conditionals involving casted values outside of the main
folding mechanism, because this optimization inhibits the VRP jump
threader from threading through the comparison.
As part of replacing VRP with an evrp instance, I am making sure we do
everything VRP does. Hence, I am abstra
Xi Ruoyao via Gcc-patches writes:
> We are comparing enum values (in wide_int) to check ODR violation.
> However, if we compare two wide_int values with different precision,
> we'll trigger an assert, leading to ICE. With enum-base introduced
> in C++11, it's easy to sink into this situation.
>
>
Ping? Does anyone have any opinions on how this issue should be resolved?
On 09/07/2021 12:16 pm, Kwok Cheung Yeung wrote:
3) In the OpenMP examples (version 5.0.1), section 9.7, the example
metadirective.3.c does not work as expected.
#pragma omp declare target
void exp_pi_diff(double *d, dou
The easiest way to motivate these additions to match.pd is with the
following example:
unsigned int foo(unsigned char i) {
return i | (i<<8) | (i<<16) | (i<<24);
}
which mainline with -O2 on x86_64 currently generates:
foo:movzbl %dil, %edi
movl%edi, %eax
movl%edi,
The following patch to the x86_64 backend improves the code generated
for a decrement followed by a conditional move. The primary change is
to recognize that after subtracting one, checking the result is -1 (or
equivalently that the original value was zero) can be implemented using
the borrow/car
Hi,
On Sun, Jul 25 2021, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> This is the 5th version of the patch for the new security feature for GCC.
>
> I have tested it with bootstrap on both x86 and aarch64, regression testing
> on both x86 and aarch64.
> Also compile and run CPU2017, without any iss
On Thu, Jul 22, 2021 at 10:27 AM Palmer Dabbelt wrote:
>
> On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Could you add a testcase? Otherwise LGTM.
> >
> > Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
> > void foo(char *dst){
> >__builtin_memset(dst, 0,
I have changed the use of the array_bounds_checker in VRP to use a
ranger in my local tree to make sure there are no regressions when using
either VRP or the ranger. In doing so I noticed that the checker
does not pass context to get_value_range, which causes the ranger to miss a
few cases. This
On Fri, 23 Jul 2021 at 17:39, Patrick Palka via Libstdc++
wrote:
>
> In passing, this also renames the template parameter _O2 to _Out2 in
> ranges::partition_copy and uglify its function parameters out_true
> and out_false.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk+branches?
On Fri, 23 Jul 2021 at 17:35, Patrick Palka via Libstdc++
wrote:
>
> In r12-569 I accidentally applied the LWG 3533 change that
> was intended for elements_view::iterator::base to
> elements_view::base instead.
>
> This patch corrects this, and also applies the corresponding LWG 3533
> change to l
LGTM, but I would like to wait Palmer's ack.
I am fine with current scheme, just check riscv_slow_unaligned_access_p,
in case we have performance issue, we can consider change mtune's
slow_unaligned_access field to a number rather than a boolean value,
so that we can have better cost model for tha
Hi Sandra,
On 23.07.21 22:43, Sandra Loosemore wrote:
On 7/23/21 8:15 AM, Tobias Burnus wrote:
On 21.07.21 12:17, Tobias Burnus wrote:
On 13.07.21 23:28, Sandra Loosemore wrote:
ISO_Fortran_binding.h is now generated in the libgfortran build
directory where it is on the default include path.
> On 25-Jul-2021, at 7:59 PM, Prathamesh Kulkarni
> wrote:
>
> !(*this == other)
Thanks for the suggestion.
Here is the updated patch.
Thank you
- Ankur
Hi,
This updated patch fixes the two-operators-per-row style issue in the
aarch64-simd.md RTL patterns as well as integrating the simplify-rtx.c
change as suggested.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
Ok for master?
Thanks,
Jonathan
---
gcc/ChangeLog:
Correct mail list, please reply under this email.
On Mon, Jul 26, 2021 at 4:47 PM liuhongt wrote:
>
> Hi:
> As decribled in PR, the pinsr instruction has poor throughput in SKX
> and CLX, which leads to worse performance in vectorization in some cases.
> This patch adds a cost member named inte
Hi Sandra,
On 25.07.21 06:11, Sandra Loosemore wrote:
Congratulation – we have found a bug in the spec, which is also
present in the current draft (21-007). I have now written to J3:
https://mailman.j3-fortran.org/pipermail/j3/2021-July/013189.html
That discussion seems to have wandered off in
Hi!
For the following testcase, B is 16-byte type, containing 8-byte
virtual pointer and 1-byte A member, and C contains two FIELD_DECLs,
one with B type and size of just 8-byte and then a field with type
A and 1-byte size.
The __builtin_clear_padding code was upset about the B typed FIELD_DECL
co
Hi!
This patch adds support for expressing the section and scan directives
using the attribute syntax and additionally fixes some bugs in the attribute
syntax directive handling.
For now it requires that the scan and section directives appear as the only
attribute, not combined with other OpenMP o
90 matches
Mail list logo
