Bugs in operations of "long" type from GCC-3.4.6 32 bit.

Hi people, bug_mult_and_shift_long.c - #include // it's for public domain by J.C. Pizarro, hahahahaha int main() { long long int a,b,c; unsigned int hi_a,lo_a,hi_b,lo_b,hi_c,lo_c; a = 100L; // 10G b = 1L; // 100M c = a * b; hi_a = (((uns

Bugs in operations of "long" type from GCC 4.1.3 20070326 (prerelease) 32 bit too.

Hi people, bug_mult_and_shift_long.c - #include // it's for public domain by J.C. Pizarro, hahahahaha int main() { long long int a,b,c; unsigned int hi_a,lo_a,hi_b,lo_b,hi_c,lo_c; a = 100L; // 10G b = 1L; // 100M c = a * b; hi_a = (((unsigned

Re: Bugs in operations of "long" type from GCC-3.4.6 32 bit.

2007/3/28, Andreas Schwab <[EMAIL PROTECTED]> wrote: "J.C. Pizarro" <[EMAIL PROTECTED]> writes: > Brief summary, there are 3 bugs: None of them are bugs in the compiler, only in your program. Sure? My program is a testsuite of why the long type doesn't work,

Re: Bugs in operations of "long" type from GCC-3.4.6 32 bit.

27 Mar 2007 16:35:16 -0700, Ian Lance Taylor <[EMAIL PROTECTED]>: You are confusing long and long long. This is C, not Java. The suffix for a long long constant is LL, not L. Very thanks, LL and %lld are the solution. The GCC compiler has not bugs that i said. testing_long_GCC_march2007_3.t

Re: Bugs in operations of "long" type from GCC-3.4.6 32 bit.

2007/3/28, Andreas Schwab <[EMAIL PROTECTED]>: "J.C. Pizarro" <[EMAIL PROTECTED]> writes: > The range of long should be -(2^63) .. +((2^63)-1). Your long has only 32 bits. > For shifts, the range of a long type should be 0 .. 64 (65 values), not 0 .. 31. Your lo

Is it possible to do some GCC's stages more "modular"?

Hi people I want to talk an interesting topic of GCC hierarchy of subhierarchies. By example, i want to add my personal option of optimization to GCC but I see that it's very "monolithic". I don't see the subhierarchy of optimation stage in the snapshot tree. Sincerely yours, J.C. Pizarro

Re: Proposal: changing representation of memory references

It's poorly implemented, unrefactored, without formal specification, without OO hierarchy, etc. "The pointers are the evilness of the optimization".

Re: Integer overflow in operator new

2007/4/6, Karl Chen <[EMAIL PROTECTED]>: Hi all, apologies if this has been discussed before, but I couldn't find anything about this issue in gcc mailing list archives. Use of operator new (et al) appears to have an integer overflow; this function: int * allocate_int(size_t n) {

Re: Integer overflow in operator new

f CATCH_NEW_INTRUDER log_and_raise_if_new_intruder_anomaly(n,4); #endif //CATCH_NEW_INTRUDER p = (int*) operator new[](4 * n); #ifdef CATCH_NEW_INTRUDER log_and_raise_if_new_intruder_anomaly_return_not_null(n,4,p); #endif //CATCH_NEW_INTRUDER return p; } J.C. Pizarro

Re: Integer overflow in operator new

So, the programmers don't have many times to write extra code for calling into operator new. The compiler should be able to eliminate many of the conditionals. Yes but no, there are cases that the compiler can't eliminate the conditionals that depend on run-time, e.g., "n" is non-constant parameter. J.C. Pizarro

Re: Integer overflow in operator new

06 Apr 2007 18:53:47 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]>: "J.C. Pizarro" <[EMAIL PROTECTED]> writes: [...] | > The compiler should be able to eliminate many of the conditionals. | Yes but no, there are cases that the compiler can't eliminate the | condit

Super bad accuracy in the output of gprof when is used -pg.

speedup formula from the Amdahl Law. Can it use the privileged i586's RDTSC to count the time in CPU cycles? Thanks J.C. Pizarro probing_p7zip-4.44_20070407.tar.bz2 Description: BZip2 compressed data

Re: Super bad accuracy in the output of gprof when is used -pg.

d of 0.00 us * 0. ms instead of 0.00 ms J.C. Pizarro

Re: Integer overflow in operator new

ables) or extend the ELF format to permit pack the sections with GZ, BZ2 or LZMA. Ross Ridge J.C. Pizarro.

Re: Integer overflow in operator new

2007/4/7, Robert Dewar <[EMAIL PROTECTED]>: > A solution is using the -shared option to generate ".so" library. That does not solve things in environments like embedded environments where there are no shared libraries. Use -Os and "strip --strip-all". And remove code if you don't like it. >

Re: Integer overflow in operator new

2007/4/7, Robert Dewar <[EMAIL PROTECTED]>: > > A solution is using the -shared option to generate ".so" library. > > That does not solve things in environments like embedded > environments where there are no shared libraries. Use -Os and "strip --strip-all". And remove code if you don't like it.

Re: Integer overflow in operator new

Joe Buck wrote: > > > inline size_t __compute_size(size_t num, size_t size) { > > > size_t product = num * size; > > > return product >= num ? product : ~size_t(0); > > > } 2007/4/9, Ross Smith <[EMAIL PROTECTED]> wrote: On Monday, 9 April 2007 10:23, Florian Weimer wrote: > * Ross Rid

Re: Integer overflow in operator new

cmpl$1048575, %ebx movl12(%ebp), %ecx setbe %dl xorl%eax, %eax cmpl$4095, %ecx setbe %al andb$1, %dl testl %eax, %eax orl $-1, %eax xorl%edx, %edx divl%ecx orl $-1, %edx cmpl%eax, %ebx movl%ebx, %edx imull %ecx, %edx popl%ebx movl%edx, %eax popl%ebp ret J.C. Pizarro

Re: Integer overflow in operator new

And this tarball. J.C. Pizarro. compute_size_april2007_2.tar.gz Description: GNU Zip compressed data

Re: Integer overflow in operator new

8(%ebp), %edx movl%edx, %eax imull 12(%ebp), %eax cmpl%edx, %eax orl $-1, %eax popl%ebp # <--- no extra instruction because return EAX = EAX? ret J.C. Pizarro

Re: Integer overflow in operator new

70326 (prerelease) and gcc 3.4.6 : 7 instructions ] movl4(%esp), %edx cmpl12(%esp), %edx movl8(%esp), %eax movl$-1, 4(%esp) imull %edx, %eax movl%eax, 4(%esp) jmp _Znaj ------------- J.C. Pizarro

Re: Integer overflow in operator new

allocate_array_april2007.tar.gz Description: GNU Zip compressed data

Re: Integer overflow in operator new

2007/4/9, J.C. Pizarro <[EMAIL PROTECTED]> wrote: _Z29__allocate_array_of_RossRidgejjj: [ gcc v3.4.6 : 9 instructions ] movl4(%esp), %edx cmpl12(%esp), %edx # comparing and ?? i lose me movl8(%esp), %eax orl $-1, %eax imull

Re: Integer overflow in operator new

2007/4/9, Robert Dewar <[EMAIL PROTECTED]>: J.C. Pizarro wrote: > The multiply is signed. It is need more researching a little bit. So what, the low order 32 bits are unaffected. I think this is just confusion on your part! Yes, i accidently eliminated the lines containing

Re: Integer overflow in operator new

jmp .L6# <- why not jmp _Znaj directly? .L2: #APP mull %edx # unsigned 32x32!!! mul is little bit slower than imul in clock cycles. #NO_APP movl%eax, 4(%esp) .L6: jmp _Znaj --------

Re: Integer overflow in operator new

2007/4/9, Ross Smith <[EMAIL PROTECTED]> wrote: On Monday, 9 April 2007 13:09, J.C. Pizarro wrote: > > This code is bigger than Joe Buck's. > > Joe Buck's code: 10 instructions > Ross Ridge's code: 16 instructions > Ross Smith's code: 16 instructions

Re: Integer overflow in operator new. Solved?

jmp _Znaj directly? .L2: movl%eax, 4(%esp) .L7: jmp _Znaj - It seems to be solved the integer overflow in operator new. J.C. Pizarro. allocate_array_longmult_april2007.tar.gz Description: GNU Zip c

Re: Integer overflow in operator new. Solved?

2007/4/9, Joe Buck <[EMAIL PROTECTED]>: On Mon, Apr 09, 2007 at 09:47:07AM -0700, Andrew Pinski wrote: > On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > >#include > > > >void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best > > unsig

Re: Integer overflow in operator new. Solved?

4. Conditional moves (cmov).

Re: Integer overflow in operator new

ic count. The static count, which could affect density of cache use, should also include the alternate return value. -- Lawrence Crowl With CoreDuo, the density of cache use is not our problem because there are L2 caches of 2 MiB! 4 MiB! and even more 6 MiB!!!. Our main problem is to reach the maximum performance for future days. J.C. Pizarro

Re: Integer overflow in operator new. Solved?

2007/4/9, Andrew Pinski <[EMAIL PROTECTED]>: On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > 3. To modify the C-preprocessor and/or C/C++ compiler for: >#if argument X is a constant then > use this code specific of constant X >#els

Re: Integer overflow in operator new. Solved?

2007/4/9, J.C. Pizarro <[EMAIL PROTECTED]> wrote: 2007/4/9, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > Well lets say this, we already support this to some extend, by using > __builtin_constant_p and then just i

Re: Integer overflow in operator new. Solved? Experimental i686 code.

ay_OptionCjj: movl4(%esp), %eax #APP orl $-1,%ecx imull 8(%esp) cmovol %ecx,%eax #NO_APP movl %eax, 4(%esp) jmp _Znaj - J.C. Pizarro allocate_array_20070409-1.tar.gz Description: GNU Zip compressed data

Re: Integer overflow in operator new. Solved? Experimental i686 code.

!!! (cmovo came from i686) * no conditional jump !!! _Z24__allocate_array_OptionDjj: movl4(%esp), %eax #APP imull 8(%esp) cmovol minus_one,%eax #NO_APP movl%eax, 4(%esp) jmp _Znaj minus_one: .long -1 ---------

Re: RFC: GIMPLE tuples. Design and implementation proposal

loops, predecessors instructions of forwarded jumps, etc. instead of poor "prev"? 3. Are there fields for more debug information? Good bye J.C. Pizarro :)

Re: RFC: GIMPLE tuples. Design and implementation proposal

ppendixD.pdf and you will discover new optimized ideas. You will need a good simplifying. Good bye. J.C. Pizarro :)

Re: RFC: GIMPLE tuples. Design and implementation proposal

Is a need to build several tables in HTML of the codes (with subcodes). Each table has an explanation. It's like a roadmap.

Re: RFC: GIMPLE tuples. Design and implementation proposal

2007/4/10, Diego Novillo <[EMAIL PROTECTED]> wrote: More debug information? What debug information are you looking for? By example, worth weigths, use's frecuencies, statistical data, ... of GIMPLE. To debug the GIMPLE too. How you debug the failed GIMPLE? J.C. Pizarro

Re: RFC: GIMPLE tuples. Design and implementation proposal

2007/4/10, Diego Novillo <[EMAIL PROTECTED]>: J.C. Pizarro wrote on 04/10/07 08:17: > Is a need to build several tables in HTML of the codes (with subcodes). > Each table has an explanation. It's like a roadmap. Hmm, what? Forget it, it's not so important.

Re: RFC: GIMPLE tuples. Design and implementation proposal

2007/4/10, Diego Novillo <[EMAIL PROTECTED]> wrote: J.C. Pizarro wrote on 04/10/07 10:24: > By example, worth weigths, use's frecuencies, statistical data, ... of GIMPLE. > To debug the GIMPLE too. That's kept separately. Pointer maps, hash tables... > How you debug

A microoptimization of isnegative or greaterthan2millions.

2147483647; to Y = ((signed)X) >= 0; * Y = X < 2147483648; to Y = ((signed)X) >= 0; * * [ Another optimization is to Y = ((~X) >> 31) ] * * 2147483647=0x7FFF 2147483648=0x8000 * * The unsigned comparison is become to signed comparison. * * by J.C. Pizarr

Re: A microoptimization of isnegative or greaterthan2millions.

I'm sorry, i did want to say 2 billions, not 2 millions. J.C. Pizarro

Re: RFC: GIMPLE tuples. Design and implementation proposal

;Tuple representation" of the GIMPLE instructions will be: HEADER: code16 bits subcode 8bits markbits 8 bits nextword# removed prev word bb word locus word# removed block word BODY: OP0 word .. OPN word Thanks friendly J.C. Pizarro

Re: A microoptimization of isnegative or greaterthan2millions.

10 Apr 2007 10:53:08 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: As far as I can tell, you are recommending that gcc generate a different code sequence than it currently does. The most helpful approach you can use for such a suggestion is to open a bug report marked as an enhancement. Se

Re: RFC: GIMPLE tuples. Design and implementation proposal

2007/4/10, Andrew MacLeod <[EMAIL PROTECTED]> wrote: On Tue, 2007-04-10 at 19:54 +0200, J.C. Pizarro wrote: > Can i remove the word "prev"? > Thanks to "bb", i can traverse the short list of > the small basic block getted from its hashtable. Do you mean imp

Re: RFC: GIMPLE tuples. Design and implementation proposal

is cache is like a hashmap of { word this instruction => word prev instruction }. If this instruction isn't in the cache then go to the beginning of a BB of this instruction and start to traverse adding pointers to the cache. Use LRU/old-age-used/less-frequently-used to replace their entries. To have many smaller nodes in the heap is better. J.C. Pizarro :)

Re: RFC: GIMPLE tuples. Design and implementation proposal

Of course, i just stick with the double linked lists too. The reason is to attain minus KLOCs of implementation and more performance in the accesses because i've not problem with the 2 GiB of RAM of my old PC. Sincerely, J.C. Pizarro :)

Re: How to control the offset for stack operation?

ng is NOT 4 bytes, is 8 bytes! Sincerely J.C. Pizarro :)

Re: GCC 4.2.0 Status Report (2007-04-15)

toXXX/bin:$PATH. * to do diff bettween configure and the configure generated by autoconf/automake with configure.ac * with these diffs, to do modifications to configure.ac * to repeat it for verifying of the scripts with recent versions of autoconf/automake Sincerely J.C. Pizarro

Re: GCC 4.2.0 Status Report (2007-04-15)

k is: 1) To update the generated configure scripts of the tarball before than distributing it. 2) Or to remove the non-updated configure scripts. Sincerely J.C. Pizarro

Re: GCC 4.2.0 Status Report (2007-04-15)

2007/4/16, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 4/16/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > The "mea culpa" is to permit for long time to modify "configure" instead of > "configure.ac" or "configure.in" that is used by &quo

Re: GCC 4.2.0 Status Report (2007-04-15)

is inconvenient. What??? Don't use autotools or do use autotools? yes or no? Or yes-and-no? J.C. Pizarro

Re: How to control the offset for stack operation?

gt; > offset is 2 and so on.. I was not talking about the size of long long but the offset i.e 4x32, required for stack operation. I want gcc to generate the code such that the offset is 2 (64 bytes)and not 4 (128 bytes) Offset in bytes? Offset in 32-bit words? Please, define offset? You confuse. J.C. Pizarro

Re: GCC 4.2.0 Status Report (2007-04-15)

2007/4/16, Dave Korn <[EMAIL PROTECTED]> wrote: On 16 April 2007 10:56, J.C. Pizarro wrote: > The GCC scripts use autotools but the site don't use autotools because > it says which is inconvenient. What??? Why don't you ever go and actually *find something out* abo

Re: GCC 4.2.0 Status Report (2007-04-15)

2007/4/16, Dave Korn <[EMAIL PROTECTED]> wrote: On 16 April 2007 11:17, J.C. Pizarro wrote: > I follow, No, not very well. > The end-users who just want to compile gcc from a tarball do not > have to have autoconf installed, because we supply all the generated files &g

Recommend lecture about the meaning of PHI function from SSA.

For novice people, i recommend to read http://en.wikipedia.org/wiki/Static_single_assignment_form You see why the meaning of "y3 <- phi(y1,y2)" :)

HTML of -fdump-tree-XXXX proposal.

more effective for humans than in text. Sincerely, J.C. Pizarro :)

Re: HTML of -fdump-tree-XXXX proposal.

2007/4/18, J.C. Pizarro <[EMAIL PROTECTED]> wrote: Hello, i've an idea to improve the report of -fdump-tree- using the HTML format for its output. I recommend XHTML-1.0 (26-Jan-2000) from http://www.w3.org/TR/xhtml1/ Note: HTML-4.01 (24-Dec-1999) from http://www.w3.org/TR/html4

Re: HTML of -fdump-tree-XXXX proposal.

2007/4/19, Brooks Moses <[EMAIL PROTECTED]> wrote: I think it makes a lot more sense to implement this as a standalone filter for the output stream, which takes the files that contain the current dump-tree output and converts it to HTML. You don't lose any functionality by doing that, and there'

Re: HTML of -fdump-tree-XXXX proposal.

2007/4/22, Per Bothner <[EMAIL PROTECTED]> wrote: Without taking a position on the current proposal, using xhtml for "dump" files has some further advantages: * Can use hyperlinks, for example from a reference to the declaration, or from a variable to its type. * Can use JavaScript to hide/un

Re: 2nd quarter of 2007 and no GPL code of Java from Sun.

2007/4/3, Fernando Lozano <[EMAIL PROTECTED]> wrote: J.C. Pizarro escreveu: > We're in 2nd quarter of 2007 and no release of the complete source > code under GPL is put to the public! > > What does Sun wait to? JavaOne, for sure. So you'll have the code in May

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

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

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

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

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

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

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

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

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

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

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 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, 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: 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: 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: 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: 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: 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: 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: 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 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/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: 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 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: 2nd quarter of 2007 and no GPL code of Java from Sun.

2007/5/2, Casey Marshall <[EMAIL PROTECTED]> wrote: > From Sun, there are not notice, news, etc about the process of GPLing > the OpenJDK. JavaOne begins May 8th. Cheers. Today, there are any news from JavaOne?

Re: GIMPLE temporary variables

Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote: Hi all, I'm writing a new compilation pass in gcc, and I'm working on GIMPLE code. When gcc produce GIMPLE code, it creates new temporary variables, in order to simplify expressions and statements. For example, if source C file contains a=a+b+19;

Re: GCC 4.2.0 Status Report (2007-05-11)

On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: PR 31797: An infinite loop in the compiler while building RTEMS. 1. Can you localize its last output that stops in its internal infinite loop? 2. Or, is there an infinite outputting in the console?

GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.

Hi developers, For the current trunk of GCC, thinking about the related thing of gprof and option -pg of GCC, it's important to output correctly the data with non-fatal accuracy, preferably 4 digits decimal instead of 2, e.g 0. ms instead of 0.00 s. It's important so that the Amdahl's Law c

Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.

2007/5/15, J.C. Pizarro <[EMAIL PROTECTED]> wrote: http://en.wikipedia.org/wiki/Amdahl's_law It's a wrong link, the next is the correct http://en.wikipedia.org/wiki/Amdahl%27s_law

Re: GCC 4.2.0 Status Report (2007-05-11)

2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote: On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote: > On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> PR 31797: An infinite loop in the compiler while building RTEMS. > > 1. Can you localize its last output

Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.

2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote: On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote: > For the current trunk of GCC, thinking about > the related thing of gprof and option -pg of GCC, > > it's important to output correctly the data with non-fatal a

Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.

2007/5/16, Joe Buck <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote: > 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote: > [ explanation of why gprof is as it is ] > It's not well reasoned. If you don't like my explanation, fe

Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.

2007/5/16, J.C. Pizarro <[EMAIL PROTECTED]> wrote: For instance, this tuple stored in the memory's cell of the user process gives an idea * number of quantum's subcontext: long64 * moment of time that the subcontext started: long64 (CPU cycles, from RDTSC) * (optional) moment

I don't understand some of gcc-4.1-20070514

I suppose that there are some bugs in the snapshot gcc-4.1-20070514. gcc/rtl.h - /* Register Transfer Language EXPRESSIONS CODE CLASSES */ enum rtx_class { /* We check bit 0-1 of some rtx class codes in the predicates below. */ /* Bit 0 = comparison if 0, arithmetic is 1 #<-wro

Re: I don't understand some of gcc-4.1-20070514

2007/5/18, Eric Botcazou <[EMAIL PROTECTED]> wrote: > I suppose that there are some bugs in the snapshot gcc-4.1-20070514. Dozens, literally, just browse the bug database. If you want to help, pick one of them and try to fix it. -- Eric Botcazou How? I can not browse http://gcc.gnu.org/bugzi

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

Hi developers, for this http://gcc.gnu.org/ml/gcc/2007-05/msg00451.html 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 (..) functions. I've patched it, builded and executed, and again again wi

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

2007/5/19, Eric Botcazou <[EMAIL PROTECTED]> wrote: [Please do not cross post between lists and do not send useless attachments.] > I've patched it, builded and executed, and again again with this patched > gcc. It's OK. You apparently didn't read my previous message carefully. The patch is re

  1   2   >