On Mon, Sep 30, 2019 at 7:51 PM Alexander Monakov wrote:
>
> On Mon, 30 Sep 2019, Alexander Monakov wrote:
>
> > +static unsigned
> > +average_cost (unsigned then_cost, unsigned else_cost, edge e)
> > +{
> > + return else_cost + e->probability.apply ((int) then_cost - else_cost);
>
> Ugh, I made
On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill wrote:
>
> My comments accidentally got lost.
>
> Several places in the front-end (and elsewhere) use the same lazy
> allocation pattern for hash_maps, and this patch replaces them with
> hash_map_safe_* functions like vec_safe_*. They don't provide a
On Mon, Sep 30, 2019 at 3:21 PM Richard Sandiford
wrote:
>
> The current aka diagnostics can sometimes leak internal details that
> seem more likely to be distracting than useful. E.g. on aarch64:
>
> void f (va_list *va) { *va = 1; }
>
> gives:
>
> incompatible types when assigning to type ‘
Hans-Peter Nilsson writes:
>> From: Richard Sandiford
>> Date: Wed, 11 Sep 2019 21:02:26 +0200
>
>> This series of patches introduces some classes and helpers for handling
>> multiple ABIs in the same translation unit. At the moment "ABI" maans
>> specifically the choice of call-clobbered regist
> I have verified this change by running my combined build process where a
> native `x86_64-linux-gnu' configuration is built first and then used to
> build a `riscv64-linux-gnu' cross-compiler, both with `--disable-libada'
> specified, without and with this patch applied. I have added `make -
On Sep 26, 2019, Richard Biener wrote:
> On Thu, Sep 26, 2019 at 4:05 AM Alexandre Oliva wrote:
> Heh, I don't have one - which usually makes me simply inline the
> beast into the single caller :P
> Maybe simply have_new_type_for_decl_with_old_die_p?
> Or new_type_for_die_p?
How about overrid
Richard Sandiford writes:
> [This follows on from:
> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html
> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01456.html]
>
> At the moment we rely on SYMBOL_REF_DECL to get the ABI of the callee
> of a call insn, falling back to the default ABI if
Optimizing gcc.dg/torture/pr41094.c, the compiler computes the
constant value and short-circuits the whole thing. At -O0, however,
on 32-bit x86, the call to pow() remains, and the program compares the
returned value in a stack register, with excess precision, with the
exact return value expected
flag_omit_frame_pointer is set in machine-independent code depending
on the optimization level. It is then overridden in x86
target-specific code depending on a macro defined by
--enable-frame-pointer.
Uses of attribute optimize go through machine-independent overriding
of flag_omit_frame_pointer
On 30/09/19 22:31 +0200, François Dumont wrote:
This is a missing part of C++20 P1023 for __debug::array.
Implement C++20 p1023 - constexpr comparison operators for
__debug::array.
* include/debug/array: Add C++20 constexpr to comparison operators.
* testsuite/23_containers/array/t
The regrename pass temporarily changes some operand RTL to CC0 so that
note_stores and scan_rtx don't see those operands. CC0 is deprecated
and we want to remove it, so we need to use something else here.
PC fits the bill fine.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
Seg
Segher Boessenkool writes:
> The regrename pass temporarily changes some operand RTL to CC0 so that
> note_stores and scan_rtx don't see those operands. CC0 is deprecated
> and we want to remove it, so we need to use something else here.
> PC fits the bill fine.
>
> Tested on powerpc64-linux {-m3
On Tue, Oct 1, 2019 at 10:59 AM Alexandre Oliva wrote:
>
> flag_omit_frame_pointer is set in machine-independent code depending
> on the optimization level. It is then overridden in x86
> target-specific code depending on a macro defined by
> --enable-frame-pointer.
>
> Uses of attribute optimize
2019-10-01 Frederik Harwath
* MAINTAINERS: Add myself to Write After Approval
Index: ChangeLog
===
--- ChangeLog (revision 276390)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-10-01 Frederik Harwath
+
+ *
Martin Jambor writes:
> Hi,
>
> On Mon, Sep 30 2019, Andrea Corallo wrote:
>> Hi all,
>> I'd like to submit this patch.
>> It release the ipa cp transformation summary after functions being expanded.
>> This is to fix the compiler when used with libgccjit on subsequent
>> compilations (every new
On Wed, Sep 25, 2019 at 5:48 PM Richard Sandiford
wrote:
> > The comment suggests that this code is only needed for Win64 and that
> > not testing for Win64 is just a simplification. But in practice it was
> > needed for correctness on GNU/Linux and other targets too, since without
> > it the RA
> From: Richard Sandiford
> Date: Tue, 1 Oct 2019 09:51:51 +0200
> Hans-Peter Nilsson writes:
> > My autotester for cris-elf complains about a build-breaking
> > commit in the revision range (working:breaking) 276299:276359
> Fixed as below. I also belatedly see a new definition of
> HARD_REGN
[Thanks for the quick review and sorry for the longish delay]
> +/* Return the index number of the landing pad for STMT, if any. */
> +
> +static int
> +lp_nr_for_store (gimple *stmt)
> +{
> + if (!cfun->can_throw_non_call_exceptions || !cfun->eh)
> +return 0;
> +
> + if (!stmt_could_throw_
On Tue, Oct 1, 2019 at 10:51 AM Alexandre Oliva wrote:
>
> On Sep 26, 2019, Richard Biener wrote:
>
> > On Thu, Sep 26, 2019 at 4:05 AM Alexandre Oliva wrote:
>
> > Heh, I don't have one - which usually makes me simply inline the
> > beast into the single caller :P
>
> > Maybe simply have_new_ty
Hi all,
Currently SLP vectorization can build SLP trees starting from reductions or
from group stores. This patch adds a third starting point: vector constructors.
For the following aarch64 test case (compiled with -O3 -fno-vect-cost-model):
char g_d[1024], g_s1[1024], g_s2[1024];
void test_
On Tue, Oct 1, 2019 at 10:56 AM Alexandre Oliva wrote:
>
> Optimizing gcc.dg/torture/pr41094.c, the compiler computes the
> constant value and short-circuits the whole thing. At -O0, however,
> on 32-bit x86, the call to pow() remains, and the program compares the
> returned value in a stack regi
On 01/10/2019 12:07, Joel wrote:
>
> SLP vectorization: vectorize vector constructors
>
>
> Currently SLP vectorization can build SLP trees staring from
> reductions or from group stores. This patch adds a third starting
> point: vector constructors.
>
>
> For the following test case (compiled wi
On Tue, Oct 1, 2019 at 1:05 PM Eric Botcazou wrote:
>
> [Thanks for the quick review and sorry for the longish delay]
>
> > +/* Return the index number of the landing pad for STMT, if any. */
> > +
> > +static int
> > +lp_nr_for_store (gimple *stmt)
> > +{
> > + if (!cfun->can_throw_non_call_exc
Happened to test this separately.
Committed.
Richard.
2019-10-01 Richard Biener
* tree-vect-loop.c (vectorizable_reduction): Move variables
to where they are used.
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-
On 30/09/19 22:21 +0200, François Dumont wrote:
On 9/30/19 11:03 AM, Jonathan Wakely wrote:
These changes are fine but should have been a separate, unrelated
commit.
Ok, sorry, I consider that just a comment change was fine.
It's fine, but it is unrelated so should be a separate commit. That
Hi All,
This adds a framework to allow pattern matchers to be written at based on the
SLP tree. The difference between this one and the one in tree-vect-patterns is
that this matcher allows the matching of an arbitrary number of parallel
statements and replacing of an arbitrary number of children
Hi All,
This patch adds pattern detections for the following operations:
1) Addition with rotation of the second argument around the Argand plane.
Supported rotations are 90 and 180.
c = a + (b * I) and c = a + (b * I * I)
2) Complex multiplication and Conjucate Complex multiplicatio
On Tue, Oct 01, 2019 at 10:18:37AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> It's mentioned by name later too:
>
> /* Step 2: Mark chains for which we have reads outside operands
>as unrenamable.
>We do this by munging all operands into CC0, an
On Tue, 1 Oct 2019, Joel Hutton wrote:
> On 01/10/2019 12:07, Joel wrote:
> >
> > SLP vectorization: vectorize vector constructors
> >
> >
> > Currently SLP vectorization can build SLP trees staring from
> > reductions or from group stores. This patch adds a third starting
> > point: vector cons
Hi Richard,
I updated patch according to all your comments.
Also bootstrapped and tested again on x86_64-pc-linux-gnu and
aarch64-linux-gnu, which took some time.
attached v3.
Thanks,
Dmitrij
On Thu, Sep 26, 2019 at 09:47:04AM +0200, Richard Biener wrote:
> On Tue, Sep 24, 2019 at 5:29 PM Dmit
On 2019/9/24 6:43 PM, Chung-Lin Tang wrote:
--- gcc/config/nvptx/nvptx.c(revision 275493)
+++ gcc/config/nvptx/nvptx.c(working copy)
+static void
+nvptx_expand_to_rtl_hook (void)
+{
+ /* For utilizing CUDA .param kernel arguments, we detect and modify
+ the gimple of offloaded chi
The code was passing a pseudo rather than its allocated hard reg
to ira_need_caller_save_p. Running under valgrind to reproduce
the failure also showed that ALLOCNO_CROSSED_CALLS_ABIS wasn't
being explicitly initialised.
Tested on aarch64-linux-gnu and cross-tested against the testcase
on cris-el
On Oct 1, 2019, at 5:14 AM, Segher Boessenkool
wrote:
>
> The regrename pass temporarily changes some operand RTL to CC0 so that
> note_stores and scan_rtx don't see those operands. CC0 is deprecated
> and we want to remove it, so we need to use something else here.
> PC fits the bill fine.
CC
Bootstrapped and regtested on s390x-redhat-linux, x86_64-redhat-linux,
ppc64le-redhat-linux.
This patch series adds signaling FP comparison support (both scalar and
vector) to s390 backend.
Patches 1-3 make it possible to query supported vcond rtxes and make
use of that for z13.
Patches 4-5 are
z13 supports only non-signaling vector comparisons. This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify
middle-end about this by using more restrictive operator predicate in
vcond.
gcc/ChangeLog:
2019-08-21 Ilya Leoshkevich
PR target/77918
*
Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
and introduces a temporary if this could happen, for example, generating
_5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
_6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
from GENERIC
VEC_COND_EXPR < (*b > { 2.0
s390.md uses a lot of near-identical expanders that perform dispatching
to other expanders based on operand types. Since the following patch
would require even more of these, avoid copy-pasting the code by
generating these expanders using an iterator.
gcc/ChangeLog:
2019-08-09 Ilya Leoshkevich
z13 supports only non-signaling vector comparisons. This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
However, we cannot express this restriction today: the code only checks
whether vcond$a$b optab exists, which does not contain information about
the operation.
Introd
dg-torture.exp=inf-compare-1.c is failing, because (qNaN > +Inf)
comparison is compiled to CDB instruction, which does not signal an
invalid operation exception. KDB should have been used instead.
This patch introduces a new CCmode and a new pattern in order to
generate signaling instructions in t
Currently gcc does not emit wf{c,k}* instructions when comparing long
double values. Middle-end actually adds them in the first place, but
then veclower pass replaces them with floating point register pair
operations, because the corresponding expander is missing.
gcc/ChangeLog:
2019-08-09 Ilya
gcc/testsuite/ChangeLog:
2019-08-09 Ilya Leoshkevich
PR target/77918
* gcc.target/s390/s390.exp: Enable Fortran tests.
* gcc.target/s390/zvector/autovec-double-quiet-eq.c: New test.
* gcc.target/s390/zvector/autovec-double-quiet-ge.c: New test.
* gcc.tar
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> Currently gcc does not emit wf{c,k}* instructions when comparing long
> double values. Middle-end actually adds them in the first place, but
> then veclower pass replaces them with floating point register pair
> operations, because the corresponding exp
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> s390.md uses a lot of near-identical expanders that perform dispatching
> to other expanders based on operand types. Since the following patch
> would require even more of these, avoid copy-pasting the code by
> generating these expanders using an iterat
Paul Koning writes:
> On Oct 1, 2019, at 5:14 AM, Segher Boessenkool
> wrote:
>>
>> The regrename pass temporarily changes some operand RTL to CC0 so that
>> note_stores and scan_rtx don't see those operands. CC0 is deprecated
>> and we want to remove it, so we need to use something else here.
> Am 02.07.2019 um 17:34 schrieb Ilya Leoshkevich :
>
> Bootstrap and regtest running on x86_64-redhat-linux, s390x-redhat-linux
> and ppc64le-redhat-linux.
>
> Currently s390 emits the following sequence to store a frame_pc:
>
> a:
> .LASANPC0:
>
> lg %r1,.L5-.L4
Hi all,
[For those who got it twice, I actually forget to include the mailing
lists in the first round. Ups.]
this patch fixes the bug that with "optional" the wrong pointer is used
with "use_device_ptr"; the bug is already observable without doing
actual offloading.
Namely, "present(ptr)"
Hi,
The attached patch fixes PR 88562.
Tested on trunk with
make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb}"
Committed to trunk, GCC 9, GCC 8, GCC 7 as r276411, r276412, r276413, r276414.
Cheers,
Oleg
gcc/ChangeLog:
PR target/88562
On 9/29/19 6:11 AM, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE, because check_alignment_of_packed_member
is called on the decltype expressions and the aggregate has not been laid
out.
The following patch fixes it by not emitting warnings on fields that weren't
laid out yet.
Boot
> * ipa-inline.c (want_early_inline_function_p): Use
> PARAM_EARLY_INLINING_INSNS_O2.
> * params.def (PARAM_EARLY_INLINING_INSNS_O2): New.
> (PARAM_EARLY_INLINING_INSNS): Update documentation.
> * invoke.texi (early-inlining-insns-O2): New.
> (early-inlining-insn
Hi,
The attached patch is committed to trunk after bootstrap+test on
x86_64-unknown-linux-gnu.
Pre-approved by Richard.
Thanks,
Prathamesh
Index: ChangeLog
===
--- ChangeLog (revision 276416)
+++ ChangeLog (working copy)
@@ -1,3 +1,8
Attached is an implementation of the __has_builtin special
preprocessor operator/macro analogous to __has_attribute and
(hopefully) compatible with the synonymous Clang feature (I
couldn't actually find tests for it in the Clang test suite
but if someone points me at them I'll verify it).
Tested
On Tue, Oct 01, 2019 at 11:16:10AM -0600, Martin Sebor wrote:
> Attached is an implementation of the __has_builtin special
> preprocessor operator/macro analogous to __has_attribute and
> (hopefully) compatible with the synonymous Clang feature (I
> couldn't actually find tests for it in the Clang
On 10/1/19 11:11 AM, Aldy Hernandez wrote:
> Hi folks.
>
> Here is my official submission of the range-ops part of the ranger to
> mainline.
>
> I realize that I could have split this patch up into 2-3 separate ones,
> but I don't want to run into the chicken-and-egg scenario of last time,
> wher
On 10/1/19 11:38 AM, Jakub Jelinek wrote:
On Tue, Oct 01, 2019 at 11:16:10AM -0600, Martin Sebor wrote:
Attached is an implementation of the __has_builtin special
preprocessor operator/macro analogous to __has_attribute and
(hopefully) compatible with the synonymous Clang feature (I
couldn't act
Hi,
sorry for taking so long to get to this. This patch fixes the ICE which
happens when we try to output warning about anonymous type.
As Jason explains in the PR log the warning is correct and I think we
should warn at compile time when parsing
$ cat 2.ii
extern "C" {
struct {
} admbaserest_;
}
On 10/1/19 1:39 PM, Tamar Christina wrote:
The patterns work by looking at the sequence produced after GCC lowers complex
numbers. As such they would match any normal operation that does the same
computations.
Thanks - I didn't understand Ramana's comments during the GNU Tools
Cauldron about
For some reason, presumably historical, the `install-gnatlib' target for
the default multilib is invoked twice, once via the `ada.install-common'
target in `gcc/ada/gcc-interface/Make-lang.in' invoked from gcc/ and
again via the `install-libada' target in libada/.
Apart from doing the same twic
On 10/1/19 3:34 AM, Richard Biener wrote:
On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill wrote:
My comments accidentally got lost.
Several places in the front-end (and elsewhere) use the same lazy
allocation pattern for hash_maps, and this patch replaces them with
hash_map_safe_* functions lik
Hi,
I am currently trying to implement -Wshadow=local, and
this patch triggers a build-failure with -Wshadow=local
since i is a parameter that is the regno.
But it is also used as loop variable,
so I think this introduces probably a bug:
> @@ -728,7 +731,11 @@ globalize_reg (tree decl, int i)
>
On Fri, 27 Sep 2019, Arnaud Charlet wrote:
> > Shall I amend the change description anyhow then? I know it has not (as
> > yet, as discussed at the GNU Tools Cauldron recently) been enforced for
> > the GCC project (unlike with e.g. glibc), however I mean to use it whole
> > as the commit mes
On 9/30/19 2:45 PM, co...@sdf.org wrote:
> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
>> Yes, the patch is mostly ok. You can commit it into the trunk after
>> applying changes mentioned below. If you do not have a write access, let me
>> know I'll commit the patch by myself
On 9/6/19 4:23 AM, Dragan Mladjenovic wrote:
> On 24.07.2019. 20:57, Jeff Law wrote:
>> On 7/17/19 2:29 AM, Dragan Mladjenovic wrote:
>>>
>>>
>>> On 09.07.2019. 23:21, Jeff Law wrote:
On 7/9/19 2:06 PM, Dragan Mladjenovic wrote:
> This patch prevents merging of CALL instructions that that
On 9/25/19 1:16 AM, Dragan Mladjenovic wrote:
> From: "Dragan Mladjenovic"
>
> This fixes the issue by checking that addr's base reg is not part of dest
> multiword reg instead just checking the first reg of dest.
>
> gcc/ChangeLog:
>
> 2019-09-25 Dragan Mladjenovic
>
> PR target/9176
On 10/1/19 12:40 AM, Richard Biener wrote:
> On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
>
>> On Wed, 25 Sep 2019 at 23:44, Richard Biener wrote:
>>>
>>> On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
>>>
On Fri, 20 Sep 2019 at 15:20, Jeff Law wrote:
>
> On 9/19/19 10:19 AM, Pr
On 9/18/19 2:04 AM, Martin Liška wrote:
> PING^4
>
> Just note that the author of the JSON implementation
> in GCC is fine with the patch ;)
OK if this is still pending :-)
jeff
On 9/13/19 12:16 PM, Janne Blomqvist wrote:
> On Fri, Sep 13, 2019 at 1:07 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> this fixes a test case where a short string constant is put in a larger
>> memory object.
>>
>> The consistency check in varasm.c is failed because both types should agree.
>>
>>
Regenerate `liboffloadmic/plugin/configure' for r275564 ("[ARM/FDPIC v6
02/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure
scripts") too.
liboffloadmic/
* plugin/configure: Regenerate.
---
On Sun, 29 Sep 2019, Christophe Lyon wrote:
> > A change made with r275564 ("
On 9/27/19 1:24 PM, Jonathan Wakely wrote:
On 20/09/19 07:08 +0200, François Dumont wrote:
I already realized that previous patch will be too controversial to
be accepted.
In this new version I just implement a real memmove in __memmove so
A real memmove doesn't just work backwards, it need
On 9/28/19 8:14 PM, Oleg Endo wrote:
> Hi,
>
> I've been dragging this patch along with me for a while.
> At the moment, I don't have the resources to fully test it as requested
> by Ian in the PR discussion.
>
> So I would like to ask for general comments on this one and hope that
> folks with b
On 10/1/19 4:11 AM, Andrea Corallo wrote:
> Martin Jambor writes:
>
>> Hi,
>>
>> On Mon, Sep 30 2019, Andrea Corallo wrote:
>>> Hi all,
>>> I'd like to submit this patch.
>>> It release the ipa cp transformation summary after functions being expanded.
>>> This is to fix the compiler when used with
* include/parallel/algo.h: Replace non-reserved names.
* include/parallel/multiway_merge.h: Likewise.
* include/parallel/multiway_mergesort.h: Likewise.
* include/parallel/numericfwd.h: Likewise.
* testsuite/17_intro/names.cc: Add RAI to test macros.
Tested
Tested x86_64-linux (normal and parallel modes), committed to trunk.
commit b11c8f480fe1cd5696ec1a8f0db481c5f45429b8
Author: Jonathan Wakely
Date: Tue Oct 1 20:31:51 2019 +0100
Disable tests that aren't valid in parallel mode
Tests that depend on debug mode can't be tested in para
Tested x86_64-linux (normal and parallel modes), committed to trunk.
Most algos still aren't constexpr in parallel mode, this just fixes
the ones needed by std::array.
commit 9b07c6cfd553566a3ebdbab72b12e007d4912bf1
Author: Jonathan Wakely
Date: Tue Oct 1 20:33:08 2019 +0100
Make some p
Tested x86_64-linux (normal and parallel modes), committed to trunk.
commit 92d5df45f3e62d31bebcdea9c1568b0877d0fe0e
Author: Jonathan Wakely
Date: Tue Oct 1 20:34:22 2019 +0100
Make some new algorithms work in parallel mode
* include/experimental/algorithm (experimental::
On 9/30/19 3:30 AM, Martin Jambor wrote:
> Hi,
>
> when looking into PR 70929 and thus looking at what
> gimple_check_call_matching_types and gimple_check_call_args (both in
> cgraph.c) do, I noticed that they get invoked a lot when cloning cgraph
> edges when code is being copied as part of inlin
On 9/27/19 12:23 PM, Aaron Sawdey wrote:
> This is the third piece of my effort to improve inline expansion of memmove.
> The
> first two parts I posted back in June fixed the names of the optab entries
> involved so that optab cpymem is used for memcpy() and optab movmem is used
> for
> memmove(
On Wed, 2 Oct 2019 at 01:08, Jeff Law wrote:
>
> On 10/1/19 12:40 AM, Richard Biener wrote:
> > On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
> >
> >> On Wed, 25 Sep 2019 at 23:44, Richard Biener wrote:
> >>>
> >>> On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
> >>>
> On Fri, 20 Sep 2019
On 9/27/19 4:31 PM, Jakub Jelinek wrote:
Hi!
The following patch attempts to implement P0784R7, which includes constexpr
destructors and constexpr new/delete/new[]/delete[].
::operator new is allowed during constexpr evaluation and returns address of
an artificial VAR_DECL with special name. A
Previously, diagnostic_show_locus saved and restored the pretty_printer's
prefix, clearing it for the duration of the call.
I have a patch kit in development that can benefit from applying a prefix
to the output of d_s_l, so this patch adds support to d_s_l for printing
such prefixes.
It moves th
Hi all,
my feeling is that %C locations are always off by one, e.g., showing the
(1) under the last white-space character before the place where the
error occurred – the match starts at the character after the
gfc_current_location.
That bothered my for a while – but today, I was wondering wh
On Tue, Oct 01, 2019 at 07:58:37PM +, Bernd Edlinger wrote:
> On 9/13/19 12:16 PM, Janne Blomqvist wrote:
> > On Fri, Sep 13, 2019 at 1:07 PM Bernd Edlinger
> > wrote:
> >>
> >> Hi,
> >>
> >> this fixes a test case where a short string constant is put in a larger
> >> memory object.
> >>
> >>
One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html
was to strengthen the sanity check in lra_assigns so that it checks
whether reg_renumber is consistent with the whole conflict set.
This duly tripped on csky for a pseudo that had been allocated
to the eliminated frame pointer.
On 10/1/19 4:39 PM, Richard Sandiford wrote:
> One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html
> was to strengthen the sanity check in lra_assigns so that it checks
> whether reg_renumber is consistent with the whole conflict set.
> This duly tripped on csky for a pseudo that
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
If an inquiry parameter cannot appear in a file IO statement
as a tag (see new testcase). The patch re-arranges the code
to prevent an ICE due to 'result->symtree = NULL;', checks
for a constant in a variable definition context
The attached patch has been tested on x86_64-*-freebsd.
OK to commmit?
In a previous patch, I specialized the simplfication of
an EXPR_OP to the case of an inserted parenthesis. This
was too restrictive as evidenced by the new test case.
The patch simply does a simplification of an expression.
Hi Mike,
On Mon, Sep 30, 2019 at 10:12:54AM -0400, Michael Meissner wrote:
> I needed
> to add a second memory constraint ('eM') that prevents using a prefixed
> address.
Do we need both em and eM? Do we ever want to allow prefixed insns but not
pcrel? Or, alternatively, this only uses eM for s
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
The patch prevents an ICE by setting the locus of an
inquiry parameter.
2019-10-01 Steven G. Kargl Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (re
As part of adding [[]]-style attributes, C2x adds the token :: for use
in scoped attribute names.
This patch adds corresponding support for that token in C to GCC. The
token is supported both for C2x and for older gnu* standards (on the
basis that extensions are normally supported in older gnu* v
On 10/1/19 4:10 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
OK Steve, thanks,
Jerry
On 10/1/19 4:46 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commmit?
OK, thanks Steve.
In a previous patch, I specialized the simplfication of
an EXPR_OP to the case of an inserted parenthesis. This
was too restrictive as evidenced by the new test ca
On 10/1/19 5:06 PM, Steve Kargl wrote:
The attached patch has been tested on x86_64-*-freebsd.
OK to commit?
Ok Steve,
Thanks,
Jerry
The patch prevents an ICE by setting the locus of an
inquiry parameter.
2019-10-01 Steven G. Kargl
On Tue, 1 Oct 2019, Jeff Law wrote:
> On 10/1/19 12:40 AM, Richard Biener wrote:
> > On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
> >
> >> On Wed, 25 Sep 2019 at 23:44, Richard Biener wrote:
> >>>
> >>> On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
> >>>
> On Fri, 20 Sep 2019 at 15:20,
On Wed, 2 Oct 2019, Prathamesh Kulkarni wrote:
> On Wed, 2 Oct 2019 at 01:08, Jeff Law wrote:
> >
> > On 10/1/19 12:40 AM, Richard Biener wrote:
> > > On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
> > >
> > >> On Wed, 25 Sep 2019 at 23:44, Richard Biener wrote:
> > >>>
> > >>> On Wed, 25 Sep 2
93 matches
Mail list logo
