On Mon, Jun 24, 2019 at 02:45:09PM +0800, Kewen.Lin wrote:
> on 2019/6/24 下午2:00, Li Jia He wrote:
> > -#define TARGET_MADDLD (TARGET_MODULO && TARGET_POWERPC64)
> > +#define TARGET_MADDLD TARGET_MODULO
>
> IMHO, I don't think this removal of TARGET_POWERPC64 is reasonable.
> As ISA V3.0
Hi Lijia,
On Mon, Jun 24, 2019 at 01:00:05AM -0500, Li Jia He wrote:
> >From PowerPC ISA3.0, the description of `maddld RT, RA.RB, RC` is as follows:
> 64-bit RA and RB are multiplied and then the RC is signed extend to 128 bits,
> and add them together.
>
> We only apply it to 64-bit mode (DI) w
on 2019/6/24 下午3:19, Segher Boessenkool wrote:
> On Mon, Jun 24, 2019 at 02:45:09PM +0800, Kewen.Lin wrote:
>> on 2019/6/24 下午2:00, Li Jia He wrote:
>>> -#define TARGET_MADDLD (TARGET_MODULO && TARGET_POWERPC64)
>>> +#define TARGET_MADDLD TARGET_MODULO
>>
>> IMHO, I don't think this remov
on 2019/6/24 下午3:43, Kewen.Lin wrote:
> on 2019/6/24 下午3:19, Segher Boessenkool wrote:
>> On Mon, Jun 24, 2019 at 02:45:09PM +0800, Kewen.Lin wrote:
>>> on 2019/6/24 下午2:00, Li Jia He wrote:
-#define TARGET_MADDLD (TARGET_MODULO && TARGET_POWERPC64)
+#define TARGET_MADDLD TARGET
> Forgot to say that this list excludes targets for which there were
> no changes in assembly length. (Thought I'd better say that since
> the list clearly doesn't have one entry per CPU directory.)
>
> FWIW the full list was:
>
> aarch64-linux-gnu aarch64_be-linux-gnu alpha-linux-gnu amdgcn
Hi Kewen,
On Mon, Jun 24, 2019 at 03:43:26PM +0800, Kewen.Lin wrote:
> on 2019/6/24 下午3:19, Segher Boessenkool wrote:
> > Newer ISAs require 64-bit to be implemented. There are no optional
> > 64-bit categories anymore. Since this instruction is enabled for P9
> > (ISA 3.0) only (that's the TARG
Eric Botcazou writes:
>> Forgot to say that this list excludes targets for which there were
>> no changes in assembly length. (Thought I'd better say that since
>> the list clearly doesn't have one entry per CPU directory.)
>>
>> FWIW the full list was:
>>
>> aarch64-linux-gnu aarch64_be-li
Hi Segher,
on 2019/6/24 下午4:02, Segher Boessenkool wrote:
> Hi Kewen,
>
> On Mon, Jun 24, 2019 at 03:43:26PM +0800, Kewen.Lin wrote:
>> on 2019/6/24 下午3:19, Segher Boessenkool wrote:
>>> Newer ISAs require 64-bit to be implemented. There are no optional
>>> 64-bit categories anymore. Since this
On Mon, Jun 24, 2019 at 03:49:35PM +0800, Kewen.Lin wrote:
> > It sounds like we can have a clean up for some others like
> > TARGET_EXTSWSLI. :)
>
> Sorry, maybe not, it's not similar to maddld for 32bit operations.
Hey, it currently is
(define_insn_and_split "ashdi3_extswsli"
[(set (match_o
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl wrote:
> On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
> > Currently variables with the AUTOMATIC attribute can not appear in an
> > EQUIVALENCE statement. However its counterpart, STATIC, can be used in
> > an EQUIVALENCE stateme
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have to handle functions found by a using declara
On 2019/6/24 10:34, luoxhu wrote:
Hi Honza,
Thanks very much to get so many useful comments from you.
As a newbie to GCC, not sure whether my questions are described clearly
enough. Thanks for your patience in advance. :)
On 2019/6/20 21:47, Jan Hubicka wrote:
Hi,
some comments on the ipa
Prathamesh Kulkarni writes:
> diff --git a/gcc/fwprop.c b/gcc/fwprop.c
> index 45703fe5f01..93a1a10c9a6 100644
> --- a/gcc/fwprop.c
> +++ b/gcc/fwprop.c
> @@ -547,6 +547,54 @@ propagate_rtx_1 (rtx *px, rtx old_rtx, rtx new_rtx, int
> flags)
> tem = simplify_gen_subreg (mode, op0, GET_MODE
The MSP430 target in the large memory model uses the (non-ISO) __int20 type for
SIZE_TYPE and PTRDIFF_TYPE.
The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
"__int20 unsigned" in user code.
When compiling with the "-pedantic-errors" flag, the use of any of these
builtin macros
> Hi,
> here is patch that adds TYPE_ODR_P to determine type that comply C++
> ODR rules (i.e. ODR types themselves or structures/unions derived
> from them).
> I have decided to use STRING_FLAG which have meaning only for integers
> and arrays which forced me to add type checks on places where
> w
> > This simple (untested) patch doesn't avoid creating the unnecessary
> > as-base types, but it should avoid using them in a way that causes
> > them to be streamed, and should let them be discarded by GC.
> > Thoughts?
>
> Looks better than Honzas patch fixing a single place.
I wonder if we ca
On Mon, 24 Jun 2019, Jan Hubicka wrote:
> > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > as-base types, but it should avoid using them in a way that causes
> > > them to be streamed, and should let them be discarded by GC.
> > > Thoughts?
> >
> > Looks better than H
On Mon, 24 Jun 2019 at 14:59, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/fwprop.c b/gcc/fwprop.c
> > index 45703fe5f01..93a1a10c9a6 100644
> > --- a/gcc/fwprop.c
> > +++ b/gcc/fwprop.c
> > @@ -547,6 +547,54 @@ propagate_rtx_1 (rtx *px, rtx old_rtx, rtx new_rtx,
> On Mon, 24 Jun 2019, Jan Hubicka wrote:
>
> > > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > > as-base types, but it should avoid using them in a way that causes
> > > > them to be streamed, and should let them be discarded by GC.
> > > > Thoughts?
> > >
> > > Loo
On Fri, 21 Jun 2019 at 08:57, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch adds exclusive scan support for simd, it is similar to
> the inclusive scan, just we need to swap the input and scan phases and
> use slightly different pattern at the start of the scan phase, so that it
> computes
On Sun, Jun 23, 2019 at 12:22 AM Marc Glisse wrote:
>
> On Sat, 22 Jun 2019, Richard Biener wrote:
>
> > On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse
> > wrote:
> >> Hello,
> >>
> >> as discussed in the PR, this seems like a simple enough approach to
> >> handle
> >> FENV functionality saf
On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
>
> On 6/21/19 2:57 PM, Jan Hubicka wrote:
> > This looks like good step (and please stream it in host independent
> > way). I suppose all these issues can be done one-by-one.
>
> So there's a working patch for that. However one will see followin
On 12/03/19 23:04 +, Jonathan Wakely wrote:
On 12/03/19 22:49 +, Joseph Myers wrote:
On Tue, 5 Mar 2019, Jonathan Wakely wrote:
The midpoint and lerp functions for floating point types come straight
from the P0811R3 proposal, with no attempt at optimization.
I don't know whether P081
On 6/24/19 2:02 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
>>
>> On 6/21/19 2:57 PM, Jan Hubicka wrote:
>>> This looks like good step (and please stream it in host independent
>>> way). I suppose all these issues can be done one-by-one.
>>
>> So there's a worki
On Sun, Jun 23, 2019 at 3:51 PM Richard Sandiford
wrote:
>
> -Og is documented as:
>
> @option{-Og} should be the optimization
> level of choice for the standard edit-compile-debug cycle, offering
> a reasonable level of optimization while maintaining fast compilation
> and a good debuggin
On Mon, Jun 24, 2019 at 1:08 AM Ian Lance Taylor wrote:
>
> On Fri, Jun 7, 2019 at 5:04 AM Martin Liška wrote:
> >
> > On 6/7/19 10:57 AM, Richard Biener wrote:
> > > On Mon, Jun 3, 2019 at 3:35 PM Martin Liška wrote:
> > >>
> > >> On 6/1/19 12:06 AM, Jeff Law wrote:
> > >>> On 5/22/19 3:13 AM,
On Mon, Jun 24, 2019 at 2:12 PM Martin Liška wrote:
>
> On 6/24/19 2:02 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
> >>
> >> On 6/21/19 2:57 PM, Jan Hubicka wrote:
> >>> This looks like good step (and please stream it in host independent
> >>> way). I suppos
Richard Biener writes:
> On Sun, Jun 23, 2019 at 3:51 PM Richard Sandiford
> wrote:
>> To get an idea of the runtime cost, I tried compiling tree-into-ssa.ii
>> at -O2 -g with various --enable-checking=yes builds of cc1plus:
>>
>> time taken
>> cc1plus compiled with -O
The following fixes the vectorizer to properly deal with STRING_CSTs
now appearing more often.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-06-24 Richard Biener
PR tree-optimization/90972
* tree-vect-stmts.c (vect_init_vector): Handle CONSTANT_CLAS
Hi.
The patch is fixing an issue reported with clang-static-analyzer.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch tomorrow if there are no objections.
Thanks,
Martin
libgcc/ChangeLog:
2019-06-24 Martin Liska
* libgcov-driver
Hi.
The patch is fixing following clang-static-analyzer error:
/home/marxin/Programming/gcc/gcc/bb-reorder.c:1031:2: warning: Value stored to
'is_better_edge' is never read
is_better_edge = true;
^
/home/marxin/Programming/gcc/gcc/bb-reorder.c:1034:2: warning:
On Fri, Jun 21, 2019 at 1:41 PM Aldy Hernandez wrote:
>
> Hi Richard. Hi folks.
>
> In order to unify the APIs for value_range and irange, we'd like to make
> some minor changes to value_range. We believe most of these changes
> could go in now, and would prefer so, to get broader testing and
>
On 6/24/19 2:44 PM, Richard Biener wrote:
> On Mon, Jun 24, 2019 at 2:12 PM Martin Liška wrote:
>>
>> On 6/24/19 2:02 PM, Richard Biener wrote:
>>> On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
On 6/21/19 2:57 PM, Jan Hubicka wrote:
> This looks like good step (and please stre
On Thu, 20 Jun 2019, Jan Hubicka wrote:
> > > Currently, costs of moves are also used for costs of RTL expressions.
> > > This
> > > patch:
> > >
> > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00405.html
> > >
> > > includes:
> > >
> > > diff --git a/gcc/config/i386/x86-tune-costs.h
> > >
On Mon, 24 Jun 2019, Jan Hubicka wrote:
> > Hi,
> > here is patch that adds TYPE_ODR_P to determine type that comply C++
> > ODR rules (i.e. ODR types themselves or structures/unions derived
> > from them).
> > I have decided to use STRING_FLAG which have meaning only for integers
> > and arrays w
On 24/06/2019 09:19, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl wrote:
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
Currently variables with the AUTOMATIC attribute can not appear in an
EQUIVALENCE statement. However its counterpart, ST
On Mon, 24 Jun 2019, Richard Biener wrote:
On Sun, Jun 23, 2019 at 12:22 AM Marc Glisse wrote:
On Sat, 22 Jun 2019, Richard Biener wrote:
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
Hello,
as discussed in the PR, this seems like a simple enough approach to
handle
FENV funct
On 6/24/19 2:29 PM, Richard Biener wrote:
> On Mon, Jun 24, 2019 at 1:08 AM Ian Lance Taylor wrote:
>>
>> On Fri, Jun 7, 2019 at 5:04 AM Martin Liška wrote:
>>>
>>> On 6/7/19 10:57 AM, Richard Biener wrote:
On Mon, Jun 3, 2019 at 3:35 PM Martin Liška wrote:
>
> On 6/1/19 12:06 AM, J
On Mon, Jun 24, 2019 at 3:47 PM Marc Glisse wrote:
>
> On Mon, 24 Jun 2019, Richard Biener wrote:
>
> > On Sun, Jun 23, 2019 at 12:22 AM Marc Glisse wrote:
> >>
> >> On Sat, 22 Jun 2019, Richard Biener wrote:
> >>
> >>> On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse
> >>> wrote:
> Hell
On Mon, Jun 24, 2019 at 3:51 PM Martin Liška wrote:
>
> On 6/24/19 2:29 PM, Richard Biener wrote:
> > On Mon, Jun 24, 2019 at 1:08 AM Ian Lance Taylor wrote:
> >>
> >> On Fri, Jun 7, 2019 at 5:04 AM Martin Liška wrote:
> >>>
> >>> On 6/7/19 10:57 AM, Richard Biener wrote:
> On Mon, Jun 3, 2
On 20/06/2019 15:10, Nick Clifton wrote:
> Hi Richard,
>
> Please may I apply this patch to the gcc-9, gcc-8 and gcc-7 branches ?
>
> I have tested it on all three branches and found no problems.
>
> Cheers
> Nick
>
> 2019-06-07 Nick Clifton
>
> Import these changes from the bin
Hi!
What does -O1g do with OPT_LEVELS_1_PLUS_NOT_DEBUG, is it enabled or
not there? Maybe that name needs to change, with your patches? It is
currently documented as
/* -O1 (and not -Og) optimizations. */
Segher
Prathamesh Kulkarni writes:
> @@ -1415,6 +1460,19 @@ forward_propagate_into (df_ref use)
>if (!def_set)
> return false;
>
> + if (reg_prop_only
> + && !REG_P (SET_SRC (def_set))
> + && !REG_P (SET_DEST (def_set)))
> +return false;
This should be:
if (reg_prop_only
Segher Boessenkool writes:
> Hi!
>
> What does -O1g do with OPT_LEVELS_1_PLUS_NOT_DEBUG, is it enabled or
> not there? Maybe that name needs to change, with your patches? It is
> currently documented as
>
> /* -O1 (and not -Og) optimizations. */
Yeah, comment should change to be:
/* -
> On 24 Jun 2019, at 14:31, Martin Liška wrote:
>
> On 6/24/19 2:44 PM, Richard Biener wrote:
>> On Mon, Jun 24, 2019 at 2:12 PM Martin Liška wrote:
>>>
>>> On 6/24/19 2:02 PM, Richard Biener wrote:
On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
>
> On 6/21/19 2:57 PM, Jan
On Sun, Jun 23, 2019 at 02:51:06PM +0100, Richard Sandiford wrote:
> What do you think? Is it worth pursuing this further?
Wouldn't it be more useful to just force all automatic variables to be
used at the end of their corresponding scope? That is IMHO the main issue
with -Og debugging, VTA is a
On 2019-06-21 9:40 a.m., Richard Sandiford wrote:
ira_setup_alts has its own code to calculate the start of the
constraint string for each operand/alternative combination,
but preprocess_constraints now provides that information in (almost)
constant time for non-asm instructions. Using it here
On 2019-06-21 9:42 a.m., Richard Sandiford wrote:
SVE has a prefix instruction (MOVPRFX) that acts as a move but is
designed to be easily fusible with the following instruction. The SVE
port therefore has lots of patterns with constraints of the form:
A: operand 0: =w,?w
...
op
On 2019-06-21 9:42 a.m., Richard Sandiford wrote:
ira_get_dup_out_num punted on operands that are matched to
earlyclobber outputs:
/* It is better ignore an alternative with early clobber. */
else if (*str == '&')
goto fail;
But I'm not sure why this is
On 2019-06-21 9:43 a.m., Richard Sandiford wrote:
make_early_clobber_and_input_conflicts records allocno conflicts
between inputs and earlyclobber outputs. It (rightly) avoids
doing this for inputs that are explicitly allowed to match the
output due to matching constraints.
The problem is tha
On Mon, Jun 24, 2019 at 04:28:34PM +0200, Jakub Jelinek wrote:
> On Sun, Jun 23, 2019 at 02:51:06PM +0100, Richard Sandiford wrote:
> > What do you think? Is it worth pursuing this further?
>
> Wouldn't it be more useful to just force all automatic variables to be
> used at the end of their corre
On Mon, Jun 24, 2019 at 7:28 AM Richard Biener wrote:
> On Mon, 24 Jun 2019, Jan Hubicka wrote:
>
> > > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > > as-base types, but it should avoid using them in a way that causes
> > > > them to be streamed, and should let them
On Mon, 24 Jun 2019, Richard Biener wrote:
-frounding-math is supposed to be equivalent to "#pragma stdc fenv_access
on" covering the whole program.
For constant expressions, I see a difference between
constexpr double third = 1. / 3.;
which really needs to be done at compile time, and
const do
Hi,
A number of Arm define_expand patterns have specified constraints for
their operands. But the constraint strings are ignored at expand time
and are therefore redundant/useless. We now avoid specifying constraints
in new define_expands, but we should clean up the existing define_expand
defi
On 6/23/19 6:00 PM, Martin Sebor wrote:
> The attached patch cleans up a number of outstanding -Wformat-diag
> instances. I plan to commit it tomorrow.
>
> With it applied, an x86_64-linux bootstrap shows just 79 unique
> instances of the warning originating in 17 files. 49 of those are
> in the
Hi all,
second version here of the gcc_jit_context_new_bitfield patch addressing
review comments.
Checked with make check-jit runs clean.
Bests
Andrea
2019-06-20 Andrea Corallo andrea.cora...@arm.com
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_12): New ABI tag.
* docs/topics/types.rst: Add
Hi all,
second version for this patch.
Given the suggestion for the bit-field one I've tried to improve also
here the error message.
I've added a simple testcase as requested, here I'm trying to do
*void=int+int.
This without checking would normally crash verifying gimple.
More complex cases can be
Hi,
A number of AArch64 define_expand patterns have specified constraints
for their operands. But the constraint strings are ignored at expand
time and are therefore redundant/useless. We now avoid specifying
constraints in new define_expands, but we should clean up the existing
define_expand
On Mon, 2019-06-24 at 15:30 +, Andrea Corallo wrote:
> Hi all,
> second version for this patch.
> Given the suggestion for the bit-field one I've tried to improve also
> here the error message.
Thanks.
> I've added a simple testcase as requested, here I'm trying to do
> *void=int+int.
> This
On 22/06/2019 23:21, Marc Glisse wrote:
> We should care about the C standard, and do whatever makes sense for C++
> without expecting the C++ standard to tell us exactly what that is. We
> can check what visual studio and intel do, but we don't have to follow them.
>
> -frounding-math is suppose
Hi,
thanks for comitting the patch!
> > > As
> > >
> > > class a var;
> > > class b:a {} *bptr;
> > >
> > > var.foo;
> > >
> > > Expanding this as var.as_base_a.foo would make access path oracle to
> > > disambiguate it from bptr->as_base_b->as_base_a.foo which is wrong with
> > > gimple memo
Segher Boessenkool writes:
> On Mon, Jun 24, 2019 at 04:28:34PM +0200, Jakub Jelinek wrote:
>> On Sun, Jun 23, 2019 at 02:51:06PM +0100, Richard Sandiford wrote:
>> > What do you think? Is it worth pursuing this further?
>>
>> Wouldn't it be more useful to just force all automatic variables to b
On Mon, 24 Jun 2019 at 19:51, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > @@ -1415,6 +1460,19 @@ forward_propagate_into (df_ref use)
> >if (!def_set)
> > return false;
> >
> > + if (reg_prop_only
> > + && !REG_P (SET_SRC (def_set))
> > + && !REG_P (SET_DEST (d
On Mon, Jun 24, 2019 at 6:37 AM Richard Biener wrote:
>
> On Thu, 20 Jun 2019, Jan Hubicka wrote:
>
> > > > Currently, costs of moves are also used for costs of RTL expressions.
> > > > This
> > > > patch:
> > > >
> > > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00405.html
> > > >
> > > >
Hi Dennis,
On 6/24/19 4:13 PM, Dennis Zhang wrote:
Hi,
A number of Arm define_expand patterns have specified constraints for
their operands. But the constraint strings are ignored at expand time
and are therefore redundant/useless. We now avoid specifying constraints
in new define_expands, but
Hi,
in August 2016 Prathamesh implemented inter-procedural propagation of
known non-zero bits on integers. In August that same year he then also
added the ability to track it for pointer, replacing separate alignment
tracking.
However, we still have an assert in ipcp_bits_lattice::meet_with from
David Malcolm writes:
> On Mon, 2019-06-24 at 15:30 +, Andrea Corallo wrote:
>> Hi all,
>> second version for this patch.
>> Given the suggestion for the bit-field one I've tried to improve also
>> here the error message.
>
> Thanks.
>
>> I've added a simple testcase as requested, here I'm tr
On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
>
> Hi,
> thanks for comitting the patch!
> > > > As
> > > >
> > > > class a var;
> > > > class b:a {} *bptr;
> > > >
> > > > var.foo;
> > > >
> > > > Expanding this as var.as_base_a.foo would make access path oracle to
> > > > disambiguate
This Go patch by Cherry Zhang changes the Go frontend to call builtin
memcmp directly, instead of going through a C function __go_memcmp.
This allows more optimizations in the compiler backend. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gof
On Mon, Jun 24, 2019 at 12:40 PM Jason Merrill wrote:
> On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
> >
> > > > > As
> > > > >
> > > > > class a var;
> > > > > class b:a {} *bptr;
> > > > >
> > > > > var.foo;
> > > > >
> > > > > Expanding this as var.as_base_a.foo would make access
Hi,
as discussed on IRC today, after all this patch should be correct. I
have re-tested it with x86_64-linux in the following variant which also
moves load of ptrtype1 that is unnecesarily early.
Bootstrapped/regtested x86_64-linux, OK?
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p):
When improving oracle limits for PR90316 I missed one line when
cut&pasting from the adjustment in get_continuation_for_phi.
Bootstrapped and tested on x86_64-unknown-linux-gnu applied to
trunk and branch.
Richard.
2019-06-24 Richard Biener
PR tree-optimization/90930
PR tre
On Mon, 24 Jun 2019, Jason Merrill wrote:
> On Mon, Jun 24, 2019 at 12:40 PM Jason Merrill wrote:
> > On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
> > >
> > > > > > As
> > > > > >
> > > > > > class a var;
> > > > > > class b:a {} *bptr;
> > > > > >
> > > > > > var.foo;
> > > > > >
>
On Mon, 24 Jun 2019, Jan Hubicka wrote:
> Hi,
> as discussed on IRC today, after all this patch should be correct. I
> have re-tested it with x86_64-linux in the following variant which also
> moves load of ptrtype1 that is unnecesarily early.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK.
R
On Mon, Jun 24, 2019 at 1:23 PM Richard Biener wrote:
> On Mon, 24 Jun 2019, Jason Merrill wrote:
>
> > On Mon, Jun 24, 2019 at 12:40 PM Jason Merrill wrote:
> > > On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka wrote:
> > > >
> > > > > > > As
> > > > > > >
> > > > > > > class a var;
> > > > > >
Hi,
>
> I thought I remembered someone's recent-ish work to treat specially
> types containing a char array, but I'm not finding it now.
>
> > For dynamically allocated memory as well as for stack space after stack
> > slot sharing done in cfgexpand I see this is necessary since we do not
> > pre
On Mon, Jun 24, 2019 at 4:57 PM Marc Glisse wrote:
>
> On Mon, 24 Jun 2019, Richard Biener wrote:
>
> -frounding-math is supposed to be equivalent to "#pragma stdc fenv_access
> on" covering the whole program.
>
> For constant expressions, I see a difference between
> cons
This Go patch by Cherry Zhang open codes string equality with builtin
memcmp. This allows further optimizations in the backend.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
=
On Mon, Jun 24, 2019 at 3:31 PM Martin Liška wrote:
>
> On 6/24/19 2:44 PM, Richard Biener wrote:
> > On Mon, Jun 24, 2019 at 2:12 PM Martin Liška wrote:
> >>
> >> On 6/24/19 2:02 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:01 PM Martin Liška wrote:
>
> On 6/21/19 2:57 PM
For the test to succeed there needs to be some header that is to be found in
the 'expected' place i.e. /usr/include/. It's important that it is
not the
name of a header for which fixincludes have been applied, since such headers
will be found in the gcc include-fixed dir and, in general, referenc
We just needed to adjust the regex to accept Darwin's register names.
tested on powerpc-darwin9, powerpc-linux-gnu,
applied to mainline
thanks
Iain
2019-06-24 Iain Sandoe
* gcc.target/powerpc/spec-barr-1.c: Adjust scan assembler regex
to recognise Darwin's register names.
dif
Hi
Any feedback regarding this patch ?
Thanks
On 5/14/19 7:46 AM, François Dumont wrote:
Hi
This is the patch on vector to:
- Optimize sizeof in Versioned namespace mode. We could go one step
further by removing _M_p from _M_finish and just transform it into an
offset but it is a l
The -mno-speculate-indirect-jumps functionality is not implemented for
Darwin and, given that it's deprecated, is unlikely to be. So skip the tests
for it that fail on Darwin.
tested on powerpc-darwin9,
applied to mainline
thanks
Iain.
2019-06-24 Iain Sandoe
* gcc.target/powerpc/safe-
On Mon, 24 Jun 2019, Szabolcs Nagy wrote:
On 22/06/2019 23:21, Marc Glisse wrote:
We should care about the C standard, and do whatever makes sense for C++
without expecting the C++ standard to tell us exactly what that is. We
can check what visual studio and intel do, but we don't have to foll
On Mon, 2019-06-24 at 16:37 +, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Mon, 2019-06-24 at 15:30 +, Andrea Corallo wrote:
> > > Hi all,
> > > second version for this patch.
> > > Given the suggestion for the bit-field one I've tried to improve
> > > also
> > > here the error
On Mon, 2019-06-24 at 15:26 +, Andrea Corallo wrote:
> Hi all,
> second version here of the gcc_jit_context_new_bitfield patch
> addressing
> review comments.
>
> Checked with make check-jit runs clean.
>
> Bests
>
> Andrea
>
> 2019-06-20 Andrea Corallo andrea.cora...@arm.com
>
> * docs/t
Hi,
here is a new version of this patch. It makes "-fno-trampolines"
work for C which then makes it possible to use nested functions
without executable stack. The only change in this version is in
the documentation.
Maybe it could be reconsidered at this stage?
Bootstrapped and regression tes
David Malcolm writes:
> On Mon, 2019-06-24 at 16:37 +, Andrea Corallo wrote:
>> David Malcolm writes:
>>
>> > On Mon, 2019-06-24 at 15:30 +, Andrea Corallo wrote:
>> > > Hi all,
>> > > second version for this patch.
>> > > Given the suggestion for the bit-field one I've tried to improve
>
Ok for trunk.
> Can you push it into upstream PSTL?
Yes.
Thanks,
Tom.
Jakub Jelinek writes:
> Hi!
>
> Now that GCC supports inclusive/exclusive scans (like ICC 19.0 so far in
> simd constructs only), we can enable it in PSTL as well.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux,
On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote:
> On Fri, 21 Jun 2019 07:10:11 -0700
> Steve Kargl wrote:
>
>> On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
>>> Currently variables with the AUTOMATIC attribute can not appear in an
>>> EQUIVALENCE statement. However its coun
The strlen enhancement committed in r263018 to handle multi-character
assignments extended the handle_char_store() function to handle such
stores via MEM_REFs. Prior to that the function only dealt with
single-char stores. The enhancement neglected to constrain a case
in the function that assume
On 6/24/19 4:25 AM, Jozef Lawrynowicz wrote:
> The MSP430 target in the large memory model uses the (non-ISO) __int20 type
> for
> SIZE_TYPE and PTRDIFF_TYPE.
> The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
> "__int20 unsigned" in user code.
> When compiling with the "-peda
On 6/24/19 5:50 PM, Martin Sebor wrote:
> The strlen enhancement committed in r263018 to handle multi-character
> assignments extended the handle_char_store() function to handle such
> stores via MEM_REFs. Prior to that the function only dealt with
> single-char stores. The enhancement neglected
These are some minor improvements to tree-ssa-dse, in particular it adds
handling of the _CHK variants of the supported functions (memcpy,
memmove, memset). It's just something I noticed while poking at 90883.
These don't trigger during bootstraps, but do in the testsuite. The
tests that were c
On 6/24/19 5:59 PM, Jeff Law wrote:
On 6/24/19 5:50 PM, Martin Sebor wrote:
The strlen enhancement committed in r263018 to handle multi-character
assignments extended the handle_char_store() function to handle such
stores via MEM_REFs. Prior to that the function only dealt with
single-char stor
On Sat, Jun 22, 2019 at 3:38 PM Uros Bizjak wrote:
>
> On Fri, Jun 21, 2019 at 8:38 PM H.J. Lu wrote:
>
> > > > > > > > > > >> > > +/* Register pair. */
> > > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI */
> > > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4);
This patch by Cherry Zhang changes libgo to mark the memequal and
memclrNoHeapPointers functions as nosplit. They are wrappers of libc
functions that use no stack. Mark them nosplit so the linker won't
patch it to call __morestack_non_split. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-g
Hi all,
As PR62147, for some cases loop iv analysis is unable to identify one loop is
finite even if the loop is actually finite and we have known it in middle-end.
It will prevent doloop_optimize and end up with worse codes.
This patch is going to leverage existing middle-end function finite_lo
98 matches
Mail list logo
