Re: libgcc_s.so.1 exception handling behaviour depending on glibc version
Jonathan Wilson kirjoitti: > Neither does Linux - by linking against a recent library you are > *asking* for a binary that requires that library. If you understand > that you might understand why everyone is saying you should build on the > lowest common denominator of the systems you're targetting. > > If you insist on shipping executables not just source then you have to be > prepared to make a bit more effort to make them distributable. You're > aware of the problems, but seem to be resisting everyone's advice on how > to avoid them. On windows, it is possible to build a binary using a compiler on Windows XP > that can then run on older versions of windows simply by not using any features > specific to the newest versions of windows XP (or by using LoadLibrary and > GetProcAddress to see if those features are available or not). Can you do the same thing on linux? The only prerequisite is a GCC & glibc & other required libraries combination which produces apps for Linux/XYZ instead of only for the Linux version/distro happened to be installed as the development platform... Simple solution but not generally liked by the Linux distributors Why? Otherwise this kind of toolchain would be always present in a Linux distro. Just like the tools on Windoze are, they are not only for WinXP or 2k or Win9x, but for Win32 My habit is to produce everything for RHL7.3, or even for RHL6.2 although working on newer Linuces. Then I have some hope that the binaries will run also on newer RHLs, and hopefully also on SuSEs, Mandrakes and so on... Surprisingly things like OpenOffice, Mozilla, Acrobat Reader etc. seem to work, so some companies really have these kind of "generic tools"
Re: GCSE considers read only memory clobbered by function calls.
Jeffrey A Law <[EMAIL PROTECTED]> wrote on 09/05/2005 18:17:45: > Yes, it looks quite reasonable. Please go ahead with the full testing > cycle and consider the patch pre-approved once complete. > I have changed the patch according to some feedbacks that I have got -- the main idea didn't change. One change is to check the MEM_READONLY_P flag also in load_killed_in_block. The new patch is attached below. bootstrap passed (with -O2 -g -fgcse -fgcse-las --param max-gcse-passes=3) and no new regressions on powerpc-apple-darwin. Since I have changed the patch a bit I am asking again for approval to commit. 2005-05-23 Mostafa Hagog <[EMAIL PROTECTED]> * gcse.c (compute_transp, load_killed_in_block): use MEM_READONLY_P. (See attached file: gcse_las3.patch) gcse_las3.patch Description: Binary data
i387 control word register definition is missing
Hello!
It looks that i387 control word register definition is missing from register
definitions for i386 processor. Inside i386.h, we have:
#define FIXED_REGISTERS \
/*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, \
/*arg,flags,fpsr,dir,frame*/\
1,1, 1, 1,1, \
/*xmm0,xmm1,xmm2,xmm3,xmm4,xmm5,xmm6,xmm7*/ \
0, 0, 0, 0, 0, 0, 0, 0, \
/*mmx0,mmx1,mmx2,mmx3,mmx4,mmx5,mmx6,mmx7*/ \
0, 0, 0, 0, 0, 0, 0, 0, \
/* r8, r9, r10, r11, r12, r13, r14, r15*/ \
2, 2, 2, 2, 2, 2, 2, 2, \
/*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/ \
2, 2,2,2,2,2,2,2}
However, there should be another register defined, i387 control word register,
'fpcr' (Please look at chapter 11.2.1.2 and 11.2.1.3 in
http://webster.cs.ucr.edu/AoA/Windows/HTML/RealArithmetic.html). There are two
instructions in i386.md that actually use fpcr:
(define_insn "x86_fnstcw_1"
[(set (match_operand:HI 0 "memory_operand" "=m")
(unspec:HI [(reg:HI FPSR_REG)] UNSPEC_FSTCW))]
"TARGET_80387"
"fnstcw\t%0"
[(set_attr "length" "2")
(set_attr "mode" "HI")
(set_attr "unit" "i387")])
(define_insn "x86_fldcw_1"
[(set (reg:HI FPSR_REG)
(unspec:HI [(match_operand:HI 0 "memory_operand" "m")] UNSPEC_FLDCW))]
"TARGET_80387"
"fldcw\t%0"
[(set_attr "length" "2")
(set_attr "mode" "HI")
(set_attr "unit" "i387")
(set_attr "athlon_decode" "vector")])
However, RTL template for these two instructions state that they use i387 STATUS
register, but they should use i387 CONTROL register. To be correct, a new fixed
register should be introduced:
#define FIXED_REGISTERS \
/*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, \
/*arg,flags,fpsr,fpcr,dir,frame*/ \
1,1, 1, 1, 1,1,\
...
and above two insn definitions should be changed to use FPCR_REG. Unfortunately,
some changes would be needed through the code (mainly to various register masks
and definitions) to fix this issue, so I would like to ask for opinions on this
change before proceeding.
This change would be needed to get i387 status word switching instructions out
of the loops, i.e.:
for ...
Thanks,
Uros.
i387 control word reg definition is missing
Hello!
It looks that i387 control word register definition is missing from register
definitions for i386 processor. Inside i386.h, we have:
#define FIXED_REGISTERS \
/*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, \
/*arg,flags,fpsr,dir,frame*/\
1,1, 1, 1,1, \
/*xmm0,xmm1,xmm2,xmm3,xmm4,xmm5,xmm6,xmm7*/ \
0, 0, 0, 0, 0, 0, 0, 0, \
/*mmx0,mmx1,mmx2,mmx3,mmx4,mmx5,mmx6,mmx7*/ \
0, 0, 0, 0, 0, 0, 0, 0, \
/* r8, r9, r10, r11, r12, r13, r14, r15*/ \
2, 2, 2, 2, 2, 2, 2, 2, \
/*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/ \
2, 2,2,2,2,2,2,2}
However, there should be another register defined, i387 control word register,
'fpcr' (Please look at chapter 11.2.1.2 and 11.2.1.3 in
http://webster.cs.ucr.edu/AoA/Windows/HTML/RealArithmetic.html). There are two
instructions in i386.md that actually use fpcr:
(define_insn "x86_fnstcw_1"
[(set (match_operand:HI 0 "memory_operand" "=m")
(unspec:HI [(reg:HI FPSR_REG)] UNSPEC_FSTCW))]
"TARGET_80387"
"fnstcw\t%0"
[(set_attr "length" "2")
(set_attr "mode" "HI")
(set_attr "unit" "i387")])
(define_insn "x86_fldcw_1"
[(set (reg:HI FPSR_REG)
(unspec:HI [(match_operand:HI 0 "memory_operand" "m")] UNSPEC_FLDCW))]
"TARGET_80387"
"fldcw\t%0"
[(set_attr "length" "2")
(set_attr "mode" "HI")
(set_attr "unit" "i387")
(set_attr "athlon_decode" "vector")])
However, RTL template for these two instructions state that they use i387 STATUS
register, but they should use i387 CONTROL register. To be correct, a new fixed
register should be introduced:
#define FIXED_REGISTERS \
/*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, \
/*arg,flags,fpsr,fpcr,dir,frame*/ \
1,1, 1, 1, 1,1,\
...
and above two insn definitions should be changed to use FPCR_REG. Unfortunately,
some changes would be needed through the code (mainly to various register masks
and definitions) to fix this issue, so I would like to ask for opinions on this
matter before proceeding.
This change is needed to get i387 status word switching instructions in
(int)->(float) conversions out of the loops, i.e.:
int i;
double d;
for (x = 0... {
i[x] = d[x];
}
Thanks,
Uros.
gcc-specific?
Hi In order to avoid being off-topic, does anybody know any mailing list where people discuss just algorithms specifically? It doesn't need to be compiler construction-specific -- even though they're amongst the most interesting algorithms around. I've recently devised an algorithm to produce user interfaces/paper forms for equipment inspection rounds. It eventually boils down to finding the largest continuous binary submatrix in a sparse binary matrix. Of course, it would be totally ridiculous is someone else described the algorithm already. I'd like to avoid that kind of embarrasment. The algorithm descends the problem's geometry stream in optimal order, and for each geometry searches the associated combinatorial stream. If someone knows of an interesting discussion place where people can verify each other's results, please let me know. Greetings Erik
Re: gcc-specific?
Erik Poupaert wrote: > If someone knows of an interesting discussion place where people can > verify each other's results, please let me know. Try the following: http://groups-beta.google.com/group/algogeeks -- Marcel Cox
Re: i387 control word reg definition is missing
On Mon, May 23, 2005 at 10:28:05AM +0200, Uros Bizjak wrote:
> This change is needed to get i387 status word switching instructions in
> (int)->(float) conversions out of the loops, i.e.:
>
> int i;
> double d;
>
> for (x = 0... {
>i[x] = d[x];
> }
I think it would also be very useful to have these instructions available as
builtins (they don't seem to be at the moment), in order to implement
fegetround() and fesetround() for example.
These functions are very useful to implement interval arithmetic, and if the
compiler knew how to optimize away some of these instructions, that would be
_really_ nice. For example : remove a rounding mode change when it is
followed by another one, or remove a rounding mode change when the compiler
knows that the rounding mode has previously been changed to that one, etc.
--
Sylvain
GCC and Floating-Point
Hello. I'm writing an extensive article about floating-point programming on Linux, including a focus on GCC's compilers. This is an outgrowth of many debates about topics like -ffast-math and -mfpmath=sse|387, and I hope it will prove enlightening for myself and others. Among the subjects covered: accuracy, precision, data organization, code speed, threading issues, and a bit about interval arithmetic and significant digits. Naturally, due to hardware availability, I'll be focusing on x86 and x86_64 systems. I'd appreciate comments, ideas, and suggestions from the folk on this mailing list. Thank you. ..Scott
Re: [rfc] mainline slush
> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > Just to let folks know that mips-elf fails to build newlib. > There's a segfault in is_gimple_reg_type(), which is being > passed a null type. I'm not sure if I'll have time to look > at it tonight. I took a look and it seemed to work for me, I'll double check with a clean tree and all multilibs in a bit. -eric
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 16:19, Eric Christopher wrote: > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > > > Just to let folks know that mips-elf fails to build newlib. > > There's a segfault in is_gimple_reg_type(), which is being > > passed a null type. I'm not sure if I'll have time to look > > at it tonight. > > I took a look and it seemed to work for me, I'll double check with a > clean tree and all multilibs in a bit. > > -eric This will be PR 21638. There's been several proposed patches for this now, but none seems to have been committed. It is getting a bit silly. R.
Re: [rfc] mainline slush
Eric Christopher <[EMAIL PROTECTED]> writes: >> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush >> >> Just to let folks know that mips-elf fails to build newlib. >> There's a segfault in is_gimple_reg_type(), which is being >> passed a null type. I'm not sure if I'll have time to look >> at it tonight. > > I took a look and it seemed to work for me, I'll double check with a > clean tree and all multilibs in a bit. Eric (and anyone else who wasn't aware): there's been a lot of discussion about this on gcc-patches since I posted that message: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html It's also PR21638: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638 It looks like Andrew, Jeff and Daniel have got things in hand but no patch has been committed yet. Richard
Re: [rfc] mainline slush
> Eric (and anyone else who wasn't aware): there's been a lot of > discussion about this on gcc-patches since I posted that message: > > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html > > It's also PR21638: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638 > > It looks like Andrew, Jeff and Daniel have got things in hand > but no patch has been committed yet. Interesting. I'll look. Thanks. -eric
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote: > > Eric (and anyone else who wasn't aware): there's been a lot of > > discussion about this on gcc-patches since I posted that message: > > > > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html > > > > It's also PR21638: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638 > > > > It looks like Andrew, Jeff and Daniel have got things in hand > > but no patch has been committed yet. > > Interesting. I'll look. Thanks. I'm slogging through the missing calls to recompute invariant-ness, and the like right now. Depending on how much longer this goes, I may go ahead with adding all the missing calls w/o installing the checking portion of the patch. jeff
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 10:00 -0600, Jeffrey A Law wrote: > On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote: > > > Eric (and anyone else who wasn't aware): there's been a lot of > > > discussion about this on gcc-patches since I posted that message: > > > > > > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html > > > > > > It's also PR21638: > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638 > > > > > > It looks like Andrew, Jeff and Daniel have got things in hand > > > but no patch has been committed yet. > > > > Interesting. I'll look. Thanks. > I'm slogging through the missing calls to recompute invariant-ness, > and the like right now. Depending on how much longer this goes, I may > go ahead with adding all the missing calls w/o installing the checking > portion of the patch. > Originally, this is one of the reasons the patch was not committed: There were places in fortran that weren't clean, etc, and i just didn't have time to go hunting (which is why i posted it to gcc patches, and left it out there for whoever wanted it). Though apparently, not checking this stuff has led us to arguably worse consequences. So i'm a little wary of not installing the patch at some point soon, although i understand we all have time constraints. --Dan
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote: > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote: > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > > > > > Just to let folks know that mips-elf fails to build newlib. > > > There's a segfault in is_gimple_reg_type(), which is being > > > passed a null type. I'm not sure if I'll have time to look > > > at it tonight. > > > > I took a look and it seemed to work for me, I'll double check with a > > clean tree and all multilibs in a bit. > > > > -eric > > This will be PR 21638. There's been several proposed patches for this > now, but none seems to have been committed. It is getting a bit silly. It's not a question of getting a bit silly, but a question of being thorough. Daniel's checking patch has exposed several more cases were we are not getting those flag bits set correctly and IMHO this situation has shown how important it is to get those bits set correctly. I'd much rather take the time to fix all these problems, install the fixes along with the checking bits to ensure they never come back rather than to iterate on each one separately. jeff
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote: > On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote: > > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote: > > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > > > > > > > Just to let folks know that mips-elf fails to build newlib. > > > > There's a segfault in is_gimple_reg_type(), which is being > > > > passed a null type. I'm not sure if I'll have time to look > > > > at it tonight. > > > > > > I took a look and it seemed to work for me, I'll double check with a > > > clean tree and all multilibs in a bit. > > > > > > -eric > > > > This will be PR 21638. There's been several proposed patches for this > > now, but none seems to have been committed. It is getting a bit silly. > It's not a question of getting a bit silly, but a question of being > thorough. Daniel's checking patch has exposed several more cases were > we are not getting those flag bits set correctly and IMHO this situation > has shown how important it is to get those bits set correctly. > > I'd much rather take the time to fix all these problems, install the > fixes along with the checking bits to ensure they never come back > rather than to iterate on each one separately. > However, in the mean-time I'm stuck. I can't build my world anymore, so I can't test the compiler Maybe we should start a timer on this one. R.
Re: Compiling GCC with g++: a report
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | Hi, | | I spent the week-end trying to get GCC -- mainline -- compilable | (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). | | My summary is: It is largely doable and it is within our reach at this | point of development. More specifically, I successfully got all | files necessary to build a native GNU C compiler on an i686-pc-linux-gnu. | Attempt to get the GNU C++ compiler through the same massage is | underway (but I'm going to bed shortly ;-)). | | I think this project is beneficial to GCC for several reasons: I have received several inquiries as whether this is a project to have GCC implemeted in C++. The answer is no. It is a project that will align us with our coding standard that codes should live in the large intersection of C and C++. Those not fluent in C++ should have to worry -- when/if they write "good" codes in C :-). Most certanly, patch reviewers will make suggestions in case a patch falls outside. And since I brought the issue, I volunteer to help fulfill that task. -- Gaby
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 12:19 -0400, Daniel Berlin wrote: > > > > Originally, this is one of the reasons the patch was not committed: > There were places in fortran that weren't clean, etc, and i just didn't > have time to go hunting (which is why i posted it to gcc patches, and > left it out there for whoever wanted it). > > Though apparently, not checking this stuff has led us to arguably worse > consequences. > > So i'm a little wary of not installing the patch at some point soon, > although i understand we all have time constraints. I haven't got to the Fortran FE yet, but I just found a gem in our C front-end. The code to recompute these status bits has a check like if (decl_function_context (decl) == current_function_decl ) Which seems pretty reasonable until you realize that when called from tree-nested.c, current_function_decl hasn't been set yet. So we get one set of flags when we lower nonlocal references in nested functions, then a different set when we actually compile the nested function. Ugh. At least everything is building at this point. It's mostly an exercise in slogging through testresults looking for new failures created by the new checking code. Jeff
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote: > On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote: > > On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote: > > > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote: > > > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > > > > > > > > > Just to let folks know that mips-elf fails to build newlib. > > > > > There's a segfault in is_gimple_reg_type(), which is being > > > > > passed a null type. I'm not sure if I'll have time to look > > > > > at it tonight. > > > > > > > > I took a look and it seemed to work for me, I'll double check with a > > > > clean tree and all multilibs in a bit. > > > > > > > > -eric > > > > > > This will be PR 21638. There's been several proposed patches for this > > > now, but none seems to have been committed. It is getting a bit silly. > > It's not a question of getting a bit silly, but a question of being > > thorough. Daniel's checking patch has exposed several more cases were > > we are not getting those flag bits set correctly and IMHO this situation > > has shown how important it is to get those bits set correctly. > > > > I'd much rather take the time to fix all these problems, install the > > fixes along with the checking bits to ensure they never come back > > rather than to iterate on each one separately. > > > > However, in the mean-time I'm stuck. I can't build my world anymore, so > I can't test the compiler I understand. But realize that I'm trying to ultimately save you time in the long run -- in the mean time you can pretty easily hack around these problems. > Maybe we should start a timer on this one. I would recommend against. Every one of these missing calls to compute the status bits properly is a latent bug waiting to be exposed. I'd much rather bite the bullet and get them fixed now. The fact that it's affecting a lot of people keep the coals hot on my feet :-) jeff
Re: libgcc_s.so.1 exception handling behaviour depending on glibcversion
Kai Rottu wrote: On windows, it is possible to build a binary using a compiler on Windows XP that can then run on older versions of windows simply by not using any features specific to the newest versions of windows XP (or by using LoadLibrary and GetProcAddress to see if those features are available or not). Can you do the same thing on linux? ... The only prerequisite is a GCC & glibc & other required libraries combination which produces apps for Linux/XYZ instead of only for the Linux version/distro happened to be installed as the development platform... Simple solution but not generally liked by the Linux distributors Why? Otherwise this kind of toolchain would be always present in a Linux distro. ... I think the LSB group is working on a toolchain that would fill this need; see http://www.linuxbase.org/build/ Also, I'm about to submit crosstool to Fedora Extras, though I suspect they'll only ship a restricted set of crosstool toolchains (maybe crosscompilers targeting all FC4-supported architectures), since each crosstool toolchain .rpm is fairly sizable, 20-30MB. I expect that eventually, such toolchains will in fact come standard with Linux distributions to some extent.
Re: Compiling GCC with g++: a report
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes: >> (4) . Ranjit> Tom Tromey's GCJX (gcjx_branch in CVS), the completely Ranjit> rewritten Java front-end that is written in C++. Plugging this into gcc has largely been fine, thanks to an earlier round of patches in this area. The biggest unsolved build issue is that it would be nice, when bootstrapping native (build=host=target), to use the just-built g++ and libstdc++ for gcjx. This involves some wacky build reordering that I've been avoiding looking at. Tom
Re: [rfc] mainline slush
On Monday 23 May 2005 18:20, Jeffrey A Law wrote: > I'd much rather take the time to fix all these problems, install the > fixes along with the checking bits to ensure they never come back > rather than to iterate on each one separately. And int the mean time, things stay broken? Gr. Steven
Re: [rfc] mainline slush
Jeffrey A Law wrote: much rather bite the bullet and get them fixed now. The fact that it's affecting a lot of people keep the coals hot on my feet :-) Jeff -- I know you're doing everything you can to fix the problems. Do you have an ETA for a solution? Probably if it's on the order of a day, everyone can wait; if it's a week, that might be more of a problem. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote: > Jeffrey A Law wrote: > > much rather bite the bullet and get them fixed now. The fact that it's > > affecting a lot of people keep the coals hot on my feet :-) > > Jeff -- > > I know you're doing everything you can to fix the problems. Do you have > an ETA for a solution? Probably if it's on the order of a day, everyone > can wait; if it's a week, that might be more of a problem. Depends on how we want to proceed. Fixing the immediate problem in forwprop.c is trivial as are fixes for similar problems in other places exposed by Daniel's checking code. C, C++ and Java look to be in pretty good shape right now. What's going to be more interesting will be the Fortran failures, which I expect to start looking at this afternoon. I'd like to hold off making any kind of estimate or decisions until I've sat down and looked at the Fortran goop. Jeff
Re: [rfc] mainline slush
Jeffrey A Law wrote: On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote: Jeffrey A Law wrote: much rather bite the bullet and get them fixed now. The fact that it's affecting a lot of people keep the coals hot on my feet :-) Jeff -- I know you're doing everything you can to fix the problems. Do you have an ETA for a solution? Probably if it's on the order of a day, everyone can wait; if it's a week, that might be more of a problem. Depends on how we want to proceed. Fixing the immediate problem in forwprop.c is trivial as are fixes for similar problems in other places exposed by Daniel's checking code. C, C++ and Java look to be in pretty good shape right now. What's going to be more interesting will be the Fortran failures, which I expect to start looking at this afternoon. I'd like to hold off making any kind of estimate or decisions until I've sat down and looked at the Fortran goop. Fair enough. Would you mind reporting back later today, then? One possibility is to do the changes that fix our primary languages (C, C++, and Java, since it's easy) and deal with Fortran later. If we can get the mainline bootstrapping and passing regression tests on primary platforms, but leaving Fortran broken, that might be worthwhile. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
Mike Stump wrote: On May 17, 2005, at 3:16 PM, Karel Gardas wrote: 1) the most expensive seems to be comptypes -- at least from data L2 refill point of view (~17%) 2) comptypes is also the most CPU intensive operation since the most of time is spent there I think comptypes can be sped up by canonicalizing types better, and also adding a conservative hash and checking it first. We've researched this in detail. Speeding up comptypes can best be done by calling it less often. One of the primary uses is the template machinery, which works very hard to work out whether it already has an existing specialization. The first step is to insert canonicalizations and other speedups there; that would reduce the number of calls to comptypes dramatically. There are also places in the front end that make redundant calls to comptypes; for example, during declaration processing we sometimes check whether or not two declarations match more than once. The changes you suggest might still be helpful, but I'd prefer to see the bigger algorithms fixed first, as those changes will have secondary benefits beyond comptypes as well. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On Mon, 23 May 2005, Mark Mitchell wrote: Mike Stump wrote: On May 17, 2005, at 3:16 PM, Karel Gardas wrote: 1) the most expensive seems to be comptypes -- at least from data L2 refill point of view (~17%) 2) comptypes is also the most CPU intensive operation since the most of time is spent there I think comptypes can be sped up by canonicalizing types better, and also adding a conservative hash and checking it first. We've researched this in detail. Speeding up comptypes can best be done by calling it less often. One of the primary uses is the template machinery, which works very hard to work out whether it already has an existing specialization. The first step is to insert canonicalizations and other speedups there; that would reduce the number of calls to comptypes dramatically. There are also places in the front end that make redundant calls to comptypes; for example, during declaration processing we sometimes check whether or not two declarations match more than once. The changes you suggest might still be helpful, but I'd prefer to see the bigger algorithms fixed first, as those changes will have secondary benefits beyond comptypes as well. Mark, shall I put some RFE to bugzilla to have it recordered somewhere, or is this already on your company or team TODO list? Thanks! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
Karel Gardas wrote: On Mon, 23 May 2005, Mark Mitchell wrote: Mike Stump wrote: On May 17, 2005, at 3:16 PM, Karel Gardas wrote: 1) the most expensive seems to be comptypes -- at least from data L2 refill point of view (~17%) 2) comptypes is also the most CPU intensive operation since the most of time is spent there I think comptypes can be sped up by canonicalizing types better, and also adding a conservative hash and checking it first. We've researched this in detail. Speeding up comptypes can best be done by calling it less often. One of the primary uses is the template machinery, which works very hard to work out whether it already has an existing specialization. The first step is to insert canonicalizations and other speedups there; that would reduce the number of calls to comptypes dramatically. There are also places in the front end that make redundant calls to comptypes; for example, during declaration processing we sometimes check whether or not two declarations match more than once. The changes you suggest might still be helpful, but I'd prefer to see the bigger algorithms fixed first, as those changes will have secondary benefits beyond comptypes as well. Mark, shall I put some RFE to bugzilla to have it recordered somewhere, or is this already on your company or team TODO list? It's certainly well-known here -- but that's not to say it shouldn't go in some nice FSF-ish place as well in case somebody else wants to work on it. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
Mark Mitchell wrote: > It's certainly well-known here -- but that's not to say it shouldn't > go in some nice FSF-ish place as well in case somebody else wants to > work on it. Probably it's obvious but indeed, we already noticed that this is also *the* bottleneck for the compile-time performance on some template-heavy TR1 facilities: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02151.html Paolo.
Re: Some questions about FIELD_DECL
Daniel Berlin wrote: While moving FIELD_DECL to it's own substruct, the following questions have come up. I figured one of you might know: 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a place where we would actually try to *output* a FIELD_DECL directly, but maybe i've missed something. I ask because the C frontend tests decl_assembler_name on field decl, but never sets it on them. Related to this: 2. Do we allow setting the section of a FIELD_DECL, so that DECL_SECTION_NAME on FIELD_DECL is necessary? We should need neither DECL_ASSEMBLER_NAME nor DECL_SECTION_NAME. If we do, that's a bug in whatever is using them -- but I don't know how hard it would be to fix. In GCC, things that look like fields, but are really variables, like C++ static data members or anonymous union members, should be represented as VAR_DECLs. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: tree ssa and type issues
> | > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); > | > It would be nice if gcc gave a warning for suspicious cases like this. I did a crude warning for this, and ironically it found a bug in valgrind: http://websvn.kde.org/trunk/valgrind/coregrind/vg_signals.c?rev=396554&r1=396296&r2=396554 A generally usable warning would need to weed out false positives by warning only when the types are suspiciously mismatched (as were these.) Tom Truscott
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On May 23, 2005, at 12:01 PM, Mark Mitchell wrote: We've researched this in detail. As have I, I also have the timings for template heavy code with the more egregious of the bugs fixed in the compiler-server branch, at that time, they were worth a 10x compile time improvement. If someone wants to pull them out from that branch, I think they are fairly isolated, let me know, and I can point the way.
Re: Some questions about FIELD_DECL
On Mon, 2005-05-23 at 12:26 -0700, Mark Mitchell wrote: > Daniel Berlin wrote: > > While moving FIELD_DECL to it's own substruct, the following questions > > have come up. I figured one of you might know: > > > > 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a > > place where we would actually try to *output* a FIELD_DECL directly, but > > maybe i've missed something. I ask because the C frontend tests > > decl_assembler_name on field decl, but never sets it on them. > > > > Related to this: > > > > 2. Do we allow setting the section of a FIELD_DECL, so that > > DECL_SECTION_NAME on FIELD_DECL is necessary? > > We should need neither DECL_ASSEMBLER_NAME nor DECL_SECTION_NAME. If we > do, that's a bug in whatever is using them -- but I don't know how hard > it would be to fix. Only one place was attempting to set them (the C++ FE, and the patch removed it), and one place was attempting to verify them (this was the gcc_assert you didn't like :P) > In GCC, things that look like fields, but are > really variables, like C++ static data members or anonymous union > members, should be represented as VAR_DECLs. >
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On Mon, 23 May 2005, Mike Stump wrote: On May 23, 2005, at 12:01 PM, Mark Mitchell wrote: We've researched this in detail. As have I, I also have the timings for template heavy code with the more egregious of the bugs fixed in the compiler-server branch, at that time, they were worth a 10x compile time improvement. If someone wants to pull them out from that branch, I think they are fairly isolated, let me know, and I can point the way. If it is possible, I'm at least interested in testing those bits on my classical "benchmark". Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Some questions about FIELD_DECL
Daniel Berlin wrote: On Mon, 2005-05-23 at 12:26 -0700, Mark Mitchell wrote: Daniel Berlin wrote: While moving FIELD_DECL to it's own substruct, the following questions have come up. I figured one of you might know: 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a place where we would actually try to *output* a FIELD_DECL directly, but maybe i've missed something. I ask because the C frontend tests decl_assembler_name on field decl, but never sets it on them. Related to this: 2. Do we allow setting the section of a FIELD_DECL, so that DECL_SECTION_NAME on FIELD_DECL is necessary? We should need neither DECL_ASSEMBLER_NAME nor DECL_SECTION_NAME. If we do, that's a bug in whatever is using them -- but I don't know how hard it would be to fix. Only one place was attempting to set them (the C++ FE, and the patch removed it), and one place was attempting to verify them (this was the gcc_assert you didn't like :P) Great; thanks. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [rfc] mainline slush
On Mon, 2005-05-23 at 19:35 +0200, Steven Bosscher wrote: > On Monday 23 May 2005 18:20, Jeffrey A Law wrote: > > I'd much rather take the time to fix all these problems, install the > > fixes along with the checking bits to ensure they never come back > > rather than to iterate on each one separately. > > And int the mean time, things stay broken? Probably for the best I agree. If things are broken I can wander my sources back a few days and continue to get some work done. -eric
Re: [wwwdocs] Simplify release process a bit
Gerald Pfeifer wrote: That said, like after the 4.0.0, I managed to find a way to simplify the list of steps you'll have to perform in the future. I just hope you don't get too used to these simplifications, they are getting harder to find. ;-) I appreciate your help -- in this case and otherwise! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Best Practices
Hi, I am teaching myself C by writing programs. I have some questions about proper practices.. 1) How do I know when to break my program into separate files. I am currently working on a Star Trek program. It has 4 or 5 large functions. They are all in one file. It's only about 900 lines right now. 2) Should I take something that is only used in one place in my program and make it a function on it's own? 3) What should I do if I have a set of functions I use in many of my programs.. for instance, a randomize() for srandom() and random() that reads /dev/random for it's seed. (so far I use it in two program and I have just cut and paste it between) another example would be a whole setup of #define statements that I use to work with ANSI console stuff. (I know I should probably use curses instead.. I am just learning curses) 4) Are global variables really bad? Why? In my star trek program I have two arrays that are used everywhere. They contain "reality". Passing them in to each function would be a problem.
Re: Best Practices
On May 23, 2005, at 3:58 PM, Ron Hudson wrote: I am teaching myself C by writing programs. I'm sorry, this is the wrong list for such questions.
Re: Compiling GCC with g++: a report
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: [...] | Attempt to get the GNU C++ compiler through the same massage is | underway (but I'm going to bed shortly ;-)). I can also report that I got the GNU C++ compiler through -- and apart form uses of C++ keywords (template, namespace, class), it worked out. A note on type sfety issue though: lookup_name() is declared in c-tree.h as extern tree lookup_name (tree); and used in c-common.c:handle_cleanup_attribute() according to that signature. It is however declared and defined in cp/ as extern tree lookup_name (tree, int); That was caught at link time (and dealt with). -- Gaby
Re: Compiling GCC with g++: a report
On Tue, 24 May 2005, Gabriel Dos Reis wrote: > I can also report that I got the GNU C++ compiler through -- and apart > form uses of C++ keywords (template, namespace, class), it worked > out. A note on type sfety issue though: lookup_name() is declared in > c-tree.h as > > extern tree lookup_name (tree); > > and used in c-common.c:handle_cleanup_attribute() according to that > signature. It is however declared and defined in cp/ as > > extern tree lookup_name (tree, int); We should try to stop c-common.c from including c-tree.h. If it is genuinely common code it shouldn't be including c-tree.h which is a C front end header. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Best Practices
Ron Hudson wrote: Hi, I am teaching myself C by writing programs. I have some questions about proper practices... Ask in news:comp.lang.c
Re: Compiling GCC with g++: a report
On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: > Hi, > > I spent the week-end trying to get GCC -- mainline -- compilable > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). These results are very interesting. As a general observation: A lot of the things you have found to be problematic, are in fact preferred idioms for C code. For instance, no standard-C programmer would ever write an explicit cast on malloc's return value. I think that we are losing something, if only in readability, if we restrict our code to the subset of C which is also correct C++. Now, if we were migrating to C++, that would be okay, because we would (eventually) get all of the additional expressive power of C++ in exchange. However, if we're not migrating to C++, I'm opposed to the inclusion of patches that restrict our C code to the subset which is correct C++. Furthermore, as I've said before, I support migrating to C++ -- but only if the C++ ABI and libstdc++ soname are first permanently frozen. If we do not do that first, we risk being trapped into a situation where we need specific versions of GCC to compile specific newer versions of GCC, which would be a Bad Thing. The C++ ABI seems to be stable at this point, but there is not yet consensus that it will never again be changed. The libstdc++ team is currently developing yet another new, incompatible version, so I see no hope for a permanent freeze of its soname in the near future. Thus, while you've discovered some interesting things by trying this, I don't think C++ compatibility patches should be applied now. Having said that, some comments on the problems you have found: > Third, there is some "type-punning" with enums, int and unsigned int, > where the middle-end (mostly) relies on implicit conversion from int > to enums. Being allowed to do this is very important. Some enumerated types are to be treated as opaque outside a very narrow context; the only way to do that in C is to have (a typedef of) unsigned int as the visible type, and only declare the enumerated type in the context where it's allowed to be used. I want to see more use of this idiom, not less; for example, 'enum machine_mode' ought to be a black box to almost the entire compiler. I'd be delighted to hear of a more C++-friendly way to code this. Naturally, where the constant is _not_ opaque outside of a defined context, but is part of an interface (as your examples seemed to be), not using it is just sloppy. > Fourth, it appears that we're implicilty using C99's semantics of > "extern inline" in our source -- when we have a pure C90 compiler that > does not understand "inline", we just #define inline to nothing so we > don't get into trouble. With a C++ compiler, we're in trouble because > an inline function needs to be defined in every translation where it > is used. So, I either move the affected functions to "static inline" > or just make then non-inline (cases are in hashtable.c and toplev.c). Use of bare 'inline' is just plain wrong in our source code; this has nothing to do with C++, no two C compilers implement bare 'inline' alike. Patches to add 'static' to such functions (AND MAKING NO OTHER CHANGES) are preapproved, post-slush. > Fifth, there is a slight difference between "const" in C and in C++. > In C++, a const variable implicitly has an internal linkage; so a > C++ compiler tends to optimize it out when its address is not taken > (so no storage is wasted). This is an issue for the objects > automatically generated by the gengtype support machinery. The are > supposed to have external linkage, so we need to explicitly say > "extern" in their definitions. Presumably such constants are declared in some header file, with external linkage. It would be better to make that declaration visible at the point of definition, rather than marking up the declarations with 'extern'. > Sixth, there is a real "mess" about name spaces. It is true that > every C programmers knows the rule saying tags inhabit different name > space than variable of functions. However, all the C coding standards > I've read so far usually suggest > >typedef struct foo foo; > > but *not* > >typedef struct foo *foo; > > i.e. "bringing" the tag-name into normal name space to name the type > structure or enumeration is OK, but not naming a different type! Ugh. Where do we do that? I will suggest, when you find these, that you tack "_s" on the end of the tag-name; that doesn't conflict with POSIX, and should require fewer changes elsewhere in the code. zw
Re: Compiling GCC with g++: a report
On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: > As a general observation: A lot of the things you have found to be > problematic, are in fact preferred idioms for C code. For instance, > no standard-C programmer would ever write an explicit cast on malloc's > return value. I think that we are losing something, if only in > readability, if we restrict our code to the subset of C which is also > correct C++. Now, if we were migrating to C++, that would be okay, > because we would (eventually) get all of the additional expressive power > of C++ in exchange. However, if we're not migrating to C++, I'm opposed > to the inclusion of patches that restrict our C code to the subset which > is correct C++. Furthermore, as I've said before, I support migrating > to C++ -- but only if the C++ ABI and libstdc++ soname are first > permanently frozen. If we do not do that first, we risk being trapped > into a situation where we need specific versions of GCC to compile > specific newer versions of GCC, which would be a Bad Thing. You keep saying this and I don't think it means what you think it means... Being stuck requiring a specific version of GCC to compile a specific newer version of GCC would be a restriction on _source compatibility_ and has nothing to do with binary compatibility. I don't see any way that the libstdc++ soname, for instance, could matter to this at all. If you do, then please be more precise about what problems you're talking about. > The C++ ABI seems to be stable at this point, but there is not yet > consensus that it will never again be changed. The libstdc++ team is > currently developing yet another new, incompatible version, so I see no > hope for a permanent freeze of its soname in the near future. Thus, > while you've discovered some interesting things by trying this, I don't > think C++ compatibility patches should be applied now. There is no such thing as an ABI that will never again be changed. Designing anything at all around that assumption is just asking to be hurt. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Compiling GCC with g++: a report
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote: Use of bare 'inline' is just plain wrong in our source code; this has nothing to do with C++, no two C compilers implement bare 'inline' alike. Patches to add 'static' to such functions (AND MAKING NO OTHER CHANGES) are preapproved, post-slush. That will not work for the cases where the bare 'inline' are used because they are external also in this case. Now this is where C99 and C++ differs at what a bare 'inline' means so I have no idea what to do, except for removing the 'inline' in first place. Thanks, Andrew Pinski
Re: Compiling GCC with g++: a report
Zack Weinberg <[EMAIL PROTECTED]> writes: | On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: | > Hi, | > | > I spent the week-end trying to get GCC -- mainline -- compilable | > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). | | These results are very interesting. | | As a general observation: A lot of the things you have found to be | problematic, are in fact preferred idioms for C code. For instance, | no standard-C programmer would ever write an explicit cast on malloc's | return value. I think that we are losing something, if only in | readability, if we restrict our code to the subset of C which is also | correct C++. I think opinions are variable here a lot. If for example, you take a look at examples in The C Programming Language (all editions), you'll find explicit casts on malloc's return value. Yet, I would refrain from calling Dennis Ritchie as a non standard-C programmer or his book, TCPL2, not describing standard C. Most of the C programmers I've met have learnt from his book. (Yes, I've also read some C programmers comment that nobody should cast the return value of malloc, but for large scale sofwtare, I have not seen their opinions as dorminating). The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC and such. It is not anything you'll find in the code directly. So, in fact we do not lose readability as you claim. | Now, if we were migrating to C++, that would be okay, | because we would (eventually) get all of the additional expressive power | of C++ in exchange. However, if we're not migrating to C++, I'm opposed | to the inclusion of patches that restrict our C code to the subset which | is correct C++. The patches are aligning us to our coding standards. I don't think it is reasonable to throw roadblocks in the way, especially when they are contrary to our current coding standards. The claim that the cast will obscure the code is unjustified as the use of the libiberty macros relieve us of springling cast in the code. See my previous patches to libiberty and fixincludes. I don't think your suggestion of moving to C++ is workable at this point. The patches of aligning us to the common subsets of C90 and C++ is following the consensus we developed as our coding standards. | Furthermore, as I've said before, I support migrating | to C++ -- but only if the C++ ABI and libstdc++ soname are first | permanently frozen. If we do not do that first, we risk being trapped | into a situation where we need specific versions of GCC to compile | specific newer versions of GCC, which would be a Bad Thing. Throwing roadblocks in the way is not going to help the GCC project. It is unreasonable to that at this time. | The C++ ABI seems to be stable at this point, but there is not yet | consensus that it will never again be changed. The libstdc++ team is | currently developing yet another new, incompatible version, so I see no | hope for a permanent freeze of its soname in the near future. Thus, | while you've discovered some interesting things by trying this, I don't | think C++ compatibility patches should be applied now. The issue of moving to C++ is independent of our aligning ourselves to our coding standards. I don't beleive it is reasonable to block these patches on the ground that we could conceive moving to C++ (which is a controversial issue). The decision to code at the intersection of C90 and C++ is a consensus we reached after repeated debates. | Having said that, some comments on the problems you have found: | | > Third, there is some "type-punning" with enums, int and unsigned int, | > where the middle-end (mostly) relies on implicit conversion from int | > to enums. | | Being allowed to do this is very important. Some enumerated types are | to be treated as opaque outside a very narrow context; the only way to | do that in C is to have (a typedef of) unsigned int as the visible type, | and only declare the enumerated type in the context where it's allowed | to be used. I have looked at every of those uses -- since I went through editing almost every file needed for compiling GNU C and GNU C++ compilers. None of the cases appear important. The only compelling cases are when front-ends (eg.g C or C++) extend them (e.g. c_tree_code or cplus_tree_code). However, none of the current approach is necessary. As, RTH pointed out in the past, front-ends should define those enumerators as a whole by appropriately #include the file. We can arrange for that -- in fact I've tested variants of that in my experiments. No cast is neeeded when done properly. | I want to see more use of this idiom, not less; for | example, 'enum machine_mode' ought to be a black box to almost the | entire compiler. Me too, but the way to make it a black box is not to cast it so unsigned int back forth willy nilly -- that does not make it a black box, on the contrary. For example, we should be using EXPAND_NORMAL instead of plai
Re: Compiling GCC with g++: a report
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: | > As a general observation: A lot of the things you have found to be | > problematic, are in fact preferred idioms for C code. For instance, | > no standard-C programmer would ever write an explicit cast on malloc's | > return value. I think that we are losing something, if only in | > readability, if we restrict our code to the subset of C which is also | > correct C++. Now, if we were migrating to C++, that would be okay, | > because we would (eventually) get all of the additional expressive power | > of C++ in exchange. However, if we're not migrating to C++, I'm opposed | > to the inclusion of patches that restrict our C code to the subset which | > is correct C++. Furthermore, as I've said before, I support migrating | > to C++ -- but only if the C++ ABI and libstdc++ soname are first | > permanently frozen. If we do not do that first, we risk being trapped | > into a situation where we need specific versions of GCC to compile | > specific newer versions of GCC, which would be a Bad Thing. | | You keep saying this and I don't think it means what you think it | means... Furthermore, I do not believe doing that (at least, as I understand it is any resonable. At any case, it is completely indpendent of the patches that align us to our coding standards. -- Gaby
Re: Compiling GCC with g++: a report
Andrew Pinski <[EMAIL PROTECTED]> writes: | On May 24, 2005, at 12:01 AM, Zack Weinberg wrote: | > Use of bare 'inline' is just plain wrong in our source code; this has | > nothing to do with C++, no two C compilers implement bare 'inline' | > alike. Patches to add 'static' to such functions (AND MAKING NO OTHER | > CHANGES) are preapproved, post-slush. | That will not work for the cases where the bare 'inline' are used | because they are external also in this case. Now this is where C99 and | C++ differs at what a bare 'inline' means so I have no idea what to | do, except for removing the 'inline' in first place. It suffices to make the function "static inline". See our current extensive usage. That works for both C and C++. -- Gaby
Re: Compiling GCC with g++: a report
Zack Weinberg wrote: On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: Hi, I spent the week-end trying to get GCC -- mainline -- compilable (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). These results are very interesting. As a general observation: A lot of the things you have found to be problematic, are in fact preferred idioms for C code. For instance, no standard-C programmer would ever write an explicit cast on malloc's return value. I don't know that I agree; I used to write such casts on other projects. I learned C and C++ at the same time, and did a fair amount of work with formal type systems, though, so I may not be representative. is correct C++. Furthermore, as I've said before, I support migrating to C++ -- but only if the C++ ABI and libstdc++ soname are first permanently frozen. If we do not do that first, we risk being trapped into a situation where we need specific versions of GCC to compile specific newer versions of GCC, which would be a Bad Thing. Line Daniel, I'm confused by this. I think we would need to be sure of source compatibility with a reasonably large set of compilers, so I'd say that it would be bad to depend on (say) a fix for a bug with templates that was fixed in the last release. But, it's doable to specify a super-conservative subset of C++ that works with anything that vaguely smells like a C++ compiler. I'd certainly say that the common subset of C and C++ is such a subset. Being allowed to do this is very important. Some enumerated types are to be treated as opaque outside a very narrow context; the only way to do that in C is to have (a typedef of) unsigned int as the visible type, and only declare the enumerated type in the context where it's allowed to be used. I agree with the goal of more hiding. You can do this in C by using an incomplete structure type in most places, and then, in the files where you want the definition visible, defining the structure to have a single field of the enumerated type. That is a little messy, but it is C++-compatible. (In fact, in ISO C++, without the additions presently in the WP, you can't do better; forward declarations of enums are still not allowed.) (The other thing you can do is to depend on the fact that enums and unsigned ints have the same representation, which you can force in C++ by declaring extra enumeration constants of values like UINT_MAX, and then use explicit casts at places where you want to go back and forth. I think this is not as nice as the incomplete structure approach.) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Compiling GCC with g++: a report
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: >> Furthermore, as I've said before, I support migrating >> to C++ -- but only if the C++ ABI and libstdc++ soname are first >> permanently frozen. If we do not do that first, we risk being trapped >> into a situation where we need specific versions of GCC to compile >> specific newer versions of GCC, which would be a Bad Thing. > > You keep saying this and I don't think it means what you think it > means... > > Being stuck requiring a specific version of GCC to compile a specific > newer version of GCC would be a restriction on _source compatibility_ > and has nothing to do with binary compatibility. I don't see any way > that the libstdc++ soname, for instance, could matter to this at all. > > If you do, then please be more precise about what problems you're > talking about. Um, yeah. I completely botched that explanation. My apologies. I'm concerned about four different scenarios which may arise when the preexisting C++ compiler and runtime are ABI-incompatible with the C++ compiler and runtime being built; none are source compatibility issues, as you point out, however two of them have just the same effect from the user's point of view: imposing constraints on what compiler can be used to build the compiler. Scenario one: Suppose that both libcpp and gcc start using , and that the initial compiler/runtime's implementation of is binary incompatible with the implementation being built. Libcpp is currently built only with the initial compiler. Bootstrap will fail in stage 2, when we try to link libcpp modules expecting the older against a library implementing the newer (or perhaps the link will succeed but the resulting executable won't work). This scenario, at least theoretically, becomes a non-issue if we make top-level bootstrap the only option before we start using C++ features in GCC, but that hasn't happened yet. Scenario two: Suppose that we have not found every last place where LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to ensure that the dynamic linker binds the stage 2 compiler to the shared libstdc++ that it's expecting. If there isn't a libstdc++.so in /usr/lib, or if there is but it is not compatible with the one the compiler wants, again bootstrap will fail. Any time this scenario comes up, it is attributable to a bug in the Makefiles, but you know just how hard it can be to fix such bugs. We've had similar problems with the shared libgcc. Scenario three: Suppose that libstdc++.so.7 (gcc-4.2) and libstdc++.so.7 (gcc-4.3) are compatible in the same way that libc.so.6 (glibc-2.0) and libc.so.6 (glibc-2.1) are compatible: that is, if you build a binary against the first, it'll run against the second, but not vice versa. Now, suppose that on some system gcc-4.2 is /usr/bin/gcc, its libstdc++.so.7 is installed in /usr/lib, and we're trying to use it to compile gcc-4.3, to be installed in /opt/gcc-4.3 or some other weird place that is not in the dynamic linker's default search path. Furthermore, scenarios one and two have been properly avoided. The bootstrap process will produce final compiler binaries that have been linked against the 4.3 libstdc++.so. If we include RPATHs in those binaries, bootstrap will fail, because the library isn't installed yet; if we don't, bootstrap and testing will succeed, but the installed compiler will not run unless the user knows to set LD_LIBRARY_PATH, which has its own problems. DT_RUNPATH could theoretically be used to make this work, but we can't count on DT_RUNPATH. If I were evil, I might point out that this is exactly the same problem that various people were complaining about last week, of depending on newer libraries than one expected to. Scenario four: Suppose that we manage to avoid all the above scenarios. Suppose further that we think we have achieved binary compatibility between different versions of libstdc++, but we are wrong. Then 'make install' is likely to overwrite the libstdc++.so on the system with one that is, in fact, not compatible, and break already-installed software. This could, of course, happen even if we don't start using C++ in GCC itself - I bring it up to caution us against rushing into declaring libstdc++ ABI-frozen. I'd want to see at least two major releases with no libstdc++ soname bump and no problems reported, before I had confidence we'd gotten it right. I want to emphasize that I don't think any of these are unsolvable problems. I do think they are all real problems, and I think there are going to be other problems I haven't listed above, and I want to be sure we have considered the problems and have solutions in hand before we take the plunge. > There is no such thing as an ABI that will never again be changed. > Designing anything at all around that assumption is just asking to > be hurt. C++ ABI stability (including libstdc++ interface) on a par with the C
Re: Compiling GCC with g++: a report
Zack Weinberg wrote: Um, yeah. I completely botched that explanation. My apologies. I'm concerned about four different scenarios which may arise when the preexisting C++ compiler and runtime are ABI-incompatible with the C++ compiler and runtime being built; none are source compatibility issues, as you point out, however two of them have just the same effect from the user's point of view: imposing constraints on what compiler can be used to build the compiler. I agree that these are valid concerns. Certainly, I can imagine us (CodeSourcery) considering shipping statically linked binaries for quite some time in order to avoid problems for customers, even though that would be less efficient. Like you, I do think these problems are surmountable; but, also like you, I think it would take some time to get all the problems solved. I don't really think, though, that this is immediately relevant; Gaby's trying to fix things that seem to me like they will actually make for better C code, and, right now at least, going to C++ isn't on the table. I think you agree that most of the changes Gaby wants to make are for the better (with the possible exception of casting the return value of malloc, which will be hidden in a macro that's probably less error-prone that writing out the malloc calls directly) -- but you're concerned about the fact that doing this work now might make it too easy for us to switch to C++ without thinking about all the issues? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Compiling GCC with g++: a report
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: [...] > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC > and such. It is not anything you'll find in the code directly. So, > in fact we do not lose readability as you claim. To be honest, I think XNEW* are less readable than bare xmalloc, and I regret that I ever invented them. > The patches of aligning us to the common subsets of C90 and C++ is > following the consensus we developed as our coding standards. I don't see that there is any such consensus. I certainly consider coding to the intersection of C90 and C++ acceptable only as a stepping stone to coding in C++. If we aren't going to do that, and in short order, we have sacrificed the additional expressiveness of C-that-is-not-C++ for no gain. I was unclear in my previous message: it seems that you have found a number of things, by your experiment, that are not just code outside the intersection, but outright bugs. The bugs should of course be fixed. Things that I consider outright bugs include: functions being called with prototypes in scope that don't match their definitions; use of numeric constants in interfaces when enumeration constants are defined for those interfaces; 'typedef struct foo *foo'. Things I consider correct coding, but outside the intersection of C90 and C++, include: not casting the return value of allocator functions; not casting to void* when passing an arbitrary pointer to a function that takes a void* parameter; unrestricted use of C++ keywords; declaring structure fields with the same name as a structure tag in scope. > | I want to see more use of this idiom, not less; for > | example, 'enum machine_mode' ought to be a black box to almost the > | entire compiler. > > Me too, but the way to make it a black box is not to cast it so > unsigned int back forth willy nilly -- that does not make it a black > box, on the contrary. For example, we should be using EXPAND_NORMAL > instead of plain "0". > > | I'd be delighted to hear of a more C++-friendly way to > | code this. > > See above. This isn't an answer to the question I asked. I asked for a more C++ friendly way to code *black box* use of enums, where (in C) one is deliberately relying on the unchecked conversion to and from integral types. > I'm talking of the various gt_* objects created by the gengtype. > Please, do have a look at the actual contents of the file and > re-read what I wrote. I haven't time; please post a reduced example and explain why my suggestion won't work. zw
Re: Compiling GCC with g++: a report
Mark Mitchell <[EMAIL PROTECTED]> writes: [snip stuff addressed elsewhere] > I agree with the goal of more hiding. > > You can do this in C by using an incomplete structure type in most > places, and then, in the files where you want the definition visible, > defining the structure to have a single field of the enumerated > type. That is a little messy, but it is C++-compatible. (In fact, in > ISO C++, without the additions presently in the WP, you can't do > better; forward declarations of enums are still not allowed.) Doesn't work, at least not as a drop-in replacement; you can't pass an incomplete structure by value. We do do this in places where there's a real structure that can be passed around by pointer... zw
Re: Compiling GCC with g++: a report
Zack Weinberg wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: [snip stuff addressed elsewhere] I agree with the goal of more hiding. You can do this in C by using an incomplete structure type in most places, and then, in the files where you want the definition visible, defining the structure to have a single field of the enumerated type. That is a little messy, but it is C++-compatible. (In fact, in ISO C++, without the additions presently in the WP, you can't do better; forward declarations of enums are still not allowed.) Doesn't work, at least not as a drop-in replacement; you can't pass an incomplete structure by value. We do do this in places where there's a real structure that can be passed around by pointer... Good point; yes, you would have to pass a pointer. I guess you could create a singleton representative of each value in the enum, and pass them around, but I agree that's getting pretty ugly. Of course, the problem with "unsigned int" is that it is a complete type, and people can accidentally pass in "7", even if there's no such enumeral. You really want forward-declared enums, but you haven't got them; it may be you just lose. :-( -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Compiling GCC with g++: a report
Zack Weinberg wrote: Gabriel Dos Reis <[EMAIL PROTECTED]> writes: [...] The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC and such. It is not anything you'll find in the code directly. So, in fact we do not lose readability as you claim. To be honest, I think XNEW* are less readable than bare xmalloc, and I regret that I ever invented them. Too late. :-) We have adopted them, and people have started using them. Unlike you, I still think they're a good thing. More importantly, I think it would be a mistake to reopen this issue; I don't think the difference is terribly important, but not having the debate seems like a win. :-) Things I consider correct coding, but outside the intersection of C90 and C++, include: not casting the return value of allocator functions; See above. not casting to void* when passing an arbitrary pointer to a function that takes a void* parameter That's not necessary in C++ either; the C++ difference is that you must cast "void *" to "int *" to call a function accepting an "int *"; not the opposite. Maybe that's what you meant? unrestricted use of C++ keywords; > declaring structure fields with the same name as a structure tag in scope. I don't think we should be reverting patches that fall afoul of these last two, even if they break Gaby's build-with-a-C++-compiler builds. But, I would tend to accept patches from Gaby to fix such problems. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Compiling GCC with g++: a report
Mark Mitchell <[EMAIL PROTECTED]> writes: ... > Like you, I do think these problems are surmountable; but, also like > you, I think it would take some time to get all the problems solved. > I don't really think, though, that this is immediately relevant; > Gaby's trying to fix things that seem to me like they will actually > make for better C code, and, right now at least, going to C++ isn't on > the table. I think you agree that most of the changes Gaby wants to > make are for the better (with the possible exception of casting the > return value of malloc, which will be hidden in a macro that's > probably less error-prone that writing out the malloc calls directly) > -- but you're concerned about the fact that doing this work now might > make it too easy for us to switch to C++ without thinking about all > the issues? Yes, that's what I'm trying to get at. Secondarily, I don't want to lose some of the expressive power of C-that-is-not-C++ if we're not getting the expressive power of C++ in exchange -- for instance, I really don't want to have to avoid the set of C++ keywords when coding in C, or remember the semantic difference between C and C++ struct tags. I'd change my tune if Gaby could demonstrate a place where the C++ compiler caught a user-visible bug that the C compiler missed. That would be worth the extra discipline. All the bugs described so far, however, have been things that, while formally incorrect, haven't affected the visible behavior of the compiler. (And I'd be less grumpy about coding to the intersection of C and C++ if someone coded up warnings for the C compiler to catch things outside the intersection.) zw
Re: Compiling GCC with g++: a report
Zack Weinberg wrote: (And I'd be less grumpy about coding to the intersection of C and C++ if someone coded up warnings for the C compiler to catch things outside the intersection.) My feeling on this is that it's not fair to expect people to know C++, until and unless we switch to actually using C++. I'd say just code how you always have, within our existing coding standards, and ignore the issue; let people who care fix it up after the fact, or comment on your patches when you post them. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Slush
I'm out of the office tomorrow, and I don't want to leave things up in the air. I've looked at test results for a few 4.01 platforms on the testresults lists: powerpc64-unknown-linux-gnu : vec failures x86_64-suse-linux-gnu: ieee failures, vect failures s390-linux-gnu: OK mips-sgi-irix6.5: OK i686-pc-linux-gnu: OK I know that's not perfect, but I think we can move forward. We certainly seem to be bootstrapping on most platforms. At the same time, I don't want to destabilize things if Jeff et. al. are trying to get cleanups done. So, let's lift the slush, effective noon Pacific time tomorrow, i.e., 12 hours from now. However, if three or more global write privileges people object, then we'll leave it in place at least until I'm back online and can review the situation. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Compiling GCC with g++: a report
Zack Weinberg <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | [...] | > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC | > and such. It is not anything you'll find in the code directly. So, | > in fact we do not lose readability as you claim. | | To be honest, I think XNEW* are less readable than bare xmalloc, and I | regret that I ever invented them. Then, we would have just agree to disagree. At least, with the explicit call to malloc + explicit specification of sizeof, I've found a number of wrong codes -- while replacing the existing xmalloc/xcallo with XNEWVEC and friends (see previous patches and messages) in libiberty, not counting the happy confusion about xcalloc() in the current GCC codes. Those are bugs we do not have with the XNEWVEC and friends. Not only, we do get readable code, we also get right codes. | > The patches of aligning us to the common subsets of C90 and C++ is | > following the consensus we developed as our coding standards. | | I don't see that there is any such consensus. I certainly consider http://www.gnu.org/software/gcc/codingconventions.html Avoid the use of identifiers or idioms that would prevent code compiling with a C++ compiler. Identifiers such as new or class, that are reserved words in C++, should not be used as variables or field names. Explicit casts should be used to convert between void* and other pointer types. Previous discussions reached this: http://gcc.gnu.org/ml/gcc/2004-07/msg00601.html | coding to the intersection of C90 and C++ acceptable only as a | stepping stone to coding in C++. If converting GCC to C++ is your ultimate goal, then I don't think you should block these patches. They do not introduce C++, but also they do provide a path to local experiments before we ever have any huge fight about that. I do not think converting GCC to C++ is on the table or will happen any time soon -- see previous long discussions. However, I do not believe it would help the GCC project to block any patch that bring us in alignment to our own committment. We can have our cake and it. I.e. we can have the source code in a form compilable with a C++ compiler and test conjectures/experiments. | If we aren't going to do that, and | in short order, we have sacrificed the additional expressiveness of | C-that-is-not-C++ for no gain. I don't think so. These patches make it possible to compile the source code with a C++ compiler. We gain better checking by doing that. In particular, it makes it possible for people to test any conjecture about the benefits of moving to C++, without actually requiring it at the moment. Those benefits largely offset the inconvenient of using XNEWVEC (with all its benefits). I was able to find those problems because I could get the source code through a C++ compiler. Making that possible to everyone, including those who do no like to use C++ in GCC is a win for everybody. | I was unclear in my previous message: it seems that you have found a | number of things, by your experiment, that are not just code outside | the intersection, but outright bugs. Exactly. I was able to find those because I spent the time to convert the souorce to be compilable to C++. I do not believe it makes to require everybody to wste such time locally, whereas it could be done one for all. | The bugs should of course be | fixed. Things that I consider outright bugs include: functions being | called with prototypes in scope that don't match their definitions; | use of numeric constants in interfaces when enumeration constants are | defined for those interfaces; 'typedef struct foo *foo'. | | Things I consider correct coding, but outside the intersection of C90 | and C++, include: not casting the return value of allocator functions; | not casting to void* when passing an arbitrary pointer to a function | that takes a void* parameter; unrestricted use of C++ keywords; | declaring structure fields with the same name as a structure tag in | scope. These do not being us any benefits as far as checking is concerned. The point of being able to do so and therefore prevent ourselves from having freely avaliable tools to catch errors completely escape my understanding. | > | I want to see more use of this idiom, not less; for | > | example, 'enum machine_mode' ought to be a black box to almost the | > | entire compiler. | > | > Me too, but the way to make it a black box is not to cast it so | > unsigned int back forth willy nilly -- that does not make it a black | > box, on the contrary. For example, we should be using EXPAND_NORMAL | > instead of plain "0". | > | > | I'd be delighted to hear of a more C++-friendly way to | > | code this. | > | > See above. | | This isn't an answer to the question I asked. I asked for a more C++ | friendly way to code *black box* use of enums, where (in C) one is | deliberately relying on the unchecked conversion to and f
