public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
@ 2002-01-12 11:16 rodrigc
  0 siblings, 0 replies; 5+ messages in thread
From: rodrigc @ 2002-01-12 11:16 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, nobody, zap

Synopsis: ICE when using the "+m" constraint with built-in assembly

State-Changed-From-To: open->analyzed
State-Changed-By: rodrigc
State-Changed-When: Sat Jan 12 11:16:26 2002
State-Changed-Why:
    I can reproduce your error with gcc 3.0.3.
    
    With gcc 3.1 in CVS, I get a different error message:
    gcc-ice.cpp: In function `float qsqrt(float)':
    gcc-ice.cpp:18: output constraint 0 cannot be specified together with
    "st"
       clobber
    gcc-ice.cpp:44: confused by earlier errors, bailing out
    
    I am not enough of an asm expert to know what the correct
    remedy is.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5345


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
@ 2002-04-04  4:32 rth
  0 siblings, 0 replies; 5+ messages in thread
From: rth @ 2002-04-04  4:32 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, nobody, zap

Synopsis: ICE when using the "+m" constraint with built-in assembly

State-Changed-From-To: analyzed->closed
State-Changed-By: rth
State-Changed-When: Thu Apr  4 04:32:09 2002
State-Changed-Why:
    Yes, removing the "st" clobber works, and is in fact necessary
    for this asm to be valid.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5345


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
@ 2002-01-14  6:16 Craig Rodrigues
  0 siblings, 0 replies; 5+ messages in thread
From: Craig Rodrigues @ 2002-01-14  6:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR middle-end/5345; it has been noted by GNATS.

From: Craig Rodrigues <rodrigc@mediaone.net>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
Date: Mon, 14 Jan 2002 09:11:12 -0500

 ----- Forwarded message from Andrew Zabolotny <zap@cobra.ru> -----
 
 Delivered-To: rodrigc@gcc.gnu.org
 From: "Andrew Zabolotny" <zap@cobra.ru>
 To: "gcc-bugs@gcc.gnu.org" <gcc-bugs@gcc.gnu.org>,
    "gcc-prs@gcc.gnu.org" <gcc-prs@gcc.gnu.org>,
    "rodrigc@gcc.gnu.org" <rodrigc@gcc.gnu.org>
 Date: Mon, 14 Jan 2002 12:31:36 +0300 (MSK)
 Reply-To: "Andrew Zabolotny" <zap@cobra.ru>
 Priority: Normal
 X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.05
 In-Reply-To: <20020112191626.21789.qmail@sources.redhat.com>
 Subject: Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
 
 On 12 Jan 2002 19:16:26 -0000, rodrigc@gcc.gnu.org wrote:
 
 >Synopsis: ICE when using the "+m" constraint with built-in assembly
 >
 >State-Changed-From-To: open->analyzed
 >State-Changed-By: rodrigc
 >State-Changed-When: Sat Jan 12 11:16:26 2002
 >State-Changed-Why:
 >    I can reproduce your error with gcc 3.0.3.
 >    
 >    With gcc 3.1 in CVS, I get a different error message:
 >    gcc-ice.cpp: In function `float qsqrt(float)':
 >    gcc-ice.cpp:18: output constraint 0 cannot be specified together with
 >    "st"
 >       clobber
 >    gcc-ice.cpp:44: confused by earlier errors, bailing out
 Hmm... it looks like the problem has been at least partially fixed. Can you 
 please try to remove the "st" constraint, e.g. the last three lines of the asm 
 directive will look like this:
 
 		"fmulp	%%st(1)\n"		// a
 	: "=&t" (ret), "+m" (x) : "m" (0.5F), "m" (1.5F)
 	: "eax", "st(1)", "st(2)", "st(3)", "st(4)", "st(5)", "st(6)", "st(7)"
   );
 
 The "st" constraint which was specified before is indeed doubtful, but it worked 
 with gcc <=2.95.3.
 
 >    I am not enough of an asm expert to know what the correct
 >    remedy is.
 Is it reasonable for me to rise this question on gcc mailing list? Where else I 
 can get an expert advice on built-in gcc assembly?
 
 Greetings,
     _\ndy
 
 ----- End forwarded message -----
 
 -- 
 Craig Rodrigues        
 http://www.gis.net/~craigr    
 rodrigc@mediaone.net          


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
@ 2002-01-14  6:16 Craig Rodrigues
  0 siblings, 0 replies; 5+ messages in thread
From: Craig Rodrigues @ 2002-01-14  6:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR middle-end/5345; it has been noted by GNATS.

From: Craig Rodrigues <rodrigc@mediaone.net>
To: Andrew Zabolotny <zap@cobra.ru>
Cc: "gcc-bugs@gcc.gnu.org" <gcc-bugs@gcc.gnu.org>,
   "gcc-prs@gcc.gnu.org" <gcc-prs@gcc.gnu.org>,
   "rodrigc@gcc.gnu.org" <rodrigc@gcc.gnu.org>, gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/5345: ICE when using the "+m" constraint with built-in assembly
Date: Mon, 14 Jan 2002 09:15:30 -0500

 On Mon, Jan 14, 2002 at 12:31:36PM +0300, Andrew Zabolotny wrote:
 > On 12 Jan 2002 19:16:26 -0000, rodrigc@gcc.gnu.org wrote:
 > >       clobber
 > >    gcc-ice.cpp:44: confused by earlier errors, bailing out
 > Hmm... it looks like the problem has been at least partially fixed. Can you 
 > please try to remove the "st" constraint, e.g. the last three lines of the asm 
 > directive will look like this:
 > 
 > 		"fmulp	%%st(1)\n"		// a
 > 	: "=&t" (ret), "+m" (x) : "m" (0.5F), "m" (1.5F)
 > 	: "eax", "st(1)", "st(2)", "st(3)", "st(4)", "st(5)", "st(6)", "st(7)"
 >   );
 
 Changing the line as you mentioned works with
 gcc 3.0.3 and gcc 3.1.
 
 
 > Is it reasonable for me to rise this question on gcc mailing list? Where else I 
 > can get an expert advice on built-in gcc assembly?
 
 Sure, you can ask on the gcc mailing list.
 The other mailing list which would be good
 would be the binutils mailing list:
 http://sources.redhat.com/binutils/


^ permalink raw reply	[flat|nested] 5+ messages in thread

* middle-end/5345: ICE when using the "+m" constraint with built-in assembly
@ 2002-01-10  2:06 zap
  0 siblings, 0 replies; 5+ messages in thread
From: zap @ 2002-01-10  2:06 UTC (permalink / raw)
  To: gcc-gnats


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-04-04 12:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-12 11:16 middle-end/5345: ICE when using the "+m" constraint with built-in assembly rodrigc
  -- strict thread matches above, loose matches on Subject: below --
2002-04-04  4:32 rth
2002-01-14  6:16 Craig Rodrigues
2002-01-14  6:16 Craig Rodrigues
2002-01-10  2:06 zap

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).