Re: [PATCH 1/2] gcc_qsort: source code changes

On Sun, 13 May 2018, H.J. Lu wrote: > This breaks bootstrap on Fedora 28/i686: > > https://gcc.gnu.org/ml/gcc-regression/2018-05/msg00088.html > > ../../src-trunk/gcc/sort.cc:112:5: note: in expansion of macro ‘REORDER_45’ > REORDER_45 (8, 8, 0); > ^~ > ../../src-trunk/gcc/sort.

[wwwdocs] Describe how to validate wwwdocs changes

This is triggered by a report from Martin who rightfully pointed out that it's not straightforward to validate wwwdocs changes before committing a change. Martin, what do you think? Would that have avoided the challenges your ran into? Anything to better clarify or otherwise improve? Gerald

[PR63185][RFC] Improve DSE with branches

Hi, Attached patch handles PR63185 when we reach PHI with temp != NULLL. We could see the PHI and if there isn't any uses for PHI that is interesting, we could ignore that ? Bootstrapped and regression tested on x86_64-linux-gnu. Is this OK? Thanks, Kugan gcc/ChangeLog: 2018-05-14 Kugan Vive

Re: [RFC] Improve tree DSE

Hi Richard, >> Given the simple testcases you add I wonder if you want a cheaper >> implementation, >> namely check that when reaching a loop PHI the only aliasing stmt in >> its use-chain >> is the use_stmt you reached the PHI from. That would avoid this and the >> tests >> for the store being

[C++ Patch] Add TYPE_REF_P

Hi, this simply adds the missing TYPE_REF_P - counterpart of TYPE_PTR_P - and uses it throughout (also adjusts a few places to consistently use the existing TYPE_PTR_P). Tested x86_64-linux. Thanks, Paolo. 2018-05-14 Paolo Carlini * cp-tree.h (TYPE_R

Re: [PATCH 1/2] gcc_qsort: source code changes

On Thu, May 10, 2018 at 8:56 AM, Alexander Monakov wrote: > * sort.cc: New file. > * system.h [!CHECKING_P] (qsort): Redirect to gcc_qsort. > * vec.c (qsort_chk): Use gcc_qsort. > This breaks bootstrap on Fedora 28/i686: https://gcc.gnu.org/ml/gcc-regression/2018-05/msg00

Re: [wwwdocs] Add GCC 8 Fortran feature description

**PING** Could someone either approve and apply this or explain to me how to do so?  I don’t have commit rights so I don’t think I can do it. Damian On May 2, 2018 at 11:22:02 AM, Damian Rouson (dam...@sourceryinstitute.org) wrote: The patch below includes a description of a new feature in gf

[Committed] PR fortran/63529 -- Fix documentation.

I've committed the attach document patch. 2018-05-13 Steven G. Kargl PR fortran/63529 * gfortran.texi: Clarify documentation for Cray pointer and assumed-sized array. -- Steve Index: gcc/fortran/gfortran.texi ===

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

On Wed, 29 Nov 2017, David Malcolm wrote: I was experimenting with optimizing away matching malloc/free pairs, moving the allocation to either the stack, or to a thread-local obstack, under certain conditions, or to hoist allocations out of loops. I didn't get any significant wins, but much of

[Patch, fortran] PR85742 sizeof allocatable arrays returning wrong value

I intend to apply this 'obvious' patch to trunk and 8-branch tonight, unless there are any objections. Bootstrapped and regetested on FC27/x86_64. Paul 2018-05-13 Paul Thomas PR fortran/85742 * trans-types.c (gfc_get_dtype_rank_type): Reorder evaluation of 'size'. If the element

Re: [PATCH] Fortran cleanup patch

On Thu, 10 May 2018 16:08:17 -0700 Steve Kargl wrote: > The attached patch removed an unused function. > OK to commit? Removing unused code, can only make things easier. Ok to commit IMHO. - Andre > > 2018-05-10 Steven G. Kargl > >* gfortran.h: Remove prototype. >* symbol.c (gfc

Re: [PATCH] PR fortran/85521 -- Zero length substrings in array aconstructors

Hi, sorry, I didn't get, that this is standard conforming. So go for it: Ok for trunk and thanks for the patch. - Andre On Thu, 10 May 2018 08:41:21 -0700 Steve Kargl wrote: > It is certainly possible to give a warning, but it > would be odd (to me) to warn about technically > standard conform