* [Patch][OpenMP] use_device_addr/use_device_ptr with Fortran
allocatable/pointer arrays (= array descriptor)
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00985.html
* [Patch][Fortran/OpenMP] Don't create "alloc:" for 'target exit data'
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01344.html
Hi,
my yesterday patch introduced ICE on combining -O2 and -O0 translation
units (since the second has missing summary).
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-fnsummary.c (ipa_merge_fn_summary_after_inlining): Check
for missing EDGE_REF
* ipa-prop.c
Richard Biener writes:
> On Fri, 25 Oct 2019, Jiufu Guo wrote:
>
>> Hi,
>>
>> In PR88760, there are a few disscussion about improve or tune unroller for
>> targets. And we would agree to enable unroller for small loops at O2 first.
>> And we could see performance improvement(~10%) for below
> OK for all 3 patches. Similarly for removing any other remnants you
> might find later.
I have removed left-overs in htdocs/backends.html
--
Eric Botcazoudiff --git a/htdocs/backends.html b/htdocs/backends.html
index 6e212b24..c9449065 100644
--- a/htdocs/backends.html
+++
On Sat, 26 Oct 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > We have to check each operand for being in a pattern, not just the
> > first when avoiding build from scalars (we could possibly handle
> > the special case of some of them being the pattern stmt root, but
> > that would
On Fri, 25 Oct 2019, Jiufu Guo wrote:
> Hi,
>
> In PR88760, there are a few disscussion about improve or tune unroller for
> targets. And we would agree to enable unroller for small loops at O2 first.
> And we could see performance improvement(~10%) for below code:
> ```
> subroutine foo (i,
On Sun, 27 Oct 2019, Alexandre Oliva wrote:
> On Oct 26, 2019, Alexandre Oliva wrote:
>
> > E.g., the reason we gather expanded calls rather than just use
> > cgraph_edges is that the latter would dump several "calls" that are
> > builtins expanded internally by the compiler, and would NOT dump
We use an eof_token global variable as a sentinel on a deferred parse
(such as in-class function definitions, or default args). This
complicates retrieving the next token in certain places.
As such deferred parses always nest properly and completely before
resuming the outer lexer, we can
On Sep 10 2019, Arnaud Charlet wrote:
> Allright, there are already similar kludges elsewhere, so I've applied the
> following patch which fixes it:
>
> 2019-09-10 Arnaud Charlet
>
> * doc/install.texi: Fix syntax for html generation.
>
> Index: doc/install.texi
>
Hello,
On Mon, 28 Oct 2019, Rainer Orth wrote:
> >> > +FAIL: gcc.dg/unroll-and-jam.c scan-tree-dump-times unrolljam "applying
> >> > unroll and jam" 6
> >>
> >> Hrmpf, I'll have a look :-/ Thanks for noticing.
> >
> > A strange interaction with LIM, which only does something on 32bit, but
> >
These are not needed for scalar operands.
2019-10-28 Uroš Bizjak
* config/i386/sse.md (sse_cvtss2si_2):
Remove %k operand modifier.
(*vec_extractv2df_1_sse): Remove %q operand modifier.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline.
Uros.
On Fri, 25 Oct 2019, Andre Vieira (lists) wrote:
>
>
> On 22/10/2019 14:56, Richard Biener wrote:
> > On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
> >
> >> Hi Richi,
> >>
> >> See inline responses to your comments.
> >>
> >> On 11/10/2019 13:57, Richard Biener wrote:
> >>> On Thu, 10 Oct
> > 2019-09-10 Arnaud Charlet
> >
> > * doc/install.texi: Fix syntax for html generation.
> >
> > Index: doc/install.texi
> > ===
> > --- doc/install.texi(revision 275400)
> > +++ doc/install.texi(working copy)
> > @@
On Mon, 28 Oct 2019, Jiufu Guo wrote:
> Richard Biener writes:
>
> > On Fri, 25 Oct 2019, Jiufu Guo wrote:
> >
> >> Hi,
> >>
> >> In PR88760, there are a few disscussion about improve or tune unroller for
> >> targets. And we would agree to enable unroller for small loops at O2 first.
> >> And
This avoids segfaulting in the GIMPLE parser on invalid input.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-10-28 Richard Biener
PR c/92249
* gimple-parser.c (c_parser_parse_gimple_body): Make
current_bb the entry block initially to
2019-10-28 Uroš Bizjak
PR target/92225
* config/i386/sse.md (REDUC_SSE_SMINMAX_MODE): Use TARGET_SSE4_2
condition for V2DImode.
testsuite/ChangeLog:
2019-10-28 Uroš Bizjak
PR target/92225
* gcc.target/i386/pr92225.c: New test.
Bootstrapped and regression tested on
On Sun, Oct 27, 2019 at 08:13:52AM +0100, Gerald Pfeifer wrote:
> On Fri, 21 Jun 2019, Marek Polacek wrote:
> >> 2019-06-20 Matthew Beliveau
> >>
> >>PR c++/90875 - added -Wswitch-outside-range option
> >>* doc/invoke.texi (Wswitch-outside-range): Document.
>
> I noticed this is not
Hi,
On Wed, 23 Oct 2019, Michael Matz wrote:
> On Tue, 22 Oct 2019, Rainer Orth wrote:
>
> > > testsuite/
> > > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case.
> >
> > this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11
> > and sparc-sun-solaris2.11, also
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-10-28 Richard Biener
PR tree-optimization/92252
* tree-vect-slp.c (vect_get_and_check_slp_defs): Adjust
STMT_VINFO_REDUC_IDX when swapping operands.
* gcc.dg/torture/pr92252.c: New
On Fri, 25 Oct 2019, Richard Biener wrote:
>
> This is a cleanup. The cond-reduction restriction can go,
> the fold-left one stays (it cannot handle more than one stmt in
> the cycle - in the future when we get partial loop vectorization
> generic code would handle duplicating of scalar code
It turns out (well, I anticipated that...) that we cannot easily
update the reduction chain during pattern detection in some of
the more contrieved cases. Instead of ICEing in this case the
following makes us give up instead.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
On Sun, Oct 27, 2019 at 6:32 PM Jeff Law wrote:
>
> On 9/29/19 1:51 PM, Martin Sebor wrote:
> > -Wstringop-overflow detects a subset of past-the-end read and write
> > accesses by built-in functions such as memcpy and strcpy. It relies
> > on the functions' effects the knowledge of which is
Hi Michael,
>> On Tue, 22 Oct 2019, Rainer Orth wrote:
>>
>> > > testsuite/
>> > > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case.
>> >
>> > this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11
>> > and sparc-sun-solaris2.11, also reports for
For the new testcase we end up using an indermediate value of the
reduction chain as reduction result. This can be easily supported
by generating epilogues for (poossibly multiple) intermediate values.
For this to work the following relaxes cycle detection to allow
out-of-loop uses plus it
Hi Tobias!
On 2019-10-25T18:17:26+0200, Tobias Burnus wrote:
> This patch is about: libgomp/testsuite/libgomp.fortran/, only
>
> The two test cases I added recently use 'call abort()', which is
> nowadays frowned on as that's a ventor extension. Hence, I change it to
> 'stop'.
>
>
On Fri, Oct 25, 2019 at 9:58 PM Prathamesh Kulkarni
wrote:
>
> On Fri, 25 Oct 2019 at 13:19, Richard Biener
> wrote:
> >
> > On Wed, Oct 23, 2019 at 11:45 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > Hi,
> > > The attached patch tries to fix PR92163 by calling
> > > gimple_purge_dead_eh_edges
On Sun, 27 Oct 2019 at 06:08, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > @@ -10288,6 +10261,23 @@ vectorizable_condition (stmt_vec_info stmt_info,
> > gimple_stmt_iterator *gsi,
> > vect_finish_stmt_generation (stmt_info, new_stmt, gsi);
> >
Hi Jeff,
> Has this been bootstrapped and regression tested?
Yes, it bootstraps OK of course. I ran regression over the weekend, there
are a few minor regressions in lto due to relying on tentative definitions
and a few latent bugs. I'd expect there will be a few similar failures on
other
On Fri, 25 Oct 2019, Andre Vieira (lists) wrote:
> Hi,
>
> This is the reworked patch after your comments.
>
> I have moved the epilogue check into the analysis form disguised under
> '!epilogue_vinfos.is_empty ()'. This because I realized that I am doing the
> "lowest threshold" check there.
On 10/23/19 8:12 PM, Steve Kargl wrote:
* trans-expr.c (gfc_conv_procedure_call): Evaluate args and then
deallocate actual args assocated with intent(out) dummies.
I think the patch by itself looks fine to me – except that the
saw_dealloc is not needed. You can either check
On Mon, 28 Oct 2019 at 07:18, Richard Biener wrote:
>
> On Fri, Oct 25, 2019 at 9:58 PM Prathamesh Kulkarni
> wrote:
> >
> > On Fri, 25 Oct 2019 at 13:19, Richard Biener
> > wrote:
> > >
> > > On Wed, Oct 23, 2019 at 11:45 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > Hi,
> > > > The
Jeff Law writes:
> On 10/5/19 5:29 AM, Richard Sandiford wrote:
>>
>> Sure. This message is going to go to the other extreme, sorry, but I'm
>> not sure which part will be the most convincing (if any).
> No worries. Worst case going to the other extreme is I have to read it
> more than once
* Jim Wilson [2019-10-22 16:34:53 -0700]:
> On Mon, Oct 21, 2019 at 5:26 AM Andrew Burgess
> wrote:
> > Below is a new versions of this patch, I believe that this addresses
> > the review comments from the earlier version. In addition this has
> > been tested using Jim's idea of forcing
On Mon, Oct 28, 2019 at 09:08:04AM +0100, Richard Biener wrote:
> On Fri, 25 Oct 2019, Jiufu Guo wrote:
> > On powerpc64le, for O2 , enable -funroll-loops and limit
> > PARAM_MAX_UNROLL_TIMES=2 and PARAM_MAX_UNROLLED_INSNS=20, we can see >2%
> > overall improvement for SPEC2017.
>
> Note the
On Mon, Oct 28, 2019 at 11:02 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Sat, Oct 26, 2019 at 09:27:12PM +0800, Hongtao Liu wrote:
> > > BTW: Please also note that there is no need to use or operand
> > > mode override in scalar insn templates for intel asm dialect when
> > > operand already has a
Greetings,
This is rather on the trivial side. Google fuzzer found signed integer
overflow in d_number, given this input: _ZZccDF2147483647
Google ref: b141647507.
Ok for trunk?
Thanks,
libiberty/ChangeLog
2019-10-28 Paul Pluzhnikov
* cp-demangle (d_number): Avoid signed int
On 10/28/19 4:44 PM, Jeff Law wrote:
On 10/28/19 4:36 PM, Martin Sebor wrote:
While testing the patch for PR 92226 I posted earlier today
I ran into a few cases where I expected the strlen range
optimization to take place but it didn't.
In other instances this wouldn't be surprising because
On October 28, 2019 7:43:33 PM GMT+01:00, David Edelsohn
wrote:
>>> Has this been bootstrapped and regression tested?
>>
>> Yes, it bootstraps OK of course. I ran regression over the weekend,
>there
>> are a few minor regressions in lto due to relying on tentative
>definitions
>> and a few
On 10/28/19 2:29 PM, Martin Sebor wrote:
> A recent enhancement to take advantage of non-constant strlen
> results constrained to a known range interacts badly with
> the nul-over-nul optimization. The optimization eliminates
> nul stores that overwrite the exiting terminating nul of
> the
Hi!
On Sat, Oct 26, 2019 at 09:27:12PM +0800, Hongtao Liu wrote:
> > BTW: Please also note that there is no need to use or operand
> > mode override in scalar insn templates for intel asm dialect when
> > operand already has a scalar mode.
>
On 10/28/19 4:36 PM, Martin Sebor wrote:
> While testing the patch for PR 92226 I posted earlier today
> I ran into a few cases where I expected the strlen range
> optimization to take place but it didn't.
>
> In other instances this wouldn't be surprising because
> the optimization was only
On 10/28/19 1:43 PM, Richard Biener wrote:
> On October 28, 2019 7:43:33 PM GMT+01:00, David Edelsohn
> wrote:
Has this been bootstrapped and regression tested?
>>>
>>> Yes, it bootstraps OK of course. I ran regression over the weekend,
>> there
>>> are a few minor regressions in lto due to
A recent enhancement to take advantage of non-constant strlen
results constrained to a known range interacts badly with
the nul-over-nul optimization. The optimization eliminates
nul stores that overwrite the exiting terminating nul of
the destination string. This interaction causes the nul
On 28/10/2019 21:52, Bernhard Reutner-Fischer wrote:
> On Mon, 28 Oct 2019 11:53:06 +1100
> Kugan Vivekanandarajah wrote:
>
>> On Wed, 23 Oct 2019 at 23:07, Richard Biener
>> wrote:
>
>>> Did you try this with multiple assembler options? I see you stream
>>> them as -Wa,-mfpu=xyz,-mthumb but
Wilco Dijkstra wrote:
>>>
>>> I suppose targets can override this decision.
>> I think they probably could via the override_options mechanism.
>
> Yes, it's trivial to add this to target_option_override():
>
> if (!global_options_set.x_flag_no_common)
>flag_no_common = 0;
for the
On Mon, 28 Oct 2019 11:53:06 +1100
Kugan Vivekanandarajah wrote:
> On Wed, 23 Oct 2019 at 23:07, Richard Biener
> wrote:
> > Did you try this with multiple assembler options? I see you stream
> > them as -Wa,-mfpu=xyz,-mthumb but then compare the whole
> > option strings so a mismatch with
While testing the patch for PR 92226 I posted earlier today
I ran into a few cases where I expected the strlen range
optimization to take place but it didn't.
In other instances this wouldn't be surprising because
the optimization was only introduced for multi-character stores
and with the
On Sat, 26 Oct 2019, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu. Ok to install?
I have only a peripheral comment:
> diff --git a/gcc/common.opt b/gcc/common.opt
> index cc279f411d796..63d646fba2b42 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1091,6 +1091,14 @@
Hi,
>> I suppose targets can override this decision.
> I think they probably could via the override_options mechanism.
Yes, it's trivial to add this to target_option_override():
if (!global_options_set.x_flag_no_common)
flag_no_common = 0;
Cheers,
Wilco
On 9/26/19 6:05 AM, Richard Sandiford wrote:
> Similarly to the simulate_builtin_function_decl patch, this one
> adds a hook for simulating an enum declaration in the source
> language. Again, the main SVE ACLE patch has tests for various
> error conditions.
>
> Tested on aarch64-linux-gnu and
Hi Bernhard,
Thanks for the review.
On Tue, 29 Oct 2019 at 08:52, Bernhard Reutner-Fischer
wrote:
>
> On Mon, 28 Oct 2019 11:53:06 +1100
> Kugan Vivekanandarajah wrote:
>
> > On Wed, 23 Oct 2019 at 23:07, Richard Biener
> > wrote:
>
> > > Did you try this with multiple assembler options? I
OK.
On Mon, Oct 28, 2019 at 7:56 PM Paul Pluzhnikov via gcc-patches
wrote:
>
> Greetings,
>
> This is rather on the trivial side. Google fuzzer found signed integer
> overflow in d_number, given this input: _ZZccDF2147483647
> Google ref: b141647507.
>
> Ok for trunk?
>
> Thanks,
>
>
Fixed one place without consistent mode.
Bootstrapped and regress testing passed on powerpc64le-linux.
Thanks!
Kewen
---
gcc/ChangeLog
2019-10-25 Kewen Lin
PR target/92132
* config/rs6000/rs6000.md (one_cmpl3_internal): Expose name.
* config/rs6000/vector.md
Hi,
Reworked according to your comments, see inline for clarification.
Is this OK for trunk?
gcc/ChangeLog:
2019-10-28 Andre Vieira
PR 88915
* tree-ssa-loop-niter.h (simplify_replace_tree): Change declaration.
* tree-ssa-loop-niter.c (simplify_replace_tree): Add context
On Mon, Oct 28, 2019 at 03:05:58PM +, Wilco Dijkstra wrote:
> > Has this been bootstrapped and regression tested?
>
> Yes, it bootstraps OK of course. I ran regression over the weekend, there
> are a few minor regressions in lto due to relying on tentative definitions
> and a few latent bugs.
>> Has this been bootstrapped and regression tested?
>
> Yes, it bootstraps OK of course. I ran regression over the weekend, there
> are a few minor regressions in lto due to relying on tentative definitions
> and a few latent bugs. I'd expect there will be a few similar failures on
> other
On 10/11/19 6:01 AM, Mihailo Stojanovic wrote:
> Currently, when a function argument of type double gets loaded into a
> vector register on a 32-bit target, it is firstly reloaded into two
> general purpose registers, and then loaded into a vector register using
> two insert.w instructions.
>
>
On October 28, 2019 6:18:26 PM GMT+01:00, Segher Boessenkool
wrote:
>On Mon, Oct 28, 2019 at 09:08:04AM +0100, Richard Biener wrote:
>> On Fri, 25 Oct 2019, Jiufu Guo wrote:
>> > On powerpc64le, for O2 , enable -funroll-loops and limit
>> > PARAM_MAX_UNROLL_TIMES=2 and
On 10/18/19 12:10 AM, Mihailo Stojanovic wrote:
> Mips built-in functions are currently not marked as pure, which
> invalidates pointers across built-in function calls. If a pointer is
> alive across built-in call, dereferencing it before and after the call
> will generate two load instructions
On 10/19/19 10:35 PM, Ian Lance Taylor wrote:
> On Sat, Oct 19, 2019 at 9:11 PM Miguel Saldivar
> wrote:
>>
>> Updated patch that uses `_Complex` and `_Imaginary`
>>
>> Thanks,
>> Miguel Saldivar
>>
>> From 742b37c88bea0118046ac359cabe5f250d69ee30 Mon Sep 17 00:00:00 2001
>> From: Miguel
On 10/21/19 4:57 AM, Mihailo Stojanovic wrote:
> This expands the existing MIPS mulditi3 pattern by adding support for
> MIPS64R6 multiplication instructions.
>
> gcc/ChangeLog:
>
> * config/mips/mips.md (mulditi3): Generate patterns for high
> doubleword and low doubleword
On 10/22/19 2:10 AM, Claudiu Zissulescu wrote:
> Hi Andrew,
>
> There are cases when an pic address gets complicated, and it needs to
> be resolved via force_reg function found in
> prepare_move_operands. When this happens, we need to disambiguate the
> pic address and re-legitimize it. Testcase
On 10/22/19 2:13 AM, Claudiu Zissulescu wrote:
> From: Shahab Vahedi
>
> Hi Andrew,
>
> The movsi_ne variants are in a wrong order, leading to wrong
> computation of the internal attribute "cond". Hence, to errors when
> outputting annul-true or annul-false instructions. Testcase added.
>
>
63 matches
Mail list logo
