[Bug c/25200] New: ICE compiling GNU tar

[Bug c/25200] New: ICE compiling GNU tar

[andreas at florath dot net]

Hello!

When compiling GNU tar 1.15.1, it stopps with:

argp-help.c: In function 'make_hol':
argp-help.c:430: warning: comparison is always true due to limited range of
data type
argp-help.c: In function 'hol_append':
argp-help.c:831: warning: comparison is always true due to limited range of
data type
argp-help.c:1684:4: argp-help.c: In function '__argp_short_program_name':
argp-help.c:1675: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [argp-help.o] Error 1


uname -a: 
SunOS 5.8 Generic_108528-26 sun4u sparc SUNW,Sun-Fire-15000

gcc -v: 
Using built-in specs.
Target: sparcv9-sun-solaris2.8
Configured with: /appl/local/be8/tmp/gcc-4.1-20051125/configure
--prefix=/appl/local/be8/pkg/pre2 --enable-shared --enable-threads
--enable-languages=c,c++ --disable-libgcj --with-gnu-as
--with-as=/appl/local/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-as --with-gnu-ld
--with-ld=/appl/local/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-ld
--disable-multilib sparcv9-sun-solaris2.8
Thread model: posix
gcc version 4.1.0 20051125 (prerelease)

To reproduce: 
1) get GNU tar 1.15.1
2) untar the tarball :-)
3) cd tar-1.15.1
4) ./configure --host=sparcv9-sun-solaris2.8 --target=sparcv9-sun-solaris2.8
5) make

Other systems also fail:
sparcv9-sun-solaris2.8: gcc 4.0.2

Other systems known to work:
sparc-sun-solaris2.8: gcc 4.0.2

The gcc 4.0.2 versions uses binutils-2.16.1.
The gcc 4.1.0 20051125 version uses binutils-051130.

If you need other information, just drop me a mail.

Happy debugging 

Andre


-- 
           Summary: ICE compiling GNU tar
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: andreas at florath dot net
 GCC build triplet: sparcv9-sun-solaris2.8
  GCC host triplet: sparcv9-sun-solaris2.8
GCC target triplet: sparcv9-sun-solaris2.8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug c/25200] ICE compiling GNU tar

[belyshev at depni dot sinp dot msu dot ru]

------- Comment #1 from belyshev at depni dot sinp dot msu dot ru  2005-12-01 10:48 -------
(In reply to comment #0)
> If you need other information, just drop me a mail.

Please attach preprocessed source of argp-help.c as prescribed here: 
http://gcc.gnu.org/bugs.html#detailed


-- 

belyshev at depni dot sinp dot msu dot ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug c/25200] ICE compiling GNU tar

[andreas at florath dot net]

------- Comment #2 from andreas at florath dot net  2005-12-01 11:12 -------
Created an attachment (id=10377)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10377&action=view)
Preprocessed argp-help.c. file 

Hello!

Here the preprocessed argp-help.c.

Regards

Andre


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug c/25200] ICE compiling GNU tar

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-01 11:32:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug middle-end/25200] ICE compiling GNU tar

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-01 20:08 -------
Hmm, the preprocessed source file looks not all the way here:
it sends like
char *
__argp_short_program_name (void)
{

I don't know if this is becuase the preprocessor is seg faulting or it just did
not get uploaded fully?

Could you invoke the gcc comment which fails with -save-temps and -v and give
the output?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug middle-end/25200] ICE compiling GNU tar

[andreas at florath dot net]

------- Comment #4 from andreas at florath dot net  2005-12-02 08:15 -------

The file argp-help.i I uploaded is 82400 bytes, and also when I download the
file, it's again 82400 bytes (and also the same file). [One thing that confuses
me, is that the size in the attachment table is just 15.49 KB.]

Here is the sha1sum for argp-help.i: dd61b5cb304ea3bf8d61111c7484e7029239a319

Also my (local) file ends with 
char *
__argp_short_program_name (void)
{

The output of the compiler call is:

bash-2.03$ gcc -v -save-temps  -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -I.
-I. -I..     -g -O2 -MT argp-help.o -MD -MP -MF ".deps/argp-help.Tpo" -c -o
argp-help.o argp-help.c
Using built-in specs.
Target: sparcv9-sun-solaris2.8
Configured with: /appl/tmo/be8/tmp/gcc-4.1-20051125/configure
--prefix=/appl/tmo/be8/pkg/pre3 --enable-shared --enable-threads
--enable-languages=c,c++ --disable-libgcj --with-gnu-as
--with-as=/appl/tmo/be8/pkg/pre3/bin/as --with-gnu-ld
--with-ld=/appl/tmo/be8/pkg/pre3/bin/ld --disable-multilib
sparcv9-sun-solaris2.8
Thread model: posix
gcc version 4.1.0 20051125 (prerelease)
 /emc01/tmo/be8/pkg/pre3/bin/../libexec/gcc/sparcv9-sun-solaris2.8/4.1.0/cc1 -E
-quiet -v -I. -I. -I.. -iprefix
/emc01/tmo/be8/pkg/pre3/bin/../lib/gcc/sparcv9-sun-solaris2.8/4.1.0/ -MD
argp-help.d -MF .deps/argp-help.Tpo -MP -MT argp-help.o -MQ argp-help.o
-D__arch64__ -D__sparcv9 -DHAVE_CONFIG_H -DLIBDIR="/usr/local/lib" argp-help.c
-mcpu=v9 -fworking-directory -O2 -fpch-preprocess -o argp-help.i
ignoring nonexistent directory
"/emc01/tmo/be8/pkg/pre3/bin/../lib/gcc/sparcv9-sun-solaris2.8/4.1.0/../../../../sparcv9-sun-solaris2.8/include"
ignoring duplicate directory
"/appl/tmo/be8/pkg/pre3/lib/gcc/sparcv9-sun-solaris2.8/4.1.0/include"
ignoring nonexistent directory
"/appl/tmo/be8/pkg/pre3/lib/gcc/sparcv9-sun-solaris2.8/4.1.0/../../../../sparcv9-sun-solaris2.8/include"
ignoring duplicate directory "."
#include "..." search starts here:
#include <...> search starts here:
 .
 ..
 /emc01/tmo/be8/pkg/pre3/bin/../lib/gcc/sparcv9-sun-solaris2.8/4.1.0/include
 /usr/local/include
 /appl/tmo/be8/pkg/pre3/include
 /usr/include
End of search list.
argp-help.c:1684:4: <built-in>:0: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
bash-2.03$


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug preprocessor/25200] ICE compiling GNU tar

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-02 15:51 -------
I think this is related to PR 23541.  I wonder if we are printing out a warning
(or an error) while preprocessing which gives the ICE.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug preprocessor/25200] ICE compiling GNU tar

[andreas at florath dot net]

------- Comment #6 from andreas at florath dot net  2005-12-05 19:36 -------

--- reproducibility ---

It looks that there is some confusion about the reproducibility of
this or similar bugs (23541, 24039).  Therefore a small description:
I was trying to compile gcc and GNU binutils for sparc where the
executables are 64 bit and the programs also create (only) 64 bit
binaries.  The steps I did: ([X -> Y] means: run with X bit, create
binaries for Y bits)

(1) gcc [32 -> 32] using Solaris cc and Solaris ld, as, ar, ...
(2) GNU binutils [32 -> 64] compiled with (1) 
(3) gcc [32 -> 64] compiled with (1) and using (2)
(4) GNU binutils [64 -> 64] compiled with (3)
(5) gcc [64 -> 64] compiled with (3) and using (4)

This ICE was found using (5).

As far as I can see, the bug can be triggered by
(A) a broken cpp from (5)
    (i. e. wrong code and only the sparc 64 triggers it)
(B) a broken sparc 64 bit backend from (3)
    (i. e. bad code is generated for cpp from (5) which then triggers
    the ICE)
(C) broken binutils

When I try to compile GNU tar with (1) or (3), it works fine. So my
assumption is, that (B) is correct (and ignoring (C)).  Then the
keyword for this and the similar bugs should be something like
'wrong-code' and component 'middle-end'.


--- duplicate notification ---

It looks, that
argp-help.c:1684:4: warning: #warning No reasonable value to return
should be printed at the point of the ICE.

When I look at the stack trace for this bug, its (nearly) the same as
in 24039:

 ffffffff7f23c0fc strlen (1005b1a90, ffffffff7f3c2c70, 1005b1a90, 0, 45f310,
ffffffff7f3b4f50) + 7c
 000000010040b6cc _cpp_begin_message (1, 1, 1dbd13, 5b1800, 10063ad08,
100639e20) + 154
 0000000100409380 do_diagnostic (10062c350, 1, 1, 0, 3c, 10064ce18) + 14
 000000010040a218 _cpp_handle_directive (1, 0, 0, 0, 1004a8ea1, 1005d47e8) + b8
 0000000100414c6c _cpp_lex_token (10062c350, 0, ffffffffffffffff,
fffffffffffffff8, 0, ffffffff7de0c481) + c0

So I think this bug is a duplicate of 23541 and 24039.


--- further investigation ---

The next steps I'll do:

  (i) check gcc-4.1-20051202
 (ii) check gcc-4.2-20051203
(iii) run test-suites for (i) or (ii) and hope to find some existing
      tests that triggers this error.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug preprocessor/25200] ICE compiling GNU tar

[andreas at florath dot net]

------- Comment #7 from andreas at florath dot net  2005-12-07 12:37 -------
--- gcc-4.1-20051202 ---

Same behaviour: ICE compiling tar.

I run the testsuites, once for (3):
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00372.html
(3 ICEs)

and once for (5):
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00381.html
(468 ICEs - most are cpp related!)

Especially the gcc part is different (80 unexpected failures for (3) and 850
unexpected failures for (5)).

@Eric Botcazou: When you run the testsuites for Solaris V9, are you using 32 or
64 bit executables?  Are you using Solaris ld, as, ar or the GNU binutils? (I'm
asking this, because your results look much better than mine.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug preprocessor/25200] ICE compiling GNU tar

[ebotcazou at gcc dot gnu dot org]

------- Comment #8 from ebotcazou at gcc dot gnu dot org  2005-12-07 13:28 -------
> I run the testsuites, once for (3):
> http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00372.html
> (3 ICEs)

The configure line doesn't match the title of the report: the compiler has been
configured as a native 64-bit compiler.  How did you compile it?

> and once for (5):
> http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00381.html
> (468 ICEs - most are cpp related!)

Neither does it.  This one seems to be a native 64-bit compiler compiled by a
64-bit compiler, which is correct.


That's pretty confusing.  What are you trying to do?  If you want to build a
full 64-bit toochain, just build everything directly as 64-bit either with "cc
-xarch=v9" or "gcc -m64" and don't enter the 32/64-bit mixing game.

> @Eric Botcazou: When you run the testsuites for Solaris V9, are you using 32or
> 64 bit executables?  Are you using Solaris ld, as, ar or the GNU binutils?
> (I'm asking this, because your results look much better than mine.)

SPARC V9 is pretty confusing, SPARC64 is a much better moniker.  The
sparc-sun-solaris2.* compiler is a multilib 32-bit compiler and must be
compiled by a pre-existing 32-bit compiler (e.g. cc).  The
sparc64-sun-solaris2.* compiler a multilib 64-bit compiler and must be compiled
by a pre-existing 64-bit compiler (e.g. cc -xarch=v9).  Using any other
combination is asking for trouble.

The problem you have run into indeed seems to be a duplicate of 23541.  It
doesn't show up for me probably because libintl is configured differently.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-12-01 11:32:42         |2005-12-07 13:28:37
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug other/25200] ICE compiling GNU tar

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|preprocessor                |other
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug other/25200] ICE compiling GNU tar

[andreas at florath dot net]

------- Comment #9 from andreas at florath dot net  2005-12-10 12:09 -------
--- gcc-4.2-20051203 ---

No differences - same results as for the 4.1 version.

--- nameing ---

>>The configure line doesn't match the title of the report: the compiler has been
>>configured as a native 64-bit compiler.  

The first one I mispelled (it should be sparcv9-sun-solaris2.8 instead
of sparc64-sun-solaris2.8) - sorry! 

--- aim ---

My aim: build up a GNU binutils and gcc pair, running on SPARC 64 bit
and creating (by default, i. e. without specifying any compiler swicth)
SPARC 64 binaries.  Also the compiler compiling binutils and
boostrapping the compiler should be gcc.


>> How did you compile it?

Steps (in more detail) (Version of gcc here is 4.2-20051203):

(1) gcc [32 -> 32] using Solaris cc and Solaris ld, as, ar, ...
    Configured compiler with:
    /appl/tmo/be8/tmp/gcc-4.2-20051203/configure
--prefix=/appl/tmo/be8/pkg/pre1 --enable-shared --enable-threads
--enable-languages=c --disable-libgcj --enable-multilib sparc-sun-solaris2.8

(2) GNU binutils [32 -> 64] compiled with (1)
    Configured with:
    /appl/tmo/be8/tmp/binutils-051130/configure --enable-64-bit-bfd
--prefix=/appl/tmo/be8/pkg/pre2 --enable-bfd-assembler
--host=sparc-sun-solaris2.8 --target=sparcv9-sun-solaris2.8

(3) gcc [32 -> 64] compiled with (1) and using (2)
    Configured with:
    /appl/tmo/be8/tmp/gcc-4.2-20051203/configure
--prefix=/appl/tmo/be8/pkg/pre2 --enable-shared --enable-threads
--enable-languages=c,c++ --disable-libgcj --with-gnu-as
--with-as=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-as --with-gnu-ld
--with-ld=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-ld
--disable-multilib sparcv9-sun-solaris2.8

(4) GNU binutils [64 -> 64] compiled with (3)
    Configured with:
    /appl/tmo/be8/tmp/binutils-051130/configure --enable-64-bit-bfd
--prefix=/appl/tmo/be8/pkg/pre3 --enable-bfd-assembler
--host=sparcv9-sun-solaris2.8 --target=sparcv9-sun-solaris2.8

(5) gcc [64 -> 64] compiled with (3) and using (4)
    Configured with:
    /appl/tmo/be8/tmp/gcc-4.2-20051203/configure
--prefix=/appl/tmo/be8/pkg/pre3 --enable-shared --enable-threads
--enable-languages=c,c++ --disable-libgcj --with-gnu-as
--with-as=/appl/tmo/be8/pkg/pre3/bin/as --with-gnu-ld
--with-ld=/appl/tmo/be8/pkg/pre3/bin/ld --disable-multilib
sparcv9-sun-solaris2.8

This works quiet good.  When I use gcc (5) now, I'll get 64 bit
binaries - without the need to specify any compiler switch.


>> That's pretty confusing.  What are you trying to do?  If you want to build a
>> full 64-bit toochain, just build everything directly as 64-bit either with "cc
>> -xarch=v9" or "gcc -m64" and don't enter the 32/64-bit mixing game.

I think the steps I do is one way to get all the tools running and be sure that
everything is created with GNU tools.


>>>> @Eric Botcazou: When you run the testsuites for Solaris V9, are you using 32or
>>>> 64 bit executables?  Are you using Solaris ld, as, ar or the GNU binutils?
>>>> (I'm asking this, because your results look much better than mine.)
>
>>
>>SPARC V9 is pretty confusing, SPARC64 is a much better moniker.  The
>>sparc-sun-solaris2.* compiler is a multilib 32-bit compiler and must be
>>compiled by a pre-existing 32-bit compiler (e.g. cc).  The
>>sparc64-sun-solaris2.* compiler a multilib 64-bit compiler and must be compiled
>>by a pre-existing 64-bit compiler (e.g. cc -xarch=v9).  

So the test results (sparc64-*-*) are done with SOLARIS ld, as, ar, ...,
running 64 bit and producing 32 bit executables using the 32 bit backend? There
is no testsuite run for the 64 bit backend?

I know that the SPARC compiler is a multilib compiler - but I
explicitly disabled this: I really only need 64 bit executables.
(I'm not a SPARC expert, I just read the installation instructions
http://gcc.gnu.org/install/specific.html#sparcv9-x-solaris2
and thought that SPARC V9 and SPARC 64 are the same.)

>> Using any other combination is asking for trouble.

Is this, because nobody else had done this before?  :-) 

In my opinion, my way to get a 64 bit-only compiler is leagal - maybe
more complicated as just bootstrap with SUNs cc - but it should work.
If it does not work, there is a bug somewhere in the chain. (Hope
you agree with this?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug other/25200] ICE compiling GNU tar

[ebotcazou at gcc dot gnu dot org]

------- Comment #10 from ebotcazou at gcc dot gnu dot org  2005-12-10 13:42 -------
> >>The configure line doesn't match the title of the report: the compiler has
> >>been configured as a native 64-bit compiler.  
> 
> The first one I mispelled (it should be sparcv9-sun-solaris2.8 instead
> of sparc64-sun-solaris2.8) - sorry! 

You missed the point.  Look at the configure lines at the very bottom of the
first report, they are not in keeping with the title.  You configured your 3rd
compiler as a native sparcv9-sun-solaris2.8 compiler, while it should have been
configured as specified in the title.  And since you built it with a 32-bit
compiler, it cannot reasonably work.

> My aim: build up a GNU binutils and gcc pair, running on SPARC 64 bit
> and creating (by default, i. e. without specifying any compiler swicth)
> SPARC 64 binaries.  Also the compiler compiling binutils and
> boostrapping the compiler should be gcc.

The last point is irrelevant, as the very purpose of bootstrapping is precisely
to let GCC compile itself.  The compiler you start from doesn't matter.

Simply take the followig steps:
- build GNU Binutils as sparcv9-sun-solaris2.8 with "cc -xarch=v9"
- bootstrap GCC as sparcv9-sun-solaris2.8 with "cc -xarch=v9"
- rebuild GNU Binutils with GCC

You are less likely to make mistakes because you don't fiddle with 32-bit
stuff.

> (3) gcc [32 -> 64] compiled with (1) and using (2)
>     Configured with:
>     /appl/tmo/be8/tmp/gcc-4.2-20051203/configure
> --prefix=/appl/tmo/be8/pkg/pre2 --enable-shared --enable-threads
> --enable-languages=c,c++ --disable-libgcj --with-gnu-as
> --with-as=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-as --with-gnu-ld
> --with-ld=/appl/tmo/be8/pkg/pre2/bin/sparcv9-sun-solaris2.8-ld
> --disable-multilib sparcv9-sun-solaris2.8

That's wrong.  It should be configured like the Binutils in step 2.

> This works quiet good.

You're lucky then. :-)  Step 3 is definitely wrong.

> So the test results (sparc64-*-*) are done with SOLARIS ld, as, ar, ...,
> running 64 bit and producing 32 bit executables using the 32 bit backend?

No, sparc64-*-* is a 64-bit compiler generating 64-bit binaries.  It generates
32-bit binaries only when passed with -m32.

> There is no testsuite run for the 64 bit backend?

See above.

> I know that the SPARC compiler is a multilib compiler - but I
> explicitly disabled this: I really only need 64 bit executables.
> (I'm not a SPARC expert, I just read the installation instructions
> http://gcc.gnu.org/install/specific.html#sparcv9-x-solaris2
> and thought that SPARC V9 and SPARC 64 are the same.)

Yes they are, but we prefer sparc64-*-* over sparcv9-*-* (and the option
-mcpu=v9 doesn't cause 64-bit code to be generated).

> Is this, because nobody else had done this before?  :-) 

Yeah, not everyone is crazy enough to use 5 steps to get a 64-bit toolchain
while 2 are sufficient. :-)

> In my opinion, my way to get a 64 bit-only compiler is leagal - maybe
> more complicated as just bootstrap with SUNs cc - but it should work.

Except step 3.

> If it does not work, there is a bug somewhere in the chain. (Hope
> you agree with this?)

Yes, I agree that, if you fix step 3, that should theoritically work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200

[Bug other/25200] ICE compiling GNU tar

[ebotcazou at gcc dot gnu dot org]

------- Comment #11 from ebotcazou at gcc dot gnu dot org  2006-01-04 09:16 -------


*** This bug has been marked as a duplicate of 23541 ***


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25200