Hello Joseph
On 01.04.09, you wrote:
I add this file some time ago to Amiga OS 68k target, and build compiler, in
config.log files during compiler build, it seem detect right, are there
still defines in config.gcc need and other defines ?
configure:3626: $? = 0
configure:3629: test -s conftest.o
Hello Dear GCC Developers,
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLVM solves many goals that are already complete and
And no this is not a 1st April joke :-)
Thanks,
Kirill
2009/4/1 Kirill Kononenko :
> Hello Dear GCC Developers,
>
>
>
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrate
Kirill Kononenko wrote:
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete
More useful in implementation of Just-In-Time compilation in Virtual
Machine runtimes. For example, for Microsoft Common Intermediate
Language (.NET).
Thanks,
Kirill
2009/4/1 Andrew Haley :
> Kirill Kononenko wrote:
>
>> I would like to ask your opinion about possibility for integration of
>> th
> 2009/4/1 Andrew Haley :
>> Kirill Kononenko wrote:
>>
>>> I would like to ask your opinion about possibility for integration of
>>> the libJIT Just-In-Time compilation library and GCC. For example, the
>>> same way as libffi is integrated within gcc source tree. It seems to
>>> me that LLVM solve
>> 2009/4/1 Andrew Haley :
>>> Kirill Kononenko wrote:
>>>
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLV
Kirill Kononenko wrote:
>>> 2009/4/1 Andrew Haley :
Kirill Kononenko wrote:
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree
Kirill Kononenko wrote:
>>> 2009/4/1 Andrew Haley:
Kirill Kononenko wrote:
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree.
Basile STARYNKEVITCH wrote:
> The second issue (which perhaps Kirill did not thought of) would be to
> accelerate some internal optimisations of GCC by using JIT-code
> generation techniques within the compiler itself. There are several
> occasions within GCC where complex internal processing happ
Kirill Kononenko wrote (citing me Basile)
The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code generation
techniques within the compiler itself. There are several occasions within
GCC where complex internal process
2009/4/1 Dave Korn :
> Kirill Kononenko wrote:
2009/4/1 Andrew Haley:
> Kirill Kononenko wrote:
>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is integ
>> The second issue (which perhaps Kirill did not thought of) would be to
>> accelerate some internal optimisations of GCC by using JIT-code
>> generation techniques within the compiler itself. There are several
>> occasions within GCC where complex internal processing happens, and one
>> could ima
> However, I see several interesting issues raised here:
>
> the first is to [re-]use GCC for just in time compilation, for instance to
> JIT-compile CLI or JVM bytecode into machine code, or even C or some
> specialized gimple-like representation into machine code, or CLISP into
> machine code, al
Andrew Haley wrote:
Useful for what? I think you have to tell us how this will improve the
experience of gcc users .
Kirill Kononenko wrote:
More useful in implementation of Just-In-Time compilation in Virtual
Machine runtimes. For example, for Microsoft Common Intermediate
Language
2009/4/1 Andrew Haley :
> Kirill Kononenko wrote:
2009/4/1 Andrew Haley :
> Kirill Kononenko wrote:
>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is i
2009/4/1 Basile STARYNKEVITCH :
>>>
>>> The second issue (which perhaps Kirill did not thought of) would be to
>>> accelerate some internal optimisations of GCC by using JIT-code
>>> generation
>>> techniques within the compiler itself. There are several occasions within
>>> GCC where complex inter
On Tue, 31 Mar 2009, DJ Delorie wrote:
> > I expect most of the OSes listed do; the types should still be entered
> > into GCC (so the Fortran front end can know them, for example), and
>
> Well, I'm not a big fan of duplicating information, but if that's what
> you want to do, here it is. Enj
Kirill Kononenko wrote:
> LLVM is an overkill for JIT compilation. I think the tasks which LLVM
> solves are already solved within GCC transformations, or can be
> integrated very easily with libJIT. LibJIT is also much easier in
> usage, for ordinary developers. So what I see here, LLVM is rather
On Wed, 1 Apr 2009, Bernd Roesch wrote:
> Hello Joseph
>
> On 01.04.09, you wrote:
>
> I add this file some time ago to Amiga OS 68k target, and build compiler, in
> config.log files during compiler build, it seem detect right, are there
> still defines in config.gcc need and other defines ?
Ye
Kirill and Andrew wrote:
>> "April Fool's joke"
> "not your area of expertise"
Maybe it would be for the best if you two started over, before this turns
sour.
cheers,
DaveK
Joseph S. Myers wrote:
> I'm hoping the maintainers of OS support in GCC, or other people set up to
> test on each OS, will put the types in an appropriate tm.h header and test
> that the c99-stdint-*.c tests pass. Adding the information myself without
> testing is very much a last resort.
2009/4/1 Dave Korn :
>> LLVM is an overkill for JIT compilation. I think the tasks which LLVM
>> solves are already solved within GCC transformations, or can be
>> integrated very easily with libJIT. LibJIT is also much easier in
>> usage, for ordinary developers. So what I see here, LLVM is rather
Hello!
I have encountered a problem with a private RISC target, where invalid
reload is generated when paradoxical registers are involved.
In a lreg pass, I have a sequence of instructions:
(insn 112 182 114 2 t.c:22 (set (mem/s/j/c:SI (plus:SI (reg/f:SI 35 frame)
(const_int -20
Is that an April fool's joke?
The new license allows Java, but it does not allow linking with
code that has no dependency on the Runtime Library whatsoever
(because it is not considered 'Independent Modules'), and it does not
allow linking with code that has been written in assembly language
(it i
Dave Korn wrote:
> Kirill and Andrew wrote:
>
>>> "April Fool's joke"
>> "not your area of expertise"
>
> Maybe it would be for the best if you two started over, before this turns
> sour.
I'm out of here already! All I can say is that I hope my boss never finds
out that virtual machines and
>> Kirill and Andrew wrote:
>>
"April Fool's joke"
>>> "not your area of expertise"
>>
>> Maybe it would be for the best if you two started over, before this turns
>> sour.
>
> I'm out of here already! All I can say is that I hope my boss never finds
> out that virtual machines and JITs ar
On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke wrote:
> Is that an April fool's joke?
>
> The new license allows Java, but it does not allow linking with
> code that has no dependency on the Runtime Library whatsoever
> (because it is not considered 'Independent Modules'), and it does not
How wou
I suggest you first find out more what is exactly reloaded and where
the inheritance occurs - inheritance can be done by choose_reload_regs
or later in emit_reload_insns and its subfunctions.
I.e. set a breakpoint on find_reloads and make it conditional on
insn->u.fld[0].rt_int == 121 && replace
,
On Wed, Apr 01, 2009 at 03:30:25PM +0200, Richard Guenther wrote:
> On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke wrote:
> > Is that an April fool's joke?
> >
> > The new license allows Java, but it does not allow linking with
> > code that has no dependency on the Runtime Library whatsoever
> >
Sorry to cross-post here because I have started this discussion on gcc-help
but since we are trying to interest people about seh exceptions it might be
better
to do it here.
I first asked how to take some instructions and generate a function with
them,
so I wanted to know if start_function was the
Richard Guenther wrote:
>
> What I do find strange is the restriction to explicitly Java VM bytecode
> (not CIL or others).
I think I understand that one. Way back in time, when gcj was contributed
by Cygnus, the FSF had to be convinced that Java VM bytecode couldn't be
used to allow, e.g., an u
Joern,
The FSF and SFLC believes that your concerns best can be addressed in the FAQ.
David
On Wed, Apr 1, 2009 at 9:18 AM, Joern Rennecke wrote:
> Is that an April fool's joke?
>
> The new license allows Java, but it does not allow linking with
> code that has no dependency on the Runtime Libr
"Joern Rennecke" writes:
> On Wed, Apr 01, 2009 at 03:30:25PM +0200, Richard Guenther wrote:
>> On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke wrote:
>> > Is that an April fool's joke?
>> >
>> > The new license allows Java, but it does not allow linking with
>> > code that has no dependency on t
"Vincent R." writes:
> Now the question is can we declare a function with an eh region and will it
> construct prologue and epilogue ?
The instructions are already in a function. Why do you need a separate
prologue and epilogue for them?
Maybe I am missing the point here. It seems to me that
Hi,
to keep everybody updated what is happening in the GRAPHITE branch, I
would like to post the notes of our weekly phone call.
Attendees: Razya, Li, Konrad, Jan, Tobi, David, Sebastian, Christophe
Discussed topics:
* Data dependencies: Tobias committed a patch filling the access
On Wed, Apr 1, 2009 at 8:14 AM, Kirill Kononenko
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 t
On Wed, 01 Apr 2009 07:54:20 -0700, Ian Lance Taylor
wrote:
> "Vincent R." writes:
>
>> Now the question is can we declare a function with an eh region and will
>> it
>> construct prologue and epilogue ?
>
> The instructions are already in a function. Why do you need a separate
> prologue and
>
>> 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 no
>>> 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
"Vincent R." writes:
> Yes I think I don't explain things very clearly, so what is important to
> know is that the __except keyword
> can be passed instructions(case 1) or directly a function(case 2).
I see that but I don't see why it matters.
> in the case 1) ie if you declare something like
On Apr 1, 2009, at 5:09 AM, Dave Korn wrote:
It seems to
me that LLVM solves many goals that are already complete and solved
in
GCC. So I think libJIT potentially is more useful for GCC and
software
developers.
but you don't say what libjit would be more useful than, or how this
overlap
I've merged mainline into plugins in preparation for a
plugins->mainline merge in the next few days. I will start preparing
separate patches to simplify review.
Bootstrapped and tested on x86_64.
Diego.
>>> It seems to
>>> me that LLVM solves many goals that are already complete and solved in
>>> GCC. So I think libJIT potentially is more useful for GCC and software
>>> developers.
>>
>> but you don't say what libjit would be more useful than, or how this
>> overlap
>> between "solved goals" betwe
2009/4/1 Kirill Kononenko :
>
> This is what Chris Lattner wrote a couple of years ago. Now I see an
> exactly contradiction:
>
Please, could you pinpoint side-by-side the two sentences that
contradict each other and later give links to (or quote) the context?
I am having troubling identifying the
On Wed, Apr 01, 2009 at 06:54:55PM +0200, Manuel López-Ibáñez wrote:
> 2009/4/1 Kirill Kononenko :
> >
> > This is what Chris Lattner wrote a couple of years ago. Now I see an
> > exactly contradiction:
> >
>
> Please, could you pinpoint side-by-side the two sentences that
> contradict each other
The other day there was a request for a compile error if you do:
int foo(void) { }
and the answer was "the standard says that this is legal -- after all,
you can say 'foo();' so the return value isn't used and it doesn't
matter that it's missing".
That makes sense.
So how about:
int foo
Hello All,
[I don't know if this discussion belongs to gcc@ or gcc-patches@ so I'm
sending it on gcc@ since I don't propose or discuss any code yet]
My understanding was that most plugins people are aware that somehow
some plugins would need to have static GTY-ed roots for the GGC machinery.
On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
wrote:
> Hello Dear GCC Developers,
>
>
>
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It s
2009/4/1 Daniel Berlin :
> On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
> wrote:
>> Hello Dear GCC Developers,
>>
>>
>>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is int
On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
> The other day there was a request for a compile error if you do:
>
> int foo(void) { }
>
> and the answer was "the standard says that this is legal -- after all,
> you can say 'foo();' so the return value isn't used and it doesn't
On Wed, 01 Apr 2009 08:56:49 -0700, Ian Lance Taylor
wrote:
> "Vincent R." writes:
>
>> Yes I think I don't explain things very clearly, so what is important to
>> know is that the __except keyword
>> can be passed instructions(case 1) or directly a function(case 2).
>
> I see that but I don't
"Vincent R." writes:
>> gcc will do the right thing if you put statements in an exception
>> region.
>
> Hum how gcc can do that kind of things, is it some kind of voodoo ?
> __except is not implemented yet and is more than a language construct
> because it's an
> OS thing.
> So maybe I need to
On Wed, Apr 1, 2009 at 7:22 PM, Basile STARYNKEVITCH
wrote:
>
> Hello All,
>
> [I don't know if this discussion belongs to gcc@ or gcc-patches@ so I'm
> sending it on gcc@ since I don't propose or discuss any code yet]
>
> My understanding was that most plugins people are aware that somehow some
>
On Wed, Apr 1, 2009 at 12:19, Diego Novillo wrote:
> I've merged mainline into plugins in preparation for a
> plugins->mainline merge in the next few days. I will start preparing
> separate patches to simplify review.
A clarification. I don't intend to do the actual merge into mainline
until th
Richard Guenther wrote:
Plugins shouldn't keep permanent references to GCed memory. At least
that would make it unnecessary to do what you suggest.
I strongly disagree with that, and I simply do not understand your
position. In my perception, plugins are essentially loaded (dlopen-ed)
but
Thanks to everyone who tested the prerelease snashot of MPC. The
maintainers have now released mpc-0.6 which incorporates hopefully
everyone's feedback and testing results.
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-April/000176.html
The MPC developers have made a concerted effort
Hi,
My name is Mallik and I work for Sun. I need a favor from you. I need
to cross compile our product to work on x86 Atom Processor on CentOS.
Could you please point me to the link where I can download the gcc
binaries. I downloaded the source from ix86/gcc-4_4-branch but facing
some pro
Please, let collect together all useful ideas and concrete thoughts? I
am sure many people already have thought about which JITing support
GCC users need. I also do have my thoughts about this research topic
but I would like also to have useful feedback from people who also
understand this research
On Sun, Mar 29, 2009 at 4:46 PM, Joseph S. Myers
wrote:
> On Sun, 29 Mar 2009, Steven Bosscher wrote:
>
>> On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey wrote:
>> > I think
>> > depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
>> > reasonable. Code generated and tuned for Itanium2
> "Joe" == Joe Buck writes:
Joe> On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
>> The other day there was a request for a compile error if you do:
>>
>> int foo(void) { }
>>
>> and the answer was "the standard says that this is legal -- after
>> all, you can say 'foo()
On Wed, Apr 1, 2009 at 8:42 PM, Kaveh R. Ghazi wrote:
> Thanks to everyone who tested the prerelease snashot of MPC. The
> maintainers have now released mpc-0.6 which incorporates hopefully
> everyone's feedback and testing results.
>
> http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-Apri
From: "Richard Guenther"
I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
platforms:
inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4: 2347 Aborted (core dumped) ${dir}$tst
FAIL: tio_str
Richard.
Thanks for the thorough testing!
I don't get
On Wed, Apr 1, 2009 at 10:36 PM, Kaveh R. Ghazi wrote:
> From: "Richard Guenther"
>>
>> I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
>> platforms:
>>
>> inp_str.c:131: MPC assertion failed: n == nread
>> /bin/sh: line 4: 2347 Aborted (core dumped) ${dir}$tst
>
Basile STARYNKEVITCH wrote:
Richard Guenther wrote:
Plugins shouldn't keep permanent references to GCed memory. At least
that would make it unnecessary to do what you suggest.
I strongly disagree with that, and I simply do not understand your
position. In my perception, plugins are essent
From: "Richard Guenther"
I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10 glibc.
I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's
tests on gcc14. Would it be fair to suspect something in your prerelease
glibc?
On Wed, Apr 1, 2009 at 11:03 PM, Kaveh R. Ghazi wrote:
> From: "Richard Guenther"
>
>> I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
>> mpfr 2.4.1 and some pre-2.10 glibc.
>
> I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's
> tests on gcc14.
On Wed, 2009-04-01 at 23:21 +0200, Richard Guenther wrote:
> On Wed, Apr 1, 2009 at 11:03 PM, Kaveh R. Ghazi
> wrote:
> > From: "Richard Guenther"
> >
> >> I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
> >> mpfr 2.4.1 and some pre-2.10 glibc.
> >
> > I tried with vanilla
> And if garbage collection is avoidable in GCC, given the strong opposition it
> has, all the GTY & gengtype stuff would have been removed by now. The mere
> fact it is staying here is in my opinion very significant. If GC was not
> relevant in GCC, GGC & GTY would have gone long time ago. They
On Thu, Apr 2, 2009 at 12:48 AM, Joern Rennecke wrote:
>> And if garbage collection is avoidable in GCC, given the
>> strong opposition it has, all the GTY & gengtype stuff would
>> have been removed by now.
This looks like a rather uninformed opinion...
>> The mere fact it is staying here is
>
From: "Janis Johnson"
Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr
2.3.2).
Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector.
I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2
-fstack-protector but no failures without those options. Th
On Wed, Apr 01, 2009 at 06:48:17AM -0700, Joern Rennecke wrote:
> Say you have module A, B, C and D. A is the main program and uses B, C
> and D. B uses the runtime library, and is therefore an independent module.
> Thus, you are allowed to link B with the runtime library. An argument
> could be
On Wed, 1 Apr 2009, Kaveh R. Ghazi wrote:
Ah, that helps. I was able to reproduce the failure using just
-D_FORTIFY_SOURCE=2. However when I used both -D_FORTIFY_SOURCE=2 *and*
-fstack-protector the error went away again.
I'm using gcc-4.1.2 if that matters, perhaps there's a bug in
-fstac
Hello All
Joern Rennecke wrote:
As long as you only need to GTY known types, you can avoid having extra GTY
roots by having all plugins share one GTY root in the plugin infrastructure;
this root can point to a list to which each plugin can add at will.
If you want new types, it gets ugly, be
Dave Korn wrote:
> Joseph S. Myers wrote:
>
>> I'm hoping the maintainers of OS support in GCC, or other people set up
>> to test on each OS, will put the types in an appropriate tm.h header and
>> test that the c99-stdint-*.c tests pass. Adding the information myself
>> without testing is very m
75 matches
Mail list logo
