[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3510.0. "GEM Assertion Error - Compiler Internal Error" by ASIC::ASIC::KIRKPATRICK () Fri Mar 21 1997 13:52

We currently have the following installed on our Digital Alpha 
platform:

   Digital UNIX V4.0B (Rev. 564)
   V5.5-004 on Digital UNIX (Alpha)

We had previously been using the following configuration with no
problems until we had to upgrade our operating system to UNIX V4.0B:

   Digital UNIX V3.2C  (Rev. 148)
   V5.1-1 for Digital UNIX (Alpha)

GEM Assertion failure

Assertion failure:  Compiler internal error - please submit problem
report
GEM ASSERTION, Compiler internal error - please submit problem report
Fatal error in: /usr/lib/cmplrs/cxx/gemc_cxx Terminated

The module it had a problem with was the code generated by byacc. We
are currently looking at it to see what could be triggering it but 
this one will be difficult for us to find.   This is stopping us from
being able to create sharable libraries for our CAD tools.  Any suggestions
or work-arounds will be appreciated.

The code is in the following area:

bigaxp.mro.dec.com:'/bigaxp_prj01/release/conf_y_tab.ixx'

Mike
T.RTitleUserPersonal
Name
DateLines
3510.1Can't find the sourceDECCXX::RMEYERSRandy MeyersFri Mar 21 1997 16:086
Re: .0

I'd like to help, but there does not seem to be any directory named
/bigaxp_prj01/release on bigaxp.mro.dec.com.

You can mail the source file to [email protected]
3510.2Erroneous code confused the compilerDECCXL::RMEYERSRandy MeyersFri Mar 21 1997 18:4246
Re: 3510.0

Amazingly, the problem can be reduced to the source:

	int nodeNum;
	void confyyparse()
	{
	    nodeNum = nodeNum++;
	}

where the line "nodeNum = nodeNum++;" causes the problem.  This line
appears as the first statement of "case 6:" in the switch statement in
confyyparse().

Although it unacceptable for the compiler to hit internal assertions, you
should do something about the line of code.  Any expression that stores a
value into a variable more than once within the same "sequence point" has
undefined behavior.  In other words, the expression is a programmer error
and may produce unpredictable results.

For example, assume that nodeNum has the value 0.  A compiler might
evaluate the expression nodeNum = nodeNum++ by:

	1.  Save the old value of nodeNum
	2.  Increment the value of nodeNum
	3.  Store the value saved in step 1 into nodeNum
	    (nodeNum has value 0)
or by:

	1.  Save the old value of nodeNum
	2.  Store the value saved in step 1 into nodeNum
	3.  Increment the value of nodeNum
	    (nodeNum has value 1)

both are perfectly reasonable "ANSI Standard" interpretations of the
expression in question.  If fact, since the program contains a programmer
error that the compiler is not obliged to diagnose, the compiler could
even do something off the wall like hit an internal assertion and die
(while permitted under the ANSI Standard, that isn't a friendly response).

I recommend that you work around the compiler assertion by either
deleting the line in question (if you want the assignment to undo the
increment) or by rewriting the line to be just "nodeNum++;" (if you want
the increment to actually happen).  You might want to look at the code
generated by the previous version of the compiler to see what seemed to
work in the past.
3510.3Not a problem in DEC C V5.6 and DEC C++ V6.0?DECC::SULLIVANJeff SullivanMon Mar 24 1997 12:1120
The example in .2 will cause the following warning (and no compiler crash) when
compiled with DEC C V5.6 and later on UNIX. That compiler will be available in
Digital UNIX V4.0D and later.

% cc -c t.c
cc: Warning: t.c, line 4: In this statement, the expression "nodeNum=nodeNum++"
modifies the variable "nodeNum" more than once without an intervening sequence
point.  This behavior is undefined.
  nodeNum = nodeNum++;
--^

These warnings are issued by the compiler used to build Digital UNIX V4.0D and
later. When it was first enabled, we found (and fixed) several areas in the UNIX
source code that relied on this undefined behavior. Fixing these warnings may
fix latent bugs that may appear later (during a port, for example).

I verified that this is still a problem in the development C++ V5.6 compiler,
but it appears to be fixed in development DEC C++ V6.0.

-Jeff
3510.4TrackedDECCXL::RMEYERSRandy MeyersMon Mar 24 1997 15:101
This problem is being tracked by note 4206.0 in our internal notesfile.
3510.5CXXC::WOLFEWed May 28 1997 10:511
markded fixed by v6.0