Re: PA specifies invalid T_ADAFLAGS

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

Our view from when we looked at this is that there is nothing wrong with
GCC or GNAT here, it is just that the assumptions that GNAT makes about
virtual addressing require this switch to be turned off. The hardware spec
seems clear to me.

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> Our view from when we looked at this is that there is nothing wrong with
> GCC or GNAT here, it is just that the assumptions that GNAT makes about
> virtual addressing require this switch to be turned off. The hardware spec
> seems clear to me.

OK.  I believe that the change that Zack Weinberg made changing
ADA_CFLAGS to T_ADAFLAGS was incorrect.  Aside from the fact
that this is incorrect for cross builds, T_ADAFLAGS appears
to be used only when compiling ada files in GCC.

I looked at the segmentation fault that I previously reported
in this thread.  It occurs in process_decls in trans.c on an
index instruction.  Thus, "-mdisable-indexing" may have to be
used in compiling the C code as well.  I need to investigate
further to determine why there is a problem with the base register
in C code.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

> No.  The semantics of Ada don't play well with the funky implicit space 
> register
> selection done on PAs.  -mdisable-indexing is really needed for Ada.

I think this is misleading, this has nothing to do with the semantics of
Ada. it has to do with implementation dependent code whose meaning is
not guaranteed by the standard, but which works fine on all architectures
we know of, except for HPUX without this switch. This switch is needed for
the GNAT front end, but not for Ada apps in general.

Re: PA specifies invalid T_ADAFLAGS

[Matthew Wilcox]

On Fri, Apr 26, 2002 at 05:54:24AM -0400, Richard Kenner wrote:
>     I think you're slightly confused.  Unless you modify the gcc backend,
>     it's just not possible to output instructions which use sr0-3.  
> 
> Sure it is, if you have a large enough virtual origin.

No, it really isn't.  See
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,959!26!244,00.html

Only space registers 4-7 are used for implicit addressing.  gcc doesn't
do explicit addressing.

Are you perhaps confused with ia64 where the address space is divided
into 8 rather than 4?

-- 
Revolutions do not require corporate support.

Re: PA specifies invalid T_ADAFLAGS

[Richard Kenner]

    I was wondering whether on hpux-like hosts whether the gnat driver
    should automatically be run with "-mdisable-indexing" (ie., whether
    it needs a SPEC define).

No, because it's only needed when compiling GNAT.  Also, it's a *host*
option, not a target option.

Re: PA specifies invalid T_ADAFLAGS

[Matthew Wilcox]

You wrote (removing me from the cc, so i can't quote you properly):

Again, the -mdisable-indexing was not working around a *bug* but a 
fundamental problem in the PA architecture preventing virtual origins
from working if they are used.

Unless *all 8* SR's are set to consecutive memory segments, it isn't safe
to use the indexing forms.

-- end quote --

I think you're slightly confused.  Unless you modify the gcc backend,
it's just not possible to output instructions which use sr0-3.  And sr4-7
have to be set to identical, not consective values.  The top two bits
of the address which select which of sr4-7 to use are left intact and
form part of the virtual address.

-- 
Revolutions do not require corporate support.

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

<I was wondering whether on hpux-like hosts whether the gnat driver
should automatically be run with "-mdisable-indexing" (ie., whether
it needs a SPEC define).
>

This is only needed for the compiler (or for any other program playing
similar virtual indexing games, which are not really well defined official
Ada :-)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

Yes, -mdisable-indexing should most definitely be used in the C code as well

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> Yes, -mdisable-indexing should most definitely be used in the C code as well

I am trying to define ADA_CFLAGS=-mdisable-indexing in a host fragment.
In doing this, I found there seems to be a problem in passing ADA_CFLAGS
from the gcc Makefile.  We have this line in ada/Make-lang.in:

ADA_FLAGS_TO_PASS = \
        "ADA_CFLAGS=$(CFLAGS)" \
	...

It looks to me like this should be
ADA_FLAGS_TO_PASS = \
        "ADA_CFLAGS=$(ADA_CFLAGS)" \

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

>>The example is not legal C

We definitely agree that the example is not legal C. However it will
in practice work on all common architectures *except* HP without the
switch. 

The gain in using virtual origins in the GNAT compiler is quite
considerable, so it is well worth taking advantage of this. Note that
it is only the compiler itself that is affected (unless some GNAT user
plays the same trick :-)

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> The gain in using virtual origins in the GNAT compiler is quite
> considerable, so it is well worth taking advantage of this. Note that
> it is only the compiler itself that is affected (unless some GNAT user
> plays the same trick :-)

I was wondering whether on hpux-like hosts whether the gnat driver
should automatically be run with "-mdisable-indexing" (ie., whether
it needs a SPEC define).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

<<If the assembler code you showed was created by compiling the C snippet,
this indicates nothing, because this wasn't C (accessing data through vb[]
is undefined).  So, that it there SEGV's is no error, as the compiler
might apply any transformations it wants.  You need to provide an actual
Ada testcase which shows this.
>>

Right, of course this is formally undefined in C, which is why for completely
valid C code, you don't need the switch. 

Whether it is formally undefined in Ada is an interesting issue. I would
say it is in the implementation defined category.

The point is that code like this will work on virtually (:-) all architectures
but on HPUX, works only if the switch is there. I think the snippet here
should indicate the problem clearly enough. If you need Ada code, imagine
the C being transformed 1-1 into Ada at exactly the same level of abstrction.

Re: PA specifies invalid T_ADAFLAGS

[Richard Kenner]

Again, the -mdisable-indexing was not working around a *bug* but a 
fundamental problem in the PA architecture preventing virtual origins
from working if they are used.

Unless *all 8* SR's are set to consecutive memory segments, it isn't safe
to use the indexing forms.

Re: PA specifies invalid T_ADAFLAGS

[law]

In message <10204251034.AA10713@vlsi1.ultra.nyu.edu>, Richard Kenner writes:
 > Again, the -mdisable-indexing was not working around a *bug* but a 
 > fundamental problem in the PA architecture preventing virtual origins
 > from working if they are used.
 > 
 > Unless *all 8* SR's are set to consecutive memory segments, it isn't safe
 > to use the indexing forms.
More correctly, sr4-sr7 need to be set to the _same_ memory segment.

Some systems do this (Utah's BSD & OSF ports for example) and there were
some PAs without space registers (level 0 implementations, not to be confused
with PA1.0).

On systems where sr4-sr4 hit the same segment or on level 0 implementations
indexing can be done without considering the implicit space register selection
problems.


jeff

Re: PA specifies invalid T_ADAFLAGS

[Richard Kenner]

The issue is that the data symbol might be in sr4, say, but when the
virtual origin is computed, it ends up in sr3.

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

> Your comments that the base register can end up in the wrong segment
> still suggests a bug to me.  I can't imagine the linker working with
> anything other than the standard runtime.  As I said, a fix was done
> regarding which register becomes the base register.  There were
> problems in the past with the index being selected as the base register
> and that didn't work with the segmented architecture of the PA.

OK, well indeed that might be correct. This always *sounded* like a bug
to me :-)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

> I think there's a misunderstanding.  If GNAT simply uses standard
> addresses from 0 to 2^32-1 there is no problem.  If GNAT tries to take
> advantage of PA's space register facilities to address more than 4GB
> simultaneously, then it simply won't work under PA Linux.

ok, well then you are saying that virtual indexing should always
work on Linux, unlike HPUX, and it sounds like you are right :-)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

I see nothing in GNAT's use of virtual indexing that would guarantee
avoidance of sr 1, 2 or 3 in the base address (i.e. the address BEFORE
indexing). Perhaps you are right, but it would take careful analysis.

Re: PA specifies invalid T_ADAFLAGS

[Matthew Wilcox]

On Wed, Apr 24, 2002 at 11:26:13PM -0400, Robert Dewar wrote:
> I see nothing in GNAT's use of virtual indexing that would guarantee
> avoidance of sr 1, 2 or 3 in the base address (i.e. the address BEFORE
> indexing). Perhaps you are right, but it would take careful analysis.

I think there's a misunderstanding.  If GNAT simply uses standard
addresses from 0 to 2^32-1 there is no problem.  If GNAT tries to take
advantage of PA's space register facilities to address more than 4GB
simultaneously, then it simply won't work under PA Linux.

-- 
Revolutions do not require corporate support.

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> I see nothing in GNAT's use of virtual indexing that would guarantee
> avoidance of sr 1, 2 or 3 in the base address (i.e. the address BEFORE
> indexing). Perhaps you are right, but it would take careful analysis.

The backend doesn't use sr1, sr2 or sr3.  So, I don't see how they would
ever get used.  As long as the base address relates to a data symbol,
and you are trying to access data, things should be ok.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

> Is this a bug in the PA backend?  Without fixing the problem, it will not
> be possible to correctly build GNAT under hppa-linux, except by starting
> with a working hpux port.  It's been some time since I tried it but
> starting from the last binary release for hpux was very difficult because
> there are major problems building the current source with 2.8.1x.

No, it is not a bug in the PA backend, it is just that the segmentation
in HPPA works on the base address before indexing. This means that if you
use virtual indexing (an important part of the data structure approach
used by GNAT), then the virual origin can be in the "wrong" segment.

Re: PA specifies invalid T_ADAFLAGS

[Robert Dewar]

> I suspect using "-mdisable-indexing" dates from a time when indexing
> didn't work very well.  This was reworked a year or two ago.

No, this is definitely needed for Ada, due to its use of virtual array
indexing, which otherwise fails on the PA, due to its odd segmentation
semantics.

Re: PA specifies invalid T_ADAFLAGS

[Matthew Wilcox]

On Wed, Apr 24, 2002 at 10:59:13PM -0400, Robert Dewar wrote:
> > I suspect using "-mdisable-indexing" dates from a time when indexing
> > didn't work very well.  This was reworked a year or two ago.
> 
> No, this is definitely needed for Ada, due to its use of virtual array
> indexing, which otherwise fails on the PA, due to its odd segmentation
> semantics.

Hmm... could you be a little more specific?  I suspect this may not be an
issue for hppa-linux.  For those who are unfamiliar with what's going on,
a potted summary:

PA has 8 space registers numbered 0 to 7.  Most instructions allow you
to specify one of 1, 2 or 3, OR to select the space register to use based
on the top two bits of the virtual address.  If the top two bits are 00,
use sr4, 01, use sr5, 10 uses 6 and 11 uses 7.  HPUX takes advantage
of this to map all shared libraries in one quadrant, program text in
another quadrant and program data in a third and fourth.  Linux does
no such thing and programs space registers 4 to 7 with the same value.
So anything can be mapped anywhere and programs appear to have a flat
address space.  As long as the compiler doesn't decide to generate an
instruction specifying sr 1, 2 or 3 -- and there's no reason it should --
you can pretty much ignore the segmentation in userspace on Linux/PA.

-- 
Revolutions do not require corporate support.

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> PA has 8 space registers numbered 0 to 7.  Most instructions allow you
> to specify one of 1, 2 or 3, OR to select the space register to use based
> on the top two bits of the virtual address.  If the top two bits are 00,
> use sr4, 01, use sr5, 10 uses 6 and 11 uses 7.  HPUX takes advantage

The first model is only available under hpux using assembly language.
The standard code generated by gcc uses sr4 which causes the top two
bits of a virtual address to select one of sr4, sr5, sr6, or sr7,
respectively.

Your comments that the base register can end up in the wrong segment
still suggests a bug to me.  I can't imagine the linker working with
anything other than the standard runtime.  As I said, a fix was done
regarding which register becomes the base register.  There were
problems in the past with the index being selected as the base register
and that didn't work with the segmented architecture of the PA.

I agree with Matthew that "-mdisable-indexing" should not be used
under linux as it has a flat memory model.

There doesn't seem to be any documentation of why -mdisable-indexing
is needed and nothing in the changelogs.  If there is something
special about the memory model used by ada, it would be good to
have it documented.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Richard Kenner]

The -mdisable-indexing flag is very much still needed for PA due to
the use of virtual arrays in GNAT.

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> The -mdisable-indexing flag is very much still needed for PA due to
> the use of virtual arrays in GNAT.

I don't know much about GNAT's virtual arrays.  However, as long as they
are intended for the access of data and not code, then I think the
current backend should work without -mdisable-indexing.  This patch fixed
a lot of problems in this area:

2000-11-22  John David Anglin  <dave@hiauly1.hia.nrc.ca>

        * function.h (emit_status): Delete member regno_pointer_flag and
	rename regno_pointer_flag_length to regno_pointer_align_length.
	Delete define for REGNO_POINTER_FLAG.
	* integrate.h (inline_remap): Delete member regno_pointer_flag.
	Add member x_regno_reg_rtx.
	* rtl.h (rtx_def): Use frame_related bit to indicate register is
	a pointer in REG expressions.  Define REG_POINTER macro.
	* alias.c (find_base_value, find_base_term): Use REG_POINTER
	instead of REGNO_POINTER_FLAG.
	* combine.c (nonzero_bits, num_sign_bit_copies): Likewise.
	* emit-rtl.c (gen_reg_rtx): Use regno_pointer_align_length instead
	of regno_pointer_flag_length.  Remove code which refers to
	regno_pointer_flag.
	(mark_reg_pointer): Use REG_POINTER.
	(free_emit_status): Remove code which refers to regno_pointer_flag.
	(init_emit, mark_emit_status): Likewise.
	* flow.c (dump_flow_info): Likewise.
	* function.c (preserve_temp_slots): Likewise.
	* integrate.c (expand_inline_function, copy_rtx_and_substitute):
	Use x_regno_reg_rtx instead of regno_pointer_flag for function
	pointer determination in map.
        * loop.c (strength_reduce, maybe_eliminate_biv_1): Use REG_POINTER.
	* predict.c (estimate_probability): Likewise.
	* regclass.c (record_address_regs, reg_scan_mark_refs): Likewise.
	* unroll.c (unroll_loop): Use x_regno_reg_rtx instead of
	regno_pointer_flag for function pointer determination in map.
	* convex.h (RTX_COSTS): Don't test regno_pointer_flag and use
	REG_POINTER.
	* pa.c (hppa_legitimize_address, emit_move_sequence, basereg_operand):
	Use REG_POINTER.
	(restore_unscaled_index_insn_codes): Revise comment.

Has the PA indexing situation been reviewed since the above patch was
installed?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Arnaud Charlet]

> Has the PA indexing situation been reviewed since the above patch was
> installed?

It sure has. This patch is pretty old at this stage. The situation has been
reviewed very recently.

Arno

Re: PA specifies invalid T_ADAFLAGS

[Richard Henderson]

On Thu, Apr 25, 2002 at 09:08:09AM +0200, Arnaud Charlet wrote:
> It sure has. This patch is pretty old at this stage. The situation has been
> reviewed very recently.

I've read this whole thread and, like John and Matt, I *still* don't
know exactly the problem you and Robert are referring to.

I think yall should supply a failing test case rather than continue
to say "it doesn't work".  At minimum this properly documents the
problem.


r~

Re: PA specifies invalid T_ADAFLAGS

[law]

In message <20020425004856.B2022@redhat.com>, Richard Henderson writes:
 > On Thu, Apr 25, 2002 at 09:08:09AM +0200, Arnaud Charlet wrote:
 > > It sure has. This patch is pretty old at this stage. The situation has bee
 > n
 > > reviewed very recently.
 > 
 > I've read this whole thread and, like John and Matt, I *still* don't
 > know exactly the problem you and Robert are referring to.
 > 
 > I think yall should supply a failing test case rather than continue
 > to say "it doesn't work".  At minimum this properly documents the
 > problem.
Conceptually you're allows to have a pointer outside the object it points to;
dereferences of the pointer will include an offset which will bring the
resulting address back into the original object.  This really mucks up the
implicit space register selection on the PA -- space registers are implicitly
selected by the upper 2 bits of the base register (not the effective address!).

I can't remember how to do much of anything in data, but if you wanted to
dig further, you'd want to look for something like "virtual origins" in the
Ada spec.

jeff

Re: PA specifies invalid T_ADAFLAGS

[Olivier Hainque]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

> Has the PA indexing situation been reviewed since the above patch was
> installed?

Perhaps a testcase exercised against the current 3.1 would help ...

IIUC, some constructs we have in Ada basically amount to the following kind of
behavior in C:


     #include <malloc.h>

     int lo ()
     {
       return 60000;
     }

     int
     main ()
     {
       volatile char c;

       char * b  = malloc (15);
       char * vb = b - lo();

       c = vb [lo()];

       return 0;
     }


 with 3.1 20020424 on pa-hpux, the O1 output without -mdisable-indexing reads:

        bl malloc,%r2
        ldi 15,%r26
        .CALL 
        bl lo,%r2
        copy %r28,%r4
        .CALL 
        bl lo,%r2
        sub %r4,%r28,%r4
        ldbx %r28(%r4),%r4   <=== Runtime fault here
        stb %r4,-120(%r30)

 
 This dumps core at the ldbx point because the space check is performed
 against r28 and not r28+r4.

Re: PA specifies invalid T_ADAFLAGS

[Michael Matz]

Hi,

On 25 Apr 2002, Olivier Hainque wrote:

> Perhaps a testcase exercised against the current 3.1 would help ...

If the assembler code you showed was created by compiling the C snippet,
this indicates nothing, because this wasn't C (accessing data through vb[]
is undefined).  So, that it there SEGV's is no error, as the compiler
might apply any transformations it wants.  You need to provide an actual
Ada testcase which shows this.


Ciao,
Michael.

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> "John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
> 
> > Has the PA indexing situation been reviewed since the above patch was
> > installed?
> 
> Perhaps a testcase exercised against the current 3.1 would help ...
> 
> IIUC, some constructs we have in Ada basically amount to the following kind of
> behavior in C:
> 
> 
>      #include <malloc.h>
> 
>      int lo ()
>      {
>        return 60000;
>      }
> 
>      int
>      main ()
>      {
>        volatile char c;
> 
>        char * b  = malloc (15);
>        char * vb = b - lo();
> 
>        c = vb [lo()];
> 
>        return 0;
>      }

[...]

>         bl lo,%r2
>         copy %r28,%r4
>         .CALL 
>         bl lo,%r2
>         sub %r4,%r28,%r4
>         ldbx %r28(%r4),%r4   <=== Runtime fault here
>         stb %r4,-120(%r30)
> 
>  
>  This dumps core at the ldbx point because the space check is performed
>  against r28 and not r28+r4.

I note that there is still confusion about space register usage and the
PA hpux runtime.  The ldbx instruction is short for

	ldbx %r28(%sr4,%r4),%r4

The space check is done using %r4 against %sr4.  When the space check
is against %sr4, the two most significant bits select one of %sr4, %sr5,
%sr6, or %sr7 to build the final physical address.  In this runtime model,
%sr0, %sr1, %sr2 and %sr3 are only used in special cases and never
for data loads.

The example is not legal C.  However, it will work under hpux if you
keep the base in the same segment as the data.  Under linux, %sr4,
%sr5, %sr6, and %sr7 are all the same, so you don't need to worry
which register gets selected.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

The use of T_ADAFLAGS stems from this change:

2001-10-08  Zack Weinberg  <zack@codesourcery.com>

        * aclocal.m4 (gcc_AC_PROG_GNAT): New.
	* configure.in: Use it.
	* configure: Regenerated.
	* config/pa/t-linux, config/pa/t-pa, config/pa/t-pa64,
	config/pa/t-pro: Set T_ADAFLAGS, not ADA_CFLAGS.

I suspect using "-mdisable-indexing" dates from a time when indexing
didn't work very well.  This was reworked a year or two ago.

Could you try removing the defines for T_ADAFLAGS and see what happens?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Matthew Wilcox]

On Wed, Apr 24, 2002 at 03:02:59PM -0400, John David Anglin wrote:
> The use of T_ADAFLAGS stems from this change:
> 
> 2001-10-08  Zack Weinberg  <zack@codesourcery.com>
> 
>         * aclocal.m4 (gcc_AC_PROG_GNAT): New.
> 	* configure.in: Use it.
> 	* configure: Regenerated.
> 	* config/pa/t-linux, config/pa/t-pa, config/pa/t-pa64,
> 	config/pa/t-pro: Set T_ADAFLAGS, not ADA_CFLAGS.
> 
> I suspect using "-mdisable-indexing" dates from a time when indexing
> didn't work very well.  This was reworked a year or two ago.
> 
> Could you try removing the defines for T_ADAFLAGS and see what happens?

I did just that when building the host=i386-linux, target=hppa-linux
and that built fine.  I then built build=i386-linux, host=hppa-linux,
target=hppa-linux and did not need to remove -mdisable-indexing.  I'm now
trying to build a native compiler on gsyprf11 with the result of that
... will report back.

-- 
Revolutions do not require corporate support.

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> I'm not terribly familiar with gcc's configure / build system, so I don't
> know who's at fault here.  Should PA be specifying this in X_ADAFLAGS?
> Should Ada not be using T_ADAFLAGS like this?

I believe that this suggestion is correct.  We should be specifying
X_ADAFLAGS in a "x-" file, or files.  It's the host not the
target that's affected by this issue.  The appropriate xmake_file
defines need to be added to config.gcc.  I think we only want to do
this for the hpux, bsd and osf configurations (ie., those that use
the SOM linker and hppa64).  The pro doesn't use space registers.
Linux puts the same value in all the relevant space registers.
Don't know about the memory models for the other elf ports.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[law]

In message <200204252014.g3PKEb5K022548@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > > I'm not terribly familiar with gcc's configure / build system, so I don't
 > > know who's at fault here.  Should PA be specifying this in X_ADAFLAGS?
 > > Should Ada not be using T_ADAFLAGS like this?
 > 
 > I believe that this suggestion is correct.  We should be specifying
 > X_ADAFLAGS in a "x-" file, or files.  It's the host not the
 > target that's affected by this issue.  The appropriate xmake_file
 > defines need to be added to config.gcc.  I think we only want to do
 > this for the hpux, bsd and osf configurations (ie., those that use
 > the SOM linker and hppa64).  The pro doesn't use space registers.
 > Linux puts the same value in all the relevant space registers.
 > Don't know about the memory models for the other elf ports.
Actually OSF puts the same value in all the space registers.  I don't
recall what BSD did.  Not that it matters, I don't believe anyone is
still running the UofU BSD or OSF1 ports.

The few embedded PAs were level 0 implementations -- which don't have
space registers at all.

jeff

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> Actually OSF puts the same value in all the space registers.  I don't
> recall what BSD did.  Not that it matters, I don't believe anyone is
> still running the UofU BSD or OSF1 ports.

Here is a first cut at a patch.  This version is for 3.1.  The 3.2
version doesn't need the patch to ada/Make-lang.in.

This patch adds xmake_file defines for the systems that previously defined
T_ADAFLAGS except for linux.  From  your comments, it appears that
the defines are not needed for osf.  There are some older hpux configurations
that probably should have the define but I doubt anybody has built these
recently because they don't include "pa/t-pa" in their tmake_file list.
We probably should delete everything older than 10.

I would like to install on 3.1 since the build problems were introduced
in the Makefile rework done last fall, creating a regression.

I have successfully bootstrapped with ada under hppa1.1-hp-hpux10.20 and
hppa-linux.  The patch should fix the cross compile problem encountered
by Matthew Wilcox.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-04-26  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* config.gcc (hppa1.1-*-pro*, hppa1.1-*-osf*, hppa1.1-*-rtems*,
	hppa1.0-*-osf*, hppa1.1-*-bsd*, hppa1.1-*-hpux10*, hppa2*-*-hpux10*,
	hppa1.0-*-hpux10*, hppa*64*-*-hpux11*, hppa1.1-*-hpux11*,
	hppa2*-*-hpux11*, hppa1.0-*-hpux11*, hppa*-*-lites*): Define xmake_file.
	* ada/Make-lang.in (ADA_FLAGS_TO_PASS): Don't pass ADA_CFLAGS.
	* pa/t-linux, pa/t-pa, pa/t-pa64, t-pro (T_ADAFLAGS): Delete.
	* pa/x-ada: New file.  Define ADA_CFLAGS.

Index: config.gcc
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.gcc,v
retrieving revision 1.167.2.15
diff -u -3 -p -r1.167.2.15 config.gcc
--- config.gcc	22 Apr 2002 22:26:05 -0000	1.167.2.15
+++ config.gcc	26 Apr 2002 15:31:17 -0000
@@ -885,11 +885,13 @@ hppa1.1-*-pro*)
 	target_cpu_default="(MASK_JUMP_IN_DELAY | MASK_PORTABLE_RUNTIME | MASK_GAS | MASK_NO_SPACE_REGS | MASK_SOFT_FLOAT)"
 	tm_file="${tm_file} pa/pa32-regs.h dbxelf.h elfos.h pa/elf.h pa/pa-pro-end.h libgloss.h"
 	tmake_file="pa/t-bsd pa/t-pro"
+	xmake_file="pa/x-ada"
 	;;
 hppa1.1-*-osf*)
 	target_cpu_default="MASK_PA_11"
 	tm_file="${tm_file} pa/pa32-regs.h pa/som.h pa/pa-osf.h"
 	tmake_file="pa/t-bsd pa/t-pa"
+	xmake_file="pa/x-ada"
 	use_collect2=yes
 	;;
 hppa1.1-*-rtems*)
@@ -897,21 +899,25 @@ hppa1.1-*-rtems*)
 	target_cpu_default="(MASK_JUMP_IN_DELAY | MASK_PORTABLE_RUNTIME | MASK_GAS | MASK_NO_SPACE_REGS | MASK_SOFT_FLOAT)"
 	tm_file="${tm_file} pa/pa32-regs.h dbxelf.h elfos.h pa/elf.h pa/pa-pro-end.h libgloss.h pa/rtems.h rtems.h"
 	tmake_file="pa/t-bsd pa/t-pro"
+	xmake_file="pa/x-ada"
 	;;
 hppa1.0-*-osf*)
 	tm_file="${tm_file} pa/pa32-regs.h pa/som.h pa/pa-osf.h"
 	tmake_file="pa/t-bsd pa/t-pa"
+	xmake_file="pa/x-ada"
 	use_collect2=yes
 	;;
 hppa1.1-*-bsd*)
 	tm_file="${tm_file} pa/pa32-regs.h pa/som.h"
 	target_cpu_default="MASK_PA_11"
 	tmake_file="pa/t-bsd pa/t-pa"
+	xmake_file="pa/x-ada"
 	use_collect2=yes
 	;;
 hppa1.0-*-bsd*)
 	tm_file="${tm_file} pa/pa32-regs.h pa/som.h"
 	tmake_file="pa/t-bsd pa/t-pa"
+	xmake_file="pa/x-ada"
 	use_collect2=yes
 	;;
 hppa1.0-*-hpux7*)
@@ -965,6 +971,7 @@ hppa1.1-*-hpux10* | hppa2*-*-hpux10*)
 	float_format=i128
 	xm_defines=POSIX
 	tmake_file="pa/t-pa pa/t-pa-hpux pa/t-hpux-shlib"
+	xmake_file="pa/x-ada"
 	if test x$enable_threads = x; then
 	    enable_threads=$have_pthread_h
 	fi
@@ -981,6 +988,7 @@ hppa1.0-*-hpux10*)
 	float_format=i128
 	xm_defines=POSIX
 	tmake_file="pa/t-pa pa/t-pa-hpux pa/t-hpux-shlib"
+	xmake_file="pa/x-ada"
 	if test x$enable_threads = x; then
 	    enable_threads=$have_pthread_h
 	fi
@@ -997,6 +1005,7 @@ hppa*64*-*-hpux11*)
 	tm_file="pa/pa64-start.h ${tm_file} pa/pa64-regs.h pa/long_double.h pa/elf.h pa/pa-hpux.h pa/pa-hpux11.h pa/pa-64.h pa/pa64-hpux.h"
 	float_format=i128
 	tmake_file="pa/t-pa64 pa/t-pa-hpux"
+	xmake_file="pa/x-ada"
 	target_cpu_default="(MASK_PA_11|MASK_PA_20|MASK_GAS)"
 
 #	if [ x$enable_threads = x ]; then
@@ -1015,6 +1024,7 @@ hppa1.1-*-hpux11* | hppa2*-*-hpux11*)
 	float_format=i128
 	xm_defines=POSIX
 	tmake_file="pa/t-pa pa/t-pa-hpux pa/t-hpux-shlib"
+	xmake_file="pa/x-ada"
 #	if test x$enable_threads = x; then
 #	    enable_threads=$have_pthread_h
 #	fi
@@ -1030,6 +1040,7 @@ hppa1.0-*-hpux11*)
 	float_format=i128
 	xm_defines=POSIX
 	tmake_file="pa/t-pa pa/t-pa-hpux pa/t-hpux-shlib"
+	xmake_file="pa/x-ada"
 #	if test x$enable_threads = x; then
 #	    enable_threads=$have_pthread_h
 #	fi
@@ -1074,6 +1085,7 @@ hppa*-*-lites*)
 	tm_file="${tm_file} pa/pa32-regs.h dbxelf.h elfos.h pa/elf.h"
 	target_cpu_default="MASK_PA_11"
 	tmake_file="pa/t-bsd pa/t-pa"
+	xmake_file="pa/x-ada"
 	use_collect2=yes
 	;;
 hppa*-*-mpeix*)
Index: ada/Make-lang.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ada/Make-lang.in,v
retrieving revision 1.7
diff -u -3 -p -r1.7 Make-lang.in
--- ada/Make-lang.in	29 Nov 2001 16:50:10 -0000	1.7
+++ ada/Make-lang.in	26 Apr 2002 15:31:17 -0000
@@ -55,7 +55,6 @@ ADA_RTL_OBJ_DIR = $(libsubdir)/adalib
 THREAD_KIND=native
 GNATBIND = gnatbind
 ADA_FLAGS_TO_PASS = \
-	"ADA_CFLAGS=$(CFLAGS)" \
 	"ADA_FOR_BUILD=$(ADA_FOR_BUILD)" \
 	"ADA_INCLUDE_DIR=$(ADA_INCLUDE_DIR)" \
 	"ADA_RTL_OBJ_DIR=$(ADA_RTL_OBJ_DIR)" \
Index: config/pa/t-linux
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/t-linux,v
retrieving revision 1.5
diff -u -3 -p -r1.5 t-linux
--- config/pa/t-linux	8 Oct 2001 17:58:30 -0000	1.5
+++ config/pa/t-linux	26 Apr 2002 15:31:17 -0000
@@ -14,5 +14,3 @@ CRTSTUFF_T_CFLAGS_S = -fPIC
 
 # Compile libgcc2.a as PIC.
 TARGET_LIBGCC2_CFLAGS = -fPIC -DELF=1 -DLINUX=1
-
-T_ADAFLAGS=-mdisable-indexing
Index: config/pa/t-pa
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/t-pa,v
retrieving revision 1.11
diff -u -3 -p -r1.11 t-pa
--- config/pa/t-pa	16 Feb 2002 22:30:35 -0000	1.11
+++ config/pa/t-pa	26 Apr 2002 15:31:17 -0000
@@ -1,4 +1,3 @@
-T_ADAFLAGS=-mdisable-indexing
 LIB2FUNCS_EXTRA=lib2funcs.asm quadlib.c
 
 lib2funcs.asm: $(srcdir)/config/pa/lib2funcs.asm
Index: config/pa/t-pa64
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/t-pa64,v
retrieving revision 1.4
diff -u -3 -p -r1.4 t-pa64
--- config/pa/t-pa64	8 Oct 2001 17:58:30 -0000	1.4
+++ config/pa/t-pa64	26 Apr 2002 15:31:17 -0000
@@ -2,7 +2,6 @@ LIB1ASMFUNCS =  _divI _divU _remI _remU 
 LIB1ASMSRC = pa/milli64.S
 TARGET_LIBGCC2_CFLAGS = -fPIC -Dpa64=1 -DELF=1
 
-T_ADAFLAGS=-mdisable-indexing
 LIB2FUNCS_EXTRA=quadlib.c
 
 # We'll need this once .init sections are enabled on PA64.
Index: config/pa/t-pro
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/t-pro,v
retrieving revision 1.8
diff -u -3 -p -r1.8 t-pro
--- config/pa/t-pro	16 Feb 2002 22:30:35 -0000	1.8
+++ config/pa/t-pro	26 Apr 2002 15:31:17 -0000
@@ -1,5 +1,3 @@
-T_ADAFLAGS=-mdisable-indexing
-
 LIB2FUNCS_EXTRA=lib2funcs.asm 
 
 # We want fine grained libraries, so use the new code to build the
--- /dev/null	Fri Apr 26 09:36:29 2002
+++ config/pa/x-ada	Fri Apr 26 09:56:45 2002
@@ -0,0 +1,4 @@
+# The ada virtual array implementation requires that indexing be disabled on
+# hosts such as hpux that use a segmented memory architecture.  Both the c
+# and ada files need to be compiled with this option for correct operation.
+ADA_CFLAGS=-mdisable-indexing

Re: PA specifies invalid T_ADAFLAGS

[Arnaud Charlet]

> I suspect using "-mdisable-indexing" dates from a time when indexing
> didn't work very well.  This was reworked a year or two ago.

No, disable-indexing is still needed for proper behavior of GNAT on PA
(otherwise GNAT will behave wrongly in some subtle ways), so removing it is
not a viable option.

Arno

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> > I suspect using "-mdisable-indexing" dates from a time when indexing
> > didn't work very well.  This was reworked a year or two ago.
> 
> No, disable-indexing is still needed for proper behavior of GNAT on PA
> (otherwise GNAT will behave wrongly in some subtle ways), so removing it is
> not a viable option.

Is this a bug in the PA backend?  Without fixing the problem, it will not
be possible to correctly build GNAT under hppa-linux, except by starting
with a working hpux port.  It's been some time since I tried it but
starting from the last binary release for hpux was very difficult because
there are major problems building the current source with 2.8.1x.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[Arnaud Charlet]

> Is this a bug in the PA backend?  Without fixing the problem, it will not

I don't remember the details, but I believe this is not a bug, but
is related to some code in GNAT, and to the PA architecture itself.

> be possible to correctly build GNAT under hppa-linux, except by starting
> with a working hpux port.  It's been some time since I tried it but
> starting from the last binary release for hpux was very difficult because
> there are major problems building the current source with 2.8.1x.

We do it everyday with no trouble. You need to start with a recent enough
version of GNAT (3.13 or better, 3.14). So if you're using an earlier
version (e.g 3.12), then first build 3.13 from 3.12, and possibly
3.14 from 3.13.

Arno

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

> We do it everyday with no trouble. You need to start with a recent enough
> version of GNAT (3.13 or better, 3.14). So if you're using an earlier
> version (e.g 3.12), then first build 3.13 from 3.12, and possibly
> 3.14 from 3.13.

That's exactly what I did.  This is what happens:

make[3]: Entering directory `/xxx/gnu/gcc-3.1/objdir/gcc/ada'
stage2/xgcc -Bstage2/ -B/opt/gnu/hppa1.1-hp-hpux10.20/bin/ -c -g -O2  -mdisable-
indexing -W -Wall -gnatpg -gnata -I- -I. -I../../../gcc/gcc/ada ../../../gcc/gcc
/ada/ada.ads
+===========================GNAT BUG DETECTED==============================+
| 5.00w (20010924) (hppa1.1-hp-hpux10.20) Storage_Error stack overflow or errone
ous memory access|
| Error detected at ../../../gcc/gcc/ada/system.ads:158:5                  |
| Please submit bug report by email to report@gnat.com.                    |
| Use a subject line meaningful to you and us to track the bug.            |
| (include your customer number #nnn in the subject line).                 |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
| (use plain ASCII or MIME attachment, or FTP to your customer directory). |
| See README.GNATPRO for full info on procedure for submitting bugs.       |
+==========================================================================+

Please include these source files with error report


compilation abandoned

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[law]

In message <200204241903.g3OJ30JL003697@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > The use of T_ADAFLAGS stems from this change:
 > 
 > 2001-10-08  Zack Weinberg  <zack@codesourcery.com>
 > 
 >         * aclocal.m4 (gcc_AC_PROG_GNAT): New.
 > 	* configure.in: Use it.
 > 	* configure: Regenerated.
 > 	* config/pa/t-linux, config/pa/t-pa, config/pa/t-pa64,
 > 	config/pa/t-pro: Set T_ADAFLAGS, not ADA_CFLAGS.
 > 
 > I suspect using "-mdisable-indexing" dates from a time when indexing
 > didn't work very well.  This was reworked a year or two ago.
No.  The semantics of Ada don't play well with the funky implicit space 
register
selection done on PAs.  -mdisable-indexing is really needed for Ada.

jeff

Re: PA specifies invalid T_ADAFLAGS

[John David Anglin]

>  > I suspect using "-mdisable-indexing" dates from a time when indexing
>  > didn't work very well.  This was reworked a year or two ago.
> No.  The semantics of Ada don't play well with the funky implicit space 
> register
> selection done on PAs.  -mdisable-indexing is really needed for Ada.

Yes.  I am testing a patch to correct the configuration regression
introduced last fall.  I had my first successful build of ada last
night under hpux with gcc 3.1.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PA specifies invalid T_ADAFLAGS

[law]

In message <200204261635.g3QGZ7bW026408@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > >  > I suspect using "-mdisable-indexing" dates from a time when indexing
 > >  > didn't work very well.  This was reworked a year or two ago.
 > > No.  The semantics of Ada don't play well with the funky implicit space 
 > > register
 > > selection done on PAs.  -mdisable-indexing is really needed for Ada.
 > 
 > Yes.  I am testing a patch to correct the configuration regression
 > introduced last fall.  I had my first successful build of ada last
 > night under hpux with gcc 3.1.
Actually, I forgot, there is a way we could get rid of -mdisable-indexing
completely (without totally removing indexing :-)

Basically we would only do indexing when we can prove that we have a 
"pure pointer"; where "pure pointer" means that we have a pointer that
we know points to a location within its object.  We largely have this
with REGNO_POINTER_FLAG, but if I recall properly it gets set sometimes when
it shouldn't.  We'd also need a reasonable way to propagage REGNO_POINTER_FLAG
to other pointer references (the code in regclass is painfully inadequate).

Anyway, once we have "pure pointers" identified & marked, then we only 
allow indexing on the pure pointer.

Moving REGNO_POINTER_FLAG out of its separate array and into the register RTL
structure itself was one of the key first steps (so that we can safely examine
it during assembly output).

The next step would be to review generation of REGNO_POINTER_FLAG to ensure
it's only generated for pure pointers.  Then we can twiddle the backend to 
use it, then we can write a pass to propagage REGNO_POINTER_FLAG so that it's
more aggressively set.

jeff

PA specifies invalid T_ADAFLAGS

[Matthew Wilcox]

I'm trying to bootstrap an Ada hppa-linux crosscompiler.  Here's my
latest problem, which doesn't appear to be PEBCAK this time :-)

Downloaded the 20020423 3.1 snapshot.  Made bootstrap (on i386-linux),
installed.  Configured with:

../gcc-3.1-20020423/configure --prefix=/opt/palinux --target=hppa-linux --enable-languages=c,ada --disable-shared --disable-nls |tee configure.out

Dies when it tries to compile:

gcc -c -g -O2  -mdisable-indexing -W -Wall -gnatpg -gnata -I- -I. -I../../../gcc-3.1-20020423/gcc/ada ../../../gcc-3.1-20020423/gcc/ada/ada.ads

since gcc (native i386 compiler) doesn't grok -mdisable-indexing which
is an HPPA specific option.  This is picked up from T_ADAFLAGS, which
is defined in:

gcc/config/pa/t-linux
gcc/config/pa/t-pa
gcc/config/pa/t-pa64
gcc/config/pa/t-pro

I'm not terribly familiar with gcc's configure / build system, so I don't
know who's at fault here.  Should PA be specifying this in X_ADAFLAGS?
Should Ada not be using T_ADAFLAGS like this?

-- 
Revolutions do not require corporate support.