Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

Hi,

I've have received news from Walter Bright that the license of the D
frontend has been assigned to the FSF. As the current maintainer of
GDC, I would like to get this moved forward, starting with getting the
ball rolling. What would need to be done? And what are the processes
required? (ie: passing the project through to technical review.)

The current home of GDC is here: https://bitbucket.org/goshawk/gdc


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Deletion of trivial insn during IRA

[Paulo J. Matos]

Ian Lance Taylor  writes:

> pa...@matos-sorge.com (Paulo J. Matos) writes:
>
>> I am trying to find where IRA, is deleting trivial insn like:
>> (set r1 r1)
>
> Search for "Discard obvious no-ops" in the function reload in the file
> gcc/reload1.c.

Thanks, that's exactly it. 

-- 
PMatos

Re: Merging gdc (GNU D Compiler) into gcc

[Andrew Haley]

On 10/04/2011 08:08 AM, Iain Buclaw wrote:

> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball rolling. What would need to be done? And what are the processes
> required? (ie: passing the project through to technical review.)

In general we welcome contributions like this.  The biggest problem in
the past has always been continued maintainership: some front- ends
have been abandoned because of a lack of TLC.  As the current GDC
maintainer, I'm sure you know that keeping up with gcc development
requires constant attention.  Do you have anyone who could be a
co-maintainer?

Andrew.

Not conform to c90?

[Bingfeng Mei]

Hello,
According to 
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Zero-Length.html#Zero-Length
A zero-length array should have a length of 1 in c90.

But I tried 

struct 
{
  char a[0];
} ZERO;

void main()
{
  int a[0];
  printf ("size = %d\n", sizeof(ZERO));
}

Compiled with gcc 4.7
~/work/install-x86/bin/gcc test.c -O2 -std=c90

size = 0

I noticed the following statement in GCC document.
"As a quirk of the original implementation of zero-length arrays, 
sizeof evaluates to zero." 

Does it mean GCC just does not conform to c90 in this respect?

Thanks,
Bingfeng Mei

Re: Not conform to c90?

[Jonathan Wakely]

On 4 October 2011 12:09, Bingfeng Mei wrote:
> Hello,
> According to 
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Zero-Length.html#Zero-Length
> A zero-length array should have a length of 1 in c90.

I think you've misunderstood that page.  You cannot have a zero-length
array in C90, what that page says is that in strict C90 you would have
to create an array of length 1 as a workaround.  It's not saying
sizeof(char[0]) is 1.

GNU C an C99 allow you to have a zero-length array.

> But I tried
>
> struct
> {
>  char a[0];
> } ZERO;
>
> void main()
> {
>  int a[0];
>  printf ("size = %d\n", sizeof(ZERO));
> }
>
> Compiled with gcc 4.7
> ~/work/install-x86/bin/gcc test.c -O2 -std=c90
>
> size = 0

If you add -pedantic you'll discover that program isn't valid in C90.

> I noticed the following statement in GCC document.
> "As a quirk of the original implementation of zero-length arrays,
> sizeof evaluates to zero."
>
> Does it mean GCC just does not conform to c90 in this respect?

C90 doesn't allow zero length arrays, so you're trying to evaluate a
GNU extension in terms of a standard.  I'm not sure what you expect to
happen.

Re: Not conform to c90?

[Erik Trulsson]

On Tue, Oct 04, 2011 at 04:09:03AM -0700, Bingfeng Mei wrote:
> Hello,
> According to 
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Zero-Length.html#Zero-Length
> A zero-length array should have a length of 1 in c90.

No, it says that zero-length arrays are not allowed in C90, so if you
want to be compliant with C90 you would have to use an array of length
1 instead.  (Normally one uses zero-length arrays to fake a variable
length array.  Technically this trick is not actually allowed by C90
even if one uses a 1-length array, but so far I have not heard of any
single C implementation where it does not work in practice.)


> 
> But I tried 
> 
> struct 
> {
>   char a[0];
> } ZERO;
> 
> void main()
> {
>   int a[0];
>   printf ("size = %d\n", sizeof(ZERO));
> }
> 
> Compiled with gcc 4.7
> ~/work/install-x86/bin/gcc test.c -O2 -std=c90
> 
> size = 0
> 
> I noticed the following statement in GCC document.
> "As a quirk of the original implementation of zero-length arrays, 
> sizeof evaluates to zero." 
> 
> Does it mean GCC just does not conform to c90 in this respect?

No, it means a program using zero-length arrays does not conform to C90
(or C99 for that matter) so as far as the C standard is concerned GCC
may do whatever it wants if it encounters a zero-length array.



-- 

Erik Trulsson
ertr1...@student.uu.se

RE: Not conform to c90?

[Bingfeng Mei]

Thank you very much. I misunderstood the document. 

Bingfeng

> -Original Message-
> From: Jonathan Wakely [mailto:jwakely@gmail.com]
> Sent: 04 October 2011 12:48
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Not conform to c90?
> 
> On 4 October 2011 12:09, Bingfeng Mei wrote:
> > Hello,
> > According to http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Zero-
> Length.html#Zero-Length
> > A zero-length array should have a length of 1 in c90.
> 
> I think you've misunderstood that page.  You cannot have a zero-length
> array in C90, what that page says is that in strict C90 you would have
> to create an array of length 1 as a workaround.  It's not saying
> sizeof(char[0]) is 1.
> 
> GNU C an C99 allow you to have a zero-length array.
> 
> > But I tried
> >
> > struct
> > {
> >  char a[0];
> > } ZERO;
> >
> > void main()
> > {
> >  int a[0];
> >  printf ("size = %d\n", sizeof(ZERO));
> > }
> >
> > Compiled with gcc 4.7
> > ~/work/install-x86/bin/gcc test.c -O2 -std=c90
> >
> > size = 0
> 
> If you add -pedantic you'll discover that program isn't valid in C90.
> 
> > I noticed the following statement in GCC document.
> > "As a quirk of the original implementation of zero-length arrays,
> > sizeof evaluates to zero."
> >
> > Does it mean GCC just does not conform to c90 in this respect?
> 
> C90 doesn't allow zero length arrays, so you're trying to evaluate a
> GNU extension in terms of a standard.  I'm not sure what you expect to
> happen.

Re: Merging gdc (GNU D Compiler) into gcc

[Ian Lance Taylor]

Iain Buclaw  writes:

> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball rolling. What would need to be done? And what are the processes
> required? (ie: passing the project through to technical review.)
>
> The current home of GDC is here: https://bitbucket.org/goshawk/gdc

Some preliminary comments.

Do you plan to move primary maintenance of the D frontend into gcc
proper, or do you plan the mirror the D frontend from an external
repository?

Are there any additional external dependencies required to build the D
frontend or the D runtime support?

I note that you have some patches to gcc proper; those patches need to
submitted individually for separate review.

The D frontend code does not appear to follow the gcc coding
conventions.  I'm not sure whether we should worry about that or not.

The D frontend code appears to be under the GPLv2.  The gcc project
would prefer GPLv3.

The D runtime appears to be in a subdirectory of gcc/d.  Ordinarily we
would prefer that it be in a separate toplevel directory, e.g.,
libdruntime.

There is a directory gcc/d/zlib, but gcc already has a top-level zlib
directory.

There is a list of most of the requirements for a new frontend at
http://gcc.gnu.org/onlinedocs/gccint/Front-End.html .  Work through the
list and make sure that everything is handled.

I would like to see this happen, thanks for pushing forward.

Ian

Re: Suboptimal __restrict optimization?

[Ulf Magnusson]

On Mon, Oct 3, 2011 at 10:22 PM, Ian Lance Taylor  wrote:
> Ulf Magnusson  writes:
>
>> Is there some reason why GCC couldn't generate this code for the first
>> version of C::f()? Is this a failure of optimization, or am I missing
>> something in how __restricted works?
>
> It's a failure of optimization.
>
> Ian
>

Is this something that has been improved in 4.6.x? (Sorry for the
initial non-reply-all.)

Re: Suboptimal __restrict optimization?

[Richard Guenther]

On Tue, Oct 4, 2011 at 5:07 PM, Ulf Magnusson  wrote:
> On Mon, Oct 3, 2011 at 10:22 PM, Ian Lance Taylor  wrote:
>> Ulf Magnusson  writes:
>>
>>> Is there some reason why GCC couldn't generate this code for the first
>>> version of C::f()? Is this a failure of optimization, or am I missing
>>> something in how __restricted works?
>>
>> It's a failure of optimization.
>>
>> Ian
>>
>
> Is this something that has been improved in 4.6.x? (Sorry for the
> initial non-reply-all.)

With 4.6 we export points-to info to RTL, so in theory it could, but
in reality combine does not work to fuse load, add and store.

Richard.

Re: Merging gdc (GNU D Compiler) into gcc

[Joseph S. Myers]

On Tue, 4 Oct 2011, Iain Buclaw wrote:

> Hi,
> 
> I've have received news from Walter Bright that the license of the D
> frontend has been assigned to the FSF. As the current maintainer of
> GDC, I would like to get this moved forward, starting with getting the
> ball rolling. What would need to be done? And what are the processes
> required? (ie: passing the project through to technical review.)

Thanks for working on this.  I think Ian covered the main technical 
points.

Was Digital Mars the only copyright holder?  I see the assignment for

GCC Digital Mars2011-10-3
Assigns Past and Future Changes to the GNU D Compiler

in copyright.list - if any parts (at least any GCC-specific parts in the 
front end as opposed to runtime libraries) have other copyright holders, 
they will also need to have assignments (and any significant changes to 
GCC outside the front end will similarly need to be covered by 
assignments).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 09:41, Andrew Haley  wrote:
> On 10/04/2011 08:08 AM, Iain Buclaw wrote:
>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this moved forward, starting with getting the
>> ball rolling. What would need to be done? And what are the processes
>> required? (ie: passing the project through to technical review.)
>
> In general we welcome contributions like this.  The biggest problem in
> the past has always been continued maintainership: some front- ends
> have been abandoned because of a lack of TLC.  As the current GDC
> maintainer, I'm sure you know that keeping up with gcc development
> requires constant attention.  Do you have anyone who could be a
> co-maintainer?
>
> Andrew.
>

There is no one else who actively co-maintains the GCC side of GDC at
this current time, only people who help out with support on a
particular platform or architecture. I do hope this will change over
the next year though.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 15:02, Ian Lance Taylor  wrote:
> Iain Buclaw  writes:
>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this moved forward, starting with getting the
>> ball rolling. What would need to be done? And what are the processes
>> required? (ie: passing the project through to technical review.)
>>
>> The current home of GDC is here: https://bitbucket.org/goshawk/gdc
>
> Some preliminary comments.
>
> Do you plan to move primary maintenance of the D frontend into gcc
> proper, or do you plan the mirror the D frontend from an external
> repository?
>

Kind of both.

It is my goal to move primary maintenance of GDC into GCC. GDC is
however in two parts, one which is the D frontend as maintained by
Digital Mars, the other is the GCC interface/bindings between the D
frontend and GCC backend as is what I maintain and develop.

The active development of the D frontend would continue to be mirrored
in an external repository, but will occasionally be merged into GDC
project.

> Are there any additional external dependencies required to build the D
> frontend or the D runtime support?
>

There are no other dependencies outside of what is required to build GCC.

> I note that you have some patches to gcc proper; those patches need to
> submitted individually for separate review.
>

These patches address two areas of the D language:
1) D calling convention.
2) Naked functions on i386 and x86_64

Some work would need to be done on naked functions at least first so
that changes required are only to gcc/config. I would be grateful if I
could get pointed in the right direction for implementing naked as a
function attribute for i386 so all frontends could benefit.

I will get on the case once I'm happy to submit them though.

> The D frontend code does not appear to follow the gcc coding
> conventions.  I'm not sure whether we should worry about that or not.
>

I have a vim macro which can sort that out. :o)

> The D frontend code appears to be under the GPLv2.  The gcc project
> would prefer GPLv3.
>

I have no problem re-licensing the project to GPLv3.

> The D runtime appears to be in a subdirectory of gcc/d.  Ordinarily we
> would prefer that it be in a separate toplevel directory, e.g.,
> libdruntime.
>

The set-up build script that is provided with the gdc development
folder makes symlinks from gcc/d/ to a libphobos toplevel directory.

> There is a directory gcc/d/zlib, but gcc already has a top-level zlib
> directory.
>

Zlib there is the version released with the D Phobos library, it is
slightly newer. But is harmless to remove.

> There is a list of most of the requirements for a new frontend at
> http://gcc.gnu.org/onlinedocs/gccint/Front-End.html .  Work through the
> list and make sure that everything is handled.
>

First question that pops up after having a quick look is, are there
any tips around for writing the scripts for the testsuite? I'm not too
familiar with Dejagnu, and the current testsuite used for GDC D2
development is written in make.

> I would like to see this happen, thanks for pushing forward.
>
> Ian
>

Cheers.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Merging gdc (GNU D Compiler) into gcc

[Andrew Pinski]

On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw  wrote:
> These patches address two areas of the D language:
> 1) D calling convention.
> 2) Naked functions on i386 and x86_64
>
> Some work would need to be done on naked functions at least first so
> that changes required are only to gcc/config. I would be grateful if I
> could get pointed in the right direction for implementing naked as a
> function attribute for i386 so all frontends could benefit.

Does D really require a new calling convention?  Also does it really
require naked support?  I think naked support is a bad idea and people
who require naked support should be writing an assembly function
wrapper.

Thanks,
Andrew Pinski

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 17:50, Joseph S. Myers  wrote:
> On Tue, 4 Oct 2011, Iain Buclaw wrote:
>
>> Hi,
>>
>> I've have received news from Walter Bright that the license of the D
>> frontend has been assigned to the FSF. As the current maintainer of
>> GDC, I would like to get this moved forward, starting with getting the
>> ball rolling. What would need to be done? And what are the processes
>> required? (ie: passing the project through to technical review.)
>
> Thanks for working on this.  I think Ian covered the main technical
> points.
>
> Was Digital Mars the only copyright holder?  I see the assignment for
>
> GCC     Digital Mars    2011-10-3
> Assigns Past and Future Changes to the GNU D Compiler
>
> in copyright.list - if any parts (at least any GCC-specific parts in the
> front end as opposed to runtime libraries) have other copyright holders,
> they will also need to have assignments (and any significant changes to
> GCC outside the front end will similarly need to be covered by
> assignments).
>

The original copyrights for the GDC D front-end for GCC are in the
name of David Friedman, who has been MIA since 2007.  Since the
project has been revived, all changes and additions have been
copyrighted in my name, Michael's, and Vincenzo's.  Would I require
approval of these people to assign ownership over to FSF?

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: new triplet for x32 psABI?

[H.J. Lu]

On Mon, Oct 3, 2011 at 8:44 PM, Michael LIAO  wrote:
> On Mon, Oct 3, 2011 at 5:53 PM, H.J. Lu  wrote:
>> On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO  wrote:
>>> On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger  wrote:
 On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:

 please don't top post

>>>
>>> sorry, it's my first post on mailing.
>>>
> Most examples would be related to tools generating code.
>
> Suppose you have a software package with several hard-coded fully
> optimized assembly file for different targets. Your build system need
> to know the current target as well as target ABI to select the correct
> assembly file to build it. It even desirable if it includes a simple
> script to help generate assembly code (like the one in OpenSSL), you'd
> better know the target ABI to prepare proper glue code without
> breaking ABI.

 hjlu posted examples to the x32 site as to handle this.  the only 
 difference
 between x86_64 and x32 is the size of the pointers.

>>>
>>> Besides the pointer size, there are other differences like indirect
>>> branch which need different code sequence on x32 and x64. Indirect
>>> branch would be used in assembly code (yeah, concrete example would
>>> valuable here but indirect branch should be used potentially and
>>> possibly in assembly code.) If the assembly code use indirect branch,
>>> it needs to know the target ABI and generate/use difference code path.
>>>
>>
>> In assembly codes, most, if not all, of x86-64 indirect branch work fine for 
>> x32
>>
>
> that may cause the target IP out of the first 4G range if assembly
> code won't follow x32 abi, e.g. indirect target is stored in a memory
> location and assembly direct use 64-bit near absolute indirect call
> with m64 opernad since the branch target is 32 bits in memory but that
> call will read 64-bit value and result in garbage on high 32 bits of
> the final IP.
>

X32 assembler/linker should handle it properly by zero-extending address
to 64bit.

-- 
H.J.

Re: Merging gdc (GNU D Compiler) into gcc

[Joseph S. Myers]

On Tue, 4 Oct 2011, Iain Buclaw wrote:

> The original copyrights for the GDC D front-end for GCC are in the
> name of David Friedman, who has been MIA since 2007.  Since the
> project has been revived, all changes and additions have been
> copyrighted in my name, Michael's, and Vincenzo's.  Would I require
> approval of these people to assign ownership over to FSF?

In the absence of permission from the FSF to do otherwise in a particular 
case (such permission would be sought via the Steering Committee, via this 
list), all significant contributors to front ends need to have papers 
(assignment or disclaimer) on file at the FSF.  
 
states what is significant.  Papers may be assignments from individuals 
with disclaimers from any employer with a potential claim, or they may be 
corporate assignments from an employer owning the rights.  (Disclaimers to 
the public domain are also possible as an alternative to assignments.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 4 October 2011 20:36, Andrew Pinski  wrote:
> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw  wrote:
>> These patches address two areas of the D language:
>> 1) D calling convention.
>> 2) Naked functions on i386 and x86_64
>>
>> Some work would need to be done on naked functions at least first so
>> that changes required are only to gcc/config. I would be grateful if I
>> could get pointed in the right direction for implementing naked as a
>> function attribute for i386 so all frontends could benefit.
>
> Does D really require a new calling convention?  Also does it really
> require naked support?  I think naked support is a bad idea and people
> who require naked support should be writing an assembly function
> wrapper.
>
> Thanks,
> Andrew Pinski
>

Naked functions are part of the D spec, and I would have to remove a
few areas of the D runtime library if they were to go (I may get a
number emails from D users too asking where it has gone).

The D calling convention is one thing I can cope just fine without. It
is needed more for use with some naked functions in the D runtime
library.  The major quirk of the D ABI really is that routines will
return floating point return values on the FPU stack, and expects this
to be cleaned off by the caller, even if they are not used. I can
instead fix the D runtime library if it is that much of a problem.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Merging gdc (GNU D Compiler) into gcc

[Tom Tromey]

> "Iain" == Iain Buclaw  writes:

Ian> There is a directory gcc/d/zlib, but gcc already has a top-level zlib
Ian> directory.

Iain> Zlib there is the version released with the D Phobos library, it is
Iain> slightly newer. But is harmless to remove.

You could alternatively update the version in gcc.

Tom

RE: The AST tree modification. Edited.

[Iyer, Balaji V]

Hello,
For most of the things you are looking for, please look for a function 
called build_decl. It is used in several places inside GCC. Let me give you a 
small example, 

If you do the following:

tree x = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifer("ii"), 
integer_type_node)

you will declare a variable called "ii" of type "integer."

Similarly, to create a new internal structure, if do something like this:

tree struct_frame = lang_hooks.make_type (RECORD_TYPE);
tree struct_field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, 
get_identifier("variable"), integer_type_node)
TREE_CHAIN(struct_field) = struct_frame

You will create the following internal structure

struct {
   int variable;
}

I hope this helps you get started.

Thanks,

Balaji V .Iyer.

-Original Message-
From: niXman [mailto:i.nix...@gmail.com] 
Sent: Monday, October 03, 2011 6:51 PM
To: gcc@gcc.gnu.org
Subject: The AST tree modification. Edited.

Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the 
information on types of translation unit, and generate static const array of 
types rtti_ex _ on its base;  //
enum class type_ {
   char_, uchar_, short_, ushort_, int_, uint_, long_, ulong_,
   int64_, uint64_, array_, pointer_, double_, long_double_, float_,
   class_
};

struct rtti_ex_ { // <
   const char* name;
   const type_ type;
   const size_t size;
   const size_t align;
   const size_t offset;
};

// generated from plugin.
static const rtti_ex_ rtti_ex_array_[] = {
   {...},
   {...},
   {...}
};
/

There aren't any problems with information collection from AST. There is a 
complexity with AST modification:
1. How to declare a variable?
2. How to declare the typedef?
3. How to declare a structure?
4. How to declare an array of structures?
I suppose that there should be a function like: tree make_subtree (const char* 
source); which result I could insert in the corresponding node. But I haven't 
found it.

Please, give me some links on this subject. It is very desirable, if you could 
give some links with examples.

Thanks.

Re: The AST tree modification. Edited.

[niXman]

Hello.
"lang_hooks" - what this? where is declared?
Thanks!


2011/10/5 Iyer, Balaji V 
>
> Hello,
>        For most of the things you are looking for, please look for a function 
> called build_decl. It is used in several places inside GCC. Let me give you a 
> small example,
>
> If you do the following:
>
> tree x = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifer("ii"), 
> integer_type_node)
>
> you will declare a variable called "ii" of type "integer."
>
> Similarly, to create a new internal structure, if do something like this:
>
> tree struct_frame = lang_hooks.make_type (RECORD_TYPE);
> tree struct_field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, 
> get_identifier("variable"), integer_type_node)
> TREE_CHAIN(struct_field) = struct_frame
>
> You will create the following internal structure
>
> struct {
>   int variable;
> }
>
> I hope this helps you get started.
>
> Thanks,
>
> Balaji V .Iyer.
>
> -Original Message-
> From: niXman [mailto:i.nix...@gmail.com]
> Sent: Monday, October 03, 2011 6:51 PM
> To: gcc@gcc.gnu.org
> Subject: The AST tree modification. Edited.
>
> Hi everybody!
> It is necessary to implement a plug-in for GCC designed to collect the 
> information on types of translation unit, and generate static const array of 
> types rtti_ex _ on its base;  //
> enum class type_ {
>   char_, uchar_, short_, ushort_, int_, uint_, long_, ulong_,
>   int64_, uint64_, array_, pointer_, double_, long_double_, float_,
>   class_
> };
>
> struct rtti_ex_ { // <
>   const char* name;
>   const type_ type;
>   const size_t size;
>   const size_t align;
>   const size_t offset;
> };
>
> // generated from plugin.
> static const rtti_ex_ rtti_ex_array_[] = {
>   {...},
>   {...},
>   {...}
> };
> /
>
> There aren't any problems with information collection from AST. There is a 
> complexity with AST modification:
> 1. How to declare a variable?
> 2. How to declare the typedef?
> 3. How to declare a structure?
> 4. How to declare an array of structures?
> I suppose that there should be a function like: tree make_subtree (const 
> char* source); which result I could insert in the corresponding node. But I 
> haven't found it.
>
> Please, give me some links on this subject. It is very desirable, if you 
> could give some links with examples.
>
> Thanks.

Re: Merging gdc (GNU D Compiler) into gcc

[David Brown]

On 04/10/11 21:36, Andrew Pinski wrote:

On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw  wrote:

These patches address two areas of the D language:
1) D calling convention.
2) Naked functions on i386 and x86_64

Some work would need to be done on naked functions at least first so
that changes required are only to gcc/config. I would be grateful if I
could get pointed in the right direction for implementing naked as a
function attribute for i386 so all frontends could benefit.


Does D really require a new calling convention?  Also does it really
require naked support?  I think naked support is a bad idea and people
who require naked support should be writing an assembly function
wrapper.

Thanks,
Andrew Pinski




"naked" functions are often useful in embedded systems, and are 
therefore useful (and implemented) on many gcc targets.  It would make 
sense to have the attribute available universally in gcc, if that 
doesn't involve a lot of extra work, even though it is of little use on 
"big" systems (Linux, Windows, etc.).


mvh.,

David

Re: Merging gdc (GNU D Compiler) into gcc

[Andrew Pinski]

On Tue, Oct 4, 2011 at 2:40 PM, David Brown  wrote:
> "naked" functions are often useful in embedded systems, and are therefore
> useful (and implemented) on many gcc targets.  It would make sense to have
> the attribute available universally in gcc, if that doesn't involve a lot of
> extra work, even though it is of little use on "big" systems (Linux,
> Windows, etc.).

Is it really useful if you can have a small top-level inline-asm wrapper?

-- Pinski

gcc-4.4-20111004 is now available

[gccadmin]

Snapshot gcc-4.4-20111004 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20111004/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 179528

You'll find:

 gcc-4.4-20111004.tar.bz2 Complete GCC

  MD5=9f80b38dc5b7d557eb72fd63945c4ad5
  SHA1=c3a076df75c5380ceabadae25442daabf257e5f0

Diffs from 4.4-20110927 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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: Merging gdc (GNU D Compiler) into gcc

[Ian Lance Taylor]

Iain Buclaw  writes:

> On 4 October 2011 20:36, Andrew Pinski  wrote:
>> On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclaw  wrote:
>>> These patches address two areas of the D language:
>>> 1) D calling convention.
>>> 2) Naked functions on i386 and x86_64
>>>
>>> Some work would need to be done on naked functions at least first so
>>> that changes required are only to gcc/config. I would be grateful if I
>>> could get pointed in the right direction for implementing naked as a
>>> function attribute for i386 so all frontends could benefit.
>>
>> Does D really require a new calling convention?  Also does it really
>> require naked support?  I think naked support is a bad idea and people
>> who require naked support should be writing an assembly function
>> wrapper.
>>
>> Thanks,
>> Andrew Pinski
>>
>
> Naked functions are part of the D spec, and I would have to remove a
> few areas of the D runtime library if they were to go (I may get a
> number emails from D users too asking where it has gone).
>
> The D calling convention is one thing I can cope just fine without. It
> is needed more for use with some naked functions in the D runtime
> library.  The major quirk of the D ABI really is that routines will
> return floating point return values on the FPU stack, and expects this
> to be cleaned off by the caller, even if they are not used. I can
> instead fix the D runtime library if it is that much of a problem.

I don't personally have a problem with naked function support.  If it is
part of the D language I think it is reasonable to add it to gcc
backends.  This will presumably require some new target hook to see if
the functionality is available.

Using a different ABI for ordinary functions seem at first glance to be
a mistake, because it hurts interoperability with code not written in D.
I guess if this is implemented it would require some other target hook.

Ian

Re: Merging gdc (GNU D Compiler) into gcc

[Ian Lance Taylor]

Iain Buclaw  writes:

> The active development of the D frontend would continue to be mirrored
> in an external repository, but will occasionally be merged into GDC
> project.

Well, Go does set a precedent for this.  The main issue here is that
this means that there is (another) directory containing source code that
the gcc maintainers can't update.  This is workable if the D frontend
does not #include any gcc header files or call any gcc functions.  That
is, if it is truly standalone.  (The Go frontend is not yet in this
state, although I am slowly working toward it.)


> Some work would need to be done on naked functions at least first so
> that changes required are only to gcc/config. I would be grateful if I
> could get pointed in the right direction for implementing naked as a
> function attribute for i386 so all frontends could benefit.

Needs a target hook in target.def and a new attribute probably in
c-family/c-common.c.  The new attribute would check the target hook to
see whether the backend supports it.


>> The D runtime appears to be in a subdirectory of gcc/d.  Ordinarily we
>> would prefer that it be in a separate toplevel directory, e.g.,
>> libdruntime.
>>
>
> The set-up build script that is provided with the gdc development
> folder makes symlinks from gcc/d/ to a libphobos toplevel directory.

That is kind of awkward, though--why not just set up libphobos in the
first place?  I understand this may require two directories to be
mirrored.


> First question that pops up after having a quick look is, are there
> any tips around for writing the scripts for the testsuite? I'm not too
> familiar with Dejagnu, and the current testsuite used for GDC D2
> development is written in make.

DejaGNU is too horrible for me to talk about.  I can't recommend
anything other than blind copying of existing scripts.

Ian

Re: The AST tree modification. Edited.

[Ian Lance Taylor]

niXman  writes:

> "lang_hooks" - what this? where is declared?

Running grep will show you that it is declared in langhooks.h.

The lang hooks are frontend hooks called from the middle-end.  The hooks
are defined in langhooks.h.

Ian

Incidents in ARM-NEON-Intrinsics

[塩谷晶彦]

Hi, Maintainer,

I found some incidents in
http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html#ARM-NEON-Intrinsics

Please check the following:

|6.54.3.8 Comparison (less-than-or-equal-to)
|
|  uint32x2_t vcle_u32 (uint32x2_t, uint32x2_t) 
|  Form of expected instruction(s): vcge.u32 d0, d0, d0 
  (snip)
|  uint32x4_t vcleq_f32 (float32x4_t, float32x4_t) 
|  Form of expected instruction(s): vcge.f32 q0, q0, q0 

in above "vcge"s may be "vcle" or "vcgt".

|6.54.3.10 Comparison (less-than)
|
|  uint32x2_t vclt_u32 (uint32x2_t, uint32x2_t) 
|  Form of expected instruction(s): vcgt.u32 d0, d0, d0 
  (snip)
|  uint32x4_t vcltq_f32 (float32x4_t, float32x4_t) 
|  Form of expected instruction(s): vcgt.f32 q0, q0, q0 

in above "vcgt"s may be "vclt" or "vcge".

|6.54.3.12 Comparison (absolute less-than-or-equal-to)
|
|  uint32x2_t vcale_f32 (float32x2_t, float32x2_t) 
|  Form of expected instruction(s): vacge.f32 d0, d0, d0 
|
|  uint32x4_t vcaleq_f32 (float32x4_t, float32x4_t) 
|  Form of expected instruction(s): vacge.f32 q0, q0, q0 

in above "vacge"s may be "vacle" or "vacgt".

|6.54.3.14 Comparison (absolute less-than)
|
|  uint32x2_t vcalt_f32 (float32x2_t, float32x2_t) 
|  Form of expected instruction(s): vacgt.f32 d0, d0, d0 
|
|  uint32x4_t vcaltq_f32 (float32x4_t, float32x4_t) 
|  Form of expected instruction(s): vacgt.f32 q0, q0, q0 

in above "vacge"s must be "vaclt" or "vacge".

Best Regard.


Hashigo (Akihiko Shiotani)

ITS Group, 4th-Engineering Division
FUJITSU TEN LIMITED
2-28, Gosho-Dori 1-chome,
Hyogo-ku, KOBE, JAPAN
(ZIP:652-8510)
E-mail：shiot...@rd.ten.fujitsu.com

The three principal virtues of a programmer are
Laziness,Impatience, and Hubris.
(Larry Wall)

Re: Merging gdc (GNU D Compiler) into gcc

[Iain Buclaw]

On 5 October 2011 00:10, Ian Lance Taylor  wrote:
> Iain Buclaw  writes:
>
>> The active development of the D frontend would continue to be mirrored
>> in an external repository, but will occasionally be merged into GDC
>> project.
>
> Well, Go does set a precedent for this.  The main issue here is that
> this means that there is (another) directory containing source code that
> the gcc maintainers can't update.  This is workable if the D frontend
> does not #include any gcc header files or call any gcc functions.  That
> is, if it is truly standalone.  (The Go frontend is not yet in this
> state, although I am slowly working toward it.)
>
>

The D frontend does not include any gcc headers or call any gcc functions.

>> Some work would need to be done on naked functions at least first so
>> that changes required are only to gcc/config. I would be grateful if I
>> could get pointed in the right direction for implementing naked as a
>> function attribute for i386 so all frontends could benefit.
>
> Needs a target hook in target.def and a new attribute probably in
> c-family/c-common.c.  The new attribute would check the target hook to
> see whether the backend supports it.
>
>
>>> The D runtime appears to be in a subdirectory of gcc/d.  Ordinarily we
>>> would prefer that it be in a separate toplevel directory, e.g.,
>>> libdruntime.
>>>
>>
>> The set-up build script that is provided with the gdc development
>> folder makes symlinks from gcc/d/ to a libphobos toplevel directory.
>
> That is kind of awkward, though--why not just set up libphobos in the
> first place?  I understand this may require two directories to be
> mirrored.
>
>

The gcc/d folder is only structured as it is now because gdc code is
shipped as a separate entity from gcc, that you can then apply to any
version of gcc that is supported.  This would no longer be the case if
merged in.  I assume best thing to do for me to get started in the
*doing* would be to set-up a new branch prep'd up as I intend for it
to be if this were to be moved forward.

>> First question that pops up after having a quick look is, are there
>> any tips around for writing the scripts for the testsuite? I'm not too
>> familiar with Dejagnu, and the current testsuite used for GDC D2
>> development is written in make.
>
> DejaGNU is too horrible for me to talk about.  I can't recommend
> anything other than blind copying of existing scripts.
>

:-)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: C++11 atomic library notes

[Jeffrey Yasskin]

On Fri, Sep 30, 2011 at 1:36 PM, Andrew MacLeod  wrote:
> I've been working on GCC's C++11 atomic implementation. In discussions with
> Lawrence, I've recently discovered a fundamental change in what libstdc++-v3
> is likely to provide as far as an implementation.
>
> Previously, header files provided a choice between a locked or a lock-free
> implementation, preferring the lock-free version when available on the
> architecture and falling back to the locked version in other cases.
>
> Now the thought is to provide lock-free instructions when possible, and fall
> back to external function calls the rest of the time. These would then be
> resolved by an application or system library.
>
> If proceeding with that change, it would be convenient to make the same
> calls that other implementations are going to use, allowing OS or
> application providers to simply provide a single library with atomic
> routines that can be used  by multiple C++11 compilers.
>
> Since GCC 4.7 stage 1 is going to end shortly and it would be nice to get
> the cxx-mem-model branch integrated, I quickly wrote up what the current
> plan for the branch is regarding these external calls and such and brought
> up a couple of issues.  Its located in the gcc wiki at:
> http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
>
> Its my first cut at it, so hopefully its mostly correct :-)
>
> If anyone has any interest or input on this subject, the sooner it is
> brought up the better!

I wanted to comment on
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary#volatility. Say we have:

typedef pair DWord;
std::atomic shared_var;

void thread1() {
  use(shared_var.load());
}

void thread2() {
  // It's legal to add "volatile" in a pointer or reference cast.
  volatile std::atomic* v_shared_var = &shared_var;
  // Now this looks identical to an access to a real volatile object.
  v_shared_var->store(DWord(ptr, val));
}

If, as the document proposes, "16 byte volatile will have to call the
external rotines, but 16 byte non-volatiles would be lock-free.", and
the external routines use locked accesses for 16-byte volatile
atomics, then this makes the concurrent accesses to shared_var not
thread-safe. To be thread-safe, we'd have to call the external
routines for every 16-byte atomic, not just the volatile ones, and
those routines would have to use locked accesses uniformly rather than
distinguishing between volatile and non-volatile accesses. Not good.

Even worse, on LL/SC architectures, every lock-free RMW operation
potentially involves multiple loads, so this interpretation of
volatility would prohibit lock-free access to all objects.

I see two ways out:
1) Say that accessing a non-volatile atomic through a volatile
reference or pointer causes undefined behavior. The standard doesn't
say that, and the casts are implicit, so this is icky.
2) Say that volatile atomic accesses may be implemented with more than
one instruction-level access.

(2) is something like how volatile reads of 128-bit structs involve
multiple mov instructions that execute in an arbitrary order. It's
also unlikely to cause problems in existing programs because nobody's
using volatile atomics yet, and they'll only start using them in ways
that work with what compilers implement.

Jeffrey