[Bug c/34161] New: -Os produces 32-bit load from 16-bit variable

[Bug c/34161] New: -Os produces 32-bit load from 16-bit variable

[vegard at peltkore dot net]

When compiling the following program with -Os, the short member x of struct a
is read using a movl instruction instead of movzwl.

struct a {
        int dummy;
        short x;
};

struct b {
        unsigned short x;
};

extern void dummy(struct b *b);

void f(struct a *a, struct b *b)
{
        dummy(b);

        if (a) {
                asm("/* THIS FIELD IS ONLY 16 BITS */");
                b->x = a->x;
        }
}

With -O3:
        movzwl  4(%ebx), %eax
        movw    %ax, (%esi)

And -Os:
        movl    4(%ebx), %eax
        movw    %ax, (%esi)


-- 
           Summary: -Os produces 32-bit load from 16-bit variable
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vegard at peltkore dot net
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161

[Bug c/34161] -Os produces 32-bit load from 16-bit variable

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-20 15:41 -------
What's wrong?  The x member is properly aligned, so a load beyond it is valid.
If you make struct a packed, then the load uses movw.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161

[Bug target/34161] -Os produces 32-bit load from 16-bit variable

[vegard at peltkore dot net]

------- Comment #2 from vegard at peltkore dot net  2007-11-21 11:05 -------
It can trigger watchpoints on other members. Try this example:

struct s {
        int dummy;
        short x;
        short y;
};

void dummy(struct s *b) { }

void f(struct s *a, struct s *b) {
        dummy(b);

        if (a) 
                b->x = a->x;
}

static struct s x;
static struct s y;

int
main()
{
        f(&x, &y);
        return 0;
}

That code never touches the y member of struct s. Yet when we run this in GDB,
we get this:

(gdb) rwatch x.y
Hardware read watchpoint 1: x.y
(gdb) run
Starting program: .../a.out 

Hardware read watchpoint 1: x.y

Value = 0
0x080483c2 in main () at movzwl.c:17
17                      b->x = a->x;


And this doesn't really make that much sense unless you know what's going on.
I'd say that following the principle of least surprise, this optimization is
unfortunate at the very least.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161

[Bug target/34161] -Os produces 32-bit load from 16-bit variable

[manu at gcc dot gnu dot org]

------- Comment #3 from manu at gcc dot gnu dot org  2007-11-21 13:06 -------
(In reply to comment #2)
> 
> And this doesn't really make that much sense unless you know what's going on.
> I'd say that following the principle of least surprise, this optimization is
> unfortunate at the very least.

Users would be surprised if optimized programs perform suboptimal operations
when better code is possible. Please, take into account that.

Now, what is unfortunate is that the hardware watchpoint triggers there.
Perhaps the debug information could tell GDB to ignore the read, or perhaps GDB
could figure it out by itself since the data read is never used. I personally
don't see a satisfactory way to solve all the issues here. And this bug report
is not the proper place. If you think there is a way to satisfy all issues, you
can discuss your proposal with the GDB hackers (http://sourceware.org/ml/gdb/).
Nonetheless, it seems to me that if a read occurs and the user sets a read
watchpoint, then the user should be informed of it. As Richard said, if you
don't want the read to occur at all, you can use "packed".

Also, you must take into account that debugging when optimisation is enabled is
always going to be problematic. We aim to produce the most accurate debug
information possible in that case, but disabling optimizations would be a
contradiction since you could always debug with optimisations disabled if you
wish.

I hope this answer satisfies you.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161

[Bug target/34161] -Os produces 32-bit load from 16-bit variable

[vegard dot nossum at gmail dot com]

------- Comment #4 from vegard dot nossum at gmail dot com  2008-02-05 09:23 -------
Is there a work-around, i.e. a command-line flag that turns _this particular_
kind of optimization off (without turning off all optimizations)? It seems that
the behaviour is found in -O1 and -O2 as well, in certain cases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161