Opened 12 months ago

Last modified 12 months ago

#16037 new bug

memcpy test inexplicably failing

Reported by: bgamari Owned by:
Priority: high Milestone: 8.8.1
Component: Compiler Version: 8.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

I have started seeing failures in the memcpy test:

  • codeGen/should_gen_asm/memcpy.run/memcpy.

    diff -uw "codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised" "codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised"
    old new  
    11callMemcpy:
     2subq
    23movq
    34movq
    45movl
    5 subq
    6 movl
     6xorl
    77call memcpy
    88addq
    99jmp

The failures aren't themselves concerning; the new assembler is perfectly valid:

.section .text
.align 8
.globl callMemcpy
.type callMemcpy, @function
callMemcpy:
.Lc6:
        movl $1024,%eax
        subq $8,%rsp
        movq %rax,%rdx
        movq %rbx,%rdi
        movq %r14,%rsi
        xorl %eax,%eax
        call memcpy
        addq $8,%rsp
        jmp *(%rbp)
        .size callMemcpy, .-callMemcpy
.section .note.GNU-stack,"",@progbits
.ident "GHC 8.7.20181211"

However, I have no explanation for why this suddenly started happening.

Change History (2)

comment:1 Changed 12 months ago by Ben Gamari <ben@…>

In 251db979/ghc:

testsuite: Try accepting new output for memcpy test

See #16037.

comment:2 Changed 12 months ago by bgamari

I have accepted the new output but would really like to understand why this changed. I believe the change arose somewhere between 856dd66fc9c6416b2f62c8f2ac8bb61f4a48b859 and 65fb69b78f4850b56ee6a2655bc5dc6c441a984e.

Note: See TracTickets for help on using tickets.