Re: GCC + libJIT instead of LLVM
Hello Everyone I wanted to let you know that if there is someone interested in working on the libJIT approach instead of using LLVM overkill under a Google Summer of Code code project and more general on this topic or as a diploma I am ready to mentor and help with this. Thanks, Kirill 2009/4/6 Mark Mitchell : > David Edelsohn wrote: > >>> My explanations seem to have also failed to explain you. >>> Unfortunately, one really needs have some back group with both >>> Just-In-Time compilers,Virtual Machines, and Common Intermediate >>> Language to understand this area. I understand that it is not your >>> area of expertise, so it is not an issue for me. >> >> I think a JIT associated with GCC would be great. Not everything is >> static compilation. "Split Compilation" combining static compilation >> for complicated analysis along with a "Managed Runtime" for >> execution and runtime transformations is becoming more important. > > I agree. > > I don't know how relevant libJIT might or might not be for this, but the > basic idea of GCC generating deployable code which can be further > optimized at run-time (presumably using some kind of JIT) is certainly a > good one. I believe that's a usage model that will become increasingly > important over time. > > -- > Mark Mitchell > CodeSourcery > m...@codesourcery.com > (650) 331-3385 x713 > -- http://code.google.com/p/libjit-linear-scan-register-allocator/
Re: Snapshots of PPL 0.10.2 available for testing
On Thu, Apr 16, 2009 at 02:08:32PM +0200, Roberto Bagnara wrote: > > All the problems of PPL 0.10.1 we are aware of have been > fixed in the snapshot of PPL 0.10.2 available at > > ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ > > In particular here is what has changed: > > - Correctly detect GMP 4.3.0. > > - Fixed the C interface library version information. > > - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x > platform. > > - Makefiles fixed so as to avoid failure of `make -n check'. > > If no further issues are reported, that snapshot will be > relabeled PPL 0.10.2 and released on Saturday, April 18, 2009. > Thanks to all who provided feedback. > All the best, > > Roberto > > -- > Prof. Roberto Bagnara > Computer Science Group > Department of Mathematics, University of Parma, Italy > http://www.cs.unipr.it/~bagnara/ > mailto:bagn...@cs.unipr.it > The 0.10.2pre1 snapshot builds fine and passes the testsuite on x86_64-apple-darwin10. FYI. Jack
Re: Snapshots of PPL 0.10.2 available for testing
On Thu, 16 Apr 2009 14:08:32 +0200 Roberto Bagnara wrote: > > All the problems of PPL 0.10.1 we are aware of have been > fixed in the snapshot of PPL 0.10.2 available at > > ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ > > In particular here is what has changed: > > - Correctly detect GMP 4.3.0. > > - Fixed the C interface library version information. > > - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x >platform. > > - Makefiles fixed so as to avoid failure of `make -n check'. > > If no further issues are reported, that snapshot will be > relabeled PPL 0.10.2 and released on Saturday, April 18, 2009. > Thanks to all who provided feedback. > All the best, Everything is working here as well. Thanks for your quick response. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: Diagnostic Messaging Suggestion
On Apr 16, 2009, at 8:44 PM, Joe Buck wrote: On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote: The rock has dropped. The answer is quoted below: "My best guess is that a header file is included twice, and lacks guards, hence the message is correct: the function is being defined twice, from the same source location." Yes, I've had to diagnose this one before; it doesn't happen with my own code because I use include guards, but I've had to help others. It would be cool if there were a way of distinguishing the case where the same header is being processed twice. We might see foo.h:11 error: redefinition of `a' foo.h:11 error: `a' previously defined here but the first "foo.h:11" might represent the 2300'th line read by the compiler, while the second "foo.h:11" might represent the 2194'th line. If, for definitions, the compiler keeps track of this detail, it would be possible to reliably print foo.h:11 error: redefinition of `a' (file was included more than once) Clang just prints the include stack information when anything in the include stack differs between two consecutive diagnostics. $ cat t.h int x = 4; $ cat t.c #include "t.h" #include "t.h" $ clang t.c In file included from t.c:3: ./t.h:1:5: error: redefinition of 'x' int x = 4; ^ In file included from t.c:2: ./t.h:1:5: note: previous definition is here int x = 4; ^ This clearly says that the first definition was coming from t.c:2 and the second from t.c:3. Of course, if you get multiple diagnostics from the same header, you only show the include stack for the first. -Chris
Re: GCC 4.3.2 bug (was: Illegal subtraction in tmp-dive_1.s)
At least, let's get it archived on GCC mailing lists.
On Fri, Apr 17, 2009 at 11:25 AM, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> FYI, here's a simple testcase:
>
> /* With GCC 4.3.2 and -O2 option: output value is 1 instead of 0.
> * If -fno-strict-aliasing is added, this bug disappears.
> */
>
> #include
> #include
>
> int test (int n)
> {
>unsigned long *p, *q;
>int i;
>
>q = p = malloc (n * sizeof (unsigned long));
>if (p == NULL)
> return 2;
>for (i = 0; i < n - 1; i++)
> p[i] = 0;
>p[n - 1] = 1;
>while ((*(q++))-- == 0) ;
>return p[n - 1] == 1;
> }
>
> int main (void)
> {
>int r;
>
>r = test (17);
>printf ("%d\n", r);
>return r;
> }
>
> You may want to use it in configure to detect the bug there (as not
> all users run "make check"). Possibly add -fno-strict-aliasing if
> the bug is detected.
>
> Nice. I think that test should go onto the GCC testsuite.
>
> I suppose a problem is that the code wrt GMP need to be *executed*;
> configure feature tests should work also when cross-compiling, I think.
>
> --
> Torbjörn
> ___
> gmp-discuss mailing list
> gmp-disc...@gmplib.org
> http://gmplib.org/mailman/listinfo/gmp-discuss
>
Re: Diagnostic Messaging Suggestion
> "Joe" == Joe Buck writes: Joe> If, for definitions, the compiler keeps track of this detail, it Joe> would be possible to reliably print Joe> foo.h:11 error: redefinition of `a' (file was included more than once) Joe> if the printable line number is the same but the internal line number Joe> is different. You could certainly implement that in today's GCC. The "internal line number" comparison can be done by directly comparing source_locations. Then "printable line number" comparison can be done by expanding the locations and comparing the contents. Chris> Clang just prints the include stack information when anything Chris> in the include stack differs between two consecutive Chris> diagnostics. We could easily do that too. Tom
Re: Diagnostic Messaging Suggestion
On Fri, Apr 17, 2009 at 11:58:48AM -0600, Tom Tromey wrote: > Chris> Clang just prints the include stack information when anything > Chris> in the include stack differs between two consecutive > Chris> diagnostics. > > We could easily do that too. FWIW, I think this would be quite useful. -- Daniel Jacobowitz CodeSourcery
Reserving a number of consecutive registers
Hi all, My target architecture has an load multiple instruction requiring a certain number of consecutive registers. I've been working on handling this case and trying to convince the local register allocator that he really does want to try to get those consecutive registers for the loads. But have been running into certain difficulties. For example: a = tab[0]; b = tab[1]; c = tab[2]; d = tab[3]; e = tab[4]; sum = a + b + c + d + e; I would like to get : load_multiple tab, r10-r14 and then have r10 linked to a, r11 to b, etc. Basically, I've worked in the direction of detecting a number of loads in the block from the same base register or symbol reference. I've got that detection running and I know in what order I want to associate the pseudo registers to the hard registers but I can't seem to request hard registers at that point. I thought I could be playing with the arrays qty_phys_sugg and qty_phys_copy_sugg but I have trouble wrapping my mind around what they really represent and how to do that. Do you have any ideas about how I can achieve this, am I going in the wrong direction? Thanks a lot, Jc
GCC + libJIT + Domain Specific Languages Concept Integration
One of the many options is in using the Common Intermediate Language and .NET to store portable programs. Does this sound like a good idea to you? .NET has been design to be as much portable as possible. You should understand that it is not the best way of handling of other people work with a way that in the very first email other people work is treated as to be not worthy. As you did with libJIT and my work. The only real truism in software is that any software is crape in someones eyes. I really want to help GCC, but if people want to continue to break head into the whale, there is not much I can help. Thanks, Kirill 2009/4/17 Kirill Kononenko : > Hello Everyone > > > I wanted to let you know that if there is someone interested in > working on the libJIT approach instead of using LLVM overkill under a > Google Summer of Code code project and more general on this topic or > as a diploma I am ready to mentor and help with this. > > > Thanks, > Kirill > > 2009/4/6 Mark Mitchell : >> David Edelsohn wrote: >> My explanations seem to have also failed to explain you. Unfortunately, one really needs have some back group with both Just-In-Time compilers,Virtual Machines, and Common Intermediate Language to understand this area. I understand that it is not your area of expertise, so it is not an issue for me. >>> >>> I think a JIT associated with GCC would be great. Not everything is >>> static compilation. "Split Compilation" combining static compilation >>> for complicated analysis along with a "Managed Runtime" for >>> execution and runtime transformations is becoming more important. >> >> I agree. >> >> I don't know how relevant libJIT might or might not be for this, but the >> basic idea of GCC generating deployable code which can be further >> optimized at run-time (presumably using some kind of JIT) is certainly a >> good one. I believe that's a usage model that will become increasingly >> important over time. >> >> -- >> Mark Mitchell >> CodeSourcery >> m...@codesourcery.com >> (650) 331-3385 x713 >> > > > > -- > http://code.google.com/p/libjit-linear-scan-register-allocator/ > -- http://code.google.com/p/libjit-linear-scan-register-allocator/
Re: GCC + libJIT + Domain Specific Languages Concept Integration
On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote: > One of the many options is in using the Common Intermediate Language > and .NET to store portable programs. Does this sound like a good idea > to you? To the extent that the effect is to create a portable binary format, I expect that the FSF would say "no, this is not a good idea at all!". This is because they seem to promote the sharing and modification of source code, not bytecodes for .Net or JVM. Others might disagree. You might have better luck working with the Mono developers if you're a .NET champion. > You should understand that it is not the best way of handling of other > people work with a way that in the very first email other people work > is treated as to be not worthy. As you did with libJIT and my work. You have responded to all criticism by taking it personally and replying with a hostile attitude. That's tended to produce hostility in response. There really aren't many successful free software projects where the response to a newcomer proposing a different approach is to say, "Yes, thank you! We will implement your ideas and commit your patches instantly! It's beautiful just the way you presented it! Just make more vague suggestions and we'll code it right up for you!" Rather, the burden is on you as the proposer to convince skeptics, and, for difficult changes, contribute actual patches, but be willing to change those patches based on critiques from reviewers. Skepticism is key to quality control.
Re: GCC + libJIT + Domain Specific Languages Concept Integration
Joe Buck wrote: > On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote: >> One of the many options is in using the Common Intermediate Language >> and .NET to store portable programs. Does this sound like a good idea >> to you? > > To the extent that the effect is to create a portable binary format, > I expect that the FSF would say "no, this is not a good idea at all!". > This is because they seem to promote the sharing and modification of > source code, not bytecodes for .Net or JVM. On the other hand, the FSF seems to understand that even free software developers do want to share binaries, including things like shared libraries that are intermediate steps between source code and a final program. I believe that things like CIL, JVM bytecodes, and such are here to stay, and I believe that GCC will need to do more with them, not less, in order to stay relevant. Since I think these things are important to GCC over the medium term, I will continue to encourage the FSF to accept them. I think we should be encouraging people interested in these kinds of features to be working with the GCC development community to implement them, and encouraging the FSF to accept them, rather than to push such people away. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GCC + libJIT + Domain Specific Languages Concept Integration
On Fri, Apr 17, 2009 at 01:14:40PM -0700, Mark Mitchell wrote: > Joe Buck wrote: > > On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote: > >> One of the many options is in using the Common Intermediate Language > >> and .NET to store portable programs. Does this sound like a good idea > >> to you? > > > > To the extent that the effect is to create a portable binary format, > > I expect that the FSF would say "no, this is not a good idea at all!". > > This is because they seem to promote the sharing and modification of > > source code, not bytecodes for .Net or JVM. > > On the other hand, the FSF seems to understand that even free software > developers do want to share binaries, including things like shared > libraries that are intermediate steps between source code and a final > program. Of course. I didn't mean to suggest not supporting CIL/.NET, or JVM, they certainly have their uses. But if the reason to advocate them is to "store portable programs", people can legitimately take issue with that.
'Obsolete' architectures in GCC 4.4
Hi Guys, I see the following in the changes for GCC 4.4: Support for a number of older systems and recently unmaintained or untested target ports of GCC has been declared obsolete in GCC 4.4. Unless there is activity to revive them, the next release of GCC will have their sources permanently removed. The following ports for individual systems on particular architectures have been obsoleted: * Generic a.out on IA32 and m68k (i[34567]86-*-aout*, m68k-*-aout*) For the record, the Generic a.out support for IA32 is used by my GCC 4.3.3 and upcoming GCC 4.4.x ports for OS/2. I don't yet have the patches in any form ready enough to be submitted for inclusion, but they are available from http://www.smedley.info/os2ports/index.php?page=gcc I'd be really grately if the IA32 a.out support could be left in place as it does work for OS/2 at least :) -- Cheers, Paul.
Re: 'Obsolete' architectures in GCC 4.4
On Fri, 17 Apr 2009, Paul Smedley wrote: > * Generic a.out on IA32 and m68k (i[34567]86-*-aout*, > m68k-*-aout*) > > For the record, the Generic a.out support for IA32 is used by my GCC > 4.3.3 and upcoming GCC 4.4.x ports for OS/2. I don't yet have the > patches in any form ready enough to be submitted for inclusion, but > they are available from > http://www.smedley.info/os2ports/index.php?page=gcc > > I'd be really grately if the IA32 a.out support could be left in place > as it does work for OS/2 at least :) Generic a.out is for bare-metal embedded boards without an operating system or with an RTOS with no specific GCC port and is obsoleted by generic ELF. An OS/2 port would have its own target, i?86-*-os2 or similar, and so would be unaffected by this deprecation. -- Joseph S. Myers jos...@codesourcery.com
