Re: inline asm clobbers

On Thu, Mar 12, 2015 at 03:09:52PM -0700, David Wohlferd wrote: > Ahh. So perhaps as I suspected: this is more commonly used on non-i386 > platforms. So clearly removing this is out of the question. glibc uses it for PowerPC and s390 at least (I only grepped for "3", quotes included -- there ma

gcc-4.8-20150312 is now available

Snapshot gcc-4.8-20150312 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150312/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: inline asm clobbers

On 3/12/2015 7:24 AM, paul_kon...@dell.com wrote: On Mar 11, 2015, at 8:53 PM, David Wohlferd wrote: ... I would agree that one should avoid it. I'd be wary of removing it from GCC at this point since it might break working code. It certainly would. It’s not all that common, but I have se

Re: inline asm clobbers

On 03/12/15 15:26, Jakub Jelinek wrote: On Thu, Mar 12, 2015 at 02:02:37PM -0700, David Wohlferd wrote: To wrap this up: Like Ian said, the order of registers here apparently never changes. I read more into that comment than I should have. For good luck, I experimented with -fomit-frame-point

Re: inline asm clobbers

On Thu, Mar 12, 2015 at 02:02:37PM -0700, David Wohlferd wrote: > To wrap this up: > > Like Ian said, the order of registers here apparently never changes. I read > more into that comment than I should have. For good luck, I experimented > with -fomit-frame-pointer, -ffixed-, etc, and nothing ha

Re: inline asm clobbers

Resending due to bounced email. On 3/11/2015 6:19 PM, Ian Lance Taylor wrote: On Wed, Mar 11, 2015 at 5:51 PM, David Wohlferd wrote: The reason I believe the order can change is this comment from i386.h: /* Order in which to allocate registers. Each register must be listed once, even tho

Re: Undefined behavior due to 6.5.16.1p3

On 03/12/2015 03:10 AM, Vincent Lefevre wrote: On 2015-03-12 00:19:55 +0100, Robbert Krebbers wrote: On 03/11/2015 05:31 PM, Vincent Lefevre wrote: I disagree that it is an extension. The standard does not say that "one union member can be active at any time". The interpretation under which th

Re: inline asm clobbers

> On Mar 11, 2015, at 8:53 PM, David Wohlferd wrote: > >>> ... >>> I would agree that one should avoid it. I'd be wary of removing it >>> from GCC at this point since it might break working code. >> It certainly would. It’s not all that common, but I have seen this done in >> production code.

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-12 01:05:42 +, Joseph Myers wrote: > On Wed, 11 Mar 2015, Vincent Lefevre wrote: > > > BTW, the following is forbidden (and makes no sense), but is accepted > > by GCC without a warning: > > > > int foo (void) > > { > > union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 }; > >

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-12 00:19:55 +0100, Robbert Krebbers wrote: > On 03/11/2015 05:31 PM, Vincent Lefevre wrote: > >I disagree that it is an extension. The standard does not say > >that "one union member can be active at any time". > > > >The interpretation under which this is allowed in confirmed by > >Note

Re: Offloading GSOC 2015

Hi Thomas, How can i progress about giving official proposal? Which topics are GCC interested in? So far, i have been tried to influence the evolution of the omp 4.0 accelerator model. Sum up of my small achievements until now - Using Shared Memory in a efficient way --- I allowed array privati

Re: Undefined behavior due to 6.5.16.1p3

BTW, the following is forbidden (and makes no sense), but is accepted by GCC without a warning: int foo (void) { union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 }; return u.b; } -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-11 17:39:31 +0100, Jakub Jelinek wrote: > On Wed, Mar 11, 2015 at 05:31:01PM +0100, Vincent Lefevre wrote: > > > (in C only one union member can be active at any time, > > > we as extension allow type punning through unions etc.) > > > > I disagree that it is an extension. The standard

Re: SPIR-V and GCC

Hi! On Fri, 6 Mar 2015 15:23:21 + (UTC), BogDan wrote: > > This http://www.g-truc.net/post-0714.html great article explans better > > what SPIR-V is. Note that I don't know anything about SPIR-V, and I'm currently too busy to learn about it, but: > I checked them a little bit and I'm afraid

Re: Newlib/Cygwin now under GIT

[Somehow I managed to drop newlib from the recipient list. Re-added] On Mar 10 19:19, Corinna Vinschen wrote: > On Mar 10 17:03, Joseph Myers wrote: > > On Tue, 10 Mar 2015, Corinna Vinschen wrote: > > > > > Hi fellow developers, > > > > > > > > > I'm happy to inform you that the move of Newli

Re: Newlib/Cygwin now under GIT

On Mar 10 17:03, Joseph Myers wrote: > On Tue, 10 Mar 2015, Corinna Vinschen wrote: > > > Hi fellow developers, > > > > > > I'm happy to inform you that the move of Newlib/Cygwin from the src CVS > > repository to the new, combined GIT repository is now final. > > I note that this repository in

Re: Undefined behavior due to 6.5.16.1p3

On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote: > On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote: > > But what about "long long" on 32 bits machines. For example: > > > > union { > > long long a; > > struct { char b1; long long b2; } b; > > } u; > > > > Will GCC perform