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 may be more archs that use it). This feature was added to GCC very long ago, in 1992, SVN commit r334. The code comment (varasm.c:decode_reg_name_and_count nowadays) makes clear it is very much deliberate (not an implementation accident). > This brings us to the question of documentation. Right now the docs > only refer to register names. I expect it would be helpful for people > to understand what it means when they come across code that uses > indices. A few words in the 'clobbers' section and the two Reg Vars > sections would probably cover it. I wouldn't. Numbers *are* the register names for all platforms where you are likely to see this used. Expecting numbers in a clobber to work as a backref to an output constraint is a) strange, and b) fatal, as so many errors with asm are. I think the only way to teach people to not hurt themselves so much with asm is to let them hurt themselves a lot, so they'll be much more careful in the future :-/ > I realize this may seem a bit redundant for people who are used to > registers named R0,R1,R2..., but on the i386, the order is: > ax,dx,cx,bx,si... And that isn't even the same as the hardware numbering. No one will or should use this on x86, and if they do, well, hurt ;-) Segher
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/gcc-4_8-branch revision 221401 You'll find: gcc-4.8-20150312.tar.bz2 Complete GCC MD5=ba56eb0afeca047fc02061ec2c10fe27 SHA1=31b9faaac66466c20ada72a8c7af762cb8fbfe10 Diffs from 4.8-20150305 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
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 seen this done in production code. Come to think of it, this certainly makes sense in machines where some instructions act on fixed registers. Really? While I've seen much code that uses clobbers, I have never (until this week) see anyone attempt to clobber by index. Since I'm basically an i386 guy, maybe this is a platform thing? Do you have some examples/links? The example I remember was not in open code. It may have been cleaned up by now, but as supplied to us by the vendor, there were some bits of assembly code that needed a scratch register and used a fixed register (t0 == %8) for that purpose rather than having GCC deal with temporaries. So there was a clobber with “8” in it. Obviously there’s a better way in that instance, but if GCC had removed the feature before we found and cleaned up that code, we would have had a failure on our hands. An example of hardwired registers I remember is some VAX instructions (string instructions). You could write those by name, of course, but if you didn’t know that GCC supports names, you might just use numbers. On machines like VAX where the register names are really just numbers (R0, R1, etc.) that isn’t such a strange thing to do. Register names would be nice as an additional capability. Every example I've ever seen uses register names. Perhaps that what you've seen before? No; I didn’t know that gcc supports register names. The examples I had seen all use numbers. Or more often, preprocessor symbols. It may be that’s because the most common asm code I run into is MIPS coprocessor references, and while general registers may be known by name, coprocessor registers may not be. Or it may just be a case of lack of awareness. paul Ahh. So perhaps as I suspected: this is more commonly used on non-i386 platforms. So clearly removing this is out of the question. This brings us to the question of documentation. Right now the docs only refer to register names. I expect it would be helpful for people to understand what it means when they come across code that uses indices. A few words in the 'clobbers' section and the two Reg Vars sections would probably cover it. Perhaps some variation of: In addition to specifying registers by name, it is also possible to use a register index (ie "3" to refer to the 3rd register). The list of registers and their order is platform specific. See the REGISTER_NAMES defined for your platform in the gcc source. I'm not excited about pointing people vaguely toward the source, but that's the only place I know to find this info. I realize this may seem a bit redundant for people who are used to registers named R0,R1,R2..., but on the i386, the order is: ax,dx,cx,bx,si... dw
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-pointer, -ffixed-, etc, and nothing has any impact here.
The list is the list.
In fact, it turns out you can use this same format with register variables:
register int x asm("3"); // i386: ebx
On some architectures, like e.g. powerpc, people often just use numbers
instead of say r at least for the general purpose registers and
usually the internal register numbering matches it.
So, while using asm ("3") on x86 is something very unusual, on other targets
it can be quite common.
Yup. And as common as it may be, I find it makes reading the resulting
assembly code far more difficult than it ought to be :(
But I won't start a rant on that issue right now ;-)
Jeff
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 has any impact here.
> The list is the list.
>
> In fact, it turns out you can use this same format with register variables:
>
> register int x asm("3"); // i386: ebx
On some architectures, like e.g. powerpc, people often just use numbers
instead of say r at least for the general purpose registers and
usually the internal register numbering matches it.
So, while using asm ("3") on x86 is something very unusual, on other targets
it can be quite common.
Jakub
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 those in FIXED_REGISTERS. List frame pointer
late and fixed registers last. Note that, in general, we prefer
registers listed in CALL_USED_REGISTERS, keeping the others
available for storage of persistent values.
The ADJUST_REG_ALLOC_ORDER actually overwrite the order,
so this is just empty initializer for array. */
That is REG_ALLOC_ORDER. The index that appears in an asm statement
is the hard register number. REG_ALLOC_ORDER is an array holding hard
register numbers. The hard register numbers can change in principle,
by changing the source code, but I actually can't recall that ever
happening.
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 has
any impact here. The list is the list.
In fact, it turns out you can use this same format with register variables:
register int x asm("3"); // i386: ebx
So while I find it ugly, unnecessarily complex, and lacking in
self-documenting-ness, it is not inherently buggy the way I feared it
was, so I can't think of any good arguments for pulling it out.
Thanks to Ian and Paul for straightening me out.
dw
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 this is allowed in confirmed by
Note 95 of 6.5.2.3p3.
Effective types disallow to access a union member other than the current one
arbitrarily, so naively effective types contradict note 95 of 6.5.2.3p3.
Well, this depends on the interpretation of effective types in the
case of a union. For instance, when writing
union { char a[16]; int b; } u;
u.b = 1;
you don't set the member only (an int), but the whole union object is
affected, even bytes that are not parts of the int. So, one may see
the effective type as being the union type.
The purpose of the term /effective type/ is to make it possible
to talk about types of allocated objects (those with no declared
type). In the example above, u.b is declared to have the type
int and assigning to it doesn't change the type of other members
of the union. But because u.a has a character type the value of
u.b can be accessed via u.a (or any other lvalue of that type).
The item "an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or" about aliasing
is also very unclear.
The purpose of this bullet is to allow access to subobjects
of otherwise incompatible aggregate types that contain members
of compatible types. For example:
// Types A and B are incompatible.
struct A { int a; };
struct B { unsigned b; double d; };
struct A *x = malloc (sizeof *x);
struct B *y = malloc (sizeof *y);
// Allocated objects *x and *y have no type, declared
// or effective (yet).
*x = (struct A){ 0 };
*y = (struct B){ 0, 0 };
// *x has effective type A and *y has effective type B.
// Access initial element of *y by an lvalue of an aggregate
// type whose first member's effective type is compatible with
// the effective type of the first member of *x.
*x = *(struct A*)y;
// The effective type of *x is still A.
Martin
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. Come to think of it, this certainly makes sense in >> machines where some instructions act on fixed registers. > > Really? While I've seen much code that uses clobbers, I have never (until > this week) see anyone attempt to clobber by index. Since I'm basically an > i386 guy, maybe this is a platform thing? Do you have some examples/links? The example I remember was not in open code. It may have been cleaned up by now, but as supplied to us by the vendor, there were some bits of assembly code that needed a scratch register and used a fixed register (t0 == %8) for that purpose rather than having GCC deal with temporaries. So there was a clobber with “8” in it. Obviously there’s a better way in that instance, but if GCC had removed the feature before we found and cleaned up that code, we would have had a failure on our hands. An example of hardwired registers I remember is some VAX instructions (string instructions). You could write those by name, of course, but if you didn’t know that GCC supports names, you might just use numbers. On machines like VAX where the register names are really just numbers (R0, R1, etc.) that isn’t such a strange thing to do. >> Register names would be nice as an additional capability. > > Every example I've ever seen uses register names. Perhaps that what you've > seen before? No; I didn’t know that gcc supports register names. The examples I had seen all use numbers. Or more often, preprocessor symbols. It may be that’s because the most common asm code I run into is MIPS coprocessor references, and while general registers may be known by name, coprocessor registers may not be. Or it may just be a case of lack of awareness. paul
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 };
> > return u.b;
> > }
>
> What constraint do you think forbids it? It looks like an ordinary case
> of overriding with designated initializers.
It seems that the standard doesn't specify the behavior.
Concerning the override, I could only see 6.7.9p19, which says:
The initialization shall occur in initializer list order, each
initializer provided for a particular subobject overriding any
previously listed initializer for the same subobject;151)
but in the case of a union, .a and .b are not the same subobject
since they don't have the same type (and not necessarily the same
size).
--
Vincent Lefèvre - Web:
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 95 of 6.5.2.3p3.
> Effective types disallow to access a union member other than the current one
> arbitrarily, so naively effective types contradict note 95 of 6.5.2.3p3.
Well, this depends on the interpretation of effective types in the
case of a union. For instance, when writing
union { char a[16]; int b; } u;
u.b = 1;
you don't set the member only (an int), but the whole union object is
affected, even bytes that are not parts of the int. So, one may see
the effective type as being the union type.
The item "an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or" about aliasing
is also very unclear.
If you think that something contradicts note 95, you should write a
defect report.
--
Vincent Lefèvre - Web:
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 privatization for private/firstprivate clause of teams and distribute directives --- But it is not possible to use private/firstprivate for big arrays. --- That's why I added dist_private([CHUNK] var-list) and dist_firstprive([CHUNK] var-list) clause in order to use shared memory for big arrays. briefly it is not putting all array into shared memory. it is putting chunk of array into shared memory. and each block is dealing with own chunk. --- I added dist_lastprivate([CHUNK] var-list). Basically lastprivate is not exist according to omp 4.0 standards, since there is no way to do synchronization among GPU Blocks. But i took off this clause doesn't need sync because it is using CHUNK. Thus, i can re-collect data from shared memory. (you can see its animation at slide page 11-12 ) - Extension of device clause --- I behave target directive as a task. Since i implemented based on OmpSs, thus OmpSs can manage my task. --- I didn't wait used to pass integer for device() clause. Thus runtime automatically started to manage multiple GPU. (OmpSs runtime is already doing this) --- Also device-to-device data transfer became available. (Normally there is no way to do this in omp) (you can see its animation at slide page 10 ) Additionally, Nowadays i am working on 2 topic 1 - How to take advantage Dynamic parallelism. --- While doing this, I am comparing dynamic parallelism with creation extra threads in advance instead creating new kernel. Because DP causes overhead and sometimes it might need communication between child-parent thread. (for example when reduction occurred. and only way to communicate global memory) 2 - Trying to find some advantages of Dynamic compilation. (from opencl side is already available. form nvidia side it is just announced with 7.0 nvrtc runtime compilation) Best Regards, Güray Özen ~grypp 2015-03-11 13:53 GMT+01:00 Thomas Schwinge : > Hi! > > On Tue, 3 Mar 2015 16:16:21 +0100, guray ozen wrote: >> I finished my master at Barcelona Supercomputing Center and i started >> to do PhD. My master thesis code generation OpenMP 4.0 for GPU >> accelerators. And i am still working on it. >> >> Last year i presented my research compiler MACC at IWOMP'14 which is >> based on OmpSs runtime (http://pm.bsc.es/). You can check here my >> paper and related paper >> http://portais.fieb.org.br/senai/iwomp2014/presentations/Guray_Ozen.pptx >> http://link.springer.com/chapter/10.1007%2F978-3-319-11454-5_16 >> >> As far as i know, GCC 5 will come with OpenMP 4.0 and OpenACC >> offloading. I am wondering that are there a any project related code >> generation within gsoc 2015? Because when i checked todo list about >> offloading, i couldn't come accross. or what am i supposed to do? > > The idea that you propose seems like a fine project for GSoC -- > definitely there'll be enough work to be done. ;-) > > Somebody from the GCC side needs to step up as a mentor. > > > Grüße, > Thomas
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:
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 does not say
> > that "one union member can be active at any time".
>
> That is not a standard wording, but what I meant is
> 6.2.6.1p7 - that when you store some union member other union members take
> unspecified values.
Well, the values are unspecified, but the value can sometimes be
deduced from what is stored.
BTW, the C11 draft I have says:
When a value is stored in a member of an object of union type, the
bytes of the object representation that do not correspond to that
member but do correspond to other members take unspecified values.
Note the "that do not correspond to that member but do correspond to
other members".
This means that on a machine where an int takes 4 bytes, if one has:
union { unsigned char a[8]; int b; } u = { .a = { 0 } };
u.b = 1;
Then the last 4 bytes of u.a take unspecified values. But the first
4 bytes depend on the representation of the int 1, and if this
representation is well-specified by the implementation (e.g. no
padding bits...), which can sometimes be deduced, then the first
4 bytes of u.a are known and one can access them via u.a.
--
Vincent Lefèvre - Web:
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 it might be a a few problems to > create a SPIR-V backend: These look -- at least superficially -- similar to issues we (that is, primarily Bernd, CCed) faced, when creating a Nvidia PTX backend (primarily for offloading use, as part of the OpenACC project we're currently working on). > 1. SPIR-V a binary Intermediate Language format but it's still not machine > code. It seems gcc backends produces a text machine code, so I think will not > be possible to produce SPIR-V a binary format directly from GCC backend. (Not a problem for text-based PTX.) Indeed I don't know if it's feasible to have GCC backends generate output in a binary format -- but then, I don't think this is a show-stopper? I'm assuming that any binary format can be represented in a textual format, and then converted into the desired binary format by an "assembler"? > 2. Because SPIR-V is not a machine format, it doesn't have any registers. > Instead it's using IDs for everything [1]. I didn't find a way to create IDs > instead of registers in GCC. > [1] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_instructions In the nvptx backend, we currently disable all register allocation, under the assumption that there is an unbounded register file, with the registers having arbitrary names -- does that match the SPIR-V model? > 3. SPIR-V supports some "non-standard" types[2], will it be a problems to > support these types in GCC frontend/backend? > [2] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_types Certainly GCC can be taught about "non-standard" types, but you'll have to see at which stage of the compilation process this is best done. Grüße, Thomas signature.asc Description: PGP signature
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 Newlib/Cygwin from the src CVS > > > repository to the new, combined GIT repository is now final. > > > > I note that this repository includes the include/ directory, in its larger > > binutils-gdb form rather than the smaller GCC form. > > > > How much of this is actually relevant for newlib? > > Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin > needs include/ for its dumper tool, which is a helper to create core > files readable by GDB. It includes > > bfd.h > elf/common.h > elf/external.h > > and all files included by those. > > > Mostly it relates to > > libiberty and object file formats, for use of code that's not included in > > this repository (which does not include libiberty). If little or none of > > this code is actually used in newlib, it might make sense to remove the > > unused files so it's clear they do not need merging from the other > > repositories. > > Of course, I have no problems to remove unused files, just not > now. I'm still looking for a small problem in the repo, so please > no unsolicited pushes for now. The problems in the repo are fixed. If you had a problem accessing the repo in the last couple of minutes, it was me moving the problematic repo out and a repaired repo back into place. Sorry about that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWuZvkD6blj.pgp Description: PGP signature
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 includes the include/ directory, in its larger > binutils-gdb form rather than the smaller GCC form. > > How much of this is actually relevant for newlib? Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin needs include/ for its dumper tool, which is a helper to create core files readable by GDB. It includes bfd.h elf/common.h elf/external.h and all files included by those. > Mostly it relates to > libiberty and object file formats, for use of code that's not included in > this repository (which does not include libiberty). If little or none of > this code is actually used in newlib, it might make sense to remove the > unused files so it's clear they do not need merging from the other > repositories. Of course, I have no problems to remove unused files, just not now. I'm still looking for a small problem in the repo, so please no unsolicited pushes for now. > (Apart from include/, various shared toplevel files and directories are > out of sync between the three repositories - GCC, binutils-gdb, > newlib-cygwin - and could do with someone identifying unmerged changes and > applying them to the repositories missing them.) This is a common problem. I guess newlib/cygwin got the oldest set and, afaik, the GCC toplevel stuff is kind of the master. It would be nice if we had some automatism in place to keep all former src repos in sync. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp32Rp5q6RAm.pgp Description: PGP signature
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 similar optimizations as for the case of big structs? I
> > tried to play around with long long in Martin's example, but failed to
> > trigger "unexpected" behaviors in GCC.
>
> I've not tried, but how about something like:
>
> struct S { long a, b, c, d; };
> union U {
> struct S a;
> struct { char b1; struct S b2; } b;
> };
> u.b.b2 = u.a;
>
> or: u.a = u.b.b2;
>
> IMHO, struct S should be large enough to avoid using registers as
> a temporary area (just in case...).
There is some PR about it in our bugzilla, and the conclusion is that
it is both invalid (in C only one union member can be active at any time,
we as extension allow type punning through unions etc.)
and we really don't want to support it.
Jakub
