On Fri, Aug 07, 2020 at 11:36:59PM +0200, Marc Glisse wrote:
> > > https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm is the most
> > > common way to compute the modular multiplicative inverse of a number. For
> > > 3
> > > and 2^32, it could tell us that 2863311531*3-2*2^32=1, so modulo 2
On 8/7/20 6:52 PM, Segher Boessenkool wrote:
> The element_mode vs. TYPE_MODE here does not matter, because we never
> deal with vector modes here, and they will error elsewhere anyway?
Agreed, TYPE_MODE is fine here.
> Okay for trunk if that is true (or with the necessary adjustments), and
> ok
This patch updates libgo to the go1.15rc2 release candidate.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
10c8507372f3e1c09df0bfe6449c126dee5075de
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index c21b6000229..b6089f3f01d 100644
--- a/gcc
Hi!
On Fri, Aug 07, 2020 at 05:16:30PM -0500, Peter Bergner wrote:
> We do not allow conversions between the MMA types and other types.
> However, we are being too strict in not matching MMA types with
> typdefs of those types. Use TYPE_CANONICAL to see through the
> types to their canonical type
Hi!
On Fri, Aug 07, 2020 at 11:06:38AM -0500, Qing Zhao wrote:
> > It would be nice if this described anywhere what the benefit of this is,
> > including actual hard numbers. I only see it is very costly, and I see
> > no benefit whatsoever.
>
> I will add the motivation of this patch clearly in
We do not allow conversions between the MMA types and other types.
However, we are being too strict in not matching MMA types with
typdefs of those types. Use TYPE_CANONICAL to see through the
types to their canonical types before comparing them.
This is currently bootstrapping and regtesting. O
On 07/08/20 21:57, Marc Glisse wrote:
On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote:
However, there are cases were the second division will not be
possible without rest.
Consider : 7*X == 3
3/7 is 0 rest 3.
0x1 / 7 is 0x24924924 rest 4
Since 3 cannot be represented as an integer
When the compgotos pass copies the tail of blocks ending in an indirect
jump, there is a micro-optimization to not copy the last one, since the
original block will then just be deleted. This does not work properly
if cleanup_cfg does not merge all pairs of blocks we expect it to.
v2: This also d
On Fri, 7 Aug 2020, Jakub Jelinek wrote:
On Fri, Aug 07, 2020 at 10:57:54PM +0200, Marc Glisse wrote:
On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote:
On 07/08/20 19:21, Marc Glisse wrote:
If we are going to handle the wrapping case, we shouldn't limit to
the non-wrapping meaning of mult
On Fri, Aug 07, 2020 at 10:57:54PM +0200, Marc Glisse wrote:
> On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote:
>
> >
> > On 07/08/20 19:21, Marc Glisse wrote:
> > >
> > > If we are going to handle the wrapping case, we shouldn't limit to
> > > the non-wrapping meaning of multiplicity. 3*X==5
On Fri, Aug 07, 2020 at 08:35:52PM +, Bert Tenjy via Gcc-patches wrote:
> The document describing POWER Architecture Vector Function interface is
> tentatively at:
> https://sourceware.org/glibc/wiki/Homepage?action=AttachFile&do=view&target=powerarchvectfuncabi.html
Doesn't exist.
> + if (
On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote:
On 07/08/20 19:21, Marc Glisse wrote:
If we are going to handle the wrapping case, we shouldn't limit to the
non-wrapping meaning of multiplicity. 3*X==5 should become X==1431655767
(for a 32 bit type), etc.
Do we have an extended gcd som
From: Bert Tenjy
This patch adds functionality to enable use of POWER Architecture's
VSX extensions to speed up certain code sequences. Typically
2 or 4 consecutive loop iterations that each make a single scalar
function call will be combined into one iteration making a single
vector function cal
On 07/08/20 19:21, Marc Glisse wrote:
If we are going to handle the wrapping case, we shouldn't limit to the
non-wrapping meaning of multiplicity. 3*X==5 should become
X==1431655767 (for a 32 bit type), etc.
Do we have an extended gcd somewhere in gcc, to help compute 1431655767?
I don't
On 8/6/20 1:52 PM, Patrick Palka wrote:
When resolving the address of a template-id, we need to drop functions
whose associated constraints are not satisfied, as per [over.over]. We
do so in resolve_address_of_overloaded_function, but not in
resolve_overloaded_unification or resolve_nondeduced_c
On 8/6/20 1:50 PM, Patrick Palka wrote:
This patch eliminates an exponential dependence in cxx_eval_vec_init on
the array dimension of a VEC_INIT_EXPR when the RANGE_EXPR optimization
applies. This is achieved by using a single constructor_elt (with index
RANGE_EXPR 0...max-1) per dimension inst
With -pedantic the debug mode bitset has an ambiguous equality
comparison operator, because it tries to compare the non-debug base to
the debug object. The base object can be converted to another debug
bitset, making the same operator== a candidate again.
The fix is to do the comparison on both ba
On Fri, Aug 07, 2020 at 08:04:57PM +0200, Aldy Hernandez wrote:
> --- a/gcc/ipa-fnsummary.c
> +++ b/gcc/ipa-fnsummary.c
> @@ -82,7 +82,6 @@ along with GCC; see the file COPYING3. If not see
> #include "gimplify.h"
> #include "stringpool.h"
> #include "attribs.h"
> -#include
> #include "tree-i
On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote:
this transformation is quite straightforward, without overflow, 3*X==15 is
the same as X==5 and 3*X==5 cannot happen.
Actually, with binary and decimal computers, this transformation (with
these specific numbers) is also valid for wrapping ov
Is the attached patch what y'all suggest?
The patch reverts the GCC vec<> usage in ipa-fnsummary.c and
implements the above suggestion.
Bootstraps, tests running...
If tests pass, is this OK?
Thanks.
Aldy
On Fri, Aug 7, 2020 at 11:17 AM Jonathan Wakely via Gcc-patches
wrote:
>
> On 07/08/20 1
Since last week's patchlet, I've delayed the creation of the exalias
decls, improved the merging of attributes, minimizing
interface/visibility updates, found a better way to assign exaliases to
nested explicit instantiations, even after enabling aliases to
already-defined types, so now I'm reasona
On 7/28/20 7:16 PM, Martin Sebor wrote:
Patch 1 adds the basic infrastructure to support array/VLA bounds
in attribute access. It extends the access string specification
to describe function parameters of array types (including VLAs),
extends the attr_access class to parse the string and store
t
Hi, Alexandre,
Thank you for the comments and suggestions.
> On Aug 7, 2020, at 8:20 AM, Alexandre Oliva wrote:
>
> On Jul 28, 2020, Qing Zhao via Gcc-patches wrote:
>
>>> 2. The main code generation part is moved from i386 backend to middle-end;
>>> 3. Add 4 target-hooks;
>>> 4. Implement th
On 7/29/20 12:12 PM, Joseph Myers wrote:
On Tue, 28 Jul 2020, Martin Sebor via Gcc-patches wrote:
+ /* A list of VLA variable bounds or null if not specified. */
+ tree vbchain = NULL_TREE;
+ if (parm->declarator->kind == cdk_array)
+ if (pd->kind != cdk_array)
+ break;
libstdc++-v3/ChangeLog:
* testsuite/18_support/comparisons/algorithms/partial_order.cc:
Replace VERIFY with static_assert where the compiler now
allows it.
* testsuite/18_support/comparisons/algorithms/weak_order.cc:
Likewise.
Tested x86_64-linux. Committed
On Fri, 7 Aug 2020, Richard Biener wrote:
I was mostly thinking of storing information like:
* don't care about the rounding mode for this operation
* may drop exceptions produced by this operation
* may produce extra exceptions
* don't care about signed zero
* may contract into FMA
* don't care
> On Aug 7, 2020, at 1:21 AM, Richard Biener wrote:
>
> On Thu, 6 Aug 2020, Kees Cook wrote:
>
>> On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote:
>>> OK, so -fzero-call-used-regs is a ROP mitigation technique. To me
>>> it sounded more like a mitigation against information le
Hi, Segher,
Thanks for your comments.
> On Aug 6, 2020, at 6:37 PM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote:
>> Jeff might be, but with the intended purpose (ROP mitigation AFAIU)
>> it would be nice for other target maintainers t
On 07/08/20 15:17 +0100, Jonathan Wakely via Libstdc++ wrote:
On 07/08/20 14:48 +0100, Jonathan Wakely wrote:
On 07/08/20 14:02 +0200, Rainer Orth wrote:
Hi Jonathan,
Here's the combined patch, based on your original with my proposed
simplifications applied.
I've now pushed that combined pa
This patch adds the device_type(any|nohost|host)
clause for 'omp declare target' to Fortran.
In OpenMP 5.0, it has no effect on variables but
only on procedures – in TR8 (and later), it also
affects variables.
This patch adds this clause to either – except that
the middle end does not seem to li
Hello,
On 05 авг 09:29, Hongtao Liu wrote:
> On Tue, Aug 4, 2020 at 6:28 PM Kirill Yukhin wrote:
> >
> > On 04 авг 13:26, Kirill Yukhin wrote:
> > > Could you please clarify, how your patch relared to [1]?
> > > I see from the bug that it describes perf issue w.r.t. scalar
> > > operations.
> >
>
On Fri, Aug 07, 2020 at 12:58:08PM +0930, Alan Modra wrote:
> On Thu, Aug 06, 2020 at 05:34:03PM -0500, Segher Boessenkool wrote:
> > > +/* { dg-do run } */
> > > +/* { dg-options "-mdejagnu-cpu=powerpc64 -O2" } */
> >
> > That is not a -mcpu= value you should ever use. Please just pick a real
>
Hi!
On Fri, Aug 07, 2020 at 10:44:10AM +0800, Kewen.Lin wrote:
> > I think this makes a lot of sense.
> >
> >> btw, not sure whether it's a good idea to move target_option_override_hook
> >> call into print_specific_help and use one function local static
> >> variable to control it's called once
On Fri, Aug 07, 2020 at 09:21:27AM -0400, Nathan Sidwell wrote:
> On 8/6/20 6:55 PM, Marek Polacek wrote:
> > On Thu, Aug 06, 2020 at 10:01:37AM -0400, Nathan Sidwell wrote:
> > > On 8/5/20 7:29 PM, Marek Polacek wrote:
> > > > On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote:
> > > >
On 07/08/20 14:48 +0100, Jonathan Wakely wrote:
On 07/08/20 14:02 +0200, Rainer Orth wrote:
Hi Jonathan,
Here's the combined patch, based on your original with my proposed
simplifications applied.
I've now pushed that combined patch to master.
Sorry it took so long to integrate your changes
Kindly pinging for a review of the libiberty parts of this patch. (e.g. the
changes in include/ and libiberty/)
The readme in libiberty suggests to ask for approval on this mailing list. The
gdb mailing list already approved the rest of the patch.
If you are missing some info or if I am doing so
On 07/08/20 14:02 +0200, Rainer Orth wrote:
Hi Jonathan,
Here's the combined patch, based on your original with my proposed
simplifications applied.
I've now pushed that combined patch to master.
Sorry it took so long to integrate your changes, but thanks very much
for the contribution to GC
On Thu, Aug 6, 2020 at 10:40 AM Roger Sayle wrote:
>
>
> Hi Uros,
>
> Many thanks for the review and feedback. Here's the final version as
> committed,
> with both the test cases requested by Richard Biener and your
> suggestion/request
> to use ix86_expand_clear. Tested again on x86_64-pc-lin
On 8/6/20 6:55 PM, Marek Polacek wrote:
On Thu, Aug 06, 2020 at 10:01:37AM -0400, Nathan Sidwell wrote:
On 8/5/20 7:29 PM, Marek Polacek wrote:
On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote:
On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote:
On Tue, Aug 04, 2020 at 03:33
On Jul 28, 2020, Qing Zhao via Gcc-patches wrote:
>> 2. The main code generation part is moved from i386 backend to middle-end;
>> 3. Add 4 target-hooks;
>> 4. Implement these 4 target-hooks on i386 backend.
>> 5. On a target that does not implement the target hook, issue error
I wonder... How
On 8/6/20 8:01 PM, Mike Stump wrote:
On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote:
XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error)
PASS: g++.dg/foo.C -std=c++17 (test for excess errors)
Which one of these would you not like to see?
Neither of these is solving the issue. How
this transformation is quite straightforward, without overflow, 3*X==15 is
the same as X==5 and 3*X==5 cannot happen.
Actually, with binary and decimal computers, this transformation (with these
specific numbers)
is also valid for wrapping overflow. More generally, it is valid for wrapping
ov
On Fri, Aug 7, 2020 at 2:15 PM Marc Glisse wrote:
>
> On Fri, 7 Aug 2020, Richard Biener wrote:
>
> > On Fri, Aug 7, 2020 at 10:33 AM Marc Glisse wrote:
> >>
> >> On Fri, 7 Aug 2020, Richard Biener wrote:
> >>
> >>> On Thu, Aug 6, 2020 at 8:07 PM Marc Glisse wrote:
>
> On Thu, 6 Aug 20
On 06/08/2020 04:54, Richard Sandiford wrote:
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index f9b0e9714d9..d7067989ad7 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -947,6 +947,11 @@ validate_subreg (machine_mode omode, machine_mode imode,
else if (VECTOR_MODE_P (omode)
&&
On Fri, 7 Aug 2020, Richard Biener wrote:
On Fri, Aug 7, 2020 at 10:33 AM Marc Glisse wrote:
On Fri, 7 Aug 2020, Richard Biener wrote:
On Thu, Aug 6, 2020 at 8:07 PM Marc Glisse wrote:
On Thu, 6 Aug 2020, Christophe Lyon wrote:
Was I on the right track configuring with
--target=arm-non
Hi Jonathan,
>>Here's the combined patch, based on your original with my proposed
>>simplifications applied.
>
> I've now pushed that combined patch to master.
>
> Sorry it took so long to integrate your changes, but thanks very much
> for the contribution to GCC!
it seems this patch caused
+FAI
On Fri, Aug 7, 2020 at 12:45 PM Marc Glisse wrote:
>
> Thank you for your comments.
>
> On Fri, 7 Aug 2020, Richard Biener wrote:
>
> >> Conversions look like
> >> .FENV_CONVERT (arg, (target_type*)0, 0)
> >> the pointer is there so we know the target type, even if the lhs
> >> disappears at some
Hi,
On x86, a memory reference reference to a TLS address can be broken out
and stored in a register, for instance:
movq%fs:8+testYearsBC@tpoff, %rdx
Subsequently becomes:
pushq %rbp
leaq8+testYearsBC@tpoff, %rbp
// later...
movq%fs:0(%rbp), %rd
Hi,
This patch adds support for 'in' as a first-class storage class with its
own mangle symbol, of which also permits 'in ref'. Previously, 'in' was
an alias to 'const [scope]', which is a type constructor.
The mangle symbol repurposed for this is 'I', which was originally used
by identifier typ
Pinging for this series of patches.
Attached all patches to this mail with the ammended patch 4 thanks to
Segher's review.
I forgot to mention originally that these patches require the previously
submitted "simplify and extend shift instruction patterns" patch to be
first applied.
https://gcc.gnu.
Pinging for this patch.
Thanks,
Jozef
On Tue, Jul 21, 2020 at 07:29:53PM +0100, Jozef Lawrynowicz wrote:
> The implementation of define_expand and define_insn patterns to handle
> shifts in the MSP430 backend is inconsistent, resulting in missed
> opportunities to make best use of the architectur
Thank you for your comments.
On Fri, 7 Aug 2020, Richard Biener wrote:
Conversions look like
.FENV_CONVERT (arg, (target_type*)0, 0)
the pointer is there so we know the target type, even if the lhs
disappears at some point. The last 0 is the same as for all the others, a
place to store options
This avoids if-converting when encountering control-altering calls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-08-07 Richard Biener
PR tree-optimization/96514
* tree-if-conv.c (if_convertible_bb_p): If the last stmt
is a call that is control-alte
Hi Richard
Thank you very much.
Richard Sandiford writes:
>Hi Qian,
>
>"Qian, Jianhua" writes:
>> Hi Richard
>>
>>> Would you like the patch to be backported further than GCC 10?
>> That is good if it could be backported to GCC9.
>
>Sure, now done.
>
>>> Does the attached patch to document the
Hi Qian,
"Qian, Jianhua" writes:
> Hi Richard
>
>> Would you like the patch to be backported further than GCC 10?
> That is good if it could be backported to GCC9.
Sure, now done.
>> Does the attached patch to document the addition to GCC 10.3 look OK?
> To avoid misunderstanding, could you ple
This patch is a little cleanup that removes trailing whitespaces from
the bpf backend source files.
2020-08-07 Jose E. Marchesi
gcc/
* config/bpf/bpf.md: Remove trailing whitespaces.
* config/bpf/constraints.md: Likewise.
* config/bpf/predicates.md: Likewise.
gcc/tests
On Wed, Aug 5, 2020 at 8:02 PM Marc Glisse wrote:
>
> Hello,
>
> I updated the patch discussed in
> https://patchwork.ozlabs.org/project/gcc/patch/alpine.deb.2.02.1906221743430.16...@grove.saclay.inria.fr/
> and pushed it as something like refs/users/glisse/heads/fenv (first user
> branch in gcc's
On 07/08/20 10:55 +0200, Jakub Jelinek wrote:
On Fri, Aug 07, 2020 at 09:34:38AM +0100, Jonathan Wakely via Gcc-patches wrote:
> Now that you say it, vec has a T[1] member so depending on T
> there might be a side-effect as invoking its CTOR? Or it might
> even not compile if there is no defaul
Hi,
I'm working on converting the AVR backend to MODE_CC, following
the steps described for case #2 in the CC0 transition wiki page,
and I've implemented the first three bullet
points (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed). With
the below patch, there are zero reg
On Fri, Aug 07, 2020 at 09:34:38AM +0100, Jonathan Wakely via Gcc-patches wrote:
> > Now that you say it, vec has a T[1] member so depending on T
> > there might be a side-effect as invoking its CTOR? Or it might
> > even not compile if there is no default CTOR available... Ick :/
>
> Right.
>
On Fri, Aug 7, 2020 at 10:34 AM Jonathan Wakely wrote:
>
> On 07/08/20 10:22 +0200, Richard Biener wrote:
> >On Fri, Aug 7, 2020 at 9:57 AM Jonathan Wakely wrote:
> >>
> >> On 07/08/20 08:48 +0200, Richard Biener wrote:
> >> >On Thu, Aug 6, 2020 at 9:24 PM Jonathan Wakely wrote:
> >> >>
> >> >>
On Fri, Aug 7, 2020 at 10:33 AM Marc Glisse wrote:
>
> On Fri, 7 Aug 2020, Richard Biener wrote:
>
> > On Thu, Aug 6, 2020 at 8:07 PM Marc Glisse wrote:
> >>
> >> On Thu, 6 Aug 2020, Christophe Lyon wrote:
> >>
> Was I on the right track configuring with
> --target=arm-none-linux-gnueab
On 07/08/20 10:22 +0200, Richard Biener wrote:
On Fri, Aug 7, 2020 at 9:57 AM Jonathan Wakely wrote:
On 07/08/20 08:48 +0200, Richard Biener wrote:
>On Thu, Aug 6, 2020 at 9:24 PM Jonathan Wakely wrote:
>>
>> On 06/08/20 19:58 +0200, Aldy Hernandez wrote:
>> >
>> >
>> >On 8/6/20 6:30 PM, Jona
On Fri, 7 Aug 2020, Richard Biener wrote:
On Thu, Aug 6, 2020 at 8:07 PM Marc Glisse wrote:
On Thu, 6 Aug 2020, Christophe Lyon wrote:
Was I on the right track configuring with
--target=arm-none-linux-gnueabihf --with-cpu=cortex-a9
--with-fpu=neon-fp16
then compiling without any special opt
On Fri, Aug 7, 2020 at 9:57 AM Jonathan Wakely wrote:
>
> On 07/08/20 08:48 +0200, Richard Biener wrote:
> >On Thu, Aug 6, 2020 at 9:24 PM Jonathan Wakely wrote:
> >>
> >> On 06/08/20 19:58 +0200, Aldy Hernandez wrote:
> >> >
> >> >
> >> >On 8/6/20 6:30 PM, Jonathan Wakely wrote:
> >> >>On 06/08/
Hi Omar,
From: Omar Tahir
Sent: 04 August 2020 17:16
To: Kyrylo Tkachov ; ni...@redhat.com; Ramana
Radhakrishnan ; Richard Earnshaw
; gcc-patches@gcc.gnu.org
Subject: [PATCH 5/5][Arm] New pattern for CSEL, CSET and CSETM instructions
This patch adds a new pattern, *cmovsi_insn, for generating
Hi Omar,
From: Omar Tahir
Sent: 04 August 2020 17:15
To: Kyrylo Tkachov ; ni...@redhat.com; Ramana
Radhakrishnan ; Richard Earnshaw
; gcc-patches@gcc.gnu.org
Subject: [PATCH 4/5][Arm] New pattern for CSNEG instructions
This patch adds a new pattern, *thumb2_csneg, for generating CSNEG
instruc
On 07/08/20 08:48 +0200, Richard Biener wrote:
On Thu, Aug 6, 2020 at 9:24 PM Jonathan Wakely wrote:
On 06/08/20 19:58 +0200, Aldy Hernandez wrote:
>
>
>On 8/6/20 6:30 PM, Jonathan Wakely wrote:
>>On 06/08/20 16:17 +0200, Aldy Hernandez wrote:
>>>
>>>
>>>On 8/6/20 12:48 PM, Jonathan Wakely wro
> -Original Message-
> From: Omar Tahir
> Sent: 06 August 2020 13:02
> To: Kyrylo Tkachov ; ni...@redhat.com;
> Ramana Radhakrishnan ; Richard
> Earnshaw ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH 3/5][Arm] New pattern for CSINC instructions
>
> > Hi Omar,
> >
> > diff --git a/gcc
69 matches
Mail list logo
