2007/5/19, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Eric, what "reason previous stated"?
"loop.c is gone in the mainline sources. Patching it on the 4.1 branch is
allowed only if you have a testcase that exposes a serious bug."
--
Eric Botcazou
Yes! There is an serious bug! It's illegible
2007/5/21, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote:
> you have this nice cleanup's patch of gcc/loop.c that
> transliterates the logic
> of the uses of the loop_invariant_p (..) and
> consec_sets_invariant_p (..)
> f
2007/5/21, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 21, 2007, at 2:04 PM, J.C. Pizarro wrote:
> I hate the '-b-r-a-i-n [ ... ]
We don't use that sort of language around here...
Don't you understand the b-r-a-i-n-f-u-c-k-e-d source code?
http://en.wikipedia.org/wi
From "Frank Schaefer" <[EMAIL PROTECTED]> wrote:
Dear GCC Team,
Last weekend I finished the release of my directly coded
analyzer generator engine for Quex. First, I thought, it would
be just a nice idea to step away from table driven approach
of flex/lex. Directly coding also facilitates the st
2007/5/31, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
To obtain 200-250% in speed gain won't be possible for this GCC
optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law
To understand the law's idea, to see first the red-A & blue-B graphic.
GCC throws
2007/6/1, Frank Schaefer <[EMAIL PROTECTED]> wrote:
> To obtain 200-250% in speed gain won't be possible for this GCC
> optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law
Amdahl's Law talks about paralellism. That is not the case here.
He apply a different approach for le
Please, to see
1. "The LLVM Compiler System" by Chris Lattner
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf
2. "Vector LLVA: A Virtual Vector Instruction Set for Media Processing"
by Bocchino and Vikram
http://llvm.org/pubs/2006-06-15-VEE-
1. Stop developing new features to GCJ
and start to develop the more advanced IcedTea (a.k.a. OpenJDK).
http://icedtea.classpath.org/wiki//Main_Page
2. Stop developing new features to GCC's backend
and start to develop the more advanced LLVM-GCC.
http://llvm.org/ (Low Level Virtual Machine)
For performance and simplicity, i show this summary
1. "The LLVM Compiler System" by Chris Lattner
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf
2. "LLVM in OpenGL and for Dynamic Languages" by Chris Lattner
http://llvm.org/devmtg/2007-05/
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
I'm seeing this on my 16-bit ix86 port. Something isn't right:
insn_cost 5: 12
insn_cost 6: 8
insn_cost 7: 4
...
rejecting combination of insns 5 and 6
original costs 12 + 8 = 24
replacement cost 28
Now, 12 + 8 = 20, not 24. The cost obv
Uros Bizjak Mon, 02 Jul 2007 20:29:41 +0200 wrote:
Hello!
It is worth noticing that latest changes to gcc brought more than 75% speed-up
on Polyhedron aermod.f90 benchmark [1]. I can confirm this on 32bit nocona, and
double-checked on 64bit core2:
gcc -O3 -funroll-loops -ftree-vectorize -ffa
2007/7/25, Joe Buck <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote:
> Patch it to investigate it a little bit more.
>
> After runned it, see "quickdirty.log" and post here your report's summary.
No, please do not. This is
---> After 1 hour
I am mostly a beginer to this elf thing. From the report
above, I am not sure that I deduce anthing. Well my testcase
is a series of .byte directives (its an image)
Thanks for the response. Could you also throw some light on
the findings -if any- from the ab
Friendly Gaurav
Build it with the -ggdb2 option, and follow those steps:
$ gdb a.out
(gdb) start
(gdb) stepi
(gdb) backtrace
(gdb) step
(gdb) bt
(gdb) stepi
(gdb) bt
(gdb) help
It's funny ;)
Patch it to investigate it a little bit more.
After runned it, see "quickdirty.log" and post here your report's summary.
;)
libelf-0.8.2_quickdirtyprint.patch
Description: Binary data
On 26 Jul 2007, Andrew Pinski wrote:
| On 7/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
| > >I would like to propose the creation a new mailing list:
| > >[EMAIL PROTECTED]
| > >
| > >The purpose of this list is to attract and help new GCC developers who
| > >might feel lost and intimidated by
http://gcc.gnu.org/svn/gcc/branches/lto/ChangeLog
http://gcc.gnu.org/svn/gcc/branches/gimple-tuples-branch/ChangeLog
2007-07-17 Nick Clifton <[EMAIL PROTECTED]>
* COPYING3: New file. Contains version 3 of the GNU General
Public License.
* COPYING3.LIB: New file. Contai
2007/7/27, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 27, 2007 at 04:22:31PM +0200, J.C. Pizarro wrote:
> > The users don't want to join and detach to many mailing lists to post
> > only a message once by week or month. He wants to post quickly,
> > not to
Hi people,
I'm looking for simulators of 64-bit processors for my 32-bit PC and
i've found one.
"qemu-system-x86_64" works simulating a x86-64 linux as slamd64, ubuntu, etc.
http://fabrice.bellard.free.fr/qemu/status.html indicates that x86-64
is OK for System emulation but is not supported for
Hi people, i've my opinion about the future SPARCv9 (64 bit): awful!
IMHO,
* Before:
Development of SunCC was 10% time vs 90% time in the development of
GCC/binutils toolchain of SPARC for GNU/Linux.
* After:
Development of SunCC was 98% time vs 2% time in the development of
GCC/binutils toolcha
ization's features is more easy without
tree-ssa code.
Sincerely, J.C. Pizarro ;)
x bi-transformation
GIMPLE->SSA->GIMPLE?
Is more powerful GENERIC->GIMPLE->RTL + "trial-and-error" local optimization?
Sincerely, J.C. Pizarro
d person.
If SSA was made to permit to eliminate prematurely dead-code and to
optimize partially the register allocation then
why is hard to optimize unrolling loop, inlining code, instructions
scheduling, etc because of the SSA's presence?
Don't forget, "Premature optimization is the root of all evil".
J.C. Pizarro
2007/10/22, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote:
> > Are they mixed into a single
> >> variable declaration? Are they treated as separate variables and
> >> handled later by the register allocator?
>
> If possible, the former. If
E?
> >
> > Is more powerful GENERIC->GIMPLE->RTL + "trial-and-error" local
> > optimization?
> >
> >Sincerely, J.C. Pizarro
>
> everyone else here is too polite to tell it to you, but could you please
> shut up, until:
>
> -- you learn
eract with A.I. agents (e.g. ala
ants colonies) to go storing better rules in the databases (to reuse
them later).
* the C programming language that is used to develop GCC is not
following above these principles.
J.C. Pizarro
om cell 'b'. It's weird for me.
I've not idea WHERE put "hidden p_5 = phi(b)"!
Too it's possible to ocurr *p_2 = c where 'b' will be hidden used through
the pointer p_2. It's too weird for me.
J.C. Pizarro
q=__fixdfsi
http://www.busybox.net/lists/uclibc/2002-November/004938.html
http://stuff.mit.edu/afs/sipb/project/pilot/src/gnusrc/fpgnulib.c
http://sourceware.org/ml/crossgcc/2002-05/msg00011.html
http://www.cygwin.com/ml/newlib/2007/msg00929.html
http://mhonarc.axis.se/dev-etrax/msg05341.html
http://www.srcdoc.com/linux_2.2.26/floatlib_8c.html
http://forums.ni.com/attachments/ni/beta2/100/1/Linker%20error%20stream.txt
J.C. Pizarro
d gcc-4.3.15 quickly possible.
J.C. Pizarro
MBs of disk space. Why?
What is there inside of fat .gch file? What means the .gch file?
J.C. Pizarro
hy the modern gcc4's family is little bit slower than the older gcc3's family.
The gcc-4.3 snapshot is worse than gcc-4.2/gcc-4.1 in the code generation,
due to its bad code size (~2.3MB) and sometimes long run time (52s).
----------
J.C. Pizarro
2007/11/2, NightStrike <[EMAIL PROTECTED]>:
> On 11/1/07, Ted Byers <[EMAIL PROTECTED]> wrote:
> > --- David Miller <[EMAIL PROTECTED]> wrote:
> > > ...
>
> I agree with you 100%. It has always been my view that if you can't
> compile fast enough, then get another machine and use distcc, or get a
> Cheers,
> > Bingfeng
They need to add an algorithm post-SSA that the code reuse the variables
converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).
The algorithms of POST_INC and POST_DEC are very specific, so an above
general algorithm is sufficient.
J.C. Pizarro
2007/11/3, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> They need to add an algorithm post-SSA that the code reuse the variables
> converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).
I'm sorry, "a_k <- phi(a_k,...)" is invalid due to SSA form definition,
2007/11/3, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote:
> > They need to add an algorithm post-SSA that the code reuse the variables
> > converting a_j <- phi(a_i,...) to a_k <- phi(a_k,...).
> >
> > The algorithms of POST_INC and
..
B) Anyone has to compile .ads with -S option to get assembly .S files
and to upload to the svn/cvs tree for bootstrapping.
C) Google.
J.C. Pizarro
e in multicores capabilites of GCC,
acknowledge of
thread-safe, atomicity of certain operations used in parallelism, etc.
I've not more questions now, thanks.
Sincerely, J.C. Pizarro
Here http://gcc.gnu.org/develop.html#timeline , it's not a future roadmap,
it's a past roadmap.
Why doesn't it publish a "future roadmap", "ToDo", "plans",
or "ideas to be improved" ... in the GCC's development?
Sincerely, J.C. Pizarro
2007/11/19, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> http://gcc.gnu.org/wiki/DevelopmentSchedule
>
> On 19/11/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> > Here http://gcc.gnu.org/develop.html#timeline , it's not a future roadmap,
> >it&#x
Hello people, i've a question.
"Is it safe the code generation when GCC is using the options
-lpthread and -mmmx -msse -msse2 -msse3 -msse4?"
The GNU Portable Threads (of -lpthread) uses longjmp/setjmp that
saves general purpose registers but not SIMD registers.
GCC should to print warning or
To imagine that i'm using "-g -Os -finline-functions -funroll-loops".
There are differences in how to generate "optimized AND debugged" code.
A) Whole-optimized but with dirty debugged information if possible.
Wh
To imagine that i'm using "-g -Os -finline-functions -funroll-loops".
There are differences in how to generate "optimized AND debugged" code.
A) Whole-optimized but with dirty debugged information if possible.
Wh
On Nov 24, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> hat is indeed the problem, but I'm not sure your requirement is
> feasible. If we permit DECL_UID divergence, it means we can't use
> DECL_UID for hashing any more. Since they already stand for hashable
> proxies for the decl pointers,
The incomplete information (with losses) from A) doesn't mean BAD design.
This is as a paradox of compression,
A) for lossy compressors like JPEG, MP3, Ogg/Vorbis, MPEG, ...
and B) for lossless data compressors like PNG, GIF, zip, gzip, bzip2,
rar, 7z, ...
You will understand quickly the meaning
2007/11/26, Robert Dewar <[EMAIL PROTECTED]> wrote:
> The word "full" worries me a bit, I am afraid of it being interpreted as
> a requirement to be 100% "correct" in all cases, and this may be too
> severe. What we are looking for is good enough in practice, which is a
> vaguer criterion, but a mo
2007/11/26, Robert Dewar <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote:
>
> > You've reason, the world "full" can mean one of many scenarios depending
> > in how wants it to "be filled"!
> >
> > So, it's afraid unknownly in what s
On Nov 26, 2007, "Alexandre Oliva" <[EMAIL PROTECTED]> wrote:
> On Nov 26, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> > On Nov 26, 2007 7:57 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> >>
> >> > No, hashing is fine,
On Nov 26, 2007, J.C. Pizarro <[EMAIL PROTECTED]> that i wrote:
> ..., last access data for elimination from bigger cache, etc. }
I'm sorry, it's date, not data:
..., last access date for elimination from bigger cache, etc. }
Sincerely, J.C.Pizarro
On Mon, Nov 26, 2007, Karthik Kumar wrote:
> I would like to propose a set of diffs to enable compilation of gcc
> without requiring flex/bison. I feel that this would greatly benefit
> the variety of users building gcc.
Dear Karthik Kumar, why not flex/bison? It's bad idea not using them.
The to
On 2007/11/26, Karthik Kumar <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> On Nov 27, 2007 12:13 AM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 26, 2007, Karthik Kumar wrote:
> > > I would like to propose a set of diffs to enable compilation of gcc
>
For your Opteron, try with this option
-O3 -fomit-frame-pointer -march=k8 -funroll-loops -finline-functions
-fpeel-loops \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow
The Opteron hardware said that it's better to use SSE2 than SSE3.
The MMX and 3DNow!+ instructions are shorter and older than SSE2/
Hello.
I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
I suppose that there is not time to eliminate many bugs from
open regressions & others.
Could not we to use "Code coverage" of the GCC snapshot
during its bootstrapping or testsuite time?
2007/11/28, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 01:43:48AM +0100, J.C. Pizarro wrote:
> > I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
> > http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
> >
> > I suppose that there
$ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
$ du -s .
1044451 .
$
It's 1'069'517'824 characters made from keyboards and generators!!!
That massive!!! And slower checkout after several minutes!!!
Is not there any another solution to reduce this massive quantity
for the most recent part of the
On 2007/11/28, Ismail DAnmez <[EMAIL PROTECTED]> wrote:
> > $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> > $ du -s .
> > 1044451 .
> > $
> >
> > It's 1'069'517'824 characters made from keyboards and generators!!!
> >
> > That massive!!! And slower checkout after several minutes!!!
> >
> > Is n
builtins.def:635: DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECVE,
"execve", BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING,
ATTR_NOTHROW_LIST)
Is it BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING
a weird bug?
The correct const symbol is BT_FN_INT_CONST_STRING_PTR_CONST_STRING
Pl
On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> builtins.def:635: DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECVE,
> "execve", BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING,
> ATTR_NOTHROW_LIST)
>
> Is it BT_FN_INT_CONST_STRING_PTR_CONST_STRING
On 2007/11/29, Sylvain Pion <[EMAIL PROTECTED]>
> Michael Meissner a écrit :
> > One of the things that I've been interested in is adding support to GCC to
> > compile individual functions with specific target options. I first
> > presented a
> > draft at the Google mini-summit, and then another
On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> Autovectorization is still a researching issue.
+--++--+ /---\ ++
| unroll-loops | -> | inline-functions | -> < big BBs &g
On 2007/11/29, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 29 November 2007 00:12, J.C. Pizarro wrote:
>
>
> > The more weird thing was "..." in middle of the C's stack from
> > int execle(const char *path, const char *arg, ..., char * const envp[]);
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggressive -
On 2007/12/06, David Kastrup <[EMAIL PROTECTED]> wrote:
> Johannes Schindelin <[EMAIL PROTECTED]> writes:
>
> > However, I think that --aggressive should be aggressive, and if you
> > decide to run it on a machine which lacks the muscle to be aggressive,
> > well, you should have known better.
>
>
On 2007/12/06, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Thu, 6 Dec 2007, Jeff King wrote:
> > >
> > > What is really disappointing is that we saved only about 20% of the
> > > time. I didn't sit around watching the stages, but my guess is
On 2007/12/6, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> For multicores CPUs, don't divide the work in threads.
> To divide the work in processes!
>
> Tips, tricks and hacks: to use fork, exec, pipes and another IPC mechanisms
> like
> mutexes, shared memory's
The autotools ( automake + libtool + autoconf + ... ) generate many big
files that they have been slowing the building's computation and growing
enormously their cvs/svn/git/hg repositories because of generated files.
To see below interesting links:
1. http://dot.kde.org/1172083974/
2. http://sam.
On 2007/12/7, Jakub Narebski <[EMAIL PROTECTED]> wrote:
> Andreas Ericsson wrote:
> > Jakub Narebski wrote:
> > >
> > > Although there was some talk about whether giw should use autotools,
> > > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > > instead of its own handmade Ma
2007/12/7, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
> > On 07 December 2007 17:24, J.C. Pizarro wrote:
> >
> > > You can do a critical section mainly between processes
> >
> > Thanks for your w
On 2007/12/7, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 07 December 2007 18:09, J.C. Pizarro wrote:
>
> > You're wrong. My suggestions are not based from school and are not useless.
>
> Now /you're/ wrong: your suggestions *are* useless. You suggested using
>
In GPLed GCC-4.1 branch appears a notice of BSD license
gcc/config/i386/gmon-sol2.c
* Copyright (c) 1991 The Regents of the University of California.
* All rights reserved.
...
J.C.Pizarro sincerely ;)
On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc. It's been on my TODO list to code up the crypto
> > unit support for Niagara-2 in the kernel, th
On 2007/12/07, "Dave Korn" <[EMAIL PROTECTED]> wrote:
> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems. The code should be changed to call
> > execve instead. Unfortunately there is no standard execvpe function.
> > Fortunately gcc never use
At http://gcc.gnu.org/ml/gcc/2007-12/msg00360.html, Andreas Ericsson
<[EMAIL PROTECTED]> wrote:
> If it's still an issue next week, we'll have a 16 core (8 dual-core cpu's)
> machine with some 32gb of ram in that'll be free for about two days.
> You'll have to remind me about it though, as I've got
On 2007/12/12, "Diego Novillo" <[EMAIL PROTECTED]> wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think w
On 2007/12/12, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 12/12/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> >
> > * The googlish user says
> > "i'm using the massive googlecc compiler that uses a lot of tons
> > of libraries
> >
101 - 174 of 174 matches
Mail list logo
