533868 – Inconsistency with how a "MOVT Rn, #-n >> 16" opcode is assembled...

Bug 533868 - Inconsistency with how a "MOVT Rn, #-n >> 16" opcode is assembled...

Summary: Inconsistency with how a "MOVT Rn, #-n >> 16" opcode is assembled...

Status:	RESOLVED INVALID

Alias:	None

Product:	Gentoo Linux
Classification:	Unclassified
Component:	[OLD] Development (show other bugs)
Hardware:	All Linux

Importance:	Normal normal (vote)
Assignee:	Gentoo Linux bug wranglers

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2014-12-28 22:38 UTC by Mark I Manning IV
Modified:	2014-12-29 09:05 UTC (History)
CC List:	0 users

See Also:
Package list:
Runtime testing required:	---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Mark I Manning IV 2014-12-28 22:38:25 UTC

Using the arm-cortexm4-eabi-as crossdev assembler, a MOVT of a negative value shifted right by 16 (to get the high 16 bits) results in an out of range error.  On my beagleboard XM running ARM Gentoo I can assemble that same line of source with no problems.

I am assuming that the >> operator is acting as though it were signed for the corssdev assembler but unsigned for the native assembker.  One or other of them is doing this wrong, not sure which. 

This is probably low priority as I can change my source to MOVT Rn, ((-2 >> 16) & 0xffff) or some such

Comment 1 Jeroen Roovers (RETIRED) gentoo-dev

2014-12-29 08:13:57 UTC

Please do file bug reports when you find bugs. Pleasee do not file bug reports when you're wondering about things.

Comment 2 Mark I Manning IV 2014-12-29 09:05:58 UTC

how was this a "wondering about things".  The assembler behaves differently depending on which version of it you run. just because there is a work around does not mean there is not an inconsistency!