* Elaboration in GNAT @ 2001-11-28 12:34 Frode Tenneboe 2001-11-28 18:13 ` Mark Johnson ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Frode Tenneboe @ 2001-11-28 12:34 UTC (permalink / raw) Using -gnatwa I get some elaboration issues with some legacy code in GNAT. One of these are: foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" The problem is that this crops up everywhere which I asume is because the elboration of package bar is not very healthy. The package in question uses Ada.Calendar, however there must be some code in one (or more) of the dependencies in the body of bar which causes this. A manual inspection of this code is not done over night. Is there a way of getting the information above a bit more verbose? -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-28 12:34 Elaboration in GNAT Frode Tenneboe @ 2001-11-28 18:13 ` Mark Johnson 2001-11-29 3:44 ` Robert Dewar 2001-11-28 19:25 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 1 reply; 22+ messages in thread From: Mark Johnson @ 2001-11-28 18:13 UTC (permalink / raw) Frode Tenneboe wrote: > Using -gnatwa I get some elaboration issues with some legacy code in GNAT. > One of these are: > > foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error > foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" > > The problem is that this crops up everywhere which I asume is because > the elboration of package bar is not very healthy. > > The package in question uses Ada.Calendar, however there must be some > code in one (or more) of the dependencies in the body of bar which > causes this. A manual inspection of this code is not done over night. > > Is there a way of getting the information above a bit more verbose? Not that I am aware of. I had some lengthy discussions with Robert Dewar about this particular issue. The warning basically says that elaboration code in the current package depends upon another package. To be safe - elaborate the other package (and all packages it depends upon) prior to elaboration of the current package. I agree with the reasoning behind this so I have this warning turned on all compiles we do as well. Since I also demand warning free software in our facility, my "solution" is to add pragma Elaborate_All(bar); in every place the warning is issued. That way if we have any mutual dependencies [we haven't] they become compiler errors. This is a quick solution and doesn't require any extensive analysis to put into place. Robert of course may give you slightly different suggestions. One that I tend to ignore is to not use "gnatwa", but to specify exactly which warnings you want and don't want. I have found over the last several months that added warnings from gnatwa are beneficial and I'm sticking with it. --Mark ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-28 18:13 ` Mark Johnson @ 2001-11-29 3:44 ` Robert Dewar 2001-11-29 13:30 ` Stephen Leake 0 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 2001-11-29 3:44 UTC (permalink / raw) Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3C052930.4FE65C5D@Raytheon.com>... > Robert of course may give you slightly different > suggestions. One that I tend > to ignore is to not use "gnatwa", but to specify exactly > which warnings you > want and don't want. I have found over the last several > months that added > warnings from gnatwa are beneficial and I'm sticking with > it. > > --Mark That's fine, but you have to be prepared for new warnings to pop up without warning, since we often add new warnings! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-29 3:44 ` Robert Dewar @ 2001-11-29 13:30 ` Stephen Leake 0 siblings, 0 replies; 22+ messages in thread From: Stephen Leake @ 2001-11-29 13:30 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3C052930.4FE65C5D@Raytheon.com>... > > Robert of course may give you slightly different > > suggestions. One that I tend > > to ignore is to not use "gnatwa", but to specify exactly > > which warnings you > > want and don't want. I have found over the last several > > months that added > > warnings from gnatwa are beneficial and I'm sticking with > > it. > > > > --Mark > > > That's fine, but you have to be prepared for new warnings > to pop up without warning, since we often add new warnings! This is true. However, they usually indicate true defects in my code. I agree with Mark; my code gets better with each release of GNAT! Keep up the good work, Robert :). -- -- Stephe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-28 12:34 Elaboration in GNAT Frode Tenneboe 2001-11-28 18:13 ` Mark Johnson @ 2001-11-28 19:25 ` Robert Dewar 2002-01-04 13:21 ` Frode Tenneboe 2001-11-29 13:13 ` Stephen Leake 2001-11-29 13:17 ` Stephen Leake 3 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 2001-11-28 19:25 UTC (permalink / raw) Frode Tenneboe <ft@alne.edh.ericsson.se> wrote in message news:<1006952193.650930@edh3>... > Using -gnatwa I get some elaboration issues with some legacy code in GNAT. > One of these are: > > foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error > foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" > Is there a way of getting the information above a bit > more verbose? If this message is not intelligible, I recommend reading the entire chapter on elaboration issues in the users guide. Elaboration is certainly a tricky issue, and generally you should not turn on -gnatwl unless you know what you are doing. We certainly find that helping customers work through elaboration issues is a significant part of our support effort, which is why we implemented the static model of elaboration to try to ameliorate this in the future. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-28 19:25 ` Robert Dewar @ 2002-01-04 13:21 ` Frode Tenneboe 2002-01-04 15:07 ` Matthew Heaney 2002-01-05 0:40 ` Robert Dewar 0 siblings, 2 replies; 22+ messages in thread From: Frode Tenneboe @ 2002-01-04 13:21 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=ISO, Size: 2651 bytes --] Robert Dewar <dewar@gnat.com> wrote: > Frode Tenneboe wrote: >> Using -gnatwa I get some elaboration issues with some legacy code in GNAT. >> One of these are: >> >> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error >> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" > If this message is not intelligible, I recommend reading > the entire chapter on elaboration issues in the users > guide. Elaboration is certainly a tricky issue, and > generally you should not turn on -gnatwl unless you know > what you are doing. I like to _think_ I know what I'm doing. :) However, elaboration is tricky and I have read the relevant chapter several times. Every time I read it I discover new neuances. I can only recomend everybody to read this chapter several times. The code is legacy code with complex dependencies and need some time to grow..... The warning is removed by adding (in the above example): pragma Elaborate_Body(bar) in bar.ads. However, I'm still not totatlly sure if this is the "correct" approach. But at least it makes more sense than adding pragma Elaborate_All in all clients using package bar. > We certainly find that helping customers work through > elaboration issues is a significant part of our support > effort, which is why we implemented the static model > of elaboration to try to ameliorate this in the future. I think the elaboration performed by GNAT is very good, especially considered when I tried to hand-elaborate a particular nasty piece of software it simply stops working. Even removing certain childs from packages which were not used there breaks the implementation. However, I find the above warning a bit misplaced in my case. I would have preferred: bar.adb:69:04: warning: instantiation of "Client" may raise Program_Error bar.adb:69:04: warning: missing pragma Elaborate_Body in spec or: bar.adb:69:04: warning: call to "Client" may raise Program_Error bar.adb:69:04: warning: missing pragma Elaborate_Body in spec I don't know if the compiler is able to detect this, but it would be nicer. I'm also unsure if this is always true, but alternatively: foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" or foo.adb:69:04: warning: missing pragma Elaborate_Body in "bar" -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-04 13:21 ` Frode Tenneboe @ 2002-01-04 15:07 ` Matthew Heaney 2002-01-05 0:43 ` Robert Dewar 2002-01-05 0:50 ` Robert Dewar 2002-01-05 0:40 ` Robert Dewar 1 sibling, 2 replies; 22+ messages in thread From: Matthew Heaney @ 2002-01-04 15:07 UTC (permalink / raw) "Frode Tenneboe" <ft@edh.ericsson.se> wrote in message news:1010151875.216658@edh3... > Robert Dewar <dewar@gnat.com> wrote: > > If this message is not intelligible, I recommend reading > > the entire chapter on elaboration issues in the users > > guide. Elaboration is certainly a tricky issue, and > > generally you should not turn on -gnatwl unless you know > > what you are doing. I'm not sure I agree with Robert's advice here. I always use -gnatwl. If you don't know what you're doing, then the best way to learn is to write some programs and submit them to the compiler! > The code is legacy code with complex dependencies and need some time > to grow..... The warning is removed by adding (in the above example): > > pragma Elaborate_Body(bar) > > in bar.ads. > > However, I'm still not totatlly sure if this is the "correct" > approach. But at least it makes more sense than adding > pragma Elaborate_All in all clients using package bar. My advice is to always use a categorization pragma in a package declaration, and to use the strongest categorization possible, ie 1) pragma Pure; 2) pragma Preelaborate; 3) pragma Elaborate_Body; The one time you cannot use a categorization pragma (say, Elaborate_Body) is when a package withs its own children, which means a client will have to use pragma Elaborate_All (if it needs to call operations in that package during its own elaboration). However, I prefer to restructure the parent package by moving the child-dependent stuff into a new child, and then have that new child with its siblings. That makes it possible to say pragma Elaborate_Body in the parent. This comes up with you declare a "protocol class" (an abstract tagged type) with a constructor to return a concrete type in the class: package P is pragma Elaborate_Body; --illegal type T is abstract tagged limited null record; procedure Op (O : access T) is abstract; type T_Class_Access is access all T'Class; function New_T (S: String) return T_Class_Access; end; package P.C is type NT is new T with null record; procedure Op (O : access NT); end; with P.C; package body P is function New_T (S : String) return T_Class_Acceess is begin return new P.C.NT; end; end; You can't use pragma Elaborate_Body in P, because the body of P withs its own child P.C. But the workaround is easy enough: simply declare the constructor as a child of P: function P.New_T (S : String) return T_Class_Access; with P.C; function P.New_T (S : String) return T_Class_Access is begin return new P.C.NT; end; Now you can use pragma Elaborate_Body for P, because the body of P no longer withs any of its children. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-04 15:07 ` Matthew Heaney @ 2002-01-05 0:43 ` Robert Dewar 2002-01-05 0:50 ` Robert Dewar 1 sibling, 0 replies; 22+ messages in thread From: Robert Dewar @ 2002-01-05 0:43 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:<u3bh1tiuppk9c7@corp.supernews.com>... > The one time you cannot use a categorization pragma (say, > Elaborate_Body) is > when a package withs its own children, which means a > client will have to use > pragma Elaborate_All (if it needs to call operations in > that package during > its own elaboration). I find the above incomprehensible. The normal case in which you cannot use Elaborate_Body is when you have mutually dependent packages, a common situation. It is simply horrible to prohibit this common and perfectly reasonable situation (the alternative is being forced to aggregate packages which can perfectly well be separate). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-04 15:07 ` Matthew Heaney 2002-01-05 0:43 ` Robert Dewar @ 2002-01-05 0:50 ` Robert Dewar 2002-01-07 17:22 ` Mark Johnson 2002-01-10 21:54 ` Robert A Duff 1 sibling, 2 replies; 22+ messages in thread From: Robert Dewar @ 2002-01-05 0:50 UTC (permalink / raw) Some things to remember here: 1. The static elaboration model of GNAT is primarily intended for the development of new code. 2. If you are using GNAT in static mode, and do not intend to port the code to other compilers, it is a waste of time to mess around adding pragma Elaborate_All's, as was correctly noted in this thread, the -gnatwl warning is useful ONLY if you want to make sure that your code remains portable to other compilers without worrying about elaboration order messing things up. 3. If you are working with legacy code, it often makes no sense to try to use the static model of GNAT, and you should simply use -gnatE, and use the RM dynamic elaboration model. I am always surprised by people who are absolutely determined to beat legacy code into submission to the GNAT static model. Yes, of course this makes life easier in the future, but you have to be sure it is worth the work. 4. If you are working with legacy code, which has complex elaboration requirements, it is *highly* likely that the' code has serious bugs in it -- namely it does not have all the pragma Elaborate statements that should be there. 5. If you have buggy code of this kind, then you are between a rock and a hard place. rock = work required to meet GNAT static model hard place = work required to stick in all the pragmas It can often be very difficult to decide which way to go But always remember that the GNAT static model is an optional additional facility. It can never make porting harder, because you can always proceed as though it is not there. The reason it is the default is so that those lucky Ada programmers who know nothing about the horrors of elaboration who are writing new code will find it impossible to dig themselves into elaboration hell unawares :-) Robert Dewar ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-05 0:50 ` Robert Dewar @ 2002-01-07 17:22 ` Mark Johnson 2002-01-08 0:00 ` Robert Dewar 2002-01-10 21:54 ` Robert A Duff 1 sibling, 1 reply; 22+ messages in thread From: Mark Johnson @ 2002-01-07 17:22 UTC (permalink / raw) Robert Dewar wrote: > > Some things to remember here: > > 1. The static elaboration model of GNAT is primarily intended for the > development of new code. Hmm. I guess I disagree with that statement. See reasons below. > [snip] > 3. If you are working with legacy code, it often makes no > sense to try to use the static model of GNAT, and you should simply > use -gnatE, and use the RM dynamic elaboration model. I am always > surprised by people who > are absolutely determined to beat legacy code into submission to the > GNAT static model. Yes, of course this > makes life easier in the future, but you have to be sure > it is worth the work. Yes and no. Two examples follow. The first example follows Robert's suggestion to use -gnatE. To predict performance of our new system, we got a copy of ACES (Ada Compiler Evaluation System) and ran several hundred of the test programs through GNAT on the several target systems. Since this was a study and not intended to be run operationally, we did not spend the time trying to find and fix all the problems with this software. The use of -gnatE was a good way to make progress without a lot of effort. The second example is our real application. We are nearing the end of porting a couple million lines of code from Apex & VADS to GNAT. We actually have a small script that takes the compiler output, recognizes the "pragma Elaborate_All" messages, and makes those changes automatically. NONE of our software has broken when this was done. It was relatively painless and easy to perform. I expect many other well designed systems fall into this category. The use of the warning of the compiler and the script to make the changes has given us confidence that our code is free from any big issues with elaboration. It is not a "big deal" to make the change in most cases. As Robert's message goes on to say - complicated elaboration code is likely filled with bugs anyway. I am glad we don't have this kind of problem to worry about. -- --Mark ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-07 17:22 ` Mark Johnson @ 2002-01-08 0:00 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2002-01-08 0:00 UTC (permalink / raw) Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3C39D954.58672C0A@Raytheon.com>... > Robert Dewar wrote: > > > > Some things to remember here: > > > > 1. The static elaboration model of GNAT is primarily intended for the development of new code. > Hmm. I guess I disagree with that statement. See reasons > below. You can't really disagree with the designer of a feature telling you its primary design intention :-) Of course it is just fine if it can be used for legacy code, and it is always good to hear of such successes. > > 3. If you are working with legacy code, it often makes > > no sense to try to use the static model of GNAT Often /= never! My point, which I guess was confusing was that it often does not make sense to put in a huge amount of work to restructure code to meet the static model > Yes and no. Two examples follow. i.e. you are agreeing, sometimes yes, and sometimes no, which is exactly what I was saying > As Robert's message goes on to say - complicated > elaboration code is likely filled with bugs anyway. = That's misreading my message, the bugs I was talking about are failure to have all the pragma Elaborate's in place, but that is very specific. The paradigm that causes most trouble with the static model is: with X; package Y is ... Q : integer := X.Func; ... where X is a giant package with a large number of with's, but you happen to know that Func is a little function that does not use any of these with's. So it is in fact safe to use pragma Elaborate, instead of pragma Elaborate_All and everything will work. The coding philosophy of the static model of GNAT rejects this coding style on the grounds that it is improper for a client of X to know anything about the implementation of the body of X (and any of its subprogram). Yes, that's a legitimate coding philosophy, but that does not mean that any code that does not follow this philosophy is buggy :-) That being said, any program which does a lot of computation at elaboration time is worrisome. That's especially so if you have library tasks, which can start up before elaboration is complete :-( (see special section on elaboration and tasking in the GNAT docs). Robert Dewar ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-05 0:50 ` Robert Dewar 2002-01-07 17:22 ` Mark Johnson @ 2002-01-10 21:54 ` Robert A Duff 2002-01-11 4:49 ` Robert Dewar 2002-01-16 11:48 ` Arnaud Charlet 1 sibling, 2 replies; 22+ messages in thread From: Robert A Duff @ 2002-01-10 21:54 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > 4. If you are working with legacy code, which has complex > elaboration requirements, it is *highly* likely that the' > code has serious bugs in it -- namely it does not have all > the pragma Elaborate statements that should be there. True, but is it not also the case that these bugs are relatively innocuous? That is, if you forget your pragmas, then your program usually blows up during elaboration (and you fix it), or else it doesn't blow up (using this compiler). That is, it's more of a *portability* problem, than a problem of programs malfunctioning when users use them. It sure is frustrating when you have to fiddle with those stupid pragmas, but that is surely less costly than "real" bugs -- the ones that find their way into the hands of your program's users. Ideally, all elaboration problems would be detected at compile time (or link time), and there would be no constraints on the structure of a program due to elaboration-order issues. Ada (even with GNAT's default mode) does not achieve that, unfortunately. - Bob ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-10 21:54 ` Robert A Duff @ 2002-01-11 4:49 ` Robert Dewar 2002-01-11 13:35 ` Robert A Duff 2002-01-16 11:48 ` Arnaud Charlet 1 sibling, 1 reply; 22+ messages in thread From: Robert Dewar @ 2002-01-11 4:49 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc1ygx50tn.fsf@shell01.TheWorld.com>... > True, but is it not also the case that these bugs are > relatively > innocuous? That is, if you forget your pragmas, then > your program > usually blows up during elaboration (and you fix it), or > else it doesn't > blow up (using this compiler). That is, it's more of a > *portability* > problem, than a problem of programs malfunctioning when > users use them. In a large program, one with thousands of units, and millions of lines of code, it can take weeks or months of fiddling to find all the pragma Elaborate's that are required, when you have to do a complete build to find just one of them. Often in such a situation it may be better to aim for the static solution off the bat. > Ideally, all elaboration problems would be detected at > compile time (or > link time), and there would be no constraints on the > structure of a > program due to elaboration-order issues. Ada (even with > GNAT's default > mode) does not achieve that, unfortunately. I understand that this is theoretically true, but in practice with GNAT's static model problems do not arise. We have not had one customer using the static model ever run into any elaboration problems at all. So from a pragmatic point of view, the problem is solved. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-11 4:49 ` Robert Dewar @ 2002-01-11 13:35 ` Robert A Duff 2002-01-11 19:18 ` Robert Dewar 0 siblings, 1 reply; 22+ messages in thread From: Robert A Duff @ 2002-01-11 13:35 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > I understand that this is theoretically true, but in practice with > GNAT's static model problems do not arise. > We have not had one customer using the static model ever > run into any elaboration problems at all. I skept. That is, I think you should say, "We have not had one customer REPORT TO US ...." :-) - Bob ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-11 13:35 ` Robert A Duff @ 2002-01-11 19:18 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2002-01-11 19:18 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcck7up80yy.fsf@shell01.TheWorld.com>... > dewar@gnat.com (Robert Dewar) writes: > > > I understand that this is theoretically true, but in practice with > > GNAT's static model problems do not arise. > > We have not had one customer using the static model ever > > run into any elaboration problems at all. > > I skept. That is, I think you should say, "We have not had one customer > REPORT TO US ...." :-) Well as a competitor (who does not have this capability) you may of course skept :-) :-) But our supported customers are not shy about telling us if they have any problems! There is one kind of order of elaboration problem that cannot be dealt with in any automatic manner, and is in a sense completely outside the elaboration model, and that is the situation in which the order of elaboration is important not because of access-before-elaboration issues (which is what the GNAT model is all about) but because of other issues. Consider a library declaration that says: x : integer := y.z; where in package y there is y : integer := 35; Now some other package z which has no elaboration relationship to x whatsoever (i.e. it is not with'ed by x and does no with x, directly or indirectly) has a package body that says: y.z := 42; Now the question is whether x gets initialized to 35 or 42, and that of course depends on when package z is elaborated. Either answer might be the intended "right" one, and there is no clue in the sources at ALL about which of these is right, so neither choice is better than the other. Naturally, GNAT has nothing to say about this issue (and perhaps that is where Bob's "skept" comes from). Note that even the Ada language is uncomfortable here, there is no way for package x to demand that z be elaborated after itself, and even if the desire is to have it elaborated before, it is junky to have to add a with for z just so that it can be mentioned in a pragma Elaborate. For a more complete description of this problem, see the section "Other Elaboration Order Considerations" in the GNAT users guide. Actually the history of this section is interesting. We thought at one time that we had a customer who had run into this situation, but it turns out that it was something else, but still it seemed worth generating the special section in the manual on this. But the bottom line here is that elaboration has proved a big issue for code using the dynamic elaboration model in GNAT, in particular legacy code with missing pragma Elaborates, but once the static model has been satisfied, elaboration disappears as a significant issue in practice. That's based on a lot of experience in working with hundreds of million lines of legacy code from our customers. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-10 21:54 ` Robert A Duff 2002-01-11 4:49 ` Robert Dewar @ 2002-01-16 11:48 ` Arnaud Charlet 1 sibling, 0 replies; 22+ messages in thread From: Arnaud Charlet @ 2002-01-16 11:48 UTC (permalink / raw) << True, but is it not also the case that these bugs are relatively innocuous? That is, if you forget your pragmas, then your program usually blows up during elaboration (and you fix it), or else it doesn't blow up (using this compiler). That is, it's more of a *portability* problem, than a problem of programs malfunctioning when users use them. >> If you have library level tasks, that's definitely not true, since you can have subtle race conditions. And when you go from version n to version n+1 of your favorite compiler, you need to go and chase these bugs again. Arno ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-04 13:21 ` Frode Tenneboe 2002-01-04 15:07 ` Matthew Heaney @ 2002-01-05 0:40 ` Robert Dewar 2002-01-07 13:28 ` Frode Tenneboe 1 sibling, 1 reply; 22+ messages in thread From: Robert Dewar @ 2002-01-05 0:40 UTC (permalink / raw) Frode Tenneboe <ft@edh.ericsson.se> wrote in message news:<1010151875.216658@edh3>... > However, I find the above warning a bit misplaced in my > case. I would have preferred: > > bar.adb:69:04: warning: instantiation of "Client" may raise Program_Error > bar.adb:69:04: warning: missing pragma Elaborate_Body in spec Well perhaps you would have preferred that the compiler tell you this, but it won't because it is wrong! The use of a EB pragma in the spec is not an adequate solution for this case! > I'm also unsure if this is always true, but > > alternatively: It is not always true > foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error > foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" or > foo.adb:69:04: warning: missing pragma Elaborate_Body in "bar" This is getting two separate things mixed up I am afraid. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-05 0:40 ` Robert Dewar @ 2002-01-07 13:28 ` Frode Tenneboe 2002-01-11 19:25 ` Robert Dewar 0 siblings, 1 reply; 22+ messages in thread From: Frode Tenneboe @ 2002-01-07 13:28 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=ISO, Size: 1925 bytes --] Robert Dewar <dewar@gnat.com> wrote: > Frode Tenneboe <ft@edh.ericsson.se> wrote in message news:<1010151875.216658@edh3>... >> However, I find the above warning a bit misplaced in my >> case. I would have preferred: >> >> bar.adb:69:04: warning: instantiation of "Client" may raise Program_Error >> bar.adb:69:04: warning: missing pragma Elaborate_Body in spec > Well perhaps you would have preferred that the compiler > tell you this, but it won't because it is wrong! The use > of a EB pragma in the spec is not an adequate solution > for this case! I realize that it is not necesarily true in all cases, but won't the compiler be able to detect if pragma EB is appropriate? I find the section starting with "The rule is simple.", second from bottom on page 119 in the GNAT 3.13p UG to be quite concise. >> I'm also unsure if this is always true, but > >> alternatively: > It is not always true My problems mainly comes from generic units which is repeatedly used around everywhere with nesting, etc. If I start from the bottom and use pure/preelaborate where possible and if the warning dissappears after using EB pragma - am I home safe? >> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error >> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" or >> foo.adb:69:04: warning: missing pragma Elaborate_Body in "bar" > This is getting two separate things mixed up I am afraid. Possibly - could you please elaborate? :) I'm trying to convey that both solutions might solve the 'problem'. For the user the most desireable would (probably) be to fix the problem in the client. -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | | with Standard.Disclaimer; use Standard.Disclaimer; | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2002-01-07 13:28 ` Frode Tenneboe @ 2002-01-11 19:25 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2002-01-11 19:25 UTC (permalink / raw) Frode Tenneboe <ft@edh.ericsson.se> wrote in message news:<1010411468.548451@edh3>... > I realize that it is not necesarily true in all cases, > but won't the compiler be able to detect if pragma EB is > appropriate? No, because it cannot see the body in question > > I find the section starting with "The rule is simple.", > > second from bottom on page 119 in the GNAT 3.13p UG to be > quite concise. Well I don't have that version of the UG in front of me, but if it is about EB, it is probably wrong. Early versions of GNAT were definitely too ready to believe that the EB pragma gave some useful guarantees when in fact it does not. It is not better than a pragma Elaborate (as opposed to Elaborate_All). If a package uses something at run time from an Elaborate_Body package, then it cannot know what is in the body, so in the general case you still need a pragma Elaborate_All in such a case (and one will be supplied automatically when using the GNAT standard static approach). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-28 12:34 Elaboration in GNAT Frode Tenneboe 2001-11-28 18:13 ` Mark Johnson 2001-11-28 19:25 ` Robert Dewar @ 2001-11-29 13:13 ` Stephen Leake 2001-11-29 13:17 ` Stephen Leake 3 siblings, 0 replies; 22+ messages in thread From: Stephen Leake @ 2001-11-29 13:13 UTC (permalink / raw) Frode Tenneboe <ft@alne.edh.ericsson.se> writes: > Using -gnatwa I get some elaboration issues with some legacy code in GNAT. > One of these are: > > foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error > foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" Can you edit the code? In that case, just add "pragma Elaborate_All (bar);" in the context clause of foo.adb. Or, if you are using my Emacs Ada mode extension gnat-fix-error.el, just hit C-f6, and this is done for you :). Hmm, apparently "Client" is a generic. In that case, it may be you need the Elaborate_All in client.ads or client.adb; I'd have to see the code, and re-read the manual, to be sure. > The problem is that this crops up everywhere which I asume is > because the elboration of package bar is not very healthy. I'm not clear what you mean by "healthy". The precise meaning of this error message is something like: "Some compilers may choose an elaboration order that will elaborate 'foo' before 'bar'. In that case, elaborating 'foo' will raise Program_Error". The default mode of GNAT is to pick an elaboration order that avoids this problem. The warning here is to help with porting to other compilers. > The package in question uses Ada.Calendar, however there must be > some code in one (or more) of the dependencies in the body of bar > which causes this. A manual inspection of this code is not done over > night. I'm not clear why you think Ada.Calendar is relevant; it is not mentioned in the error message (unless that's what 'foo' or 'bar' really is). > Is there a way of getting the information above a bit more verbose? You need to read the chapters in the GNAT manual about elaboration; I think you are confused (not surprising; elaboration can be confusing!). Feel free to post a (small) example that gives this error. > > > -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson > Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | | > with Standard.Disclaimer; use Standard.Disclaimer; | -- -- Stephe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-28 12:34 Elaboration in GNAT Frode Tenneboe ` (2 preceding siblings ...) 2001-11-29 13:13 ` Stephen Leake @ 2001-11-29 13:17 ` Stephen Leake 2001-11-30 12:44 ` Simon Wright 3 siblings, 1 reply; 22+ messages in thread From: Stephen Leake @ 2001-11-29 13:17 UTC (permalink / raw) Frode Tenneboe <ft@alne.edh.ericsson.se> writes: > Using -gnatwa I get some elaboration issues with some legacy code in GNAT. > One of these are: > > foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error > foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" Can you edit the code? In that case, just add "pragma Elaborate_All (bar);" in the context clause of foo.adb. Or, if you are using my Emacs Ada mode extension gnat-fix-error.el, just hit C-f6, and this is done for you :). Hmm, apparently "Client" is a generic. In that case, it may be you need the Elaborate_All in client.ads or client.adb; I'd have to see the code, and re-read the manual, to be sure. > The problem is that this crops up everywhere which I asume is > because the elboration of package bar is not very healthy. I'm not clear what you mean by "healthy". The precise meaning of this error message is something like: "Some compilers may choose an elaboration order that will elaborate 'foo' before 'bar'. In that case, elaborating 'foo' will raise Program_Error". The default mode of GNAT is to pick an elaboration order that avoids this problem. The warning here is to help with porting to other compilers. > The package in question uses Ada.Calendar, however there must be > some code in one (or more) of the dependencies in the body of bar > which causes this. A manual inspection of this code is not done over > night. I'm not clear why you think Ada.Calendar is relevant; it is not mentioned in the error message (unless that's what 'foo' or 'bar' really is). > Is there a way of getting the information above a bit more verbose? You need to read the chapters in the GNAT manual about elaboration; I think you are confused (not surprising; elaboration can be confusing!). Feel free to post a (small) example that gives this error. > > > -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson > Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | | > with Standard.Disclaimer; use Standard.Disclaimer; | -- -- Stephe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Elaboration in GNAT 2001-11-29 13:17 ` Stephen Leake @ 2001-11-30 12:44 ` Simon Wright 0 siblings, 0 replies; 22+ messages in thread From: Simon Wright @ 2001-11-30 12:44 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes: > Feel free to post a (small) example that gives this error. My worst experience was with a 700-unit cycle (and although we were supported, the code was classified) ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-01-16 11:48 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-11-28 12:34 Elaboration in GNAT Frode Tenneboe 2001-11-28 18:13 ` Mark Johnson 2001-11-29 3:44 ` Robert Dewar 2001-11-29 13:30 ` Stephen Leake 2001-11-28 19:25 ` Robert Dewar 2002-01-04 13:21 ` Frode Tenneboe 2002-01-04 15:07 ` Matthew Heaney 2002-01-05 0:43 ` Robert Dewar 2002-01-05 0:50 ` Robert Dewar 2002-01-07 17:22 ` Mark Johnson 2002-01-08 0:00 ` Robert Dewar 2002-01-10 21:54 ` Robert A Duff 2002-01-11 4:49 ` Robert Dewar 2002-01-11 13:35 ` Robert A Duff 2002-01-11 19:18 ` Robert Dewar 2002-01-16 11:48 ` Arnaud Charlet 2002-01-05 0:40 ` Robert Dewar 2002-01-07 13:28 ` Frode Tenneboe 2002-01-11 19:25 ` Robert Dewar 2001-11-29 13:13 ` Stephen Leake 2001-11-29 13:17 ` Stephen Leake 2001-11-30 12:44 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox