Bug 23972 - Codegen Error in Inlined Code
Summary: Codegen Error in Inlined Code
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2005-09-19 20:04 UTC by Evandro Menezes
Modified: 2005-09-20 16:45 UTC (History)
1 user (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:

Sample C++ code. (265 bytes, text/plain)
2005-09-19 20:05 UTC, Evandro Menezes
Preprocessed sample code. (1.72 KB, application/octet-stream)
2005-09-19 20:06 UTC, Evandro Menezes

Note You need to log in before you can comment on or make changes to this bug.
Description Evandro Menezes 2005-09-19 20:04:59 UTC
When building the attached file with -O3 (to enable inlining), Saturate16 () is
inlined in Mul16_all () and its return value is lost:

	movq	%mm0, -24(%rsp)	# 
	movw	%cx, (%r8)	# tmp83,* pDst

Note that the %cx is not loaded from the slot at "-24(%rsp)" before it's stored.
 The correct would be:

	movq	%mm0, -24(%rsp)	# 
	movw	-24(%rsp), %cx	# tmp83,* pDst
	movw	%cx, (%r8)	# tmp83,* pDst

Better yet:

	movq	%mm0, (%r8)	# 

The same error happens in 32-bit mode ("-m32 -mmmx").  This error affects 4.0.0
as well.
Comment 1 Evandro Menezes 2005-09-19 20:05:49 UTC
Created attachment 9776 [details]
Sample C++ code.
Comment 2 Evandro Menezes 2005-09-19 20:06:28 UTC
Created attachment 9777 [details]
Preprocessed sample code.
Comment 3 Evandro Menezes 2005-09-19 20:08:13 UTC
(In reply to comment #0)

> Better yet:
> 	movq	%mm0, (%r8)	# 
> 	emms

Ahem, never mind...
Comment 4 Andrew Pinski 2005-09-19 20:17:14 UTC
First try -fno-strict-aliasing, since:
	return *(short*)&tmp;

is violating them.
Second I think this is a known issue.
Comment 5 Andrew Pinski 2005-09-19 20:25:38 UTC
Yes this is a case where you are violating C/C++ aliasing rules.

*** This bug has been marked as a duplicate of 21920 ***
Comment 6 Evandro Menezes 2005-09-20 16:06:36 UTC
It would be nice if -Wall, -Wstrict-aliasing or -Wstrict-aliasing=2 caught it...
Comment 7 Andrew Pinski 2005-09-20 16:08:11 UTC
From the dup bug:
Also PR 14024 is the bug for C++ front-end not reporting possible aliasing violations.
Comment 8 Evandro Menezes 2005-09-20 16:43:44 UTC
-fno-strict-aliasing still doesn't result in the correct code.  I agree with
your assesment, but what am I missing?
Comment 9 Evandro Menezes 2005-09-20 16:45:28 UTC
Ahem, never mind.  My eyes are blury after looking at so much asm code...