Bug 54556

Summary:

gcc generates "Internal compiler error" for simple if statement

Product:

[Retired] Red Hat Linux

Reporter:

p929001

Component:

xemacs

Assignee:

Trond Eivind Glomsrxd <teg>

Status:

CLOSED NOTABUG

QA Contact:

Brian Brock <bbrock>

Severity:

high

Docs Contact:

Priority:

medium

Version:

7.1

Target Milestone:

---

Target Release:

---

Hardware:

i386

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2001-10-12 09:32:47 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
The source code that generates the problem (line 42)	none
Header file included in the source file	none

Description p929001 2001-10-12 08:44:04 UTC

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 08:46:48 UTC

Created attachment 33981 [details]
The source code that generates the problem (line 42)

Comment 2 p929001 2001-10-12 08:50:09 UTC

Created attachment 33982 [details]
Header file included in the source file

Comment 3 Jakub Jelinek 2001-10-12 09:14:53 UTC

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 09:26:18 UTC

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 09:32:42 UTC

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 14:44:16 UTC

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 =".