On Sat, Sep 4, 2010 at 05:53, Jack Howarth 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
> to start...
>
> 1) Mo
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 opini
On 09/10/2010 03:12 PM, Manuel López-Ibáñez wrote:
On 10 September 2010 15:00, Steven Bosscher wrote:
On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner
wrote:
Some strong way of addressing the concern that this could be used to make
proprietary front-ends or proprietary back-ends using part of
On 09/19/2010 11:05 AM, Ralf Wildenhues wrote:
Hi Paolo, all,
any plans to bump Autoconf and Libtool versions used in GCC?
I'd like to see 2.68 and 2.4.0 in 4.6 in due course of course
(i.e., after both have been released, and before stage 1 ends).
Regarding Libtool, sure. However, we need to
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 make_m
On 09/23/2010 08:49 PM, Ian Lance Taylor wrote:
Diego Novillo 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
indentation in gengty
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 because
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 "vol
> 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
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
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 2
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/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/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/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 introduce
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/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?
Pa
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 (I
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 constrain
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/
-B/Users/regress/tbox/objs/pow
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/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 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 spli
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
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 :
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 will only be built
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromey writes:
"Ian" == Ian Lance Taylor 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 *
Ian> +objfile_attri
On 11/02/2010 11:50 AM, Paolo Bonzini wrote:
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromey 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 c
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
bri
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 libt
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/09/2010 10:22 AM, Joern Rennecke wrote:
Quoting roy rosen :
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 splitting and at the end w
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/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 witho
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Paolo
On 11/13/2010 03:34 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
x86 has
;; Clear the upper 128bits of AVX registers, equivalent to a NOP
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and
it would be valid, but not a noop.
Paolo
On 11/13/2010 05:10 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and i
On 11/13/2010 10:08 PM, Xinliang David Li wrote:
Though gcc leads LLVM in performance overrall, there are a couple of
benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and
twolf (32bit), vortex (64bit). This needs to be triaged. gcc
miscompiles gcc and eon in 32bit -- is there
The only targets that are using textual prologues and epilogues are now
arc, cris, pdp11 and vax. ARC should probably have been deprecated long
ago, any plans to convert the others or (for cris) to flip the default?
Paolo
We currently have 3 non-algorithmic maintainers:
loop optimizer Zdenek Dvorak o...@ucw.cz
loop optimizer Daniel Berlin dber...@dberlin.org
libcpp Tom Tromey tro...@redhat.com
Especially for the loop optimizer, the situation is a
On 11/15/2010 04:48 PM, Joseph S. Myers wrote:
* The macro is tested with #if/#ifdef/#ifndef/#elif in a source file
outside of config/ (but including front-end subdirectories). Care is
needed in identifying such macros through grep because of
backslash-newline line continuations and because it's
On 11/15/2010 11:10 PM, Hans-Peter Nilsson wrote:
There *is* an option to omit the prologue and epologue
controlling the TARGET_PROLOGUE_EPILOGUE; I'm guessing that
could cause confusion.
That's what confused me.
Is that getting in the way of something?
Yes, there is code conditionalized on
On 11/16/2010 10:17 PM, Ian Lance Taylor wrote:
I don't know how we want to get there, but it seems to me that the place
we want to end up is with the target hooks defined to take an argument
of type struct cumulative_args * (or a better name if we can think of
one).
Actually, this doesn't work
On 11/17/2010 03:10 AM, Ian Lance Taylor wrote:
Joern Rennecke writes:
I don't see how going to a struct cumulative_args gets us closer
to a viable solution for a multi-target executable, even if you
threw in C++. Having the target describe a type, and shoe-horning
this through a target hook i
> Is there sufficient interest to post the branch patches to gcc-patches as I
> go?
If not that could be a substantial review headache at merge time.
On 18/12/2010, Joern Rennecke wrote:
> I have created the branch:
> svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch
> to continue work
On 12/20/2010 12:43 PM, Claudiu Zissulescu wrote:
Hi,
Why don't you use a define_insn "zero_extendbisi2" which generates
your conversion instruction.
You're right that this should be a valid workaround, but Bingfeng
reported a bug indeed.
(zero_extend:SI (reg:BI 120))
should have been tran
On 12/22/2010 03:43 PM, Bingfeng Mei wrote:
Thanks for letting me know this. Since only our target experiences such
issue, I guess no other processors have such requirements of manipulating
BImode. I can live with the workaround now.
Perhaps Blackfin, but it has a BI->SI extension instruction s
On 01/26/2011 03:55 PM, James Murray wrote:
On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:
Stephane Carrez is listed as maintainer of the port, so he should
know how to contribute fixes to the port upstream.
Yes, but as I said... he is no longer active on this port. His last
publ
On 01/26/2011 08:56 PM, Diego Novillo wrote:
At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).
The best way of thinking about it is "bugzilla for patches". The
system creates an entry for every p
On 01/26/2011 08:56 PM, Diego Novillo wrote:
At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).
The best way of thinking about it is "bugzilla for patches". The
system creates an entry for every p
I think this is either PR 25890 or PR 25905.
It's PR25905, an assertion failure caused by invalid RTL produced by
expand. (PR25890 instead is where combine produces invalid RTL that
fails its own assertion).
Paolo
tractions.
The attached patch does exactly this. I'm bootstrapping it overnight,
but I'll post it right now so that people affected by the bug can also
test it.
Ok for mainline if it passes?
Paolo
2006-01-23 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optimization/25890
OK to revert this workaround now? Mainline now passes bootstrap &
regtesting on i686 without it.
You can approve reversion of your own patches. svnwrite.html says that
"no outside approval is needed to revert a patch that you checked in."
Paolo
I tried 'make all-stage1 STAGE1_LANGUAGES=c++,fortran'. Not only that
didn't work, it wiped the directory /gcc/testsuite.
I believe it was only relocated in stage3-gcc/testsuite.
Right now to change the STAGE1_LANGUAGES, you have to remove the
stage1-gcc directory. I have a patch to fix this
Diego Novillo wrote:
Paolo Bonzini wrote:
I believe it was only relocated in stage3-gcc/testsuite.
Huh. Any reason in particular? Why not leave it in /gcc?
Because all the gcc directory has been relocated in stage3-gcc. It
allows you for example to run the testsuite for stage2
So, I would just need to move /gcc/testsuite into /stage1-gcc?
I suppose. I don't understand why can't you just look in
stage3-gcc/testsuite, but I guess you know what you're doing. :-)
Also note that with my patch you could do make check-fortran: all the
targets for the disabled languag
Is it intentional that these functions have global visibility and
interfere with functions declared and implemented by the system
libraries? If not, can they be compilied with hidden visibility?
Yes (I originally tried to "see what happens if we use the glibc
routines", then I shared the c
As an aside, the cross compiler successfully builds and links target
libraries because it uses:
[EMAIL PROTECTED]:~/gcc-build$ cat gcc/as
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-as "$@"
[EMAIL PROTECTED]:~/gcc-build$ cat gcc/collect-ld
#!/bin/sh
exec /opt/odcctools/bin/i386-
Darthrader (sent by Nabble.com) wrote:
Is the AST[Abstract Syntax Tree] machine dependent?
The nodes that are generated for the program as it is parsed are machine
independent. However:
1) this can only be true if your source code is already preprocessed.
Otherwise, the source code that GC
Sorry if I am more terse this time. Also, these questions are now more
suited for the gcc-help list, rather than this one which is for
development of GCC itself.
# 1 "test.c"
# 1 " "
# 1 " "
# 1 "test.c"
What do these represent?
Try "info cpp", and search for "Preprocessor Output".
Kindl
Liu Haibin wrote:
Hi,
I wanted to use bb->count, so I expected that -fprofile-arcs and
-fbranch-probabilities would help. I added printf just before
peephole2 optimization and ran the following.
$gcc -O3 -fprofile-arcs test.c -o test
$./test (which produced test.gcno only, but no test.gcda)
$gc
Hi!
My spec cpu2000 run shows 252.eon miscompared with i686-redhat-linux
4.1.0 20060221 (prerelease) compiler. Optimization level is -O2. Spec
reported "miscompare of pixels_out.kajiya".
Has anybody seen this before?
You should use -ffast-math for eon.
Paolo
There's a requirement to not use footnotes in install.texi, apparently.
Also, I did not know about install.texi2html so I added a note on it.
Ok to install?
Paolo
2006-02-22 Paolo Bonzini <[EMAIL PROTECTED]>
* install.texi: Add notes on install.texi2html.
(
There's a requirement to not use footnotes in install.texi, apparently.
Also, I did not know about install.texi2html so I added a note on it.
Ok to install?
Paolo
2006-02-22 Paolo Bonzini <[EMAIL PROTECTED]>
* install.texi: Add notes on install.texi2html.
(
Gerald Pfeifer wrote:
Hi Paolo,
thanks for the patch. I just saw Joseph's okay, but I believe there
is one minor detail left.
On Wed, 22 Feb 2006, Paolo Bonzini wrote:
+GNU Make 3.79 and above, which is necessary to build GCC, support
+building in parallel.
Specifically, i
Joel Sherrill wrote:
Hi,
I think/thought this has been dealt with
but am not sure. I started with a fresh install
directory, built and installed a native GNU/Linux
C, C++, and Ada toolset. Then proceeded to
try to build cross Ada for *-rtems. All targets
are failing because they are not find
Mark Mitchell wrote:
I will spin GCC 4.1 RC2 tonight.
The only patch I plan to apply, relative to current sources, is Paolo
Bonzini's Ada patch.
... which is revision 108058. I gather that you want to apply it yourself?
r108058 | bonzini | 2005-12-05 15:40:27 +0100 (Mon, 05 Dec
So is it feasible that I can make executable to output gcda file to my
Host PC via fputs or fwrite?
Sure. The easiest way is to run the program under a functional
simulator of the nios2, that can map system calls from the C library to
I/O on the target board. The Altera people probably kno
Comments? I'm of course also volunteering to write the patch, provided that
an adept at the new bootstrap (black) magic gives me a clue as to where I
should start. :-)
You just have to write the test in the toplevel configure.in, and place
it just before the AC_SUBST(stage1_cflags).
The m
I'm happy to hear that. I've tried 4.1 and it works
like a charm. I hope that the same happens with glibc.
I doubt that. And glibc is much harder to set up and is usually built
only by "people that know what they're doing"; which means you have a ~0
chance of getting the maintainers to do t
That's sad news. Maybe they would would consider a
well-written patch; I have to try.
If you want to remain sane, don't look at their makefiles. :-)
(Note that GCC 4.1.x is just building with builddir
!= srcdir under your feet).
That's perfectly good for me.
That was to mean, that the
the only trouble is that the tree generated unpacking and compiling
libmpfr.2.2.0.tar.bz2 is not compatible with what --with-mpfr-dir
expects, so that configure exits; I had to copy the mpfr include files
in foo/include, the libraries in foo/lib and use --with-mpfr=../../foo .
You have to sp
Zdenek Dvorak wrote:
Hello,
here is a proposal for the patch to remove loop notes (I still need to
benchmark it, and probably split into smaller parts). However, I do not
understand some of the code from that it removes loop note usage, so I
would appreciate comments on them:
cse.c:cse_end_of_
So I'm basically asking for people who want to play around with some
cool new technology to help make source code better. If this interests
you, please feel free to reach out to me directly. And of course, if
there are other packages you care about that aren't currently on the
list, I want
I reproduced this with just gcc-core, I normally also build g++ and
gfortran as well. The problem goes away if I unpack the sources for
objc, which I am not really interested in.
Any takers? How/against what do I report this?
The problem is that now configure is processing config-lang.in fil
target-zlib: should be sufficient to add i386-darwin to the supported
platforms
zlib is being skipped only because libjava is.
target-boehm-gc: a patch exists for porting to the new platform, so it
should be a matter of applying it
Well, good.
target-libffi, target-libmudflap, target-libj
tbp wrote:
On 3/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Actually the best way of improving the inline heuristics is to get
a real testcase (and not some benchmark) where the inline heuristics
is messed up.
Ah, you mean a brand new testcase because PR-21195 wasn't good enough?
show u
bool
truncated_to_mode (enum machine_mode mode, rtx x)
{
if (REG_P (x) && rtl_hooks.reg_truncated_to_mode (mode, x))
return true;
gcc_assert (!TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode),
GET_MODE_BITSIZE (GET_MODE (x)));
return num_sign_b
config.log in libiberty contains:
configure:2272:
/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2/./prev-gcc/xgcc
-B/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2/./prev-gcc/
-B/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install/i686-pc-linux-gnu/bin/ -c
-g -O2 conftes
Rainer Emrich wrote:
Paolo Bonzini schrieb:
I have a patch. Will keep you posted.
Paolo
Now it's completly broken!!!
But I didn't commit anything, and not even posted it, because of the
breakage... :-)
Paolo
Mike Stump wrote:
In:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02102.html
you add restrap unconditionally, and yet it was already defined above,
thus causing make to say:
Yeah, I had delayed a bit the fix hoping that Dan J. would rip out the
old bootstrap mechanism. He did not, so since
Michael Matz wrote:
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
The lower-subreg patch that Richard
The lower-subreg patch that Richard Henderson posted, and that comes
up again and again from time to time, may also help. It does require
a bit of hacking in the MDs (mostly removing the DImode patterns for
logical operations since the middle-end is able to synthesize them on
its own).
Tha
The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.
Apparently, the GNU Pascal crew did not want integration with every
Piotr Marasz wrote:
I try compile example program
gcc.exe -I"c:\gcc\include" -L"c:\gcc\lib" c:\gcc\bin\program.c
gcc.exe: Internal error: (null) (program as)
Please submit bug report.
First the bug report should not go here but to
http://gcc.gnu.org/bugzilla (this is a list for development of
Also, is there a function for simplifying a zero_extract?
What combine is doing is to expand compound operations such as
zero_extract, simplifying them, and try to make new compound operations.
Therefore you should first try to understand what's causing combine to
miss the simplification.
I think it is simply because combine.c doesn't have any code to simplify this kind of expression.
In theory it should have...
However, if you add these simplifications to simplify-rtx.c, it will
be picked up by combine.
There is a lot of simplification code in combine.c too. Should I
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Because (that's unfortunate, agreed) GCC does need some marketing.
Unfortunately people compare GCC with icc (or other compilers) using
SPEC, and you want them to compare apples to apples -- compile
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.
From what I can see of the source,
> The short answer is that AltiVec dictated this behavior. :-( Longer
> answers were given by Ian and Paul, and I agree with them.
OK, so: firstly, is this behaviour actually documented anywhere? In
AltiVec docs, maybe?
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?
> "Vector types can be cast to other vector types. The cast does not
> perform a conversion: it preserves the 128-bit pattern, but not
> necessarily the value. A cast between a vector type and a scalar type is
> not allowed."
Everything becomes clear. I would never have started this thread
If you're interested in adding value for generic vectors, it may be
interesting to consider element access operations. Being able to
write things like:
float X = V[1];
or
V[2] = X;
That was on my todo list, but unfortunately I have little time for FSF
work now and this would require me to
The point is that the existing Altivec and SPE cast syntax requires that
a C-style cast from one vector type to another be bit-preserving. So,
we can't change that (or static_casts, which are the kind of C++ cast
that are using to implement this kind of C-style cast) without breaking
backward
Inder wrote:
Hi All,
From the GCC manual, its clear that optimization options from –O1 to
–O3 or any greater level emphasis On the performance while –Os
emphasis only on the code size, it (-Os) says nothing about the
performance (execution time).
In our case : Size in case of –Os is less than
Inder wrote:
Hi All,
From the GCC manual, its clear that optimization options from –O1 to
–O3 or any greater level emphasis On the performance while –Os
emphasis only on the code size, it (-Os) says nothing about the
performance (execution time).
In our case : Size in case of –Os is less than
701 - 800 of 1079 matches
Mail list logo
