On 06/08/2017 04:08 AM, Rainer Orth wrote:
> The following patches have remained unreviewed for a week or more:
>
> [build] Support --sysroot with Solaris ld
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02342.html
>
> This needs a build maintainer unless one considers it obvious.
On 06/07/2017 02:07 AM, Bin.Cheng wrote:
> On Tue, Jun 6, 2017 at 6:47 PM, Jeff Law wrote:
>> On 06/02/2017 05:52 AM, Bin Cheng wrote:
>>> Hi,
>>> This patch enables -ftree-loop-distribution by default at -O3 and above
>>> optimization levels.
>>> Bootstrap and test at O2/O3 on x86_64 and AArch64
On 05/28/2017 06:31 AM, Segher Boessenkool wrote:
> __atomic_add_fetch adds a value to some memory, and returns the result.
> If there is no direct support for this, expand_builtin_atomic_fetch_op
> is asked to implement this as __atomic_fetch_add (which returns the
> original value of the mem), fo
On 05/23/2017 07:50 AM, Prathamesh Kulkarni wrote:
> Hi Jeff,
> As discussed in the other thread, this patch removes dead call to
> memset in free_hist().
> Bootstrap+tested on x86_64-unknown-linux-gnu.
> Cross-tested on arm*-*-*, aarch64*-*-*.
> OK for trunk ?
>
> Thanks,
> Prathamesh
>
>
> val
On 05/17/2017 12:33 AM, Uros Bizjak wrote:
> On Wed, May 17, 2017 at 4:45 AM, Hans-Peter Nilsson wrote:
>
>>> But yes, we definitely should document the final canonical ordering.
>>
>> Is that about to also happen?
>>
>> I foresee in another half-a-dozen years, and *this* iteration is
>> forgotte
On 05/16/2017 08:18 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> A tree type dump currently doesn't print the attributes. Since we have
> so many now and they do many interesting things dumping them can be
> useful. So dump them by default for tree type dumps.
>
> Passes bootstrap and testing on
On 05/08/2017 08:38 PM, Martin Sebor wrote:
> On 04/28/2017 12:35 PM, Jeff Law wrote:
>> On 04/26/2017 11:05 AM, Martin Sebor wrote:
>>> On 04/24/2017 03:35 PM, Jeff Law wrote:
On 04/11/2017 12:57 PM, Martin Sebor wrote:
> In a review of my fix for bug 80364 Jakub pointed out that to
>
On 05/04/2017 12:16 PM, David Malcolm wrote:
> As of r247522, fix-it-hints can suggest the insertion of new lines.
>
> This patch updates -Wimplicit-fallthrough to provide suggestions
> with fix-it hints, showing the user where to insert "break;" or
> fallthrough attributes.
>
> For example:
>
>
On 04/29/2017 01:06 AM, Bernd Edlinger wrote:
> On 04/28/17 20:46, Jeff Law wrote:
>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>> Yes I agree, that is probably not worth it. So I could try to remove
>>> the special handling of PIC+const and see what happens.
>>>
>>> However the SYMBOL_REF_FU
On 06/20/2017 04:28 AM, Andreas Schwab wrote:
> Tested on m68k, installed on trunk and gcc-7 branch.
>
> Andreas.
>
> PR target/80970
> * config/m68k/m68k.md (bsetdreg, bchgdreg, bclrdreg): Use "=d"
> instead of "+d".
Thanks for taking care of this. I've been buried in the land
he June 19th, 2017 change from Martin Liska , made the
target_clones support more usable, in that it it changed the external name from
being the default function to being the ifunc handler. This means that calls
from other modules will call the appropriate clone based on what machine it is
runnin
The %T format code in the C++ frontend gracefully handles being passed
a NULL type, printing nothing (and hence '' for %qT).
In r248698 (template type diff printing) I converted many uses of pairs
of %qT in the C++ FE to %qH and %qI.
PR c++/81167 reports a case where a NULL is passed to one of th
Currently the "make selftest" target run during each stage of the
build just runs the selftests within cc1.
As part of the fix for PR c++/81167 I want to be able to write
C++-specific selftests (to exercise the C++ implementation of
the pp's format_decoder).
Hence this patch generalizes the exist
Richard,
I reworked the patch and retested on big endian as well as little. The original
code was performing two swaps in the big endian case which works out to no
swaps at all.
I also updated the ChangeLog per your comments. Okay for trunk?
2017-06-19 Michael Collison
* config/aar
Jeff Law wrote:
> You can be in one of 3 states when you start the callee's prologue.
>
> 1. You're somewhere in the normal stack.
>
> 2. You've past the guard and are already in the heap or elsewhere
>
> 3. You're somewhere in the guard
>
> State #3 is what we're trying to address. The attacker h
Andreas Schwab noticed that the two tests for PR 80510 failed on 32-bit systems
due to long being only a 32-bit type.
Yesterday, I committed this patch to disable the test for 32-bit:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01607.html
This patch implements the necessary move and peephole su
This libgo patch uncomments a check. Now that systemstack changes to
the g0 stack, the check passes. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go
The CgocallbackDone function calls dropm after it calls entersyscall,
which means that dropm must not have any write barriers. Mark it
accordingly. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
This patch to libgo exports the getm function so that it can be
referenced by a test (from
runtime/testdata/testprogcgo/dropm_stub.go). The test is not
currently run, but it will be soon. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofronte
This patch moves about 1400 lines of code for various block and string
compare/move/zero expansions out of rs6000.c into a new file
rs6000-string.c. Segher had asked me to do this before I go adding new
code here.
Bootstrap passes on ppc64le, regtest in progress. OK for trunk if that
passes?
2
Ping #1
http://gcc.gnu.org/ml/gcc-patches/2017-06/msg01029.html
Georg-Johann Lay schrieb:
Hi,
Since PR71151 we have jump-tables in .text so that branches
crossing the tables have longer offsets that needed.
This moves jump-tables out of test again, but not into
.progmem.gcc_sw_tables like bef
* Jeff Law:
> But I still think we're going to want to explicitly test the various
> cases where we want to see probes vs when we do not. That kind of
> testing won't be covered unless we explicitly do so and the least
> painful way to cover may be via dump messages or the unit testing
> framewor
7;struct ia64_fpreg'
> struct ia64_fpreg {
> ^~
> In file included from /usr/include/signal.h:339:0,
> from
> /usr/local/gcc/gcc-20170622/Build/gcc/include-fixed/sys/ucontext.h:32,
> from /usr/include/ucontext.h:27,
>
On Thu, Jun 22, 2017 at 11:09 AM, Rainer Orth
wrote:
>
>> Because of how gccgo implements cgo calls, the code in dropm may not
>> have any write barriers. As a step toward implementing that, change
>> the gcstack, gcnextsegment, and gcnextsp fields of the g struct to
>> uintptr, so that assignmen
On 06/22/2017 12:23 PM, Florian Weimer wrote:
> * Mike Stump:
>
>> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>>
>>> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
>>> is compiled with -fstack-check. That isn't totally unexpected. I
>>> would have also been recepti
This patch starts cleaning up how we mark special identifiers. We
currently use some of the TREE_LANG_FLAGS on IDENTIFIER_NODEs for
various things, but most of those things are mutually exclusive, so an
enumeration is better -- it allows us to distinguish more things with
fewer bits. This pat
On Thu, Jun 22, 2017 at 08:42:54PM +0200, Richard Biener wrote:
> >The thought of scanning the assembly code or RTL is too painful to
> >contemplate. THus I've been pondering having the prologue expanders
> >emit notes into the dump file about what they did and why WRT probing.
> >
> >Or maybe we
On June 22, 2017 7:17:16 PM GMT+02:00, Jeff Law wrote:
>On 06/22/2017 11:07 AM, Jakub Jelinek wrote:
>> On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
>>> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
Sure. I'll do something with 20031023-1.c to ensure it or an
>equivalent
Hi all,
On 16 January 2017 at 16:34, Kyrill Tkachov wrote:
>
> On 13/01/17 16:35, James Greenhalgh wrote:
>>
>> On Wed, Jan 11, 2017 at 04:32:45PM +, Kyrill Tkachov wrote:
>>>
>>> Hi all,
>>>
>>> In this PR we generated ADRP/ADD instructions with :lo12: relocations on
>>> symbols even though
OK.
On Thu, Jun 22, 2017 at 2:00 PM, Martin Sebor wrote:
> By making use of STRIP_NOPS() on the destination of the memory
> function call, besides discarding the (implicit) conversion to
> void* the warning also strips any explicit casts that remove
> cv-qualifiers. This causes warnings that sho
* Mike Stump:
> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>
>> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
>> is compiled with -fstack-check. That isn't totally unexpected. I
>> would have also been receptive to adding -fstack-check to the torture flags.
>
> O
Hi Ian,
> Because of how gccgo implements cgo calls, the code in dropm may not
> have any write barriers. As a step toward implementing that, change
> the gcstack, gcnextsegment, and gcnextsp fields of the g struct to
> uintptr, so that assignments to them do not require write barriers.
> The gci
By making use of STRIP_NOPS() on the destination of the memory
function call, besides discarding the (implicit) conversion to
void* the warning also strips any explicit casts that remove
cv-qualifiers. This causes warnings that should otherwise be
suppressed, as pointed out in bug 81169.
The att
On Sun, Jun 18, 2017 at 10:56 AM, Uros Bizjak wrote:
> On Fri, Jun 16, 2017 at 11:42 PM, Matt Turner wrote:
>> Currently -march=native selects -march=broadwell on Kaby Lake systems,
>> since its model numbers are missing from the switch statement. It falls
>> back to the default case and chooses
On Jun 22, 2017, at 10:21 AM, Jeff Law wrote:
>
> This time with the test. Just #includes 20031023-1.c with a suitable dg
> directive to ensure we compile with -fstack-check.
>
> I won't be surprised if other targets fail this test. It's a really big
> stack frame :-)
The int16 people are goi
On Thu, Jun 22, 2017 at 11:21:15AM -0600, Jeff Law wrote:
> +2017-06-22 Jeff Law
> +
> + * gcc.c-torture/compile/stack-check-1.c: New test.
> +
> 2016-06-22 Richard Biener
>
> * gcc.dg/vect/pr65947-1.c: Remove xfail.
> diff --git a/gcc/testsuite/gcc.c-torture/compile/stack-check-
Hi Carl,
On Thu, Jun 22, 2017 at 09:04:38AM -0700, Carl Love wrote:
> Commit 249424 fixed the vec_mulo and vec_mule support however, the
> changes for the test case did not get included in the previous patch.
> The testing worked great for me as I had the fix. Not so good for
> everyone else as I
This time with the test. Just #includes 20031023-1.c with a suitable dg
directive to ensure we compile with -fstack-check.
I won't be surprised if other targets fail this test. It's a really big
stack frame :-)
Anyways, committed to the trunk.
Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
On 06/22/2017 11:07 AM, Jakub Jelinek wrote:
> On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
>> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>>
>>> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
>>> is compiled with -fstack-check. That isn't totally unexpe
On Thu, Jun 22, 2017 at 10:02 AM, Mike Stump wrote:
> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>>
>> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
>> is compiled with -fstack-check. That isn't totally unexpected. I
>> would have also been receptive to adding -fst
On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
> On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
> >
> > Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
> > is compiled with -fstack-check. That isn't totally unexpected. I
> > would have also been receptive to
On Jun 22, 2017, at 8:32 AM, Jeff Law wrote:
>
> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent
> is compiled with -fstack-check. That isn't totally unexpected. I
> would have also been receptive to adding -fstack-check to the torture flags.
Ouch. Though stack check
On 06/22/2017 06:16 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 06/20/2017 10:59 AM, Martin Sebor wrote:
On 06/20/2017 02:41 AM, Aldy Hernandez wrote:
On 05/23/2017 03:26 PM, Martin Sebor wrote:
On 05/23/2017 04:48 AM, Aldy Hernandez wrote:
+ void Union (wide_int x, wide_int y
On June 22, 2017 6:20:57 PM GMT+02:00, Alan Hayward
wrote:
>
>> On 22 Jun 2017, at 12:54, Richard Biener wrote:
>>
>> On Thu, 22 Jun 2017, Alan Hayward wrote:
>>
>>>
On 22 Jun 2017, at 09:52, Richard Biener wrote:
On Thu, 22 Jun 2017, Richard Biener wrote:
> On Wed,
On Thu, Jun 22, 2017 at 09:25:21AM -0300, Alexandre Oliva wrote:
> On Jun 8, 2017, Segher Boessenkool wrote:
>
> > Would it work to just have "else" instead if this "if"? Or hrm, we'll
> > need to kill the recorded reg_stat value in the last case before this
> > as well?
>
> The patch below (i
> On 22 Jun 2017, at 12:54, Richard Biener wrote:
>
> On Thu, 22 Jun 2017, Alan Hayward wrote:
>
>>
>>> On 22 Jun 2017, at 09:52, Richard Biener wrote:
>>>
>>> On Thu, 22 Jun 2017, Richard Biener wrote:
>>>
On Wed, 21 Jun 2017, Richard Biener wrote:
>
> During my attempt
On 06/22/2017 10:07 AM, Szabolcs Nagy wrote:
> On 22/06/17 16:30, Jeff Law wrote:
>> It just happens to be the case that x86 hits *sp when it stores the
>> return pointer and that ppc always stores the backchain into *sp when it
>> allocates additional stack space. As a result on those targets we
On 06/21/2017 11:47 AM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> I'm a little confused. I'm not defining or changing the ABI. I'm
>> working within my understanding of the existing aarch64 ABI used on
>> linux systems. My understanding after reading that ABI and the prologue
>> code for aar
On 22/06/17 16:30, Jeff Law wrote:
> It just happens to be the case that x86 hits *sp when it stores the
> return pointer and that ppc always stores the backchain into *sp when it
> allocates additional stack space. As a result on those targets we know
> the offset between the stack pointer and th
GCC Maintainers:
Commit 249424 fixed the vec_mulo and vec_mule support however, the
changes for the test case did not get included in the previous patch.
The testing worked great for me as I had the fix. Not so good for
everyone else as I didn't share the test case fix with mainline. Sorry
for t
On Thu, Jun 22, 2017 at 03:21:01AM -0300, Alexandre Oliva wrote:
> On Jun 8, 2017, Segher Boessenkool wrote:
>
> > [ I missed this patch the first time around; please cc: me to prevent this ]
>
> > On Thu, May 18, 2017 at 07:25:57AM -0300, Alexandre Oliva wrote:
> >> When an insn used by combin
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, Jun 22, 2017 at 12:58 PM, Marc Glisse wrote:
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse
wrote:
Hello,
I was asked to handle (const) fenv_t and fexcept_t the same way as FILE
and
const tm. Sin
In libgo system goroutines register themselves after they start. That
means that there is a small race between the goroutine being seen by
the scheduler and the scheduler knowing that the goroutine is a system
goroutine. That in turn means that runtime.NumGoroutines can
overestimate the number of
This patch from Than McIntosh removes a stale comment in code that
accepts "go:nowritebarrier" pragma and updates the comment for
"go:nowritebarrierrec". Bootstrapped on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On 06/22/2017 09:29 AM, Richard Earnshaw (lists) wrote:
> On 22/06/17 16:01, Jeff Law wrote:
>> This fixes a bug discovered when we were evaluating the current state of
>> -fstack-check. It ought to be able to go forward independent of the
>> rest of the -fstack-check work.
>>
>> The aarch64 speci
On 06/22/2017 03:53 AM, Richard Earnshaw (lists) wrote:
> On 21/06/17 18:25, Jeff Law wrote:
>> On 06/21/2017 02:41 AM, Richard Earnshaw (lists) wrote:
>>
But the stack pointer might have already been advanced into the guard
page by the caller. For the sake of argument assume the guard
On 22/06/17 16:01, Jeff Law wrote:
> This fixes a bug discovered when we were evaluating the current state of
> -fstack-check. It ought to be able to go forward independent of the
> rest of the -fstack-check work.
>
> The aarch64 specific code does not correctly handle large frames and
> will gen
PR80044 notes that -static and -pie together behave differently when
gcc is configured with --enable-default-pie as compared to configuring
without (or --disable-default-pie). This patch removes that
difference. In both cases you now will have -static completely
overriding -pie.
Fixing this wasn
Hi Carl,
On Wed, Jun 21, 2017 at 02:23:06PM -0700, Carl Love wrote:
> +;; Vector reverse elements
> +(define_expand "altivec_vreve2"
> + [(set (match_operand:VEC_A 0 "register_operand" "=v")
> + (unspec:VEC_A [(match_operand:VEC_A 1 "register_operand" "v")]
> + UNSPEC_VREVEV
On Jun 20 2017, Wilco Dijkstra wrote:
> * config/aarch64/aarch64.c (aarch64_legitimate_constant_p):
> Return true for non-tls symbols.
This breaks gcc.target/aarch64/reload-valid-spoff.c with -mabi=ilp32:
/opt/gcc/gcc-20170622/gcc/testsuite/gcc.target/aarch64/reload-valid-s
The --enable-libstdcxx-debug option builds extra versions of libstdc++
without optimisation and installs them in $libdir/debug, which can be
used via RPATH or LD_LIBRARY_PATH. However, there's no gdb.py
installed alongside those debug versions of the libs, so while you can
step into unoptimised li
On Thu, Jun 22, 2017 at 09:01:03AM -0600, Jeff Law wrote:
> This fixes a bug discovered when we were evaluating the current state of
> -fstack-check. It ought to be able to go forward independent of the
> rest of the -fstack-check work.
>
> The aarch64 specific code does not correctly handle larg
This fixes a bug discovered when we were evaluating the current state of
-fstack-check. It ought to be able to go forward independent of the
rest of the -fstack-check work.
The aarch64 specific code does not correctly handle large frames and
will generate RTL with unrecognizable insns for such ca
Hi,
I proofread the code and noticed that in some cases I may trigger division by 0
that may
get different outputs depending on optimization setting on Itanium.
This is what I comitted after profiledbootstrap and regtesting at x86_64.
* profile-count.h (apply_probability,
apply_s
With the gc toolchain apparently
var s *string
_ = *s
is enough to panic with a nil pointer dereference. The gccgo compiler
will simply discard the dereference, which I think is a reasonable and
acceptable optimization. Change the tests to use an exported variable
instead. The tests are not
Because of how gccgo implements cgo calls, the code in dropm may not
have any write barriers. As a step toward implementing that, change
the gcstack, gcnextsegment, and gcnextsp fields of the g struct to
uintptr, so that assignments to them do not require write barriers.
The gcinitialsp field rema
Calling a deferred function in libgo currently requires changing from
a uintptr to the function code to a Go function value. That is done by
setting the value of a func local variable using unsafe.Pointer. The
local variable will always be on the stack. Adjust the code that sets
the local variable
In the gc version of the Go library the _defer struct has a _panic
field with a completely different meaning, that we are going to want
to adopt into libgo. This trivial patch renames libgo's _panic field
to panicStack to clear the way. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. C
This patch to libgo adjusts some runtime tests for gccgo:
- don't run tests that depend on SetCgoTraceback
- don't expect a '(' after the function name in a traceback
- change the expected name of nested functions in a traceback
These tests are not currently run, but they will be soon.
Bootstrap
The libgo library doesn't provide runtime.SetCgoTraceback, which is
used by the gc toolchain to collect combined C/Go tracebacks. Since
gccgo uses the normal C ABI, the function is not necessary for gccgo,
and it is difficult to implement. This patch changes the runtime
tests so that the ones tha
This libgo patch builds the runtime test testprogcgo with -pthread, as
is required by gccgo. This test is not currently run, but it will be
soon. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
On Thu, 22 Jun 2017, Rainer Orth wrote:
> > Support $SYSROOT for = in -I etc.
> > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00011.html
> >
> > This needs a cpp or C maintainer.
>
> It still does...
OK, though I'd expect that in most cases = is more convenient to use than
$SYSROO
This fixes recently introduced undefined behaviour caused by passing a
null pointer to memset. The patch also removes some trailing
whitespace.
PR libstdc++/81173
* include/bits/stl_bvector.h (vector::_M_initialize_value):
Do not pass null pointer to memset.
Tested powerp
Hi,
On 21 June 2017 at 14:50, Martin Liška wrote:
> On 06/21/2017 10:26 AM, Jan Hubicka wrote:
>>>
>>> Ok, so I fixed that in the described way. There's one remaining fallout of:
>>> gcc/testsuite/gcc.dg/tree-ssa/ipa-split-5.c
>>>
>>> Where a fnsplit is properly done, but then it's again inlined
From: Daniel Cederman
Date: Wed, 21 Jun 2017 15:27:51 +0200
> I have modified the patch so that the workaround is enabled by using
> either mfix-ut699, -mfix-ut700, or -mfix-gr712rc.
Eric, does Daniel's patch meet your requirements now?
On Jun 22, 2017, Jakub Jelinek wrote:
> On Thu, Jun 22, 2017 at 07:00:59AM -0300, Alexandre Oliva wrote:
>> [adding the list]
>> Thanks, I'm checking this in. Regstrapped on x86_64-linux-gnu.
> I bet it won't apply, I didn't know you were looking at this;
> Martin Liska filed PR81151 recently
On Jun 22, 2017, Alexandre Oliva wrote:
> The patch below (is this what you meant?) fixes the PR testcase, and the
> new else block doesn't get exercised in an x86_64-linux-gnu bootstrap.
Err, I misdescribed the situation. It's not that it doesn't get
exercised, it's that this new block doesn't
PING^1
On 05/31/2017 04:10 PM, Martin Liška wrote:
> ..adding missing patch
>
Hi.
As mentioned in the PR, we only generate a resolver function when there's a
usage
of a function with target_clones attribute. Let's document the behavior.
Ready to be installed?
Martin
gcc/ChangeLog:
2017-06-22 Martin Liska
PR other/78366
* doc/extend.texi: Document whe
On Jun 8, 2017, Segher Boessenkool wrote:
> Would it work to just have "else" instead if this "if"? Or hrm, we'll
> need to kill the recorded reg_stat value in the last case before this
> as well?
The patch below (is this what you meant?) fixes the PR testcase, and the
new else block doesn't g
Aldy Hernandez writes:
> On 06/20/2017 10:59 AM, Martin Sebor wrote:
>> On 06/20/2017 02:41 AM, Aldy Hernandez wrote:
>>> On 05/23/2017 03:26 PM, Martin Sebor wrote:
On 05/23/2017 04:48 AM, Aldy Hernandez wrote:
>>>
+ void Union (wide_int x, wide_int y);
+ bool Union (const irange
On Jun 13, 2017, Olivier Hainque wrote:
> 2017-06-13 Olivier Hainque
> * Makefile.def (host_modules): Set depgcc to true for libcc1,
> meaning need of a dep on stage_current if gcc-bootstrap and on
> maybe-all-gcc otherwise.
> (dependencies) Remove unconditional depend
The following patch implements $subject which means condition reduction
support for x86_64 which lacks a horizontal max vector operation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2016-06-22 Richard Biener
* tree-vect-loop.c (vect_model_reductio
On Thu, 22 Jun 2017, Alan Hayward wrote:
>
> > On 22 Jun 2017, at 09:52, Richard Biener wrote:
> >
> > On Thu, 22 Jun 2017, Richard Biener wrote:
> >
> >> On Wed, 21 Jun 2017, Richard Biener wrote:
> >>
> >>>
> >>> During my attempt to refactor reduction vectorization I ran across
> >>> the
On Thu, Jun 22, 2017 at 12:58 PM, Marc Glisse wrote:
> On Thu, 22 Jun 2017, Richard Biener wrote:
>
>> On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse
>> wrote:
>>>
>>> Hello,
>>>
>>> I was asked to handle (const) fenv_t and fexcept_t the same way as FILE
>>> and
>>> const tm. Since these have spec
On Thu, Jun 22, 2017 at 12:57 PM, Martin Liška wrote:
> On 06/22/2017 12:27 PM, Richard Biener wrote:
>> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote:
>>> Hello.
>>>
>>> There's one additional predictor enhancement that is GOTO predict that
>>> used to working. Following patch adds expect
Ping*2
Richard Sandiford writes:
> Ping for this Ada patch/question.
>
> Richard Sandiford writes:
>> Richard Biener writes:
> How does this look? Changes since v1:
>
> - Added access_fn_component_p to check for valid access function
> components.
>
> - Added access_fn_
Ping*2
Richard Sandiford writes:
> Ping
>
> Richard Sandiford writes:
>> Jeff Law writes:
>>> On 11/16/2016 09:32 AM, Richard Sandiford wrote:
Later patches will make machmode.h rely on wide-int.h and the
new poly-int.h, so it needs to appear later in the coretypes.h
include list
Ping*3
Richard Sandiford writes:
> Ping*2
>
> Richard Sandiford writes:
>> In this testcase, we (correctly) record after:
>>
>> strcpy (p1, "abcde");
>> char *p2 = strchr (p1, '\0');
>> strcpy (p2, q);
>>
>> that the length of p1 and p2 can be calculated by converting the
>> second strcpy
And there are backports for GCC 7 branch that I'm going to install.
Martin
>From 818c118793ae5e95948dd95471561c261247924c Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 19 Jun 2017 13:27:48 +
Subject: [PATCH 12/12] Backport r249368
gcc/ChangeLog:
2017-06-19 Martin Liska
PR sanitizer/
The test case triggered this assert in vect_update_misalignment_for_peel:
gcc_assert (DR_MISALIGNMENT (dr) / dr_size ==
DR_MISALIGNMENT (dr_peel) / dr_peel_size);
We knew that the two DRs had the same misalignment at runtime, but when
considered in isolation, one d
Hello.
I'm going to install the very same set of patches as for GCC 6.x except first 4
patches
to ipa-visibility.c. These will be more complicated to backport.
Martin
>From 4d28482901c9569abd91cbff64a2362d39be50a1 Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 31 May 2017 11:40:13 +
Subje
> On 22 Jun 2017, at 09:52, Richard Biener wrote:
>
> On Thu, 22 Jun 2017, Richard Biener wrote:
>
>> On Wed, 21 Jun 2017, Richard Biener wrote:
>>
>>>
>>> During my attempt to refactor reduction vectorization I ran across
>>> the special casing of inital values for INTEGER_INDUC_COND_REDUCTI
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse wrote:
Hello,
I was asked to handle (const) fenv_t and fexcept_t the same way as FILE and
const tm. Since these have special handling in quite a few places, it seems
necessary to make their support a bit
On 06/22/2017 12:27 PM, Richard Biener wrote:
> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote:
>> Hello.
>>
>> There's one additional predictor enhancement that is GOTO predict that
>> used to working. Following patch adds expect statement for C and C++ family
>> languages.
>>
>> There's one
Hi.
There's a small fallout where I blow up a function in order to
suppress function inlining. Honza pre-approved the change, I'm
going to install the patch.
Martin
>From dc4f022b91913e25eaff2ddcaf4dfef0e44217a2 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 22 Jun 2017 12:45:55 +0200
Subject:
On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse wrote:
> Hello,
>
> I was asked to handle (const) fenv_t and fexcept_t the same way as FILE and
> const tm. Since these have special handling in quite a few places, it seems
> necessary to make their support a bit more generic first. If I didn't mess
>
Hi!
I'm seeing almost 750 of runtime errors like:
../../gcc/ada/gcc-interface/trans.c:6992:20: runtime error: load of value 240,
which is not a valid value for type 'bool'
(with random values in place of the 240 above) during bootstrap-ubsan.
The problem is that atomic_access_required_p only ini
On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote:
> Hello.
>
> There's one additional predictor enhancement that is GOTO predict that
> used to working. Following patch adds expect statement for C and C++ family
> languages.
>
> There's one fallout which is vrp24.c test-case, where only 'Simpli
On 2017-06-19 12:44 -0600, Martin Sebor wrote:
> On 06/19/2017 11:28 AM, Xi Ruoyao wrote:
> > On 2017-06-19 10:51 -0600, Martin Sebor wrote:
> > > On 06/11/2017 07:32 PM, Xi Ruoyao wrote:
> > > > This patch adds warning option -Wstring-plus-int for C/C++.
> > > >
> > > > gcc/ChangeLog:
> > > >
>
1 - 100 of 115 matches
Mail list logo