Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#10664 closed bug (fixed)

T8131 times out on master

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

Description

The testsuite test codeGen/should_fail/T8131 appears to time out on the master branch as of today. This isn't counted as a testsuite failure as it is a should-fail test, but nevertheless something is not right as it doesn't terminate despite being allowed to run for several minutes.

Change History (11)

comment:1 Changed 2 years ago by bgamari

I should note that there is no CPU usage while the test is running. It appears to be deadlocked.

comment:2 Changed 2 years ago by bgamari

The test runs for five minutes before being killed.

comment:3 Changed 2 years ago by rwbarton

Oh good, then the <<loop>> mentioned at ticket:8131#comment:17 is not hopeless to debug after all :)

comment:4 Changed 2 years ago by simonpj

Using -dshow-passes it appears to get <<loop>> when parsing the .cmm input file. I have no idea why.

Simon

comment:5 Changed 2 years ago by bgamari

Hmm, it seems like some knot-typing in FCode may be going wrong. I've been chasing this down with the profiler and -xc and it appears that we're getting stuck in StgCmmMonad.fixC. It appears that the only user of this is StgCmmExtCode.loopDecls.

comment:6 Changed 2 years ago by bgamari

The issue appears to be triggered by the fourth argument of the %memcpy call being non-constant,

// This fails
testMemcpy (W_ dst, W_ src, W_ l, W_ sz) {
  prim %memcpy(dst, src, l, sz);
  return ();
}

// This also fails
testMemcpy (W_ dst, W_ src, W_ l, W_ sz) {
  W_ a;
  a = 0;
  prim %memcpy(dst, src, l, a);
  return ();
}

// But this succeeds
testMemcpy (W_ dst, W_ src, W_ l, W_ sz) {
  prim %memcpy(dst, src, l, 0);
  return ();
}
Last edited 2 years ago by bgamari (previous) (diff)

comment:7 Changed 2 years ago by bgamari

It appears that this is due to a rework did of the C-- parser for the LLVM backend, 681973c31c614185229bdae4f6b7ab4f6e64753d. Here I wanted to enforce that the alignment passed to memcpy was a constant expression, as this is required by LLVM. Here I explicitly forced the alignment argument to %memcpy calls to ensure that pprPgmError fired. I did this as otherwise the should-fail test I introduced to test the feature would fail in the case of the NCG (which apparently sometimes never forces the alignment).

Admittedly this was a bit of a large hammer to just make some tests pass. I'm going to remove the seq and just only run the test against the LLVM backend.

Last edited 2 years ago by bgamari (previous) (diff)

comment:8 Changed 2 years ago by bgamari

Owner: set to bgamari

comment:9 Changed 2 years ago by Ben Gamari <ben@…>

In 64b6733e/ghc:

CmmParse: Don't force alignment in memcpy-ish operations

This was initially made in 681973c31c614185229bdae4f6b7ab4f6e64753d.
Here I wanted to enforce that the alignment passed to %memcpy was a
constant expression, as this is required by LLVM. However, this breaks
the knot-tying done in `loopDecls`, causing T8131 to hang.

Here I remove the `seq` and mark T8131 as `expect_broken` in the case
of the NCG, which doesn't force the alignment in this case.

Fixes #10664.

comment:10 Changed 2 years ago by bgamari

Resolution: fixed
Status: newclosed

comment:11 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

Note: See TracTickets for help on using tickets.