On 08/11/14 01:27 AM, Carter Schonwald wrote:

I could be wrong, but I think assembler-with-cpp came up only as part of certain clang work arounds, it should suffice to use any GCC like traditional mode CPP (like the CPPHS tool).

This is interesting, but it looks like -x assembler-with-cpp is hard-coded into DriverPipeline.hs in doCpp function and either assembler-with-cpp or assembler is used in runPhase as and this is completely independent from target cpp even when configure with --with-hs-cpp= option.

note that the configure script tries to detect what the CPP program you specify using --with-hs-cpp IS, and it only has logic for modern GCC/Clang/CPPHS, so you should specify a suitable set of flags if you're picking something different (theres a flag like --with-hs-cpp-flags you can set explicitly)

Hmm, seeing CPPHS give me an idea about either - prioritizing CPPHS usage, when configure detects CPPHS availability it is then set as with --with-hs-cpp option and used as a preprocessor or - integrate CPPHS directly into GHC as it seems it provides some library API. Sidenote: builders are testing ghc binary dist installed into the "install dir" directory and it looks like this process of installation completely forgot about original --with-hs-cpp option. And seeing Solaris builder test_bindist[1] output it looks like not only --with-hs-cpp option is forgotten but every option of original configure run is forgotten... Karel [1]: http://haskell.inf.elte.hu/builders/solaris-x86-head/135/20.html

On Sun, Aug 10, 2014 at 5:06 PM, Karel Gardas mailto:karel.gardas@centrum.cz> wrote:

Folks,

in my attempt to lower number of failing tests on Solaris I've found several tests which fail on just difference in file name report. My ghc reports warning/error in /tmp/ghc<something>/<some different thing> while expected is clear T<something>.hs.

See http://haskell.inf.elte.hu/__builders/solaris-x86-head/125/__21.html http://haskell.inf.elte.hu/builders/solaris-x86-head/125/21.html and search for T7145b as an example of this behavior.

The reason why this happen is that Solaris GNU C 4.x does not emit line markers in preprocessed file when it's preprocessed with -x assembler-with-cpp. The reason behind this is documented in this thread[1] on GCC mailing list. Simply speaking Sun's assembler in the past chokes on some linemarkers generated. This was apparently case of as on older Solaris then 10 version and perhaps this will be fixed in future major GCC release as Solaris 9 is not supported anymore. Anyway, we still do have a case with GNU C compilers provided by Solaris 10 and Solaris 11. FYI: Solaris' 10 GNU C 3.4.x is OK, Solaris 11's GNU C 4.5.2 is broken and with this all more modern 4.x releases so probably also all 4.x release provided by Solaris 11.1/11.2.

So far I've solved the issue of those failing tests by passing --with-hs-cpp=/usr/sfw/bin/gcc -- so configured this way GHC will use old not-buggy GNU C 3.4.x on my Solaris 11 builder as CPP and otherwise it'll use /usr/bin/gcc (GNU C 4.5.2) and everything will pass fine hopefully.

Anyway, the thread[1] also contains a question which also rings in my head and that is: why we use -x assembler-with-cpp at all? Isn't simple -E enough. Or isn't simple usage of system provided CPP enough /usr/lib/cpp on Solaris)? Or what will happen if we for example change -x assembler-with-cpp to -x c or -x c-header or something like that? Please note that the testcase is OK with -x c/c-header even using this "buggy" GNU C 4.5.2 since the compiler/cpp is really buggy just for the case of -x assembler-with-cpp.

Thanks! Karel

[1]: https://gcc.gnu.org/ml/gcc/__2014-08/msg00114.html https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html _________________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs

What i'm hearing you say is we actually need TWO sets of CPP flags, one for normal haskell, and another for the CPP used on the assembler? wheres this hardcoding?

why should this flag be passed to cpp when invoked on HS files? It'd be easy to expose another field in the settings file for this other invokecation.. though i should look more closely at the use site before opinining :) On Mon, Aug 11, 2014 at 4:27 PM, Karel Gardas wrote:

On 08/11/14 08:48 PM, Carter Schonwald wrote:

...

What i'm hearing you say is we actually need TWO sets of CPP flags, one for normal haskell, and another for the CPP used on the assembler? wheres this hardcoding?

DriverPipeline.hs -- grep for "assembler-with-cpp" and you will find it.

IMHO best would be to move this "-x assembler-with-cpp" into the hs-cpp-flags managed by configure. This way it may be even possible to use system supplied plain cpp instead of cpp builtinto GNU C.

Karel

Oooooo. Then it's possibly debris leftover from Austin's initial clang compatibility work predating the improvements via the settings file work. I'm Afk right now, but that probably can be safely removed from ghc, especially since the configure script for clang cpp adds that anyways now I think? I might be wrong though. On Monday, August 11, 2014, Karel Gardas wrote:

On 08/11/14 11:18 PM, Carter Schonwald wrote:

...

why should this flag be passed to cpp when invoked on HS files? It'd be easy to expose another field in the settings file for this other invokecation.. though i should look more closely at the use site before opinining :)

Hmm, isn't doCpp function what's invoked when cpp is invoked for HS files? If so, then -x assembler-with-cpp is already used for HS files anyway.

Karel

...

On Mon, Aug 11, 2014 at 4:27 PM, Karel Gardas mailto:karel.gardas@centrum.cz> wrote:

On 08/11/14 08:48 PM, Carter Schonwald wrote:

What i'm hearing you say is we actually need TWO sets of CPP flags, one for normal haskell, and another for the CPP used on the assembler? wheres this hardcoding?

DriverPipeline.hs -- grep for "assembler-with-cpp" and you will find it.

IMHO best would be to move this "-x assembler-with-cpp" into the hs-cpp-flags managed by configure. This way it may be even possible to use system supplied plain cpp instead of cpp builtinto GNU C.

Karel