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

2008-02-05 Thread 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



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

2007-11-21 Thread 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

2007-11-21 Thread 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