pointer dereferencing code does not load the address

[GoogleCodeExporter]

testcase gcc.c-torture/execute/20001027-1.c (the date is actually barbara's
birthday ... ;)) fails with -O1,2,3,s.

a very simple testcase:

int x,*p=&x;

int main()
{
  int i=0;
  x=1;
  p[i]=2;
  if (x != 2)
    abort ();
  exit (0);
}

with -O0, the generated code is OK: address of p is loaded from the
appropriate symbol, array indexing translated to addition, and p[0] value
set OK.

with -O1, this gets compiled to:

    lds $s35,.LC1               # = &x        
    or  $s36,1,(0)1             # = 1
    stl $s36,0(,$s35)           # x = 1
    or  $s36,2,(0)1             # = 2
    stl $s36,0(,$s8)            # ????? wtf is $s8?!?!?
    ldl=    $s35,0(,$s35)           # load x
    cps $s35,$s35,$s36          # cmp x, 2
    bes $s35,.L2                # == 2 -> goto L2
    lds $s35,.LC3           # call abort()
        ...

now, address of p[0], where the 2 should be stored is supposed to be in
$s8. of course, $s8 contains nonsense, as it is not set to anything
meaningful. (actually, function prologue computes stack size ($s0 - $s2)
and stores result in $s8 to see if we should monc, but this has nothing to
do with p).

bizarre.

also, issue #83 could be manifestation of the same problem, it's just that
use of $s35 instead of $s8 there gives the impression that $s35 should live
accross function calls, as the proper value was (probably accidentaly)
stored in $s35 before. keeping them separate for the time being.

Original issue reported on code.google.com by jmoc...@gmail.com on 6 Jan 2009 at 2:30

[GoogleCodeExporter]

here is the minimal code that reproduces this:

----
int x, *px = &x;

void
ptrfuckup()
{
    *px = 1;
}
----

with -O1, this is compiled to an elegant assembly twoliner:

    or  $s36,1,(0)1
    stl $s36,0(,$s35)

(excluding pro- and epi-logue)

slightly indeterministic, wouldn't you say? ;)

Original comment by jmoc...@gmail.com on 6 Jan 2009 at 2:41

• Added labels: rotfl

[GoogleCodeExporter]

actually, this is the perfect oportunity to stress that no languages that allow 
any
side effects whatsoever should be allowed in a perfect world. just pure 
functional
ones, please.

Original comment by jmoc...@gmail.com on 6 Jan 2009 at 2:45

[GoogleCodeExporter]

this problem does not originate from rtl optimization passes, as the initial
expansion, 104r.expand for the minimal testcase is:

;; *px = 1
(insn 10 8 11 (set (reg:SI 134)
        (const_int 1 [0x1])) -1 (nil)
    (nil))

(insn 11 10 0 (set (mem:SI (reg/f:DI 133) [0 S4 A32])
        (reg:SI 134)) -1 (nil)
    (nil))

with (reg/f:DI 133) not being set anywhere, just referenced.

so this must come from tree optimization passes ... now, how does one tackle 
such a bug?

Original comment by jmoc...@gmail.com on 6 Jan 2009 at 3:20

[GoogleCodeExporter]

also testcases gcc.c-torture/execute/
20021024-1.c
20030828-1.c
950221-1.c
const-addr-expr-1.c
and probably some more of them from the gcc.dg testsuite ...

... all seem to suffer from this very bug as well. interesting enough, not with 
all
these testcases do all optimization levels >0 result in this bug, most of the 
time it
is {1,2,3,s}, but sometimes it is a subset of these. however, all these 
testcases
assign an address of some (often local var) to a global ptr and the reference 
it in
some function, ending up with code that assumes some bogus register contains the
address assigned to global ptr.

rotfl, indeed.

Original comment by jmoc...@gmail.com on 6 Jan 2009 at 3:55

[GoogleCodeExporter]

Issue 41 has been merged into this issue.

Original comment by jmoc...@gmail.com on 7 Jan 2009 at 10:30

[GoogleCodeExporter]

Issue 83 has been merged into this issue.

Original comment by jmoc...@gmail.com on 7 Jan 2009 at 10:31

[GoogleCodeExporter]

this is not triggered by any of the single -f... optimization switches implied 
by
-O1. :( trying all possible combinations would be a bit time consuming ...

Original comment by jmoc...@gmail.com on 7 Jan 2009 at 10:48

[GoogleCodeExporter]

gcc.c-torture/execute/20000706-4.c as well

Original comment by jmoc...@gmail.com on 12 Jan 2009 at 12:07

[GoogleCodeExporter]

and gcc.c-torture/execute/960521-1.c

bottom line is that with -O>0, addresses from pointers are sometimes (often) not
loaded to the register where the subsequent code (loading from/storing to that
address) expects them to be.

Original comment by jmoc...@gmail.com on 12 Jan 2009 at 12:50

• Added labels: wtf

[GoogleCodeExporter]

this is a never ending story ... gcc.c-torture/execute/990628-1.c

Original comment by jmoc...@gmail.com on 12 Jan 2009 at 1:22

[GoogleCodeExporter]

Issue 88 has been merged into this issue.

Original comment by jmoc...@gmail.com on 15 Jan 2009 at 12:20

[GoogleCodeExporter]

changed bug summary.

let's repeat what we've learned so far:

the bug surfaces in code that does pointer dereferencing.

it only occurs with higher optimization levels, with -O>0.

could be that the same is the case with some array indexing code.

also, the bug is present in the initial rtl expansion, so it probably really -
however improbable this sounds - stems from SSA optimization passes.

Original comment by jmoc...@gmail.com on 15 Jan 2009 at 12:24

• Changed title: pointer dereferencing code does not load the address

[GoogleCodeExporter]

Original comment by jmoc...@gmail.com on 15 Jan 2009 at 12:33

• Changed state: Started

[GoogleCodeExporter]

also, this simple test is a nice, runnable example:

----
extern void abort();

char c = 'A', *ptr = "B! I said B!";

int
main(int argc, char **argv)
{
    c = *ptr;
    if(c != 'B')
        abort();
}
----

fails with -O>0.

with -O1 it will segfault, because $s8 is (wrongly) assumed to hold ptr address.

Original comment by jmoc...@gmail.com on 15 Jan 2009 at 3:50

[GoogleCodeExporter]

just a thought: perhaps the relevant expand that should emit insn loading the
address, does not emit anything ...

Original comment by jmoc...@gmail.com on 15 Jan 2009 at 3:57

[GoogleCodeExporter]

some more ...

gcc.dg/20031216-1.c

Original comment by jmoc...@gmail.com on 30 Jan 2009 at 10:14

[GoogleCodeExporter]

fixed with r215.

Original comment by jmoc...@gmail.com on 30 Jan 2009 at 1:03

• Changed state: Fixed