Re: [PATCH, LRA] Fix PR rtl-optimization 77289, LRA matching constraint problem

On 9/9/16 5:51 PM, Jeff Law wrote: On 08/30/2016 10:23 PM, Peter Bergner wrote: gcc/ PR rtl-optimization/77289 * lra-constraints.c (get_final_hard_regno): Add support for non hard register numbers. Remove support for subregs. (get_hard_regno): Use SUBREG_P. Don't call

[Committed] PR fortran/77420

I've committed the following patch. It restores gfortran's behavior prior to my commit r224159 if the current namespace has an empty equivalent list. 2016-09-09 Steven G. Kargl PR fortran/77420 * module.c (load_equiv): If the current namespace has a list of

[PATCH] Fix -Wshadow warning in libiberty/cp-demangle.c

valgrind contains a copy of the libiberty demangler which gets compiled with -Wshadow. That shows the following warning: cp-demangle.c: In function ‘d_substitution’: cp-demangle.c:3772:35: warning: declaration of ‘c’ shadows a previous local struct demangle_component *c;

Re: [PATCH] avoid non-printable characters in diagnostics (c/77620, c/77521)

On 09/09/2016 07:59 AM, Joseph Myers wrote: On Thu, 8 Sep 2016, Martin Sebor wrote: PS I used hexadecimal based on what c-format.c does but now that I checked more carefully how %qE formats string literals I see it uses octal. I think hexadecimal is preferable because it avoids ambiguity but

Re: [PATCH 9/9] cse.c selftests

On 09/09/2016 07:28 AM, Bernd Edlinger wrote: Hi David, I attempted to create a reproducer for PR 71779; however I'm not yet able to replicate the bogus cse reported there via the test case. Thanks, this is just awesome. I immediately had to try your patch. I'd pointed David at 71779

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/09/2016 02:41 PM, Segher Boessenkool wrote: On Fri, Sep 09, 2016 at 12:31:31PM -0600, Jeff Law wrote: On 06/08/2016 03:18 AM, Bernd Schmidt wrote: On 06/08/2016 03:47 AM, Segher Boessenkool wrote: + /* regrename creates wrong code for exception handling, if used together +

Re: [PATCH 0/4] (v2) Generating patches from fix-it hints

On 08/24/2016 07:13 PM, David Malcolm wrote: Here's a much less ambitious version of the patch kit, which eliminates any attempt to write to the user's source code (getting rid of edit_context::apply_changes and -fdiagnostics-apply-fixits). It implements -fdiagnostics-generate-patch. In so

Re: [PATCH, LRA] Fix PR rtl-optimization 77289, LRA matching constraint problem

On 08/30/2016 10:23 PM, Peter Bergner wrote: PR77289 exposes a latent problem with LRA constraint matching. In the buggy test cases, LRA performs a speculative register elimination before checking operands for matching constraints. With the elimination, the operands appear to match. However,

Re: [PATCH] df: Keep return address register undefined until epilogue_completed

On 08/29/2016 02:41 PM, Segher Boessenkool wrote: On Mon, Aug 29, 2016 at 10:19:25PM +0200, Steven Bosscher wrote: On Mon, Aug 29, 2016 at 6:50 PM, Segher Boessenkool wrote: This patch changes that so that that def is only added after epilogue_completed. ... Does this work on all other

Re: [PATCH] df: Keep return address register undefined until epilogue_completed

On 08/29/2016 10:50 AM, Segher Boessenkool wrote: For separate shrink-wrapping we need to find out which basic blocks need what components set up by a prologue, so that we can move those prologue pieces deeper into the function, so that those pieces are executed less frequently, improving

[patch,gomp4] Fix PR74600

By design, the libgomp OpenACC runtime prohibits data clauses with aliased addresses from being used in the same construct. E.g., the user is not allowed to specify #pragma acc parallel copy(var[0:10]) copy(pvar[0:10]) where pvar is a pointer to var or if those subarrays overlap. To a certain

Re: [PATCH] df: Keep return address register undefined until epilogue_completed

On 08/29/2016 02:19 PM, Steven Bosscher wrote: On Mon, Aug 29, 2016 at 6:50 PM, Segher Boessenkool wrote: This patch changes that so that that def is only added after epilogue_completed. ... Does this work on all other targets? Guessing: not for targets where INCOMING_RETURN_ADDR_RTX is the

Re: [PATCH] Remove support for INITIAL_FRAME_POINTER_OFFSET

On 09/09/2016 03:40 PM, Bernd Edlinger wrote: Hi, I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which is no longer used by any target today. This removes a bunch of conditional code, and fixes a few bits in the documentation. I'd say that part of the documentation

Re: [PATCH, PR71602, 4/4] Make canonical_va_list_type more strict

On 08/29/2016 10:12 AM, Tom de Vries wrote: On 29/08/16 17:51, Joseph Myers wrote: On Wed, 24 Aug 2016, Tom de Vries wrote: This patch fixes PR71602 by making canonical_va_list_type more strict. Bootstrapped and reg-tested on x86_64. OK for trunk, 6-branch? ENOPATCH Patch attached this

[PING] set libfunc entry for sdivmod_optab to NULL in optabs.def

Hi, I would like to ping the following patch: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html While implementing divmod transform: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html I ran into an issue with optab_libfunc(). It appears optab_libfunc (sdivmod_optab, mode) returns

Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate components

On Thu, Sep 08, 2016 at 12:34:07PM -0600, Jeff Law wrote: > On 07/31/2016 07:42 PM, Segher Boessenkool wrote: > > > >Deciding what blocks should run with a certain component active so that > >the total cost of executing the prologues (and epilogues) is optimal, is > >not a computationally feasible

Re: [PATCH] Fix suggestions for non-trivial Wformat type cases (PR c/72858)

On 08/12/2016 01:27 PM, David Malcolm wrote: In r239260 I attempted to add fix-it hints for -Wformat type warnings. Unfortunately, my implementation was too simplistic, and only worked correctly for the most simple format strings: the fix-it hint would suggest replacement of an entire

[PATCH] Remove support for INITIAL_FRAME_POINTER_OFFSET

Hi, I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which is no longer used by any target today. This removes a bunch of conditional code, and fixes a few bits in the documentation. I'd say that part of the documentation is quite out of sync, but I just have to stop

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote: > On 08/09/16 09:10 +0200, Marc Glisse wrote: >> >> Do we want a generic fallback implementation (similar to >> gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc / >> _aligned_free would also be

Re: [PATCH 7/9] cprop: Leave RTX_FRAME_RELATED_P instructions alone

On Thu, Sep 08, 2016 at 11:55:04AM -0600, Jeff Law wrote: > On 07/31/2016 07:42 PM, Segher Boessenkool wrote: > >Doing cprop on frame-related instructions blows up spectacularly. > >So don't. > > > >2016-06-07 Segher Boessenkool > > > > * regcprop.c

Define TS 18661-1 CR_DECIMAL_DIG in

TS 18661-1 defines a macro CR_DECIMAL_DIG in , for the number of decimal digits for which conversions between decimal character strings and (IEEE) binary formats, in both directions, are correctly rounded. This patch implements support for this macro in GCC's . The definition __UINTMAX_MAX__ is

Re: [PATCH 6/9] sel-sched: Don't mess with register restores

On Thu, Sep 08, 2016 at 11:54:33AM -0600, Jeff Law wrote: > On 07/31/2016 07:42 PM, Segher Boessenkool wrote: > >If selective scheduling copies register restores it confuses dwarf2cfi. > > > >2016-06-07 Segher Boessenkool > > > > * sel-sched-ir.c

Re: [PATCH] remove conditional compilation of HAVE_AS_LEB128 code

On 08/20/2016 09:57 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders Hi, basically just $subject, always define HAVE_AS_LEB128, and then use if / else instead of #ifdef. Note the diff has a bit of whitespace noise, so there's a -w diff below the full

Re: [PATCH 4/9] regrename: Don't rename restores

On Thu, Sep 08, 2016 at 11:51:53AM -0600, Jeff Law wrote: > On 07/31/2016 07:42 PM, Segher Boessenkool wrote: > >A restore is supposed to restore some certain register. Restoring it > >into some other register will not work. Don't. > > > >2016-06-07 Segher Boessenkool

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote: > I think the lack of test coverage is something we'll want to address. Building and running the compiler, the various target libraries, and the testsuite is more than enough coverage for correctness in my opinion -- I cannot make up

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On Fri, Sep 09, 2016 at 12:31:31PM -0600, Jeff Law wrote: > On 06/08/2016 03:18 AM, Bernd Schmidt wrote: > >On 06/08/2016 03:47 AM, Segher Boessenkool wrote: > >>+ /* regrename creates wrong code for exception handling, if used > >>together > >>+ with separate shrink-wrapping.

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On Fri, Sep 09, 2016 at 12:28:12PM -0600, Jeff Law wrote: > >The generic code only does > > > >+ /* We don't handle "strange" functions. */ > >+ if (cfun->calls_alloca > >+ || cfun->calls_setjmp > >+ || cfun->can_throw_non_call_exceptions > >+ || crtl->calls_eh_return > >+

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

Patch #1. All the fixes to static buffer sizes that were inspired by your warning. These are all approved and can go in immediately. Attached is this patch. Hi, this patch changed the file gcc/go/gofrontend/expressions.cc. As described in gcc/go/gofrontend/README, the files in the

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, Sep 09, 2016 at 12:19:03PM -0600, Jeff Law wrote: > >>Does this impact the compile time computation complexity issue that was > >>raised elsewhere? > > > >I'm not sure what you mean here either, sorry. It is all O(NM) with N > >the number of BBs and M the number of components (and

Go patch committed: increase buffer size to avoid -Wformat-length warning

This patch to the Go frontend increases the size of a local buffer to avoid a -Wformat-length warning. This undoes a patch that was earlier committed to the GCC repository in favor of a patch to the gofrontend repository mirrored to GCC. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

[PATCH] PR fortran/77429

The following patch fixes an ICE due to a gcc_assert() firing. As everyone here knows, gfortran runs a series a matchers during parsing. If a matcher fails, it often queuesi/reports an error message and returns, which allows other matchers to run. If a match is successful, a queued error

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/26/2016 07:03 AM, Bernd Schmidt wrote: On 08/01/2016 03:42 AM, Segher Boessenkool wrote: This is the second version. Concern was renamed to component, and all other comments were addressed (I hope). Not really, I'm afraid. There still seems to be no detailed explanation of the

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On Fri, Aug 19, 2016 at 8:29 AM, Martin Sebor wrote: >> My biggest concern with this iteration is the tight integration between >> the optimization and warning. We generally avoid that kind of tight >> integration such that enabling the warning does not affect the >>

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 06/08/2016 03:18 AM, Bernd Schmidt wrote: On 06/08/2016 03:47 AM, Segher Boessenkool wrote: + /* regrename creates wrong code for exception handling, if used together + with separate shrink-wrapping. Disable for now, until we have + figured out what exactly is going on. */

Go patch committed: add abstraction layer for SHA1 checksum code

This patch by Than McIntosh adds an abstraction layer for the SHA1 checksum code in the Go frontend. This breaks a dependency of the gofrontend on libiberty, and thus adds another separation between the gofrontend code and GCC proper. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On 09/09/2016 09:04 AM, Segher Boessenkool wrote: On Fri, Sep 09, 2016 at 12:58:11PM +0200, Bernd Schmidt wrote: Hmm? The problem is that you can't generally emit a save/restore independent of placement, because you may not know which offset to use from whichever base register. But these

Re: [PATCH] PR fortran/77406

On Wed, Aug 31, 2016 at 05:14:43PM -0700, Steve Kargl wrote: > > 2016-09-03 Steven G. Kargl > > PR fortran/77406 > * interface.c (gfc_compare_interfaces): Fix detection of ambiguous > interface involving alternate return. > (check_interface1):

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 09:40 AM, Segher Boessenkool wrote: So I think sticking with this as a design decision makes sense -- does it impact the issue around running a particular component's prologue more than once? I don't follow, sorry; could you rephrase? Nevermind -- my question has been resolved.

Re: Define TS 18661-1 type width macros in and

On Fri, 9 Sep 2016, Bernd Edlinger wrote: > Hi, > > just a nit: > > +Defined to the widths of the corresponding types. They exist to make > +the implementations of @file{limits.h} and @file{stdint.h} make > +correctly. > > Defined to the bit widths ... > > They exist to make the

Re: Define TS 18661-1 type width macros in and

Hi, just a nit: +Defined to the widths of the corresponding types. They exist to make +the implementations of @file{limits.h} and @file{stdint.h} make +correctly. Defined to the bit widths ... They exist to make the implementations of ... behave correctly. Bernd.

Go patch committed: remove dependence on libiberty hex_value

This patch by Than McIntosh removes the dependence of the Go frontend on the hex_value array from libiberty. This is a step toward breaking the links between the gofrontend code proper on GCC. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index:

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 10:57 AM, Segher Boessenkool wrote: On Fri, Sep 09, 2016 at 10:48:30AM -0600, Jeff Law wrote: and even allows them to be executed more than once, if that is cheaper. This is the part that I'm still struggling with. The usual example: 1 |\ | \ | 2 | / |/ 3 |\ | \ | 4 | / |/

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/16 11:35, Florian Weimer wrote: > On 09/07/2016 08:32 PM, Bernd Edlinger wrote: >> interesting. I just tried the test case from PR 77330 with _Decimal128. >> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with >> gcc-7.0.0. > > Recent GCC versions rely on struct

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 10:49 AM, Segher Boessenkool wrote: On Fri, Sep 09, 2016 at 09:59:03AM -0600, Jeff Law wrote: On 09/09/2016 09:17 AM, Segher Boessenkool wrote: On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote: So can you expand on the malloc example a bit -- I'm pretty sure I understand

Define TS 18661-1 type width macros in and

TS 18661-1 defines and macros for widths of standard integer types and the typedefs defined in, or whose limits are defined in, . (The connection to the main floating-point subject matter of TS 18661-1 is that these are intended to be used with the fromfp functions to convert from floating

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, Sep 09, 2016 at 10:48:30AM -0600, Jeff Law wrote: > and even allows them to be executed more than once, if that is > >cheaper. > This is the part that I'm still struggling with. The usual example: 1 |\ | \ | 2 | / |/ 3 |\ | \ | 4 | / |/ 5 where 2 and 4 need a certain prologue

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On 09/09/2016 09:33 AM, Segher Boessenkool wrote: On Thu, Sep 08, 2016 at 11:20:41AM -0600, Jeff Law wrote: On 08/29/2016 03:31 AM, Bernd Schmidt wrote: On 08/01/2016 03:42 AM, Segher Boessenkool wrote: +@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS (sbitmap) +Emit

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, Sep 09, 2016 at 09:59:03AM -0600, Jeff Law wrote: > On 09/09/2016 09:17 AM, Segher Boessenkool wrote: > >On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote: > >>So can you expand on the malloc example a bit -- I'm pretty sure I > >>understand what you're trying to do, but a concrete

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 09:28 AM, Segher Boessenkool wrote: Segher's code essentially allows individual components of the prologue to sink to different points within the function rather than forcing the prologue to be sunk as an atomic unit. It also allows prologue an epilogue components to be placed in

Re: Implement -Wimplicit-fallthrough (version 8)

Hi! On Thu, Sep 01, 2016 at 03:40:49PM +0200, Marek Polacek wrote: > @@ -1749,6 +1758,16 @@ c_parser_declaration_or_fndef (c_parser *parser, bool > fndef_ok, > { >if (auto_type_p) > error_at (here, "%<__auto_type%> in empty declaration"); > + else if (specs->typespec_kind

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

On Fri, Sep 9, 2016 at 6:52 AM, Andreas Schwab wrote: > > You should use alignof(ucontext_t) instead of hardcoding 16. Fair enough. Done like so. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu, committed to mainline. Ian Index: gcc/go/gofrontend/MERGE

Re: [PATCH] PR fortran/77507

On Fri, Sep 09, 2016 at 08:13:01AM -0700, Steven G. Kargl wrote: > On Fri, Sep 09, 2016 at 01:47:40PM +0200, Paul Richard Thomas wrote: > > > > This is OK for trunk. Are you backporting any of these fixes? If so, > > you're OK to go back to 5-branch. > > > > I have a pile of *.diff files that I

Re: [PATCH 3/9] dce: Don't dead-code delete separately wrapped restores

On 09/09/2016 09:51 AM, Segher Boessenkool wrote: On Thu, Sep 08, 2016 at 11:50:56AM -0600, Jeff Law wrote: On 07/31/2016 07:42 PM, Segher Boessenkool wrote: Deleting restores (before a noreturn) that are dead confuses dwarf2cfi. 2016-06-07 Segher Boessenkool

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 09:17 AM, Segher Boessenkool wrote: On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote: So can you expand on the malloc example a bit -- I'm pretty sure I understand what you're trying to do, but a concrete example may help Bernd and be useful for archival purposes. Sure,

Re: [PATCH 3/9] dce: Don't dead-code delete separately wrapped restores

On Thu, Sep 08, 2016 at 11:50:56AM -0600, Jeff Law wrote: > On 07/31/2016 07:42 PM, Segher Boessenkool wrote: > >Deleting restores (before a noreturn) that are dead confuses dwarf2cfi. > > > >2016-06-07 Segher Boessenkool > > > > * dce.c (delete_unmarked_insns):

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On 09/09/2016 04:58 AM, Bernd Schmidt wrote: On 09/08/2016 07:20 PM, Jeff Law wrote: On 08/29/2016 03:31 AM, Bernd Schmidt wrote: How do these actually know where to save/restore registers? The frame pointer may have been eliminated, and SP isn't necessarily constant during the function. Seems

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On Thu, Sep 08, 2016 at 11:37:17AM -0600, Jeff Law wrote: > I don't have major concerns with this patch -- I'd like to see > clarification done on the ownership of the sbitmaps (ie, who allocates > and releases those objects). I'd like to see if we can get a better > introduction as well.

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, Sep 09, 2016 at 09:26:39AM -0600, Jeff Law wrote: > >>I think one of the questions (and I haven't looked through the whole > >>thread yet to see if it's answered) is why the basic shrink-wrapping > >>algorithm can't be applied to each of the prologue components -- though > >>you may have

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On Thu, Sep 08, 2016 at 11:20:41AM -0600, Jeff Law wrote: > On 08/29/2016 03:31 AM, Bernd Schmidt wrote: > >On 08/01/2016 03:42 AM, Segher Boessenkool wrote: > >>+@deftypefn {Target Hook} void > >>TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS (sbitmap) > >>+Emit prologue insns for the components

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Thu, Sep 08, 2016 at 10:58:13AM -0600, Jeff Law wrote: > >And that comment puzzles me. Surely prologue and epilogue are executed > >only once currently, so how does frequency come into it? Again - please > >provide an example. > Right, they're executed once currently. But the prologue could be

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 12:19 AM, Segher Boessenkool wrote: Thanks for looking at the patches Jeff. On Thu, Sep 08, 2016 at 10:28:59AM -0600, Jeff Law wrote: Right. Essentially Segher's patch introduces the concept of prologue components that are independent of each other and which can be

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote: > So can you expand on the malloc example a bit -- I'm pretty sure I > understand what you're trying to do, but a concrete example may help > Bernd and be useful for archival purposes. Sure, but it's big (which is the problem :-) ) > I

Re: [PATCH] PR fortran/77507

On Fri, Sep 09, 2016 at 01:47:40PM +0200, Paul Richard Thomas wrote: > > This is OK for trunk. Are you backporting any of these fixes? If so, > you're OK to go back to 5-branch. > I have a pile of *.diff files that I will someday apply to at least 6. I know I have lost a few diffs, so those

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On Fri, Sep 09, 2016 at 12:58:11PM +0200, Bernd Schmidt wrote: > Hmm? The problem is that you can't generally emit a save/restore > independent of placement, because you may not know which offset to use > from whichever base register. But these offsets aren't necessarily > constant throughout

[GCC-6][RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

On 27/05/16 15:51, Ulrich Weigand wrote: > Andre Vieira (lists) wrote: >> On 07/04/16 10:30, Andre Vieira (lists) wrote: >>> On 17/03/16 16:33, Andre Vieira (lists) wrote: On 23/10/15 12:31, Bernd Schmidt wrote: > On 10/12/2015 11:58 AM, Ulrich Weigand wrote: >> >> Index:

Re: [patch] Fix PR fortran/72743

On 2016/9/1 03:13 PM, Richard Biener wrote: > On Wed, 31 Aug 2016, Chung-Lin Tang wrote: > >> Hi Richard, Martin, >> this issue is actually sort of like PR 70856, basically the same ICE >> after IPA-ICF, due to DECL_PT_UIDs not consistent after reaching for the >> ultimate_alias_target(). >> >>

libgo patch committed: Remove remaining use of MAKECONTEXT_STACK_TOP

The definition and most uses of MAKECONTEXT_STACK_TOP in libgo were removed in https://golang.org/cl/88660043, which removed support for Solaris 8/9. One use of MAKECONTEXT_STACK_TOP was accidentally left in the source code. Remove it now. Bootstrapped and ran Go testsuite on

Re: [PATCH] avoid non-printable characters in diagnostics (c/77620, c/77521)

On Thu, 8 Sep 2016, Martin Sebor wrote: > PS I used hexadecimal based on what c-format.c does but now that > I checked more carefully how %qE formats string literals I see it > uses octal. I think hexadecimal is preferable because it avoids > ambiguity but I'm open to changing it to octal if

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

On Sep 09 2016, Ian Lance Taylor wrote: > Index: libgo/runtime/proc.c > === > --- libgo/runtime/proc.c (revision 239872) > +++ libgo/runtime/proc.c (working copy) > @@ -156,6 +156,20 @@

Re: Fwd: libgo patch committed: Use -fgo-c-header to share between Go and C

On Fri, Sep 2, 2016 at 9:27 AM, Andreas Schwab wrote: > On Sep 02 2016, Ian Lance Taylor wrote: > >> On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote: >>> >>> That breaks libgo on ia64. The problem is that _ucontext_t isn't >>>

Re: [PATCH 9/9] cse.c selftests

Hi David, > I attempted to create a reproducer for PR 71779; however I'm not yet > able to replicate the bogus cse reported there via the test case. Thanks, this is just awesome. I immediately had to try your patch. The main reason for PR 71779 was that this (insn 1047 1046 1048 (set (reg:DI

[PATCH] PR java/71917

Hi, Although libjava is currently on death row, here is a patch to (correctly) fix mips64el in the java interpreter. This restores sparc64 BE java support based on the report[1] that reverting my original patch fixes the bug (I have not rerun this on spark64 BE as we are back to the original code

Re: [PATCH] PR fortran/77507

Hi Steve, This is OK for trunk. Are you backporting any of these fixes? If so, you're OK to go back to 5-branch. Thanks for the patch Paul On 9 September 2016 at 01:49, Steve Kargl wrote: > The attached patch fixes issues with using keywords with > the

Re: [PATCH] Delete GCJ

On Tue, Sep 6, 2016 at 2:06 AM, Richard Biener wrote: > On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley wrote: >> On 05/09/16 17:15, Richard Biener wrote: >>> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley >>> wrote: As

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On 09/08/2016 07:20 PM, Jeff Law wrote: On 08/29/2016 03:31 AM, Bernd Schmidt wrote: How do these actually know where to save/restore registers? The frame pointer may have been eliminated, and SP isn't necessarily constant during the function. Seems like you'd have to calculate CFA reg/offset

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

On 26 August 2016 at 14:28, Richard Biener wrote: > On Fri, Aug 26, 2016 at 5:08 AM, Prasad Ghangal > wrote: >> On 24 August 2016 at 15:32, Richard Biener >> wrote: >>> On Mon, Aug 22, 2016 at 8:40 PM, Prasad

Re: [PATCH] PR fortran/77506

On Fri, Sep 9, 2016 at 3:13 AM, Steve Kargl wrote: > Regression tested on x86_64-*-freebsd. OK to commit? > > 2016-09-08 Steven G. Kargl > > PR fortran/77506 > * array.c (gfc_match_array_constructor): CHARACTER(len=*)

Re: [PATCH v2 0/9] Separate shrink-wrapping

Thanks for looking at the patches Jeff. On Thu, Sep 08, 2016 at 10:28:59AM -0600, Jeff Law wrote: > Right. Essentially Segher's patch introduces the concept of prologue > components that are independent of each other and which can be > shrink-wrapped separately. The degree of independence is