Opened 6 years ago

Closed 6 years ago

#8143 closed bug (duplicate)

File name module name mismatch in Parser.hs in HEAD

Reported by: carter Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.7
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

compiler/stage1/build/Parser.hs:1:1:
    File name does not match module name:
    Saw: `Main'
    Expected: `Parser'
make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1
make: *** [all] Error 2

on current head c384bb1e30499bb4809dca60803a4066762ce5f4 and i tried a random recent commit 2e41f2fa91c833a4420ac273254e49468044bc4b

Change History (9)

comment:1 Changed 6 years ago by carter

does anyone else have this problem

comment:2 Changed 6 years ago by carter

Seems to be that the Parser.hs file generated by Parser.y.pp has some leading white space on its CPP pragmas

 #if __GLASGOW_HASKELL__ >= 707
-- Required on x86 to avoid the register allocator running out of
-- stack slots when compiling this module with -fPIC -dynamic.
{-# OPTIONS_GHC -fcmm-sink #-}
 #endif

If I change it to

#if __GLASGOW_HASKELL__ >= 707
-- Required on x86 to avoid the register allocator running out of
-- stack slots when compiling this module with -fPIC -dynamic.
{-# OPTIONS_GHC -fcmm-sink #-}
#endif

the build gets further along (though it fails later)

The offending original code seems to be this:

-- CPP tricks because we want the directives in the output of the
-- first CPP pass.
--
-- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for
-- some reason) that there be a line of whitespace between the two
-- definitions here, and the subsequent use of __IF_GHC_77__ - this
-- seems to be a bug in clang or something, where having the line of
-- whitespace will make the preprocessor correctly format the rendered
-- lines in the 'two step' CPP pass. No, this is not a joke.
#define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707
#define __ENDIF__ #endif

__IF_GHC_77__
-- Required on x86 to avoid the register allocator running out of
-- stack slots when compiling this module with -fPIC -dynamic.
{-# OPTIONS_GHC -fcmm-sink #-}
__ENDIF__

I'm trying a test build of Current HEAD where my host c compiler is gcc-4.8, and my ./configure with-gcc=clang where I put the CPP in directly. (i'm not sure why we need the IF_GHC_77 and ENDIF)

alternatively, to prevent the leading whitespace, something like

#define __IF_GHC_77__  /
#if __GLASGOW_HASKELL__ >= 707

might make sense?

Last edited 6 years ago by carter (previous) (diff)

comment:3 Changed 6 years ago by carter

just tried the indirect definition trick, doesn't work

i'm going to just inline that pragma at the top.

edit: nope didn't work

Last edited 6 years ago by carter (previous) (diff)

comment:4 Changed 6 years ago by carter

relatedly: why does that conditional pragma need to be propagated / preserved? aren't we always using the same GHC for the CPP pass and the compilation pass?

comment:5 Changed 6 years ago by carter

This seems to be an issue when xcode 5 is installed (ie it goes away when I switch back to the 4.6 CLI tools).

comment:6 Changed 6 years ago by carter

oddly, It shouldn't have been happening, because I was using gcc-4.8, so i'm not sure how it could have happened

comment:7 Changed 6 years ago by carter

This makes me suspect that somewhere in the build system, a gcc version is hard coded...

comment:8 Changed 6 years ago by carter

yup, even though i did ./configure --with-gcc=othercompilername it was calling gcc itself!

comment:9 Changed 6 years ago by carter

Resolution: duplicate
Status: newclosed

shifting this to being discussed in ticket #8148, which identifies the root issue

Note: See TracTickets for help on using tickets.