Testcase required.

Subject: Re:  gcc 4.5.0 miscompiles binutils

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rguenth at gcc dot gnu dot org schrieb:
> ------- Comment #1 from rguenth at gcc dot gnu dot org  2009-10-19 11:00 -------
> Testcase required.
> 
> 

Richard, some advice how to create a testcase for this particular issue would be
appreciated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrcUOMACgkQoUhjsh59BL5teACfQuLfIIXop524bwIJ2XUyjAuK
8kMAoKlEtN8uv1qnV4TsHWEs9eEoVd2P
=MQ4R
-----END PGP SIGNATURE-----

Forgot to mention that's with binutils 2.20 and binutils head.

For a suspected wrong-code bug, the standard way to create a testcase is to first find out if there are gcc options with which you get the expected result (such as it works when compiled with -O0, doesn't when compiled with -O2), or, if even at -O0 new gcc misbehaves some other compiler version.
Then either guess or do a binary search between objects compiled with a known good and known bad options to narrow it down to a particular source file.
Then try -fno-inline on that file to see if it is still bad, if it is, it will be far easier, as no inlining is performed and thus fn boundaries are clearer.
In any case either guess the miscompiled function or play with attribute optimize (known to have issues though) or splitting source file into several smaller ones to do a binary search to a particular function.
Last, find out what arguments it has been called with and try to emulate that inside of a main, just preparing the right arguments (and what they point to etc.), then calling only the problematic function.  And, stub all (noninlined) functions the problematic function calls, with something that gives back the right result, use noinline attribute on it and possibly asm volatile ("":::"memory"); to prevent it being optimized.  Remove any unnecessary stuff, provide it as preprocessed source, which can be run and show clearly a bad vs. good behavior (say exit 0 in the right case, abort otherwise).

works when build with "-g -O0" and "-g -O1".
fails when build with "-g -O2" and "-g -O3".

Try also -g -O2 -fno-strict-aliasing, if that one works, look for aliasing warnings.

Subject: Re:  gcc 4.5.0 miscompiles binutils

jakub at gcc dot gnu dot org wrote:
> ------- Comment #6 from jakub at gcc dot gnu dot org  2009-10-19 15:21 -------
> Try also -g -O2 -fno-strict-aliasing, if that one works, look for aliasing
> warnings.
> 
> 

works when build with "-g -O2 -fno-ipa-sra" and "-g -O3 -fno-ipa-sra".

So, that's the easy part. Try to get further. Any help appreciated.

fails when build with "-g -O1 -fipa-sra".

So, the ipa-sra pass causes the issue, no?

build with "-g -O1 -fipa-sra -fno-inline" I get the following backtrace:

Core was generated by `ia64-unknown-linux-gnu-ld --verbose --sysroot=/opt/devel/tec/setup/sys-root/Lin'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000043c3e3 in get_got (abfd=0x711300, info=<value optimized out>) at elf64-ia64.c:2073
2073      return x->addend < y->addend ? -1 : x->addend > y->addend ? 1 : 0;
(gdb) where
#0  0x000000000043c3e3 in get_got (abfd=0x711300, info=<value optimized out>) at elf64-ia64.c:2073
#1  0x000000000043c9bc in elf64_ia64_check_relocs (abfd=<value optimized out>, info=0x6ead00, sec=<value optimized out>, relocs=<value optimized out>) at elf64-ia64.c:2073
#2  0x0000000000459a52 in elf_link_add_object_symbols (abfd=<value optimized out>, info=<value optimized out>) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:477
#3  0x0000000000459e85 in bfd_elf_link_add_symbols (abfd=<value optimized out>, info=<value optimized out>) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:477
#4  0x000000000040f947 in load_symbols (entry=0x6eb1e0, place=<value optimized out>) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:353
#5  0x000000000040fea4 in open_input_bfds (s=0x6eb1e0, force=0) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:353
#6  0x000000000041217e in lang_process () at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:353
#7  0x0000000000414cc0 in main (argc=27, argv=0x7fffa21c0d78) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldmain.c:1383
(gdb) 

The line numbers in the traceback in comment #9 are completly bogus. I had to upgrade my gdb to version 0.7. Now it looks much better:

Core was generated by `ia64-unknown-linux-gnu-ld --verbose --sysroot=/opt/devel/tec/setup/sys-root/Lin'.
Program terminated with signal 11, Segmentation fault.
#0  get_got (abfd=0x711300, info=<value optimized out>) at elf64-ia64.c:2418
2418          if (!bfd_set_section_alignment (abfd, got, 3))
(gdb) where
#0  get_got (abfd=0x711300, info=<value optimized out>) at elf64-ia64.c:2418
#1  0x000000000043c9bc in elf64_ia64_check_relocs (abfd=<value optimized out>, info=0x6ead00, sec=<value optimized out>, relocs=<value optimized out>) at elf64-ia64.c:2973
#2  0x0000000000459a52 in elf_link_add_object_symbols (abfd=<value optimized out>, info=<value optimized out>) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:4774
#3  0x0000000000459e85 in bfd_elf_link_add_symbols (abfd=<value optimized out>, info=<value optimized out>) at /opt/devel/gnu/src/gcc/binutils-2.20/bfd/elflink.c:5097
#4  0x000000000040f947 in load_symbols (entry=0x6eb1e0, place=<value optimized out>) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:2707
#5  0x000000000040fea4 in open_input_bfds (s=0x6eb1e0, force=0) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:3138
#6  0x000000000041217e in lang_process () at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldlang.c:6287
#7  0x0000000000414cc0 in main (argc=27, argv=0x7fffa21c0d78) at /opt/devel/gnu/src/gcc/binutils-2.20/ld/ldmain.c:455
(gdb) 

verified that compiling only bfd/elf64-ia64.c with -fno-ipa-sra is sufficient to get a working ia64-unknown-linux-gnu-ld.

First of all, it's nearly impossible to create a short self contained test case, at least for me. The function get_got in bfd/elf64-ia64.c shows the issue.
Resolving the dependencies of this function is like opening a can of worms.

What I have:
I verified that enclosing only the get_got function in 
#pragma GCC optimize ("ipa-sra", "no-inline")
.
.
#pragma GCC reset_options
yields the fault.

In contrast enclosing the get_got function in
#pragma GCC optimize ("no-ipa-sra", "no-inline")
.
.
#pragma GCC reset_options
gives a working ia64-unknown-linux-gnu-ld.

I'm attaching both versions as preprocessed source.

compiling these with gcc -g -O2 -S produces the correspondent assembler output, also attached.

Created attachment 18841 [details]
preproccessed source

no-ipa-sra, no-inline

Created attachment 18842 [details]
preproccessed source

ipa-sra, no-inline

Created attachment 18843 [details]
assembler output

Created attachment 18844 [details]
assembler output

Revision 152433 is OK and revision 152642 is bad.

This is another IPA-SRA bug.

I have downloaded binutils 2.20 and compiled the file on a native ia64
compiler.  I have only managed to look at the dumps but so far could
not see any problem there.  I will have another look on Thursday.

(In reply to comment #19)
> I have downloaded binutils 2.20 and compiled the file on a native ia64
> compiler.  I have only managed to look at the dumps but so far could
> not see any problem there.  I will have another look on Thursday.
> 

I'm not sure, but by my impression that's a host issue, no? So, I doubt that working on target will get you any further.

(In reply to comment #20)
> I'm not sure, but by my impression that's a host issue, no? So, I doubt that
> working on target will get you any further.
> 

Perhaps, I don't know (or do you mean that you know that the native
compiler does not have this problem?).  I have also built a
cross-compiler x86_64->ia64 but when I feed the attachment in comment
#14 to it, it segfaults at -O2 regardless of -fno-ipa-sra (it
segfaults at /home/jamborm/gcc/mine/gcc/config/ia64/ia64.c:7032).

Nevertheless, I can get the IPA-SRA dump file from the cross compiler
and it is (as I belive it should be) almost identical to the one from
the native compiler and I still don't see any problem there.  I admit
that at the moment I am not sure what to look at next...

IPA-SRA miscompiled get_got in elf64-ia64.c:

  got = ia64_info->root.sgot;
  if (!got)
    {
      flagword flags;

      dynobj = ia64_info->root.dynobj;
      if (!dynobj)
        ia64_info->root.dynobj = dynobj = abfd;
      if (!_bfd_elf_create_got_section (dynobj, info))
        return 0;

      got = ia64_info->root.sgot;

ia64_info->root.sgot is NULL and _bfd_elf_create_got_section is called
to create one. However, IPA-SRA turns

get_got (struct bfd * abfd, struct bfd_link_info * info, struct elf64_ia64_link_hash_table * ia64_info)

into

get_got (struct bfd * abfd, struct bfd_link_info * info, struct bfd * * ISRA.111, struct asection * ISRA.112)

Where does "struct asection * ISRA.112" come from? It doesn't look right.

It then generates:

<bb 5>:
  # dynobj_3 = PHI <dynobj_6(3), abfd_7(D)(4)>
  # DEBUG dynobj => dynobj_3
  D.16894_10 = _bfd_elf_create_got_section (dynobj_3, info_9(D));
  if (D.16894_10 == 0)
    goto <bb 10>;
  else
    goto <bb 6>;

<bb 6>:
  got_12 = ISRA.112_15(D);

and later we get

  # dynobj_362 = PHI <dynobj_361(104), abfd_39(D)(105)>
  # DEBUG dynobj => dynobj_362
  D.18569_363 = _bfd_elf_create_got_section (dynobj_362, info_35(D));
  if (D.18569_363 == 0)
    goto <bb 111>;
  else
    goto <bb 107>;

<bb 107>:
  got_364 = D.18212_262;

Withot IPA-SRA, we get

  D.16894_10 = _bfd_elf_create_got_section (dynobj_3, info_9(D));
  if (D.16894_10 == 0)
    goto <bb 10>;
  else
    goto <bb 6>;

<bb 6>:
  got_12 = ia64_info_4(D)->root.sgot;

Created attachment 18930 [details]
A testcase

[hjl@gnu-6 pr41750]$ make clean
rm -f *.o *.s *.c.*
[hjl@gnu-6 pr41750]$ make CFLAGS="-O -fipa-sra"
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -fipa-sra   -c -o foo.o foo.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -fipa-sra   -c -o main.o main.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -o foo foo.o main.o
./foo
make: *** [all] Error 1
[hjl@gnu-6 pr41750]$ make clean
rm -f *.o *.s *.c.*
[hjl@gnu-6 pr41750]$ make CFLAGS=-O
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O   -c -o foo.o foo.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O   -c -o main.o main.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -o foo foo.o main.o
./foo
[hjl@gnu-6 pr41750]$

Thanks for the simple testcase, it has certainly helped me.  I have
sent a patch to address this issue to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01814.html

Subject: Bug 41750

Author: jamborm
Date: Mon Nov  2 14:13:49 2009
New Revision: 153809

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153809
Log:
2009-11-02  Martin Jambor  <mjambor@suse.cz>

	PR tree-optimization/41750
	* tree-sra.c (analyze_modified_params): Loop over all
	representatives of components of a parameter.

	* testsuite/gcc.c-torture/execute/pr41750.c: New test.


Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-sra.c

Tthis is now fixed.

Subject: Bug 41750

Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20  H.J. Lu  <hongjiu.lu@intel.com>

	Backport from mainline:
	2009-11-18  Alexandre Oliva  <aoliva@redhat.com>

	PR debug/41926
	* gcc.dg/vect/vect-debug-pr41926.c: New.

	2009-11-16  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/42055
	* g++.dg/template/crash92.C: New.

	2009-11-08  Richard Guenther  <rguenther@suse.de>

	PR rtl-optimization/41928
	* gfortran.dg/pr41928.f90: New testcase.

	2009-11-06  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/41935
	* gcc.dg/pr41935.c: New test.
	* c-c++-common/pr41935.c: New test.
	* gcc.c-torture/execute/pr41935.c: New test.

	2009-11-04  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/41919
	* gcc.c-torture/execute/pr41919.c: New testcase.

	2009-11-03  Tobias Burnus  <burnus@net-b.de>

	PR fortran/41907
	* gfortran.dg/missing_optional_dummy_6.f90: New test.

	2009-11-02  Martin Jambor  <mjambor@suse.cz>

	PR tree-optimization/41750
	* gcc.c-torture/execute/pr41750.c: New test.

	2009-11-02  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/41841
	* gcc.dg/pr41841.c: New test.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c
      - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C
      - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c
      - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c
      - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c
      - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c
      - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c
      - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c
      - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90
      - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90
      - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90
Modified:
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog