Re: [PATCH/AARCH64] Add scheduler for vulcan.

Hi James, > Would you mind taking a look at some of these techniques to see if you can > reduce the size of the generated automata without causing too much > trouble for code generation for Vulcan? Thanks for the review. I will look into this. with regards, Virendra Pathak On Mon, Jul 25,

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

On Tue, Jul 26, 2016 at 08:04:32PM -0400, Michael Meissner wrote: > > dg-do compile? That's not testing much then, as an executable test! > > Good catch. Hopefully, third time is a charm. I verified that changing the > dg-do compile to dg-do run did run properly on a big endian power7 (both >

Re: [Bug tree-optimization] Fix for PR71994

Hi Jeff, Thanks for your comments. * tree-ssa-reassoc.c (maybe_optimize_range_tests): Check type compatibility. I'd kind of like to see some analysis of how we've got a bool here -- ISTM it ought to have been converted it to the type of the LHS of the PHI when propagated. You are

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

On Tue, Jul 26, 2016 at 06:26:19PM -0500, Segher Boessenkool wrote: > On Tue, Jul 26, 2016 at 04:09:01PM -0400, Michael Meissner wrote: > > > Could you test all five functions please? Use multiple testcases, maybe. > > > > I decided to write an executable test rather than do more assembly tests.

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

On Tue, Jul 26, 2016 at 04:09:01PM -0400, Michael Meissner wrote: > > Could you test all five functions please? Use multiple testcases, maybe. > > I decided to write an executable test rather than do more assembly tests. The > patch to rs6000.c is unchanged, and the test now tests all of the

[PATCH 1/2] Add a STATIC_ASSERT on sizeof (struct cp_token)

On Mon, 2016-07-25 at 10:36 +0200, Richard Biener wrote: > On Fri, Jul 22, 2016 at 4:11 PM, Jakub Jelinek > wrote: > > On Fri, Jul 22, 2016 at 10:33:50AM -0400, David Malcolm wrote: > > > gcc/cp/ChangeLog: > > > * parser.h (struct cp_token): Add a STATIC_ASSERT on the > >

[PATCH 2/2] Use static_assert for STATIC_ASSERT for C++11 onwards

C++11 has a static_assert (COND, MESSAGE) which gives more readable error messages for STATIC_ASSERT than our current implementation. This patch makes us use it if __cplusplus >= 201103L There's also a provisional static_assert (COND) in C++1z, but presumably we should wait until that one is

Re: [PATCH] correct atomic_compare_exchange_n return type (c++/71675)

On 07/25/2016 05:03 AM, Renlin Li wrote: Hi Martin, I observed the following error: ERROR: gcc.dg/atomic/pr71675.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects : syntax error in target selector "target c11" for " dg-do 3 compile { target c11 } " It seems we don't have a c11 effective

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

On Tue, Jul 26, 2016 at 11:05:32AM -0500, Segher Boessenkool wrote: > > --- gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0) > > +++ gcc/testsuite/gcc.target/powerpc/float128-cmp.c (revision 0) > > @@ -0,0 +1,17 @@ > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */ > > +/* {

Re: [PATCH] Remove special streaming of builtins

On July 26, 2016 7:26:46 PM GMT+02:00, "H.J. Lu" wrote: >On Mon, Jul 25, 2016 at 4:35 AM, Richard Biener >wrote: >> >> So I needed to fix that builtins appearing in BLOCK_VARs and the >solution >> I came up with accidentially disabled streaming via the

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

On 07/23/2016 01:18 PM, Martin Sebor wrote: + /* A pair of the first non-static non-empty data members following + either the flexible array member, if found, or the zero-length + array member otherwise. AFTER[1] refers to the first such data + member of a union that the struct

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

On 26/07/16 18:11, David Malcolm wrote: gcc/ChangeLog: * gcc.c (cpp_options): Rename string to... (cpp_options_): ...this, to avoid clashing with struct in cpplib.h. It seems to me that you need this because now gcc.c includes cpplib.h via input.h, which seems wrong.

[PATCH] Fix wrong code on aarch64 due to paradoxical subreg

Hi! As described in PR 71779 and PR 70903 we have a wrong code issue on aarch64 which is triggered by a paradoxical subreg that can be created in store_bit_field_using_insv when the target has an EP_insv bitfield instruction. The attached patch changes this insn... (insn 1047 1046 1048 (set

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 26 July 2016 at 19:21, ayush goel wrote: > On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez > (lopeziba...@gmail.com) wrote: >> On 25 July 2016 at 18:18, ayush goel wrote: >> > On top of the previously filed patch for importing gnulib (the link >> > isn’t available

Re: [PATCH] Remove special streaming of builtins

On Mon, Jul 25, 2016 at 4:35 AM, Richard Biener wrote: > > So I needed to fix that builtins appearing in BLOCK_VARs and the solution > I came up with accidentially disabled streaming via the special path. > Thus the following patch removes the special-casing completely and

[PATCH GCC]Vectorize possible infinite loop by loop versioning.

Hi, This patch vectorizes possible infinite loops by versioning. It analyzes loops considered for vectorization using loop constraint facility which was introduced by previous patch; then vectorizes the loop with respect to assumptions of loop niters information; at last, it sets constraint

[Patch GCC]Support constraint flags in loop structure.

Hi, This patch adds support for constraint flags in loop structure. Different to existing boolean flags which are set by niter analyzer, constraint flag is mainly set by consumers and affects certain semantics of niter analyzer APIs. Currently niter APIs affected are

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 26 July 2016 at 14:51, ayush goel wrote: > On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez > (lopeziba...@gmail.com) wrote: >> Why the change from "fnmatch.h" to ? > > Gnulib doesn’t contain a header for fnmatch. It itself relies on > glib’c fnmatch.h I see two

Re: [PATCH] gfortran: Fix allocation of diagnostig string (was too small).

On Tue, Jul 26, 2016 at 6:42 PM, Dominik Vogt wrote: > The attached patch fixes an out of bound write to memory allocated > with alloca() on the stack. This rarely ever happened because on > one hand -fbounds-check needs to be enabled, and on the other hand > alloca()

[PATCH 3/3] c-format.c: suggest the correct format string to use (PR c/64955)

This adds fix-it hints to c-format.c so that it can (sometimes) suggest the format string the user should have used. The patch adds selftests for the new code in c-format.c. These selftests are thus lang-specific. This is the first time we've had lang-specific selftests, and hence the patch

[PATCH 1/3] (v2) On-demand locations within string-literals

This is an updated version of: "[PATCH] RFC: On-demand locations within string-literals" https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html Changes in v2: - Tweaks to substring location selftests - Many more selftests (EBCDIC, the various wide string types, etc) - Clean up conditions

[PATCH 2/3] Use class substring_loc in c-format.c (PR c/52952)

This patch updates c-format.c to use the new class substring_loc, added in the previous patch, replacing location_column_from_byte_offset. Hence with this patch, Wformat can underline the precise erroneous format string in many more cases. The patch also introduces two new functions for emitting

Re: [PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

On Tue, Jul 26, 2016 at 11:23:38AM -0400, Michael Meissner wrote: > When I originally developed the IEEE 128-bit floating point support, the > emulation routines in libgcc did not raise errors on signalling NaNs. In the > course of adding full support for IEEE 128-bit floating point, we now have

Re: [Patch, testuite, committed] Fix some more tests that fail for non 32-bit int targets

On Jul 26, 2016, at 1:08 AM, Senthil Kumar Selvaraj wrote: > Is the below patch ok? Ok. Thanks. Such changes are trivial, usual and customary.

Re: [PATCH 2/2][v4] Drop excess size used for run time allocated stack variables.

Finally a patch that works and is simple. Bootstrapped and regression tested on s390, s390x biarch and x86_64. The new patch exploits the known alignment of (stack pointer + STACK_DYNAMIC_OFFSET) as described earlier (see below). I think that is the right way to get rid of the extra allocation.

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

Hi Richard, It turned out that the patch proposed by you does not work properly for nested loop. If we slightly change pr70729.cc to (non-essential part is omitted void inline Ss::foo (float w) { #pragma omp simd for (int i=0; i

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/22/16 14:49, Bernd Edlinger wrote: > > Hmm, cough... > > Boot-strap and reg-test was OK, but... > > I just noticed that the new built-ins do not quite work as expected. > > First with C++ there is no warning in this example although the > parameters are different: > > cat test2.C > extern

[PATCH] gfortran: Fix allocation of diagnostig string (was too small).

The attached patch fixes an out of bound write to memory allocated with alloca() on the stack. This rarely ever happened because on one hand -fbounds-check needs to be enabled, and on the other hand alloca() used to allocate a few bytes extra most of the time so most of the time the excess write

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

2016-07-26 18:26 GMT+03:00 Jeff Law : > On 07/26/2016 03:57 AM, Ilya Enkovich wrote: >>> >>> >>> Ilya, what's the fundamental reason why we need to run >>> if-conversion again? Yes, I know you want to if-convert the >>> epilogue, but why? >>> >>> What are the consequences of not

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On 07/26/2016 03:57 AM, Ilya Enkovich wrote: Ilya, what's the fundamental reason why we need to run if-conversion again? Yes, I know you want to if-convert the epilogue, but why? What are the consequences of not doing if-conversion on the epilogue? Presumably we miss a vectorization

Re: [PATCH 2/6] use auto_sbitmap in various places

On 07/25/2016 07:55 PM, Trevor Saunders wrote: On Mon, Jul 25, 2016 at 11:18:07AM -0600, Jeff Law wrote: On 07/24/2016 05:44 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2016-07-24 Trevor Saunders

[PATCH], Fix PR 71869, Correctly implement isgreater, etc. on PowerPC __float128

When I originally developed the IEEE 128-bit floating point support, the emulation routines in libgcc did not raise errors on signalling NaNs. In the course of adding full support for IEEE 128-bit floating point, we now have added exception signaling support in the library. This means the

Re: [Bug tree-optimization] Fix for PR71994

On 07/25/2016 09:13 PM, kugan wrote: Hi, For testcase in pr71994, type of bb conditional result and the type of the PHI stmt are different (as om.0_1 is int and the first PHI argument is _bool; PHI stmt uses a constant zero that comes from edge 2). Therefore when we optimize final range test

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Tue, 26 Jul 2016, Richard Sandiford wrote: > Richard Biener writes: > > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > > > >> Hi, > >> The attached patch tries to fix PR71078. > >> I am not sure if I have got the converts right. > >> I put (convert? @0) and (convert1?

[AArch64] Handle HFAs of float16 types properly

Hi, It looks like we've not been handling structures of 16-bit floating-point data correctly for AArch64. For some reason we end up passing them packed in to integer registers. That is to say, on trunk and GCC 6, for: struct x { __fp16 x[4]; }; __fp16 foo1 (struct x x) {

RE: [PATCH 3/4] Add support to run auto-vectorization tests for multiple effective targets

Hi, > On May 5, 2016, at 8:14 AM, Robert Suchanek > wrote: > > > > I'm resending this patch as it has been rebased and updated. I reverted a > change > > to check_effective_target_vect_call_lrint procedure because it does not use > > cached result. > > Ok. > >

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote: > On 25 July 2016 at 18:18, ayush goel wrote: > > On top of the previously filed patch for importing gnulib (the link > > isn’t available on the archive yet, however this contains some of the > > information: > >

Re: [patch] Get rid of stack trampolines for nested functions

> So i think with the various nits I pointed out the target independent > stuff is good to go on the trunk. Then you can just iterate with the > target guys to get those wrapped up. OK, I'll do a pass on the entire patch, post a second version with the required fixes, split into 2 parts as

Re: [RFC][IPA-VRP] Early VRP Implementation

On Tue, Jul 26, 2016 at 2:27 PM, kugan wrote: > > > Hi Riachard, > > Thanks for the review. Here is an updated patch with comments below. > >> +/* Restore/Pop all the old VRs maintained in the cond_stack. */ >> + >> +void evrp_dom_walker::finalize_dom_walker ()

Re: warn for dead function calls [4/4] stor-layout.c fallout

On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > On 26 July 2016 at 17:07, Richard Biener wrote: > > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > > > >> The following is an interesting case which broke stor-layout.c. > >> The patch warned for the following call to be

Re: warn for dead function calls [3/4] testsuite fallout

On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > On 26 July 2016 at 17:06, Richard Biener wrote: > > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > > > >> Hi, > >> The following test-cases broke due to the warning. > >> I think however the warning is right for all the

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

Richard Biener writes: > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > >> Hi, >> The attached patch tries to fix PR71078. >> I am not sure if I have got the converts right. >> I put (convert? @0) and (convert1? (abs @1)) >> to match for cases when operands's types may >> be

Re: warn for dead function calls [4/4] stor-layout.c fallout

On 26 July 2016 at 17:07, Richard Biener wrote: > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> The following is an interesting case which broke stor-layout.c. >> The patch warned for the following call to be dead from >> bit_field_mode_iterator::next_mode() to

Re: [PATCH][AArch64] Cleanup frame push/pop code

On 26/07/16 11:08, Wilco Dijkstra wrote: > This patch improves the readability of the prolog and epilog code by moving > some > code into separate functions. There is no difference in generated code. > > OK for commit? > > ChangeLog: > 2016-07-26 Wilco Dijkstra > > gcc/

Re: warn for dead function calls [3/4] testsuite fallout

On 26 July 2016 at 17:06, Richard Biener wrote: > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> Hi, >> The following test-cases broke due to the warning. >> I think however the warning is right for all the cases: >> >> a) g++.dg/tree-ssa/invalid-dom.C: >> I believe the

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

On 26 July 2016 at 17:28, Richard Biener wrote: > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > >> On 25 July 2016 at 14:32, Richard Biener wrote: >> > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: >> > >> >> Hi Richard, >> >> The attached patch tries

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On Tue, Jul 26, 2016 at 3:03 PM, Ilya Enkovich wrote: > 2016-07-26 14:51 GMT+03:00 Richard Biener : >> On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich >> wrote: >>> 2016-07-26 0:08 GMT+03:00 Jeff Law :

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

2016-07-26 14:51 GMT+03:00 Richard Biener : > On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich > wrote: >> 2016-07-26 0:08 GMT+03:00 Jeff Law : >>> On 07/25/2016 12:32 PM, Richard Biener wrote: On July 25, 2016 8:01:17

Re: [Bug tree-optimization] Fix for PR71994

On Tue, Jul 26, 2016 at 2:34 PM, kugan wrote: > Hi Richard, > > > On 26/07/16 21:48, Richard Biener wrote: >> >> On Tue, Jul 26, 2016 at 5:13 AM, kugan >> wrote: >>> >>> Hi, >>> >>> For testcase in pr71994, type of bb

[PATCH] Add mark_spam.py script

Hello. This is python script that utilizes bugzilla API and marks PRs as spam: $ ./mark_spam.py --help usage: mark_spam.py [-h] [--verbose] api_key range Mark Bugzilla issues as spam. positional arguments: api_key API key range Range of IDs, e.g. 10-23,24,25,27 optional

Re: [Bug tree-optimization] Fix for PR71994

Hi Richard, On 26/07/16 21:48, Richard Biener wrote: On Tue, Jul 26, 2016 at 5:13 AM, kugan wrote: Hi, For testcase in pr71994, type of bb conditional result and the type of the PHI stmt are different (as om.0_1 is int and the first PHI argument is _bool;

Re: [patch, avr] Fix mmcu to specs issues

On 26.07.2016 12:20, Pitchumani Sivanupandi wrote: avr-gcc expected to find the device specs in the search paths specified. But it doesn't work as expected when device specs in different place than the installed location. Example-1: avr-gcc wrongly assumes the device specs will be in first

Re: [RFC][IPA-VRP] Early VRP Implementation

Hi Riachard, Thanks for the review. Here is an updated patch with comments below. +/* Restore/Pop all the old VRs maintained in the cond_stack. */ + +void evrp_dom_walker::finalize_dom_walker () +{ + while (!cond_stack.is_empty ()) +{ + tree var = cond_stack.last ().second; +

GCC 4.9.4 Status Report (2016-07-26), branch frozen for release

The 4.9 branch is now frozen for the final GCC 4.9.4 release, I will announce GCC 4.9.4 RC1 once it has built. Richard.

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > Hi, > The attached patch tries to fix PR71078. > I am not sure if I have got the converts right. > I put (convert? @0) and (convert1? (abs @1)) > to match for cases when operands's types may > be different from outermost type like in pr71078-3.c

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > On 25 July 2016 at 14:32, Richard Biener wrote: > > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > > > >> Hi Richard, > >> The attached patch tries to fix PR70920. > >> It adds your pattern from comment 1 in the PR > >>

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich wrote: > 2016-07-26 0:08 GMT+03:00 Jeff Law : >> On 07/25/2016 12:32 PM, Richard Biener wrote: >>> >>> On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote: On 07/22/2016 05:36

Re: [Bug tree-optimization] Fix for PR71994

On Tue, Jul 26, 2016 at 5:13 AM, kugan wrote: > Hi, > > For testcase in pr71994, type of bb conditional result and the type of the > PHI stmt are different (as om.0_1 is int and the first PHI argument is > _bool; PHI stmt uses a constant zero that comes from

Re: warn for dead function calls [4/4] stor-layout.c fallout

On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > The following is an interesting case which broke stor-layout.c. > The patch warned for the following call to be dead from > bit_field_mode_iterator::next_mode() to get_mode_alignment (): > > /* Stop if the mode requires too much alignment.

Re: warn for dead function calls [3/4] testsuite fallout

On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > Hi, > The following test-cases broke due to the warning. > I think however the warning is right for all the cases: > > a) g++.dg/tree-ssa/invalid-dom.C: > I believe the call from main() to E::bar() is dead call ? Can't find this testcase. > b)

Re: warn on dead function calls [2/4] libsupc++/eh_alloc.cc fallout

On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > Many warnings for dead-calls are emitted with patch on call to > operator new in libsupc++/eh_alloc.cc, which I am not sure are correct > or false positives, for instance: > >

Re: Gimple loop splitting v2

On Mon, Jul 25, 2016 at 10:57 PM, Andrew Pinski wrote: > On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote: >> Hi, >> >> On Tue, 1 Dec 2015, Jeff Law wrote: >> >>> > So, okay for trunk? >>> -ENOPATCH >> >> Sigh :) >> Here it is. > > > I found one problem with

Re: [PATCH] Remove dead call to gimple_bb in slsr_process_phi

On Mon, Jul 25, 2016 at 9:51 PM, Bill Schmidt wrote: > Hi, > > As reported on the gcc mailing list, slsr_process_phi contains a dead call > to gimple_bb. I looked into why this wasn't noticed before, and concluded > that we don't actually need the call. To reach

[PATCH] Fix PR72517, improve vector extract RTL expansion

The following patch fixes a bug in selecting a "better" mode to do a vector extract from. The existing code was evidently written without knowing what GET_MODE_WIDER_MODE does for vector modes in the face of multiple supported vector sizes. This results in odd code-generation choices for HImode

Re: [RS6000] push_secondary_reload ICE

On Tue, Jul 26, 2016 at 03:26:55AM -0500, Segher Boessenkool wrote: > On Tue, Jul 26, 2016 at 04:09:12PM +0930, Alan Modra wrote: > > /* If this is a scalar floating point value and we want to load it into > > the > > traditional Altivec registers, do it via a move via a traditional > >

[patch, avr] Fix mmcu to specs issues

avr-gcc expected to find the device specs in the search paths specified. But it doesn't work as expected when device specs in different place than the installed location. Example-1: avr-gcc wrongly assumes the device specs will be in first identified 'device-specs' folder in prefix path. avr-gcc

[PATCH][AArch64] Cleanup frame push/pop code

This patch improves the readability of the prolog and epilog code by moving some code into separate functions. There is no difference in generated code. OK for commit? ChangeLog: 2016-07-26 Wilco Dijkstra gcc/ * config/aarch64/aarch64.c (aarch64_pushwb_pair_reg):

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

2016-07-26 0:08 GMT+03:00 Jeff Law : > On 07/25/2016 12:32 PM, Richard Biener wrote: >> >> On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote: >>> >>> On 07/22/2016 05:36 AM, Richard Biener wrote: The thing that needs work I think is re-running of

Re: [RS6000] push_secondary_reload ICE

Hi Alan, Thanks for the writeup. On Tue, Jul 26, 2016 at 04:09:12PM +0930, Alan Modra wrote: > /* If this is a scalar floating point value and we want to load it into the > traditional Altivec registers, do it via a move via a traditional > floating > point register, unless we have

Re: [Patch, testuite, committed] Fix some more tests that fail for non 32-bit int targets

Mike Stump writes: > On Jul 25, 2016, at 5:00 AM, Senthil Kumar Selvaraj > wrote: >> >> The below patch fixes tests that fail for the avr target, because they >> assume ints are atleast 32 bits wide and pointers and longs have the >> same size. >> >>

[RS6000] push_secondary_reload ICE

target.h struct secondary_reload_info has two fields that "are for the use of the backward compatibility hook", default_secondary_reload. t_icode is used to pass information from one invocation of default_secondary_reload to the next, between the targetm.secondary_reload call below in