On 11/10/2010 12:47 AM, Joern Rennecke wrote:
I remember that it has been there even before the GNU GCC project started
using cvs. Fortunately, we still have the translated history from RCS
going backeven further... but the earliest mention of find_split_point
in combine.c is shown as having
On 11/10/2010 11:58 AM, Georg Lay wrote:
In the old 3.4.x (private port) I introduced a target hook in combine,
just prior to where recog_for_combine gets called. The hook did some
canonicalization of rtx and thereby considerably reduced the number of
patterns that would have been necessary
On 11/09/2010 10:22 AM, Joern Rennecke wrote:
Quoting roy rosen roy.1ro...@gmail.com:
What is the difference when writing define_insn_and_split?
From what I understood from the docs then if there is such an insn
then the split does not occur so it would simply match it as an insn
without
On 11/09/2010 05:38 PM, Joern Rennecke wrote:
A define_insn will be recognized in all contexts.
Having an insn pattern for an insn that does not actually exist can cause
all kinds of unintended consequences as the optimizers try to generate
and recognize 'optimized' patterns, or when reload does
On 11/04/2010 11:28 AM, Bingfeng Mei wrote:
I think of adding a warning too. Should I submit a patch?
That's always a good idea. :)
Paolo
On 11/05/2010 07:00 PM, Ian Lance Taylor wrote:
To the steering committee: I propose Ralf Wildenhues as a new maintainer
for the build machinery.
Ralf often has useful comments for proposed patches to the configure
scripts. He has done good work in upgrading to new versions of autoconf
and
On 11/05/2010 08:10 AM, Jay K wrote:
the checking for puts_locked...
the fact that asm_fprintf calls putc one character at a time,
which probably benefits from _unlocked.
Honest question: is asm_fprintf in the profile at all, even at -O0?
Paolo
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals 16.16 How to Split Instructions mention two flavours of insn
splitting: One after reload for the scheduler and one during combine stage, the
latter just doing single_set -- 2 * single_set splits
On 11/02/2010 11:39 AM, Georg Lay wrote:
Paolo Bonzini schrieb:
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals 16.16 How to Split Instructions mention two flavours
of insn
splitting: One after reload for the scheduler and one during combine
On 10/31/2010 08:12 PM, Ian Lance Taylor wrote:
I assume that the reason we do that for intl is because it has complex
interactions with the rest of the C library, so using the wrong intl
library will cause confusing behaviour when the LC_ environment
variables are set. That case does not arise
On 11/01/2010 11:47 AM, Joern Rennecke wrote:
Quoting Geert Bosch bo...@adacore.com:
On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
But to get that coverage, testers will need to have gnat installed.
Will that become a requirement for middle-end patch regression testing?
No, the language
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromeytro...@redhat.com writes:
Ian == Ian Lance Taylori...@google.com writes:
Ian This patch puts the code in libiberty, but it could equally well go in
Ian gcc. Anybody want to make an argument one way or another?
Ian +extern const
On 11/02/2010 11:50 AM, Paolo Bonzini wrote:
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromeytro...@redhat.com writes:
Ian This patch puts the code in libiberty, but it could equally well
go in
Ian gcc. Anybody want to make an argument one way or another?
Ian +extern const char
On 11/02/2010 12:36 PM, Joern Rennecke wrote:
define_insn_and_split is little more than syntactic sugar to avoid
re-typing the same patterns again.
Yes, on the other hand it was introduced as combiner-splitter patterns
fell out of fashion, substantially replaced by what you call combiner
On 10/30/2010 05:30 AM, H.J. Lu wrote:
Will put
if [ Go is enabled ]; then
boot_language=yes
fi
in cp/config-lang.in work?
It's a bit backwards, no?
Paolo
On 10/29/2010 05:08 PM, Georg Lay wrote:
As far as I understand the internals, peephole2 matches due to predicates and
condition, it does not care for constraints (except for optional match_scratch)
Yes, I was referring as using constraints in the define_insn. But
you're dong that as far as
On 10/29/2010 06:18 PM, Georg Lay wrote:
(define_split
[(set (match_operand:SI 0 register_operand )
(and:SI (match_operand:SI 1 register_operand )
(match_operand:SI 2 const_int_operand )))
(clobber (match_operand:SI 3 register_operand ))]
...
On 10/22/2010 01:16 PM, Georg Lay wrote:
I already tried to fix this by introducing a different return-pattern, i.e. a
PARALLEL of return and bunch of clobbers of unused regs. That fixes this problem
but has many other disadvantages compared to a simple return.
What were this disadvantages?
On 10/28/2010 12:24 PM, Georg Lay wrote:
Emitting a bunch of CLOBBERs in epilogue/sibcall_epilogue works also, at least
for the small example above. But using LOCAL_REGNO seems more natural to me and
that does not clutter RTL.
True. It's a pretty elegant solution, and I missed it in my mail
On 10/28/2010 03:10 PM, Georg Lay wrote:
Georg Lay schrieb:
This code is not nice.
;; d8 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
this should be
;; d2 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
It seems to me that some of your peepholes should instead be implemented
using
On 10/29/2010 12:35 AM, Andrew Pinski wrote:
The important part of the log is:
/bin/sh ./libtool --tag=CC --mode=compile
/Users/regress/tbox/native/build/./gcc/xgcc
-B/Users/regress/tbox/native/build/./gcc/
-B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/
On 10/27/2010 12:54 PM, Georg Lay wrote:
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL) CURRENT = FIRST = 0xc008010 = {...,4,15}
Ok, this looks like a bug somewhere (either in DF or in your backend).
hmmm. How could the backend
On 10/27/2010 04:30 PM, Georg Lay wrote:
The first time it occurs in exit block uses is in pro/epilogue:
peep2.c.193r.split2:;; exit block uses 2 [d2] 26 [SP] 27 [a11]
peep2.c.195r.pro_and_epilogue:;; exit block uses2 [d2] 15 [d15] 26 [SP]
27 [a11]
peep2.c.196r.dse2:;; exit
On 10/26/2010 07:42 PM, Georg Lay wrote:
I set a break at the end of df_simulate_one_insn_backwards.
CURRENT = *(live-current-bits)
FIRST = *(live-first-bits)
Or call debug_bitmap (). :)
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL)
On 10/25/2010 11:35 AM, Georg Lay wrote:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
(xor:SI (reg:SI
On 10/25/2010 10:46 AM, Frederic Riss wrote:
Hi,
The constant propagation pass propagates constants into the
instructions that accept immediates. I'm trying to find if there's
some CSE pass in GCC that would be able to undo this effect when the
constant is used more than once in the function. I
On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
configure.ac
Add libgo. If building Go, build C++ as a boot language.
Can you generalize this using something in gcc/go/config-lang.in?
Paolo
On 10/22/2010 01:16 PM, Georg Lay wrote:
Then the first insn gets split after reload and before peephole2:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143 {*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21
It's been a long time since I dealt with this aspect of porting, but
isn't it the case that most ports don't expose branch-on-carry-set
branch-on-carry-clear? It looks like the mn103 was recently changed to
not use cc0, which is definitely a good thing. I'm not sure offhand the
best way to recode
I hate to say this when I don't have the time to fix it myself, but
toplevel of gcc and src is once more out of sync, and this is bad.
I think that we should apply a *very* strict policy of not approving
toplevel patches unless the toplevel files are in sync.
Thanks in advance to anyone that
Other than that, below is the combined patch I intend to commit to src
unless there are disagreements.
Ok, thanks.
DJ, can you amend your scripts so that the head of gcc/ChangeLog and
src/ChangeLog is included? This will make it easier to bug relevant
people.
Paolo
On 09/24/2010 10:10 AM, Paulo J. Matos wrote:
The rules currently take the shape:
,
| (define_expand umulqihi3
`
These rules were created in gcc42 and the idea was that we can use smult
instead of umult whenever RAH (MSW of the result) is not used
afterwards. The 2nd argument of
On 09/23/2010 08:49 PM, Ian Lance Taylor wrote:
Diego Novillodnovi...@google.com writes:
I'd suggest sending one initial patch fixing indentation issues and
then sending your functional changes on top of the first patch.
Yes.
Basile, I'm sorry you have to struggle with some poor existing
On 09/24/2010 11:29 AM, Basile Starynkevitch wrote:
I don't understand what concrete steps are you suggesting. As
explained above, I am using M-x indent-region but it does indent
gengtype code because gengtype is mis-indented from the beginning.
Maybe my patches will never go into trunk
On 09/10/2010 03:12 PM, Manuel López-Ibáñez wrote:
On 10 September 2010 15:00, Steven Bosscherstevenb@gmail.com wrote:
On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
Some strong way of addressing the concern that this could be used to make
proprietary
On 09/07/2010 10:41 AM, Basile Starynkevitch wrote:
The words gengtype, GTY, garbage do not seem to appear the
MAINTAINERS file, so it seems that gengtype GTY don't have any
specialized reviewers.
And gengtype is not a very well written and easy to maintain piece of
code, at least in our
On Sat, Sep 4, 2010 at 05:53, Jack Howarth howa...@bromo.med.uc.edu wrote:
Paolo,
Could you please look over PR45524 and then revert the offending
r163815/r163816 that has broken decimal float support for all non-linux
targets. That patch is wrong in so many ways, it is hard to know where
On 08/24/2010 07:38 PM, Basile Starynkevitch wrote:
(actually, this happened to us before e.g.
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02178.html etc).
Sorry, but that's what happens when you ignore the maintainers' opinion.
Do not misunderstand me: I'm very interested in your works and
On 08/09/2010 01:39 PM, Ulrich Weigand wrote:
(define_expand cbranchsi4
[(parallel [(set (cc0)
(compare (match_operand:SI 1 register_operand )
(match_operand:SI 2 nonmemory_operand )))
(clobber (match_scratch:QI 4 ))])
(set
On 08/08/2010 07:13 AM, Florian Weimer wrote:
* Vincent Lefevre:
On 2010-08-07 13:38:05 +0200, Florian Weimer wrote:
* John Regehr:
[...]
Let me know if more detail is needed or if it would be better for me to
file all 71 bug reports.
I wonder if we should give up and make -fwrapv the
On 08/04/2010 07:34 PM, Alfred M. Szmidt wrote:
So one way to move forward is to effectively have two manuals,
one containing traditional user-written text (GFDL), the other
containing generated text (GPL). If you print it out as a
book, the generated part would
On 08/04/2010 08:48 PM, Alfred M. Szmidt wrote:
You probably haven't read this thread fully, or you wouldn't imply
that GCC should have an options manual separate from the user's
manual.
I have read the thread in full, and I do not see the problem with
keeping that info in a
On 08/04/2010 10:52 PM, Richard Guenther wrote:
On Wed, Aug 4, 2010 at 10:03 PM, Alfred M. Szmidta...@gnu.org wrote:
I have read the thread in full, and I do not see the problem with
keeping that info in a seperate manual; GCC has so many options
for various architectures and
On 08/04/2010 11:52 PM, Joe Buck wrote:
On Wed, Aug 04, 2010 at 02:12:18PM -0700, Paolo Bonzini wrote:
However, until there is a possibility to relicense anything GPL-GFDL I
cannot disagree. In fact, since the GFDL is more restrictive, it is the
same thing as the Affero GPL.
No, because
On 08/03/2010 01:35 AM, Richard Kenner wrote:
That is true, but very often the documentation is needed in two
places: in the code and in the manual. Especially for things like
machine constraints, flags and options.
Yes, but the audiences are different between users who read the manual and
.
Paolo
patch 1/4:
2009-03-13 Paolo Bonzini bonz...@gnu.org
* combine.c (expand_compound_operation): Fix thinko.
(simplify_shift_const_1): Avoid noncanonical rtx.
Index: gcc/combine.c
===
--- gcc/combine.c (branch
On 07/15/2010 09:57 AM, Uros Bizjak wrote:
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a (c 0x1f);
}
The macro was defined as:
+/* Implement
On 07/08/2010 10:58 PM, Maxiwell Garcia wrote:
Hi,
I am writing a paper about instruction-set architecture simulators. In
first time, I used gcc-4.4.0 and the compilation time reached 33
minutes (with -O3) for my simulator and the performance reached 270
MIPS (Million instruction per second).
On 07/13/2010 04:53 PM, Richard Guenther wrote:
On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzinibonz...@gnu.org wrote:
On 07/08/2010 10:58 PM, Maxiwell Garcia wrote:
Hi,
I am writing a paper about instruction-set architecture simulators. In
first time, I used gcc-4.4.0 and the compilation
On 07/13/2010 04:53 PM, Richard Guenther wrote:
On Tue, Jul 13, 2010 at 4:50 PM, Paolo Bonzinibonz...@gnu.org wrote:
On 07/08/2010 10:58 PM, Maxiwell Garcia wrote:
Hi,
I am writing a paper about instruction-set architecture simulators. In
first time, I used gcc-4.4.0 and the compilation
On 07/10/2010 10:01 PM, Gerald Pfeifer wrote:
On Sat, 10 Jul 2010, Steven Bosscher wrote:
Well, let me add one short comment then. I'd say hppa2-hpux is still
much more relevant than ia64-hpux -- at least, everywhere I'm looking
i.e. workstations. It may be different in the server market.
On 06/30/2010 09:43 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 3:24 PM, David Edelsohndje@gmail.com wrote:
He understood your point very well. That is why Frank said, You
falsely presume zero vetting.
Maybe I didn't get the zero vetting part, then. I thought I did, but
apparently
On 07/01/2010 02:27 PM, Joern Rennecke wrote:
When risks of the patch mostly involve type checking or things that
could be caught with a simple compilation, could we relax this
testing requirement to do a cross-build of all-gcc all-target-libgcc
with a recent fully bootstrapped compiler, with
On 06/30/2010 11:18 PM, Basile Starynkevitch wrote:
How do distributions makers achieve that?? IIRC they have a strict rule
that no compilation or build should run under root!
You use make install DESTDIR=`pwd`/buildroot and then copy the
contents of the buildroot into the real root (e.g.
On 07/01/2010 02:57 PM, Joern Rennecke wrote:
Quoting Paolo Bonzini bonz...@gnu.org:
On 07/01/2010 02:27 PM, Joern Rennecke wrote:
When risks of the patch mostly involve type checking or things that
could be caught with a simple compilation, could we relax this
testing requirement to do
On 07/01/2010 03:26 PM, Joern Rennecke wrote:
Quoting Paolo Bonzini bonz...@gnu.org:
Sorry, I meant that it should not give any warning, not that -Werror is
in use.
Well, what we want for a bootstrap replacement is that it gives errors
for everything where a bootstrap gives errors
On 07/01/2010 03:34 PM, Joern Rennecke wrote:
Quoting Paolo Bonzini bonz...@gnu.org:
On 07/01/2010 03:26 PM, Joern Rennecke wrote:
Well, what we want for a bootstrap replacement is that it gives
errors for everything where a bootstrap gives errors.
--enable-werror-always?
No, we don't
On 06/29/2010 06:48 PM, Basile Starynkevitch wrote:
On Tue, 2010-06-29 at 11:40 +0200, Paolo Bonzini wrote:
On 06/29/2010 04:16 AM, Tom Tromey wrote:
Ian In Tom's interesting idea, we would write the mark function by hand for
Ian each C++ type that we use GTY with.
I think we should
On 06/29/2010 04:16 AM, Tom Tromey wrote:
Ian In Tom's interesting idea, we would write the mark function by hand for
Ian each C++ type that we use GTY with.
I think we should be clear that the need to write a mark function for a
new type is a drawback of this approach. Perhaps gengtype
On 06/11/2010 10:15 AM, yuanbin wrote:
gcc initial the first member of union now, This is not the C standard also.
I just want gcc initial the last member of union with some switch.
Why do you want the last one? Is there a compiler that does that (e.g.
MSVC++)? If yes, it can be toggled by
On 06/11/2010 03:26 PM, Jan Hubicka wrote:
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Compiler can not report it because it does not see the other object files.
It
On 06/10/2010 06:28 AM, Jeremy Kerr wrote:
Hi Paolo,
The hash would be different for git diff and svn diff due to the
different headers.
The headers are not included in the hash. However, the filenames will need to
be the same - patchwork expects '-p1' patches, but normalises the top-level
On 06/10/2010 10:57 AM, yuanbin wrote:
initialization of the enum:
you mean union.
enum {
int i;
float f;
} t={1.5}; //t.f
The above makes no sense, what if you have int and char?
You have to say
union { ... } t = { .f = 1.5 };
and that already works in
On 06/08/2010 10:37 PM, Ian Lance Taylor wrote:
Are there ways that we can adjust our e-mail messages to make this
work better?
Two things: 1) we should make the [bracket] prefixes more standard for
patches destined to feature branches; 2) we should likely not send
multiple patches in one
On 06/09/2010 10:03 AM, Jeremy Kerr wrote:
Hi Manuel,
2) Use the command-line patchwork client to update patch state when a
patch is committed. People have done this with a git post-commit hook to
update the state of the patch in patchwork; I'm not sure if svn has
something equivalent.
Yes
On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
So perhaps the thing to do is somehow separate patches from regular
contributors and irregular contributors. A relatively easy way to do
this would be for a regular contributor to include a
On 06/08/2010 09:21 PM, Basile Starynkevitch wrote:
On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote:
I don't understand. WAA rights definitely allow you to shepherd and commit
patches from people without svn access, even for patches you can't approve.
And basile (and other WAA
On 06/07/2010 09:38 AM, pem wrote:
I am not familar with both c++ and compiler implementation, donot konw
why the results are differnt for gcc and clang. Anyone could help and
explain this difference for me?
First of all, this would be a question for gcc-h...@gcc.gnu.org. This
mailing list
From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html:
we looked at the current list of primary and
secondary targets and suggested (again) to demote i686-apple-darwin to
a secondary platform on the base that it is unmaintained. We
recognize that it is used and gets many bugs filed against.
It
On 06/01/2010 08:10 AM, Ian Lance Taylor wrote:
Mark Mitchellm...@codesourcery.com writes:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is
On 06/01/2010 04:11 PM, Ian Lance Taylor wrote:
In the gccgo IR I don't represent everything with a single type.
Instead, I use a separate base class for types, expressions and
statements (in Go there is more of a distinction between expressions
and statements than there is in C/C++). I
Well, on the one hand I agree - but on the other hand I see people
eagerly waiting to be the first to post patches to convert all
VEC uses that allocate from the heap(!) (yes - we can't use STL
for GC allocated stuff!), leaving us with files that use a mix of
stl::vector and VEC. VEC is clearly
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type arguments,
consider specializing for void* (or const void*) and define all other
pointer specialization in terms of
On 06/02/2010 03:54 PM, Ian Lance Taylor wrote:
Richard Guentherrichard.guent...@gmail.com writes:
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylori...@google.com wrote:
Richard Guentherrichard.guent...@gmail.com writes:
Overall the wiki document looks good. I'd like to disallow
*
On 05/31/2010 12:30 PM, 徐持恒 wrote:
I think compiler can and should be host independent, like LLVM.
It is. Changes to code generation depending on the host are considered
to be serious bugs, and have been long before LLVM existed.
Paolo
On 05/31/2010 06:26 PM, Basile Starynkevitch wrote:
On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
There's no reason to get into these kinds of questions at this point.
The goal is not to reimplement GCC from the ground up using modern
OO/C++ techniques. The goal is simply to permit
On 05/31/2010 11:48 AM, Eric Botcazou wrote:
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it, see hwint.h.
Both of you are right, as our requirements for building a cross compiler
are stricter than for a native
On 05/28/2010 06:36 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Dear GCC developers,
Would you please consider suppressing (relatively new) warnings like
this one:
ignoring return value of 'int chdir(const char*)', declared with
attribute warn_unused_result
in cases when the source code
On 05/26/2010 07:03 PM, Ulrich Weigand wrote:
This is the reason why we implemented TARGET_ADDR_SPACE_KEYWORDS as
macro (note that all the other address-space related back-end
callbacks were already implemented as hooks to begin with).
One nice cleanup would be to merge the per-address-space
On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E]
vaka...@ncbi.nlm.nih.gov wrote:
Hi Paolo,
Can this design please be changed
By saying by design I was implying that it won't.
FWIW I agree with you, but I'm also very undecided whether it is not
glibc that was too greedy in
On 05/27/2010 08:25 AM, Steven Bosscher wrote:
On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzinibonz...@gnu.org wrote:
Well, gives me at least one clue so far: the implicit rule .c.o is
over-ruled by t-i386, which explains why the extra CFLAGS-$file are
not passed to config/i386/i386-c.c. I'm now
On 05/27/2010 10:02 AM, Joern Rennecke wrote:
Quoting Paolo Bonzini bonz...@gnu.org:
On 05/26/2010 09:25 AM, Joern Rennecke wrote:
What we can't do under this scheme is retroactively re-use code
as documentation or vice versa; we'd need the appropriate license
grant from the FSF for each bit
gcc/ChangeLog:
* Makefile.in (ALL_CFLAGS): Add file-specific CFLAGS.
(ALL_HOST_FRONTEND_OBJS): New, for all front-end specific objects.
(ALL_HOST_BACKEND_OBJS): New, for all backend and target objects.
(ALL_HOST_OBJS): Now a union of the above two.
On 05/27/2010 10:10 AM, Steven Bosscher wrote:
-/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end file.
- Pretend this is a back-end file. */
-#define IN_GCC_BACKEND
#include expr.h /* For vector_mode_valid_p */
Is this really the only reason? We don't have any other
On 05/27/2010 12:33 PM, Amker.Cheng wrote:
while GCC3.4.4 treats the long long multiplication just like simple
ones, which generates only one
mult insn for each statement, like
In my understanding, It‘s not necessary using three mult insn to implement
long long mult, since the operands are
Remainders, in reverse chronological order:
Thanks Ralf. I'm CCing the people.
Paolo
2010-05-05 Sebastian Pop sebastian@amd.com
* configure.ac: Allow all the versions greater than 0.10 of PPL.
* configure: Regenerated.
2010-04-16 Rainer Orth
On 05/27/2010 06:58 AM, Steven Bosscher wrote:
Well, it looks like I do need something like @F because I now only get
the define on files in gcc/. Any file with a / in the full name $@
does not get a file specific CFLAGS.
Interesting, this simpler testcase worked:
test-a/b = $(warning ok)
On 05/26/2010 09:25 AM, Joern Rennecke wrote:
What we can't do under this scheme is retroactively re-use code
as documentation or vice versa; we'd need the appropriate license
grant from the FSF for each bit of code/documentation that we want
to re-use in that manner.
Does it help that large
On 05/25/2010 09:55 AM, Steven Bosscher wrote:
1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS
2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
3) Conditionally poison symbols in system.h
For the last step, that would be e.g.:
#ifdef
On 05/25/2010 12:13 PM, Revital1 Eres wrote:
Hello,
I am using current mainline to compile a testcase which contains a loop.
The target I'm working on supports cmpsi pattern.
While expanding the loop condition I get that do_compare_rtx_and_jump ()
and
do_jump_by_parts_greater_rtx () call
On 05/25/2010 03:01 PM, Revital1 Eres wrote:
Hello,
Just did so... :-)
and it indeed solves this.
Remember to do the same for cstore.
Most of the time it will remove more code from your target than it adds.
I think that it did so for basically all targets in GCC 4.5, sometimes
cutting up
On Tue, May 25, 2010 at 16:59, Andreas Schwab sch...@redhat.com wrote:
Steven Bosscher stevenb@gmail.com writes:
So I guess this plan of mine is not going to work...
Other ideas?
Add $(CFLAGS-$(@F)) to the .c.o rule
Actually $@ is fine, since you want cp/tree.o to have different flags
All,
the toplevel configury of gcc/gdb/binutils is very much out of sync.
If people agree, I would like to freeze commits to the toplevel
configury until they are not diverging anymore.
Also, I would like to make a new policy that from now on patches to the
toplevel cannot be committed by
On 05/25/2010 07:09 PM, Ralf Wildenhues wrote:
* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST:
the toplevel configury of gcc/gdb/binutils is very much out of sync.
Unfortunately I don't have much time to devote to bringing the trees
back in shape, and not even to chase down
On 04/28/2010 12:33 AM, Alfred M. Szmidt wrote:
1) The back-and-forth is too much for casual contributors. If it is
more effort to do the legal work than to submit the first patch,
then they will never submit any patch at all.
Please do not exaggerate, if people have time for
On 04/28/2010 03:47 AM, Amker.Cheng wrote:
You can get the RTL for these patterns when expanding stores like
a = (b c);
In this case, GCC tries to avoid a conditional branch and (I suppose you are
on GCC4.5) instead of cmpmode and bcond you go through cmpmode and
scond. cmpmode does
[trimming Cc list]
It wouldn't be worth my time and I have trouble understanding how
I could demonstrate personal loss making the law suit worth persuing in
the first place.
Perhaps because you know the code better than anyone else, so you
could provide paid support on that derivative as
On 04/27/2010 11:42 AM, Amker.Cheng wrote:
Hi :
There is a pattern define_insn scode_mode in mips md file, like
(define_insn scode_mode
[(set (match_operand:CC 0 register_operand =z)
(swapped_fcond:CC (match_operand:SCALARF 1 register_operand f)
On 04/27/2010 03:46 AM, Russ Allbery wrote:
This is all relatively easily handled under the copyright policy on
the academic side of the house for students and faculty.
Unless it's institutional work... I was in the same boat during my
own Ph.D. studies, cherrypicking what to send for
On 04/26/2010 07:20 AM, Richard Kenner wrote:
[1] France in my case, probably Europe in general. What you do in
your free time is yours by default, land grab clauses are not
accepted, and it's only when you work at home on things you also
do at work that questions can be asked.
That's true in
601 - 700 of 1512 matches
Mail list logo
