On 07/12/2011 06:37 PM, Rainer Orth wrote:
The next easy step in toplevel libgcc migration is moving
i386/crtprec.c. I noticed that -mpc{32, 64, 80} wasn't supported on
Solaris/x86 yet and corrected that. The only testcase using the switch
was adapted to also do so on Darwin/x86 (which already
On 07/12/2011 06:45 PM, Rainer Orth wrote:
+crt0.o: $(srcdir)/config/i386/netware-crt0.c
+ $(crt_commpile) $(CRTSTUFF_T_CFLAGS) -c $<
Typo here. Otherwise looks good, thanks.
Paolo
> > FWIW, elsewhere in gcc we use "continue;" for empty loop bodies.
>
> I think I've never run into this idiom in about a decade of work on GCC. :-)
Nor have I. I'm used to seeing just a ";" on its own line.
Autogenerate pph.map instead of manually maintaining it.
This change avoids tests that appear to pass only because
the pph.map file was not properly updated and the pph file was never read.
We will need to update this automation
when we start PPHing the C++ standard library.
(g++.dg/pph/pph.exp)
R
The libgo tests expect to be run in the order in which they appear in
the source file. This patch uses -fno-toplevel-reorder to make sure
that happens. Bootstrapped and ran libgo tests on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 8020981d5461 libgo/testsuite/gotest
--- a/lib
Hi,
-mfused-madd is deprecated and -mfma is undocumented. This patch
removes -mfused-madd and documents -mfma. OK for trunk?
Thanks.
H.J.
---
2011-07-12 H.J. Lu
* doc/invoke.texi (x86): Remove -mfused-madd and add -mfma.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
On Tue, Jul 12, 2011 at 3:32 PM, Diego Novillo wrote:
> On 11-07-12 16:43 , Gabriel Charette wrote:
>
>> Even if this doesn't break tests anymore, we probably still want this,
>> no point adding stuff to the pph image that is not needed...
>
> Actually, the reverse is true. We want to write out t
On Tue, Jul 12, 2011 at 3:25 PM, Diego Novillo wrote:
> On 11-07-12 16:34 , Gabriel Charette wrote:
>
>> We probably want pph_register_decl_in_symtab to be inline as it does
>> so little now.
>
> It doesn't really matter all that much. Given that it's a static function,
> the compiler will inline
e if it is
easily possible using current option handling framework.
Bootstrapped/regtested on x86_64-linux, e.g. cc1plus has just a few
different DW_AT_producers (sort|uniq -c|sort -n -r output):
322 (indirect string, offset: 0x4fb3): GNU C 4.7.0 20110712 (experimental)
-mtune=generic -m
On 11-07-11 18:53 , Delesley Hutchins wrote:
This patch fixes get_canonical_lock_expr so that it works on lock
expressions that involve a MEM_REF. Gimple code can use either
MEM_REF or INDIRECT_REF in many expressions, and the choice of which
to use is somewhat arbitrary. The canonical form of
This patch to the C frontend disables warnings about -Wstrict-overflow
when handling expressions which will not be evaluated. This fixes PR
49705.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for mainline?
Ian
gcc/c-family:
2011-07-12 Ian Lance Taylor
PR middle-end/4970
On 11-07-12 16:43 , Gabriel Charette wrote:
Even if this doesn't break tests anymore, we probably still want this,
no point adding stuff to the pph image that is not needed...
Actually, the reverse is true. We want to write out the IL exactly as
the original parser emitted it. There are thi
On 06/07/11 11:11, Xinyu Qi wrote:
> Hi,
>
> It is the first part of iWMMXt maintenance.
>
> *config/arm/arm.c (arm_option_override):
> Enable iWMMXt with VFP. iWMMXt and NEON are incompatible. iWMMXt
> unsupported under Thumb-2 mode.
> (arm_expand_binop_builtin): Accept immediate op (with mod
On 11-07-12 16:34 , Gabriel Charette wrote:
We probably want pph_register_decl_in_symtab to be inline as it does
so little now.
It doesn't really matter all that much. Given that it's a static
function, the compiler will inline it (or not) as an optimization. The
'inline' keyword is more a
On 07/12/2011 02:22 PM, harsha.jaga...@amd.com wrote:
> We would like to propose changing AVX generic mode tuning to generate 128-bit
> AVX instead of 256-bit AVX.
You indicate a 3% reduction on bulldozer with avx256.
How does avx128 compare to -mno-avx -msse4.2?
Will the next AMD generation have
We would like to propose changing AVX generic mode tuning to generate 128-bit
AVX instead of 256-bit AVX. As per H.J's suggestion, we have reviewed the
various tuning choices made for generic mode with respect to AMD's upcoming
Bulldozer processor. At this moment, this is the most significant chang
On 07/12/2011 12:34 PM, Richard Sandiford wrote:
- HOST_WIDE_INT num_type_elements, num_initialized_elements;
+ bool complete_p = true;
+ HOST_WIDE_INT num_elts = 0;
Let's use num_split_elts so that it's clearer that we're counting the
number of elements that have been initialized outside t
Hi Dave,
Could you split this further into a patch that deals with the
case for disabling MCR memory barriers for Thumb1 so that it
maybe backported to the release branches ? I have commented inline
as well.
Could you also provide a proper changelog entry for this that will
also help with review
A few more notes:
+ if (DECL_NAMESPACE_SCOPE_P (decl))
+ {
+ if (!check_literal_operator_args(decl,
+&long_long_unsigned_p, &long_double_p))
+ {
+ error ("%qD has illegal argument list", decl);
+ return
> FWIW, elsewhere in gcc we use "continue;" for empty loop bodies.
I think I've never run into this idiom in about a decade of work on GCC. :-)
Sometimes there is a comment after the ; on the line, but this is somewhat
redundant IMO. Maybe we should simply ban loops with emtpy bodies.
--
Eric
Hello.
This patch turns TARGET_CLASS_MAX_NREGS macro into a hook.
The patch has been bootstrapped on and regression tested on
x86_64-unknown-linux-gnu and v850-unknown-elf for c.
Changes for other platforms is obvious and similar changes in v850 target.
This patch is pre-approved and s
The reason I put that patch out is that sometimes, when we stream an
actual chain, lto_input_chain is going to rebuild the new chain it's
meant to be, but then pph_read_tree (which is called after by the
name_hook to finish reading special parts of the tree) overwrites the
DECL_CHAIN that was intro
On 07/12/2011 01:07 PM, Eric Botcazou wrote:
> - while (*constraint++ != ',');
> + while (*constraint++ != ',')
> + ;
FWIW, elsewhere in gcc we use "continue;" for empty loop bodies.
r~
I like the modified implementation with VEC.
We probably want pph_register_decl_in_symtab to be inline as it does
so little now.
Now that you simply chainon bindings, you probably want to nreverse
them before you chain them on (this way we will stream them in from
first->last as this pacth does (
G++ kindly suggested making the following changes during a build so here we go.
Bootstrapped/regtested on x86_64-suse-linux, applied as obvious.
2011-07-12 Eric Botcazou
* cse.c (insert_with_costs): Put semi-colon after empty loop body
on the next line.
* emit-rtl.c (
OK.
Jason
We were using cxx_scope and cp_binding_level interchangeably in
confusing ways. This patch implements Jason's suggestion of making
cp_binding_level the typedef for struct cp_binding_level.
Tests currently running on x86_64.
OK for mainline if they pass?
Diego.
* name-lookup.h (cp_bin
Hello!
No functional change.
2011-07-12 Uros Bizjak
* config/i386/i386.c: Tidy processor feature bitmasks.
(m_P4_NOCONA): New.
Tested on x86_64-pc-linux-gnu {,-m32}. Committed to mainline SVN.
Uros.
Index: i386.c
==
On Fri, Jul 8, 2011 at 21:20, Gabriel Charette wrote:
> 2011-07-08 Gabriel Charette
>
> * pph-streamer-in.c (pph_in_function_decl): Stream in
> DECL_CHAIN of FUNCTION_DECL only if it's part of a RECORD_OR_UNION_TYPE
> (pph_read_tree): Stream in DECL_CHAIN of VAR_DECL only
This patch is a slight adaptation of Gab's fix to the order in which
we stream chains (http://codereview.appspot.com/4657092). I mostly
just changed how we keep the temporary list to reverse (it now uses a
VEC instead of a custom-build linked list).
The other change is in the reader. We were no
On 07/12/2011 02:29 AM, Richard Earnshaw wrote:
> On 12/07/11 10:05, Andreas Schwab wrote:
>> I think this has caused the bootstrap failure on ia64:
>>
>> In file included from ../../gcc/dwarf2cfi.c:31:0:
>> ../../gcc/dwarf2out.h: In function 'dwarf_frame_regnum':
>> ../../gcc/dwarf2out.h:271:3: er
On Tue, Jul 12, 2011 at 11:42 AM, Andrew Pinski wrote:
> Hi,
> The problem here is the code reads:
> /* Check for more than one successor. */
> if (! EDGE_COUNT (bb->succs) > 1)
> But that expression is always false as ! has a higher precedence than
>> does. So the obvious thing is to
Hi,
The problem here is the code reads:
/* Check for more than one successor. */
if (! EDGE_COUNT (bb->succs) > 1)
But that expression is always false as ! has a higher precedence than
> does. So the obvious thing is to rewrite this statement as:
if (EDGE_COUNT (bb->succs) <= 1)
A
On Tue, Jul 12, 2011 at 14:23, Gabriel Charette wrote:
> Right, I remember my original implementation had the same behaviour,
> but I'm pretty sure I had a comment mentioning that in the function
> usage comment. I'm just saying it should be mentioned what passing
> NULL means (especially since we
It *appears* as if the references we were generating before
switching the thunk to rtl weren't valid. Certainly those
same references don't pass legitimate_address_p, which is
the direct cause of the assertion failure.
Fixed by using the same address transformation that
ix86_expand_call would ha
Right, I remember my original implementation had the same behaviour,
but I'm pretty sure I had a comment mentioning that in the function
usage comment. I'm just saying it should be mentioned what passing
NULL means (especially since we do it all over the place).
On Tue, Jul 12, 2011 at 11:14 AM, D
On Tue, Jul 12, 2011 at 13:56, Gabriel Charette wrote:
> I like this implementation!
> Only one thing, if we ACTUALLY want "to_register" NULL instead of the read
> value we can't as in your current implementation NULL means don't do the
> alternate registration.
I don't think that's a problem. N
On Tue, Jul 12, 2011 at 14:02, Gabriel Charette wrote:
> My patch at http://codereview.appspot.com/4657092/ was fixing this.
>
> Did you apply that already? I didn't see it as part of your commits to date?
Ah, so that was it. No, it wasn't 4657092. I think we both fixed
this independently. I n
On Jul 12, 2011, at 9:37 AM, Rainer Orth wrote:
> The next easy step in toplevel libgcc migration is moving
> i386/crtprec.c. I noticed that -mpc{32, 64, 80} wasn't supported on
> Solaris/x86 yet and corrected that. The only testcase using the switch
> was adapted to also do so on Darwin/x86 (whi
On Jul 12, 2011, at 9:31 AM, Rainer Orth wrote:
> As a prerequisite to moving i386/crtprec.c to toplevel libgcc, it turned
> out that I need to move darwin-crt[23].c first to avoid the problem with
> inconsistent versions of extra_parts in gcc and libgcc:
>
> http://gcc.gnu.org/ml/gcc-patche
Re-adding gcc-patches (forgot to send plain text last time...sigh!)
On Tue, Jul 12, 2011 at 10:56 AM, Gabriel Charette wrote:
> I like this implementation!
> Only one thing, if we ACTUALLY want "to_register" NULL instead of the read
> value we can't as in your current implementation NULL means do
My patch at http://codereview.appspot.com/4657092/ was fixing this.
Did you apply that already? I didn't see it as part of your commits to date?
Gab
On Tue, Jul 12, 2011 at 5:55 AM, Diego Novillo wrote:
>
> Not quite sure what patch fixed this one and I'm too lazy to figure it out
> now.
>
> Co
On 07/12/2011 10:07 AM, Rainer Orth wrote:
> Only a couple of special defines (like FLOAT_WORD_ORDER_MISMATCH,
> QUIET_NAN_NEGATED) are moved to special t-* files in libgcc/config with
> [FDT]PBIT_CFLAGS similar to e.g. LIBGCC_SYNC_CFLAGS. If it were
> possible to have gcc define some __LIBGCC_* m
Richard Guenther wrote:
> 2011-07-11 Richard Guenther
>
> * tree-vrp.c (simplify_conversion_using_ranges): Manually
> translate the source value-range through the conversion chain.
This causes a build failure in cachemgr.c on spu-elf. A slightly
modified simplified test case also
Hmm, sorry I didn't notice this patch until now. Please CC me on C++
patches, and feel free to ping me if I don't respond promptly. Thanks
for working on this!
2. Templates don't really work. This is proving difficult for my little brain.
I need to parse this:
123_abc;
and replace it with
On Tue, 2011-07-12 at 19:25 +0200, Rainer Orth wrote:
> After rebuilding libstdc++-v3/configure, you should be fine.
>
> Rainer
Ah, I may have forgotten to run autoconf. My original testing was with
a subversion workarea, I am now trying to do it in a git area that I
created and I may hav
Steve,
> /wsp/sje/gcc_git/src/gcc/libstdc++-v3/libsupc++/eh_call.cc:34:23: fatal
> error: unwind-pe.h: No such file or directory
> compilation terminated.
> make[4]: *** [eh_call.lo] Error 1
> make[4]: Leaving directory
> `/wsp/sje/gcc_git/build-ia64-hp-hpux11.23-gcc/obj_gcc/ia64-hp-hpux11.23/li
> Certainly looks better to me.
Thanks, applied. In any case, it's only a quantitative issue: since gigi will
very likely use C++ features at some point, it needs to be compiled with the
C++ compiler, which means that all the FE headers must be extern "C". So half
of the 33 files must be modi
On Tue, 2011-07-12 at 11:50 -0500, William J. Schmidt wrote:
> Ilya, thanks for posting this! This patch is useful also on powerpc64.
> Applying it solved a performance degradation with bwaves due to loss of
> reassociation somewhere between 4.5 and 4.6 (still tracking it down).
> When we apply -f
Rainer,
I did another GCC build with your libgcc patch and with fixes for the
two problems I already mentioned to you and got another failure:
libtool: compile:
/wsp/sje/gcc_git/build-ia64-hp-hpux11.23-gcc/obj_gcc/./gcc/xgcc -shared-libgcc
-B/wsp/sje/gcc_git/build-ia64-hp-hpux11.23-gcc/obj_gc
On Tue, Jul 12, 2011 at 9:50 AM, William J. Schmidt
wrote:
> Ilya, thanks for posting this! This patch is useful also on powerpc64.
> Applying it solved a performance degradation with bwaves due to loss of
> reassociation somewhere between 4.5 and 4.6 (still tracking it down).
> When we apply -ft
Hello,
As discussed on IRC, I reuse here the do_dce flag to choose folding
direction within BB.
Bootstrapped and regression tested for all standard-languages (plus
Ada and Obj-C++) on host x86_64-pc-linux-gnu.
Ok for apply?
Regards,
Kai
ChangeLog gcc/
2011-07-12 Kai Tietz
* tree-s
Ilya, thanks for posting this! This patch is useful also on powerpc64.
Applying it solved a performance degradation with bwaves due to loss of
reassociation somewhere between 4.5 and 4.6 (still tracking it down).
When we apply -ftree-reassoc-width=2 to bwaves, the more optimal code
generation retu
gcc/Makefile.in currently has some support for crt0.o and mcrt0.o, but
it is only used by the i?86-*-netware* target, which admits in a comment
to abuse it.
So this patch removes the related support and moves the NetWare files
over to libgcc. I've decided to rename libgcc/config/i386/t-nwld to
t-
The next easy step in toplevel libgcc migration is moving
i386/crtprec.c. I noticed that -mpc{32, 64, 80} wasn't supported on
Solaris/x86 yet and corrected that. The only testcase using the switch
was adapted to also do so on Darwin/x86 (which already has the support,
but didn't exercise it).
Fo
PR 48183 is caused by the fact that we don't really support integers
(or least integer constants) wider than 2*HOST_BITS_PER_WIDE_INT:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01220.html
However, such constants shouldn't be needed in normal use.
They came from an unnecessary zero-initialis
As a prerequisite to moving i386/crtprec.c to toplevel libgcc, it turned
out that I need to move darwin-crt[23].c first to avoid the problem with
inconsistent versions of extra_parts in gcc and libgcc:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00831.html
The following pretty mechanical
Another easy part in the toplevel libgcc move was sync.c and related
stuff. While doing this, it turned out to be easier to move the rest of
gcc/config/mips/t-libgcc-mips16 rather than leave it behind.
The patch is untested except for including it in a mips-sgi-irix6.5
build to make sure it is sy
On 07/12/2011 02:05 AM, Andreas Schwab wrote:
> Richard Henderson writes:
>
>> @@ -261,6 +262,15 @@ extern void dwarf2out_set_demangle_name_func (const
>> char *(*) (const char *));
>> extern void dwarf2out_vms_debug_main_pointer (void);
>> #endif
>>
>> +/* Unfortunately, DWARF_FRAME_REGNUM
I noticed that this approval had not been sent to the mailing list. I'm
restesting and checking in the remaining preliminary patches for C6X now.
Bernd
Original Message
Subject: Re: The TI C6X port
Date: Wed, 25 May 2011 17:11:53 -0400
From: Vladimir Makarov
To: Bernd Schmidt
On 1 July 2011 16:57, Dr. David Alan Gilbert wrote:
>
> As per pr/48126 Michael Edwards spotted that in the case where
> the compare fails in the cmpxchg, the barrier at the end wasn't taken
> theoretically allowing a following load to float up above the load
> value compared.
Please resubmit wit
> "Richard" == Richard Guenther writes:
Richard>java/
Richard>* builtins.c (static): Use fold_build_pointer_plus.
Richard>* class.c (make_class_data): Likewise.
Richard>(build_symbol_entry): Likewise.
Richard>* except.c (build_exception_object_ref): Lik
Hello Thomas,
> On Fri, 08 Jul 2011 13:25:13 +0200, Rainer Orth
> wrote:
>> 2011-06-22 Rainer Orth
>>
>> gcc:
>> * config/dfp-bit.c, config/dfp-bit.h: Move to ../libgcc.
>> * config/t-dfprules: Move to ../libgcc/config.
>
> Seems that you forgot to remove the files from gcc/co
I noticed we forget to clear the stats and that we do 1:1
replacements.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-07-12 Richard Guenther
* tree-ssa-copyrename.c (rename_ssa_copies): Zero statistics.
Do not perform no-op changes.
In
On Tue, Jul 12, 2011 at 2:21 PM, Kai Tietz wrote:
> 2011/7/12 Richard Guenther :
>> On Tue, Jul 12, 2011 at 11:48 AM, Kai Tietz wrote:
>>> 2011/7/12 Richard Guenther :
On Mon, Jul 11, 2011 at 5:37 PM, Kai Tietz wrote:
> 2011/7/8 Richard Guenther :
>> On Fri, Jul 8, 2011 at 1:32 PM,
On Tue, Jul 12, 2011 at 2:12 PM, Tom de Vries wrote:
> Hi Richard,
>
> here's a new version of the pass. I attempted to address as much as possible
> your comments. The pass was bootstrapped and reg-tested on x86_64.
>
> On 06/14/2011 05:01 PM, Richard Guenther wrote:
>> On Fri, Jun 10, 2011 at 6:
On 04/07/11 15:26, Andrew Stubbs wrote:
On 28/06/11 15:14, Andrew Stubbs wrote:
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned
type
then the compiler will attempt to use usmul_widen_optab or
um
Hi!
The final standard now explicitly lists how copyin should copy allocatables.
Here is a testcase for something that hasn't been covered by the testsuite
yet.
2011-07-12 Jakub Jelinek
* testsuite/libgomp.fortran/allocatable8.f90: New test.
--- libgomp/testsuite/libgomp.fortran/allo
Hi!
This patch fixes atomic capture with structure block and
pre/post inc/decrement and adds tests for it (these
forms weren't in the 3.1 draft and were parsed by mistake
before and for x++; v = x; and x--; v = x; it actually ICEd).
I haven't added the x = x binop expr forms yet for neither
atomi
Not quite sure what patch fixed this one and I'm too lazy to figure it out
now.
Committed to branch.
Diego.
* g++.dg/pph/c4pr36533.cc: Mark fixed.
diff --git a/gcc/testsuite/g++.dg/pph/c4pr36533.cc
b/gcc/testsuite/g++.dg/pph/c4pr36533.cc
index 0093db1..ce2bf1f 100644
--- a/gcc/testsui
The C++ changes are OK.
Jason
>
> It's been tested cross to ARM from x86 and also a native x86 build & test.
Cross on qemu ? You do mean a native ARM build and test :) You are
missing changelog entries in each of your patches. Could you please
reply to each of your patches with the appropriate Changelog entries ?
Thanks,
Rama
On Fri, Jul 8, 2011 at 21:29, Gabriel Charette wrote:
> 2011-07-08 Gabriel Charette
>
> * gcc/cp/pph-streamer-in.c (pph_add_bindings_to_namespace):
> NAMESPACE_LEVEL should never be null for a namespace, removed check.
OK. I committed it to the branch. I need to adjust the oth
Hello,
Here is a patch related to missed optimization opportunity in tree
reassoc phase.
Currently tree reassoc phase always generates a linear form which
requires the minimum registers but has the highest tree height and
does not allow computation to be performed in parallel. It may be
critical
On 07/12/2011 01:05 AM, Janne Blomqvist wrote:
PING
On Mon, Jul 4, 2011 at 00:57, Janne Blomqvist wrote:
Hi,
the attached patch fixes the remaining cases of handling input that
ends in EOF instead of a normal separator for list formatted read of
the primitive types. Ok for trunk and 4.6?
Y
On 07/12/2011 12:33 PM, Richard Guenther wrote:
Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages.
Are the frontend parts ok?
The Fortran bits are OK.
Tobias
2011-07-12 Richard Guenther
fortran/
* trans-expr.c (fill_with_spaces): Use fold_build_pointer_
2011/7/12 Richard Guenther :
> On Tue, Jul 12, 2011 at 11:48 AM, Kai Tietz wrote:
>> 2011/7/12 Richard Guenther :
>>> On Mon, Jul 11, 2011 at 5:37 PM, Kai Tietz wrote:
2011/7/8 Richard Guenther :
> On Fri, Jul 8, 2011 at 1:32 PM, Kai Tietz wrote:
>> 2011/7/8 Richard Guenther :
>
On Jun 10, 2011, at 6:55 PM, Jan Hubicka wrote:
> Hi,
> this patch updated ipa-cp and ipa-prop for aliases. It is basically easy -
> we don't
> analyze nodes represneting aliases and when propagating we skip them, like
> everywhere
> else.
...
> @@ -759,7 +768,8 @@ ipcp_propagate_stage (void)
>
Bernd Schmidt wrote:
> On 07/12/11 13:04, Andrew Stubbs wrote:
>> On 12/07/11 11:35, Georg-Johann Lay wrote:
>>> +(define_insn "*mulsu"
>>> + [(set (match_operand:HI 0
>>> "register_operand" "=r")
>>> +(mult:HI (sign_extend:HI (match_operand:QI 1
>>> "register_opera
Andrew Stubbs wrote:
> On 12/07/11 11:35, Georg-Johann Lay wrote:
>> +(define_insn "*mulsu"
>> + [(set (match_operand:HI 0
>> "register_operand" "=r")
>> +(mult:HI (sign_extend:HI (match_operand:QI 1
>> "register_operand" "a"))
>> + (zero_extend:HI (
On Tue, Jul 12, 2011 at 1:26 PM, Andrew Stubbs wrote:
> On 12/07/11 12:05, Richard Guenther wrote:
>>
>> (**) We really ought to forbid any arithmetic on types that have non-mode
>> precision and only allow conversions to/from such types.
>
> Hmmm, presumably the problem is that we might have a co
On 12/07/11 12:05, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Hmmm, presumably the problem is that we might have a compatible
precision, but the backends actually work with purely mo
On 12/07/11 12:11, Bernd Schmidt wrote:
2. There's no need to define both of these. For one thing, putting a '%'
at the start of the constraint list for operand 1 does precisely this,
Unfortunately it doesn't. It won't swap the sign/zero-extend.
Ah, my mistake. I still think that one form sh
On 07/12/11 13:04, Andrew Stubbs wrote:
> On 12/07/11 11:35, Georg-Johann Lay wrote:
>> +(define_insn "*mulsu"
>> + [(set (match_operand:HI 0
>> "register_operand" "=r")
>> +(mult:HI (sign_extend:HI (match_operand:QI 1
>> "register_operand" "a"))
>> +
On Tue, Jul 12, 2011 at 1:04 PM, Richard Guenther
wrote:
> On Tue, Jul 12, 2011 at 11:50 AM, Andrew Stubbs wrote:
>> On 23/06/11 15:39, Andrew Stubbs wrote:
>>>
>>> This patch has two effects:
>>>
>>> 1. It permits the use of widening multiply instructions that widen by
>>> more than one mode. E.
On 12/07/11 11:35, Georg-Johann Lay wrote:
+(define_insn "*mulsu"
+ [(set (match_operand:HI 0 "register_operand" "=r")
+(mult:HI (sign_extend:HI (match_operand:QI 1 "register_operand" "a"))
+ (zero_extend:HI (match_operand:QI 2 "register_operand"
On Tue, Jul 12, 2011 at 11:50 AM, Andrew Stubbs wrote:
> On 23/06/11 15:39, Andrew Stubbs wrote:
>>
>> This patch has two effects:
>>
>> 1. It permits the use of widening multiply instructions that widen by
>> more than one mode. E.g. HImode -> DImode.
>>
>> 2. It enables the use of widening multi
On Mon, Jul 11, 2011 at 6:55 PM, Andrew Stubbs wrote:
> On 07/07/11 10:58, Richard Guenther wrote:
>>
>> I think you should assume that series of widenings,
>> (int)(short)char_variable
>> are already combined. Thus I believe you only need to consider a single
>> conversion in valid_types_for_mad
For widening multiply there is room for optimization, e.g.:
* (mult:HI (extend:HI(QI)) HI) is better than
(extend:HI(QI)) and (mult:HI HI HI)
* For mult with power of 2 sometimes a mult is
better than a shift left.
* Support MULSU instruction, i.e.
(mult:HI (sign_extend:HI(QI))
> Revised version, only 33 files modified now (instead of 51). We compile the C
> files for the compiler proper (and gnatbind) with the C++ compiler, but we
> keep compiling them with the C compiler in the other cases (library & tools).
> I think that this is in keeping with the other compilers (e
On Tue, Jul 12, 2011 at 11:48 AM, Kai Tietz wrote:
> 2011/7/12 Richard Guenther :
>> On Mon, Jul 11, 2011 at 5:37 PM, Kai Tietz wrote:
>>> 2011/7/8 Richard Guenther :
On Fri, Jul 8, 2011 at 1:32 PM, Kai Tietz wrote:
> 2011/7/8 Richard Guenther :
>> On Thu, Jul 7, 2011 at 6:07 PM, Ka
> This is an updated version of Laurent's patch originally here:
> http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html
Revised version, only 33 files modified now (instead of 51). We compile the C
files for the compiler proper (and gnatbind) with the C++ compiler, but we
keep compiling them with
On 12/07/11 10:15, Andrew Haley wrote:
> On 12/07/11 10:12, Richard Earnshaw wrote:
>> On 11/07/11 17:23, Andrew Haley wrote:
>>> On a multicore ARM, you really do have to clear both caches, not just the
>>> dcache. This bug may exist in other ports too.
>>>
>>> Andrew.
>>>
>>>
>>> 2011-07-11 And
On 23/06/11 15:39, Andrew Stubbs wrote:
This patch has two effects:
1. It permits the use of widening multiply instructions that widen by
more than one mode. E.g. HImode -> DImode.
2. It enables the use of widening multiply instructions for (extended)
inputs of narrower mode than the instructio
2011/7/12 Richard Guenther :
> On Mon, Jul 11, 2011 at 5:37 PM, Kai Tietz wrote:
>> 2011/7/8 Richard Guenther :
>>> On Fri, Jul 8, 2011 at 1:32 PM, Kai Tietz wrote:
2011/7/8 Richard Guenther :
> On Thu, Jul 7, 2011 at 6:07 PM, Kai Tietz wrote:
>> Hello,
>>
>> This patch - se
On 12/07/11 10:05, Andreas Schwab wrote:
> Richard Henderson writes:
>
>> @@ -261,6 +262,15 @@ extern void dwarf2out_set_demangle_name_func (const
>> char *(*) (const char *));
>> extern void dwarf2out_vms_debug_main_pointer (void);
>> #endif
>>
>> +/* Unfortunately, DWARF_FRAME_REGNUM is no
> Tested on arm-linux-gnueabi. OK to install?
This is OK.
cheers
Ramana
On Mon, Jul 11, 2011 at 5:37 PM, Kai Tietz wrote:
> 2011/7/8 Richard Guenther :
>> On Fri, Jul 8, 2011 at 1:32 PM, Kai Tietz wrote:
>>> 2011/7/8 Richard Guenther :
On Thu, Jul 7, 2011 at 6:07 PM, Kai Tietz wrote:
> Hello,
>
> This patch - second of series - adds boolification of
Hi!
Now that LIM is scheduled after IVOPTS too, it needs to be prepared to
handle TARGET_MEM_REFs IVOPTS creates.
Tested on x86_64-linux, committed to trunk as obvious.
2011-07-12 Jakub Jelinek
PR tree-optimization/49712
* tree-ssa-loop-im.c (gen_lsm_tmp_name): Handle TARGET_M
On 12/07/11 10:12, Richard Earnshaw wrote:
> On 11/07/11 17:23, Andrew Haley wrote:
>> On a multicore ARM, you really do have to clear both caches, not just the
>> dcache. This bug may exist in other ports too.
>>
>> Andrew.
>>
>>
>> 2011-07-11 Andrew Haley
>>
>> * src/arm/ffi.c (FFI_IN
1 - 100 of 104 matches
Mail list logo
