Re: Reconsidering gcjx

[Thorsten Glaser]

Tom Tromey dixit:

>In my preferred approach we would simply delete a portion of the
>existing gcj and turn jc1 into a purely bytecode-based compiler.

>ecj is written in java.  This will complicate the bootstrap process.

Why not keep enough support in jc1 to bootstrap ecj?
Maybe split out so that it can be used for only bootstrapping
(calling it jc1source or something, and being built only once
during a make bootstrap)?

>However, the situation will not be quite as severe as the Ada

Indeed. Try to build gcc 3.4 with gcc 4.0 (the Ada part)...

But having front-ends written in languages other than
C really is no good idea. On the other hand, in this
case the technical and maintenance (dropping off the
work to other people) benefits may outweigh it.

bye,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Toplevel bootstrap only - where are we?

[Daniel Jacobowitz]

Paolo's recent post on gcc-patches reminded me of all the toplevel
libgcc changes I have pending.  To recap, the dependence is: if libgcc
is moved out of the top level, the "configure --disable-bootstrap; make
bootstrap" approach will no longer work.  Building without a bootstrap
will be fine, of course - either for cross compilers, or in today's
sources with "configure --disable-bootstrap; make", or in hypothetical
future sources with "configure; make" if that goes back to being a
non-bootstrap target at some point.

So, how many people are still working with old-style GCC subdirectory
bootstrap?  What blockers are there, besides retraining our fingers?

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to reverse patch reversal in cfgcleanup.c (Was: RFA: re-instate struct_equiv code)

[Joern RENNECKE]

Bernd Schmidt wrote:


Joern RENNECKE wrote:

Because the new code as of December actually updated life information 
incorrectly, the global updates that were done had also quite a lot 
of work to do (and didn't really do it right, because of the presence 
of fake edges).



Could you elaborate on the problem with fake edges?


A fake edge is an edge from a node where there control might flow out of 
the function (or not at all), e.g. a call to a noreturn function, to the 
exit block.  As far as I can tell, these are inserted for the 
crossjumping pass so that we will cover matches involving such nodes, as 
they otherwise might not have any successor.
The problem with doing live updates in the presence of fake edges is 
that a number of registers are live in the exit block, in particular all 
the call-saved registers with are restored in the epilogue (the epilogue 
is a proper predecessor of the exit block, and the register restores are 
kept live by marking these registers as live in the exit block).
If you do an live update while fake edges are present, the liveness of 
registers in the exit block is propagated into the sources of the fake 
edges, even though most or all of these registers

are not actually live there.

libmudflap on Solaris?

[Aleksandar Milivojevic]

Was there any work (or plans) on porting libmudflap to Solaris (either 
SPARC or x86)?




This message was sent using IMP, the Internet Messaging Program.

XML tree dumps

[Dietmar Ebner]

Hi,

we're currently developing an experimental back-end for a very
irregular DSP architecture violating very basic assumptions of the
gcc back-end. In order to have the option to switch the front-end
for experimental reasons and to have a clear interface to gcc, we
chose to decouple the back-end and use XML as an intermediate language.

I just finished an initial implementation for XML tree dumps for the
4.1 branch that preserves the internal tree structure quite well and
might be of general interest. The patch itself and a small sample
are available at

http://www.complang.tuwien.ac.at/cd/ebner/xmldump

Given the strong tool support for XML and XSL, this might serve as an
excellent debugging utility. Furthermore, it might be useful to other
tools relying on the semantics of programs.

The intention of this posting is to ask for suggestions and to see if
it is of interest to integrate a dump format like this in gcc. The
representation is not yet as compact as I'd like to have it and the
current implementation ignores annotations such as alias information.
However, the intention should be clear.

Cheers,

-
Dietmar

PS: I didn't find a way to have manually malloc'ed memory point to
garbage collected trees, so I put my whole data structure under
ggc control. I would be grateful if somebody wants to have a look
at it since I'm not fully convinced of the correctness of my
implementation - although it seems to work.

-
Dietmar Ebner
CD Laboratory - Compilation Techniques for Embedded Processors
Institut fuer Computersprachen  E: [EMAIL PROTECTED]
Technische Universitaet WienT: (+431) 58801-18598
Argentinierstrasse 8 / E1851F: (+431) 58801-58521
1040 Wien, Austria  W: www.complang.tuwien.ac.at/cd/ebner

Re: Reconsidering gcjx

[Andrew Haley]

Tom Tromey writes:
 > > "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 this is: we really want to fix these things,

We can't.  They're inherent.  As far as I'm aware all bugs caused by
this difference have been fixed in the current bytecode compiler
(after much rewriting :-), but it's an "impedance mismatch" that
doesn't go away.

 > because, e.g., we'll probably be compiling all the java code in FC to
 > objects from class files for the foreseeable future anyway (to avoid
 > huge divergences from upstream build setups).
 > 
 > Moving to gcjx would turn "writing a 1.5 compiler" from a project
 > taking all of my time for the next year into a project that takes all
 > of my time for 2 months.  Then we'd have more time to fix other
 > things.

I understand that, but I don't believe it.  IMO, integrating ecj in
such an inelegant way would lead to perpetual maintenance problems,
especially with bootstrapping.  The great thing about the possibility
of gcjx is that it's possible to get things right, with a clean
separation of interfaces.

I would contrast your proposed ecj interface with a "correct" (IMO,
YMMV, etc) way to do it -- pass the parse trees from ecj to gcj, with
none of this messing about with bytecode.  I'm sure that's possible
with ecj.  But it still would lead to some fairly painful problems
bootstrapping.  This wouldn't affect us, because we always have a Java
compiler of some kind on every system we use.

 > Andrew> In particular,
 > Andrew> .class files don't contain the full pathnames to source files.

Apparently (says Per) there's a JSR around that we can use to fix this
in a standard way.

Andrew.

Re: libmudflap on Solaris?

[Rainer Orth]

Aleksandar Milivojevic <[EMAIL PROTECTED]> writes:

> Was there any work (or plans) on porting libmudflap to Solaris (either 
> SPARC or x86)?

Last time I looked (cf. PR libmudflap/15176), libmudflap depended on GNU
ld's --wrap option.  You might have some success when you use GNU binutils,
but I prefer the vendor linker if at all possible, so I haven't tried this.

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Changing the number of registers

[murali]

Hi,

  I am trying to change the number of registers for simplescalar's gcc
(2.7.2.3) compiler. I modified the ss.h file - FIXED_REGISTERS bits
and CALL_USED_REGISTERS bits, so as to leave just 8 integer and 4 FP
registers. But when I do a live registers analysis, I get > 8 integer
registers live. Please tell me if there is something else I need to
take care of to change the number of registers.

  thanks,
  murali

  PS: There was a thread before with the same subject and similar
problems - I read that, but it still didn't solve the problem

Re: libmudflap on Solaris?

[Aleksandar Milivojevic]

Quoting Rainer Orth <[EMAIL PROTECTED]>:


Aleksandar Milivojevic <[EMAIL PROTECTED]> writes:


Was there any work (or plans) on porting libmudflap to Solaris (either
SPARC or x86)?


Last time I looked (cf. PR libmudflap/15176), libmudflap depended on GNU
ld's --wrap option.  You might have some success when you use GNU binutils,
but I prefer the vendor linker if at all possible, so I haven't tried this.


I'm using GNU ld.  Before I sent this email, I simply attempted to pass 
'--enable-libmudflap' to gcc configure script.  The compilation failed 
while compiling libmudflap/mf-hooks2.c with bunch of warnings about 
'bzero', 'bcopy, and so on, and then errors about dereferencing pointer 
to incomplete type.  I was just curious if anybody was already porting 
it to Solaris...




This message was sent using IMP, the Internet Messaging Program.

[gnu.org #272999] Gcc installation help

[Stephen Huenneke via RT]

Hi,
I'm sorry, but as this is only a general contact address, I cannot
properly answer technical questions such as yours.  The best I can do is
refer you to the GCC Manual (http://gcc.gnu.org/onlinedocs/) and Frequently
Asked Questions (http://gcc.gnu.org/faq.html).  If neither of those provide
an answer to your question, please contact the GCC users' help list; you
can learn more about it at .

I am sorry that I couldn't be of more help
-- 
Stephen Huenneke
Program Assistant
Free Software Foundation
51 Franklin St. Fifth Floor
Boston, MA 02110

Re: Mainline is broken on ia64

[Richard Henderson]

On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX
> with an ifdef)?

That would be wrong.  INCOMING_RETURN_ADDR_RTX is *required*
when defining DWARF2_UNWIND_INFO.  

But DWARF2_UNWIND_INFO shouldn't be defined for ia64.

Re: Mainline is broken on ia64

[H. J. Lu]

On Mon, Jan 30, 2006 at 10:26:44AM -0800, Richard Henderson wrote:
> On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> > Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX
> > with an ifdef)?
> 
> That would be wrong.  INCOMING_RETURN_ADDR_RTX is *required*
> when defining DWARF2_UNWIND_INFO.  
> 
> But DWARF2_UNWIND_INFO shouldn't be defined for ia64.

Does that mean DWARF2_UNWIND_INFO should be checked before using
INCOMING_RETURN_ADDR_RTX instead of checking INCOMING_RETURN_ADDR_RTX?


H.J.

Re: Changing the number of registers

[Mike Stump]

On Jan 30, 2006, at 9:50 AM, murali wrote:

  I am trying to change the number of registers for simplescalar's gcc
(2.7.2.3) compiler.


It is unlikely we're going to help much with 2.7.2.3, we'd recommend  
up-porting to gcc 4.2 to start with.

RFD: marking a variable as addressable - need new hook? (pr26004)

[Joern RENNECKE]

gimplify.c:gimplify_modify_expr_rhs tries to optimize calls to functions 
which return their value in memory, if the result is assigned to a 
variable, by using the address of that variable as the location where 
the result is top be stored.  It uses lang_hooks.mark_addressable to 
mark the variable

as addressable.
There is a preceding check that is supposed to verify that the variable 
is not a register variable,  but the function called - 
is_gimple_reg_type - is really more a heuristic for optimizations.
The necessary information to decide if we can safely call 
lang_hooks.mark_addressable is not available in a frontend-independet 
manner.  I think we need a new frontend hook that can tell an optimizer 
if a call to lang_hooks.mark_addressable  would succeed.

Enabling tree->rtl to generate (plus for asm() operands at O0

[Mike Stump]

I'm trying to get:

void foo() {
  int rowfraclo[2];
  rowfraclo[1] = 42;
  asm ("movd mm6, %a0" : : "p" (rowfraclo+1));
}

to generate:

movd mm6, -4(%ebp)

at -O0.  Currently we generate:

  leal-8(%ebp), %eax
  addl$4, %eax
  movd mm6, (%eax)

With the below patch (still running the testsuite) I can get the  
compiler to generate that code.  So, the question is how better can I  
do this?


Doing diffs in .:
--- ./expr.c.~1~2006-01-27 14:56:09.0 -0800
+++ ./expr.c2006-01-27 15:46:14.0 -0800
@@ -6358,9 +6358,11 @@ expand_expr_addr_expr_1 (tree exp, rtx t
  TREE_USED (exp) = 1;
}
 
+#if 0
  if (modifier != EXPAND_INITIALIZER
  && modifier != EXPAND_CONST_ADDRESS)
result = force_operand (result, target);
+#endif
  return result;
}
 
--- ./function.c.~1~2006-01-27 14:56:10.0 -0800
+++ ./function.c2006-01-27 16:55:58.0 -0800
@@ -1455,6 +1455,18 @@ instantiate_virtual_regs_in_insn (rtx in
   x = recog_data.operand[i];
   switch (GET_CODE (x))
{
+   case PLUS:
+ {
+   bool changed = false;
+   rtx addr = x;
+
+   for_each_rtx (&addr, instantiate_virtual_regs_in_rtx, &changed);
+   x = addr;
+   if (!changed)
+ continue;
+ }
+ break;
+
case MEM:
  {
rtx addr = XEXP (x, 0);
--- ./stmt.c.~1~2006-01-27 14:56:16.0 -0800
+++ ./stmt.c2006-01-27 15:56:26.0 -0800
@@ -867,7 +867,7 @@ expand_asm_operands (tree string, tree o
   type = TREE_TYPE (val);
   op = expand_expr (val, NULL_RTX, VOIDmode,
(allows_mem && !allows_reg
-? EXPAND_MEMORY : EXPAND_NORMAL));
+? EXPAND_MEMORY : EXPAND_SUM));
 
   /* Never pass a CONCAT to an ASM.  */
   if (GET_CODE (op) == CONCAT)
--- ./tree-gimple.c.~1~ 2006-01-27 14:56:06.0 -0800
+++ ./tree-gimple.c 2006-01-27 15:41:37.0 -0800
@@ -386,6 +386,9 @@ is_gimple_asm_val (tree t)
   if (TREE_CODE (t) == VAR_DECL && DECL_HARD_REGISTER (t))
 return true;
 
+  if (TREE_CODE (t) == PLUS_EXPR)
+return true;
+
   return is_gimple_val (t);
 }
 
--

Re: Reconsidering gcjx

[Tom Tromey]

> "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:

>> ecj is written in java.  This will complicate the bootstrap process.

Thorsten> Why not keep enough support in jc1 to bootstrap ecj?

We don't know how much of the language that would be.

Tom

Re: Enabling tree->rtl to generate (plus for asm() operands at O0

[Andrew Pinski]

> I'm trying to get:
> 
> void foo() {
>int rowfraclo[2];
>rowfraclo[1] = 42;
>asm ("movd mm6, %a0" : : "p" (rowfraclo+1));
> }
> 
> With the below patch (still running the testsuite) I can get the  
> compiler to generate that code.  So, the question is how better can I  
> do this?

I don't know how better you can do but this actually fixes PR 23200.

Which does:
static char var;
int main()
{
  asm volatile ("" :: "i"(&var + 1));
  return 0;
}

(which looks weird in the sense it is undefined code but still legal code).

Thanks,
Andrew Pinski

Re: Mainline is broken on ia64

[Richard Henderson]

On Mon, Jan 30, 2006 at 10:31:18AM -0800, H. J. Lu wrote:
> Does that mean DWARF2_UNWIND_INFO should be checked before using
> INCOMING_RETURN_ADDR_RTX instead of checking INCOMING_RETURN_ADDR_RTX?

Yes.  But as-quoted, it already is.


r~

Microchip PIC

[François Poulain]

Hello,

I am talking about porting GCC on PIC18Fxxx, by Microchip.
I found some source code from Microchip to support the PIC30F. Anyone
can tell me why this code isn't in the gcc tree ? Is it dirty code ?

I ask this question, cause I maybe re-use that source code for testing.

Best Regards,

-- 
François Poulain
ch 734 rezid. du technopôle
29280 Plouzane
France
tel : 02 98 45 74 22

Re: Microchip PIC

[Lucas (a.k.a T-Bird or bsdfan3)]

I'm sorry about my e-mail client mangling your name in the To: field.

I don't know about the Microchip source, but I'd be happy to help with 
the GCC->PIC18Fxxx port...however, PIC's have 1 true accumulator (W) and 
everything else in data memory (which they use in the manner of a 
register file)...IDK how well GCC's register allocator would handle such 
a thing...


François Poulain wrote:


Hello,

I am talking about porting GCC on PIC18Fxxx, by Microchip.
I found some source code from Microchip to support the PIC30F. Anyone
can tell me why this code isn't in the gcc tree ? Is it dirty code ?

I ask this question, cause I maybe re-use that source code for testing.

Best Regards,

 

Re: Microchip PIC

[DJ Delorie]

> everything else in data memory (which they use in the manner of a
> register file)...IDK how well GCC's register allocator would handle
> such a thing...

For the m32c, I ended up describing 8 "registers" that were really
memory.  It gave gcc something to work with at least, but you have to
get the preferences right so it avoids them when it can.

Re: Microchip PIC

[François Poulain]

For the instant, I am learning for how GCC work, and for the definition
of machines descriptor. I founded the GCC port for PIC30, but it 's very
far of the PIC18.
I also seen the IP2022 port, and it will be helpfull.

In the Microchip PIC, there is only one Work register, but all the RAM
memory access takes only one Tcy. Another problem is the RAM memory,
witch is fragmented in some "banks" (due to the fact that the PIC is a 8
bit processor).

Le lundi 30 janvier 2006 à 17:37 -0600, Lucas (a.k.a T-Bird or bsdfan3)
a écrit :
> I'm sorry about my e-mail client mangling your name in the To: field.
> 
> I don't know about the Microchip source, but I'd be happy to help with 
> the GCC->PIC18Fxxx port...however, PIC's have 1 true accumulator (W) and 
> everything else in data memory (which they use in the manner of a 
> register file)...IDK how well GCC's register allocator would handle such 
> a thing...
> 
> François Poulain wrote:
> 
> >Hello,
> >
> >I am talking about porting GCC on PIC18Fxxx, by Microchip.
> >I found some source code from Microchip to support the PIC30F. Anyone
> >can tell me why this code isn't in the gcc tree ? Is it dirty code ?
> >
> >I ask this question, cause I maybe re-use that source code for testing.
> >
> >Best Regards,
> >
> >  
> >
>