On Tue, 20 Jun 2017, James Greenhalgh wrote:
>
> On Fri, Jun 16, 2017 at 11:41:57AM +0200, Richard Biener wrote:
> > On Fri, 16 Jun 2017, James Greenhalgh wrote:
> > > On Mon, Jun 12, 2017 at 03:56:25PM +0200, Richard Biener wrote:
> > > > + We can't do the same for signed A, as it might be neg
Hi folks.
The following is another iteration of the SSA range class, taking into
account many of the suggestions posted on this thread, especially the
addition of a memory efficient class for storage, folding non-zero bits
back into the range information, C++ suggestions by Martin, and some
m
On Tue, Jun 20, 2017 at 4:34 PM, Pierre-Marie de Rodat
wrote:
> On 06/20/2017 02:16 PM, Richard Biener wrote:
>>
>> Nice. This looks ok.
>
>
> Great, thank you!
>
>> I'm mildy curious about the deecrease of debuginfo size for cc1 -- did
>> you spot anything obvious there?
>
>
> Well, the benchmar
On Tue, Jun 20, 2017 at 11:00 PM, Marc Glisse wrote:
> Hello,
>
> now that FRE was fixed to avoid infinite recursion, this patch passes
> bootstrap+testsuite on x86_64-pc-linux-gnu multilib with all languages
> (including ada).
>
> This isn't exactly the patch that was reverted, because the previo
On Jun 19 2017, Jan Hubicka wrote:
> this patch makes us to track quality of the profile. This is useful
> to disable some agressive optimizations when counts are known to be
> unreliable.
This breaks bootstrap on ia64 with a comparison failure in value-prof.o.
The only difference is in gimple
Hello!
> glibc marks fegetround as a pure function. On x86, people tend to use
> _MM_GET_ROUNDING_MODE instead, which could benefit from the same. I think it
> is safe, but
> a second opinion would be welcome. I could have handled just this builtin,
> but it seemed better to
> provide def_builti
On Jun 20 2017, Eric Botcazou wrote:
> Right, because the Linux kernel for x86/x86-64 is the only OS flavor that
> doesn't let you probe the stack ahead of the stack pointer. All other
> combinations of OS and architecture we tried (and it's quite a lot) do.
Take a look at do_page_fault in ar
On Tue, Jun 20, 2017 at 10:18:20AM +0200, Richard Biener wrote:
> > It would be an attempt to avoid sanitizing int foo (int *p) { return p[10]
> > + p[-5]; }
> > (when the offset is constant and small and we dereference it).
> > If there is no page mapped at NULL or at the highest page in the virt
On 20 Jun, Jason Merrill wrote:
> On Tue, Jun 20, 2017 at 3:06 PM, David Malcolm wrote:
>> It's not clear to me what the issue alluded to with negative
>> obstack_blank is, but I chose to follow the above docs and use
>> obstack_blank_fast; am testing an updated patch in which the above line
>> no
On Tue, Jun 20, 2017 at 09:41:43AM +0200, Richard Biener wrote:
> > 2) libcpp/line-map.c has this:
> > static int
> > location_adhoc_data_update (void **slot, void *data)
> > {
> > *((char **) slot) += *((int64_t *) data);
> > return 1;
> > }
> > where the (why int64_t always?, we really need j
On Wed, 21 Jun 2017, Jakub Jelinek wrote:
> On Tue, Jun 20, 2017 at 09:41:43AM +0200, Richard Biener wrote:
> > > 2) libcpp/line-map.c has this:
> > > static int
> > > location_adhoc_data_update (void **slot, void *data)
> > > {
> > > *((char **) slot) += *((int64_t *) data);
> > > return 1;
>
On Wed, 21 Jun 2017, Jakub Jelinek wrote:
> On Tue, Jun 20, 2017 at 10:18:20AM +0200, Richard Biener wrote:
> > > It would be an attempt to avoid sanitizing int foo (int *p) { return
> > > p[10] + p[-5]; }
> > > (when the offset is constant and small and we dereference it).
> > > If there is no p
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 to backport
also refactoring patches applied by Nathan (244529, 244156).
I would appreciate another pair of eyes to
>
> 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:
>
> Considering split_me.part.0/5 with 23 size
> to be inlined into test/2 in unknown:0
> Estimated b
Updated the patch per Richard's suggestions to allow scheduling of instructions
before reload.
Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk?
2017-05-22 Kyrylo Tkachov
Michael Collison
PR target/70119
* config/aarch64/aarch64.md (*aarch64__reg_3_ma
On 21/06/17 00:22, Wilco Dijkstra wrote:
> Jeff Law 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 entry is 0xf1010 and that
>> the caller hasn
On 20/06/17 22:39, Jeff Law wrote:
> On 06/20/2017 03:27 AM, Richard Earnshaw (lists) wrote:
>> On 19/06/17 18:07, Jeff Law wrote:
>>> As some of you are likely aware, Qualys has just published fairly
>>> detailed information on using stack/heap clashes as an attack vector.
>>> Eric B, Michael M --
Hi,
This patch removes old parallel code for avx512er. Parallel in this case can't
be generated anymore, because all existing patterns were reworked to unspec in
r249423 and r249009. Ok for trunk?
gcc/
* gcc/config/i386/i386.c (ix86_erase_embedded_rounding):
Remove code for old r
On Jun 21 2017, "Richard Earnshaw (lists)" wrote:
> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
> stack which, with at least 8 parameters passed in registers, would allow
> for calls with 40 parameters. There can't be many in that space. Any
> function making calls
On 21/06/17 09:44, Andreas Schwab wrote:
> On Jun 21 2017, "Richard Earnshaw (lists)" wrote:
>
>> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
>> stack which, with at least 8 parameters passed in registers, would allow
>> for calls with 40 parameters. There can't be m
On 21/06/17 09:46, Richard Earnshaw (lists) wrote:
> On 21/06/17 09:44, Andreas Schwab wrote:
>> On Jun 21 2017, "Richard Earnshaw (lists)" wrote:
>>
>>> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
>>> stack which, with at least 8 parameters passed in registers, would
On 14/06/17 19:13 +0100, Jonathan Wakely wrote:
There are two symbols defined in GCC 7.1's libstdc++.6.0.23 library
which are not exported on all targets (because I wrote "m" in the
linker script instead of "[jmy]").
This patch bumps the library version on gcc-7-branch to 6.0.24 and
exports the
Richard Earnshaw wrote:
> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
> stack which, with at least 8 parameters passed in registers, would allow
> for calls with 40 parameters. There can't be many in that space. Any
> function making calls with more than that might ne
On 20/06/17 16:41, James Greenhalgh wrote:
>
> Hi,
>
> This patch adds support for the ARM Cortex-A75 and
> Cortex-A55 processors through the -mcpu/-mtune values cortex-a55 and
> cortex-a75, and an ARM DynamIQ big.LITTLE configuration of these two
> processors through the -mcpu/-mtune value corte
On 20/06/17 22:29, Andreas Tobler wrote:
> Hi All,
>
> I committed the chunk below to fix bootstrap on armv6*-*-freebsd.
>
> Andreas
>
> 2017-06-20 Andreas Tobler
>
> * config.gcc (armv6*-*-freebsd*): Change the target_cpu_cname to
> arm1176jzf-s.
>
> Index: config.gcc
> ===
On 20/06/17 15:56, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>
>> What testing has this had with -fpic? I'm not convinced that this
>> assertion is true in that case?
>
> I ran the GLIBC tests which pass. -fpic works since it does also form a
> constant address, ie. instead of:
>
> adrp
On 06/06/17 20:52, Andrew Stubbs wrote:
Thomas objects to the new option, and after talking with him the
reasoning seems sound. GCC has been moving away from -mcpu in any case,
so I guess I'll put -march and -mtune back, and use those for the same
purpose.
I'll commit the patch with those cha
On Tue, Jun 20, 2017 at 09:45:10PM +0200, Andreas Schwab wrote:
> On Jun 20 2017, Jason Merrill wrote:
>
> > On Tue, Jun 20, 2017 at 5:40 AM, Andreas Schwab wrote:
> >> FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for errors, line 10)
> >> FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++1
> > movi\\t%0.4h, #0
> > - mov\\t%0.h[0], %w1
> > + fmov\\t%s0, %w1
>
> Should this not be %h0?
The problem is that H registers are only available in ARMv8.2+,
I'm not sure what to do about ARMv8.1 given your other feedback
Pointing out that the bit patterns between how it's stored in s v
*ping*
Thanks,
James
On Mon, Jun 12, 2017 at 02:44:40PM +0100, James Greenhalgh wrote:
> [Sorry for the re-send. I spotted that the attributes were not right for the
> new pattern I was adding. The change between this and the first version was:
>
> + [(set_attr "type" "neon_bsl,neon_bsl,neon
On Mon, Jun 12, 2017 at 03:28:52PM +0100, Kyrill Tkachov wrote:
>
> On 12/06/17 14:53, James Greenhalgh wrote:
> >Hi,
> >
> >In the AArch64 backend and scheduling models there is some confusion as to
> >what the load1/load2 etc. scheduling types refer to. This leads to us using
> >load1/load2 in t
*ping*
Thanks,
James
On Mon, Jun 12, 2017 at 02:54:00PM +0100, James Greenhalgh wrote:
>
> Hi,
>
> There seems to be a partial misconception in the AArch64 backend that
> load1/load2 referred to the number of registers to load, rather than the
> number of words to load. This patch fixes that us
On Tue, Jun 20, 2017 at 11:13:24AM -0700, Andrew Pinski wrote:
> Here is the updated patch based on the new infrastructure which is now
> included.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions
> and tested again on SPEC CPU 2006 on THunderX T88 with the speed up
> men
Hi!
This patch is both a fix for the ICE on the testcase below and an
optimization - there is no point to keep shared clauses for vars that
have ctors/dtors, but aren't referenced in the construct, for privatization
clauses we do it because of the ctors/dtors involved, but for shared there
is no p
On Tue, Jun 20, 2017 at 02:07:22PM -0700, Andrew Pinski wrote:
> On Mon, Jun 19, 2017 at 2:00 PM, Andrew Pinski wrote:
> > On Wed, Jun 7, 2017 at 10:16 AM, James Greenhalgh
> > wrote:
> >> On Fri, Dec 30, 2016 at 10:05:26PM -0800, Andrew Pinski wrote:
> >>> Hi,
> >>> Currently for the following
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 to backport
also refactoring patches applied by Nathan (244529, 244156).
On 06/21/2017 09:11 AM, Richard Biener wrote:
Sure, no obligation for you to enhance Fortran debug!
Understood, thanks. For your information, I just committed the change.
Thank you again for reviewing!
--
Pierre-Marie de Rodat
> use INTEGRAL_TYPE_P.
Done.
> but you do not actually _use_ vr_outer. Do you think that if
> vr_outer is a VR_RANGE then the outer operation may not
> possibly have wrapped? That's a false conclusion.
These were remains of a previous version. vr_outer is indeed not needed
anymore; removed.
On 20 June 2017 at 11:45, Richard Biener wrote:
> On Tue, 20 Jun 2017, Alan Hayward wrote:
>
>>
>> > On 19 Jun 2017, at 13:35, Richard Biener wrote:
>> >
>> > On Mon, 19 Jun 2017, Christophe Lyon wrote:
>> >
>> >> Hi Richard,
>> >>
>> >> On 16 June 2017 at 14:18, Richard Biener wrote:
>> >>> On
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:
>>
>> Considering split_me.part.0/5 with 23 size
>> to be
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 'Simplified
relational'
appears just once. Adding Richi and Patrick who
On 06/21/2017 03: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 'Simplified
>
On Fri, Jun 09, 2017 at 04:24:30PM +0200, Tom de Vries wrote:
> * gcc.dg/tree-prof/comp-goto-1.c: Same.
> * gcc.dg/tree-prof/pr44777.c: Same.
> --- a/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c
> +++ b/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c
> @@ -1,6 +1,8 @@
> /* { dg-require-e
Hello all,
I have modified the patch so that the workaround is enabled by using
either mfix-ut699, -mfix-ut700, or -mfix-gr712rc.
Daniel
-
This patch adds a workaround to the Sparc backend for the LEON3FT
store-store errata. It is enabled when using the -mfix-ut699,
-mfix-ut700, or -mfix-gr712r
Hi all,
As Andrew pointed out, the patch at r248921
(https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01648.html)
that allowed const0_rtx as an argument to the compare-exchange
patterns was incomplete. It didn't extend the TARGET_LSE patterns as well,
causing the expander to generate
an invalid pa
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_MAX_EXPR by simply
doing the reduction in scalar code
On Tue, 2017-06-20 at 15:11 -0400, Jason Merrill wrote:
> On Tue, Jun 20, 2017 at 3:06 PM, David Malcolm
> wrote:
> > It's not clear to me what the issue alluded to with negative
> > obstack_blank is, but I chose to follow the above docs and use
> > obstack_blank_fast; am testing an updated patch
Thanks for the feedback. I'll redo the patch according to your comments.
Igor
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Tuesday, June 20, 2017 11:30 PM
To: Tsimbalist, Igor V
Cc: gcc-patches@gcc.gnu.org; Chupin, Pavel V
Subject: Re: [PATCH] [i386] Ena
Hi,
this patch fixes a 'return type defaults to int' warning in test-case
gcc.dg/tree-prof/comp-goto-1.c.
Committed as obvious.
Thanks,
- Tom
Fix warning in gcc.dg/tree-prof/comp-goto-1.c
2017-06-21 Tom de Vries
* gcc.dg/tree-prof/comp-goto-1.c: Fix 'return type defaults to int'
warnin
[ was: Re: [PATCH, testsuite] Add effective target stack_size ]
On 06/21/2017 03:19 PM, Jakub Jelinek wrote:
On Fri, Jun 09, 2017 at 04:24:30PM +0200, Tom de Vries wrote:
* gcc.dg/tree-prof/comp-goto-1.c: Same.
* gcc.dg/tree-prof/pr44777.c: Same.
--- a/gcc/testsuite/gcc.dg/tr
Regenerate symbols file for aarch64-none-linux-gnu. Tested with make
check in libstdc++ and eyeballing outputs.
Applied as obvious.
Tested on aarch64-none-linux-gnu with no issues in libstdc++ tests.
regards
Ramana
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate
diff --
Hi Carl,
On Tue, Jun 20, 2017 at 06:23:33PM -0700, Carl Love wrote:
> * config/rs6000/rs6000-builtin.def (VREVE_V2DI, VREVE_V4SI,
> VREVE_V8HI, VREVE_V16QI, VREVE_V2DF, VREVE_V4SF, VREVE): New
"New." or "New builtin.".
> * config/rs6000/altivec.md (UNSPEC_VREVEV, VEC_A_size,
>
On Tue, Jun 20, 2017 at 10:18:20AM +0200, Richard Biener wrote:
> > > > 3) not really related to this patch, but something I also saw during the
> > > > bootstrap-ubsan on i686-linux:
> > > > ../../gcc/bitmap.c:141:12: runtime error: signed integer overflow:
> > > > -2147426384 - 2147475412 cannot
On Wed, Jun 21, 2017 at 02:48:20PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> As Andrew pointed out, the patch at r248921
> (https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01648.html) that allowed
> const0_rtx as an argument to the compare-exchange patterns was incomplete. It
> didn't extend the TA
On Wed, Jun 21, 2017 at 6:32 AM, Jakub Jelinek wrote:
> The following patch fixes it by allowing that wording too on the line 10.
> Is this ok for trunk or do you have some other preference?
OK, thanks.
Jason
On Wed, Jun 21, 2017 at 04:40:01PM +0200, 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 excess errors)
> +FAIL: gcc.dg/tree-ss
Hi,
Commit r249422 to dg-cmp-results.sh broke the variant selection feature
where one can restrict the regression test to a specific target variant. This
fix restores the feature.
ChangeLog entry is as follows:
*** contrib/ChangeLog ***
2017-06-21 Thomas Preud'homme
* dg-cmp-resul
Michael Collison writes:
> Updated the patch per Richard's suggestions to allow scheduling of
> instructions before reload.
Thanks, this looks good to me FWIW, but obviously I can't approve it.
Richard
> Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk?
>
> 2017-05-22 Kyrylo Tkacho
On Jun 21, 2017, at 8:30 AM, Thomas Preudhomme
wrote:
>
> Commit r249422 to dg-cmp-results.sh broke the variant selection feature
> 2017-06-21 Thomas Preud'homme
>
> * dg-cmp-results.sh: Restore filtering on target variant.
>
>
> Tested on a file with multiple variants which now giv
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 excess errors)
+FAIL: gcc.dg/tree-ssa/cmpexactdiv-2.c scan-tree-
Hi,
On 19 June 2017 at 11:32, Richard Earnshaw (lists)
wrote:
> On 16/06/17 15:56, Prakhar Bahuguna wrote:
>> On 16/06/2017 15:37:18, Richard Earnshaw (lists) wrote:
>>> On 16/06/17 08:48, Prakhar Bahuguna wrote:
On 15/06/2017 17:23:43, Richard Earnshaw (lists) wrote:
> On 14/06/17 10:3
Hi,
On 19 June 2017 at 11:32, Richard Earnshaw (lists)
wrote:
> On 16/06/17 15:56, Prakhar Bahuguna wrote:
>> On 16/06/2017 15:37:18, Richard Earnshaw (lists) wrote:
>>> On 16/06/17 08:48, Prakhar Bahuguna wrote:
On 15/06/2017 17:23:43, Richard Earnshaw (lists) wrote:
> On 14/06/17 10:3
On 06/20/2017 05:22 PM, Wilco Dijkstra wrote:
> Jeff Law 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 entry is 0xf1010 and that
>> the caller
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 entry is 0xf1010 and that
>> the caller hasn't
On 06/20/2017 04:20 PM, Eric Botcazou wrote:
>> But what you end up depending on is undocumented behavior of a
>> particular kernel implementation. That seems rather unwise.
>
> And it's the single example of such a thing in the entire codebase?
> I don't know the code of the sanitizer much, but
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 aarch64 is there's nothing that can currently be relied u
On Tue, 2017-06-20 at 17:16 -0500, Segher Boessenkool wrote:
> On Tue, Jun 20, 2017 at 09:34:25PM +, Joseph Myers wrote:
> > On Tue, 20 Jun 2017, Segher Boessenkool wrote:
> >
> > > > And as you see see below the gcc.target tests have to be duplicated
> > > > anyway. Even if the C code is comm
On 21 June 2017 16:07:29 CEST, "Tsimbalist, Igor V"
wrote:
>Thanks for the feedback. I'll redo the patch according to your
>comments.
what is "noni-tracking" ? Surplus i.
"codegeneration" probably lacks a space.
Thanks,
Hi!
This expander has a gap in between the operands and match_dup indexes,
which results in genemit generating:
operand2 = operands[2];
(void) operand2;
where operands[2] has not been initialized.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2017-06-
Hi!
tsubst_* ICEs when seeing an OVERLOAD that is dependent on template
arguments. But if we see an OVERLOAD in an OpenMP data sharing/mapping clause,
even when processing_template_decl we know that it won't be a variable,
so we can as well diagnose it right away, without having to wait for the
i
On 06/20/2017 11:52 PM, Jeff Law wrote:
> I've also wondered if a 2 page guard would solve some of these problems.
> In the event of stack overflow, the kernel maps in one of the two pages
> for use by the signal handler. But changing things at this point may
> not be worth the effort.
I think
On Wed, Jun 21, 2017 at 8:27 PM, Jakub Jelinek wrote:
> Hi!
>
> This expander has a gap in between the operands and match_dup indexes,
> which results in genemit generating:
> operand2 = operands[2];
> (void) operand2;
> where operands[2] has not been initialized.
>
> Fixed thusly, bootstr
On Wed, Jun 21, 2017 at 12:55:54PM -0500, Steven Munroe wrote:
> > > I don't expect many different effective-target / dg-add-options keywords
> > > to be needed for common tests (obviously, duplicating tests for each
> > > architecture wanting these intrinsics is generally a bad idea).
> >
> > Y
Andreas Schwab noticed that the tests for PR target/80510 were failing on
32-bit PowerPC systems.
In looking at the tests, the reason was it was trying to create a test that had
more than 32 live floating point values. The loop to use all of the values had
tests of the form:
for (i = 0; i < n;
GCC maintainers:
I have updated the patch per the comments from Segher. I used the
functions GET_MODE_UNIT_SIZE() and GET_MODE_NUNITS() as suggested. I
didn't know about these functions, I checked out all the various
functions defined in machmode.h for future reference.
Note, I did make some a
This patch from James Cowgill fixes the libgo ptrace implementation
for MIPS by modifying mksysinfo.sh to look for the pt_regs struct.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu, which
admittedly proves little. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
This patch from James Cowgill implements randomTrip for mips64p32*.
Bootstrapped on x86_64-pc-linux-gnu, which proves little. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 249
This libgo patch by James Cowgill adds mips64p32* to the size maps in
the cgo tool. Bootstrapped on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 249474)
This patch from James Cowgill changes libgo to use the gc toolchain
names for MIPS variants. Bootstrapped on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision
This patch from James Cowgill finishes standardizing on the names used
in the gc toolchain by removing the old names used in the gofrontend
sources. It drops the mipso64 ABI, which has been dead for a long
time (as a historical note I think I invented the o64 ABI by accident
when I did the initial
This patch from Than McIntosh fixes a missing case in
Array_type::get_value_pointer in the Go frontend. It updates the code
in Array_type::get_value_pointer that handles "lvalue" context to look
for both regular var expressions and temp var expressions, since both
can appear in array/slice index e
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.
>
> Bootstrapped and regression tested on alphaev68-linux-gnu.
Thanks! Commit
This patch adds IEEE 128 support to the existing scalar_insert_exp,
scalar_extract_exp, scalar_extract_sig, scalar_test_data_class, and
scalar_test_neg rs6000 built-in functions. Test programs are provided
to exercise the new IEEE 128 functionality and to validate forms of
these built-in function
This Go frontend patch produces a better stack trace for `go f()`
where f is nil. The test for this is TestGoNil in the runtime
package, which we don't run yet but will run with a subsequent gotools
patch. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index
This libgo patch changes tracebacks to print "panic" rather than
"runtime.gopanic". Since the user's code calls "panic", this is
generally clearer. The test for this is TestPanicTraceback in
runtime/crash_test.go; we don't run it yet, but we will soon.
Bootstrapped and ran Go testsuite on x86_64-
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 combine has multiple SETs, only the non-REG_UNUSED
>> set is used: others will end
Rainer Orth writes:
> The following patches have remained unreviewed for two weeks despite a
> reminder:
it's three weeks now...
> [build] Support --sysroot with Solaris ld
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02342.html
>
> This needs a build maintainer, though I still
87 matches
Mail list logo
