[m-rev.] Tiny change to fix building

[Ben Schmidt]

>>>> It reveals a GCC bug. When compiling mercury_event_parser.c it fails,
 >>>> grumbling about differing types for YYSTYPE, though they are defined
>>>> to be exactly the same union (once in the included header file and once
 >>>> in the .c file proper).

>>> What version of gcc?
>>
>> At least the one on jupiter:
>> gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
> 
> jupiter (and to the best of my knowledge all x86 machines) require
> at least gcc 3.4 to compile successfully since the recent addition of 
> the event_spec library.  (Run configure with --with-cc=/usr/bin/gcc-3.4 on
> jupiter).
> 
>> And on my local machine:
>> i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 
>> 5363) (patched by me to fix another bug)
> 
> Mainline gcc 4.0.X is pretty much a dead loss on anything as far as 
> Mercury is concerned - I can't imagine Apple's builds being any better.

Apple's builds definitely do have some bugfixes related to global 
register variables and so on, which seem to be the main GCC headache 
causing problems, so I wouldn't jump to a conclusion there. At the 
moment, though, no version of GCC seems to work out of the box on i386 
Darwin, though using a patched version of GCC 4.0.1, I seem to be able 
to get it working, at least mostly.

One question: is there a simple way, via a configure option or such, to 
turn off the use of GCC global register variables and thereby get a more 
reliable, even if less efficient, system? It strikes me that given the 
number of problems these things seem to cause, it would be worth having 
an easy way of turning them off. I imagine for a lot of people, changing 
a Mercury configure option and dealing with slower executables may be 
preferable to upgrading GCC (especially on Intel Darwin where no version 
of GCC seems to work!).

Back on topic, though, I get the GCC error using mainline GCC 3.4.4 on 
PPC Darwin also. It seems to me the error easily occurs frequently 
enough to warrant the fix. Happy for me to commit it?

Ben.





Estimated hours taken: 0
Branches: main

trace/mercury_event_parser.y:
	Remove unnecessary header inclusion that causes errors with GCC.

Index: trace/mercury_event_parser.y
===================================================================
RCS file: 
/home/mercury/mercury1/repository/mercury/trace/mercury_event_parser.y,v
retrieving revision 1.3
diff -u -r1.3 mercury_event_parser.y
--- trace/mercury_event_parser.y	14 Dec 2006 04:36:03 -0000	1.3
+++ trace/mercury_event_parser.y	21 Dec 2006 23:08:59 -0000
@@ -22,7 +22,9 @@

  #include "mercury_event_spec.h"             /* for MR_EventSpecs etc */
  #include "mercury_event_spec_missing.h"     /* for mercury_event_text 
etc */
-#include "mercury_event_parser.h"
+/* #include "mercury_event_parser.h"           the content of this 
header is
+                                               in bison's .c output anyway;
+                                               including it again 
chokes GCC. */
  #include "mercury_event_scanner.h"          /* for mercury_event_lex 
etc */

  MR_EventSet         mercury_event_parsetree;
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------