Re: IRA for GCC 4.4

On Tue, 29 Apr 2008 20:25:56 +0200, "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > Vladimir, if you feel that Peter's code cannot be used directly in IRA, > > would you please explain why not? > > I think he already has

Re: Database for GCC

On Tue, 29 Apr 2008 08:16:14 -0500, "Tom Browder" <[EMAIL PROTECTED]> wrote: > A naive thought, perhaps: > > Would there be any advantage to using a key-value embedded database > program for the voluminous maps needed for gcc optimization, etc.? > > If so, consider

Re: IRA for GCC 4.4

On 2008/4/27 J.C. Pizarro <[EMAIL PROTECTED]> wrote: > On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner <[EMAIL PROTECTED]> wrote: > > The difference between a compressed upper triangular bit matrix from a > standard > > upper triangular bit matrix like the one abo

Re: IRA for GCC 4.4

On 2008/4/28 Dave Korn <[EMAIL PROTECTED]> wrote: > J.C. Pizarro wrote on : > > > > On 2008/4/28 Ben Elliston wrote: > >> On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: > >> > >> > Don't be stupid! > >> > >&g

Re: IRA for GCC 4.4

On 2008/4/28 Ben Elliston <[EMAIL PROTECTED]> wrote: > On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: > > > Don't be stupid! > > Could you be a bit more civil, please? It's fairly unusual for people > on this list to talk to each other in this way

Re: IRA for GCC 4.4

On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner <[EMAIL PROTECTED]> wrote: > On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote: > > Hi, Peter. The last time I looked at the conflict builder > > (ra-conflict.c), I did not see the compressed matrix. Is it in the > > trunk? What should I l

Re: gcc compiler for pdp10

On Fri, 18 Apr 2008 21:56:38 -0400, Alan Lehotsky <[EMAIL PROTECTED]> wrote: >Martin, > >I did a port of GCC to the Analog Devices SHARC chip. I ended up supporting 3 >kinds of pointers for this chip (two for address >spaces and one for byte pointers - the chip itself is only word addressable >(alt

Re: GSOC Student application

On 2008/3/30, Alexey Salmin <[EMAIL PROTECTED]> wrote: > > There are issues of Garbage Collection from libgcc or Boehms's GC > > that you possibly can't use another allocators that these defaults, > > unless you have control of the manager of the whole memory, > > and it's too complex due to

Re: GSOC Student application

On Sat, 29 Mar 2008 12:39:13 +0600, "Alexey Salmin" <[EMAIL PROTECTED]> wrote: > Hello, here's my application. Please, leave your comments as I still > have two days to fix it if something is wrong :) > > Project > I want to make some improvements in the Lexer/cpplib area: > 1) Change the way of fi

Re: larger default page sizes...

On 2008/3/26, J.C. Pizarro <[EMAIL PROTECTED]> i wrote: > On 2008/3/26, J.C. Pizarro <[EMAIL PROTECTED]> i wrote: > > On Tue, 25 Mar 2008 16:22:44 -0700 (PDT), David Miller wrote: > > > > On Mon, 24 Mar 2008, David Miller wrote: > > > > >

Re: larger default page sizes...

On 2008/3/26, J.C. Pizarro <[EMAIL PROTECTED]> i wrote: > On Tue, 25 Mar 2008 16:22:44 -0700 (PDT), David Miller wrote: > > > On Mon, 24 Mar 2008, David Miller wrote: > > > > > > > There are ways to get large pages into the process address space for

Re: Could someone please check if FSF received papers for Intel engineers?

On 2008/3/13, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Thu, Mar 13, 2008 at 2:38 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > > Ohh, contributions aren't accepted because they had not assigned > > the copyrights to FSF. > > > > Then, are we

Re: Could someone please check if FSF received papers for Intel engineers?

On 2008/3/13, Joe Buck <[EMAIL PROTECTED]> wrote: > This is off-list, because you are wasting the time of the list readership. No, it's the readership that has to waste its little time if he wants to read the short lines mails. > On Thu, Mar 13, 2008 at 08:14:38PM +0100, J

Re: Could someone please check if FSF received papers for Intel engineers?

On 2008/3/13, Robert Dewar <[EMAIL PROTECTED]> wrote: > J.C. Pizarro wrote: > > On Thu, 13 Mar 2008 09:44:29 -0400, David Edelsohn wrote: > >> The engineers currently are not listed in the FSF copyrights > >> assignment file. > >> > >&

Re: Could someone please check if FSF received papers for Intel engineers?

On Thu, 13 Mar 2008 09:44:29 -0400, David Edelsohn wrote: > The engineers currently are not listed in the FSF copyrights > assignment file. > > David Why they've to be listed in FSF copyrights assignment file? Intel released original x86 hardware. AMD released original x86-64 hardware. Int

Benchmarks: 7z, bzip2 & gzip.

Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222. -- # User's time is taken, machine is Ath64 3200+ 2.0 GHz x1, 64+64K

Re: optimizing predictable branches on x86

On Tuesday 26 February 2008 21:14, Jan Hubicka wrote: > Only cases we do so quite reliably IMO are: > 1) loop branches that are not interesting for cmov conversion > 2) branches leading to noreturn calls, also not interesting > 3) builtin_expect mentioned. > 4) when profile feedback is arou

Re: optimizing predictable branches on x86

It's a final summary for good performance of the tested machines: + unpredictable: * don't use conditional jmp (the worst). / * use cmov or C version. / \ + no deps: * use cmov or C version. \ / + predictable: \ + has deps: * do

Re: optimizing predictable branches on x86

On 2008/2/26, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote: > 4. C > cmov >> jmp when it's unpredictable and has not data dependencies. I'm sorry of my error typo, the correct is (without the "not") 4. C > cmov >> jmp when it's unpredicta

Re: optimizing predictable branches on x86

Compiling and executing the code of Nick Piggin at http://gcc.gnu.org/ml/gcc/2008-02/msg00601.html in my old Athlon64 Venice 3200+ 2.0 GHz, 3 GiB DDR400, 32-bit kernel, gcc 3.4.6, i got $ gcc -O3 -falign-functions=64 -falign-loops=64 -falign-jumps=64 -falign-labels=64 -march=i686 foo.c -o foo $ .

When the R.I.P. of 4.1.x branch for?

The 4.0.x branch was R.I.P.ed. Commiting 4.1.x, 4.2.x, 4.3.x and 4.4.x means 4 times of efforts than 3 times. They are very similar in design, they use TreeSSA, autovectoring, etc. It's recommended to be online 4.2.x, 4.3.x and 4.4.x branches. I want to see a comparison of performances between 4

Idea to gain the time of wider testing.

Hallo! I've ideas when there are repetitive processes as e.g. the testing processes. Q1. Why to lose time testing the same reiterated files that always had worked for many months or years? A1. To cache them the worked testsuite's files that had worked for many months or years and put it t

Superfluous testresults in 4.4.0.

Hallo, i'm comparing minor differences between testresults of 4.4/4.3 (20080221 x64) http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01486.html http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01487.html and i found superfluous reporting in 4.4.0: FAIL: foo/bar.mm (test for excess errors) UNRESO

RE: RFC: GCC 4.4 criteria - add Fortran as primary language?

On Wed, 20 Feb 2008, "Weddington, Eric" <[EMAIL PROTECTED]> wrote: > > Maybe there could be a "semi-primary" or "experimental > > primary" status; > > a feature could be treated as primary, but with the understanding that > > the requirement will be waived if it causes excessive delay. The > > "ex

Slow GCC compiler => Very few people recompile lesser latest packages.

Hallo, When the recent GCC compiler is very slow compiling projects or packages then many people refuse to follow recompiling updated versions of projects, few people tend to test each time less the updated versions, there are less beta testers and finally less detection of unknown bugs . Where G

Is there summarized table of ABI binary compatibility?

Hallo, Is there summarized table of ABI binary compatibility of following compiled programs by ...? 1st. C (the core) 2nd. Fortran 3rd. C++ and 4th. GCJ's Java between the 4.3.0, 4.2.3, 4.1.x, 4.0.x, 3.4.x and 3.3.x versions? The comments are not for me, they are for everyones who need maintain

Re: [RFC] WHOPR - A whole program optimizer framework for GCC

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 > >

Re: [RFC] WHOPR - A whole program optimizer framework for GCC

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

Re: Something is broken in repack. Why not with fork and pipes?

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

The Regents of the University of California BSD-license in GPLed GCC.

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 ;)

Re: Git and GCC

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

Re: libiberty/pex-unix vfork abuse?

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 >

Re: libiberty/pex-unix vfork abuse?

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

RE: libiberty/pex-unix vfork abuse?

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

Re: In future, to replace autotools by cmake like KDE4 did?

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

In future, to replace autotools by cmake like KDE4 did?

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.

Re: Git and GCC. Why not with fork, exec and pipes like in linux?

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

Re: Git and GCC. Why not with fork, exec and pipes like in linux?

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

Re: [PATCH] gc --aggressive: make it really 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. > >

Re: Git and GCC

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 -

Re: Bug in builtins.def, the execve. don't use execle, use execel.

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[]);

Re: Function specific optimizations call for discussion

On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote: > Autovectorization is still a researching issue. +--++--+ /---\ ++ | unroll-loops | -> | inline-functions | -> < big BBs &g

Re: Function specific optimizations call for discussion

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

Re: Bug in builtins.def, the execve. don't use execle, use execel.

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

Bug in builtins.def, the execve.

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

Re: svn trunk reaches nearly 1 GiB!!! That massive!!!

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

svn trunk reaches nearly 1 GiB!!! That massive!!!

$ 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

Re: Why don't use "Code Coverage" in GCC?

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

Why don't use "Code Coverage" in GCC?

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?

Re: [Fwd: performance with gcc -O0/-O2]

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/

Re: Suggestion for removing flex/bison as a dependancy

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 >

Re: Suggestion for removing flex/bison as a dependancy

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

Re: Designs for better debug info in GCC

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

Re: Designs for better debug info in GCC

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,

Re: Designs for better debug info in GCC. Choice A or B?

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

Re: Designs for better debug info in GCC. Choice A or B?

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

Re: Designs for better debug info in GCC. Choice A or B?

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

Re: Designs for better debug info in GCC. Choice A or B?

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,

Re: Designs for better debug info in GCC. Choice A or B?

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

Re: Designs for better debug info in GCC. Choice A or B?

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

SIMD-enabled and -lpthread incompatible?

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

Re: Has anyone idea/plans for GCC-4.4? No such roadmap, I not idea.

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

Re: Has anyone idea/plans for GCC-4.4? No such roadmap, I not idea.

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

Has anyone idea/plans for GCC-4.4? No such roadmap, I not idea.

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

Re: GNAT is required to build ada

.. 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

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

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

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

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,

RE: Tree-SSA and POST_INC address mode inompatible in GCC4?

> 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

Re: Results of 7z-4.55 performance with current GCCs.

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

Results of 7z-4.55 performance with current GCCs.

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

What means the fat .gch file?

MBs of disk space. Why? What is there inside of fat .gch file? What means the .gch file? J.C. Pizarro

Re: GCC 4.3 release schedule

d gcc-4.3.15 quickly possible. J.C. Pizarro

Would you like to give me advice about how to compile gcc? __addd3f link error.

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

Re: alias and pointers analysis

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

Re: From SSA back to GIMPLE.

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

Re: From SSA back to GIMPLE.

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

Re: From SSA back to GIMPLE.

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

Re: From SSA back to GIMPLE.

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

Re: From SSA back to GIMPLE.

x bi-transformation GIMPLE->SSA->GIMPLE? Is more powerful GENERIC->GIMPLE->RTL + "trial-and-error" local optimization? Sincerely, J.C. Pizarro

one question: tree-ssa vs no tree-ssa? no such global optimization exists.

ization's features is more easy without tree-ssa code. Sincerely, J.C. Pizarro ;)

Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?

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

What 64-bit CPU targets dominate in the future?

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

Re: Creating gcc-newbies mailing list. Too many mailinglists? Unified mailing list?

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

GPLv3 in LTO and GIMPLE branches ya?

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

Re: Creating gcc-newbies mailing list. Too many mailinglists? Unified mailing list?

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

Re: dlopen() crash -gcc 3.4.6 20060404

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 ;)

Re: URGENT : elf_update - low performance with large files ? (fwd)

---> 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

Re: URGENT : elf_update - low performance with large files ? (fwd)

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

Re: URGENT : elf_update - low performance with large files ? (fwd)

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

Re: Wow!

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

Proposal: adding two zeros to the integer cost to calibrate better.

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

When EOL? Replacing GCJ by IcedTea, GCC by LLVM.

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/

When EOL? Replacing GCJ by IcedTea, GCC by LLVM.

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)

Re: Some thoughts about steerring commitee work

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-

Re: Very Fast: Directly Coded Lexical Analyzer

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

Re: Very Fast: Directly Coded Lexical Analyzer

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

Re: Very Fast: Directly Coded Lexical Analyzer

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

Re: I don't understand some of gcc-4.1-20070514, a patch here.

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

Re: I don't understand some of gcc-4.1-20070514, a patch here.

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

Re: I don't understand some of gcc-4.1-20070514, a patch here.

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

  1   2   >