[GHC] #14946: GHC Calls CPP for HS with -undef
#14946: GHC Calls CPP for HS with -undef -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC Is calling the C preprocessor when processing HS files with `-undef` which unsets and compiler pre-defines. Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support. Is this really the intended behavior? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14946 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14946: GHC Calls CPP for HS with -undef -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Phyx-: Old description:
GHC Is calling the C preprocessor when processing HS files with `-undef` which unsets and compiler pre-defines.
Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support.
Is this really the intended behavior?
New description: GHC Is calling the C preprocessor[1] when processing HS files with `-undef` which unsets and compiler pre-defines. Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support. Is this really the intended behavior? [1] https://github.com/ghc/ghc/blob/60aa53d97da1bbfbb88e9f2791c3f686ba34e764/acl... -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14946#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14946: GHC Calls CPP for HS with -undef -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Phyx-: Old description:
GHC Is calling the C preprocessor[1] when processing HS files with `-undef` which unsets and compiler pre-defines.
Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support.
Is this really the intended behavior?
[1] https://github.com/ghc/ghc/blob/60aa53d97da1bbfbb88e9f2791c3f686ba34e764/acl...
New description: GHC Is calling the C preprocessor[1] when processing HS files with `-undef` which unsets the C compiler pre-defines. Essentially it means you cannot use any normal compiler defines to check for platform or intrinsics support. Is this really the intended behavior? I get the fact that we're processing a Haskell source file, but why restrict the pre-processor to only GHC defines. You lose information like if unaligned accesses are supported or not etc. [1] https://github.com/ghc/ghc/blob/60aa53d97da1bbfbb88e9f2791c3f686ba34e764/acl... -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14946#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14946: GHC Calls CPP for HS with -undef -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): erikd says,
Phyx-, bgamari-, angerman : the preprocessor should *not* be getting called with `-undef` , but it should be getting called with `-Wcpp-undef` which warns on undefined macros. see 3cb32d8b0b51c5
so adding `-Wcpp-undef` to ghc command line adds `-Wundef` to the CPP command line
That being said, I don't see why this is responsible for the issue that Phyx- is seeing as it adds `-Wundef`, not `-undef` (and indeed the commit looks right). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14946#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14946: GHC Calls CPP for HS with -undef -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I think erikd was referring to something a bit unrelated to this issue. Warning flags are not the issue. As far as I can see going as far back as ghc 7.8 (I stopped trying to track it after that as the option keeps getting refactored to somewhere else making the blame annoying) it seems that GHC has always passed `-undef` to the C preprocessor. Which I think is a mistake. It makes the CPP mode a lot less useful. For instance https://phabricator.haskell.org/D26 was one such refactoring that moved the option from somewhere else. So we've been doing this for years and years. I should probably finish the archeology to see if I can't figure out why we did this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14946#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC