RE: HTML of -fdump-tree-XXXX proposal.
On 18 April 2007 06:04, David Daney wrote: > Diego Novillo wrote: >> J.C. Pizarro wrote on 04/17/07 21:48: >> >> >>> The visual representation in HTML is more effective for humans than in >>> text. >>> >> >> No. Heck, no. >> > I agree. PDF is clearly superior ;-) > > J.C., Please submit a patch for PDF support. > > David Daney I think we should output the tree dumps in a combination of active JAXML that lets you edit fonts and typestyles in real time, with embedded VRML so that you can fly round a three-dimensional forest full of SSA trees rendered in real time. It would be nice if you could customize the bark texture used to render the trees, too. JC, if you really really *really* want html output, write a post-processor. cheers, DaveK -- Can't think of a witty .sigline today
What are the chances of GCC for PRIMOS?
Hello guys, Recently, on comp.sys.prime a PRIMOS emulator was announced. It is for quite an old version of Primos (rev 19.2) before Prime puts its weight behind an official C compiler. We on this ng are trying to track down an unofficial C compiler that was around at that time. But someone suggested that maybe GCC might, at some point, be able to emit code for PRIMOS. This would be PMA (Prime Macro Assembler). I really hope that this could be done. I wonder what the chances are. I know that Primes are ancient and that Prime has been dead for many years, but this emulator seems to have given PRIMOS a new lease of life. People have already started to upload source to the emulator to get their favourite programs up and running on what used to be a very popular system. For example, I want to compile uEmacs which is written in K&R C. Even if this work cannot be done for GCC it would be good to at least get an official statement to that effect (would put us Primates out of our misery..). Regards, Andrew Marlow There is an emerald here the size of a plover's egg! Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html **" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. ***" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " ***
RE: What are the chances of GCC for PRIMOS?
On 18 April 2007 10:29, Andrew Marlow wrote: > Recently, on comp.sys.prime a PRIMOS emulator was announced. It is for > quite an old version of Primos (rev 19.2) before Prime puts its weight > behind an official C compiler. We on this ng are trying to track down an > unofficial C compiler that was around at that time. But someone > suggested that maybe GCC might, at some point, be able to emit code for > PRIMOS. This would be PMA (Prime Macro Assembler). I really hope that > this could be done. I wonder what the chances are. Depends how you count it. Gcc can be ported to generate pretty much any assembler code, so the chance could be said to be 100%. Then again, it's probably a few months of more-or-less fulltime work. So the chances of it just happening without someone actually getting up and doing it is 0%. If some of the newsgroup guys want to volunteer to do it, everyone here will offer help and advice. If you want to hire a contractor to do it, that would work too. But the odds of some random gcc hacker with no special interest in PRIMOS suddenly deciding to volunteer that amount of time and effort for no reason are ... small. > Even if this work cannot be done for GCC it would be good to at least > get an official statement to that effect (would put us Primates out of > our misery..). http://cygwin.com/acronyms#SHTDI http://cygwin.com/acronyms#PTC > There is an emerald here the size of a plover's egg! plugh! cheers, DaveK -- Can't think of a witty .sigline today
What are the chances of GCC for PRIMOS?
Dave Korn wrote: > On 18 April 2007 10:29, Andrew Marlow wrote: > >> Recently, on comp.sys.prime a PRIMOS emulator was announced. It is >> for quite an old version of Primos (rev 19.2) before Prime puts its >> weight behind an official C compiler. We on this ng are trying to >> track down an unofficial C compiler that was around at that time. >> But someone suggested that maybe GCC might, at some point, be able to >> emit code for PRIMOS. This would be PMA (Prime Macro Assembler). >> I really hope that this could be done. I wonder what the chances are. > > If some of the newsgroup guys want to volunteer to do it, everyone > here will offer help and advice. This is good to know, thanks :-) > If you want to > hire a contractor to do it, that would work too. That is not going to happen. > But the > odds of some random gcc hacker with no special interest in PRIMOS > suddenly deciding to volunteer that amount of time and effort for no > reason are ... small. Er, yes. I don't have the skills myself. I was hoping that maybe some ex-primates hung around in the GCC ml. Perhaps this was wildly optimistic. > >> Even if this work cannot be done for GCC it would be good to at least >> get an official statement to that effect (would put us Primates out >> of our misery..). > > http://cygwin.com/acronyms#SHTDI > http://cygwin.com/acronyms#PTC There may be some chance of this. In comp.sys.prime it was just announced that the source for a very early unofficial version of the C compiler has been found. I wonder if this might be a useful starting point. Does this ml have a pointer (URL maybe) for any GCC implementing a new backend documentation that I can point my fellow primates to? Maybe one of them could use this info in conjunction with the source that was just discovered. > >> There is an emerald here the size of a plover's egg! > plugh! Nothing happens. > > cheers, > DaveK Regards, Andrew Marlow There is an emerald here the size of a plover's egg! Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html **" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. ***" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " ***
RE: What are the chances of GCC for PRIMOS?
On 18 April 2007 11:00, Andrew Marlow wrote: [ list Cc'd back in as I see you sent this reply there as well as off-list ] >> But the >> odds of some random gcc hacker with no special interest in >> PRIMOS suddenly deciding to volunteer that amount of time and >> effort for no reason are ... small. > > Er, yes. I don't have the skills myself. I was hoping that maybe some > ex-primates hung around in the GCC ml. Perhaps this was wildly optimistic. Not /wildly/ optimistic, but optimistic yes. There are quite a lot of pretty old-school big iron guys among the older crew, as it happens. Even so, they'd have to be pretty keen to want to do this work... > There may be some chance of this. In comp.sys.prime it was just announced > that the source for a very early unofficial version of the C compiler has > been found. I wonder if this might be a useful starting point. Does this ml > have a pointer (URL maybe) for any GCC implementing a new backend > documentation that I can point my fellow primates to? Maybe one of them > could use this info in conjunction with the source that was just > discovered. The main documentation is the gcc internals manual: http://gcc.gnu.org/onlinedocs/gccint/, other formats available at http://gcc.gnu.org/onlinedocs/. After that, the next step is to look at the other backend ports, pick one that's architecturally close to your target, and study how it makes things work. See also http://gcc.gnu.org/readings.html, particularly HP's "Porting gcc for dunces". There's no chance the code of the old compiler will be /directly/ useful in a gcc context, but much of the information it tells you will surely be vital. >>> There is an emerald here the size of a plover's egg! >> plugh! > > Nothing happens. A hollow voice says "Well, I wasn't really expecting it to work here anyway." cheers, DaveK -- Can't think of a witty .sigline today
Re: [cygwin] Can't boostrap current gcc trunk with libjava: ../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: error: "_EXFUN" redefined
16 Apr 2007 16:50:03 -0600, Tom Tromey <[EMAIL PROTECTED]>: > "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> The definition of _EXFUN in mprec.h is unconditionally: Dave> #define _EXFUN(name, proto) name proto libjava, and subsequently Classpath, imported an old version of this code, which was then hacked over randomly. Dave> How about we whip up a patch to just turn all the _EXFUN Dave> definitions into real honest-to-goodness ansi prototypes? Is it Dave> actually serving any real purpose? I think just the hypothetical scenario of making it simpler to import a newer version of fdlibm and/or mprec. I think we may have imported a new mprec at one point, but I don't recall us ever importing a newer fdlibm. Tom ehrm, well... I have to ask. Have you convereged at something yet? -- Cheers, /ChJ
RE: [cygwin] Can't boostrap current gcc trunk with libjava: ../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: error: "_EXFUN" redefined
On 18 April 2007 11:41, Christian Joensson wrote: > 16 Apr 2007 16:50:03 -0600, Tom Tromey <[EMAIL PROTECTED]>: >>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: >> >> Dave> The definition of _EXFUN in mprec.h is unconditionally: >> Dave> #define _EXFUN(name, proto) name proto >> >> libjava, and subsequently Classpath, imported an old version of this >> code, which was then hacked over randomly. >> >> Dave> How about we whip up a patch to just turn all the _EXFUN >> Dave> definitions into real honest-to-goodness ansi prototypes? Is it >> Dave> actually serving any real purpose? >> >> I think just the hypothetical scenario of making it simpler to import >> a newer version of fdlibm and/or mprec. I think we may have imported >> a new mprec at one point, but I don't recall us ever importing a newer >> fdlibm. >> >> Tom >> > > ehrm, well... I have to ask. Have you convereged at something yet? Well, Tom is the java/libgcj maintainer. Tom, are you interested in fixing this in the immediate timescale by doing an import, or shall I whip up a patch as proposed above just to get bootstrap fixed until you're ready to do the import in some more long-term timescale? cheers, DaveK -- Can't think of a witty .sigline today
RE: Bootstrap is broken on i[345]86-linux
On 18 April 2007 09:00, François-Xavier Coudert wrote: > [ http://gcc.gnu.org/ml/gcc/2007-04/msg00145.html ] >> I'm starting to look into it now. > > ping? FWIW, bootstrap looks still broken... > > Could you propose a patch, disable decimal float for i[345]86-linux, > revert your original patch or review the patch at > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01764.html ? I think > we're not missing ways of action here :) > > Failing that, can a i386 maintainer do something (a non-exhaustive > list of possible actions can be found in the above paragraph)? The formal procedure would be at this point to request any global maintainer to start the 48hr reversion countdown. [ Note that /this/ email is not such a request on my part, because I haven't yet been bitten by this bug. ] cheers, DaveK -- Can't think of a witty .sigline today
Re: HTML of -fdump-tree-XXXX proposal.
Dave Korn wrote: I think we should output the tree dumps in a combination of active JAXML that lets you edit fonts and typestyles in real time, with embedded VRML so that you can fly round a three-dimensional forest full of SSA trees rendered in real time. It would be nice if you could customize the bark texture used to render the trees, too. Or perhaps we should just use Microsoft word format--so convenient for all gcc participants, and I am sure Microsoft will be happy to license any patents that are involved to us :-)
RE: HTML of -fdump-tree-XXXX proposal.
On 18 April 2007 12:35, Robert Dewar wrote: > Dave Korn wrote: > >> I think we should output the tree dumps in a combination of active JAXML >> that lets you edit fonts and typestyles in real time, with embedded VRML so >> that you can fly round a three-dimensional forest full of SSA trees >> rendered in real time. >> >> It would be nice if you could customize the bark texture used to render >> the trees, too. > > Or perhaps we should just use Microsoft word format--so convenient for > all gcc participants, and I am sure Microsoft will be happy to license > any patents that are involved to us :-) Well, it's always good to comply with ISO standards[*], isn't it? ;-) cheers, DaveK [*] - No. Not any more. -- Can't think of a witty .sigline today
Re: Segfault on OpenMP program
On Wednesday 18 April 2007 00:19, FX Coudert wrote: > Someone reported on bug on a trivial statically-linked Fortran progam > with OpenMP and a I/O operation. I can reproduce the segfault, which > happens at: >... > Andrew suggested on bugzilla that this might be a GLIBC issue (I use > glibc-2.4 from redhat), with "pthreads not linking in correctly". > Does this ring a bell? Can someone confirm that it's not a GCC issue > (or that it is)? Details can be found in PR 31604. The answer to any question involving glibc and static linking is generally "don't do that". I've seen pthread related problems with static linking, though that was related to nss dlopening a shared library from a static application. Paul
Re: Segfault on OpenMP program
On Wed, Apr 18, 2007 at 02:38:24PM +0100, Paul Brook wrote: > On Wednesday 18 April 2007 00:19, FX Coudert wrote: > > Someone reported on bug on a trivial statically-linked Fortran progam > > with OpenMP and a I/O operation. I can reproduce the segfault, which > > happens at: > >... > > Andrew suggested on bugzilla that this might be a GLIBC issue (I use > > glibc-2.4 from redhat), with "pthreads not linking in correctly". > > Does this ring a bell? Can someone confirm that it's not a GCC issue > > (or that it is)? Details can be found in PR 31604. > > The answer to any question involving glibc and static linking is > generally "don't do that". Yeah, especially anything involving libpthread. As a workaround you can link whole libpthread.a in (... -static ... -Wl,--whole-archive -lpthread \ -Wl,--no-whole-archive) but even that it really is not supported, if it works for you, fine, though even then you should study all the reasons why we don't recommend static linking, if it doesn't, just link dynamically. Jakub
[DataFlow Branch] Query regarding an ICE in global.c
Hi ,
I am working on integrating a private port into the Dataflow branch and
am running into a couple of issues with ICEs in global.c . The ICE is
at gcc_assert ( REGS_LIVE (i)) at line 534 in global_alloc in
global.c ..
However because of the way we generate calls in the backend with an
extra clobber register for calculating the return address. The temporary
which gets clobbered is here.
(call_insn:HI 32 29 34
4 ../../../../gnu/libgcc/../gcc/unwind-dw2-fde.c:487 (parallel [
(set (reg:SI 1 $r1)
(call (mem:SI (reg/v/f:SI 145 [ fde_compare ]) [0 S4
A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 31 $link))
(clobber (reg:SI 153))
]) 40 {call_value_indirect} (expr_list:REG_DEAD (reg:SI 3 $c3)
(expr_list:REG_DEAD (reg:SI 2 $r2)
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 $r3))
(expr_list:REG_DEP_TRUE (use (reg:SI 2 $r2))
(expr_list:REG_DEP_TRUE (use (reg:SI 1 $r1 [ ob ]))
(nil)
Is it something to do with the way that REGS_EVER_LIVE is calculated ?
If so where does this get updated in the new infrastructure. I am still
feeling my way through the df code , so any help would be appreciated.
Thanks in advance.
This is with revision 123253 of the DF branch which is slightly older .
I am considering moving up but wanted to check before that .
cheers
Ramana
--
Ramana Radhakrishnan <[EMAIL PROTECTED]>
Codito Technologies Pvt. Ltd.
Re: [DataFlow Branch] Query regarding an ICE in global.c
On Wed, 2007-04-18 at 19:54 +0530, Ramana Radhakrishnan wrote: > Hi , > > I am working on integrating a private port into the Dataflow branch and > am running into a couple of issues with ICEs in global.c . The ICE is > at gcc_assert ( REGS_LIVE (i)) at line 534 in global_alloc in > global.c .. Sorry that should read REG_LIVE_LENGTH(i) and not as mentioned. -Ramana > -- Ramana Radhakrishnan <[EMAIL PROTECTED]>
Re: [DataFlow Branch] Query regarding an ICE in global.c
Ramana Radhakrishnan wrote:
> Hi ,
>
> I am working on integrating a private port into the Dataflow branch and
> am running into a couple of issues with ICEs in global.c . The ICE is
> at gcc_assert ( REGS_LIVE (i)) at line 534 in global_alloc in
> global.c ..
>
> However because of the way we generate calls in the backend with an
> extra clobber register for calculating the return address. The temporary
> which gets clobbered is here.
>
> (call_insn:HI 32 29 34
> 4 ../../../../gnu/libgcc/../gcc/unwind-dw2-fde.c:487 (parallel [
> (set (reg:SI 1 $r1)
> (call (mem:SI (reg/v/f:SI 145 [ fde_compare ]) [0 S4
> A32])
> (const_int 0 [0x0])))
> (use (const_int 0 [0x0]))
> (clobber (reg:SI 31 $link))
> (clobber (reg:SI 153))
> ]) 40 {call_value_indirect} (expr_list:REG_DEAD (reg:SI 3 $c3)
> (expr_list:REG_DEAD (reg:SI 2 $r2)
> (nil)))
> (expr_list:REG_DEP_TRUE (use (reg:SI 3 $r3))
> (expr_list:REG_DEP_TRUE (use (reg:SI 2 $r2))
> (expr_list:REG_DEP_TRUE (use (reg:SI 1 $r1 [ ob ]))
> (nil)
>
>
>
>
> Is it something to do with the way that REGS_EVER_LIVE is calculated ?
> If so where does this get updated in the new infrastructure. I am still
> feeling my way through the df code , so any help would be appreciated.
> Thanks in advance.
>
> This is with revision 123253 of the DF branch which is slightly older .
> I am considering moving up but wanted to check before that .
>
>
> cheers
> Ramana
>
>
>
>
There may have been a few fixes that might help so you should try
updating first.
There is a fix was that causes the REG_N... information to be rebuilt at
the start of global rather than reusing the info computed during local.
If you are adding this pseudo very late, this will likely fix the problem.
Fixing your kind of bug was not the reason for this fix. The fix
solves an issue where the regs live across a call computed during local
is different than the way it is computed during global.
This kind of information is built by the RI problem when df_analyze is
called and that problem is not resolved when df_analyze is called inside
global.
Hope this fixes you issue.
Kenny
>
>
>
>
>
>
>
>
Re: [DataFlow Branch] Query regarding an ICE in global.c
On Wed, 2007-04-18 at 10:35 -0400, Kenneth Zadeck wrote:
> Ramana Radhakrishnan wrote:
> > Hi ,
> >
> > I am working on integrating a private port into the Dataflow branch and
> > am running into a couple of issues with ICEs in global.c . The ICE is
> > at gcc_assert ( REGS_LIVE (i)) at line 534 in global_alloc in
> > global.c ..
> >
> > However because of the way we generate calls in the backend with an
> > extra clobber register for calculating the return address. The temporary
> > which gets clobbered is here.
> >
> > (call_insn:HI 32 29 34
> > 4 ../../../../gnu/libgcc/../gcc/unwind-dw2-fde.c:487 (parallel [
> > (set (reg:SI 1 $r1)
> > (call (mem:SI (reg/v/f:SI 145 [ fde_compare ]) [0 S4
> > A32])
> > (const_int 0 [0x0])))
> > (use (const_int 0 [0x0]))
> > (clobber (reg:SI 31 $link))
> > (clobber (reg:SI 153))
> > ]) 40 {call_value_indirect} (expr_list:REG_DEAD (reg:SI 3 $c3)
> > (expr_list:REG_DEAD (reg:SI 2 $r2)
> > (nil)))
> > (expr_list:REG_DEP_TRUE (use (reg:SI 3 $r3))
> > (expr_list:REG_DEP_TRUE (use (reg:SI 2 $r2))
> > (expr_list:REG_DEP_TRUE (use (reg:SI 1 $r1 [ ob ]))
> > (nil)
> >
> >
> >
> >
> > Is it something to do with the way that REGS_EVER_LIVE is calculated ?
> > If so where does this get updated in the new infrastructure. I am still
> > feeling my way through the df code , so any help would be appreciated.
> > Thanks in advance.
> >
> > This is with revision 123253 of the DF branch which is slightly older .
> > I am considering moving up but wanted to check before that .
> >
> >
> > cheers
> > Ramana
> >
> >
> >
> >
> There may have been a few fixes that might help so you should try
> updating first.
I shall anyways try updating to a newer version.
> There is a fix was that causes the REG_N... information to be rebuilt at
> the start of global rather than reusing the info computed during local.
> If you are adding this pseudo very late, this will likely fix the problem.
Could you elaborate on the "very late" bit ? The pattern that we have
gets generated at RTL Expansion time , so its not being added too late
in the chain.
>
> Fixing your kind of bug was not the reason for this fix. The fix
> solves an issue where the regs live across a call computed during local
> is different than the way it is computed during global.
Ok -
>
> This kind of information is built by the RI problem when df_analyze is
> called and that problem is not resolved when df_analyze is called inside
> global.
>
> Hope this fixes you issue.
I'll try updating and post again. Thank you for the prompt response.
cheers
-Ramana
>
> Kenny
> >
> >
> >
> >
> >
> >
> >
> >
>
--
Ramana Radhakrishnan <[EMAIL PROTECTED]>
Codito Technologies Pvt. Ltd.
Re: Segfault on OpenMP program
On 18 Apr 2007, at 15:38, Paul Brook wrote: On Wednesday 18 April 2007 00:19, FX Coudert wrote: Someone reported on bug on a trivial statically-linked Fortran progam with OpenMP and a I/O operation. I can reproduce the segfault, which happens at: ... Andrew suggested on bugzilla that this might be a GLIBC issue (I use glibc-2.4 from redhat), with "pthreads not linking in correctly". Does this ring a bell? Can someone confirm that it's not a GCC issue (or that it is)? Details can be found in PR 31604. The answer to any question involving glibc and static linking is generally "don't do that". I've seen pthread related problems with static linking, though that was related to nss dlopening a shared library from a static application. Is this only advised with parallel programs, or is it a general rule? In my research, I statically link all my benchmarks because that I measure stuff about them using instrumentation on a bunch of computer (which might have various OSs, OS versions, libc versions, ...). Because we want to analyze the same dynamic executed code over and over again (no matter on which machine the analysis is donne), I use static linking. I've heard to warnings about static linking before from other people too: using a libc version which is not intented for the system you are running on might lead to weird behavior. Concerning this, I have some questions: - What are the possible issues with static linking? Are they listed above (pthread problems, libc vs kernel conflicts), or are there more? - How can I easily dynamically link against libc, but statically link with everything else? Currently, making everything statically linked is easy: in the various makefiles I set CC="gcc -static". Is there a similar 'trick' to link libc dynamically but everything else statically? (I'm using GCC 4.1.2 if it matters) greetings, Kenneth -- Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital (Aaron Levenstein) Kenneth Hoste ELIS - Ghent University [EMAIL PROTECTED] http://www.elis.ugent.be/~kehoste
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/html401/ is very popular but very old and it's not XML-1.0 (16-Aug-2006) format from http://www.w3.org/TR/xml/ implying that HTML-4.01 is hardful for some parsers. The proposal is instead of gcc $CFLAGS -fdump-tree-ssa file.c gcc $CFLAGS -fdump-tree-gimple file.c to use the -html option for -fdump-tree- like so gcc $CFLAGS -html -fdump-tree-ssa file.c gcc $CFLAGS -html -fdump-tree-gimple file.c and they will generate the files file.c.tXX.ssa.html and file.c.tXX.gimple.html instead of file.c.tXX.ssa and file.c.tXX.gimple Why? There are a good reason for ".ssa" principally. 1. To use "charset=utf-8" or &#number; from HTML for greek symbols. 2. Is better to use subscripted numbers than numbers. 3. There is a greek symbol for PHI-function ( e.g. # X_1 = PHI ; ) 4. Underlining or middlelining the instructions, operands or labels marked like dead by example. 5. Etc. The visual representation in HTML is more effective for humans than in text. Sincerely, J.C. Pizarro :) I've used ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070416/gcc-core-4.1-20070416.tar.bz2 ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070416/gcc-g++-4.1-20070416.tar.bz2 In the attachment there is a quick&dirty alpha patch that i don't known why the gcc compiler says "gcc: unrecognized option '-html'". ??? I don't known where to modify the gcc code to add an option. The XHTML format to fputs is a little bad. There are examples to test too. The idea is to filter the output stream. Bye, i'm not an expert, i'm a novice, i've not much time :s i'm busy J.C. Pizarro gcc-4.1-20070416_pphtml_alpha.patch Description: Binary data factorial.c Description: Binary data run.sh Description: Bourne shell script factorial.c.t26.ssa Description: Binary data
gcc preprocessor
Hi Can some one tell me if gcc preprocessor can support in some way the following features 1. Repeating a block a certain number of times 2. Multiline macros with new lines 3. Setting a symbolic constant inside a #define thanks dz
Re: gcc preprocessor
On Wed, Apr 18, 2007 at 09:07:07PM -0400, drizzle drizzle wrote: > Can some one tell me if gcc preprocessor can support in some way > the following > features You are asking a beginner C programming question. gcc's preprocessor does what standard C preprocessors do.
Re: HTML of -fdump-tree-XXXX proposal.
On Apr 18, 2007, at 12:38 AM, Dave Korn wrote: I think we should output the tree dumps in a combination of active JAXML that lets you edit fonts and typestyles in real time, with embedded VRML so that you can fly round a three-dimensional forest full of SSA trees rendered in real time. I disagree. VRML sucks, I have patches to pump the data into a doom engine and then you can wonder around and fire your weapons at the SSA trees to explore them, works much better in my experience.
Re: HTML of -fdump-tree-XXXX proposal.
On 4/18/07, Mike Stump <[EMAIL PROTECTED]> wrote:> I disagree. VRML sucks, I have patches to pump the data into a doom engine and then you can wonder around and fire your weapons at the SSA trees to explore them, works much better in my experience. Can I suggest Collada (http://collada.org/) instead (sorry for the Sony pitch again but I feel this is getting out of hand)? -- Pinski
