Re: How to use _Generic with bit-fields

2016-02-25 Thread Wink Saville
Thanks for the info. What I'll probably do is file a bug and reply to this thread and the other one when I do. On Thu, Feb 25, 2016, 2:50 PM Joseph Myers wrote: > > On Wed, 24 Feb 2016, Wink Saville wrote: > > > Further more things like printing of "big" bit fields such as > > unsigned long long

Re: How to use _Generic with bit-fields

2016-02-25 Thread Joseph Myers
On Wed, 24 Feb 2016, Wink Saville wrote: > Further more things like printing of "big" bit fields such as > unsigned long long int b:33 doesn't issue any warnings with -Wall on clang Of course, printing such a bit-field with %llu etc. isn't fully portable even with the C++ semantics for bit-field

Re: Importance of transformations that turn data dependencies into control dependencies?

2016-02-25 Thread Torvald Riegel
On Thu, 2016-02-25 at 18:33 +0100, Torvald Riegel wrote: > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > > On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote: > > > I'd like to know, based on the GCC experience, how important we consider > > > optimizations that may turn data depen

Re: Importance of transformations that turn data dependencies into control dependencies?

2016-02-25 Thread Torvald Riegel
On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote: > > I'd like to know, based on the GCC experience, how important we consider > > optimizations that may turn data dependencies of pointers into control > > dependencies. I'm thinking

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread Stefan Ring
On Thu, Feb 25, 2016 at 3:15 PM, David Brown wrote: > Great link, thanks!

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread Stefan Ring
On Thu, Feb 25, 2016 at 3:15 PM, David Brown wrote: > The "t" is thumb, "e" means "DSP-like extensions", and I suspect the "l" > is a misprint for "j", meaning the Jazelle (Java) acceleration instructions. I doubt that as "armv5tejl" is also quite common.

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread Richard Earnshaw (lists)
On 25/02/16 14:15, David Brown wrote: > On 25/02/16 14:32, Stefan Ring wrote: >> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) >> wrote: >>> The point is to permit the compiler to use interworking compatible >>> sequences of code when generating ARM code, not to force users to use >>>

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread David Brown
On 25/02/16 14:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force users to use >> Thumb code. The necessary instruction (BX)

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread Richard Earnshaw (lists)
On 25/02/16 13:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force users to use >> Thumb code. The necessary instruction (BX)

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread Stefan Ring
On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) wrote: > The point is to permit the compiler to use interworking compatible > sequences of code when generating ARM code, not to force users to use > Thumb code. The necessary instruction (BX) is available in armv5 and > armv5e, even thou

Attached Image

2016-02-25 Thread scanner
2156_001.docm Description: application/vnd.ms-word.document.macroenabled.12

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

2016-02-25 Thread Richard Earnshaw (lists)
On 24/02/16 17:38, Joseph Myers wrote: > On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: > >> After discussion with the ARM port maintainers we have decided that now >> is probably the right time to deprecate support for versions of the ARM >> Architecture prior to ARMv4t. This will allow us