Re: PR37363: PR36090 and PR36182 all over again

[Richard Sandiford]

Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> In case of cris, the predicate goes into general_operand, which does
>>>
>>>   if (CONSTANT_P (op))
>>> return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
>>>  || mode == VOIDmode)
>>> && (! flag_pic || LEGITIMATE_PIC_OPERAND_P (op))
>>> && LEGITIMATE_CONSTANT_P (op));
>>>
>>> H-P can check for the problematic case inside his LEGITIMATE_CONSTANT_P
>>> (*), or add a move expander for it.
>> 
>> I think you're mixing up CRIS and rs6000, the latter which
>> generated something it had to handle but which was munged,
>> PR36090.  CRIS is mainstream in that sense.  (You'd have to get
>> buy-in from David Edelsohn on a LEGITIMATE_CONSTANT_P definition
>> in rs6000 if PR36090 resurfaces.)
>
> This is from CRIS:
>
> (define_expand "movsi"
>   [(set
> (match_operand:SI 0 "nonimmediate_operand" "")
> (match_operand:SI 1 "cris_general_operand_or_symbol" ""))]
>   ...
>
> (define_special_predicate "cris_general_operand_or_symbol"
>   (ior (match_operand 0 "general_operand")
>(and (match_code "const, symbol_ref, label_ref")
> ...

As H-P says, the predicates on move expanders are generally ignored.
emit_move_insn & subroutines deliberately don't check them.
(Our usual method of making things match predicates is to force them
into a register, but that could easily lead to infinite recursion if
applied to moves.)

FWIW, in MIPS, I have a port policy of not adding predicates
to move expanders.  I think adding them just creates confusion,
because readers will think they actually mean something.

>>> 2) it makes clear how to fix bugs -- you restrict
>>> LEGITIMATE_CONSTANT_P/LEGITIMATE_PIC_OPERAND_P or add a move expander.
>> 
>> Contradicting current use, where anything that's found in a
>> non-LEGITIMATE_CONSTANT_P/LEGITIMATE_PIC_OPERAND_P must be
>> handled by a move expander!
>
> Not necessarily; anything that's found in a non-legitimate constant must
> be handled by force_reg, and force_reg also tries using force_operand if
> what it gets is not a general_operand.  But maybe it's necessary to add a
>
>   if (GET_CODE (value) == CONST)
> value = XEXP (value, 0);
>
> in force_operand.

As you say, force_operand currently does nothing with constants.
My understanding is that that really is by design (in the loosest
possible sense of the word).  As H-P says, it's then the move expander's
responsibility to handle the thing.

I know it's not the cleanest interface, but many ports are written
to follow this behaviour.

TBH, as I said in comment #11 in PR36182, I think rs6000 is being
overly cute with the representation of a TOC entry as:

   (const (minus foo (symbol_ref "*.LCTOC1"))).

It might be accurate, but (symbol_ref "*.LCTOC1") has no real meaning
to GCC.  And as we can see from these bugs, the extra symbol_ref just
tends to get in the way.

Other ports would generally use an unspec here.  (E.g. most ports
use an unspec for GOT-relative constants, even though:

   (const (minus foo (symbol_ref "_GLOBAL_OFFSET_TABLE_")))

would in some cases be accurate.)  I think using an unspec in rs6000
would solve some of the port-specific issues.  In particular, I don't
think 36090 would have happened with an unspec representation.

Richard

Re: PR37363: PR36090 and PR36182 all over again

[Paolo Bonzini]

> As H-P says, the predicates on move expanders are generally ignored.
> emit_move_insn & subroutines deliberately don't check them.

It's even worse; force_reg is effectively hardcoding movXX's operand 1
to be a general_operand.  (But my point was that force_reg does use
LEGITIMATE_CONSTANT_P through general_operand).

>> Not necessarily; anything that's found in a non-legitimate constant must
>> be handled by force_reg, and force_reg also tries using force_operand if
>> what it gets is not a general_operand.  But maybe it's necessary to add a
>>
>>   if (GET_CODE (value) == CONST)
>> value = XEXP (value, 0);
>>
>> in force_operand.
> 
> As you say, force_operand currently does nothing with constants.
> My understanding is that that really is by design (in the loosest
> possible sense of the word).  As H-P says, it's then the move expander's
> responsibility to handle the thing.

force_reg is weird:

1) it tries the move expander if operand 1 is a general_operand first;

2) it tries force_operand if it is not;

3) it tries the move expander if force_operand fails.

It would make sense to have something like: 1) check the move expander's
predicate; 2) try force_operand; 3) abort.  But I agree that it is not a
lightweight to change it, and I wouldn't propose it -- especially now.
OTOH every message in this thread is highlighting something fishy.

> would in some cases be accurate.)  I think using an unspec in rs6000
> would solve some of the port-specific issues.  In particular, I don't
> think 36090 would have happened with an unspec representation.

I agree.  So your plan would be to change rs6000 to an unspec, and drop
the problematic hunk in simplify-rtx.c?  That would be okay with me, but
it's not a small change for rs6000.

Paolo

front-end: compilation fails - how to fix 'use poisoned USE_MAPPED_LOCATION'

[Lemaitre Laurent-R29173]

Hi All,
I am building a new gcc front-end based on the treelang example.
I recently updated my gcc local SVN repository.
When I compile my front-end I get the following errors:
../../svn/gcc/laurent/lex.l:6:8: error: attempt to use poisoned
"USE_MAPPED_LOCATION"
../../svn/gcc/laurent/lex.l:26:8: error: attempt to use poisoned
"USE_MAPPED_LOCATION"
../../svn/gcc/laurent/lex.l: In function 'update_locus':
../../svn/gcc/laurent/lex.l:42: error: lvalue required as left operand
of assignment
../../svn/gcc/laurent/lex.l:60:11: error: attempt to use poisoned
"USE_MAPPED_LOCATION"
I used to refer to the treelang example in order to adapt my front-end
and make
it compile with the latest SVN version of gcc.
However I just found out that treelang is no more maintained (since a
few months).
Is-there a good (wiki) place where I can get some info on how to fix my
issue with 
USE_MAPPED_LOCATION?
Thanks for your help!
Laurent 

Re: New assert in haifa-sched.c

[Maxim Kuvyrkov]

Adam Nemet wrote:

Maxim Kuvyrkov writes:
I'm not 100% sure about current state of things, considering recent 
merge of sel-sched, but before that it was:


set_priorities() -> priority() -> dep_cost() -> recog_memoized().


I don't think that was the case for all insns even before the patch.  The only
new thing is the assert which now catches this.

If the consumer is an asm just like in gcc.dg/tree-ssa/stdarg-2.c:f10() then
we would not call recog on the producer inside dep_cost*.

The patch below fixes the issue for me.  I am going to test this if it looks
good to people.


I think a cleaner way would be to call recog_memoized() from within 
sched_init().  There's no ideal place to put call to recog_memoized() at 
the moment, but something like init_h_i_d() seems to be a better choice 
for initializing INSN_CODE() than dep_cost().


As far as your patch goes, I think it's ok (I'm not the maintainer, though).

--
Maxim

Re: PR37363: PR36090 and PR36182 all over again

[Hans-Peter Nilsson]

> Date: Sat, 06 Sep 2008 15:14:46 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>

> >> H-P can check for the problematic case inside his LEGITIMATE_CONSTANT_P
> >> (*), or add a move expander for it.
> > 
> > I think you're mixing up CRIS and rs6000, the latter which
> > generated something it had to handle but which was munged,
> > PR36090.  CRIS is mainstream in that sense.  (You'd have to get
> > buy-in from David Edelsohn on a LEGITIMATE_CONSTANT_P definition
> > in rs6000 if PR36090 resurfaces.)
> 
> This is from CRIS:

Oh, I misunderstood you.  By "problematic case" I thought you
meant the invalid or nonstandard CONSTs mentioned in the PRs!

> > Did you mean this as a short-term or long-term solution?
> > (Mind, we already have a proposed short-term solution.)
> 
> As a long term solution.  Though not in that exact shape -- I wanted to
> have discussion on it and converge together to a real solution.

Very well.

> >>   (*) but then does this mean the documentation for L_C_P is obsolete,
> >>   and returning 1 is not necessarily a good thing to do for targets with
> >>   sections?  Maybe there is a better definition that can be the default?
> > 
> > Again, LEGITIMATE_CONSTANT_P is the wrong macro, it's for
> > checking constants which are appropriate as immediate operands
> > (to non-move insns), not for being at-all-legitimate.
> 
> LEGITIMATE_CONSTANT_P is just what is used by general_operand.  I'm
> proposing another use of *the predicate for mov's operand 1*, not of
> LEGITIMATE_CONSTANT_P.  With the above questions, I was expressing my
> doubts on the doc for LEGITIMATE_CONSTANT_P in general.

Definitely.  Not sure that LEGITIMATE_CONSTANT_P is used
consistently too.

The doc's are based on the assumption that whatever is in the
CONST is benevolent and sane, either created by the target or
e.g.  symbol_ref + const_int.  The simplify-rtx optimization was
dreaming up a new one, (minus sym2 sym1).  The sad thing is that
*this* point (the CONST creation, simplify_plus_minus) isn't
really where it should be sanitized, because the constant could
very much just be a algorithmically correct "dream", intended to
just be put in a REG_EQUAL note.  (Which is exactly what happens
*first*; *then* a few lines, src of the insn is replaced too.)

Or, maybe the constant is not fit for any operand but as a
constant in memory!  *Then* we'd need a hook to sanitize
that...but maybe let's blow up that bridge only if we get to it.

A helper function, e.g. "trivial_constant_expression_p" that
returns true only if there's just a non-CONST CONST_OBJ or an
(const (plus (symbol_ref foo) (const_int N))) would do as the new
default for LEGITIMATE_CONSTANT_P.

> > Signalling that they are not legitimate means they can still be
> > handled by a move.
> 
> That's why I used the predicate.

But if the insn where the CONST is to be used isn't a move,
that's the wrong test...hm.

Ok, I stepped through the failing test, and the change in the
insn *is* validized, so a checking LEGITIMATE_CONSTANT_P would
help there.

> >> 2) it makes clear how to fix bugs -- you restrict
> >> LEGITIMATE_CONSTANT_P/LEGITIMATE_PIC_OPERAND_P or add a move expander.
> > 
> > Contradicting current use, where anything that's found in a
> > non-LEGITIMATE_CONSTANT_P/LEGITIMATE_PIC_OPERAND_P must be
> > handled by a move expander!
> 
> Not necessarily; anything that's found in a non-legitimate constant must
> be handled by force_reg, and force_reg also tries using force_operand if
> what it gets is not a general_operand.  But maybe it's necessary to add a
> 
>   if (GET_CODE (value) == CONST)
> value = XEXP (value, 0);
> 
> in force_operand.

Um, yeah, that might work (as amended by the two follow-up
messages).

> > To wit: a new bug would surface: you could here form something
> > that wasn't LEGITIMATE_CONSTANT_P but which was handled by a
> > move expander, and you'd force this into an insn which *isn't* a
> > move.  N.B. the insn in PR36182 wasn't a move.
> 
> Shouldn't the insn fail recognization, then?

Only with a LEGITIMATE_CONSTANT_P catching it...

So, can we agree on some or all of:

1. This (PR37363/PR36182) and PR36090 (in both ports) and
   whatever other port will be affected should be solved by a
   stricter LEGITIMATE_CONSTANT_P check, and where
   canonicalization is undefined (and a new definition can't get
   consensus agreed upon), the port has to check itself for
   whatever RTL expression it accepts.

2. Change the LEGITIMATE_CONSTANT_P documentation.

3. Change the default of LEGITIMATE_CONSTANT_P to a helper
   function, maybe trivial_constant_expression_p above.

brgds, H-P

Re: front-end: compilation fails - how to fix 'use poisoned USE_MAPPED_LOCATION'

[Tom Tromey]

> "Laurent" == Lemaitre Laurent-R29173 <[EMAIL PROTECTED]> writes:

Laurent> Is-there a good (wiki) place where I can get some info on how
Laurent> to fix my issue with USE_MAPPED_LOCATION?

USE_MAPPED_LOCATION was removed.  Only mapped locations remain.
So, you can fix your issue by removing the not-mapped code.

Tom

Re: PR37363: PR36090 and PR36182 all over again

[Paolo Bonzini]

> Only with a LEGITIMATE_CONSTANT_P catching it...

Of course.

> So, can we agree on some or all of:
> 
> 1. This (PR37363/PR36182) and PR36090 (in both ports) and
>whatever other port will be affected should be solved by a
>stricter LEGITIMATE_CONSTANT_P check, and where
>canonicalization is undefined (and a new definition can't get
>consensus agreed upon), the port has to check itself for
>whatever RTL expression it accepts.
> 
> 2. Change the LEGITIMATE_CONSTANT_P documentation.
> 
> 3. Change the default of LEGITIMATE_CONSTANT_P to a helper
>function, maybe trivial_constant_expression_p above.

Agreed, but I don't see t_c_e_p in GCC sources (if you meant my function
using the predicate, it cannot work because the predicate might in turn
call LEGITIMATE_CONSTANT_P).  It could be

  if (GET_CODE (x) != CONST)
return true;

  x = XEXP (x, 0);
  return GET_CODE (x) == PLUS && GET_CODE (XEXP (x, 1)) == CONST_INT
 && (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
 || GET_CODE (XEXP (x, 0)) == LABEL_REF);

(i.e. the test in cse.c) or something like that.

Would you change simplify-rtx.c to test LEGITIMATE_CONSTANT_P before
wrapping something with a CONST?

Alternatively, I wouldn't mind see rs6000 use unspecs for GOT/TOC
offsets as other ports do; this would allow removing the optimization in
simplify_plus_minus, which would fix CRIS too (because I'm worried that
other targets might be affected, not just CRIS).  Of course, if that
gives known pessimizations on rs6000 it would not be a good thing to do,
and probably no one would volunteer to do that change anyway, so...

Paolo

Re: PR37363: PR36090 and PR36182 all over again

[Hans-Peter Nilsson]

> Date: Sun, 07 Sep 2008 17:48:17 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>

> > 3. Change the default of LEGITIMATE_CONSTANT_P to a helper
> >function, maybe trivial_constant_expression_p above.
> 
> Agreed, but I don't see t_c_e_p in GCC sources

Of course not, as it's a *proposed* new helper function, but
nevertheless exactly as your suggestion. ;)

> Would you change simplify-rtx.c to test LEGITIMATE_CONSTANT_P before
> wrapping something with a CONST?

No, because as I mentioned, those CONSTs aren't only meant for
operands.  The change is validate_change'd later, so the new
LEGITIMATE_CONSTANT_P change catches the PR case and all is
good.  (It'd work for a move too, since we're dealing with
actual insns, not forced move expansion trickery.)

> Alternatively, I wouldn't mind see rs6000 use unspecs for GOT/TOC
> offsets as other ports do; this would allow removing the optimization in
> simplify_plus_minus, which would fix CRIS too (because I'm worried that
> other targets might be affected, not just CRIS).

Affecting not just CRIS is exactly a point I've been trying to
make clear!  But... those other targets would also be covered
with CONST-validizing LEGITIMATE_CONSTANT_P.  (Just an inside
guess, test results from CRIS change not in yet.)

>  Of course, if that
> gives known pessimizations on rs6000 it would not be a good thing to do,
> and probably no one would volunteer to do that change anyway, so...

*shrug*
With proper UNSPECs for their GOT and TOC expressions, I don't
think they'd suffer.  But, I don't have a horse in that race.

tm.texi change coming up.

brgds, H-P

Re: PR37363: PR36090 and PR36182 all over again

[Richard Sandiford]

Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> would in some cases be accurate.)  I think using an unspec in rs6000
>> would solve some of the port-specific issues.  In particular, I don't
>> think 36090 would have happened with an unspec representation.
>
> I agree.  So your plan would be to change rs6000 to an unspec, and drop
> the problematic hunk in simplify-rtx.c?  That would be okay with me, but
> it's not a small change for rs6000.

Yeah, this is very much my preferred option.

FWIW, here's a proof-of-concept patch for GNU/Linux and AIX.
It knowingly breaks Darwin, so it can't be applied as-is.
But if the idea seems OK to David, I'll volunteer to do the
Darwin stuff too (including x86 if necessary).

I compared the gcc.c-torture, gcc.dg and g++.dg output for the
following options:

-O2
-O2 -fpic
-O2 -fPIC
-O2 -mminimal-toc

on the following targets:

powerpc-linux-gnu
powerpc64-linux-gnu
powerpc-aix4.3

and there were no differences.  diffstat says:

 4 files changed, 49 insertions(+), 81 deletions(-)

Richard


gcc/
* config/rs6000/rs6000-protos.h (rs6000_output_addr_const_extra):
Declare.
* config/rs6000/rs6000.h (OUTPUT_ADDR_CONST_EXTRA): New macro.
* config/rs6000/rs6000.md (UNSPEC_TOCREL): New constant.
* config/rs6000/rs6000.c (constant_pool_expr_1): Delete.
(constant_pool_expr_p): Use split_const and check the base.
(toc_relative_expr_p): Likewise, checking for an UNSPEC_TOCREL
instead of a MINUS.
(legitimate_constant_pool_address_p): Check toc_relative_p
instead of constant_pool_expr_p.
(print_operand_address): Always use output_addr_const for
constant pool addresses.
(rs6000_output_addr_const_extra): New function.
(create_TOC_reference): Create an UNSPEC_TOCREL instead of
a MINUS.

Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   2008-09-07 11:22:24.0 +0100
+++ gcc/config/rs6000/rs6000-protos.h   2008-09-07 12:32:01.0 +0100
@@ -77,6 +77,7 @@ extern int extract_ME (rtx);
 extern void rs6000_output_function_entry (FILE *, const char *);
 extern void print_operand (FILE *, rtx, int);
 extern void print_operand_address (FILE *, rtx);
+extern bool rs6000_output_addr_const_extra (FILE *, rtx);
 extern enum rtx_code rs6000_reverse_condition (enum machine_mode,
   enum rtx_code);
 extern void rs6000_emit_sCOND (enum rtx_code, rtx);
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  2008-09-07 11:20:37.0 +0100
+++ gcc/config/rs6000/rs6000.h  2008-09-07 12:31:43.0 +0100
@@ -2344,6 +2344,12 @@ #define PRINT_OPERAND_PUNCT_VALID_P(CODE
 
 #define PRINT_OPERAND_ADDRESS(FILE, ADDR) print_operand_address (FILE, ADDR)
 
+#define OUTPUT_ADDR_CONST_EXTRA(STREAM, X, FAIL)   \
+  do   \
+if (!rs6000_output_addr_const_extra (STREAM, X))   \
+  goto FAIL;   \
+  while (0)
+
 /* uncomment for disabling the corresponding default options */
 /* #define  MACHINE_no_sched_interblock */
 /* #define  MACHINE_no_sched_speculative */
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md 2008-09-07 11:13:27.0 +0100
+++ gcc/config/rs6000/rs6000.md 2008-09-07 12:02:53.0 +0100
@@ -99,6 +99,7 @@ (define_constants
(UNSPEC_DLMZB_CR46)
(UNSPEC_DLMZB_STRLEN47)
(UNSPEC_RSQRT   48)
+   (UNSPEC_TOCREL  49)
   ])
 
 ;;
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  2008-09-07 10:53:53.0 +0100
+++ gcc/config/rs6000/rs6000.c  2008-09-07 16:17:05.0 +0100
@@ -765,7 +765,6 @@ static void rs6000_emit_allocate_stack (
 static unsigned rs6000_hash_constant (rtx);
 static unsigned toc_hash_function (const void *);
 static int toc_hash_eq (const void *, const void *);
-static int constant_pool_expr_1 (rtx, int *, int *);
 static bool constant_pool_expr_p (rtx);
 static bool legitimate_small_data_p (enum machine_mode, rtx);
 static bool legitimate_lo_sum_address_p (enum machine_mode, rtx, int);
@@ -3456,58 +3455,28 @@ gpr_or_gpr_p (rtx op0, rtx op1)
 
 /* Subroutines of rs6000_legitimize_address and rs6000_legitimate_address.  */
 
-static int
-constant_pool_expr_1 (rtx op, int *have_sym, int *have_toc)
-{
-  switch (GET_CODE (op))
-{
-case SYMBOL_REF:
-  if (RS6000_SYMBOL_REF_TLS_P (op))
-   return 0;
-  else if (CONSTANT_POOL_ADDRESS_P (op))
-   {
- if (ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (op), Pmode))
-  

Re: PR37363: PR36090 and PR36182 all over again

[David Edelsohn]

On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
>> I agree.  So your plan would be to change rs6000 to an unspec, and drop
>> the problematic hunk in simplify-rtx.c?  That would be okay with me, but
>> it's not a small change for rs6000.
>
> Yeah, this is very much my preferred option.
>
> FWIW, here's a proof-of-concept patch for GNU/Linux and AIX.
> It knowingly breaks Darwin, so it can't be applied as-is.
> But if the idea seems OK to David, I'll volunteer to do the
> Darwin stuff too (including x86 if necessary).
>
> I compared the gcc.c-torture, gcc.dg and g++.dg output for the
> following options:
>
>-O2
>-O2 -fpic
>-O2 -fPIC
>-O2 -mminimal-toc
>
> on the following targets:
>
>powerpc-linux-gnu
>powerpc64-linux-gnu
>powerpc-aix4.3
>
> and there were no differences.

I do not object in principle to converting the TOC addressing to
use UNSPEC.  We need to ensure that this produces the same
assembly code, not just lack of testsuite failures.

I still think that this is ignoring the issue of simplify-rtx.c versus
commutative_operand_precedence.  Even if rs6000 does not
rely on this idiom, simplify-rtx.c is re-grouping operands it
should not change.

David

Re: PR37363: PR36090 and PR36182 all over again

[Richard Sandiford]

"David Edelsohn" <[EMAIL PROTECTED]> writes:
> On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
> <[EMAIL PROTECTED]> wrote:
>>> I agree.  So your plan would be to change rs6000 to an unspec, and drop
>>> the problematic hunk in simplify-rtx.c?  That would be okay with me, but
>>> it's not a small change for rs6000.
>>
>> Yeah, this is very much my preferred option.
>>
>> FWIW, here's a proof-of-concept patch for GNU/Linux and AIX.
>> It knowingly breaks Darwin, so it can't be applied as-is.
>> But if the idea seems OK to David, I'll volunteer to do the
>> Darwin stuff too (including x86 if necessary).
>>
>> I compared the gcc.c-torture, gcc.dg and g++.dg output for the
>> following options:
>>
>>-O2
>>-O2 -fpic
>>-O2 -fPIC
>>-O2 -mminimal-toc
>>
>> on the following targets:
>>
>>powerpc-linux-gnu
>>powerpc64-linux-gnu
>>powerpc-aix4.3
>>
>> and there were no differences.
>
> I do not object in principle to converting the TOC addressing to
> use UNSPEC.  We need to ensure that this produces the same
> assembly code, not just lack of testsuite failures.

Yeah, sorry, that's what I meant by the rather vague "differences".
The assembly output was the same in all cases.

> I still think that this is ignoring the issue of simplify-rtx.c versus
> commutative_operand_precedence.  Even if rs6000 does not
> rely on this idiom, simplify-rtx.c is re-grouping operands it
> should not change.

Well, my hope is that if we move towards unspecs for this kind of thing,
we can define a simple grammar for CONSTs.  See my reply to H-P's
gcc-patches message for details.  There wouldn't be any grouping
inside a CONST then: it would either be an unspec base,
or a base + a CONST_INT.

I'll work on a Darwin patch, but it might be a few days...

Richard

passes description

[Basile STARYNKEVITCH]

Hello All,

I have a wish: that each (middle-end) pass [those in gcc/tree-passes.h] 
would have a small documentation describing it (in particular which 
representations, TREE, SSA, CFG, etc... are valid after the pass). A 
simple wiki page (describing each pass) would be more than enough for 
me. Or at least having each *_opt_pass described in 
http://gcc.gnu.org/onlinedocs/gccint/Tree_002dSSA-passes.html without 
exceptions (even trivial clean-up passes need a few sentences).


I have difficulty in trying to position my passes in passes.c I'm pretty 
sure not to be alone on that!


I want to use MELT to prototype a single interval static analyser (like 
the interval analysis mentioned in 
http://en.wikipedia.org/wiki/Abstract_interpretation). I believe I need 
SSA & CFG.


perhaps we might need to define, e.g, some common comment structure for 
each *_opt_pass of tree-passes.h.


What do people think?

In addition, I find difficult & unrealistic to propose a patch for that, 
because that would essentially means understand the exact role of every 
pass, and I am not able of that, and I even think that few GCC hackers 
are understanding that.


I'm suggesting at least adding detailed comments inside each *_opt_pass 
structure.


I also think that each pass should have a unique name. Remember, if a 
pass name starts with '*' it behave as if it has no name (ie no dumping 
occur). I find pitiful that some new passes are still unamed.


I presume that there are some passes which nobody understands, but I 
believe that since the gimple -> tuple transition happened recently this 
 might be false know. I suppose that there are active contributors who 
know what the pass they patched are grossly doing.


So what would be the easiest solution to get more description of each pass?

Given that passes are central to the middle end in GCC, shouldn't we 
want each of them (without exception!) be described by at least a simple 
paragraph. I'm sure that is a small effort for each pass writer (he/she 
knows what he has coded) but it is a huge effort for somebody not 
understanding them. Should we aim for some structured comments, for some 
requirements regarding documenting the pass in the doc/*texi files, in 
the wiki, ...?


See also http://gcc.gnu.org/wiki/MakingGCCEasierToLearn

regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Bootstrap failure on sparc-sun-solaris2.10

[Eric Botcazou]

> When I tried mainline bootstrap on sparc-sun-solaris2.11 as of 20080903
> (rev 139939), I get a configure failure in stage2 libgcc:
>
> checking for suffix of object files... configure: error: in
> `/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile See
> `config.log' for more details.
>
> and config.log reveals:
>
> configure:2590: checking for suffix of object files
> configure:2611: /vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/xgcc
> -B/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/
> -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
> -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
> /vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2conftest.c >&5
> conftest.c:12: internal compiler error: Bus Error
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Confirmed (on Solaris 9).  Would you mind opening a PR?  There is already one 
for Linux (37344) but the failure is a little different.  Thanks in advance.

-- 
Eric Botcazou