On 03/20/2015 02:21 PM, Jason Merrill wrote:
I think we want to drop the debug_early check there entirely; the added
conditions seem to be gutting it. If is_cu_die (old_die->die_parent) is
false, then class_or_namespace_scope_p (old_die->die_parent) ought to be
true.
Jason
Good catch. I am
On Fri, 2015-03-20 at 15:52 -0500, Segher Boessenkool wrote:
> Maybe it would be nicer if the builtin-expansion code handled the copy
> from cc, instead of stacking on RTL expanders.
That would allow getting rid of the expanders completely, which
would be nice. I'd have to somehow add some type o
The attached patch allows the attempt to READ or WRITE after an EOF for legacy
code. The runtime error is suppressed for -std=legacy and -std=gnu. For
standard conformance the error is retained as is now.
Regression tested on x86-64. Test case endfile_3.f90 is updated by the patch.
OK for tr
> Please also prioritize fixing P1s and avoid pushing in risky
> fixes for P2s that might end up causing regressions. We are still
> seeing way too many changes in the IPA area (hi Honza!).
Hello :)
GCC 5 is a busy release from IPA point of view indeed. Here is a quick summary
what is still on m
I think we want to drop the debug_early check there entirely; the added
conditions seem to be gutting it. If is_cu_die (old_die->die_parent) is
false, then class_or_namespace_scope_p (old_die->die_parent) ought to be
true.
Jason
On 03/20/2015 05:03 PM, Jakub Jelinek wrote:
Hi!
Just for completeness:
On Fri, Mar 20, 2015 at 09:56:52PM +0100, Marek Polacek wrote:
+constexpr char d1 = *(&s[4] - 0); // { dg-error "array subscript out of bound"
}
+constexpr char d2 = *(&s[4] - 1);
+constexpr char d3 = *(&s[4] - 2);
+const
On 03/20/2015 01:23 PM, Jakub Jelinek wrote:
Well, but the traditional preprocessor behavior in the end is not in not
expanding macro arguments, normally they actually are expanded, but not
immediately, but because of trying to preprocess the result of preprocessing
again and again.
When traditio
Hi!
Just for completeness:
On Fri, Mar 20, 2015 at 09:56:52PM +0100, Marek Polacek wrote:
> +constexpr char d1 = *(&s[4] - 0); // { dg-error "array subscript out of
> bound" }
> +constexpr char d2 = *(&s[4] - 1);
> +constexpr char d3 = *(&s[4] - 2);
> +constexpr char d4 = *(&s[4] - 3);
> +conste
On Thu, 2015-03-12 at 14:20 +0100, Richard Biener wrote:
> After noticing tree-parloop.c passing crap to split_block (a tree
> rather than a gimple or an rtx) I noticed those CFG functions simply
> take void * pointers. The following patch fixes that and adds
> two overloads, one for GIMPLE use an
On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
> On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
> >Though, a question is if we do (or, if we don't and should) reject say
> >constexpr char s[] = "abc";
> >constexpr int j = 4;
> >constexpr char c = *(&s[j] - 2);
> >because there was out
Hi Peter,
Nice patch. Some minor things...
On Fri, Mar 20, 2015 at 02:27:40PM -0500, Peter Bergner wrote:
> Index: gcc/config/rs6000/htm.md
> ===
> --- gcc/config/rs6000/htm.md (revision 221519)
> +++ gcc/config/rs6000/htm.md (wo
ok thanks.
David
On Fri, Mar 20, 2015 at 1:40 PM, Teresa Johnson wrote:
> After offline discussions with David, I changed to the approach of
> generating __tls_init for the aux module, but then modifying the LIPO
> code to allow it to be statically promoted and treated as an aux
> function as a
After offline discussions with David, I changed to the approach of
generating __tls_init for the aux module, but then modifying the LIPO
code to allow it to be statically promoted and treated as an aux
function as a special case of an artificial decl. That works well. New
patch below. Fixed the tes
PR target/64579 exposes a bug in the definitions of the HTM builtins
and associated define_expands. All of the HTM builtins were defined to
return true on success and false on failure, but that only makes sense
for the tbegin builtin (which is unchanged here). It makes more sense
for the other bu
On 03/10/2015 02:59 PM, Tobias Burnus wrote:
This patch completes the description of the coarray library functions, invoked
for -fcoarray=lib.
OK for the trunk?
(The currently documented functions can be seen at
https://gcc.gnu.org/onlinedocs/gfortran/Coarray-Programming.html )
Tobias
OK, th
On 03/12/2015 12:18 AM, Tobias Burnus wrote:
There are two groups of features which are not properly implemented with remote
access:
* "caf(:)[i]%a" might have a byte stride which is not compatible with the size
of "a". (Fix: new array descriptor.)
* All access which involves dereferencing point
On 03/20/2015 12:17 PM, Sebastian Pop wrote:
Richard Biener wrote:
On Thu, Mar 19, 2015 at 8:54 PM, Sebastian Pop wrote:
Richard Biener wrote:
please instead fixup after copy_bbs in duplicate_seme_region.
Thanks for the review.
Attached patch that does not modify copy_bbs.
Fixes make check
Richard Biener wrote:
> On Thu, Mar 19, 2015 at 8:54 PM, Sebastian Pop wrote:
> > Richard Biener wrote:
> >> please instead fixup after copy_bbs in duplicate_seme_region.
> >>
> >
> > Thanks for the review.
> > Attached patch that does not modify copy_bbs.
> > Fixes make check in hmmer and make ch
> The patch is implemented within libcpp: any such conflict markers were
> typically injected by tools that work on raw lines of unpreprocessed
> text, so it seemed fitting to do it there.
>
> The error can be suppressed with -fno-detect-conflict-markers for
> the case where you're using the compil
Hi Jason.
For class scoped static functions:
class C {
public:
static void moo () {}
};
...we are calling gen_subprogram on moo() the usual handful of times
(during early dwarf): once as a member of C and once becaus
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64366
The patch was bootstrapped on x86/x86-64, power64, and aarch64.
Committed as rev.221541.
2015-03-20 Vladimir Makarov
PR rtl-optimization/64366
* lra.c (lra_update_insn_regno_info): Consider
> > gcc/
> > 2015-03-11 Yvan Roux
> >
> > Backport from trunk r216841.
> > 2014-10-29 Martin Liska
> >
> > PR ipa/63587
> > * cgraphunit.c (cgraph_node::expand_thunk): Only VAR_DECLs are put
> > to local declarations.
> > * function.c (add_local_decl): Implementation m
On Fri, 20 Mar 2015, David Malcolm wrote:
> I believe that the presense of these markers in source code is almost
> always a bug (are there any GCC frontends in which the markers are
> parsable as something valid?)
Well, obviously they are valid inside #if 0, strings (where you have a
test, thou
> gcc/ChangeLog:
>
> 2015-03-20 Martin Liska
> Jakub Jelinek
>
> * config/i386/i386.c (def_builtin): Set deferred_isa_values for
> masks that can potentially include a builtin.
> (ix86_add_new_builtins): Introduce fast filter for isa values
> that cannot tri
Somewhere in the hurricane of debug-early patches of the past month, we
fixed this and forgot verify it was still an issue.
Types are no longer appearing in limbo in late dwarf, so there is no
reason to special case this.
Tested with the guality.exp framework and the gdb testsuite.
Committed
On Wed, Mar 18, 2015 at 12:08:47PM +0100, Richard Biener wrote:
> Did you double-check if there are any differences in generated code?
> Esp. the SPEC INT benchmarks look odd - they don't contain any
> FP code.
SpecINT does contain some amount of floating point. Off the top of my head:
1) B
Jason Merrill writes:
> On 03/20/2015 12:48 PM, Jakub Jelinek wrote:
>> On Fri, Mar 20, 2015 at 12:30:44PM -0400, Jason Merrill wrote:
>>> On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
__has_{cpp_,}attribute builtin macros are effectively function-like macros
taking one argument (and the
On Fri, Mar 20, 2015 at 01:15:52PM -0400, Jason Merrill wrote:
> On 03/20/2015 12:48 PM, Jakub Jelinek wrote:
> >On Fri, Mar 20, 2015 at 12:30:44PM -0400, Jason Merrill wrote:
> >>On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
> >>>__has_{cpp_,}attribute builtin macros are effectively function-like m
On 03/20/2015 12:48 PM, Jakub Jelinek wrote:
On Fri, Mar 20, 2015 at 12:30:44PM -0400, Jason Merrill wrote:
On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
__has_{cpp_,}attribute builtin macros are effectively function-like macros
taking one argument (and the ISO preprocessor expands macros in the
On 20/03/15 17:13 +, James Greenhalgh wrote:
This patch just disables the check in this test case for
"unused" when testing for ARM, which resolves the issue.
Tested on arm-none-linux-gnueabihf to confirm it clears the FAIL.
OK, thanks.
Hi,
As discussed on IRC, glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h
for ARM has a field named "unused", in a struct which looks like this:
struct _libc_fpstate
{
struct
{
unsigned int sign1:1;
unsigned int unused:15;
unsigned int sign2:1;
unsigned int
On Thu, 12 Mar 2015, Marek Polacek wrote:
> 2015-03-12 Marek Polacek
>
> PR c/65345
> * c-decl.c (set_labels_context_r): New function.
> (store_parm_decls): Call it via walk_tree_without_duplicates.
> * c-typeck.c (convert_lvalue_to_rvalue): Use create_tmp_var_raw
>
Dear Andre,
This patch fixes the issues I have reported in my previous mail. In addition it
allows the Metcalf’s oo.f90 to compiles and gives sensible results at run time
(yes, I have noticed the patch to fix the memory leak, and it works).
I have a two comments:
The list of the (partially) fi
Hi all,
This is a simple patch to enable two simplifications for UNSIGNED_FLOAT
expression.
For the following rtx patterns, they can be simplified when the integer
x can be
represented in float mode without precision loss:
float_truncate (float x) --> float x
float_extend (float x) --> float
Just cleaning up some left over or non-applicable comments.
Committed to branch.
commit b783ed568b4b56d42f4203ce32d964104be6a368
Author: Aldy Hernandez
Date: Fri Mar 20 09:49:23 2015 -0700
Minor cleanups.
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index c538d2e..c4ffcf2 100644
--- a/gc
On Fri, Mar 20, 2015 at 12:30:44PM -0400, Jason Merrill wrote:
> On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
> >__has_{cpp_,}attribute builtin macros are effectively function-like macros
> >taking one argument (and the ISO preprocessor expands macros in the argument
> >which is IMHO desirable), bu
On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
__has_{cpp_,}attribute builtin macros are effectively function-like macros
taking one argument (and the ISO preprocessor expands macros in the argument
which is IMHO desirable), but the traditional preprocessor has been crashing
on them or reporting er
Hi all,
This comment in expmed.c talks about multiplying by a value that ends in
...01 by doing the T-1 multiplication first and then
adding T to get the final result. But the typo says '1' instead of 'T'.
Similarly with the T+1, -T case.
I'll apply this patch on Monday unless someone objects
Various tools that operate on source code files will inject markers
into them when an unfixable conflict occurs in a merger.
There appears to be no blessed standard for these conflict markers,
but an ad-hoc convention is for 7 '<' , '=', or '>' characters at
the start of a line, followed optionall
On Fri, Mar 20, 2015 at 11:15:30AM -0400, Jason Merrill wrote:
> On 03/20/2015 11:11 AM, Jakub Jelinek wrote:
> >>&s[3] is the address of the terminal \0.
> >
> >Yeah, sure. But the above testcase does &s[4], which is out of bounds
> >arithmetics
>
> But since &s[3] is the address of an element o
On Thu, Mar 19, 2015 at 10:38 PM, Xinliang David Li wrote:
> On Thu, Mar 19, 2015 at 9:57 PM, Teresa Johnson wrote:
>> On Thu, Mar 19, 2015 at 8:00 PM, Xinliang David Li
>> wrote:
>>> ok -- then there is an over assertion in get_local_tls_init_fn. The
>>> method can be called for aux module --
On 03/20/2015 11:11 AM, Jakub Jelinek wrote:
&s[3] is the address of the terminal \0.
Yeah, sure. But the above testcase does &s[4], which is out of bounds
arithmetics
But since &s[3] is the address of an element of the array (the NUL),
&s[4] is one-past-the-end, which is fine. &s[5] would
On Fri, Mar 20, 2015 at 11:02:59AM -0400, Jason Merrill wrote:
> On 03/20/2015 10:59 AM, Jakub Jelinek wrote:
> >On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
> >>On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
> >>>Though, a question is if we do (or, if we don't and should) reject sa
On 03/20/2015 10:59 AM, Jakub Jelinek wrote:
On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
Though, a question is if we do (or, if we don't and should) reject say
constexpr char s[] = "abc";
constexpr int j = 4;
constexpr char c = *(&
On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
> On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
> >Though, a question is if we do (or, if we don't and should) reject say
> >constexpr char s[] = "abc";
> >constexpr int j = 4;
> >constexpr char c = *(&s[j] - 2);
> >because there was out
On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
Though, a question is if we do (or, if we don't and should) reject say
constexpr char s[] = "abc";
constexpr int j = 4;
constexpr char c = *(&s[j] - 2);
because there was out of bound access in there.
I don't see an out-of-bound access in this exampl
Hello,
the problem here is that for cases of vla-array-types, the types don't
get finally layouted in build_cplus_array_type. So the type-alignment
isn't set in such cases for the resulting type.
ChangeLog
2015-03-20 Kai Tietz
PR c++/65390
* tree.c (strip_typedefs): Ignore alignment
On 03/20/2015 08:59 AM, Richard Biener wrote:
Hum... variant types should have the same TYPE_FIELDs as the main variant.
So why's the variants TYPE_FIELDS NULL?
Because we're in the middle of parsing the class, so we haven't called
fixup_type_variants to copy TYPE_FIELDS yet.
The patch is OK
Hi all,
I was now asked several times when this basic version for deferred length char
arrays in unlimited polymorphic entities will be backported to 4.9. Please
note, I was not asked *if* I backport it, but *when*.
So here it is. The patch is essential the same like for 5.0, besides that some
fo
On 03/20/2015 12:24 PM, Jakub Jelinek wrote:
On Fri, Mar 20, 2015 at 11:33:09AM +0100, Martin Liška wrote:
@@ -30670,6 +30673,20 @@ def_builtin_const (HOST_WIDE_INT mask, const char
*name,
static void
ix86_add_new_builtins (HOST_WIDE_INT isa)
{
+ /* Last cached isa value. */
+ static H
Hi all,
during checking that pr 61275 is really fixed, I found a indentation issue and
a piece of my former code, that could be done nicer and more readable. This
patch addresses both these issues.
Bootstraps and regtests ok on x86_64-linux-gnu/F20.
Ok for trunk?
Regards,
Andre
--
Andr
On Fri, Mar 20, 2015 at 01:59:14PM +0100, Richard Biener wrote:
> Hum... variant types should have the same TYPE_FIELDs as the main variant.
> So why's the variants TYPE_FIELDS NULL?
That is a good question, but unfortunately, even after hours trying to find
that out, I don't know. I thought that
On 18/03/15 18:16 +, Jonathan Wakely wrote:
This adds the abi_tag attribute in a few places it's missing, so that
-Werror=abi-tag builds will work after Jason's upcoming patches to
make functions inherit the tag from their return type.
Jason suggested using an inline namespace instead of ta
On Fri, Mar 20, 2015 at 1:48 PM, Marek Polacek wrote:
> The problem turned out to be that lookup_anon_field was not able to find
> a FIELD_DECL so we passed NULL member to finish_class_member_access_expr
> and that SEGVs on that. The reason is that "const struct C" object does
> not have any fiel
The problem turned out to be that lookup_anon_field was not able to find
a FIELD_DECL so we passed NULL member to finish_class_member_access_expr
and that SEGVs on that. The reason is that "const struct C" object does
not have any fields; for that, we need to look at the main variant. So
fixed by
On Fri, Mar 20, 2015 at 01:30:48PM +0100, Tom de Vries wrote:
> On 20-03-15 12:57, Jakub Jelinek wrote:
> >>@@ -5569,6 +5569,7 @@ expand_omp_taskreg (struct omp_region *region)
> >>>/* Inform the callgraph about the new function. */
> >>>DECL_STRUCT_FUNCTION (child_fn)->curr_proper
On 20-03-15 12:57, Jakub Jelinek wrote:
@@ -5569,6 +5569,7 @@ expand_omp_taskreg (struct omp_region *region)
>/* Inform the callgraph about the new function. */
>DECL_STRUCT_FUNCTION (child_fn)->curr_properties =
cfun->curr_properties;
>cgraph_node::add_new_function (chi
On Fri, Mar 20, 2015 at 12:38:51PM +0100, Richard Biener wrote:
>
> This removes a road-block towards fixing PR64715 - the gimplifier
> performing an undesired "simplification" of &X + CST to
> &MEM[&X, CST]. IMHO this is premature there.
>
> The fallout is small - two testcases are no longer si
Status
==
The trunk is open for regression and documentation fixes only.
We've come a long way towards the release criteria of zero P1 bugs.
There are still a few remaining P1s though and we are targeting
for a GCC 5 release candidate in the first week of April (given
those P1 bugs are eithe
On Fri, Mar 20, 2015 at 11:27 AM, Thomas Preud'homme wrote:
> Sorry, I missed the parenthesis. REG_P needs indeed to be kept. I'd be
> tempted to use !HARD_REGISTER_P instead since REG_P is already
> checked but I don't mind either way.
I put the cprop_reg_p check there instead of !HARD_REGISTER_P
On Fri, Mar 20, 2015 at 12:37:11PM +0100, Tom de Vries wrote:
> Mark omp thread functions as parallelized
>
> 2015-03-20 Tom de Vries
>
> PR tree-optimization/65458
> * cgraph.c (cgraph_node::dump): Handle parallelized_function field.
> * cgraph.h (cgraph_node): Add paralleli
On 19-03-15 12:05, Tom de Vries wrote:
On 18-03-15 18:22, Tom de Vries wrote:
Hi,
this patch fixes PR65460.
The patch marks offloaded functions as parallelized, which means the parloops
pass no longer attempts to modify that function.
Updated patch to postpone mark_parallelized_function unti
This removes a road-block towards fixing PR64715 - the gimplifier
performing an undesired "simplification" of &X + CST to
&MEM[&X, CST]. IMHO this is premature there.
The fallout is small - two testcases are no longer simplified at -O0
(who cares), and devirt-40.C shows that SCEV adheres too clo
On 19/03/15 21:50 +0100, François Dumont wrote:
On 18/03/2015 19:16, Jonathan Wakely wrote:
Preparing this patch reminded me that we currently have two copies of
the Catalog_info and Catalogs code in the unnamed namespace in
config/locale/gnu/messages_members.cc, one using the old string and
on
On 19-03-15 12:29, Jakub Jelinek wrote:
On Thu, Mar 19, 2015 at 12:27:04PM +0100, Tom de Vries wrote:
Sure, I can update that, I'll retest and repost.
Yes, please. Probably the tree-parloops.h include will not be needed either
then.
Updated to eliminate mark_parallelized_function.
Bootstr
On Fri, Mar 20, 2015 at 11:33:09AM +0100, Martin Liška wrote:
> @@ -30670,6 +30673,20 @@ def_builtin_const (HOST_WIDE_INT mask, const char
> *name,
> static void
> ix86_add_new_builtins (HOST_WIDE_INT isa)
> {
> + /* Last cached isa value. */
> + static HOST_WIDE_INT last_tested_isa_value =
On 03/20/2015 01:10 AM, Jan Hubicka wrote:
Hi.
Explanation of the patch is introduced.
thanks
mask &= ~OPTION_MASK_ISA_64BIT;
if (mask == 0
@@ -30670,6 +30673,14 @@ def_builtin_const (HOST_WIDE_INT mask, const char
*name,
static void
ix86_add_new_builtins (HOST_WIDE_IN
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> I noticed in do_local_cprop you replace >= FIRST_PSEUDO_REGISTER by
> cprop_reg_p without removing the REG_P as well.
Sorry, I missed the parenthesis. REG_P needs indeed to be kept.
This is a regression present on the mainline: gigi gets confused translating a
volatile access type whose designated type has its elaboration delayed.
Fixed thusly, tested on x86_64-suse-linux, applied on the mainline.
2015-03-20 Eric Botcazou
PR ada/65451
* gcc-interface/ut
On 22-02-15 18:37, Arnaud Charlet wrote:
While generating gnat-style.info, we see these warnings:
...
src/gcc/doc/include/fdl.texi:33: warning: node `Index' is next for
`GNU Free Documentation License' in menu but not in sectioning
src/gcc/doc/include/fdl.texi:33: warning: node `Top' is up for `G
On Fri, Mar 20, 2015 at 9:50 AM, Andreas Krebbel
wrote:
> On 03/18/2015 12:04 PM, Richard Biener wrote:
>> On Tue, Mar 17, 2015 at 7:29 PM, Jeff Law wrote:
>>> On 03/17/2015 02:17 AM, Andreas Krebbel wrote:
Just to have some numbers I did run a -j1 GCC bootstrap twice with and
On Thu, Mar 19, 2015 at 11:40 PM, Tom de Vries wrote:
> [ was: Re: [PATCH, stage1] Make parloops gate more strict ]
> On 19-03-15 10:00, Richard Biener wrote:
Yeah - it makes the -fdump-passes "hack" more pervasive throughout
>>the compiler.
>>
>>I suppose it should instea
On Thu, Mar 19, 2015 at 8:54 PM, Sebastian Pop wrote:
> Richard Biener wrote:
>> please instead fixup after copy_bbs in duplicate_seme_region.
>>
>
> Thanks for the review.
> Attached patch that does not modify copy_bbs.
> Fixes make check in hmmer and make check RUNTESTFLAGS=tree-ssa.exp
>
> Full
Ping.
On 11 March 2015 at 16:38, Yvan Roux wrote:
> Hi,
>
>
PR ipa/65236
* cgraphunit.c (cgraph_node::expand_thunk): Enable return slot
opt.
>>
>> This bugfix adds ipa-icf-6.C test which failed on 4.9 branch as
>> ipa-icf is not backported on that branch. I
On 03/18/2015 12:04 PM, Richard Biener wrote:
> On Tue, Mar 17, 2015 at 7:29 PM, Jeff Law wrote:
>> On 03/17/2015 02:17 AM, Andreas Krebbel wrote:
>>>
>>>
>>> Just to have some numbers I did run a -j1 GCC bootstrap twice with and
>>> without the patch on x86_64.
>>> Best results for both are:
>>>
Hi Steven,
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Friday, March 20, 2015 3:54 PM
>
>
> What I meant, is that I believe the tests are already done in
> hash_scan_set and should be redundant in cprop_insn (i.e. the test can
> be replaced with gcc_[checking_]assert).
Ok.
>
Hi,
Identifiers read with input_identifier miss IDENTIFIER_TRANSPARENT_ALIAS bit.
We always expect it for instrumentation clones, thus restore it input_cgraph_1.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
2015-03-20 Ilya Enkovich
* lto-cgra
On Tue, Feb 17, 2015 at 3:51 AM, Thomas Preud'homme wrote:
>> > - else if (REG_P (src)
>> > - && REGNO (src) >= FIRST_PSEUDO_REGISTER
>> > - && REGNO (src) != regno)
>> > - {
>> > - if (try_replace_reg (reg_used, src, insn))
>> > + else if (src_r
78 matches
Mail list logo
