On Thu, Jun 22, 2017 at 12:39 AM, Ian Lance Taylor wrote:
> On Tue, Jun 20, 2017 at 12:46 PM, Uros Bizjak wrote:
>> This patch inroduces applyRelocationsALPHA to solve:
>>
>> FAIL: TestCgoConsistentResults
>> FAIL: TestCgoPkgConfig
>> FAIL: TestCgoHandlesWlORIGIN
>>
>> gotools errors.
>>
>> Boots
On 2017/6/14 12:00 AM, Jakub Jelinek wrote:
> I don't see sufficient information on what you want to change and why
> and whether the changes are backwards compatible (say will a valid
> OpenACC 2.0 program compiled by GCC 7 work against both libgomp from GCC 7
> as well as one with this patch)?
>
from ../../../libgo/sysinfo.c:106:
/usr/include/asm/fpu.h:57:8: error: redefinition of '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/s
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_REDUCTION
> and tried to see what it is about. So I ended up implementing
> cond reduction support for targets w/o REDUC_
On Wed, 21 Jun 2017, Marc Glisse wrote:
> On Wed, 21 Jun 2017, Jakub Jelinek wrote:
>
> > So, I wrote following patch to do the subtraction in unsigned
> > type. It passes bootstrap, but on both x86_64-linux and i686-linux
> > regresses:
> > +FAIL: gcc.dg/torture/pr66178.c -O* (test for exces
On Wed, Jun 21, 2017 at 08:59:29AM +0200, Richard Biener wrote:
> Actually I was looking for a bit more generic
>
> bool
> target_supports_op_p (tree type, enum tree_code code,
> enum optab_subtype = optab_default)
> {
> optab ot = optab_for_tree_code (code, type, optab_subty
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 up, this patch should not change anything.
Bootstrap + tes
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_REDUCTION
> > and tried to see what it is about. So I ended up impl
On Thu, 22 Jun 2017, Richard Biener wrote:
If we consider pointers as unsigned, with a subtraction that has a signed
result with the constraint that overflow is undefined, we cannot model that
optimally with just the usual signed/unsigned operations, so I am in favor of
POINTER_DIFF, at least in
On Thu, 22 Jun 2017, Marc Glisse wrote:
> On Thu, 22 Jun 2017, Richard Biener wrote:
>
> > > If we consider pointers as unsigned, with a subtraction that has a signed
> > > result with the constraint that overflow is undefined, we cannot model
> > > that
> > > optimally with just the usual signed
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 page is
>>> 0xf1000 and assume that our stack pointer at entr
[adding the list]
On Jun 8, 2017, Uros Bizjak wrote:
> On Thu, Jun 8, 2017 at 9:22 PM, Alexandre Oliva wrote:
>> I was playing with bootstrap STAGE2_C{,XX}FLAGS='-O0 -fcompare-debug' to
>> test some changes I'm working on, and -Werror in stage2 prevented
>> compilation of one of the insn-*.c f
On Thu, Jun 22, 2017 at 07:00:59AM -0300, Alexandre Oliva wrote:
> [adding the list]
>
> On Jun 8, 2017, Uros Bizjak wrote:
>
> > On Thu, Jun 8, 2017 at 9:22 PM, Alexandre Oliva wrote:
> >> I was playing with bootstrap STAGE2_C{,XX}FLAGS='-O0 -fcompare-debug' to
> >> test some changes I'm work
On Wed, Jun 21, 2017 at 1:17 PM, Nathan Sidwell wrote:
> On 06/21/2017 04:14 AM, Martin Liška wrote:
>>
>> As release managers are planning to release next version of GCC 6. I would
>> like to
>> do backport revisions attached.
>>
>> The only complicated one is the one for PR69953 where I decided
Resending for the list, as the last copy got bounced.
Thanks,
James
- Forwarded message from James Greenhalgh -
Date: Thu, 22 Jun 2017 11:16:38 +0100
From: James Greenhalgh
To: Michael Collison , Wilco Dijkstra
, Christophe Lyon , GCC
Patches , nd ,
richard.sandif...@linaro.org
Subj
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:
> > > >
>
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
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 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.
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 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
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 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
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
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
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/
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
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*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_
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
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, 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
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 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
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 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
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
PING^1
On 05/31/2017 04:10 PM, Martin Liška wrote:
> ..adding missing patch
>
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
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
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?
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
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
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 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
==
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 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
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
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
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
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
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
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
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
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 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
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
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
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
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 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
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
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
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
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 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
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 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 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 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 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 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 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 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 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 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
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
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
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-
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 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
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
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
* 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
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
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
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
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
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 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
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
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,
>
* 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
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
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
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
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 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
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
1 - 100 of 115 matches
Mail list logo
