comp.lang.ada
 help / color / mirror / Atom feed
* Please Help: Sun Ada Bug
@ 1993-09-14  1:10 Byron Darrah
  0 siblings, 0 replies; 8+ messages in thread
From: Byron Darrah @ 1993-09-14  1:10 UTC (permalink / raw)


     Hello, there, Ada  community!

     I am getting an internal error from a Sun Ada 1.0
compiler that reads:

     internal: assertion error at file lreg.c line xxx
cg_ret: 1

(I _think_ xxx is 174, but I don't remember for sure.)  I looked through
the release notes and found no reference to assertion errors in lreg.c.
If anyone can provide information that may be related to this bug, I would
greatly appreciate it.

Thanks in advance,
Byron Darrah

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-15 17:11 Terry J. Westley
  0 siblings, 0 replies; 8+ messages in thread
From: Terry J. Westley @ 1993-09-15 17:11 UTC (permalink / raw)


In article <37106@hacgate.SCG.HAC.COM> bdarr@atr-16 (Byron Darrah) writes:
>
>     I am getting an internal error from a Sun Ada 1.0
>compiler that reads:
>
>     internal: assertion error at file lreg.c line xxx
>cg_ret: 1
>
>Thanks in advance,
>Byron Darrah

We get this type of error from Sun Ada (aka VADS) occasionally.  It's
tough to comment on your particular error without the source code.
Generally, it means that you have illeagal code that the compiler
couldn't handle.  Clearly, this is a defect in the compiler.  It should
emit an error message related to YOUR code, not the compiler's.

Go back to your code and inspect what you just added before you got
the error.  Look especially for interactions between language features.

On the other hand, we got this error most recently when compiling on a
SPARCserver 10 and it went away when the file was recompiled without
change on a 4/490!  But, this has been the exception rather than the rule.
-- 
Terry J. Westley, Principal Computer Scientist
Calspan Corporation, P.O. Box 400, Buffalo, NY 14225
westley@calspan.com
Let's hear it for smart mailers that cut off long signa

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-15 19:44 B uffy Hyler
  0 siblings, 0 replies; 8+ messages in thread
From: B uffy Hyler @ 1993-09-15 19:44 UTC (permalink / raw)


In article <37106@hacgate.SCG.HAC.COM> bdarr@atr-16 (Byron Darrah) writes:
>
>     I am getting an internal error from a Sun Ada 1.0
>compiler that reads:
>
>     internal: assertion error at file lreg.c line xxx
>cg_ret: 1
>
>Thanks in advance,
>Byron Darrah

Another reason that we have seen this error is that there isn't
enough memory to compile the unit on the given machine.  Many
times Sun Ada will relate this fact, and other times we get these
internal errors.  If it is possible, try recompiling on a machine
with larger memory, or offload as many applications as you can.



---
----------------------------------------------------------------------
Buffy Hyler (hyler@ast.saic.com)
SAIC, Campus Point
San Diego, California
----------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-15 21:34 Dan Rittersdorf
  0 siblings, 0 replies; 8+ messages in thread
From: Dan Rittersdorf @ 1993-09-15 21:34 UTC (permalink / raw)


In article <37106@hacgate.SCG.HAC.COM> bdarr@atr-16 (Byron Darrah) writes:
>
>     I am getting an internal error from a Sun Ada 1.0
>compiler that reads:
>
>     internal: assertion error at file lreg.c line xxx
>cg_ret: 1
>
>Thanks in advance,
>Byron Darrah

   Any time you see "internal: assertion error ..." or 
   "internal: case error ..." in a Verdix based compiler, you've detected
   a compiler error.  Actually, the compiler has detected an error
   within itself.  In this case, lreg.c is in the code generator (cg_ret=1).

   Report it to the vendor, giving more detail, such as the actual line
   number (it's significant, so they can locate *which* assertion
   in lreg.c has gone bonkers.  They may be able to give you a hint about
   what your program did special to cause the compiler to assert.
   for example, if you had a LOT of initializations, and used up all
   the logical registers they had allowed for or something.

   There are a lot of assertions in the compiler, and each has a different 
   possible cause.  Only the vendor (or Verdix) who has the source can tell
   you which assertion, what it was asserting, and what you could do to work
   around it till you get a fix.

   It isn't much, but be thankful that the compiler is self checking -- the
   alternative could well have been:

      bus error: core dumped

   if the assertion hadn't been written.

-- 
-danr
______________________________________________________________________________
  Dan Rittersdorf                             danr@ada1.ssd.csd.harris.com
  Harris Corporation, Computer Systems Division, Fort Lauderdale, FL 33309
  Michigan Address:                178 Washington Street, Sparta, MI 49345
______________________________________________________________________________

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-16 14:44 Esther Lumsdon
  0 siblings, 0 replies; 8+ messages in thread
From: Esther Lumsdon @ 1993-09-16 14:44 UTC (permalink / raw)


From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Date: Tue, 14 Sep 93 11:37:58 EDT
To: bdarr@atr-16
Subject: Re: Please Help: Sun Ada Bug
Newsgroups: comp.lang.ada
References: <37106@hacgate.SCG.HAC.COM>

In comp.lang.ada you write:
>     I am getting an internal error from a Sun Ada 1.0
>compiler that reads:

>     internal: assertion error at file lreg.c line xxx
>cg_ret: 1

>(I _think_ xxx is 174, but I don't remember for sure.)  I looked through
>the release notes and found no reference to assertion errors in lreg.c.
>If anyone can provide information that may be related to this bug, I would
>greatly appreciate it.
>Thanks in advance,
>Byron Darrah


The deficiency report below sounds like your problem.  You have not reported
a precise description, so I can't be sure.  I advise you to call the Verdix 
Support hotline and report this with a more precise description.  Or dial
the Verdix Support BBS at 703-318-5898 if you are in North America.  I beleive 
this is fixed in SunAda1.1(i).
========================================================================----=
DR Number: 1487 
Title: internal: assertion error at file lreg.c, line 174
========================================================================---+=
    Workaround by:                  Date:
None.  integer'last -1 works ok, though.
========================================================================-+--=
    Abstract
When a variant record contains a case statement alternative where a choice is
integer'last, as follows:

   type my_rec (Dscrmnt : integer) is 
   record        
      case Dscrmnt is
         when integer'last =>   
            a: integer;        
         when others => 
            null;
       end case;
   end record;

an internal assertion error at file lreg.c, line 174 is produced by the code
generator.
========================================================================---+=
-- 
-- Esther Lumsdon, not speaking for Verdix.   esther@verdix.com
"It's time to cut bait and talk turkey.  It takes 2 snakes to cross a
puddle. You have to bale hay while the tractor is warm."
  ---- either H. Ross Perot or Dave Barry

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-16 16:59 Stef Van Vlierberghe
  0 siblings, 0 replies; 8+ messages in thread
From: Stef Van Vlierberghe @ 1993-09-16 16:59 UTC (permalink / raw)


In article <37106@hacgate.SCG.HAC.COM> bdarr@atr-16 (Byron Darrah) writes:
>     I am getting an internal error from a Sun Ada 1.0
>compiler that reads:
>
>     internal: assertion error at file lreg.c line xxx
>cg_ret: 1

I once had something similar with Verdix on HP700, and it had an
easy workaround :

internal: assertion error at file il_load.c, line 246

If you compile :

package Operator is
   type T is private;
   Name_Max_Length : constant := 12;
   type Name_T is private;
   function NONE return NAME_T;
private
   type T is record
      Name : Name_T := NONE;
   end record;

   type Name_T is new String ( 1 .. Name_max_length );
end Operator;

Putting the complete declaration of Name_t before the complete declaration of
T (a better place for it anyway), solves the problem.

Perhaps you problem is similar ?
-- 
Stef VAN VLIERBERGHE            Eurocontrol - Central Flow Management Unit
stef@cfmu.eurocontrol.be        Avenue des Arts 19H
Tel: +32 2 729 33 42            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-17 14:24 Wes Groleau x1240 C73-8
  0 siblings, 0 replies; 8+ messages in thread
From: Wes Groleau x1240 C73-8 @ 1993-09-17 14:24 UTC (permalink / raw)


In article <1993Sep15.171145.23064@calspan.com> westley@calspan.com (Terry J. W
estley) writes:
>In article <37106@hacgate.SCG.HAC.COM> bdarr@atr-16 (Byron Darrah) writes:
>>     internal: assertion error at file lreg.c line xxx
>>cg_ret: 1
>Generally, it means that you have illeagal code that the compiler
>couldn't handle.  Clearly, this is a defect in the compiler.  It should
>emit an error message related to YOUR code, not the compiler's.

More often, it means an legal construct that triggers a bug.
If a previous version of the same file compiled, check what's different.
Then experiment with different ways of accomplishing whatever the change
was put in for.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Please Help: Sun Ada Bug
@ 1993-09-20 18:26 Byron Darrah
  0 siblings, 0 replies; 8+ messages in thread
From: Byron Darrah @ 1993-09-20 18:26 UTC (permalink / raw)


     Thank you for all of the responses, everyone.

     We were able to compile the same source under DEC's Ada, so
the sources are most likely legal Ada.  There was also plenty of
Swap space left when the error occurred, so it is doubtful that the
compiler  used up all available memory; Though we ARE talking about a
VERY big source file (automatically generated by a tool, so that there
would be a lot of effort required to try to pinpoint which line
caused the error, if such a thing even makes sense) so perhaps internal
allocations for this or that do underestimate needed quantities.

     In any case, we are now going to seek help from Verdix.  BTW: The
line in lreg.c was indeed "174", though we are not using variant records.

     Also:  Does anyone have any suggestions for alternative 
Ada compilers on the Sun?  (SPARC, SunOS 4.1.x, and we are not planning to
upgrade to Solaris 2.x in the near future).

     -Byron Darrah
     bdarr@atr-2s.hac.com
 

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1993-09-20 18:26 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-09-20 18:26 Please Help: Sun Ada Bug Byron Darrah
  -- strict thread matches above, loose matches on Subject: below --
1993-09-17 14:24 Wes Groleau x1240 C73-8
1993-09-16 16:59 Stef Van Vlierberghe
1993-09-16 14:44 Esther Lumsdon
1993-09-15 21:34 Dan Rittersdorf
1993-09-15 19:44 B uffy Hyler
1993-09-15 17:11 Terry J. Westley
1993-09-14  1:10 Byron Darrah

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox