Opened 3 years ago

Last modified 6 months ago

#11495 new bug

TH_spliceE5_prof is failing with release candidate 8.0.1

Reported by: thomie Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.0.1-rc1
Keywords: Cc: simonmar
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 (last modified by thomie)

TH_spliceE5_prof looks like this:

	$(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof
	'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c
	'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@

In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that $(ghcThWayFlags) to the first compilation command. With a release compiler, ghcThWayFlags defaults to -dynamic. But compiling with -dynamic doesn't produce .dyn_o files (you need -dynamic-too for that, which is enabled by -XTemplateHaskell, but not when compiling with -dynamic), so the second compilation results in:

TH_spliceE5_prof.hs:8:17: fatal:
    cannot find object file ‘./TH_spliceE5_prof_Lib.dyn_o’
    while linking an interpreted expression
make[1]: *** [TH_spliceE5_prof] Error 1

*** unexpected failure for TH_spliceE5_prof(normal)

Not passing -dynamic fixes the test. But in the function failNonStd in compiler/ghci/Linker.hs Simon suggests that passing -dynamic is necessary:

    Cannot load -prof objects when GHC is built with -dynamic
    To fix this, either:
      (1) Use -fexternal-interprter, or
      (2) Build the program twice: once with -dynamic, and then
          with -prof using -osuf to set a different object file suffix.

Some ideas for a solution:

  • change that message to not mention -dynamic
  • always turn on -dynamic-too when -XTemplateHaskell is on, also when using -dynamic
  • find the place where .dyn_o is expected, and teach it that .o might also be ok.
  • make -fexternal-interpreter the default. Delete the test and a whole bunch of other stuff.

It's all such a mess.

Change History (9)

comment:1 Changed 3 years ago by thomie

Description: modified (diff)

comment:2 Changed 3 years ago by Thomas Miedema <thomasmiedema@…>

In eeb67c9b/ghc:

Testsuite: fixup req_profiling tests (#11496)

* T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof.
* TH_spliceE5_prof (#11495) is failing when ghc_dynamic
* Rename ghci_dynamic to ghc_dynamic. It's the same thing.

comment:3 Changed 3 years ago by simonmar

It's all such a mess.


I guess we should not put -dynamic in ghcThWayFlags, because (a) it doesn't work with -prof and (b) It is sort-of handled magically by GHC turning on -dynamic-too when we need TH.

This crap is part of the reason I wanted to make -fexternal-interpreter.

comment:4 Changed 3 years ago by thomie

I guess we should not put -dynamic in ghcThWayFlags

That doesn't work in batch mode (edit: make test TEST='T7022b annth_compunits T2386 T7445 T2014' would fail).

Take this example:


{-# LANGUAGE TemplateHaskell #-}
module A where
import B


{-# LANGUAGE TemplateHaskell #-}
module B where
import Language.Haskell.TH
dec = [d| x = 1 |]


$ ghc -c B.hs
$ ghc -c A.hs
    cannot find normal object file ‘./B.dyn_o’
    while linking an interpreted expression

How about this: when compiling with -dynamic, create .dyn_o and .dyn_hi files by default instead of .o and .hi files. Is there any drawback to this? It would be more consistent with what -dynamic-too does as well.

-osuf and -hisuf could keep working as before.

Last edited 3 years ago by thomie (previous) (diff)

comment:5 Changed 3 years ago by simonmar

Would you also make -prof produce .p_o and .p_hi? This is quite a big change to make, and I suspect would break quite a lot of things (though I'm not sure exactly what).

comment:6 Changed 2 years ago by thoughtpolice


Punting to 8.2.1 (there's clearly more to discuss here that we don't have time for in the 8.x series).

comment:7 Changed 18 months ago by bgamari


Given that 8.2.1-rc1 is imminent, I'm bumping these off to the 8.4

comment:8 Changed 8 months ago by bgamari


This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

comment:9 Changed 6 months ago by bgamari

Milestone: 8.6.1

Removing milestone as there is no one actively working on this and we very much lack direction here.

Note: See TracTickets for help on using tickets.