Bug 43262 - inline asm with -O2 breaks logic if comparisons are involved
Summary: inline asm with -O2 breaks logic if comparisons are involved
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.3.4
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 43263 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-04 21:57 UTC by Slava
Modified: 2010-03-04 22:26 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Slava 2010-03-04 21:57:45 UTC
I put here a simple example to illustrate what looks like a bug to me

#include<iostream>

inline unsigned next_exp2(unsigned x)
{
	unsigned n;
	asm volatile("bsr %0, %1" : "=r" (n) : "r" (x)); // most significant bit
	return((x == (1u << n)) ? n : n);
};
inline unsigned next_exp2_(unsigned x)
{
	unsigned n;
	asm volatile("bsr %0, %1" : "=r" (n) : "r" (x)); // most significant bit
	return((x == (1u << n)) ? n : n+1);
};

int main()
{
	unsigned x = 1025;
	std::cout << "n1 = " << next_exp2(x) << std::endl;
	std::cout << "n2 = " << next_exp2_(x) << std::endl;
	
	return(0);
}


The difference between two function is n+1 returned from the underscored version. Compiled with g++ -O2 ./foo.cpp, my output  is:

n1 = 10
n2 = 3078596801

while I would expect n2 = 11.

If I compile it with g++ -g foo.cpp, everything works as expected.
Comment 1 Andrew Pinski 2010-03-04 22:08:40 UTC
The problem you are seeing is Intel vs AT&T asm formats.  GNU as defaults to AT&T format in that it is src, dst. So you have the operands swapped.  Note also you also don't clobber the flags register as bsr sets the Zero flag.
asm volatile("bsr %1, %0" : "=r" (n) : "r" (x) : "flags");
Is the correct code you want.  It just happened to work at -O0 because the register allocator used the same registers for the input and output.
Comment 2 Andrew Pinski 2010-03-04 22:24:47 UTC
*** Bug 43263 has been marked as a duplicate of this bug. ***
Comment 3 Slava 2010-03-04 22:26:40 UTC
You're absolutely right. Sorry for the false alarm.