Hi all,
I'm trying to inject code that uses variable addresses into the first
mudflap pass. These variables are not natively addressable in the
program itself.
The problem is that the first mudflap pass takes place at the GIMPLE
level, at which point all variables have their
addressable/non
Hear, hear!
I think using ecj as a gcj front end sounds like a terrific idea!
Kind regards,
Thomas Hallgren
Tom Tromey wrote:
Now that the GPL v3 looks as though it may be EPL-compatible, the time
has come to reconsider using the Eclipse java compiler ("ecj") as our
primary gcj front end. Thi
Tom Tromey writes:
> Historically we've wanted to have a 'native' java-source-code-reading
> compiler, that is, one which parses java sources and converts them
> directly to trees. From what I can remember this was based on 3
> things:
>
> * In the past the compiler handled loops built wit
Ok... can someone explain to me how the generic vector extension is
supposed to work? I've added a few V2HImode operations to the Blackfin
backend (in a 3.4-based compiler), and now I'm getting aborts all over
the place because the compiler is trying to make V8HImode registers for
operations o
Andrew Haley wrote:
I think that from a maintenance point of view this would be a PITA.
Also, as Per mentioned we'd need to extend the .class file format in a
non-standard way to get full debugging information. In particular,
.class files don't contain the full pathnames to source files.
The "
Yoav Etsion wrote:
> The problem is that the first mudflap pass takes place at the GIMPLE
> level, at which point all variables have their
> addressable/non-addressable attributes set, which forbids me to build an
> ADDR_EXPR node for a non-addressable pointer variable ("invalid operand
> to unary
On Friday 27 January 2006 09:10, Paolo Bonzini wrote:
> How big would the mini Java-runtime be? A bytecode-interpreter, with
> only support for two or three packages, using a simple Baker or
> mark'n'sweep GC, could be done in 10,000 lines of C code or maybe less.
JamVM is pretty small, I doubt
Hi Diego,
Diego Novillo wrote:
> Yoav Etsion wrote:
>
>
>>The problem is that the first mudflap pass takes place at the GIMPLE
>>level, at which point all variables have their
>>addressable/non-addressable attributes set, which forbids me to build an
>>ADDR_EXPR node for a non-addressable pointer
> ecj is written in java. This will complicate the bootstrap process.
> However, the situation will not be quite as severe as the Ada
> situation, in that it ought to be possible to bootstrap gcj using any
> java runtime, including mini ones such as JamVM -- at least, assuming
> that the sugg
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
> [...] IMHO, writing your frontend in the same language it's intended
> to compile causes it to be marginalized. It no longer becomes part
> of the default bootstrap sequence and gets much less testing. [..]
Even if so, it may be worth spelling out
Yoav Etsion <[EMAIL PROTECTED]> writes:
> The transformation is simple: mudflap already injects a call to
> __mf_register when an addressable variable is declared. I want to do
> the same for all pointer variables [...]
Why? If those pointers are not themselves taken address of, what kind
access
[EMAIL PROTECTED] (Frank Ch. Eigler) writes:
| - supplies "virtuous circle" motivation for improvement (speed,
| quality, ...), since it itself directly benefits
Fully agreed. Witness: GNU C :-)
-- Gaby
On Thu, Jan 26, 2006 at 05:08:20PM -0700, Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss the
Quoting Eric Botcazou <[EMAIL PROTECTED]>:
So, the question is, did I broke something by attempting to have both
32-bit and 64-bit GMP library installed simultaniously? Did I miss
anything needed to have both 32-bit and 64-bit GMP available on the
system?
Do not install both 32-bit and 64-bit
> I did some additional testing. I can reproduce the problem *only* on
> UltraSPARC-IIe machine. If I run the program on any other machine, it
> runs correctly.
Weird.
> Also, if I statically link program on UltraSPARC-IIe machine, it
> doesn't run on any other machine. If I statically link it
The pointer variable's address is used as the pointer's unique ID in a
database, collecting information about each pointer variable - mostly
its legal bounds. That way I can test when a pointer crosses its
object's bounds.
Terrible overhead, I know. Just need it to collect statistics about
pr
The newlib build fails with:
/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/./gcc/xgcc
-B/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/./gcc/ -nostdinc
-B/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/sh64-elf/compact/newlib/
-isystem
/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/sh64-elf/compact/n
> "Paolo" == Paolo Bonzini <[EMAIL PROTECTED]> writes:
Paolo> How big would the mini Java-runtime be? A bytecode-interpreter, with
Paolo> only support for two or three packages, using a simple Baker or
Paolo> mark'n'sweep GC, could be done in 10,000 lines of C code or maybe less.
The problem
Joern RENNECKE wrote:
> OK to backport to 4.1 if bootstrap on i686-pc-linux-gnu succeeds?
Yes.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Jan 26, 2006, at 4:05 PM, [EMAIL PROTECTED] wrote:
I really need correct profile information before PRE. By moving
rest_of_handle_branch_prob() just before rest_of_handle_gcse() have I
violated some critical assumptions which is causing the profile
information to be occasionally corrupted ?
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A couple of other factors:
Thanks for bringing these up.
Per> * Compile time.
Yeah, this is a potential problem. If it is severe it could be fixed
by linking ecj into GCC. FWIW, at least for all the packaging we do
in Fedora, we have
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> In particular, the type system and the rules for exception
Andrew> regions are different. Also, a "slot" in the .class format
Andrew> doesn't necessarily correspond to a variable in the source
Andrew> language.
One way to look at
On Fri, Jan 27, 2006 at 11:59:06AM -0700, Tom Tromey wrote:
> Column numbers, as Per mentioned, are trickier. We know that ecj has
> this information (since Eclipse itself uses it), but there is no
> standard way to pass it via the class file format. But does gdb
> actually use column numbers?
N
Yoav Etsion <[EMAIL PROTECTED]> writes:
> The pointer variable's address is used as the pointer's unique ID in
> a database, collecting information about each pointer variable -
> mostly its legal bounds. That way I can test when a pointer crosses
> its object's bounds.
If I understand correctly
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> But before fighting the political battles, we should first figure out if
Joe> this is what we really want to do if there weren't political obstacles.
Joe> Let's try coming to a technical consensus first.
I made a list of things which would
On Fri, Jan 27, 2006 at 12:14:40PM +0100, Bernd Schmidt wrote:
> Is this something that just isn't supposed to work in 3.4?
Probably. I don't remember that code well.
> Current
> mainline behaves differently and gives me TImode registers (which I'd
> rather prefer not to have to deal with eith
On Fri, 2006-01-27 at 09:25 -0500, Kaveh R. Ghazi wrote:
> > ecj is written in java. This will complicate the bootstrap process.
> > However, the situation will not be quite as severe as the Ada
> > situation, in that it ought to be possible to bootstrap gcj using any
> > java runtime, includi
On Fri, Jan 27, 2006 at 11:09:11PM +0100, Laurent GUERBY wrote:
> On Fri, 2006-01-27 at 09:25 -0500, Kaveh R. Ghazi wrote:
> > > ecj is written in java. This will complicate the bootstrap process.
> > > However, the situation will not be quite as severe as the Ada
> > > situation, in that it ou
Frank Ch. Eigler wrote:
Yoav Etsion <[EMAIL PROTECTED]> writes:
The pointer variable's address is used as the pointer's unique ID in
a database, collecting information about each pointer variable -
mostly its legal bounds. That way I can test when a pointer crosses
its object's bounds.
..
Snapshot gcc-4.1-20060127 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, 2006-01-27 at 17:17 -0500, Daniel Jacobowitz wrote:
> Two interesting things I'd like to point out here:
>
> - I don't know if it's been a problem lately, but GNAT definitely
> used to have issues with not just the language it was written
> in, but what specific version of the co
I got
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
`df_record_entry_block_defs':
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error:
`INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function)
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: (Each
und
> "Laurent" == Laurent GUERBY <[EMAIL PROTECTED]> writes:
Laurent> If someone comes up with an old JVM that misrun java in GCC
Laurent> and there's no easy obvious workaround, will you cancel the
Laurent> java project or just tell the user to install a known to work
Laurent> JVM from the GCC i
H. J. Lu wrote:
> I got
>
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
> `df_record_entry_block_defs':
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error:
> `INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function)
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df
> From: Laurent GUERBY
> Wether C++, Java or Ada, a new language requirement looks the same to
> me: having a good enough base compiler and runtime installed
> for the language, I do not see anything special to Java or
> Ada over C++ here. The base compiler I use for building GCC
> has only c,
As others have pointed out, there's potentially a small difference in
the case of Java, in that I believe the .class -> .o part of the
compiler would still be buildable without an existing JVM, and perhaps
even somewhat tested without one. And that's the part that's likely
Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss them below.
First, I'd like to commend and t
> Also I believe not allowing new languages for new front-ends might
> limit the increase of language front-ends in the GNU Compiler
> Collection:
I think "not allowing" is too strong a characterization of my previous
message. I have neither the inclination or the power to do that on my
own.
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
[...]
| However with Tom's proposal, we need an existing java compiler for our
| target.
I don't believe the issues at hand here (Java specific case) are as
severe as they sound from your messages. If GCC creators had to
follow the reasoning develope
Another concern: I gather there are lots of dependencies
between Eclipse libraries. Does ecj depend on any other
Eclipse libraries? Even if there are no run-time dependencies,
it's awkward if a class statically references some random
Eclipse class that somehow pulls in large parts of Eclipse.
I
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Another concern: I gather there are lots of dependencies
Per> between Eclipse libraries. Does ecj depend on any other
Per> Eclipse libraries?
Good point. I forgot to mention this.
The Eclipse compiler is standalone by design.
The pro
On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> H. J. Lu wrote:
> > I got
> >
> > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
> > `df_record_entry_block_defs':
> > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error:
> > `INCOMING_RETURN_ADDR_RTX' undecl
H. J. Lu wrote:
> On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
>> H. J. Lu wrote:
>>> I got
>>>
>>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
>>> `df_record_entry_block_defs':
>>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error:
>>> `INCOMING_RETUR
1) What would need to be done to reg-stack.c to allow other ports
besides i386 to use it? (support for multiple-stack machines would be
REALLY nice, but rather far off) (any other ideas?)
2) I found a minor bug in the header comment for reg-stack.c -- when
whoever wrote the comment documented
> "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
>
> | However with Tom's proposal, we need an existing java compiler for
> | our target.
>
> I don't believe the issues at hand here (Java specific case) are as
> severe as they sound from your messages.
Okay fine, let's quantify it. I dow
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| > "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| >
| > | However with Tom's proposal, we need an existing java compiler for
| > | our target.
| >
| > I don't believe the issues at hand here (Java specific case) are as
| > severe as they sound
46 matches
Mail list logo
