Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Richard Kenner]

    My guess is that the r symbol is not flagged as local when
    there's an address clause and an Import pragma, so it
    might be a gigi problem.

Yup.  Indeed when I first saw this, I suspected something in that area.
I had to make a change in the way that case was handled to avoid an
inconsistent setting of flags on decls.

I not 100% sure I understand the exact Ada semantics there and need to do
a little investigation of what that pragma Import is supposed to mean
in the presence of the address clause.  In other place I saw this, it
seemed to be being uses precisely to define the external name.

Thanks for cutting this down to a tiny test case.  It indeed saved me the
time of doign that.

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Laurent GUERBY]

On Sat, 2004-09-18 at 12:49, Richard Kenner wrote:
> I not 100% sure I understand the exact Ada semantics there and need to do
> a little investigation of what that pragma Import is supposed to mean
> in the presence of the address clause.  In other place I saw this, it
> seemed to be being uses precisely to define the external name.

It is mentionned in the annotated version 13.3.12.c
<<
13.3 {Operational and Representation Attributes} [Representation
Attributes]
[...]
    12    {specifiable (of Address for stand-alone objects and for program units)
               [partial]} {Address clause} Address may be specified for
              stand-alone objects and for program units via an
              attribute_definition_clause.
[...]
    12.c  If the Address of an object is specified, any explicit or implicit
          initialization takes place as usual, unless a pragma Import is also
          specified for the object (in which case any necessary initialization
          is presumably done in the foreign language).
>>

Import is added here only to suppress the potential Ada language defined
initialization that would otherwise clobber memory at
the given address, not as a mean to specify an external symbol.

If an object has an address clause, no symbol need to be generated for
it (at least I don't see such a case).

Laurent

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Robert Dewar]

Richard Kenner wrote:

>     My guess is that the r symbol is not flagged as local when
>     there's an address clause and an Import pragma, so it
>     might be a gigi problem.
> 
> Yup.  Indeed when I first saw this, I suspected something in that area.
> I had to make a change in the way that case was handled to avoid an
> inconsistent setting of flags on decls.
> 
> I not 100% sure I understand the exact Ada semantics there and need to do
> a little investigation of what that pragma Import is supposed to mean
> in the presence of the address clause.  In other place I saw this, it
> seemed to be being uses precisely to define the external name.

The only meaning of the pragma Import when there is an address
clause is to suppress any implicit initialization, which is
something the front end takes care of, otherwise it should
be completely ignored. I guess actually the front end could
do this.
> 
> Thanks for cutting this down to a tiny test case.  It indeed saved me the
> time of doign that.

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Robert Dewar]

Laurent GUERBY wrote:
> On Fri, 2004-09-17 at 23:24, Robert Dewar wrote:
> 
>>Either or both, but I don't want to process any bug report
>>without proper tracking and filing! If it is a bug, then
>>we can properly track the discussion and fix.
> 
> 
> It's in GCC bugzilla, PR17540
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17540

OK, thanks for filing this. This is indeed a bug. The
problem is that pragma Import should not generate an
external reference if there is also an address clause.
That is true in earlier versions (this is not a front
end problem, but rather some change in the back end).
We will investigate ASAP.
> 
> Laurent

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Laurent GUERBY]

On Fri, 2004-09-17 at 23:24, Robert Dewar wrote:
> Either or both, but I don't want to process any bug report
> without proper tracking and filing! If it is a bug, then
> we can properly track the discussion and fix.

It's in GCC bugzilla, PR17540
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17540

Laurent

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Robert Dewar]

Laurent GUERBY wrote:

> On Fri, 2004-09-17 at 22:39, Robert Dewar wrote:
> 
>>This does not look like a bug to me, but in any case, surely
>>the proper procedure is to file a bug report!
> 
> 
> Well technically it's a regression shown by the testsuite
> in CVS, are you suggesting I file a PR in GCC bugzilla
> or to ACT?

Either or both, but I don't want to process any bug report
without proper tracking and filing! If it is a bug, then
we can properly track the discussion and fix.

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Laurent GUERBY]

On Fri, 2004-09-17 at 22:39, Robert Dewar wrote:
> This does not look like a bug to me, but in any case, surely
> the proper procedure is to file a bug report!

Well technically it's a regression shown by the testsuite
in CVS, are you suggesting I file a PR in GCC bugzilla
or to ACT?

Very similar code is present in GNAT sources and is causing the ACATS
failures, see s-fatgen.adb, function Valid:

      XA : constant System.Address := To_Address (Float_Access (X));

      R : Float_Rep;
      pragma Import (Ada, R);
      for R'Address use XA;
      --  R is a view of the input floating-point parameter. Note that we
      --  must avoid copying the actual bits of this parameter in float
      --  form (since it may be a signalling NaN.

(I believe it's your code BTW, and the comment misses a closing parenthesis :) 

Since it's a generic, it might lead to generated code
as I've writen in my example if multiple instanciation
are present. Such a construct has worked for all versions of GNAT, but might depend
on some specific code generation behaviour that is no longer present.

Laurent

Re: Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Robert Dewar]

This does not look like a bug to me, but in any case, surely
the proper procedure is to file a bug report!

Ada system.fat_lflt.fat_long_float.scaling problem analysis

[Laurent GUERBY]

On Mon, 2004-09-13 at 23:24, Richard Kenner wrote:
>     s-fatlfl.o(.bss+0x0): In function `system.fat_lflt.fat_long_float.scaling':
>     /home/guerby/work/gcc/build/build-20040913T200122/gcc/ada/rts/s-fatgen.adb:540: multiple definition of `r'
>     s-fatflt.o(.bss+0x0):/home/guerby/work/gcc/build/build-20040913T200122/gcc/ada/rts/s-fatgen.adb:540: first defined here
> 
> I'm assuming this is a problem in the Ada front end, though I haven't
> gotten a chance to look at it yet.

I looked at the expanded code for s-fatflt.ads and found the "r":

xa : constant system.system__address := 
           system__fat_flt__fat_float__valid__to_addressGP22755__target!
           (system__fat_flt__fat_float__valid__float_access(x));
r : system__fat_flt__fat_float__valid__float_rep;
        pragma import (ada, r);
        for r'address use xa;
        freeze r []

The following reduced test case shows the problem:

procedure P is
   procedure P1 (X : access Integer) is
      R : Integer;
      pragma Import (Ada, R);
      for R'Address use X.all'Address;
   begin
      null;
   end P1;
   procedure P2 (X : access Integer) is
      R : Integer;
      pragma Import (Ada, R);
      for R'Address use X.all'Address;
   begin
      null;
   end P2;
begin
   null;
end P;

$ /home/guerby/work/gcc/build/build-20040917T192720/gcc/xgcc -B/home/guerby/work/gcc/build/build-20040917T192720/gcc/ -c p.adb
/tmp/ccK6lePn.s: Assembler messages:
/tmp/ccK6lePn.s:13: Error: symbol `r' is already defined

My guess is that the r symbol is not flagged as local when
there's an address clause and an Import pragma, so it
might be a gigi problem.

Hope this helps,

Laurent