Bug 1136939

Can you provide preprocessed method-to-ir.i and list what gcc options are used to compile it?  Thanks.

Created attachment 934142 [details]
method-to-ir.i

You are faster than I am :). Attaching method-to-ir.i & the command line used for build:

gcc -DHAVE_CONFIG_H -I. -I../..   -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP  -D__default_codegen__ -DUSE_COMPILER_TLS -I../.. -I../../eglib/src -I../../eglib/src    -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -fno-strict-aliasing -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes  -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -mbackchain -D__USE_STRING_INLINES -c method-to-ir.c

Can't reproduce this:
./cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain method-to-ir.i; as -o method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
	.hidden	mono_defaults
	.ident	"GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)"
	.section	.note.GNU-stack,"",@progbits

I think there a very similar problem on i386 building Hercules, which goes away when the cpu.c file is compiled with -O1

...
libtool: link: gcc -shared  -fPIC -DPIC  .libs/hconsole.o .libs/w32util.o .libs/strsignal.o .libs/impl.o .libs/config.o .libs/bldcfg.o .libs/panel.o .libs/history.o .libs/fillfnam.o .libs/ipl.o .libs/assist.o .libs/dat.o .libs/stack.o .libs/cpu.o .libs/vstore.o .libs/general1.o .libs/general2.o .libs/general3.o .libs/pfpo.o .libs/plo.o .libs/control.o .libs/crypto.o .libs/io.o .libs/decimal.o .libs/service.o .libs/scedasd.o .libs/losc.o .libs/chsc.o .libs/opcode.o .libs/diagnose.o .libs/diagmssf.o .libs/vm.o .libs/vmd250.o .libs/channel.o .libs/external.o .libs/float.o .libs/trace.o .libs/machchk.o .libs/vector.o .libs/xstore.o .libs/cmpsc.o .libs/sie.o .libs/qdio.o .libs/clock.o .libs/timer.o .libs/esame.o .libs/ieee.o .libs/dfp.o .libs/httpserv.o .libs/cgibin.o .libs/loadparm.o .libs/hsccmd.o .libs/cmdtab.o .libs/hao.o .libs/hscmisc.o .libs/sr.o .libs/ecpsvm.o   -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/.libs -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/decNumber/.libs -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/softfloat/.libs -L/home/dan/hercules/hercules-3.10/.libs ./.libs/libhercs.so ./.libs/libhercu.so ./.libs/libherct.so ./.libs/libhercd.so /home/dan/hercules/hercules-3.10/.libs/libhercu.so /home/dan/hercules/hercules-3.10/.libs/libhercs.so decNumber/.libs/libdecNumber.so softfloat/.libs/libsoftfloat.so -lltdl -lpthread -lrt -lz -lresolv -lnsl -lm -ldl -lbz2  -O2 -m32 -march=i686 -mtune=atom -O2 -m32 -march=i686 -mtune=atom -Wl,-z -Wl,relro -Wl,--warn-common -pthread -pthread   -pthread -Wl,-soname -Wl,libherc.so -o .libs/libherc.so
/usr/bin/ld: .libs/cpu.o: relocation R_386_GOTOFF against undefined symbol `.L1887' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

I'm working on the details now ...

(In reply to Jakub Jelinek from comment #3)
> Can't reproduce this:
> ./cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109
> -mtune=z10 -fno-strict-aliasing -mbackchain method-to-ir.i; as -o
> method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
> 	.hidden	mono_defaults
> 	.ident	"GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)"
> 	.section	.note.GNU-stack,"",@progbits

My bad, mono builds two versions - one with -fPIC and one without it and it is actually the -fPIC that makes the difference:

/usr/libexec/gcc/s390x-redhat-linux/4.9.1/cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain -fPIC method-to-ir.i; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
                 U .L2527
	.hidden	mono_defaults
	.ident	"GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)"
	.section	.note.GNU-stack,"",@progbits

(In reply to Dan Horák from comment #4)
> I think there a very similar problem on i386 building Hercules, which goes
> away when the cpu.c file is compiled with -O1

see bug #1106758 for details

for the record - gcc-4.9.1-9.fc21 doesn't fix this problem

Yes, the fix is not in -10.fc22 either, waiting for Honza to commit it to 4.9.

So, is this still a problem with latest gcc (4.9.2-3.fc2[12])?

(In reply to Jakub Jelinek from comment #9)
> So, is this still a problem with latest gcc (4.9.2-3.fc2[12])?

yes, it is

[sharkcz@devel3 mono]$ /usr/libexec/gcc/s390x-redhat-linux/4.9.2/cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain -fPIC method-to-ir.i; as -o method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
                 U .L2534
	.hidden	mono_defaults
	.ident	"GCC: (GNU) 4.9.2 20141217 (Red Hat 4.9.2-3)"
	.section	.note.GNU-stack,"",@progbits

Ok, reproduced with cross-compiler, reducing the testcase now.

Reduced testcase (-O2 -fPIC -m64):
struct { long q; } *h;
long a, b, g, j, k, *c, *d, *e, *f, *i;
long *baz (void);

static inline int
foo (void)
{
  switch (b)
    {
    case 0:
    case 2:
      return a++;
    case 3:
      return a++;
    case 1:
      a++;
    }
  return 0;
}

void
bar (void)
{
  for (;;)
    {
      foo ();
      switch (0)
	{
	case 0:
	  if (d)
	    {
	      f = baz ();
	      g = k++;
	      if (&h->q)
		{
		  j = *f;
		  h->q = *f;
		}
	      else
		i = (long *) (h->q = *f);
	      *c++ = (long) f;
	      e += 6;
	      break;
	    }
	  f = baz ();
	  g = k++;
	  if (&h->q)
	    {
	      j = *f;
	      h->q = *f;
	    }
	  else
	    i = (long *) (h->q = *f);
	  *c++ = (long) f;
	  e += 6;
	}
    }
}

Filed upstream now.

I can confirm mono builds fine with gcc-4.9.2-5.fc21.s390x

gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21

Package gcc-python-plugin-0.13-3.fc21, gcc-4.9.2-6.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gcc-python-plugin-0.13-3.fc21 gcc-4.9.2-6.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-2063/gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21
then log in and leave karma (feedback).

gcc-python-plugin-0.13-3.fc21, gcc-4.9.2-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.