On Thu, Jan 4, 2018 at 4:21 AM, Jerry DeLisle wrote:
> On 01/03/2018 03:37 AM, Janne Blomqvist wrote:
>> On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle
>> wrote:
>>> On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig
wrote:
>>> ---snip---
>
On 01/03/2018 03:37 AM, Janne Blomqvist wrote:
> On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle wrote:
>> On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
>>> On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig
>>> wrote:
>> ---snip---
>>>
>>> I can provide that stuff as a separate patch, or merge it
On 01/03/2018 04:47 PM, Jakub Jelinek wrote:
On Tue, Jan 02, 2018 at 04:40:50PM -0700, Jeff Law wrote:
Attached is the patch with the casts removed (still bootstrapping).
Martin
gcc-printf-lli.diff
gcc/ChangeLog:
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Use
On 01/02/2018 04:29 PM, Jeff Law wrote:
On 01/01/2018 05:58 PM, Martin Sebor wrote:
The -Wrestrict code assumes that built-ins are called with
the correct number of arguments. When this isn't so it
crashes. The attached patch avoids the ICE due to this
error.
There are outstanding assumptions
On Tue, Jan 02, 2018 at 04:40:50PM -0700, Jeff Law wrote:
> > Attached is the patch with the casts removed (still bootstrapping).
> >
> > Martin
> >
> > gcc-printf-lli.diff
> >
> >
> > gcc/ChangeLog:
> >
> > * gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Use
> > offset_
The default value of MAX_BITSIZE_MODE_ANY_MODE is calculated
from the initial mode sizes specified in the modes.def file.
The target needs to be able to override it if ADJUST_BYTESIZE
& co. can choose a bigger size.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also test
Use partial_subreg_p in code that was added since the initial patch
that introduced this function.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the before and after assembly output for at
least one target per CPU directory. Committed as obvious
Jakub Jelinek writes:
> On Mon, Oct 23, 2017 at 06:26:12PM +0100, Richard Sandiford wrote:
>> 2017-10-23 Richard Sandiford
>> Alan Hayward
>> David Sherwood
> ...
>
>> --- /dev/null2017-10-21 08:51:42.385141415 +0100
>> +++ gcc/testsuite/gcc.dg/vect-opt-info-1.c 20
Prathamesh's fix restores the optimization for the test case
reported in the bug (thanks!) but it isn't sufficient to bring
GCC 8 completely up to par with 7. Prior GCC versions are able
to compute the string length in the test case below but GCC 8
cannot.
char d[8];
const char s[] = "123456
On 01/03/2018 01:49 PM, Jeff Law wrote:
> On 01/03/2018 01:36 PM, Jakub Jelinek wrote:
>> On Wed, Jan 03, 2018 at 12:57:10PM -0700, Jeff Law wrote:
Ok for trunk if it passes bootstrap/regtest on x86_64 and i686-linux?
2018-01-03 Jakub Jelinek
PR target/83641
*
On Mon, Oct 23, 2017 at 06:26:12PM +0100, Richard Sandiford wrote:
> 2017-10-23 Richard Sandiford
> Alan Hayward
> David Sherwood
...
> --- /dev/null 2017-10-21 08:51:42.385141415 +0100
> +++ gcc/testsuite/gcc.dg/vect-opt-info-1.c2017-10-23 17:22:26.571498977
> +010
Hi!
My recent dwarf2out.c, dbxout.c and rs6000.c uses of crtl->has_bb_partition
all assume that if it is true then the function actually has 2 partitions
and NOTE_INSN_SWITCH_SECTIONS is present, but as the following testcase
shows, that isn't always the case, crtl->has_bb_partition is set during
On January 3, 2018 9:42:01 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>When var-tracking pass isn't done (e.g. with -O2 -g -fno-var-tracking
>or -O2 -gstatement-frontiers), rest_of_handle_final calls
>variable_tracking_main in order to perform delete_vta_debug_insns
>- replace the debug marker insn
On January 3, 2018 9:46:14 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>The ICE here is when calling multiple_p with GET_MODE_BITSIZE
>(BLKmode),
>so SIGFPE because it is 0. BLKmode can leak into the debug stmts
>through
>generic vectors without HW support, but doing say (plus:BLK ...) etc.
>just d
On 01/03/2018 01:36 PM, Jakub Jelinek wrote:
> On Wed, Jan 03, 2018 at 12:57:10PM -0700, Jeff Law wrote:
>>> Ok for trunk if it passes bootstrap/regtest on x86_64 and i686-linux?
>>>
>>> 2018-01-03 Jakub Jelinek
>>>
>>> PR target/83641
>>> * config/i386/i386.c (ix86_adjust_stack_and_prob
Hi!
The ICE here is when calling multiple_p with GET_MODE_BITSIZE (BLKmode),
so SIGFPE because it is 0. BLKmode can leak into the debug stmts through
generic vectors without HW support, but doing say (plus:BLK ...) etc.
just doesn't look like a valid RTL, so instead of just not trying to subreg
i
Hi!
When var-tracking pass isn't done (e.g. with -O2 -g -fno-var-tracking
or -O2 -gstatement-frontiers), rest_of_handle_final calls
variable_tracking_main in order to perform delete_vta_debug_insns
- replace the debug marker insns with notes. The problem with that is
that final pass is after free
On Wed, Jan 03, 2018 at 12:57:10PM -0700, Jeff Law wrote:
> > Ok for trunk if it passes bootstrap/regtest on x86_64 and i686-linux?
> >
> > 2018-01-03 Jakub Jelinek
> >
> > PR target/83641
> > * config/i386/i386.c (ix86_adjust_stack_and_probe_stack_clash): For
> > noreturn probe, u
On 01/03/2018 04:57 AM, Jakub Jelinek wrote:
> On Tue, Jan 02, 2018 at 01:02:26PM -0700, Jeff Law wrote:
>> It's fairly obvious that the probe of *sp isn't actually necessary here
>> because the register saves in the prologue act as probe points for *sp.
>>
>> In fact, the only way this can ever ca
On 03/01/18 16:34 +0200, Ville Voutilainen wrote:
Tested partially on Linux-x64, finishing testing the full suite on
Linux-PPC64. Ok for trunk?
Yes, and gcc-7-branch please. Thanks.
Hi.
On 01/02/2018 05:43 PM, Michele Pezzutti wrote:
On 01/02/2018 02:28 AM, Ed Smith-Rowland wrote:
I like the patch.
I have a similar one in the tr29124 branch.
Anyway, I got held up and I think it's good to have new folks looking
into this.
It looks good except that you need to uglify
On Wed, Jan 3, 2018 at 8:34 PM, Bob Deen wrote:
> On 12/29/17 5:31 AM, Janne Blomqvist wrote:
>>
>> In order to handle large character lengths on (L)LP64 targets, switch
>> the GFortran character length from an int to a size_t.
>>
>> This is an ABI change, as procedures with character arguments ta
On Tue, 2018-01-02 at 21:25 +0100, Andreas Schwab wrote:
> /daten/gcc/gcc-
> 20180101/gcc/testsuite/gcc.dg/plugin/expensive_selftests_plugin.c:175
> :1: warning: no return statement in function returning non-void [-
> Wreturn-type]
>
> Andreas.
Thanks.
I forgot to handle the --enable-checking=
On 01/02/2018 11:03 PM, Prathamesh Kulkarni wrote:
> Hi,
> malloc_candidate_p() in ipa-pure-const misses detecting that a
> function is malloc-like if the return value is result of PHI and one
> of the arguments of PHI is 0.
> For example:
>
> void g(unsigned n)
> {
> return (n) ? __builtin_mal
On 12/29/17 5:31 AM, Janne Blomqvist wrote:
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
This is an ABI change, as procedures with character arguments take
hidden arguments with the character length.
Did this chang
There's a of sense of deja-vu on this BZ. There's a lot of similarities
with an issue that came up earlier on aarch64 and its special handling
of the outgoing argument area.
Basically the residual of dynamic allocation may be a compile time
constant or a runtime variant and anything in between.
On Wed, Jan 03, 2018 at 11:45:55AM -0500, Nathan Sidwell wrote:
> On 01/03/2018 11:31 AM, Marek Polacek wrote:
> > Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
> > with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
> >
> > The matching code in fold
On Wed, Jan 03, 2018 at 05:40:32PM +, Richard Sandiford wrote:
> Marek Polacek writes:
> > Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
> > with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
> >
> > The matching code in fold_indirect_ref_1 uses
Marek Polacek writes:
> Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
> with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
>
> The matching code in fold_indirect_ref_1 uses uHWIs so I've followed suit.
> But that code now also uses poly_uint64 and I
Hi All,
This patch adds support for the FP16 multiply add/subtract instructions in
Armv8.4-a. Support for the new instructions is in the form of new ACLE
intrinsics. A new command line feature modifier, +fp16fml, is added to enable
the support. Enabling +fp16fml automatically enables +fp16.
T
Hi All,
This patch adds support for the SHA-512 and SHA-3 instructions added in
Armv8.4-a. Support for the new instructions is in the form of new ACLE
intrinsics. A new command line feature modifier, +sha3, is added to enable the
support.
Test cases were added to verify that the ACLE Intrinsic
Hi All,
This patch adds support for the SM3/SM4 cryptographic instructions added in
Armv8.4-a. Support for the new instructions is in the form of new ACLE
intrinsics. A new command line feature modifier, +sm4, is added to enable the
support.
Test cases were added to verify that the ACLE Intrin
Hi all,
This patch adds support for the Arm architecture v8.4. A new command line
option, -march=armv8.4-a, is added as well as documentation.
Bootstrapped on aarch64-none-elf. Tested with new binutils and verified all
instructions assembly correctly.
2017-11-10 Michael Collison
*
Hi all,
This patch adds two new command line options for the legacy cryptographic
extensions AES (+aes) and SHA-1/SHA-2 (+sha2). Backward compatibility is
retained by modifying the +crypto feature modifier to enable +aes and +sha2.
Bootstrapped on aarch64-none-elf. Tested with new binutils and
Hello,
The ARMv8.4-A architecture builds on ARMv8.3-A and includes optional
cryptographic extensions supporting SHA512, SHA3, SM3 and SM4. New FP16
multiply add/subtract instructions have been added that are mandatory in
ARMv8.4-A and optional from ARMv8.2-A onward.
Although the new cryptogr
On 01/03/2018 11:31 AM, Marek Polacek wrote:
Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
The matching code in fold_indirect_ref_1 uses uHWIs so I've followed suit.
But that code now also uses po
Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
The matching code in fold_indirect_ref_1 uses uHWIs so I've followed suit.
But that code now also uses poly_uint64 and I'm not sure if any of the
conste
On 01/02/2018 09:24 PM, Ben Elliston wrote:
> It's a new year, time to update these scripts.
>
> Ben
>
>
> 2018-01-03 Ben Elliston
>
> * config.guess: Import latest version.
> * config.sub: Likewise.
Seems reasonable. I did a quick looksie and nothing looked unreasonable.
jeff
On 2 January 2018 at 19:29, Richard Biener wrote:
> On Thu, Dec 28, 2017 at 8:42 AM, Prathamesh Kulkarni
> wrote:
>> On 21 December 2017 at 12:53, Prathamesh Kulkarni
>> wrote:
>>> Hi Jakub,
>>> Based on your suggestions in PR83501, I have updated the patch to
>>> check for integer_zerop for 2nd
Hi all,
The only allowed addressing mode for aarch64 is DImode, AKA Pmode.
ptr_mode could be SImode or DImode depending on the ABI used.
This patch here fixes the addressing mode of two patterns as DImode.
If any other mode is ever used, somewhere in the compiler might go wrong.
aarch64-none-e
This fixes a tree dumping ICE involving static thunk fns. Copying the
thunked-to fn's context suffices.
nathan
--
Nathan Sidwell
2018-01-03 Nathan Sidwell
PR c++/83667
* method.c (make_alias_for): Copy DECL_CONTEXT.
PR c++/83667
* g++.dg/ipa/pr83667.C: New.
Index: cp/method.c
On 01/03/2018 08:25 AM, Martin Liška wrote:
This is small enhancement reported by users of gcov tool. I'm aware of current
stage of GCC,
but it's really small change in code. Apart from that, a small fix to
documentation is included.
yeah, this is useful, thanks.
nathan
--
Nathan Sidwell
r241959 included code to stop us increasing the alignment of a
"user-aligned" variable. This wasn't the main purpose of the patch,
and I think it was just there to make the testcase work.
The documentation for the aligned attribute says:
This attribute specifies a minimum alignment for the var
Hi
On 03/01/18 14:38, Segher Boessenkool wrote:
Hi!
On Wed, Jan 03, 2018 at 01:57:38PM +, Sudakshina Das wrote:
This patch add support for the missing transformation of (x | y) == x ->
(y & ~x) == 0.
Testing done: Checked for regressions on bootstrapped
aarch64-none-linux-gnu and arm-no
Hi!
On Wed, Jan 03, 2018 at 01:57:38PM +, Sudakshina Das wrote:
> This patch add support for the missing transformation of (x | y) == x ->
> (y & ~x) == 0.
> Testing done: Checked for regressions on bootstrapped
> aarch64-none-linux-gnu and arm-none-linux-gnueabihf and added new test
> cas
Tested partially on Linux-x64, finishing testing the full suite on
Linux-PPC64. Ok for trunk?
2018-01-03 Ville Voutilainen
Protect optional's deduction guide with the feature macro
* include/std/optional: Use the feature macro.
diff --git a/libstdc++-v3/include/std/optional
b/libstdc+
On Wed, Jan 03, 2018 at 02:02:16PM +0100, Jakub Jelinek wrote:
> Though, the above snippet reminds me I should probably also replace:
> + expr = build_base_path (MINUS_EXPR, expr, base,
> + /*nonnull=*/!sanitize_null_p, complain);
> with:
> + expr = build_base_
On 01/03/2018 02:40 PM, Jan Hubicka wrote:
+ if (!original->in_same_comdat_group_p (alias))
+{
+ if (dump_file)
+ fprintf (dump_file, "Not unifying; alias cannot be created; "
+ "across comdat group boundary\n\n");
+
+ return false;
On 01/03/2018 02:41 PM, Jan Hubicka wrote:
>> Hi.
>>
>> As mentioned in the PR, we should bail out inlining of thunks with variadic
>> arguments. It's problematic for cgraph_node::expand_thunk function that
>> does not support variadic functions.
>>
>> Patch can bootstrap on ppc64le-redhat-linux an
Hi
This patch add support for the missing transformation of (x | y) == x ->
(y & ~x) == 0.
The transformation for (x & y) == x case already exists in
simplify-rtx.c since 2014 as of r218503 and this patch only adds a
couple of extra patterns for the IOR case.
Citing the example given in PR82
> Hi.
>
> As mentioned in the PR, we should bail out inlining of thunks with variadic
> arguments. It's problematic for cgraph_node::expand_thunk function that
> does not support variadic functions.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be in
> >> + if (!original->in_same_comdat_group_p (alias))
> >> +{
> >> + if (dump_file)
> >> + fprintf (dump_file, "Not unifying; alias cannot be created; "
> >> + "across comdat group boundary\n\n");
> >> +
> >> + return false;
> >> +}
> >
> > Wasn't we supposed to do th
Hi.
As mentioned in the PR, we should bail out inlining of thunks with variadic
arguments. It's problematic for cgraph_node::expand_thunk function that
does not support variadic functions.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
g
On 01/03/2018 02:24 PM, Jan Hubicka wrote:
>> Hi.
>>
>> This patch is follow-up of r246848. This time ICF creates an edge between 2
>> functions,
>> where one is inside a comdat group and second is not. I've got patch that is
>> conservative
>> about the comdat groups (in_same_comdat_group_p).
>>
> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
> index 09ca3590039..0406d5588d2 100644
> --- a/gcc/ipa-pure-const.c
> +++ b/gcc/ipa-pure-const.c
> @@ -910,7 +910,8 @@ malloc_candidate_p (function *fun, bool ipa)
> #define DUMP_AND_RETURN(reason) \
> { \
>if (dump_file && (dump_
e_number},@var{end_line_number},@var{execution_count},@var{function_name}
lcount:@var{line number},@var{execution_count},@var{has_unexecuted_block}
@@ -212,6 +209,7 @@ times.
Here is a sample when @option{-i} is used in conjunction with @option{-b} option:
@smallexample
+version: 8.1.0 20180103
> Hi.
>
> This patch is follow-up of r246848. This time ICF creates an edge between 2
> functions,
> where one is inside a comdat group and second is not. I've got patch that is
> conservative
> about the comdat groups (in_same_comdat_group_p).
>
> Patch can bootstrap on ppc64le-redhat-linux an
On Wed, Jan 03, 2018 at 02:07:36PM +0100, Martin Liška wrote:
> 2018-01-03 Martin Liska
>
> PR tree-optimization/83593
> * tree-ssa-strlen.c (strlen_check_and_optimize_stmt): Clean-up
> EH gimple statements.
> (strlen_dom_walker::before_dom_children): Call
> gimple
On 01/03/2018 01:50 PM, Jakub Jelinek wrote:
> If gimple_purge_dead_eh_edges returns true, you want to arrange for the
> pass to return TODO_cleanup_cfg (probably needs to use some global static
> variable to propagate that).
>
> Jakub
Hi.
Sending v2. I'm suggesting to propagate that in
s
On Wed, Jan 03, 2018 at 01:49:11PM +0100, Richard Biener wrote:
> On January 3, 2018 1:21:40 PM GMT+01:00, Nathan Sidwell
> wrote:
> >On 01/02/2018 04:12 PM, Jakub Jelinek wrote:
> >> Hi!
> >>
> >> This patch improves code generated for:
> >> struct A { int a; };
> >> struct B { int b; };
> >> s
On 01/03/2018 01:49 PM, Marc Glisse wrote:
> On Wed, 3 Jan 2018, Martin Liška wrote:
>
> + *cleanup_eh = maybe_clean_or_replace_eh_stmt (stmt,
> + stmt);
>
> Do you mean *cleanup_eh |= ... ?
>
Yes. Thanks!
On Wed, Jan 03, 2018 at 01:27:01PM +0100, Martin Liška wrote:
> /* Reading the final '\0' character. */
> tree zero = build_int_cst (TREE_TYPE (lhs), 0);
> gimple_set_vuse (stmt, NULL_TREE);
> gimple_assign_set
On Wed, 3 Jan 2018, Martin Liška wrote:
+ *cleanup_eh = maybe_clean_or_replace_eh_stmt (stmt,
+ stmt);
Do you mean *cleanup_eh |= ... ?
--
Marc Glisse
On January 3, 2018 1:21:40 PM GMT+01:00, Nathan Sidwell wrote:
>On 01/02/2018 04:12 PM, Jakub Jelinek wrote:
>> Hi!
>>
>> This patch improves code generated for:
>> struct A { int a; };
>> struct B { int b; };
>> struct C : A, B { int c; };
>> C *bar (B *b) { return &static_cast(*b); }
>> Unlike
Hi.
Strlen pass does following transformation:
Optimizing: _7 = *ju_5(D);
into: _7 = 0;
which leads to need of removal of EH for the gimple statement. That's done via
maybe_clean_or_replace_eh_stmt
and then we need to call gimple_purge_dead_eh_edges. Last question I have is
whether it's also n
On 01/03/2018 06:59 AM, Marek Polacek wrote:
Since the -Wparentheses extension regarding Most Vexing Parse we started
warning on e.g. "reinterpret_cast(&a)". I don't think the warning was
meant to warn in this situation, since in reinterpret_cast there's no decl/expr
disambiguation, is it?
It s
On Wed, Jan 3, 2018 at 2:10 PM, Thomas Koenig wrote:
> Hi Janne,
>
>> attached is a patch that makes the two attached testcases work. It
>> applies on top of the charlen->size_t patch. In the formatted I/O
>> stuff, I have mostly used ptrdiff_t to avoid having to deal with
>> signed/unsigned issue
On 01/02/2018 04:12 PM, Jakub Jelinek wrote:
Hi!
This patch improves code generated for:
struct A { int a; };
struct B { int b; };
struct C : A, B { int c; };
C *bar (B *b) { return &static_cast(*b); }
Unlike return static_cast(b); where b can be validly NULL, the
reference shouldn't bind to NUL
On 01/02/2018 04:07 PM, Jakub Jelinek wrote:
Hi!
If lookup_name_fuzzy finds an exact match with a macro, it later in the dtor
uses node->value.macro->line in libcpp. The problem is that for builtin
macros node->value.macro contains garbage, we use node->value.builtin union
member in those cases
On 01/02/2018 04:03 PM, Jakub Jelinek wrote:
Hi!
The gimplifier uses in several places STRIP_USELESS_TYPE_CONVERSION and
that, being primarily a middle-end predicate, doesn't like error_mark_nodes
appearing in conversion operands. I've talked about it with Richi on IRC
and he'd prefer not to ch
Hi Janne,
attached is a patch that makes the two attached testcases work. It
applies on top of the charlen->size_t patch. In the formatted I/O
stuff, I have mostly used ptrdiff_t to avoid having to deal with
signed/unsigned issues, as the previous code was using int.
Did you regression-test?
Since the -Wparentheses extension regarding Most Vexing Parse we started
warning on e.g. "reinterpret_cast(&a)". I don't think the warning was
meant to warn in this situation, since in reinterpret_cast there's no decl/expr
disambiguation, is it?
It seems we should simply disable the warning in TY
On Tue, Jan 02, 2018 at 01:02:26PM -0700, Jeff Law wrote:
> It's fairly obvious that the probe of *sp isn't actually necessary here
> because the register saves in the prologue act as probe points for *sp.
>
> In fact, the only way this can ever cause problems is if %esi is used in
> the body in w
On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle wrote:
> On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
>> On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote:
> ---snip---
>>
>> I can provide that stuff as a separate patch, or merge it into the
>> original megapatch and resubmit that, whichever
> On Wed, Jan 03, 2018 at 10:05:30AM +0100, Richard Biener wrote:
> > >One concern I have is that with the patch, malloc_candidate_p will
> > >return true if all the args to PHI are NULL:
> > >retval = PHI<0, 0>
> > >return retval
> > >
> > >However I expect that PHI with all 0 args would be consta
Hi.
This patch is follow-up of r246848. This time ICF creates an edge between 2
functions,
where one is inside a comdat group and second is not. I've got patch that is
conservative
about the comdat groups (in_same_comdat_group_p).
Patch can bootstrap on ppc64le-redhat-linux and survives regress
On Wed, Jan 3, 2018 at 1:13 PM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes a missing check for eoshift.
>
> If you're wondering what the "else" belongs to - it is
>
> if (boundary != NULL)
>
> Regression-tested. OK for trunk?
>
> Regards
>
> Thomas
>
> 2018-01-03 T
Hello world,
the attached patch fixes a missing check for eoshift.
If you're wondering what the "else" belongs to - it is
if (boundary != NULL)
Regression-tested. OK for trunk?
Regards
Thomas
2018-01-03 Thomas Koenig
PR fortran/83664
* check.c (gfc_check_eoshif
Hi Kugan,
On 15 November 2017 at 12:23, James Greenhalgh wrote:
> On Wed, Nov 15, 2017 at 09:58:28AM +, Kyrill Tkachov wrote:
>> Hi Kugan,
>>
>> On 07/11/17 04:10, Kugan Vivekanandarajah wrote:
>> > Hi,
>> >
>> > Attached patch implements the vld1_*_x2 intrinsics as defined by the
>> > neon
Hi!
This testcase contains:
! Third, complete example from the PGInsider article:
! "Object-Oriented Programming in Fortran 2003 Part 3: Parameterized Derived
Types"
! by Mark Leair
!
! Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved.
!
! NVIDIA CORPORATION and its licensors ret
On 19 December 2017 at 00:36, Jeff Law wrote:
> On 12/11/2017 08:44 AM, James Greenhalgh wrote:
>> Hi,
>>
>> In the testcase in this patch we create an SLP vector with only two
>> elements. Our current vector initialisation code will first duplicate
>> the first element to both lanes, then overwri
Many thanks, Damian. I will commit soonish; probably tomorrow.
Paul
On 3 January 2018 at 00:22, Damian Rouson wrote:
> I have now confirmed that the patch works the same for the 7 branch: it
> doesn’t break any previously passing tests.
>
> Damian
>
> On January 1, 2018 at 9:44:59 AM, Paul Rich
Hi!
Happy New Year to everyone!
2018-01-03 Jakub Jelinek
gcc/
* gcc.c (process_command): Update copyright notice dates.
* gcov-dump.c (print_version): Ditto.
* gcov.c (print_version): Ditto.
* gcov-tool.c (print_version): Ditto.
* gengtype.c (create_fil
On Wed, Jan 03, 2018 at 10:05:30AM +0100, Richard Biener wrote:
> >One concern I have is that with the patch, malloc_candidate_p will
> >return true if all the args to PHI are NULL:
> >retval = PHI<0, 0>
> >return retval
> >
> >However I expect that PHI with all 0 args would be constant folded to
>
On January 3, 2018 7:03:26 AM GMT+01:00, Prathamesh Kulkarni
wrote:
>Hi,
>malloc_candidate_p() in ipa-pure-const misses detecting that a
>function is malloc-like if the return value is result of PHI and one
>of the arguments of PHI is 0.
>For example:
>
>void g(unsigned n)
>{
> return (n) ? __b
This patch changes the number of elements in a vector being built
by a vector_builder from unsigned int to poly_uint64. The case
in which it isn't a constant is the one that motivated adding
the vector encoding in the first place.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linu
This patch changes the vec_perm_indices element type from HOST_WIDE_INT
to poly_int64, so that it can represent indices into a variable-length
vector.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the before and after assembly output for at
least
On 01/02/2018 04:22 PM, Jeff Law wrote:
> On 01/02/2018 03:05 PM, Florian Weimer wrote:
>> On 01/02/2018 09:02 PM, Jeff Law wrote:
>>> * config/i386/i386.c (ix86_adjut_stack_and_probe_stack_clash): Do not
>>
>> Typo: “adjut”.
>>
>>> explicitly probe *sp in a noreturn function if there were
88 matches
Mail list logo
