On Mon, Oct 14, 2019 at 03:24:02PM -0700, Prathamesh Kulkarni wrote:
> The patch fixes this by simply putting gsi_next in else, which avoids
> the above issue.
> Bootstrap+test in progress on x86_64-unknown-linux-gnu.
> OK to commit if passes ?
No ChangeLog entry.
--- a/gcc/tree-if-conv.c
+++ b/g
Thanks for all your reviews and comments, very helpful!
Peter Bergner writes:
> I think we just need to fix the bug in the current logic when checking
> whether the caller's ISA flags supports the callee's ISA flags. ...and
> for that, I think we just need to add a test that enforces that the
On Wed, 9 Oct 2019 at 08:14, Prathamesh Kulkarni
wrote:
>
> On Tue, 8 Oct 2019 at 13:21, Richard Sandiford
> wrote:
> >
> > Leaving the main review to Richard, just some comments...
> >
> > Prathamesh Kulkarni writes:
> > > @@ -9774,6 +9777,10 @@ vect_is_simple_cond (tree cond, vec_info *vinfo,
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00570.html
On 10/8/19 5:51 PM, Martin Sebor wrote:
Attached is a resubmission of the -Wrestrict implementation for
the sprintf family of functions. The original patch was posted
in 2017 but never approved. This revision makes only a few minor
When a subsequent element or member of a local aggregate containing
a prior character array is initialized the strlen pass discards
the length it computed for the prior element/member. E.g., here:
struct { char a[4], b[4]; } s = { "1", "12" };
even though strlen (s.b) is folded to 2, strlen (
On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
>> The general case should be that if the caller ISA supports the callee one
>> then inlining is OK. If this is not wanted in some cases then there are
>> options like using a noinline a
The C2x attribute syntax, [[ ]], appears in different places in the
syntax from GNU __attribute__, and, where they can appear in the same
place in the syntax, they do not always appertain to the same entity.
(For example, in "int func(void) ATTRS;", GNU attributes appertain to
the declaration but C
On Mon, 14 Oct 2019, Martin Sebor wrote:
> On 10/14/19 4:03 PM, Joseph Myers wrote:
> > How does this interact with translation?
> >
> > My expectation would be that in user code, the message is taken literally
> > as-is; it is not looked up in the GCC message catalog even if it is
> > identical
On 10/14/19 4:03 PM, Joseph Myers wrote:
How does this interact with translation?
My expectation would be that in user code, the message is taken literally
as-is; it is not looked up in the GCC message catalog even if it is
identical to some GCC diagnostic. However, when used internally for GCC
This Go frontend patch by Than McIntosh is an addendum to the fix for
issue https://golang.org/issue/34577
(,https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00366.html) which was
not sufficiently general. During export data processing, when looking
at the types of constants mentioned in inlinable fu
On Mon, Oct 14, 2019 at 05:16:03PM -0400, Michael Meissner wrote:
> On Fri, Oct 11, 2019 at 04:17:02PM -0500, Segher Boessenkool wrote:
> > > * config/rs6000/predicates.md (lwa_operand): Allow using PLWA to
> > > generate sign extend with odd offsets.
> >
> > I don't understand what this means
Hi,
The issue with PR91532 patch was in following hunk in ifcvt_local_dce:
if (dse_classify_store (&write, stmt, false, NULL, NULL, latch_vdef)
== DSE_STORE_DEAD)
delete_dead_or_redundant_assignment (&gsi, "dead");
gsi_next (&gsi);
continue;
On Mon, Oct 14, 2019 at 05:12:56PM -0400, Michael Meissner wrote:
> On Thu, Oct 10, 2019 at 05:02:09PM -0500, Segher Boessenkool wrote:
> > > @@ -7786,8 +7790,12 @@ (define_insn_and_split "*movtd_64bit_nod
> > >"#"
> > >"&& reload_completed"
> > >[(pc)]
> > > -{ rs6000_split_multireg_mo
How does this interact with translation?
My expectation would be that in user code, the message is taken literally
as-is; it is not looked up in the GCC message catalog even if it is
identical to some GCC diagnostic. However, when used internally for GCC
diagnostics, they should be translated,
Committed, with that nitch, r276972.
OK with a minor nit. — Thanks for the patch.
Thanks a lot for the review!
Regards
Thomas
Matthias Klose noted that on less powerful targets, a link might take more
than 5 minutes; he mentions a figure of 3 hours for an LTO link. So this
patch changes the timeout to a check for whether the locking process still
exists.
Alex, you had a lot of helpful comments when I first wrote this, a
On Fri, Oct 11, 2019 at 04:44:51PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 09, 2019 at 04:22:06PM -0400, Michael Meissner wrote:
> > This patch allows -fstack-protect to work with large stack frames.
>
> I don't understand; please explain.
>
> What I see is a workaround for not properly ha
On Fri, Oct 11, 2019 at 04:53:23PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Oct 09, 2019 at 04:26:20PM -0400, Michael Meissner wrote:
> > --- gcc/config/rs6000/vsx.md(revision 276713)
> > +++ gcc/config/rs6000/vsx.md(working copy)
> > @@ -1149,10 +1149,14 @@ (define_insn
On 10/7/19 8:42 PM, Alexandre Oliva wrote:
> Some x86 tests of stack realignment, that disaligned the stack with
> pushes and pops, failed when the compiler was configured to tune for a
> target that preferred to accumulate outgoing arguments: the stack
> space is reserved before the asm push, the
On 10/8/19 4:39 AM, Jozef Lawrynowicz wrote:
> This patch has the functional changes to optimize zero_extend insns and
> pointer
> manipulation in the large memory model.
>
>
> 0002-MSP430-PSImode-pointer-manipulation-and-zero-extend-.patch
>
> From f8156e115c4743ce94a86835ffa5601b6d28a555 Mon
On 10/8/19 4:36 AM, Jozef Lawrynowicz wrote:
> This is an "obvious" mechanical patch which just reorders and groups the
> zero_extend insns in msp430.md, in preparation for the next functional patch.
>
>
> 0001-MSP430-Reorder-and-group-zero_extend-insns-in-msp430.patch
>
> From 8810aa7a19569d7e4
On 10/8/19 4:34 AM, Jozef Lawrynowicz wrote:
> In the large memory model, MSP430 instructions have some useful properties
> when
> performing byte, word or address-word writes to registers or memory:
> - Byte-writes to registers clear bits 19:8
> - Word-writes to registers clear bits 19:16
> - PSI
On Fri, Oct 11, 2019 at 04:17:02PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 09, 2019 at 04:07:50PM -0400, Michael Meissner wrote:
> > It also adds two new predicates that disallow prefixed memory that will
> > used in
> > patches #5 and #7.
>
> Then you should have really introduced them in
On 10/10/19 3:14 AM, co...@sdf.org wrote:
> On Thu, Oct 10, 2019 at 09:41:35AM +0100, Maciej W. Rozycki wrote:
>> On Wed, 9 Oct 2019, co...@sdf.org wrote:
>>
>>> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
>>> b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
>>> new file mode 100
On Thu, Oct 10, 2019 at 05:02:09PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 09, 2019 at 03:56:01PM -0400, Michael Meissner wrote:
> > This patch fixes the prefixed and non-prefixed instruction sizes for the
> > 128-bit types that aren't loaded into 128-bit vectors (TDmode, TFmode,
> > IFmode
On 10/10/19 4:40 AM, Joel Hutton wrote:
> Hi all,
>
> I noticed when reading the documentation that BREAK_FROM_IMM_USE_SAFE
> was removed at some point in 2006 and replaced with BREAK_FROM_IMM_USE_STMT.
>
>
> 2019-10-10 Joel Hutton joel.hut...@arm.com
>
> * doc/tree-ssa.texi: Update renam
On 10/10/19 5:08 AM, Mihailo Stojanovic wrote:
> This rejects vector constants from the constant pool, which removes
> unnecessary reloads of zero constant around function call in the test
> case.
>
> Tested with mips-mti-linux-gnu.
>
> gcc/ChangeLog:
>
> * config/mips/mips.c (mips_canno
Attached is a more fleshed out version of the built-in implemented
to run in a pass of its own. I did this in anticipation of looking
at the CFG to help eliminate false positives due to ASAN
instrumentation (e.g., PR 91707).
The built-in now handles a decent number of C and GCC formatting
direct
The comment for get_formal_tmp_var says that it shouldn't be used for
expressions whose value might change between initialization and use, and in
this case we're creating a temporary precisely because the value might
change, so we should use get_initialized_tmp_var instead.
I also noticed that man
Steve,
Brilliant! Yes, it's good to commit.
Thanks
Paul
On Mon, 14 Oct 2019 at 21:06, Steve Kargl
wrote:
>
> See attached patch. It includes my previous patch and
> patch to check for C1550. OK to commit?
>
> 2019-10-14 Steven G. Kargl
>
> PR fortran/89943
> decl.c (gfc_ma
On 10/14/19 7:30 AM, Jozef Lawrynowicz wrote:
> On Sun, 13 Oct 2019 10:22:31 -0600
> Jeff Law wrote:
>
>> On 10/7/19 2:28 PM, Jozef Lawrynowicz wrote:
>>> MSP430 supports post increment addressing for the source operand only. The
>>> attached patch enables post increment addressing for MSP430 in
The testcase was crashing because lazily_declare_fn was failing to add a
defaulted constructor, because the implicit declaration was less constrained
than the inherited default constructor. But when we have an inherited
constructor, we shouldn't be trying to declare a default constructor in the
fi
The same way I proposed to review std::copy overload for
istreambuf_iterator we can implement std::advance using pubseekoff.
It is both a cleaner implementation and avoids yet another friend
declaration.
* include/std/streambuf
(advance(istreambuf_iterator<>&, _Distance)): Remove fri
On 10/14/19 3:46 PM, Jeff Law wrote:
On 10/14/19 6:09 AM, Nathan Sidwell wrote:
On 10/14/19 7:16 AM, Richard Biener wrote:
On Sun, Oct 13, 2019 at 4:45 PM Nathan Sidwell wrote:
In constifying some more of line-map I discovered gengtype didn't
know mutable.
Added thusly.
mutable is bad. Wh
See attached patch. It includes my previous patch and
patch to check for C1550. OK to commit?
2019-10-14 Steven G. Kargl
PR fortran/89943
decl.c (gfc_match_function_decl): Ignore duplicate BIND(C) for function
declaration in submodule. Implement at check for F2018 C1
On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> The general case should be that if the caller ISA supports the callee one
> then inlining is OK. If this is not wanted in some cases then there are
> options like using a noinline attribute.
I agree, and that is what we already d
On Mon, Oct 14, 2019 at 10:31:58AM -0500, Peter Bergner wrote:
> I agree with your other comment that we should be looking at explicit option
> usage versus default options. However, the way we now implement default CPU,
> the gcc driver always passes a -mcpu= option to cc1 no matter if the user
>
On 10/14/19 6:09 AM, Nathan Sidwell wrote:
> On 10/14/19 7:16 AM, Richard Biener wrote:
>> On Sun, Oct 13, 2019 at 4:45 PM Nathan Sidwell wrote:
>>>
>>> In constifying some more of line-map I discovered gengtype didn't
>>> know mutable.
>>> Added thusly.
>>
>> mutable is bad. Why do you want to u
Improve some comments, replace some asserts that have been in the code
base for years with checking-asserts. Use unsigned ints for the picbase
counters.
tested on x86_64-darwin16,
applied to mainline,
Iain
gcc/ChangeLog:
2019-10-14 Iain Sandoe
* config/darwin.c: Use unsigned ints
Ping
To give a bit more rationale: some of the functions handled by
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01002.html operate
on structs and enums. There are already langhooks for creating the
necessary struct types, but there's no direct way of creating a
language-level enum.
One option
Ping
See also https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00413.html
for more details about why this seemed like a good idea. A shorter
version of that message (well, it started out that way :-)) is that
it lets us use:
#ifndef _ARM_SVE_H_
#define _ARM_SVE_H_
#include
typedef __fp16
On 10/14/19 12:38 PM, Richard Biener wrote:
On October 14, 2019 2:32:43 PM GMT+02:00, Richard Sandiford
wrote:
Richard Biener writes:
On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
wrote:
The range-tracking code has a pretty hard-coded assumption that
is_gimple_min_invariant is equi
On October 14, 2019 2:53:36 PM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On Fri, Oct 11, 2019 at 4:39 PM Richard Sandiford
>> wrote:
>>>
>>> This turned out to be useful for the SVE PCS support, and is a
>natural
>>> tree-level analogue of insn_callee_abi.
>>>
>>> Tested on
On October 14, 2019 2:32:43 PM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
>> wrote:
>>>
>>> The range-tracking code has a pretty hard-coded assumption that
>>> is_gimple_min_invariant is equivalent to "INTEGER_CST or invarian
On October 14, 2019 5:31:58 PM GMT+02:00, Peter Bergner
wrote:
>On 10/12/19 3:46 AM, Segher Boessenkool wrote:
>> Two spaces after a period. How about something like
>>
>> /* Callee's options should be a subset of the caller's. Also,
>a function
>> without VSX enabled should not be
Hi,
On Thu, 10 Oct 2019, David Malcolm wrote:
> This patch uses the support for pretty-printing escaped URLs added in
> the previous patch (PR 87488) so that in a sufficiently capable terminal
> the [-Wname-of-option] emitted at the end of each diagnostic becomes a
> hyperlink to the documenta
Wilco Dijkstra writes:
> Hi Richard,
>
>>> No - the testcases fail with that.
>>
>> Hmm, OK. Could you give more details? What does the motivating case
>> actually look like?
>
> Well it's now a very long time ago since I first posted this patch but the
> failure
> was in SPEC. It did something
On October 14, 2019 4:53:02 PM GMT+02:00, Christophe Lyon
wrote:
>On Fri, 11 Oct 2019 at 12:43, Richard Biener wrote:
>
>> On Fri, 11 Oct 2019, Rainer Orth wrote:
>>
>> > Hi Christophe,
>> >
>> > > On Thu, 10 Oct 2019 at 16:01, Richard Biener
>> wrote:
>> > >
>> > >>
>> > >> The following fixes
Hi Richard,
>> No - the testcases fail with that.
>
> Hmm, OK. Could you give more details? What does the motivating case
> actually look like?
Well it's now a very long time ago since I first posted this patch but the
failure
was in SPEC. It did something like &array[0xff000 - x], presuma
On 10/12/19 3:46 AM, Segher Boessenkool wrote:
> Two spaces after a period. How about something like
>
> /* Callee's options should be a subset of the caller's. Also, a
> function
>without VSX enabled should not be inlined into one with VSX enabled,
>because it may be impo
On Fri, 11 Oct 2019 at 12:43, Richard Biener wrote:
> On Fri, 11 Oct 2019, Rainer Orth wrote:
>
> > Hi Christophe,
> >
> > > On Thu, 10 Oct 2019 at 16:01, Richard Biener
> wrote:
> > >
> > >>
> > >> The following fixes a few param adjustments that are made based on
> > >> per-function adjustable
Hi,
This is a ping to the following patch.
Thanks,
Qing
> Begin forwarded message:
>
> From: Qing Zhao
> Subject: [PATCH][gcov-profile/91971]Profile directory concatenated with
> object file path
> Date: October 9, 2019 at 10:30:04 AM CDT
> To: hubi...@ucw.cz
> Cc: gcc-patches@gcc.gnu.org
>
On Mon, Oct 14, 2019 at 2:09 AM Andreas Krebbel wrote:
>
> 2019-10-14 Andreas Krebbel
>
> * libgo/go/runtime/os_linux_s390x.go: cpu.go, cpu_s390x.go,
> cpu.go, and cpu_linux_s390x.go expect the hardware facilities in
> capital letters. Sync this file accordingly. Add s
On Mon, Oct 14, 2019 at 2:09 AM Andreas Krebbel wrote:
>
> Since the update to Go 1.13beta1 the kdsaQuery function is expected to
> be present. However, it is not with GCCGO since the assembler file
> from GOLANG cannot be understood by gas. This patch adds an inline
> assembly implementation to
Hi,
On 10/13/19 5:41 PM, Thomas Koenig wrote:
OK, so here's the update. There was a problem with uninitialized
variables, which for some reason was not detected on compilation.
OK for trunk?
OK with a minor nit. — Thanks for the patch.
unsigned int do_not_warn : 1;
+
+ /* Set this if t
On Sun, 13 Oct 2019 10:22:31 -0600
Jeff Law wrote:
> On 10/7/19 2:28 PM, Jozef Lawrynowicz wrote:
> > MSP430 supports post increment addressing for the source operand only. The
> > attached patch enables post increment addressing for MSP430 in GCC.
> >
> > Regtested on trunk for the small and la
Two other params do similar scaling so fix them similarly.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-10-14 Richard Biener
PR middle-end/92046
* dse.c (scan_insn): Use param max_active_local_stores.
(dse_step1): Get PARAM_MAX_DSE_AC
This is a follow-up patch to the use_device_addr work. In particular, it
replaces the patch at https://gcc.gnu.org/ml/fortran/2019-09/msg00088.html
Fortran array descriptors need special handling, which this patch adds.
[The use_device-addr-{3,4} test cases are based on the
use_device_addr-{1,
On Thu, 10 Oct 2019 at 21:57, François Dumont wrote:
> I think this build has been done between the 2 commits I used to apply
> this patch (because of a problem between the chair and the keyboard). Now
> it should be fine.
>
Indeed the test passes since at least r 276644
Thanks
> But it shows t
Richard Biener writes:
> On Fri, Oct 11, 2019 at 4:39 PM Richard Sandiford
> wrote:
>>
>> This turned out to be useful for the SVE PCS support, and is a natural
>> tree-level analogue of insn_callee_abi.
>>
>> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>>
>> Richard
>>
>>
>
On 10/14/19 8:31 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 10/14/19 4:30 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 10/11/19 10:42 AM, Richard Sandiford wrote:
The range-tracking code has a pretty hard-coded assumption that
is_gimple_min_invariant is equivalent t
Richard Biener writes:
> On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
> wrote:
>>
>> The range-tracking code has a pretty hard-coded assumption that
>> is_gimple_min_invariant is equivalent to "INTEGER_CST or invariant
>> ADDR_EXPR". It seems better to add a predicate specifically for
>> th
Aldy Hernandez writes:
> On 10/14/19 4:30 AM, Richard Sandiford wrote:
>> Aldy Hernandez writes:
>>> On 10/11/19 10:42 AM, Richard Sandiford wrote:
The range-tracking code has a pretty hard-coded assumption that
is_gimple_min_invariant is equivalent to "INTEGER_CST or invariant
ADD
Hi Bernhard,
> Am 14.10.2019 um 11:58 schrieb Bernhard Reutner-Fischer
> :
>
> On 14 October 2019 10:50:55 CEST, Jakub Jelinek wrote:
>>> On Tue, Oct 08, 2019 at 02:04:17PM +0200, Tobias Burnus wrote:
>>>testsuite/
>>>* gfortran.dg/gomp/target-simd.f90: New.
>>
>> John Reporte in bugz
Let me try again to get this patch ready. It will need a few iterations...
This patch is without documentation and testsuite. I can add them on request
but would prefer a follow-up patch after getting this one right.
I recommend to review starting from simd.h + simd_scalar.h, then
simd_builtin.
On 10/14/19 7:16 AM, Richard Biener wrote:
On Sun, Oct 13, 2019 at 4:45 PM Nathan Sidwell wrote:
In constifying some more of line-map I discovered gengtype didn't know mutable.
Added thusly.
mutable is bad. Why do you want to use it?
the line map info has a caching field.
mutable is part
This fixes the PR by not setting vect_nested_cycle on the latch def
for nested cycles.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-14 Richard Biener
PR tree-optimization/92069
* tree-vect-loop.c (vect_analyze_scalar_cycles_1): For nested
On Fri, Oct 11, 2019 at 4:47 PM Richard Sandiford
wrote:
>
> r273783 introduced an unchecked use of tree_to_uhwi. This is
> tested by the SVE ACLE patches, but could potentially trigger
> in non-SVE cases too.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK.
Richard.
>
On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
wrote:
>
> The range-tracking code has a pretty hard-coded assumption that
> is_gimple_min_invariant is equivalent to "INTEGER_CST or invariant
> ADDR_EXPR". It seems better to add a predicate specifically for
> that rather than contiually fight c
On Fri, Oct 11, 2019 at 4:39 PM Richard Sandiford
wrote:
>
> This turned out to be useful for the SVE PCS support, and is a natural
> tree-level analogue of insn_callee_abi.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> Richard
>
>
> 2019-10-11 Richard Sandiford
>
>
On Sun, Oct 13, 2019 at 4:45 PM Nathan Sidwell wrote:
>
> In constifying some more of line-map I discovered gengtype didn't know
> mutable.
> Added thusly.
mutable is bad. Why do you want to use it?
> nathan
>
> --
> Nathan Sidwell
The following tries to improve debug info for PRE inserted expressions
by assigning them locations from any of the original expressions
involved. For simple cases where there exists a 1:1 match this
is "correct" while for more complex cases (like code-hoisting)
this will pick the location of any
This time with testcase. Is the subdir for the test ok?
gcc/ChangeLog:
2019-10-11 Matthias Kretz
* gcc/cp/parser.c (cp_parser_operator): Parse operator?: as an
attempt to overload the conditional operator. Then
grok_op_properties can print its useful "ISO C++ prohibits
On 14 October 2019 11:56:28 CEST, Tobias Burnus wrote:
>Hi Bernard,
>
>On 10/14/19 11:52 AM, Bernhard Reutner-Fischer wrote:
>>> Comitted as Rev. 276953 (+ 276955).
>
>The second commit (i.e "+" part) and the second attached patch (scroll
>
>to the last line of previous/that email) are there beca
On 10/14/19 4:30 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 10/11/19 10:42 AM, Richard Sandiford wrote:
The range-tracking code has a pretty hard-coded assumption that
is_gimple_min_invariant is equivalent to "INTEGER_CST or invariant
ADDR_EXPR". It seems better to add a predicate
On 14 October 2019 10:50:55 CEST, Jakub Jelinek wrote:
>On Tue, Oct 08, 2019 at 02:04:17PM +0200, Tobias Burnus wrote:
>> testsuite/
>> * gfortran.dg/gomp/target-simd.f90: New.
>
>John reported in bugzilla the testcase fails on hppa with an error that
>looks like heap corruption, and ind
Hi Bernard,
On 10/14/19 11:52 AM, Bernhard Reutner-Fischer wrote:
Comitted as Rev. 276953 (+ 276955).
The second commit (i.e "+" part) and the second attached patch (scroll
to the last line of previous/that email) are there because I saw the
following myself.
+++ b/gcc/fortran/error.c
@@
On 14 October 2019 10:34:37 CEST, Tobias Burnus wrote:
>In patch https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00092.html , I
>increased the error column location by one to point to the actual
>error.
>
>That works fine, except when the character is one before the end of the
>
>line (= '\0') – as
Since the update to Go 1.13beta1 the kdsaQuery function is expected to
be present. However, it is not with GCCGO since the assembler file
from GOLANG cannot be understood by gas. This patch adds an inline
assembly implementation to cpu_gccgo.c.
2019-10-14 Andreas Krebbel
* libgo/go/in
2019-10-14 Andreas Krebbel
* libgo/go/runtime/os_linux_s390x.go: cpu.go, cpu_s390x.go,
cpu.go, and cpu_linux_s390x.go expect the hardware facilities in
capital letters. Sync this file accordingly. Add support for the
VXE HWCAP as well.
---
libgo/go/runtime/os_
Hi,
On 12/10/19 00:28, Jakub Jelinek wrote:
@@ -10036,8 +10035,6 @@ compute_array_index_type_loc (location_t name_loc,
indicated by the state of complain), so that
another substitution can be found. */
return error_mark_node;
- else if (in_syste
On Tue, Oct 08, 2019 at 02:04:17PM +0200, Tobias Burnus wrote:
> testsuite/
> * gfortran.dg/gomp/target-simd.f90: New.
John reported in bugzilla the testcase fails on hppa with an error that
looks like heap corruption, and indeed, running the test under valgrind
fails on x86_64-linux t
On 10/10/19 7:37 PM, Gerald Pfeifer wrote:
On Thu, 10 Oct 2019, Kyrill Tkachov wrote:
Not sure whether this is supposed to be a living document or just a
record of what the mission statement was when egcs became GCC. The
date at the top is still 1999-04-22.
Ah, I hadn't considered that. Good
In patch https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00092.html , I
increased the error column location by one to point to the actual error.
That works fine, except when the character is one before the end of the
line (= '\0') – as the PR 92072 shows.
This patch checks for this and only inc
Aldy Hernandez writes:
> On 10/11/19 10:42 AM, Richard Sandiford wrote:
>> The range-tracking code has a pretty hard-coded assumption that
>> is_gimple_min_invariant is equivalent to "INTEGER_CST or invariant
>> ADDR_EXPR". It seems better to add a predicate specifically for
>> that rather than c
Hi!
in_reduction and task_reduction clauses need to be handled the same as
reduction clause.
Fixed thusly, tested on x86_64-linux, committed to trunk.
2019-10-14 Jakub Jelinek
PR c++/92084
* semantics.c (handle_omp_array_sections_1): Temporarily disable
-fstrong-eval-
On Freitag, 11. Oktober 2019 16:17:09 CEST Marek Polacek wrote:
> On Fri, Oct 11, 2019 at 04:06:43PM +0200, Matthias Kretz wrote:
> > This is a minor bugfix for improved error reporting. Overloading ?: is
> > just as disallowed as it is without this change.
>
> Thanks. Can you provide a testcase
87 matches
Mail list logo
