Conference turris::decc

    
    Dave,
    
    We are aware of these issues, and are working on them now.  We hope
    that the final Steel compiler will resolve them.
    
    As for right now...the -verbose option will provide the message-id
    for most messages.  It appears in parens after the message text.
    However, there are a few messages for which -verbose does not work.
    These are messages generated by the GEM code generator, and the
    message you are most concerned about: "routine a can never be called"
    is one of these.  In these few cases you have to go to VMS to try
    it.  The ident for this message is "uncalled"
    
    Again, we are aware of these issues and hope to have them all addressed
    in the Steel release.
    
    						Ed
    
    

Dave:
	The steel development pools have a very noisy DECC compiler,
	and that is by design.  The noisier diags will be removed
	before IFT but for now they are there to support much of the
	steel pool cleanup efforts.

Joe

I'm glad to hear it'll be cleared up by Steel.

Joe -- I understand the purpose, and I'm not even disagreeing. I was merely
complaining about how difficult the compiler makes the task of figuring out
how to disable the messages that truly AREN'T helpful (for our code). We're
getting these messages in lots of places, and I've already made sure we don't
actually need (or want) to worry about any of them. The plethora of messages
that we need to ignore on each build obscure any other messages that we might
want to notice!

Ed -- thanks for the information!

	/dave

Uh, one more thing. Can anyone tell me why it doesn't appear to be working?

header.h:

	#pragma message disable uncalled

	#pragma inline (func)
	static int func (int) { ... };

And I still get "routine func can never be called" messages. Is there
something about this configuration that overrides the disable (pragma needs
to be in .c, or doesn't work for inlined, etc.) -- or is this really covered
by a different message ID?

There are no #pragma message save/restore, and no #pragma message enable
uncalled, (in my code or, as far as I can see, in any steelos.nightly system
headers), so it would appear there's no way my disable could be reversed.

	/dave

    
    Dave, 
    
    (You'll like this one)...Put the "#pragma message disable uncalled"
    at the end of the source file that is being compiled.
    
    There is another problem with those messages that are generated by
    GEM.  The enable/disable state for all those messages are the
    state at the end of the source program, not the state at the
    point in the source where the message is output.  This is different
    than the front-end generated messages.
    
    So if you have
    
    #pragma environment save
    #pragma message disable uncalled
    
    static int func (int) { ... };
    
    #pragma environment restore
    
    
    You'll still see the message.  You need to moeve the #pramga message
    disable to the end of the compilation.  (Actually, putting it as
    the first thing in the compilation will also work if all you do
    is save/restore message states).
    
    This is also a problem we are aware of.  Fixing this one is quite
    a bit of work that is (I believe) not planned for Steel.
    
    						Ed
    
    

I really don't want to change every source file -- I was hoping to be able to
put the pragma into the header file that declares the functions.

I can't see any way there could be a save before this with a matching restore
after it -- we don't do that between header files. And I'm pretty sure there
couldn't be any "message enable uncalled" pragmas -- I searched our code and
the system headers for "pragma[ \t]*message" before I tried this.

	/dave

    
    Dave,
    
    I suspect the problem is the PEA files that
    get placed around your include file.  These contain 
    #pragma environment save and #pragma environment restore.
    #pragma environment save does a #pragma message save, and
    #pragma environment restore does a #pragma message restore.
    
    						Ed
    
    

        Too bad there isn't a
        
        	$ CC/BEFORE=pathname/AFTER=pathname ...
        
        that specifies an initial and/or final file to include.
        
        Then the /AFTER file can contain
        
        	#pragma message disable uncalled
        
        for this topic and the before file can contain
        
        
        	#undef __VMS_VER
        	#define __VMS_VER 60100000
        
        for topic 2189 here.
        
        Dan

RE .8:

>        Too bad there isn't a
>        
>        	$ CC/BEFORE=pathname/AFTER=pathname ...
>        
>        that specifies an initial and/or final file to include.


The "BEFORE" functionality is something that is just now being
implemented for UNIX, and will likely get into Steel.  This
functionality is offered in VC++, and we'll most likely use
the same switch syntax, -FIpathname.  Note that an AFTER file
would not be needed for Dave's problem: the PEA files get
placed around include files from directories that contain
these specially-named files (__DECC_include_prologue.h and
__DECC_include_epilogue.h).  So if his BEFORE file was in
a directory that did not contain these files, then the
save/restore semantics would leave the message turned off
at the end of the compilation.  Another feature that may
be added in Steel is the ability to suppress a message
from the command line, which would also work.  Unfortunately,
neither feature is in the current build compiler.

But .8 used VMS syntax.  We were not planning to add an
equivalent for -FI on VMS largely because the "+" feature
of DCL seems to make it mostly unnecessary (you get AFTER
as well).  The problems with using "+" for BEFORE seem to
be that you'd have to add a /obj= qualifier to avoid having
your object file named after the BEFORE file, and perhaps
you'd need a #pragma module to avoid having the object module
named after the BEFORE file.  But these did not seem like
huge problems.  Does anybody think that something like /BEFORE
is really necessary on VMS?

        /BEFORE=pathname/AFTER=pathname can be put into the "CFLAGS"
        macro of an MMS script ... is there an equally easy way to
        tweak an existing MMS script to use the + notation?  If so,
        then /BEFORE and /AFTER on OpenVMS are nice but not necessary.
        
        Dan

re .10: I'm afraid there isn't yet an easy way to have +lists in MMS. I
asked for that feature and they put it on the wish list. I don't know the
current status. If some more people ask, maybe we can get it.

Hartmut

ps: The noise I generated in the mms notes file:

            <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]MMS.NOTE;1 >>>
                         -< MMS general interest file >-
================================================================================
Note 1323.0                    mms$source_plus ???                     5 replies
MUCTEC::BECKER "Hartmut B., VMS & Languages, Munich" 16 lines  15-NOV-1995 10:27
--------------------------------------------------------------------------------
Couldn't find anything on plus-separeted lists. Is there any special
macro to generate out of the dependencies a plus list?

For example, if I have architectural specific defines in arch.mar I look for a
simple action line

x.obj :	arch.mar x.mar
	macro/obj=$@ mms$source_plus	# or $& if it can be re-used in this
					# context

which should give me the action "$ macro/obj=x.obj arch.mar+x.mar".

Did I miss something (rtm)? Or is there a workaround?

Thanks,
Hartmut
================================================================================
Note 1323.1                    mms$source_plus ???                        1 of 5
EDSDS6::GLEASON "Daryl Gleason, DECset Engineering"  21 lines  16-NOV-1995 09:25
                        -< specific action line needed >-
--------------------------------------------------------------------------------
    Hartmut,
    
    MMS does not have any inherent intelligence concerning the relationship
    of one source file to another. All it knows is that a target depends
    upon zero or more sources and that there are certain actions to be
    taken to update the target from the sources. The actions may be
    specified in built-in rules, user-defined rules, or user-specified
    action lines specific to that target. 
    
    MMS cares only that the actions required to update the target exist; it
    does not care what those actions really are. It will dutifully attempt
    to execute any actions that are specified.
    
    So in your example, if you wish for arch.mar and x.mar to be compiled
    as concatenated sources, it will be necessary to instruct MMS to do
    that by explicitly specifying the appropriate action line. MMS cannot
    figure this out for itself.
    
    I hope this helps!
    
    -- Daryl
================================================================================
Note 1323.2                    mms$source_plus ???                        2 of 5
MUCTEC::BECKER "Hartmut B., VMS & Languages, Munich" 22 lines  17-NOV-1995 05:28
                           -< specific macro wanted >-
--------------------------------------------------------------------------------
Daryl,

thanks for your answer. I think I didn't express very clearly what I want.
I'm familiar with some of the make tools and know that they can't figure
out what I intend to do. The only thing I'm looking for is a similar
special macro like MMS$SOURCE_LIST. This macro expands to a comma list. I'm
not aware that this expansion type is generally available in make files. It
looks like a VMS specific expansion. A plus list is another VMS specific
expansion. That's what I'm asking for. That is if a target depends on
several sources I would like to have one special macro to combine these
sources to a plus list (hope I got it clearer). On the other hand I can
work around this with GNU make, for example

space=	$(undefined) $(undefined)
foo.obj :	foo.c bar.c
	cc/obj=$@ $(subst $(space),+,$^)

which expands the action line to

	cc/obj=foo.obj foo.c+bar.c

Hartmut
================================================================================
Note 1323.3                    mms$source_plus ???                        3 of 5
EDSDS6::GLEASON "Daryl Gleason, DECset Engineering"  15 lines  17-NOV-1995 07:43
--------------------------------------------------------------------------------
    Harmut,
    
    Thanks for the clarification! You're right that MMS does not have a
    plus-separated analog of MMS$SOURCE_LIST. If you think that this would
    be a useful feature, I could add it to the wish list. It sounds like
    enhancing MMS to be compatible (as far as possible) with GNU make would
    be even more useful.
    
    In any event, as a workaround, what I would do is to write a command
    procedure that takes as input a comma-separated list and transforms it
    into a plus-separated list. This command procedure could then be called
    from an MMS action line to operate on MMS$SOURCE_LIST, and the output
    could be used in the following compile command action line.
    
    -- Daryl
================================================================================
Note 1323.4                    mms$source_plus ???                        4 of 5
MUCTEC::BECKER "Hartmut B., VMS & Languages, Munich"  9 lines  17-NOV-1995 11:02
                               -< wishlist item >-
--------------------------------------------------------------------------------
Please add it to the wishlist. I did some hacking and found a workaround
for only two sources:

plist='f$ext(0,f$loc(",","$+"),"$+")'+'f$ext(f$loc(",","$+")+1,f$len("$+"),"$+")

x.obj :	arch.mar x.mar
	macro/obj=$@ $(plist)

Hartmut
================================================================================
Note 1323.5                    mms$source_plus ???                        5 of 5
EDSDS6::GLEASON "Daryl Gleason, DECset Engineering"   3 lines  17-NOV-1995 16:43
                               -< MMS wish #47 >-
--------------------------------------------------------------------------------
    I've added this as MMS wish #47.
    
    -- Daryl

OK, I remember all the discussions about implicit prologue & epilogue files,
so I'll assume they have gained the TLA "PEA". OK, fine. However, the
steelos.nightly export/alpha/usr/include has no "__DECC_*" files, nor any
"*prologue*" files, nor any files containing "pragma[ \t]+environment" or
"pragma[ \t]+message".

Oh, and, one more thing. I decided, as an experiment (although I don't like
the idea of changing all my .c files), to put the #pragma message disable
uncalled as the last line of one of the .c files. I still get the messages
when I compile it.

cc: Info:
/usr/users/butenhof/sb/private/src/usr/ccs/lib/libpthread/alpha/thd_vp_os.h,
line 432: routine vpUnsetCritical can never be called
static void
^

	/dave

Dave:
	Two things are happening here.

	1) The "#pragma message disable" feature doesn't work for
	   messages that the GEM backend emits.  The uncalled message
	   is one of the few that GEM emits.  
	   
	   This has been a day-one problem in DECC/C++.  We hope to
	   have this fixed in the final Steel DECC.  

	2) The uncalled message is one of the messages that we 
	   "hardwired-on" in the steel pools.  The release team is
	   getting some summer hires to cleanup the steel pools
	   and they'll be using these diags.  

	These extra noisy diagnostics are only in the steel development
	pools.  If any of the more intesting ones can help you now, 
	great.  Else, wait a few months till we remove them.

Joe 

Thanks, Joe. OK. It's impossible, so don't worry about it. I can handle that.

	/dave

        You could + a file that defines a static routine that calls
        itself and all of the other static routines in the headers. :-)
        
        Dan