Bug 10922 - [Darwin] Internal error: Illegal instruction (program cc1plus)
Summary: [Darwin] Internal error: Illegal instruction (program cc1plus)
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL: http://cci.lbl.gov/~rwgk/bugs/mac_os/...
Keywords:
Depends on: 11070 11072
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-22 01:40 UTC by Ralf W. Grosse-Kunstleve
Modified: 2003-07-05 19:36 UTC (History)
1 user (show)

See Also:
Host: powerpc-apple-darwin6.6
Target: powerpc-apple-darwin
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-05-31 05:22:17


Attachments
preprocessed source (171.16 KB, application/octet-stream)
2003-05-22 02:05 UTC, Giovanni Bajo
Details
gcc 3.4 preprocessed source (163.02 KB, application/octet-stream)
2003-05-31 05:09 UTC, Dara Hazeghi
Details
gcc 3.4 error log (964 bytes, text/plain)
2003-05-31 05:13 UTC, Dara Hazeghi
Details
fixed 3.4 preprocessed sources (149.51 KB, text/plain)
2003-06-03 01:15 UTC, Wolfgang Bangerth
Details
fixed 3.4 preprocessed sources (149.51 KB, application/octet-stream)
2003-06-03 01:17 UTC, Wolfgang Bangerth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf W. Grosse-Kunstleve 2003-05-22 01:40:38 UTC
% uname -a
Darwin coral.lbl.gov 6.6 Darwin Kernel Version 6.6: Thu May  1 21:48:54 PDT 
2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC  Power Macintosh powerpc

gcc (GCC) 3.3
Configured with: ./configure --prefix=/usr/local_cci/gcc-3.3 --enable-
languages=c,c++

g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2 -
Ilibtbx/include -I/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx/include -
I/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/include -
I/net/cci/rwgk/boost_releases/1_30_0/mac/boost -
I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -
c /net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/array_family/boost_python/flex_
bool.cpp
g++: Internal error: Illegal instruction (program cc1plus)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

% g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2 -
Ilibtbx/include -I/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx/include -
I/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/include -
I/net/cci/rwgk/boost_releases/1_30_0/mac/boost -
I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -
E /net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/array_family/boost_python/flex_
bool.cpp > flex_bool_pp.cpp

% g++ -fPIC -ftemplate-depth-120 -w -O3 -c flex_bool_pp.cpp
g++: Internal error: Illegal instruction (program cc1plus)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

The preprocessed file is available here:
http://cci.lbl.gov/~rwgk/bugs/mac_os/gcc_3_3_flex_bool_pp.cpp

Additional comments:
The same Internal error appears for several of our source code files.
Some of these files compile if they are first preprocessed with -E,
followed by compilation of the preprocessor output as shown above.
Some files compile only with -O0. Of these some compile only if first
preprocessed.
Comment 1 Giovanni Bajo 2003-05-22 02:05:39 UTC
Created attachment 4049 [details]
preprocessed source
Comment 2 Dara Hazeghi 2003-05-25 08:06:33 UTC
Hello,

I can confirm that this testcases crashes here too with gcc 3.3. Unfortunately the testcase will not 
compile with gcc mainline for other reasons. Would it be possible to explain how to get and build 
the original source file, so as to check whether this problem is present in mainline gcc? Thanks,

Dara
Comment 3 Ralf W. Grosse-Kunstleve 2003-05-26 04:25:53 UTC
All the code involved is unrestricted open source. However, to reproduce the 
bug you'd need to install Python 2.3b1 (also open source) as root. If that's 
acceptable I'd be happy to create a self-contained source code bundle incl. 
instructions. I think it would be worth it because it brings to light some 
other bugs:

- Undefined symbols while linking that (sometimes) go away if the code is 
rearranged.

- Segmentation faults and bus errors when using -O3 instead of -O0.

You could also use our code to verify that the gcc 3.3 optimizer is broken 
under Redhat 8 (where you could use the Python that comes with the OS).
Comment 4 Dara Hazeghi 2003-05-26 06:14:32 UTC
Hello,

I can install the necessary python. If you can e-mail me (or attach to this report) the necessary 
instructions, that'd be great. Thanks,

Dara
Comment 5 Ralf W. Grosse-Kunstleve 2003-05-27 06:22:57 UTC
The full source for reproducing the internal compiler error is available here:

http://cci.lbl.gov/~rwgk/bugs/mac_os/scitbx_2003_05_26.tar.gz

Unpack and follow the instruction in the file README.

For the records, here is content of the README file:

Regarding:

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

Under Mac OS 10.2 get and unpack the file

  http://www.python.org/ftp/python/2.3/Python-2.3b1.tgz

and install with the commands:

  ./configure --enable-framework
  make
  make frameworkinstall

The last command requires root privileges because the target directory is:
  /Library/Frameworks/Python.framework/Versions/2.3
"make frameworkinstall" will also create softlinks in /usr/local/bin.
In the following it is assumed that /usr/local/bin is on $PATH and that
the command "python" resolves to /usr/local/bin/python.

It is also assumed that g++ is gcc 3.3.

The internal compiler error is very elusive. Slight changes to the
header files make it go away for certain source code files, and make
it appear for others. Here is what I hope you can use to reproduce
the bug very quickly:

  mkdir build
  cd build
  python ../libtbx/configure.py --build=quick cctbx
  source setpaths.csh
  libtbx.scons cctbx/sgtbx/boost_python/rt_mx.os

If this works for you try:

  libtbx.scons -k .

This will take a while but hopefully you will see a failure for at
least one of the files. The output on my computer is in the file:

  build.log

If for some odd reason everything works on your computer try this:

  mkdir build
  cd build
  python ../libtbx/configure.py cctbx
  source setpaths.csh
  libtbx.scons -k .

This compiles with full optimization (-O3) and results in several
internal compiler errors on my computer.

If you get to the point where all files compile and link without
errors you can run our regression tests with this command:

  python $SCITBX_DIST/run_tests.py

This should show many "OK". It is known to work under Redhat 8 with
both gcc 3.2 and gcc 3.3 (latter with -O0 only, -03 breaks one test).
It also works under Tru64 Unix and IRIX using the native C++ compilers.

About the source code:

- boost (http://www.boost.org/) is the CVS snapshot from 2003-05-26 ca.
  2:15pm Pacific time.

- libtbx, boost_adaptbx, scitbx, cctbx are CVS snapshots of modules in
  the http://cctbx.sourceforge.net/ project.

- scons == SCons 0.14, http://www.scons.org/
  SCons is a build tool (replacing make) implemented in pure Python.
  There is no C++ code in this directory.

I hope this is useful. It took me a long time to put everything together
in a clean way. Please don't hesitate to ask questions about this package:
rwgk@yahoo.com
Comment 6 Ralf W. Grosse-Kunstleve 2003-05-27 22:51:59 UTC
A new observation: simply moving the source code directory and the build 
directory to different locations makes the internal compiler error go away for 
certain sources and appear for others!
Comment 7 Andrew Pinski 2003-05-27 22:58:47 UTC
Sounds like a memory or disk problem.
Comment 8 Dara Hazeghi 2003-05-31 05:09:37 UTC
Created attachment 4115 [details]
gcc 3.4 preprocessed source
Comment 9 Dara Hazeghi 2003-05-31 05:13:36 UTC
Created attachment 4116 [details]
gcc 3.4 error log
Comment 10 Dara Hazeghi 2003-05-31 05:22:17 UTC
Hello,

with the instructions provided, I can now fully reproduce this error on gcc 3.3 branch. I sincerely 
doubt this is due to a hardware problem, as Andrew suggested, since it has been independently 
confirmed on two different machines. However, with gcc mainline (20030526), I get an error, 
followed by an ICE. I've attached the error log, as well as the preprocessed source for mainline. A 
C++ expert will probably have to determine if the code in question is truly invalid or not... 

Dara

P.S. Here's the first error gcc 3.4 outputs when building:

/Users/dara/Downloads/scitbx_2003_05_26/boost/boost/python/object/instance.hpp:4
5: error: a
   cast to a type other than an integral or enumeration type cannot appear in a
   constant-expression
/Users/dara/Downloads/scitbx_2003_05_26/boost/boost/python/object/instance.hpp:4
5: error: expected
   `)'

The relevant lines are:
template <class Data>
struct additional_instance_size
{
    typedef instance<Data> instance_data;
    typedef instance<char> instance_char;
    static const std::size_t value = sizeof(instance_data) - (reinterpret_cast <
size_t> (&reinterpret_cast <char &>(static_cast <instance_char *> (0)->storage))
); <<< this is the failing line, (actually the last three lines are all one)

};
Comment 11 Dave Abrahams 2003-05-31 22:44:11 UTC
This is not a cast.  It only looks like a cast because you ran the code 
through the preprocessor.  It's actually a use of the offsetof() macro.  7.17 
paragraph 3 in the 'C' standard says:

The macros are

    NULL

which expands to an implementation-defined null pointer constant; and

    offsetof(type, member-designator)

which expands to an integer constant expression
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^

The C++ standard only restricts the use of offsetof to have a POD type as its 
first argument.  

18.1:

"-5- The macro offsetof accepts a restricted set of type arguments in this 
International Standard. type shall be a POD structure or a POD union (clause 
class). The result of applying the offsetof macro to a field that is a static 
data member or a function member is undefined. "

Since instance_char is in fact a POD, the code is legal.
Comment 12 Dara Hazeghi 2003-06-02 21:01:19 UTC
Hello,

with g++ 3.4, here's the line that yields the first error:

template <class Data>
struct additional_instance_size
{
    typedef instance<Data> instance_data;
    typedef instance<char> instance_char;  
    BOOST_STATIC_CONSTANT(   
        std::size_t, value = sizeof(instance_data)
                           - BOOST_PYTHON_OFFSETOF(instance_char,storage));
};

When preprocessed, it becomes:

template <class Data>
struct additional_instance_size
{
    typedef instance<Data> instance_data;
    typedef instance<char> instance_char;
    static const std::size_t value = sizeof(instance_data) - (reinterpret_cast <
size_t> (&reinterpret_cast <char &>(static_cast <instance_char *> (0)->storage))
);

Preprocessed output is attached to this... 

Thanks,

Dara
Comment 13 Wolfgang Bangerth 2003-06-02 22:55:21 UTC
The ICE-on-mainline is now reported independently in PR 11070.
Comment 14 Wolfgang Bangerth 2003-06-03 01:15:28 UTC
Created attachment 4148 [details]
fixed 3.4 preprocessed sources

I have now attached preprocessed sources that are "fixed" in the
sense that the ICE is no longer triggered. I get a _lot_ of other
errors, though.
Comment 15 Wolfgang Bangerth 2003-06-03 01:17:25 UTC
Created attachment 4149 [details]
fixed 3.4 preprocessed sources
Comment 16 Wolfgang Bangerth 2003-06-03 01:36:34 UTC
The problem with offsetof is now treated in 11072. BTW, where did you read
that the result of offsetof is an integral constant expression? It is not
in my copy of the standard, or at least not at the places I looked at...

W.
Comment 17 Andrew Pinski 2003-06-22 18:50:36 UTC
I think this problem is that Darwin (Mac OS X)'s stack limit is just set too low.  I will try once I 
download a 3.3.1 (snapshot) compiler.  I know for 3.4 errors out saying you should raise th limit to 
unlimited.  With the limit at 512 I do not get an ICE (Illegal instruction) but it works but with the 
limit set to 100 I do get the Illegal instruction ICE so this really looks like a too low stack limit.
Comment 18 Ralf W. Grosse-Kunstleve 2003-06-25 16:09:36 UTC
In response to comment #17:

I've confirmed that the compilation of cctbx/sgtbx/boost_python/rt_mx.cpp (see 
comment #5) crashes when using the default stacksize of 512k, but works 
correctly after setting the stacksize to 8192k. -- Ouch!

Thank you very much Andrew!
Comment 19 Wolfgang Bangerth 2003-06-25 17:57:55 UTC
Darwin stack size limit. I really wonder why the set it so low...

W.
Comment 20 Dara Hazeghi 2003-07-05 19:36:40 UTC
Yup, confirmed fixed when using ulimit unlimited. Note that the testcase still needed 184MB RAM 
to compile. Ouch.