Bug 54556 - gcc generates "Internal compiler error" for simple if statement
gcc generates "Internal compiler error" for simple if statement
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: xemacs (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-12 04:44 EDT by p929001
Modified: 2007-04-18 12:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-12 05:32:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The source code that generates the problem (line 42) (1.26 KB, text/plain)
2001-10-12 04:46 EDT, p929001
no flags Details
Header file included in the source file (530 bytes, text/plain)
2001-10-12 04:50 EDT, p929001
no flags Details

  None (edit)
Description p929001 2001-10-12 04:44:04 EDT
Description of Problem:
When trying to compile a C++ program I get the error message listed below
(Internal compiler error)

Version-Release number of selected component (if applicable):
gcc-2.96-85

How Reproducible:
Always

Steps to Reproduce:
1. gcc Array.cpp -o Array

Actual Results:
I get an error message:
Array.cpp: In method `Mytype Array<Mytype>::operator[] (const int &) 
const':
Array.cpp:42: universal-character-name `\u
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.

The line in question is "if (i<_lower ||B i>_upper)", which appears in the
function before without problems.

Expected Results:
Normal compile; there seems to be nothing wrong with the code. The exact
same code appears in the function before, and there are no problems.

Additional Information:
Code submitted as attachment.
I saw this problem with another piece of code, and it also involved a
statement of the form "if (some_conditional || some_other_conditional)" the
problem remains even if I replace the line with "if (true || true)". For
some stange reason, the problem disappeared in the other piece of code,
after trying some variants with extra parantheses etc. I do not know what
caused the sudden disappearance of the problem. This time I seem stuck,
however.
Comment 1 p929001 2001-10-12 04:46:48 EDT
Created attachment 33981 [details]
The source code that generates the problem (line 42)
Comment 2 p929001 2001-10-12 04:50:09 EDT
Created attachment 33982 [details]
Header file included in the source file
Comment 3 Jakub Jelinek 2001-10-12 05:14:53 EDT
There is something very wrong with the code actually, but there was a bug
in diagnostic code for this in gcc up to 2.96-85 (ie. anything above 2.96-85,
such as e.g. 2.96-9[89] should tell you:
/root/Array.cpp: In method `Mytype Array<Mytype>::operator[] (const int
&) const':
/root/Array.cpp:42: universal-character-name `\u00a0' not valid in
identifier
/root/Array.cpp:42: universal-character-name `\u00a0' not valid in
identifier
/root/Array.cpp:42: sorry, not implemented: universal characters in
identifiers
).
The problem is that you're using '\xa0' character instead of space in the
if condition.
Comment 4 p929001 2001-10-12 05:26:18 EDT
Found the error same time as you (Actually got a "Mid-air collision"). By the
way, there is no package update for the gcc you mention? (I tried updating gcc
before submitting the bug). This is what I wanted to submit this time:

Tried compiling on a Sun Solaris (Sun Enterprise 250) This gives the error:

Array.cpp: In method `Mytype Array<Mytype>::operator [](const int &) const':
Array.cpp:42: parse error before character 0240
Array.cpp:45: confused by earlier errors, bailing out

Seems there is a hidden character in the line in question. Removing this
character resolves the problem. The character can be seen with mc or vi, but not
more, less, joe, emacs or xemacs. The file was created with XEmacs, which I have
noticed tends to "stick" modifier keys one more character press. For example,
when I use Ctrl-(left arrow) to move word by word, the next character press
(e.g. right arrow) becomes Ctrl modified. Thus the character is probably created
by AltGr-Space, as I have to press AltGr-' to get the pipe sign for the ||. This
one could say this is a bug in XEmacs, which strongly affects gcc.
Comment 5 Jakub Jelinek 2001-10-12 05:32:42 EDT
With joe and less it depends how they are configured (ie. if they are configured
for ASCII or LatinN (in the latter case they don't show anything, since
'\xa0' should be printed as space.
As for XEmacs, I'll let Trond say his word.
Comment 6 Trond Eivind Glomsrxd 2001-10-12 10:44:16 EDT
I've never seen XEmacs use sticky keys, unless you ask for it (iso-accents-mode
or other input methods). Jakub gave the reason why it isn't displayed. To
display more info on it, go to it's location and do "C-u C-x =".

Note You need to log in before you can comment on or make changes to this bug.