Bug 11018 - [3.3 regression] [SPARC] -mcpu=ultrasparc busts tar-1.13.25
Summary: [3.3 regression] [SPARC] -mcpu=ultrasparc busts tar-1.13.25
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.3
: P1 critical
Target Milestone: 3.3.1
Assignee: Eric Botcazou
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-28 16:38 UTC by partain
Modified: 2003-06-04 07:34 UTC (History)
1 user (show)

See Also:
Host: sparc-sun-solaris2.8
Target: sparc-sun-solaris2.8
Build: sparc-sun-solaris2.8
Known to work:
Known to fail:
Last reconfirmed: 2003-05-29 16:54:46


Attachments
Proposed fix. (780 bytes, patch)
2003-05-29 21:43 UTC, Eric Botcazou
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description partain 2003-05-28 16:38:47 UTC
GNU tar 1.13.25 (in alpha.gnu.org:gnu/tar/) fails 'make check' badly
on sparc-solaris8 if compiled with -mcpu=ultrasparc.  This is a regression
from many prev versions of GCC.  My table of what works and doesn't
for CFLAGS:

-g : OK on sparc-solaris8
-O : OK on sparc-solaris8
-O -mcpu=ultrasparc : not OK on sparc-solaris8
-O2 : OK on sparc-solaris8
-O2 -mcpu=ultrasparc : not OK on sparc-solaris8 (OK on ia32-linux-rh7.2)

I'd guess it's a miscompilation of to_octal in src/create.c

The symptom is that the resulting tar miscreates tar files (but
seems to read them fine).  Just look at bytes 101ff in a bad/good
tar file -- the mode/uid/gid things come out obviously busted.

Keep up the good work.
Comment 1 Wolfgang Bangerth 2003-05-28 23:55:07 UTC
In order to reproduce a bug, we need significantly more information.
Please review
  http://gcc.gnu.org/bugs.html
for this.

Thanks
  Wolfgang
Comment 2 partain 2003-05-29 09:28:54 UTC
Um... get a copy of the tar-1.13.25.tar.gz tarball from, uh, alpha.gnu.org
in directory 'gnu'.  Unpack it.  Configure with

CFLAGS="-O2 -mcpu=ultrasparc" ./configure
make all
make check

Virtually all of the 'make check' tests will fail, because it will be creating
duff tar archives.  Make a trivial archive with a good (GNU) tar.  Make a comparable
archive with the tar just built.  Look at the two tar archives, at about
byte 100.  Where one shows a unix 'mode' (etc), the busted one will be plainly
different.

If you go back and do CFLAGS=-O2 ./configure, everything should work fine.
Comment 3 Eric Botcazou 2003-05-29 12:06:08 UTC
Quoting the aforementioned document:

"What we do not want
[...]
The location (URL) of the package that failed to build (we won't download it,
anyway, since you've already given us what we need to duplicate the bug, haven't
you? :-)
[...]"

We have not the time and resources to download and debug every source tarball,
GNU software or not. Could you help us by narrowing down the problem to a single
source file (even better, a single function within the file) and following the
instructions of the document?

Thanks in advance.
Comment 4 partain 2003-05-29 15:56:10 UTC
Subject: Re:  [sparc] -mcpu=ultrasparc busts tar-1.13.25 on sparc-solaris8

> We have not the time and resources to download and debug every source tarball,
> GNU software or not. Could you help us by narrowing down the problem to a single
> source file (even better, a single function within the file) and following the
> instructions of the document?

Compile the code below (on a sparc-solaris box), with and
without -mcpu=ultrasparc, and note the different answers:

   % gcc -O2 bug-11xx.c 
   % ./a.out           
   value=010644, result=00010644
   % gcc -O2 -mcpu=ultrasparc bug-11xx.c 
   % ./a.out                            
   value=010644, result=00000004
   %

Will

=== start

typedef unsigned long long uint64_t;
typedef uint64_t uintmax_t;
typedef unsigned int size_t;

static void
to_octal (uintmax_t value, char *where, size_t size)
{
  uintmax_t v = value;
  size_t i = size;

  do
    {
      where[--i] = '0' + (v & ((1 << 3) - 1));
      v >>= 3;
    }
  while (i);
}

#include <stdio.h>
main ()
{
  char buf[1024];
  to_octal(010644,buf,8);
  printf("value=010644, result=%s\n",buf);
}

=== end
Comment 5 Eric Botcazou 2003-05-29 16:51:17 UTC
Thanks for this pretty testcase!

Confirmed as a regression from GCC 3.2.3 on 3.3 branch but not on mainline.
Comment 6 Eric Botcazou 2003-05-29 21:43:53 UTC
Created attachment 4111 [details]
Proposed fix.

The patch has not yet undergone the required round of testing.
Comment 7 Eric Botcazou 2003-06-04 07:34:58 UTC
See http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02417.html