printf enhancement
Since it is possible to use the 0b prefix to specify a binary number in GCC/C++, will there be any resistance to add %b format specifier to the printf family format strings? Best regards Piotr Wyderski
Re: printf enhancement
On 01/22/2010 12:01 PM, Piotr Wyderski wrote: > Since it is possible to use the 0b prefix > to specify a binary number in GCC/C++, > will there be any resistance to add %b > format specifier to the printf family format > strings? > This has absolutely nothing to do with GCC and its development, you understand. Paolo.
Re: printf enhancement
Paolo Carlini wrote: > This has absolutely nothing to do with GCC and its development, you > understand. You sure? Isn't the implementation of printf formatting engine a part of GCC support libraries and doesn't adding an extension to it belong to the category "development"?
Re: printf enhancement
On 01/22/2010 12:31 PM, Piotr Wyderski wrote: > You sure? Isn't the implementation of printf formatting engine a part > of GCC support libraries The C library, to which library printf belongs, is not part of the GCC project. Paolo.
Re: printf enhancement
Paolo Carlini wrote: > The C library, to which library printf belongs, is not part of the GCC > project. In that case it certainly isn't a GCC issue.
A bug on 32-bit host?
Hello,
I am tracking a bug and find the lshift_value function in
expmed.c questionable (both head and gcc 4.4).
Suppose HOST_BITS_PER_WIDE_INT = 32, bitpos = 0
and bitsize = 33, the following expression is wrong
high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos))
& ((1 << (bitpos + bitsize - HOST_BITS_PER_WIDE_INT)) - 1);
v >> 32 bits on a 32-bit machine is undefined. On i386,
v >> 32 results in v, which is not intention of the function.
Cheers,
Bingfeng Mei
static rtx
lshift_value (enum machine_mode mode, rtx value, int bitpos, int bitsize)
{
unsigned HOST_WIDE_INT v = INTVAL (value);
HOST_WIDE_INT low, high;
if (bitsize < HOST_BITS_PER_WIDE_INT)
v &= ~((HOST_WIDE_INT) -1 << bitsize);
if (bitpos < HOST_BITS_PER_WIDE_INT)
{
low = v << bitpos;
/* Obtain value by shifting and set zeros for remaining part*/
if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT)
high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos))
& ((1 << (bitpos + bitsize - HOST_BITS_PER_WIDE_INT)) - 1);
else
high = 0;
}
else
{
low = 0;
high = v << (bitpos - HOST_BITS_PER_WIDE_INT);
}
return immed_double_const (low, high, mode);
}
How to make make changes in gcc code
Hi, I posted this question on the mailing list gcc-h...@gcc.gnu.org but did not get any reply about it. I have bootstrapped gcc 4.4.2 on my machine and now i have to make changes in gcc code. However, I dont know how to make those changes effective.Do I need to change the source files accordingly and bootstrap again or is there any other way of making changes in the source code and compiling only the affected source files. Point me to any documentation that may be available. Thanks in advance -- cheers sandy -- cheers sandy
Re: Question about peephole2 and addressing mode
2010/1/22 Richard Henderson : > On 01/21/2010 06:22 AM, Mohamed Shafi wrote: >> >> Hello all, >> >> I am doing a port for a 32bit a target in GCC 4.4.0. The target >> supports (base + offset) addressing mode for QImode store instructions >> but not for QImode load instructions. GCC doesn't take the middle >> path. It either supports an addressing mode completely and doesn't >> support at all. I tried lot of hacks to support (base + offset) >> addressing mode only for QI mode store instructions. After a lot of >> fight i finally gave up and removed the QImode support for this >> addressing mode completely in GO_IF_ LEGITIMATE_ADDRESS macro. Now i >> am pursing an alternate solution. Have peephole2 patterns to implement >> QImode (base+offset) addressing mode for store instructions. How does >> it sound? > > It doesn't sound totally implausible. But as you notice, peepholes only act > on sequential instructions. In order to assist generating sequential > instructions, you could try allowing base+offset in non-strict mode. > > I fear you'll likely have to use a combination of methods in order to get > decent code here. can you point out the combination of the methods in your mind? And by the way is it possible to allow the addressing mode completely and then break it down into register indirect addressing mode after reload pass? Regards, Shafi
Re: How to make make changes in gcc code
On Fri, Jan 22, 2010 at 1:48 PM, sandeep soni wrote: > Hi, > > I posted this question on the mailing list gcc-h...@gcc.gnu.org > but did not get any reply about it. > > I have bootstrapped gcc 4.4.2 on my machine and now i have to make > changes in gcc code. However, I dont know how to make those changes > effective.Do I need to change the source files accordingly and > bootstrap again or is there any other way of making changes in the > source code and compiling only the affected source files. Typing make in the build directory will re-make the necessary parts. Note that because you bootstrapped stage2 and stage3 will be completely re-built. For developing configure with --disable-bootstrap and type make all-gcc to re-build things in gcc/, or in gcc/ for example use make cc1 to just rebuild cc1. Richard. > > Point me to any documentation that may be available. > > Thanks in advance > > -- > cheers > sandy > > > > -- > cheers > sandy >
How to write legitimize_reload_address
Hi all,
I am doing a port of a 32bit target in GCC 4.4.0. I have written the
macro legitimize_reload_address which does something similar to what
the target pa does. i.e
For the PA, transform:
memory(X + )
into:
if ( & mask) >= 16
Y = ( & ~mask) + mask + 1 Round up.
else
Y = ( & ~mask) Round down.
Z = X + Y
memory (Z + ( - Y));
The input for the macro is
(plus:SI (reg/f:SI 23 r7)
(const_int 65536 [0x1]))
and the target support only 15bit signed offset so in
legitimize_reload_address i have
mask = 0x3fff;
offset = INTVAL (XEXP ((addr), 1));
/* Choose rounding direction. Round up if we are >= halfway. */
if ((offset & mask) >= ((mask + 1) / 2))
newoffset = (offset & ~mask) + mask + 1;
else
newoffset = offset & ~mask;
/* Ensure that long displacements are aligned. */
newoffset &= ~(GET_MODE_SIZE (mode) - 1);
if (newoffset)
{
temp = gen_rtx_PLUS (Pmode, XEXP (addr, 0),
GEN_INT (newoffset));
addr = gen_rtx_PLUS (Pmode, temp, GEN_INT (offset - newoffset));
push_reload (XEXP (addr, 0), 0, &XEXP (addr, 0), 0,
BASE_REG_CLASS, Pmode, VOIDmode, 0, 0,
opnum, type);
return addr;
}
The macro is defined like this:
#define LEGITIMIZE_RELOAD_ADDRESS(X,MODE,OPNUM,TYPE,IND_L,WIN) \
do { \
rtx new_x = legitimize_reload_address (X, MODE, OPNUM, TYPE, IND_L); \
if (new_x) \
{ \
X = new_x; \
goto WIN;\
} \
} while (0)
I issue that i am facing is that if i return null_rtx without doing
any processing the complier works propely. But if
legitimize_reload_address gets executed and jumbs to the label WIN
iget ICE.
ice1.c:5: error: unrecognizable insn:
(insn 45 44 20 2 ice1.c:5 (set (mem/c:SI (plus:SI (reg:SI 16 r0)
(const_int 65536 [0x1])) [4 S4 A32])
(reg:SI 2 d2)) -1 (nil))
Is there something wrong with my legitimize_relaod_address?
Thanks for your time.
Regards,
shafi
Re: Question about peephole2 and addressing mode
On 01/22/10 06:23, Mohamed Shafi wrote: 2010/1/22 Richard Henderson: On 01/21/2010 06:22 AM, Mohamed Shafi wrote: Hello all, I am doing a port for a 32bit a target in GCC 4.4.0. The target supports (base + offset) addressing mode for QImode store instructions but not for QImode load instructions. GCC doesn't take the middle path. It either supports an addressing mode completely and doesn't support at all. I tried lot of hacks to support (base + offset) addressing mode only for QI mode store instructions. After a lot of fight i finally gave up and removed the QImode support for this addressing mode completely in GO_IF_ LEGITIMATE_ADDRESS macro. Now i am pursing an alternate solution. Have peephole2 patterns to implement QImode (base+offset) addressing mode for store instructions. How does it sound? It doesn't sound totally implausible. But as you notice, peepholes only act on sequential instructions. In order to assist generating sequential instructions, you could try allowing base+offset in non-strict mode. I fear you'll likely have to use a combination of methods in order to get decent code here. can you point out the combination of the methods in your mind? And by the way is it possible to allow the addressing mode completely and then break it down into register indirect addressing mode after reload pass? I would recommend you look at how the PA port handles these problems. It has integer indexed loads, but no stores. You have to reject these addresses in GO_IF_LEGITIMATE_ADDRESS, but you can make operand predicates & constraints which allow these addressing modes. Jeff
Re: How to write legitimize_reload_address
On 01/22/10 07:10, Mohamed Shafi wrote:
Hi all,
I am doing a port of a 32bit target in GCC 4.4.0. I have written the
macro legitimize_reload_address which does something similar to what
the target pa does. i.e
For the PA, transform:
memory(X +)
into:
if ( & mask)>= 16
Y = ( & ~mask) + mask + 1 Round up.
else
Y = ( & ~mask) Round down.
Z = X + Y
memory (Z + ( - Y));
The input for the macro is
(plus:SI (reg/f:SI 23 r7)
(const_int 65536 [0x1]))
and the target support only 15bit signed offset so in
legitimize_reload_address i have
mask = 0x3fff;
offset = INTVAL (XEXP ((addr), 1));
/* Choose rounding direction. Round up if we are>= halfway. */
if ((offset& mask)>= ((mask + 1) / 2))
newoffset = (offset& ~mask) + mask + 1;
else
newoffset = offset& ~mask;
/* Ensure that long displacements are aligned. */
newoffset&= ~(GET_MODE_SIZE (mode) - 1);
if (newoffset)
{
temp = gen_rtx_PLUS (Pmode, XEXP (addr, 0),
GEN_INT (newoffset));
addr = gen_rtx_PLUS (Pmode, temp, GEN_INT (offset - newoffset));
push_reload (XEXP (addr, 0), 0,&XEXP (addr, 0), 0,
BASE_REG_CLASS, Pmode, VOIDmode, 0, 0,
opnum, type);
return addr;
}
The macro is defined like this:
#define LEGITIMIZE_RELOAD_ADDRESS(X,MODE,OPNUM,TYPE,IND_L,WIN) \
do { \
rtx new_x = legitimize_reload_address (X, MODE, OPNUM, TYPE, IND_L); \
if (new_x) \
{ \
X = new_x; \
goto WIN;\
} \
} while (0)
I issue that i am facing is that if i return null_rtx without doing
any processing the complier works propely. But if
legitimize_reload_address gets executed and jumbs to the label WIN
iget ICE.
ice1.c:5: error: unrecognizable insn:
(insn 45 44 20 2 ice1.c:5 (set (mem/c:SI (plus:SI (reg:SI 16 r0)
(const_int 65536 [0x1])) [4 S4 A32])
(reg:SI 2 d2)) -1 (nil))
Is there something wrong with my legitimize_relaod_address?
Perhaps. However, I would strongly recommend you get your port working
before defining LEGITIMIZE_RELOAD_ADDRESS. It should not be required
for proper operation, particularly for the case you're dealing with.
Once your port is working, particularly any special cases for secondary
reloads, then go back and enable LEGITIMIZE_RELOAD_ADDRESS.
As for debugging LEGITIMIZE_RELOAD_ADDRESS, be aware that properly
defining this macro often requires knowing how reload itself works and
the ability to predict how reload will react to changes you make in
LEGITIMIZE_RELOAD_ADDRESS. With that in mind, I would start by
examining the addresses passed to LEGITIMIZE_RELOAD_ADDRESS, the
resulting insns & reload to verify they all look as you expect.
Jeff
Re: The "right way" to handle alignment of pointer targets in the compiler?
On 01/01/2010 09:51 PM, Tim Prince wrote:
Benjamin Redelings I wrote:
Hi,
I have been playing with the GCC vectorizer and examining assembly
code that is produced for dot products that are not for a fixed number
of elements. (This comes up surprisingly often in scientific codes.)
So far, the generated code is not faster than non-vectorized code, and
I think that it is because I can't find a way to tell the compiler
that the target of a double* is 16-byte aligned.
From Pr 27827 - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827 :
"I just quickly glanced at the code, and I see that it never uses
"movapd" from memory, which is a key to getting decent performance."
How many people would take advantage of special machinery for some old
CPU, if that's your goal?
Actually, I think a lot. I did some tests using -mtune=barcelona, and
the code was no faster than a no-SSE version, on a Core2 Duo, even
though movupd instructions were generated.
Color me confused. Does "some old CPU" include all CPUs except the Core
i7? I hear that there is no penalty (or very little penalty) for using
unaligned loads on the Core i7, but apparently Core2 still needs the
aligned loads?
simplifying your example to
double f3(const double* p_, const double* q_,int n)
{
double sum = 0;
for(int i=0; i
Re: A bug on 32-bit host?
"Bingfeng Mei" writes: > /* Obtain value by shifting and set zeros for remaining part*/ > if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT) > high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos)) > & ((1 << (bitpos + bitsize - HOST_BITS_PER_WIDE_INT)) - 1); That is not what expmed.c looks like on mainline or on gcc 4.4 branch. You must have a local change. Ian
RE: A bug on 32-bit host?
Oops, that is embarassing. Usually any local change are marked with #ifdef in our port. I shoud double check next time when I report an issue. Thanks. Bingfeng > -Original Message- > From: Ian Lance Taylor [mailto:i...@google.com] > Sent: 22 January 2010 15:04 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org > Subject: Re: A bug on 32-bit host? > > "Bingfeng Mei" writes: > > > /* Obtain value by shifting and set zeros for remaining part*/ > > if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT) > > high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos)) > > & ((1 << (bitpos + bitsize - > HOST_BITS_PER_WIDE_INT)) - 1); > > That is not what expmed.c looks like on mainline or on gcc 4.4 branch. > You must have a local change. > > Ian > >
GCC 4.4.3 Released
The GNU Compiler Collection version 4.4.3 has been released. GCC 4.4.3 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.4.2. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!
Re: How to make make changes in gcc code
sandeep soni wrote:
Hi,
I posted this question on the mailing list gcc-h...@gcc.gnu.org
but did not get any reply about it.
I have bootstrapped gcc 4.4.2 on my machine and now i have to make
changes in gcc code.
Changing code is done usually with a good editor :-) but I suppose I am not
answering your question.
Perhaps you are asking how to understand what part of GCC you might improve.
However, I dont know how to make those changes effective.
You did not explain at all what kind of changes you want to do, and why!
Nobody can help you if you don't explain your objectives.
If you want to contribute to GCC core, you should be aware of the [legal] prerequisites, see
http://gcc.gnu.org/contribute.html - in particular the transfer of copyright to FSF migh take several weeks or months.
I am supposing you want to make GPLv3 free software changes to GCC. But I don't know why you want to do that. GCC is a
very complex software (four million lines of source code),and nobody understand all of it.
A possibly simpler solution for you might be to develop a plugin for your changes. GCC 4.5 (the next release) will allow
plugins. And the MELT plugin offer a higher-level language to code plugins.
Still, we cannot help you because we cannot guess your objectives.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: printf enhancement
On Fri, 22 Jan 2010, Piotr Wyderski wrote: > Paolo Carlini wrote: > > > The C library, to which library printf belongs, is not part of the GCC > > project. > > In that case it certainly isn't a GCC issue. Assuming this feature is accepted in glibc, you'll want to update GCC's -Wformat flag.
Re: printf enhancement
Since it is possible to use the 0b prefix to specify a binary number in GCC/C++, will there be any resistance to add %b format specifier to the printf family format strings? You can do that yourself by using the hook facility for printf, see (libc) Customizing Printf in the GNU C library manual; this is a GNU extention and not supported by ISO C.
Mangled Typedef names in GNU 4.1.2 DWARF data?
The GNU 4.1.2 C++ compiler is mangling typedef names to the point that they are
not retrievable from the DWARF data.
For example, the type BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
The GNU 4.1.2 compiler generates the following DWARF data for this type
<1><1279>: Abbrev Number: 35 (DW_TAG_union_type)
<127a> DW_AT_sibling : <12a8>
<127e> DW_AT_name: $_4
<1282> DW_AT_byte_size : 4
<1283> DW_AT_decl_file : 35
<1284> DW_AT_decl_line : 29
<2><1285>: Abbrev Number: 36 (DW_TAG_member)
<1286> DW_AT_name: ch
<1289> DW_AT_decl_file : 35
<128a> DW_AT_decl_line : 30
<128b> DW_AT_type:
<2><128f>: Abbrev Number: 36 (DW_TAG_member)
<1290> DW_AT_name: iVal
<1295> DW_AT_decl_file : 35
<1296> DW_AT_decl_line : 31
<1297> DW_AT_type:
<2><129b>: Abbrev Number: 36 (DW_TAG_member)
<129c> DW_AT_name: IVal
<12a1> DW_AT_decl_file : 35
<12a2> DW_AT_decl_line : 32
<12a3> DW_AT_type:
Notice that the union name has been changed to "$_4" in DIE <1279>.
The GNU 3.4.4 compiler generates the following DWARF data from the same source
code:
<1><11d0>: Abbrev Number: 27 (DW_TAG_union_type)
DW_AT_sibling : <123f>
DW_AT_name: (indirect string, offset: 0x6e): BASE_UNION
DW_AT_byte_size : 4
DW_AT_decl_file : 3
DW_AT_decl_line : 29
<2><11dc>: Abbrev Number: 28 (DW_TAG_member)
DW_AT_name: ch
DW_AT_decl_file : 3
DW_AT_decl_line : 30
DW_AT_type:
<2><11e6>: Abbrev Number: 28 (DW_TAG_member)
DW_AT_name: iVal
DW_AT_decl_file : 3
DW_AT_decl_line : 31
DW_AT_type:
<2><11f2>: Abbrev Number: 28 (DW_TAG_member)
DW_AT_name: IVal
DW_AT_decl_file : 3
DW_AT_decl_line : 32
DW_AT_type:
<2><11fe>: Abbrev Number: 29 (DW_TAG_subprogram)
DW_AT_sibling : <1219>
DW_AT_name: (indirect string, offset: 0x79): operator=
DW_AT_type: <123f>
DW_AT_artificial : 1
DW_AT_declaration : 1
<3><120d>: Abbrev Number: 9 (DW_TAG_formal_parameter)
DW_AT_type: <1245>
DW_AT_artificial : 1
<3><1213>: Abbrev Number: 10 (DW_TAG_formal_parameter)
DW_AT_type: <124b>
<2><1219>: Abbrev Number: 30 (DW_TAG_subprogram)
DW_AT_sibling : <1230>
DW_AT_name: $_4
DW_AT_artificial : 1
DW_AT_declaration : 1
<3><1224>: Abbrev Number: 9 (DW_TAG_formal_parameter)
DW_AT_type: <1245>
DW_AT_artificial : 1
<3><122a>: Abbrev Number: 10 (DW_TAG_formal_parameter)
DW_AT_type: <124b>
<2><1230>: Abbrev Number: 31 (DW_TAG_subprogram)
DW_AT_name: $_4
DW_AT_artificial : 1
DW_AT_declaration : 1
<3><1237>: Abbrev Number: 9 (DW_TAG_formal_parameter)
DW_AT_type: <1245>
DW_AT_artificial : 1
Notice that DIE <11D0> contains the correct type name. Also notice that
coincidently, DIE <1230> has a constructor with the "$_4" name which was used
as the type name in GNU 4.1.2.
Why is GNU 4.1.2 generating the mangled type name and how do I correct this to
generate the real type name?
Re: printf enhancement
Alfred M. Szmidt wrote: >Since it is possible to use the 0b prefix to specify a binary >number in GCC/C++, will there be any resistance to add %b format >specifier to the printf family format strings? > > You can do that yourself by using the hook facility for printf, see > (libc) Customizing Printf in the GNU C library manual; this is a GNU > extention and not supported by ISO C. > If you add support for it, you may break code that already registers %b using this functionality, no? Cheers, Nils
Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
Ron Louzon wrote:
The GNU 4.1.2 C++ compiler is mangling typedef names to the point that they are
not retrievable from the DWARF data.
For example, the type BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
This is an anonymous union which is typedef'ed to BASE_UNION.
The GNU 4.1.2 compiler generates the following DWARF data for this type
<1><1279>: Abbrev Number: 35 (DW_TAG_union_type)
<127a> DW_AT_sibling : <12a8>
<127e> DW_AT_name: $_4
<1282> DW_AT_byte_size : 4
<1283> DW_AT_decl_file : 35
<1284> DW_AT_decl_line : 29
This doesn't look correct. The union has no name, so DW_AT_name should
not be present or should be null. From the DWARF v.3 spec:
2.15 Identifier Names
Any debugging information entry representing a program entity that has been
given a name may have a DW_AT_name attribute, whose value is a string
representing the name as it appears in the source program. A debugging
information entry containing no name attribute, or containing a name attribute
whose value consists of a name containing a single null byte, represents a
program entity for which no name was given in the source.
<2><1285>: Abbrev Number: 36 (DW_TAG_member)
<1286> DW_AT_name: ch
<1289> DW_AT_decl_file : 35
<128a> DW_AT_decl_line : 30
<128b> DW_AT_type:
<2><128f>: Abbrev Number: 36 (DW_TAG_member)
<1290> DW_AT_name: iVal
<1295> DW_AT_decl_file : 35
<1296> DW_AT_decl_line : 31
<1297> DW_AT_type:
<2><129b>: Abbrev Number: 36 (DW_TAG_member)
<129c> DW_AT_name: IVal
<12a1> DW_AT_decl_file : 35
<12a2> DW_AT_decl_line : 32
<12a3> DW_AT_type:
Notice that the union name has been changed to "$_4" in DIE <1279>.
The GNU 3.4.4 compiler generates the following DWARF data from the same source
code:
<1><11d0>: Abbrev Number: 27 (DW_TAG_union_type)
DW_AT_sibling : <123f>
DW_AT_name: (indirect string, offset: 0x6e): BASE_UNION
DW_AT_byte_size : 4
DW_AT_decl_file : 3
DW_AT_decl_line : 29
This is similarly incorrect. The union has no name.
Why is GNU 4.1.2 generating the mangled type name and how do I correct this to
generate the real type name?
A better question might by why there is no DW_TAG_typedef
DIE which looks like
DW_TAG_typedef
DW_AT_name: BASE_UNION
DW_AT_type: <1279>
BTW gcc-4.3.2 generates
DW_AT_name:
which is also incorrect.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Question about code licensing
Hi, folks, There is renewed interest in getting a D compiler into the GCC sources. The most direct route for this to happen is to use the existing Digital Mars DMD front end. The current DMD front end code is GPL licensed, and copyright is owned by Digital Mars. If they were to fork the source, and contribute that fork under the current license of GCC, do they still possess the freedom to continue to do what they wish with the original code? Thanks, Jerry Quinn
Re: Question about code licensing
> The current DMD front end code is GPL licensed, and copyright is owned > by Digital Mars. If they were to fork the source, and contribute that > fork under the current license of GCC, do they still possess the freedom > to continue to do what they wish with the original code? Yes.
Re: Question about code licensing
On Fri, Jan 22, 2010 at 05:31:03PM -0800, Jerry Quinn wrote: > There is renewed interest in getting a D compiler into the GCC sources. > The most direct route for this to happen is to use the existing Digital > Mars DMD front end. > > The current DMD front end code is GPL licensed, and copyright is owned > by Digital Mars. If they were to fork the source, and contribute that > fork under the current license of GCC, do they still possess the freedom > to continue to do what they wish with the original code? The standard FSF contribution paperwork assigns copyright to the FSF and then grants back a license to the contributor to do whatever they want with the original code (continue to develop it, distribute under other terms, embed in proprietary products -- not sure about any restrictions). I'm not sure whether that would work for what they want to do or not. If it would, it's easy. Otherwise they might be able to make some other arrangement with the FSF. Ideally, something could be worked out so they wouldn't feel the need to continue to maintain a fork. It's not very efficient.
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote: > Timothy Madden writes: > >> Is there any progress or start yet in implemententing export for C++ >> templates ? > > Not to my knowledge. > > The C++0x standards committee considered deprecating export for C++0x, > but I think they have decided to retain it for now. > > >> Why is everybody such not interested in this ? It would be such a >> great feature, especially for >> a leading C++ implementation like gcc ... > > Why would it be useful? What advantage does it provide? > > >> Why is it so hard to store template definitions (and the set of >> symbols visible to them) in an >> object file, probably as a representation of the parsed template source tree >> ? > > I recommend reading "Why We Can't Afford Export." This link may work > for you: > > http://docs.google.com/viewer?a=v&q=cache:lmlZ1p7te3gJ:www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf+why+we+can't+afford+export+sutter&hl=en&gl=us&pid=bl&srcid=ADGEESgDdiuh8WxBHeWHGfnK_iJXXYj0XCWOwfnHQuja8Ihd5567rnFyRsF13uY-HN9NbjYJpwMsUo8VQNx5_ffYSiOfOMeIfKMW-d8s57IMr8B8vUN3UfpXLXVtlLd1C8UiUNNe-i7t&sig=AHIEtbQo42iDSyaR0-I4hQ1bHFV3WTeYfA > > or search for the PDF. > > Note in particular that namespace issues are hideously complex with > export. Thanks to two-phase name lookup, the meaning of a template > depends on the environment in which it is defined. That means that in > order to correctly instantiate an exported template, the export file > must contain not only the template definition, but the definition of > all names mentioned in the template definition, recursively. > > As far as I know, exactly one compiler implements export, and nobody > uses it. It's because it is not implemented yet that it is not used ... :) Even if I would buy Comeau I would not write code that I know will not compile with any other compiler. Many books though teach how to use a #define to turn your template code into export-ready templates, even if export is not widely available. Actually lots of books and articles talk about export. I have seen that paper in the link, N1426, and I find it to be biased against export ... Everyone will admit to the technical challenges when implementing export. Template code is not object code. It is something else, it is another level, another way of doing things... This is why templates in C++ are so great. For that the compiler has to adapt, there is a new step required in the compilation process, for template instantiation. It is like there are now two levels of compilation: for templates and for object code ... So yes, there would be quite some work for it. The requirement to store symbol table entries when generating pre-compiled templates is as true as it can be. Such an idea is known for quite some time: it is what a precompiled header does: it stores the symbols table. Or at least there are certain similarities or a common approach or point of view. Is this such a problem ? The export keyword is there in the standard with some purpose: it allows the programmer to separate the template definition from the declaration. Its benefits are organised and clear code (and template code) for end-users of the language. It allows anyone to use the template without knowledge of how it is implemented and where it is implemented. It is like in object code one can use external functions and variables without knowledge of where do they come from and how do they work. You just have the declarations and you can use them, templates or not. Many people will say now that it is not the same, that it can not be the same because template code is not like object code, it goes by different rules. Well then I will have to say it loud and clear, that for the end-user's view of things, yes it is ! For them it is the same thing, this is what export does! And it is the end users that matter, it is them the compiler is made for, right ? The differences that still exist (rightfully so, for technical reasons) are ... not important. Someone on that long thread on comp.lang.c++.moderated about 'export' has put things in a very clear light, 6 years ago, when asked what is export so good for: Imagine for a moment that C++ had no one-definition-rule problems, and that it /required/ you to have the body of each and every function you use (call or take address) included in every translation unit ! Imagine you would have to always include the function definition of all functions you call in a .cc file, and the functions that are called by them. How would that be ? Now imagine that this happened because compiler implementers decided it is a real lot of work to devise something like a linker that would link function definitions with references at some point after compilation... I know it is actually possible anyway to write programmes even so, I know that if you insist enough you could write programmes by including all function definitions everywhere, but I bet you 1 dollar that you would not lik
