[Bug gas/15914] New: ARM gas does not support UDF mnemonic

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15914

Bug ID: 15914
   Summary: ARM gas does not support UDF mnemonic
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: jsm28 at gcc dot gnu.org
Target: arm*-*

The ARM architecture has certain instruction encodings specified as permanently
undefined (guaranteed to generate an Undefined Instruction exception), and
these have a defined UDF mnemonic to generate them, but gas does not know that
mnemonic.

("Issue C.a of this manual first defines an assembler mnemonic for these
encodings.", according to DDI0406C.b.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/14768] Checklist: Binutils Migration To Git

[hp at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14768

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #16 from Hans-Peter Nilsson  ---
A few more to-do items:

* Git migrations and work-flow offered for remaining projects
(like newlib and cgen).

* (related:) Do not set in stone this git repo as "binutils+gdb"
in any documentation changes and names assuming we agree that other projects
may be added.

* Add remaining "partial checkout" methods as mentioned in
CVSROOT/modules to src-release, for related migrating projects (well, at
least "sim").  Mention this as a (the only?) supported way to
generate the project-specific tree.

See  for reasons.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/14768] Checklist: Binutils Migration To Git

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14768

--- Comment #17 from joseph at codesourcery dot com  ---
On Fri, 30 Aug 2013, hp at sourceware dot org wrote:

> * Git migrations and work-flow offered for remaining projects
> (like newlib and cgen).

That should be in the form: document in detail how the migration worked, 
so that if the newlib community chooses to move to git, it has the benefit 
of documentation of the process when replicating it to move to its own git 
repository.

> * (related:) Do not set in stone this git repo as "binutils+gdb"
> in any documentation changes and names assuming we agree that other projects
> may be added.

Rather, I say the repository should be exactly 6(b) from 
 (subject to confirming 
the exact set of directories with only Attic contents in CVS whose history 
gets converted).  (c), (d), (e), (f), (g) and each of the three parts of 
(h) should, if someone in their respective communities wishes to convert 
them away from CVS, be converted independently to separate repositories 
(based on shared toplevel code only when it's actually used); (a) may be 
convenient to avoid shared files diverging, but is not required.

(I do not definitively assert whether (c) newlib and (d) winsup should be 
separate or a single repository; that's for the relevant communities to 
work out.  I am confident that all the other divisions make sense.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/14768] Checklist: Binutils Migration To Git

[hp at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14768

--- Comment #18 from Hans-Peter Nilsson  ---
(In reply to jos...@codesourcery.com from comment #17)
> On Fri, 30 Aug 2013, hp at sourceware dot org wrote:
> 
> > * Git migrations and work-flow offered for remaining projects
> > (like newlib and cgen).

Sorry, there was an ambiguity here.  By "work-flow" I meant
"git-migration-unrelated usual work-flow, of checking out and building and
committing changes to files affected by the migration changes", not
specifically "work-flow of git migration" - though that makes sense too on its
own.

> That should be in the form: document in detail how the migration worked, 
> so that if the newlib community chooses to move to git, it has the benefit 
> of documentation of the process when replicating it to move to its own git 
> repository.

Not sure if your reply was affected by the ambiguity of my suggestion, but
anyway your suggestion makes sense.

> > * (related:) Do not set in stone this git repo as "binutils+gdb"
> > in any documentation changes and names assuming we agree that other projects
> > may be added.
> 
> Rather, I say the repository should be exactly 6(b) from 
> 

If the src CVS is to be able to continue on its own then there's one or two
missing TODO items last:

* Undo the read-only marking of the subset of converted directories that are
shared with non-migrated projects.

(For example: config/) and

* Alert all non-migrated projects affected by converted directories.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils