#2083 Constant address parameters broken

closed-fixed
7
2013-05-25
2012-09-09
Anonymous
No

With two calls to memset() in the same function using constant expressions one of them will get the incorrect address. In fact, it appears to re-use the address of the first call.

Discussion

  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-09-09
     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-09-09

    membug.c contains build instructions, compiler version and more specifics of the problem which I'd meant to put in the description.

    This excerpt from membug.asm shows HL loaded with 0x8000 in both instances rather than 0x9000 in second as it should.

    ;membug.c:9: memset((char *)0x8000, 1, 0x1000);
    ld hl,#0x8000 ; Correct
    ld (hl), #0x01
    ld e, l
    ld d, h
    inc de
    ld bc, #0x0FFF
    ldir
    ;membug.c:10: memset((char *)0x8000 + 0x1000, 2, 0x1000);
    ld hl,#0x8000 ; WRONG
    ld (hl), #0x02
    ld e, l
    ld d, h
    inc de
    ld bc, #0x0FFF
    ldir
    ret
    _main_end::

     
  • Philipp Klaus Krause

    • priority: 5 --> 7
    • labels: 100692 -->
     
  • Philipp Klaus Krause

    This happens for all ports, and even for a trivial example:

    void g(void *);

    void f(void)
    {
    g((char *)0);
    g((char *)0 + 1);
    }

    will pass 0 to both calls. This issue might be related to #3564104.
    Increasing priority to 7, since bad code is generated silently.

    Philipp

     
  • Philipp Klaus Krause

    • summary: z80 memset bug --> Constant address parameters broken
     
  • Erik Petrich

    Erik Petrich - 2012-09-10

    Fixed in revision #8096.

    I don't think this is related to #3564104; the problem here occured when adding to a pointer literal the result of the addition was given the type of the pointer, including its original literal value. In bug #3564104, the base pointer is a variable, so there is no literal value to inadvertently copy with the type.

     
  • Erik Petrich

    Erik Petrich - 2012-09-10
    • assigned_to: nobody --> epetrich
    • labels: --> C-Front End
    • milestone: --> fixed
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks