This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
The command line option -fcallgraph-info is added and makes the
compiler generate another output file (xxx.ci) for each compilation
unit, which is a valid VCG file (you can launch your favorite VCG
vie
This comment cut&pasto fix was split out of another patch I'm about to
contribute, as the current version of the patch no longer touches cgraph
data structures.
I'm checking it in as obvious.
From: Eric Botcazou
for gcc/ChangeLog
* cgraph.c (cgraph_node::rtl_info): Fix cut&pasto in c
This patch adds a new optimization pass for rs6000 targets.
This new pass scans existing rtl expressions and replaces X-form loads and
stores with rtl expressions that favor selection of the D-form instructions in
contexts for which the D-form instructions are preferred. The new pass runs
af
Maciej W. Rozycki wrote:
On Tue, 21 May 2019, Jacob Bachmeyer wrote:
IOW I don't discourage you from developing a comprehensive solution,
however applying my proposal right away will help at least some people and
will not block you in any way.
Correct, although, considering how lo
I merged trunk revision 277462 to the gccgo branch.
Ian
Hi Jiufu,
On Fri, Oct 25, 2019 at 10:44:39PM +0800, Jiufu Guo wrote:
> 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.
[ snip ]
> PR tree-optimization/88760
> * config/rs6000/rs60
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 from ifcvt_local_dce if we need eh cleanup.
> > Does it look OK ?
>
> Hmm. I thi
On Fri, Oct 25, 2019 at 03:47:10PM +, Wilco Dijkstra wrote:
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global variable accesses have a codesize and perform
Ugh. I should have caught this earlier.
My Fedora tester failed recently on the "flatbuffers" package. It
worked on Oct 6th GCC snapshot, but was failing by Oct 13th snapshot.
Bisection ultimately landed on:
> commit d9d534895b775a453b8d8d291ef72d6dfa5f9e52 (HEAD, refs/bisect/bad)
> Author: ms
On Fri, Oct 25, 2019 at 9:20 PM Hongtao Liu wrote:
>
> > Looking into sse.md, there is a lot of inconsistencies in existing *vm
> > patterns w.r.t. operand constraints. Unfortunately, these were copied
> > into proposed patterns. One example is existing
> >
> > (define_insn "_vmsqrt2"
> > [(set
On Fri, Oct 25, 2019 at 9:13 PM Hongtao Liu wrote:
>
> Update patch.
>
> On Fri, Oct 25, 2019 at 4:01 PM Uros Bizjak wrote:
> >
> > On Fri, Oct 25, 2019 at 7:55 AM Hongtao Liu wrote:
> > >
> > > On Fri, Oct 25, 2019 at 1:23 PM Hongtao Liu wrote:
> > > >
> > > > On Fri, Oct 25, 2019 at 2:39 AM U
This patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 25 Oct 2019 at 14:18, Richard Sandiford
wrote:
>
> Hi Prathamesh,
>
> I've just committed a patch that fixes a large number of SVE
> reduction-related failures. Could you rebase and retest on top of that?
> Sorry for messing you around, but regression testing based on the state
> before t
> Looking into sse.md, there is a lot of inconsistencies in existing *vm
> patterns w.r.t. operand constraints. Unfortunately, these were copied
> into proposed patterns. One example is existing
>
> (define_insn "_vmsqrt2"
> [(set (match_operand:VF_128 0 "register_operand" "=x,v")
> (vec_merg
Update patch.
On Fri, Oct 25, 2019 at 4:01 PM Uros Bizjak wrote:
>
> On Fri, Oct 25, 2019 at 7:55 AM Hongtao Liu wrote:
> >
> > On Fri, Oct 25, 2019 at 1:23 PM Hongtao Liu wrote:
> > >
> > > On Fri, Oct 25, 2019 at 2:39 AM Uros Bizjak wrote:
> > > >
> > > > On Wed, Oct 23, 2019 at 7:48 AM Hong
Fixed by r277351, applying to trunk.
2019-10-25 Marek Polacek
PR c++/91581 - ICE in exception-specification of defaulted ctor.
* g++.dg/cpp0x/noexcept55.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/noexcept55.C
gcc/testsuite/g++.dg/cpp0x/noexcept55.C
new file mode 10064
In the gofrontend we've encountered problems with numeric expressions
that have named types, as shown at https://golang.org/issue/34577.
Those problems are fixed on trunk, but the fixes there rely on other
machinery that has been added since the GCC 9 branch. This patch
fixes the same problems on
Wilco Dijkstra schrieb:
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards. On many targets
this means global variable accesses have a codesize and performance penalty.
This applies to C code only, C++ cod
However, passing a scalar instead of an array/array
element worked/works with (nearly?) all compilers. Hence, passing
a scalar is seemingly common pattern. Thus, I wonder whether we
should do something about this.
Maybe we could mention -fallow-argument-mismatch in the error message.
(Reall
After r269667 which introduced joust_maybe_elide_copy, in C++17 we can elide
a constructor if it uses a conversion function that returns a prvalue, and
use the conversion function in its stead.
This eliding means that if we have a candidate that previously didn't have
->second_conv, it can have it
Hi Jeff, hi Thomas, hi all,
I had a look at Wannier90. (Fedora uses Version 2.0.0 of 2013, 2.0.1 was
released 2015; current is 3.0 of Feb 2019 and does build.) I think that
problem in Wannier90 it typical for all failing code, although there are
likely a few other failures. Namely,
That code
This patch aims to allow more load/store instructions to be compressed by
replacing a load/store of 'base register + large offset' with a new load/store
of 'new base + small offset'. If the new base gets stored in a compressed
register, then the new load/store can be compressed. Since there is an o
The sched2 pass undoes some of the addresses generated by the RISC-V
shorten_memrefs code size optimization (patch 1/2) and consequently increases
code size. This patch prevents sched-deps.c from changing an address if it is
expected to increase address cost.
Tested on bare metal rv32i, rv32iac, r
Hi Kito,
Thank you for taking the time to review my patch. I am posting an updated
patchset taking into account your comments.
On 18/09/2019 11:01, Kito Cheng wrote:
> Hi Craig:
>
> Some general review comment:
> - Split new pass into new file.
> - Add new option to enable/disable this pass.
> -
On Tue, 21 May 2019, Jacob Bachmeyer wrote:
> > IOW I don't discourage you from developing a comprehensive solution,
> > however applying my proposal right away will help at least some people and
> > will not block you in any way.
> >
>
> Correct, although, considering how long my FSF paper
All of these special member functions do exactly what the compiler would
do anyway. By defining them as defaulted for C++11 and later we prevent
move constructors and move assignment operators being defined (which is
consistent with the previous semantics).
Also move default init of the input_ite
Hello Jeff,
Yes, it is a backport to gcc-8. No, I don't have commit access. Could you
please commit it for me?
Thanks,
Delia
From: Jeff Law
Sent: 04 October 2019 22:27
To: Delia Burduv ; gcc-patches@gcc.gnu.org
Cc: nd ; i...@airs.com ; rguent...@suse.de
Subj
On Fri, Oct 25, 2019 at 06:17:26PM +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'.
>
> Additional
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.
The only place where we may reject an epilogue_vinfo is when
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, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know we
On 22/10/2019 18:52, Richard Sandiford wrote:
Thanks for doing this. Hope this message doesn't cover too much old
ground or duplicate too much...
"Andre Vieira (lists)" writes:
@@ -2466,15 +2476,65 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters,
tree nitersm1,
else
ni
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'.
Additionally, the 'fortran.exp' in the directory states: "For Fortran
we're doing to
On Fri, Oct 25, 2019 at 09:05:03AM +0200, Tobias Burnus wrote:
> On 10/24/19 10:43 PM, Steve Kargl wrote:
> > The patch moves the matching of the nonstandard type-spec
> > BYTE to its own matching function. During this move, a
> > check for invalid matching in free-form source code it
> > detected
This patch is for libgomp/testsuite/libgomp.oacc-fortran/ and does two
things:
* It changes 'call abort' to 'stop 1' (etc.) to make Bernhard R.-F.
happy as it is then doesn't use a vendor extension.
[Note: I kept the abort call in abort-{1,2,}.f90. [NB: stop*.f also
exists.] And: 'call abort
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards. On many targets
this means global variable accesses have a codesize and performance penalty.
This applies to C code only, C++ code is not affected by -fcom
Hi Steve,
On 10/25/19 4:17 PM, Steve Kargl wrote:
My BOZ patch brought gfortran closer to an actual comforming Fortran
compiler while providing an option that would allow quite a few
documented and undocumented extensions. If the patch broke some of
your code, and -fallow-invalid-boz did not a
On 10/25/19 7:54 AM, Tobias Burnus wrote:
> Hi Jeff,
>
> On 10/25/19 3:22 PM, Jeff Law wrote:
>> So across Fedora the BOZ stuff tripped 2-3 packages. In comparison the
>> function argument stuff broke 30-40 packages, many of which still
>> don't build without -fallow-argument-mismatch.
>
> Regard
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, i1, block)
integer :: i, i1
integer :: block(9,
On Fri, Oct 25, 2019 at 12:39:58AM +0200, Jakub Jelinek wrote:
> Hi!
>
> When looking into the constexpr new issues and adding is_std_construct_at
> function, I've noticed that with --enable-symvers=gnu-versioned-namespace
That is... sneaky. I guess I/we need to test with
--enable-symvers=gnu-ve
Hi Thomas,
On 10/25/19 10:43 AM, Thomas Schwinge wrote:
OK for trunk, with the following few small items considered.
Committed as Rev. 277451 – after a fresh bootstrap and regtesting.
Changes:
* I have now a new test case
libgomp/testsuite/libgomp.oacc-fortran/common-block-3.f90 which looks
On Fri, Oct 25, 2019 at 10:35:24AM +0200, Tobias Burnus wrote:
> On 9/26/19 10:45 AM, Mark Eggleston wrote:
>
> PS: I was also not that happy about the BOZ changes by Steve, which
> broke code here – but, fortunately, adding int( ,kind=) around it was
> sufficient and that code was supposed to b
One of the changes in r277281 was to make the typedef variant
handling in strip_typedefs pass the raw DECL_ORIGINAL_TYPE to the
recursive call, instead of applying TYPE_MAIN_VARIANT first.
This PR shows that that interacts badly with the implementation
of DR1558, because we then refuse to strip ali
Hi Jeff,
On 10/25/19 3:22 PM, Jeff Law wrote:
So across Fedora the BOZ stuff tripped 2-3 packages. In comparison the
function argument stuff broke 30-40 packages, many of which still
don't build without -fallow-argument-mismatch.
Regarding the latter:
The initial patch was too strict – an als
On 25/10/19 14:34 +0100, Jonathan Wakely wrote:
On 23/10/19 08:08 +0100, Jonathan Wakely wrote:
On Wed, 23 Oct 2019 at 00:33, Tam S. B. wrote:
The use of concepts is causing `#include ` to break on clang.
OK, thanks, I'll guard it with #if.
Fixed on trunk with this patch. My Clang 7.0.1 st
On 23/10/19 08:08 +0100, Jonathan Wakely wrote:
On Wed, 23 Oct 2019 at 00:33, Tam S. B. wrote:
The use of concepts is causing `#include ` to break on clang.
OK, thanks, I'll guard it with #if.
Fixed on trunk with this patch. My Clang 7.0.1 still can't compile current
trunk though, because w
On 10/25/19 2:35 AM, Tobias Burnus wrote:
> On 9/26/19 10:45 AM, Mark Eggleston wrote:
>> Original thread starts here
>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
>> OK to commit?
>
> As Steve, I am not really happy about adding yet another option and
> especially not about legacy f
Hi.
And there's one more integer overflow fix.
Martin
>From 35c22704dc705508672f19b09e6d1b94bd956535 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 25 Oct 2019 15:09:32 +0200
Subject: [PATCH] Fix unsigned type overflow in memory report.
gcc/ChangeLog:
2019-10-25 Martin Liska
* ggc
On Fri, 25 Oct 2019 at 12:08, Richard Earnshaw (lists)
wrote:
>
> On 24/10/2019 17:10, Richard Earnshaw (lists) wrote:
> > On 24/10/2019 11:16, Christophe Lyon wrote:
> >> On 23/10/2019 15:21, Richard Earnshaw (lists) wrote:
> >>> On 23/10/2019 09:28, Christophe Lyon wrote:
> On 21/10/2019 14
This patch adds AArch64 patterns for converting between 64-bit and
128-bit integer vectors, and makes the vectoriser and expand pass
use them.
2019-10-24 Richard Sandiford
gcc/
* tree-vect-stmts.c (vectorizable_conversion): Extend the
non-widening and non-narrowing path to han
Although a previous patch allowed mixed vector sizes within a vector
region, we generally still required equal vector sizes within a vector
stmt. Specifically, vect_get_vector_types_for_stmt computes two vector
types: the vector type corresponding to STMT_VINFO_VECTYPE and the
vector type that det
This patch makes the vectoriser try mixtures of 64-bit and 128-bit
vector modes on AArch64. It fixes some existing XFAILs and allows
kernel 24 from the Livermore Loops test to be vectorised (by using
a mixture of V2DF and V2SI).
I'll apply this if the prerequisites are approved.
2019-10-24 Ric
After previous patches, it's now possible to make the vectoriser
support multiple vector sizes in the same vector region, using
related_vector_mode to pick the right vector mode for a given
element mode. No port yet takes advantage of this, but I have
a follow-on patch for AArch64.
This patch als
> This can be further optimized by using memcmp in place of strncmp, since from
> the length check you know that you won't see the null terminator among the
> three
> chars you're checking.
Fair enough, here's the combined changelog/diff, with memcmp:
2019-10-22 Eduard-Mihai Burtescu
include/
Some callers of get_same_sized_vectype were dealing with operands that
are constant or defined externally, and so have no STMT_VINFO_VECTYPE
available. Under the current model, using get_same_sized_vectype for
that case is equivalent to using get_vectype_for_scalar_type, since
get_vectype_for_scal
This patch replaces vec_info::vector_size with vec_info::vector_mode,
but for now continues to use it as a way of specifying a single
vector size. This makes it easier for later patches to use
related_vector_mode instead.
2019-10-24 Richard Sandiford
gcc/
* tree-vectorizer.h (vec_inf
This is another patch in the series to remove the assumption that
all modes involved in vectorisation have to be the same size.
Rather than have the target provide a list of vector sizes,
it makes the target provide a list of vector "approaches",
with each approach represented by a mode.
A later p
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html
I was privately pointed at the Clang tests. The implementation
passes most of them. The one difference I noticed is that GCC
expands macros in the __has_builtin argument list while Clang
doesn't. Since this is in line with other si
The validation phase of vectorizable_shift used TYPE_MODE to check
whether the shift amount vector was compatible with the shifted vector:
if ((op1_vectype == NULL_TREE
|| TYPE_MODE (op1_vectype) != TYPE_MODE (vectype))
&& (!slp_node
|| SLP_TREE_DEF_TYPE
Except for one case, get_vectype_for_scalar_type_and_size calculates
what the vector mode should be and then calls build_vector_type,
which recomputes the mode from scratch. This patch makes it use
build_vector_type_for_mode instead.
The exception mentioned above is when preferred_simd_mode retur
This is a continuation of the patch series I started on Wednesday
this time posted under a covering message. Parts 1-5 were:
[1/n] https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01634.html
[2/n] https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01637.html
[3/n] https://gcc.gnu.org/ml/gcc-patches/2019-
gcc/ChangeLog:
2019-10-25 Martin Liska
* cgraphunit.c (symbol_table::compile): Remove argument
for dump_memory_report.
* ggc-common.c (dump_ggc_loc_statistics): Likewise.
(compare_final): Remove in order to make report
better readable.
* ggc.h (
gcc/ChangeLog:
2019-10-25 Martin Liska
* cgraphunit.c (symbol_table::compile): Pass
title as dump_memory_report argument.
* toplev.c (dump_memory_report): New argument.
(finalize): Pass new argument.
* toplev.h (dump_memory_report): Add argument.
gcc/
Hi.
The patches fix 3 issues I spotted today during a LTO debugging
session:
1) Removal of two different sorting of GGC memory, it's confusing.
2) Move Leak to the first column for GGC memory similarly to
other reports.
3) I make a significant header/title that can distinguish in between
-f
gcc/ChangeLog:
2019-10-25 Martin Liska
* ggc-common.c: Move Leak to the first column.
---
gcc/ggc-common.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index 8bc77a0a036..37d3c5df9e1 100644
--- a/gcc/ggc-common.c
+++
Where possible, it is always desirable to use 430 format instructions when
compiling for the 430X ISA and the large memory model. 430 instructions have
reduced code size and faster execution time.
This patch recognizes a couple of new patterns in which we can use 430 insns in
the large memory mode
Hi!
I'm aware that incremental builds aren't really supported, but during
day-to-day development, they're still useful -- as long as they work.
;-)
A recent change (adding '\$(srcdir)/cp/logic.cc' to 'gtfiles' in
'gcc/cp/config-lang.in') broke things:
[...]/source-gcc/gcc/cp/logic.cc:907:25
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 parts, they'd
simply stay single-lane SLP graph parts).
When I remove the swapping of operands in the IL I didn't actually
relax swapping restrictions.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-10-25 Richard Biener
* tree-vect-slp.c (vect_get_and_check_slp_defs): Only fail
swapping if we actual
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 be a followup improvement).
Bootstrap & regtest running on x86-64-unknown-linux-gnu.
R
On 24/10/2019 17:10, Richard Earnshaw (lists) wrote:
On 24/10/2019 11:16, Christophe Lyon wrote:
On 23/10/2019 15:21, Richard Earnshaw (lists) wrote:
On 23/10/2019 09:28, Christophe Lyon wrote:
On 21/10/2019 14:24, Richard Earnshaw (lists) wrote:
On 21/10/2019 12:51, Christophe Lyon wrote:
O
Hi,
To support full condition reduction vectorization, we have to define
vec_cmp_* and vcond_mask_*. This patch is to add related expands.
Add vector_{ungt,unge,unlt,unle} for unique vector_*
interface support.
Regression testing just launched.
gcc/ChangeLog
2019-10-25 Kewen Lin
PR
Unwanted unrolling meant that we had more single-precision FADDAs
than expected.
Tested on aarch64-linux-gnu (with and without SVE) and applied as r277442.
Richard
2019-10-25 Richard Sandiford
gcc/testsuite/
* gcc.target/aarch64/sve/reduc_strict_3.c (double_reduc1): Prevent
Recent target-independent patches mean that several SVE tests
now produce the code that we'd originally wanted them to produce.
Really nice to see :-)
This patch therefore updates the expected baseline, so that hopefully
we don't regress from this point in future.
Tested on aarch64-linux-gnu (wit
Hi.
I'm fixing one obvious issue in dump_tree_statistics.
I'm going to install the patch.
Martin
gcc/ChangeLog:
2019-10-25 Martin Liska
* tree.c (dump_tree_statistics): Use sorted index 'j' and not 'i'.
---
gcc/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Hi Prathamesh,
I've just committed a patch that fixes a large number of SVE
reduction-related failures. Could you rebase and retest on top of that?
Sorry for messing you around, but regression testing based on the state
before the patch wouldn't have been that meaningful. In particular...
Prath
Hi Tobias!
On 2019-10-23T22:34:42+0200, Tobias Burnus wrote:
> Updated version attached. Changes:
> * Use "true" instead of "openacc" for the OpenACC-only "copy()" clause
> (as not shared w/ OpenMP)
> * Add some documentation to gimplify.c
> * Use GOVD_FIRSTPRIVATE also for "kernel"
Thanks!
>
On 9/26/19 10:45 AM, Mark Eggleston wrote:
Original thread starts here
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
OK to commit?
As Steve, I am not really happy about adding yet another option and
especially not about legacy features. On the other hand, I see that
legacy code is
On Wed, Oct 23, 2019 at 1:13 PM Richard Sandiford
wrote:
>
> build_same_sized_truth_vector_type was confusingly named, since for
> SVE and AVX512 the returned vector isn't the same byte size (although
> it does have the same number of elements). What it really returns
> is the "truth" vector type
On Wed, Oct 23, 2019 at 1:10 PM Richard Sandiford
wrote:
>
> Callers of vect_halve_mask_nunits and vect_double_mask_nunits
> already know what mode the resulting vector type should have,
> so we might as well create the vector type directly with that mode,
> just like build_vector_type_for_mode le
On 10/25/19 8:04 AM, Gerald Pfeifer wrote:
I looked for a replacement, and there does not appear to be one, so I
remove the link.
Well, like always there is the web archive:
https://web.archive.org/web/20190419071502/http://www.idris.fr/data/publications/F95/test_F95_english.html
It does have
On Thu, Oct 24, 2019 at 9:45 AM Richard Sandiford
wrote:
>
> Bernhard Reutner-Fischer writes:
> > On 23 October 2019 13:16:19 CEST, Richard Sandiford
> > wrote:
> >
> >>+++ gcc/config/gcn/gcn.c 2019-10-23 12:13:54.091122156 +0100
> >>@@ -3786,8 +3786,7 @@ gcn_expand_builtin (tree exp, rtx
On Thu, Oct 24, 2019 at 9:29 AM Richard Sandiford
wrote:
>
> Now that vectorizable_operation vectorises most loop stmts involved
> in a reduction, it needs to be aware of reductions in fully-masked loops.
> The LOOP_VINFO_CAN_FULLY_MASK_P parts of vectorizable_reduction now only
> apply to cases t
Reduction discovery nicely computes STMT_VINFO_REDUC_IDX for all
stmts involved in the reduction but that has been useless somewhat
since pattern recog later will wreck the info. The following is
an attempt to fix that during pattern recog. I may very well miss
some cases but hope to fix them..
Hello Mark, hi all,
On 10/21/19 4:40 PM, Mark Eggleston wrote:
This is an extension to support a legacy feature supported by other
compilers such as flang and the sun compiler. As I understand it this
feature is associated with DEC so it enabled using
-fdec-char-conversions and by -fdec.
It
On Fri, Oct 25, 2019 at 7:55 AM Hongtao Liu wrote:
>
> On Fri, Oct 25, 2019 at 1:23 PM Hongtao Liu wrote:
> >
> > On Fri, Oct 25, 2019 at 2:39 AM Uros Bizjak wrote:
> > >
> > > On Wed, Oct 23, 2019 at 7:48 AM Hongtao Liu wrote:
> > > >
> > > > Update patch:
> > > > Add m constraint to define_in
Richard Biener writes:
> On Wed, Oct 23, 2019 at 2:12 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Wed, Oct 23, 2019 at 1:51 PM Richard Sandiford
>> > wrote:
>> >>
>> >> Richard Biener writes:
>> >> > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford
>> >> > 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 from ifcvt_local_dce if we need eh cleanup.
> Does it look OK ?
Hmm. I think it shows an issue with the return value of remove_stmt_form_eh_lp
whi
On Fri, Oct 25, 2019 at 1:52 AM Indu Bhagat wrote:
>
>
>
> On 10/11/2019 04:41 AM, Jakub Jelinek wrote:
> > On Fri, Oct 11, 2019 at 01:23:12PM +0200, Richard Biener wrote:
> >>> (coreutils-0.22)
> >>>.debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf
> >>> (uncompressed) | ratio
On 10/21/19 7:28 PM, Paul Richard Thomas wrote:
Please find attached a patch to keep 9-branch up to speed with trunk
as far as the ISO_Fortran_binding feature is concerned.
It bootstraps and regtests on 9-branch and incorporates the correction
for PR92027, which caused problems for trunk on cert
On Wed, Oct 23, 2019 at 2:12 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Oct 23, 2019 at 1:51 PM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford
> >> > wrote:
> >> >>
> >> >> This patch is the first o
On 10/24/19 10:43 PM, Steve Kargl wrote:
The patch moves the matching of the nonstandard type-spec
BYTE to its own matching function. During this move, a
check for invalid matching in free-form source code it
detected (see byte_4.f90). OK to commit?
OK with a nit.
+ if (gfc_current_for
91 matches
Mail list logo
