Created attachment 18567 [details]
gzipped preprocessed source file

Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference.

/gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include    -c  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I ../gcc -Ijava -I/gnu/gcc/gcc-unpatched/gcc -I/gnu/gcc/gcc-unpatched/gcc/java -I/gnu/gcc/gcc-unpatched/gcc/../include -I/gnu/gcc/gcc-unpatched/gcc/../libcpp/include -I/usr/include -I/usr/include -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber/dpd -I../libdecnumber    /gnu/gcc/gcc-unpatched/gcc/java/expr.c -o java/expr.o --save-temps -g0

(In reply to comment #2)
> Unsurprisingly, 

Oops, sorry, wrong PR!  I was on the wrong browser tab.  Apologies.

Is this just because of the use of random number generators to name symbols with internal linkage, or is there some actual difference that -fcompare-debug detects?  (-fcompare-debug uses -frandom-seed to avoid the differences).

There is a real difference, i.e.

- 179:  mov    0x8(%ebp),%edx
- 17c:  movzwl (%edx),%eax
+ 179:  mov    0x8(%ebp),%esi
+ 17c:  movzwl (%esi),%eax

[...]

- 1a0:  mov    %edx,(%esp)
- 1a3:  mov    %edx,-0x24(%ebp)
- 1a6:  call   1a7 <_Z8copy_rtxP7rtx_def+0x37>
- 1ab:  mov    %eax,%ecx
- 1ad:  movzbl 0x3(%eax),%eax
- 1b1:  mov    %eax,%esi
- 1b3:  and    $0xffffffdf,%eax

[...]

+ 1a0:  mov    %esi,(%esp)
+ 1a3:  call   1a4 <_Z8copy_rtxP7rtx_def+0x34>
+ 1a8:  mov    %eax,%edi
+ 1aa:  movzbl 0x3(%eax),%eax
+ 1ae:  mov    %eax,%ecx
+ 1b0:  and    $0xffffffdf,%eax
+ 1b3:  mov    %al,0x3(%edi)

etc.

-fcompare-debug produces  -fcompare-debug failure (length)

Created attachment 18813 [details]
gzipped preprocessed source file

Another case. Compile with:

cc1 -O3 -march=i686 -g tree-eh.i


-    2fb6:      sub    $0xdc,%esp
+    2fb6:      sub    $0xcc,%esp

[...]

-    38f2:      mov    $0x1,%edi
-    38f7:      movb   $0x0,-0x98(%ebp)
-    38fe:      mov    %edx,-0x9c(%ebp)
-    3904:      cmp    %eax,(%ecx)
-    3906:      jne    3ad9 <execute_cleanup_eh+0xb29>

[...]

+    38f2:      xor    %edi,%edi
+    38f4:      cmp    %eax,(%ecx)
+    38f6:      jne    3ac3 <execute_cleanup_eh+0xb13>
+    38fc:      mov    0x0,%eax
+    3901:      xor    %esi,%esi

Confirmed, for -m32 -march=i686 -O3 -g vs. -g0 generates different code on:
typedef struct { int t; } *T;
struct S1 { unsigned s1; };
struct S2 { struct S1 s2; };
struct S3 { unsigned s3; struct S2 **s4; };
struct S5 { struct S2 *s5; };

extern void fn0 (void) __attribute__ ((__noreturn__));
T fn6 (struct S3);
void fn7 (void);

int
fn1 (const struct S1 *x)
{
  return x->s1;
}

int
fn2 (const struct S1 *x, unsigned y)
{
  if (y >= x->s1)
    fn0 ();
  return 0;
}

int
fn3 (struct S3 x)
{
  return (x.s3 == fn1 (*x.s4 ? &(*x.s4)->s2 : 0));
}

int
fn4 (struct S3 x)
{
  return fn2 (&(*x.s4)->s2, x.s3);
}

int
fn5 (struct S3 x, T *y)
{
  if (!fn3 (x))
    {
      *y = (T) (long) fn4 (x);
      return 1;
    }
  return 0;
}

void
test (struct S5 *x)
{
  struct S3 a;
  T b;
  unsigned char c = 0;
  a.s4 = &x->s5;
  while (fn5 (a, &b))
    if (!(b->t & 8))
      c = 1;
  a.s4 = &x->s5;
  while ((b = fn6 (a)))
    ;
  if (!c)
    fn7 ();
}

NONDEBUG_INSN_P differences start appearing in DSE1, looking into it.

Actually, it is not DSE1 but already loop-invariant.c, and the difference is in max_reg_pressure of the current loop (4 vs. 5 for one of the classes).

Created attachment 18832 [details]
gcc45-pr41340.patch

Patch I'm going to bootstrap/regtest.

Subject: Bug 41340

Author: jakub
Date: Tue Oct 20 13:29:08 2009
New Revision: 153011

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153011
Log:
	PR debug/41340
	* loop-invariant.c (calculate_loop_reg_pressure): Don't count regs
	referenced just in DEBUG_INSNs.

	* gcc.dg/pr41340.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr41340.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/loop-invariant.c
    trunk/gcc/testsuite/ChangeLog

The original rtl.ii.gz testcase compiles just fine with -fcompare-debug too (though, it surely used to be something different, as those loop-invariant.c changes are from end of September).

The original testcase still fails with -fcompare-debug with GCC 4.5.0 20091022. This bug is now tracked here: bug 41806.

The second bug is indeed fixed.