middle-end/5345: ICE when using the "+m" constraint with built-in assembly
zap@cobra.ru
zap@cobra.ru
Thu Jan 10 02:06:00 GMT 2002
>Number: 5345
>Category: middle-end
>Synopsis: ICE when using the "+m" constraint with built-in assembly
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Thu Jan 10 02:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Andrew Zabolotny
>Release: 3.0.2
>Organization:
>Environment:
gcc 3.0.2 on OS/2, also tried and `works' with gcc 2.96 on Linux
>Description:
I've used for a long time ago a quick sqrt() routine for the x86 processor, which cheased to compile with gcc 3.0.x series.
Trying to find what happens and how it could be corrected I have encountered an inexplicable ICE.
The routine uses built-in assembly, which references a `float ' variable by memory address, both for input and output (the "+m" constraint). The variable itself is an argument to the function. When I try to compile it, I get: "output number 1 not directly addressable". Then I tried to add an printf() which would print the address of that variable... I got an ICE.
I've attached the .cpp file, since it includes just stdio.h (for printf) - I don't think the preprocessed file matters, while you will (possibly) be unable to compile it on other platforms.
>How-To-Repeat:
gcc -c gcc-ice.cpp
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gcc-ice.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gcc-ice.cpp"
I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCnN0YXRpYyBpbmxpbmUgZmxvYXQgcXNxcnQgKGZsb2F0IHgp
DQp7DQogIGZsb2F0IHJldDsNCg0KICBwcmludGYgKCIlcFxuIiwgJngpOw0KDQovLyBPcmlnaW5h
bCBDKysgZm9ybXVsYWU6DQovLyBmbG9hdCB0bXAgPSB4Ow0KLy8gKigodW5zaWduZWQgKikmdG1w
KSA9ICgweGJlNmYwMDAwIC0gKigodW5zaWduZWQgKikmdG1wKSkgPj4gMTsNCi8vIGRvdWJsZSBo
ID0geCAqIDAuNTsNCi8vIGRvdWJsZSBhID0gdG1wOw0KLy8gYSAqPSAxLjUgLSBhICogYSAqIGg7
DQovLyBhICo9IDEuNSAtIGEgKiBhICogaDsNCi8vIHJldHVybiBhICogeDsNCg0KICBfX2FzbV9f
ICgNCgkJImZsZHMJJTFcbiIJCQkvLyB4DQoJCSJtb3ZsCSQweGJlNmYwMDAwLCUlZWF4XG4iDQoJ
CSJzdWJsCSUxLCUlZWF4XG4iDQoJCSJzaHJsCSQxLCUlZWF4XG4iDQoJCSJtb3ZsCSUlZWF4LCUx
XG4iDQoJCSJmbGRzCSUyXG4iCQkJLy8geCAwLjUNCgkJImZtdWwJJSVzdCgxKVxuIgkJLy8geCBo
DQoJCSJmbGRzCSUzXG4iCQkJLy8geCBoIDEuNQ0KCQkiZmxkcwklMVxuIgkJCS8vIHggaCAxLjUg
YQ0KCQkiZmxkCSUlc3RcbiIJCQkvLyB4IGggMS41IGEgYQ0KCQkiZm11bAklJXN0XG4iCQkJLy8g
eCBoIDEuNSBhIGEqYQ0KCQkiZm11bAklJXN0KDMpXG4iCQkvLyB4IGggMS41IGEgYSphKmgNCgkJ
ImZzdWJyCSUlc3QoMilcbiIJCS8vIHggaCAxLjUgYSAxLjUtYSphKmgNCgkJImZtdWxwCSUlc3Qo
MSlcbiIJCS8vIHggaCAxLjUgYQ0KCQkiZmxkCSUlc3RcbiIJCQkvLyB4IGggMS41IGEgYQ0KCQki
Zm11bAklJXN0XG4iCQkJLy8geCBoIDEuNSBhIGEqYQ0KCQkiZm11bHAJJSVzdCgzKVxuIgkJLy8g
eCBhKmEqaCAxLjUgYQ0KCQkiZnhjaFxuIgkJCS8vIHggYSphKmggYSAxLjUNCgkJImZzdWJwICAl
JXN0LCUlc3QoMilcbiIJCS8vIHggMS41LWEqYSpoIGENCgkJImZtdWxwCSUlc3QoMSlcbiIJCS8v
IHggYQ0KCQkiZm11bHAJJSVzdCgxKVxuIgkJLy8gYQ0KCTogIj0mdCIgKHJldCksICIrbSIgKHgp
IDogIm0iICgwLjVGKSwgIm0iICgxLjVGKQ0KCTogImVheCIsICJzdCIsICJzdCgxKSIsICJzdCgy
KSIsICJzdCgzKSIsICJzdCg0KSIsICJzdCg1KSIsICJzdCg2KSIsICJzdCg3KSINCiAgKTsNCiAg
cmV0dXJuIHJldDsNCn0NCg0KaW50IG1haW4gKCkNCnsNCiAgcHJpbnRmICgiJWdcbiIsIHFzcXJ0
ICgxMjMpKTsNCiAgcmV0dXJuIDA7DQp9DQo=
More information about the Gcc-bugs
mailing list