gcc 4.2 breaks debugging anonymous namespace
[Since this gcc problem affects gdb, I'm sending this to both lists]
[Warning, long mail. But the actual description isn't that long, just the
testcases are.]
Hi,
a specific test in the GDB testsuite (namespace.exp) contains tests
on variables within anonymous namespaces. When compiling the testcases
under g++ 4.2, all these tests fail. The same tests pass successfully
when built with gcc 4.1. I reproduced it on a native i686-pc-linux-gnu
and on a cross i686-pc-linux-gnu-x-mips64-elf. The below testcases are
generated using the native toolchain.
The reason for the GDB FAILs is two-fold.
First of all, the following code fails to generate any useful code for
the symbol `b' in the anonymous namespace when building under 4.2:
cat > x1.cc << EOF
namespace A {
int a = 1;
}
namespace {
int b = 2;
}
EOF
$ g++ -S x1.cc -o-
.file "x1.cc"
.globl _ZN1A1aE
.data
.align 4
.type _ZN1A1aE, @object
.size _ZN1A1aE, 4
_ZN1A1aE:
.long 1
.ident "GCC: (GNU) 4.2.1 20070516 (prerelease) (GNUPro 07r1) (Based
on: GCC 4.2, BINUTILS 2.17, GDB 6.6)"
.section.note.GNU-stack,"",@progbits
The symbol b just doesn't show up. One could think that it has been
intentionally optimized away, which would make sort of sense, given that
symbols in the anonymous namespace are compilation unit local and the
symbol b is never referenced. However, there's something weird here.
Consider the next example which consists only of the anonymous namespace:
cat > x2.cc << EOF
namespace {
int b = 2;
}
EOF
$ g++ -S x2.cc -o-
.file "x2.cc"
.data
.align 4
.type _ZN34_GLOBAL__N_x2.cc__8E6B23431bE, @object
.size _ZN34_GLOBAL__N_x2.cc__8E6B23431bE, 4
_ZN34_GLOBAL__N_x2.cc__8E6B23431bE:
.long 2
.ident "GCC: (GNU) 4.2.1 20070516 (prerelease) (GNUPro 07r1) (Based
on: GCC 4.2, BINUTILS 2.17, GDB 6.6)"
.section.note.GNU-stack,"",@progbits
Suddenly the symbol b shows up. b and the anonymous namespace are still
compilation unit local, so why the difference?
The next testcase is the shortest possible approximation for the GDB
testcase namespace.exp. The symbol b is referenced the same way as the
symbols in the actual GDB testcase:
cat > x3.cc << EOF
namespace A {
int a = 1;
}
namespace {
int b = 2;
int foo ()
{
b;
}
}
EOF
$ g++ -S x3.cc -o-
.file "x3.cc"
.text
.align 2
.type _ZN19_GLOBAL__N__ZN1A1aE3fooEv, @function
_ZN19_GLOBAL__N__ZN1A1aE3fooEv:
.LFB2:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
popl%ebp
ret
.LFE2:
.size _ZN19_GLOBAL__N__ZN1A1aE3fooEv,
.-_ZN19_GLOBAL__N__ZN1A1aE3fooEv
.globl __gxx_personality_v0
.globl _ZN1A1aE
.data
.align 4
.type _ZN1A1aE, @object
.size _ZN1A1aE, 4
_ZN1A1aE:
.long 1
.ident "GCC: (GNU) 4.2.1 20070516 (prerelease) (GNUPro 07r1) (Based
on: GCC 4.2, BINUTILS 2.17, GDB 6.6)"
.section.note.GNU-stack,"",@progbits
Ok, so there has been code generated for the function foo and the
function foo has a mangled name. There hasn't been code generated for
b, though, even though the symbol is referenced. Shouldn't that only
happen when some -O option has been given?
Now, let's generate an object file with additional debug information:
$ g++ -g -c x3.cc -o x3.o
$ nm x3.o
t _ZN19_GLOBAL__N__ZN1A1aE3fooEv
G _ZN1A1aE
U __gxx_personality_v0
The symbol table has a mangled name for the function foo, the symbol b
doesn't show up. This was to be expected from the above generated
assembler code. What about foo and b in the debug information?
$ readelf -wi x3.o
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length:248
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer: GNU C++ 4.2.1 20070516 (prerelease) (GNUPro 07r1)
(Based on: GCC 4.2, BINUTILS 2.17, GDB 6.6)
DW_AT_language: 4 (C++)
DW_AT_name: x3.cc
DW_AT_comp_dir: /home/corinna/tests
DW_AT_low_pc : 0
DW_AT_high_pc : 0x5
DW_AT_stmt_list : 0
<1><91>: Abbrev Number: 2 (DW_TAG_namespace)
DW_AT_sibling :
<2><96>: Abbrev Number: 3 (DW_TAG_subprogram)
DW_AT_name: foo
DW_AT_decl_file : 1
DW_AT_decl_line : 6
DW_AT_type:
DW_AT_declaration : 1
<2>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_name: b
DW_AT_decl_file : 1
DW_AT_decl_line : 5
DW_AT_type:
DW_AT_declaration : 1
<1>: Abbrev Number: 5 (DW_TAG_imported_module)
PR for multilib build problems?
Is there a PR existing for multilib build failures of the form... configure: error: `CXX' has changed since the previous run ...as described (and patch proposed) in... http://sourceware.org/ml/newlib/2007/msg00425.html? I am currently testing that patch with gcc trunk to see if it eliminates these build failures on powerpc Darwin. Jack
RE: PR for multilib build problems?
On 25 May 2007 13:03, Jack Howarth wrote: >Is there a PR existing for multilib build failures > of the form... > > configure: error: `CXX' has changed since the previous run http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type= allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_typ e=allwordssubstr&long_desc_type=substring&long_desc=has+changed+since+the+prev ious+run&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordss ubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwords substr&gccbuild=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtyp e1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype 2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=No w&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&v alue0-0-0= gives us PR32078, which looks a lot like what you're describing. cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc 4.2 breaks debugging anonymous namespace
On Fri, May 25, 2007 at 02:00:35PM +0200, Corinna Vinschen wrote: > IMHO, this is a bug in g++. The mangled name in DW_AT_MIPS_linkage_name > is required so that GDB can correctly recognize mangled c++ symbols. Yes, I think so. Keep in mind that, in turn, the dependency on DW_AT_MIPS_linkage_name is actually a bug in GDB; I worked on this for a while, but the patches had some rough spots and I never finished them. I hope I can come back to it some day soon. -- Daniel Jacobowitz CodeSourcery
Re: Dynamically linking against GMP and MPFR
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote: > We need a configure time option to link statically against GMP and > MPFR even if dynamic versions of the libraries are available. > > I would argue that static linking should be the default, since that is > the least surprising option. People who understand the issues can > enable dynamic linking. But I'm willing to be overruled on this > point. It's no different than any other library used by any other program. I wouldn't object to configure support to request static gmp/mpfr for developer convenience, but GCC is a perfectly normal dynamically linked program and should behave like one IMO. -- Daniel Jacobowitz CodeSourcery
Re: ***[Possible UCE]*** Dynamically linking against GMP and MPFR
[EMAIL PROTECTED] wrote: If you carefully install the appropriate versions of GMP and MPFR on one machine in the normal way, and build gcc on that machine, cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and libmpfr.so. If you then copy the compiler to some other system, or simply run it from another system via NFS, and you have not carefully installed the appropriate versions of GMP and MPFR on that other system, the compiler will fail to start, getting an error from the dynamic linker. I simply dump the required .so into the lib64 directory of my new gcc installation, and tar up the whole thing. I can untar into my own directory on systems where I have no root access. No doubt others do the same.
Re: Dynamically linking against GMP and MPFR
On 5/25/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote: > We need a configure time option to link statically against GMP and > MPFR even if dynamic versions of the libraries are available. > > I would argue that static linking should be the default, since that is > the least surprising option. People who understand the issues can > enable dynamic linking. But I'm willing to be overruled on this > point. It's no different than any other library used by any other program. I wouldn't object to configure support to request static gmp/mpfr for developer convenience, but GCC is a perfectly normal dynamically linked program and should behave like one IMO. I agree. I wouldn't expect to have to update gcc just because mpfr had a bugfix. Richard.
RE: Dynamically linking against GMP and MPFR
On 25 May 2007 15:10, Ian Lance Taylor wrote: > I would argue that static linking should be the default, since that is > the least surprising option. People who understand the issues can > enable dynamic linking. And besides, wasn't it the case that one of the main points in defence of adding YA dependency in the first place was "This will only affect developers, not end-users"? That's only true if they are statically linked in. I think your suggestion should not be overruled! cheers, DaveK -- Can't think of a witty .sigline today
Dynamically linking against GMP and MPFR
I just noticed a problem with our use of GMP and MPFR. If you carefully install the appropriate versions of GMP and MPFR on one machine in the normal way, and build gcc on that machine, cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and libmpfr.so. If you then copy the compiler to some other system, or simply run it from another system via NFS, and you have not carefully installed the appropriate versions of GMP and MPFR on that other system, the compiler will fail to start, getting an error from the dynamic linker. We need a configure time option to link statically against GMP and MPFR even if dynamic versions of the libraries are available. I would argue that static linking should be the default, since that is the least surprising option. People who understand the issues can enable dynamic linking. But I'm willing to be overruled on this point. Ian
Re: Dynamically linking against GMP and MPFR
> It's no different than any other library used by any other program. > I wouldn't object to configure support to request static gmp/mpfr for > developer convenience, but GCC is a perfectly normal dynamically > linked program and should behave like one IMO. How a compiler can be "a perfectly normal dynamically linked program", especially if it's the system compiler? IMHO the less dependencies the better in this case. -- Eric Botcazou
Re: Dynamically linking against GMP and MPFR
On Fri, May 25, 2007 at 04:33:56PM +0200, Eric Botcazou wrote: > > It's no different than any other library used by any other program. > > I wouldn't object to configure support to request static gmp/mpfr for > > developer convenience, but GCC is a perfectly normal dynamically > > linked program and should behave like one IMO. > > How a compiler can be "a perfectly normal dynamically linked program", > especially if it's the system compiler? IMHO the less dependencies the > better in this case. I honestly don't know how to answer this question. Bootstrapping is an unrelated problem, and the compiler is not a vital runtime component of the system, so its dependencies do not need to be exceptionally robust in the way that glibc's or even libstdc++'s do. If you were talking about linking libstdc++ to MPFR I'd have a different story to tell. -- Daniel Jacobowitz CodeSourcery
RE: Dynamically linking against GMP and MPFR
On 25 May 2007 15:34, Eric Botcazou wrote: >> It's no different than any other library used by any other program. >> I wouldn't object to configure support to request static gmp/mpfr for >> developer convenience, but GCC is a perfectly normal dynamically >> linked program and should behave like one IMO. > > How a compiler can be "a perfectly normal dynamically linked program", > especially if it's the system compiler? IMHO the less dependencies the > better in this case. Yes, hasn't this been one of the design goals of gcc for as long as any of us can remember? It wants to be able to bootstrap the GNU world on non-free systems from scratch and part of that is not requiring anything other than the standard headers and libraries distributed with the system - isn't that an important qualification in terms of the GPL? cheers, DaveK -- Can't think of a witty .sigline today
Re: ***[Possible UCE]*** Dynamically linking against GMP and MPFR
Tim Prince <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > If you > > carefully install the appropriate versions of GMP and MPFR on one > > machine in the normal way, and build gcc on that machine, > > cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and > > libmpfr.so. If you then copy the compiler to some other system, or > > simply run it from another system via NFS, and you have not carefully > > installed the appropriate versions of GMP and MPFR on that other > > system, the compiler will fail to start, getting an error from the > > dynamic linker. > > I simply dump the required .so into the lib64 directory of my new gcc > installation, and tar up the whole thing. I can untar into my own > directory on systems where I have no root access. No doubt others do > the same. I know that there are many ways to handle this but the point is that it should work easily and conveniently without extra work. Ian
Re: Dynamically linking against GMP and MPFR
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote: > I just noticed a problem with our use of GMP and MPFR. If you > carefully install the appropriate versions of GMP and MPFR on one > machine in the normal way, and build gcc on that machine, > cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and > libmpfr.so. If you then copy the compiler to some other system, or > simply run it from another system via NFS, and you have not carefully > installed the appropriate versions of GMP and MPFR on that other > system, the compiler will fail to start, getting an error from the > dynamic linker. > > We need a configure time option to link statically against GMP and > MPFR even if dynamic versions of the libraries are available. > I have been doing it ever since gmp was introduced. Otherwise, my gcc binaries aren't very useful as you have discovered. H.J.
Re: Dynamically linking against GMP and MPFR
Dave Korn wrote: On 25 May 2007 15:34, Eric Botcazou wrote: It's no different than any other library used by any other program. I wouldn't object to configure support to request static gmp/mpfr for developer convenience, but GCC is a perfectly normal dynamically linked program and should behave like one IMO. How a compiler can be "a perfectly normal dynamically linked program", especially if it's the system compiler? IMHO the less dependencies the better in this case. Yes, hasn't this been one of the design goals of gcc for as long as any of us can remember? It wants to be able to bootstrap the GNU world on non-free systems from scratch and part of that is not requiring anything other than the standard headers and libraries distributed with the system - isn't that an important qualification in terms of the GPL? That seems like a different issue, though. Bootstrapping GCC on a system is something that would be solved by placing GMP and MPFR in the build tree (as has been proposed), and once they are built as part of the usual bootstrap, it is irrelevant whether they are linked statically or dynamically. On the other hand, when one is distributing pre-built binaries of GCC (as in the present discussion) it irrelevant whether GMP and MPFR are built separately or as part of the bootstrap, but the question of whether they are dynamically or statically linked is a significant question. - Brooks
Re: [dataflow] partial register handling
But I don't think that's enough, with the current loop it would strip the
subreg of a multiword subreg and there is some logic in df_ref_record,
which wouldn't see it. An alternative might be:
while (GET_CODE (dst) == STRICT_LOW_PART
|| GET_CODE (dst) == ZERO_EXTRACT)
{
flags |= DF_REF_READ_WRITE | DF_REF_PARTIAL;
loc = &XEXP (dst, 0);
dst = *loc;
}
if (df_read_modify_subreg_p (dst))
flags |= DF_REF_READ_WRITE | DF_REF_PARTIAL;
That would only leave singleword subreg and paradoxical subreg, if they
should require anything.
This seems also correct, if you want to test it.
One could also restrict STRICT_LOW_PART to subregs, as after reload the
subreg part is usually gone.
No, a strict_low_part of a reg is also a partial set.
Paolo
Re: ***[Possible UCE]*** Dynamically linking against GMP and MPFR
On 25 May 2007 07:52:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Tim Prince <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > If you > > carefully install the appropriate versions of GMP and MPFR on one > > machine in the normal way, and build gcc on that machine, > > cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and > > libmpfr.so. If you then copy the compiler to some other system, or > > simply run it from another system via NFS, and you have not carefully > > installed the appropriate versions of GMP and MPFR on that other > > system, the compiler will fail to start, getting an error from the > > dynamic linker. > > I simply dump the required .so into the lib64 directory of my new gcc > installation, and tar up the whole thing. I can untar into my own > directory on systems where I have no root access. No doubt others do > the same. Don't seem to have the full thread here, but this is a problem that we very recently faced while distributing pre-built compilers to a customer for quick testing. We instead integrated the correct versions of gmp and mpfr into our combined tree. Because this is an embedded port we build with --disable-shared and that allows gmp and mpfr to automatically get statically linked into the compiler. I know that there are many ways to handle this but the point is that it should work easily and conveniently without extra work. Ian -- Ramana Radhakrishnan
Re: Dynamically linking against GMP and MPFR
On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote: > > I honestly don't know how to answer this question. Bootstrapping is an > > unrelated problem, and the compiler is not a vital runtime component > > of the system, so its dependencies do not need to be exceptionally > > robust in the way that glibc's or even libstdc++'s do. > > A compiler is a "second order" thing though: its ill behaviour sends ripples > through all the stuff it compiles. Suppose that an MPFR upgrade introduces a > bug in the library and that the compiler is affected; every single program > compiled from now on will be potentially affected by the MPFR bug, even if it > has nothing to do with MPFR. That just means that it's an application you care about. And now an upgrade of MPFR which fixes bugs will require you to rebuild the compiler. We could go around this in circles forever; I think that the tradeoffs are exactly the same as for any other application on your system, both pro and con. I'm not going to complain if someone makes a configure switch to prefer static versions. We (CodeSourcery) are almost certainly going to ship compilers statically linked to MPFR / GMP; we already have machinery to build them that way. On the other hand I am positive Debian will not ship its system compiler that way; Debian policy is quite clear on this, dynamic libraries should always be used. -- Daniel Jacobowitz CodeSourcery
Re: Dynamically linking against GMP and MPFR
> I honestly don't know how to answer this question. Bootstrapping is an > unrelated problem, and the compiler is not a vital runtime component > of the system, so its dependencies do not need to be exceptionally > robust in the way that glibc's or even libstdc++'s do. A compiler is a "second order" thing though: its ill behaviour sends ripples through all the stuff it compiles. Suppose that an MPFR upgrade introduces a bug in the library and that the compiler is affected; every single program compiled from now on will be potentially affected by the MPFR bug, even if it has nothing to do with MPFR. I think that the compiler, especially the system compiler, should not depend on dynamic libraries that are lower than it in the system hierarchy, which pretty much leaves only the libc. -- Eric Botcazou
Re: Dynamically linking against GMP and MPFR
> Bootstrapping GCC on a system is something that would be solved by > placing GMP and MPFR in the build tree (as has been proposed), and once > they are built as part of the usual bootstrap, it is irrelevant whether > they are linked statically or dynamically. On the other hand, when one > is distributing pre-built binaries of GCC (as in the present discussion) > it irrelevant whether GMP and MPFR are built separately or as part of > the bootstrap, but the question of whether they are dynamically or > statically linked is a significant question. I don't think gcc is any different to other application in this respect. If you're building binaries for distribution you'd better be building them in an environment that matches that of your intended user. ie. if your host->build sysroot should match the system you're building for, or if building natively your native system should match the one you're going to run the final binaries on. Paul
Re: Dynamically linking against GMP and MPFR
On Fri, 25 May 2007, Daniel Jacobowitz wrote: > On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote: > > > I honestly don't know how to answer this question. Bootstrapping is an > > > unrelated problem, and the compiler is not a vital runtime component > > > of the system, so its dependencies do not need to be exceptionally > > > robust in the way that glibc's or even libstdc++'s do. > > > > A compiler is a "second order" thing though: its ill behaviour sends ripples > > through all the stuff it compiles. Suppose that an MPFR upgrade introduces > > a > > bug in the library and that the compiler is affected; every single program > > compiled from now on will be potentially affected by the MPFR bug, even if > > it > > has nothing to do with MPFR. > > That just means that it's an application you care about. And now an > upgrade of MPFR which fixes bugs will require you to rebuild the > compiler. > > We could go around this in circles forever; I think that the tradeoffs > are exactly the same as for any other application on your system, both > pro and con. I agree. There are pros & cons and reasonable people can arrive at different conclusions about whether to link cc1 shared or static. If we had a way to specify it via a configure option that would let each person decide for themselves. So perhaps having a flag is a good idea. I don't have an opinion on what the default should be, and I hope we can avoid a flame war over that. :-) However there are two existing options in the mean time: One is build/install gmp/mpfr yourself and specify --disable-shared to both. Then use --with-mpfr= to specify using them instead of the system's shared versions. The second is to drop gmp/mpfr into the top level directory and let the bootstrap process build them. This will automatically do --disable-shared and not install these libraries, IIRC. CLEARLY, these aren't as easy as a configure option, but should work for people building their own compiler distributions. If we decide to add a top level configure option I believe that honoring it would require using libtool to link cc1 et al. I'm not fluent in libtool at all and so I'm not confortable enough to propose a patch. --Kaveh PS: A related problem with shared libraries is that currently all binaries (xgcc, collect2, cpp, gcov, etc) are linked with gmp/mpfr, whereas only cc1 etc (stuff containing libbackend.a) really needs to be. It's probably harmless, but may add a few microseconds of unnecessary startup time. -- Kaveh R. Ghazi [EMAIL PROTECTED]
RE: Dynamically linking against GMP and MPFR
On Fri, 25 May 2007, Dave Korn wrote: > On 25 May 2007 15:34, Eric Botcazou wrote: > > Yes, hasn't this been one of the design goals of gcc for as long as any of > us can remember? It wants to be able to bootstrap the GNU world on non-free > systems from scratch and part of that is not requiring anything other than the > standard headers and libraries distributed with the system - isn't that an > important qualification in terms of the GPL? Along with the header/library requirements, you left out needing a bootstrap C compiler. Since gmp/mpfr are both written in C, depending on them is no worse than having GCC depend on libdecnumber or libcpp. Except that the source doesn't live in the tree at the moment. (You can of course plop them in yourself and it will "just work"). The ability to build the "GNU world" using only the system lib, header and compiler hasn't fundamentally changed. You can still do it. Now distributing a dynamically linked cc1 has added a shared lib dependency. But as noted upthread, some people regard dynamic linking as a virtue. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Bribing a reviewer
Hi, about two weeks ago I started submitting patches for C++ compatibility. Unfortunately reviewing as been, ahem, a bit slow. Probably because nobody cares about C++ compatibility. As I have only send 4% of the total patch so far, the current acceptance rate (as in 0 patches in 2 weeks) bothers me a bit. Therefore I am offering a deal to potential reviewers: If you promise to review some of my patches, I will code something _you_ care about. Within reasonable limits, of course :) I don't expect my patches to be simply accepted (i.e. I will have to redo the ChangeLog entries of the early ones), but some help in getting them into gcc would be nice. And I will do something for your first, so you basically cannot lose. Thomas
Call for port conversions to MD define_constraint
Back in 2006 I added a mechanism for defining machine-specific constraints in the MD file rather than with C macros. This mechanism offers several advantages over the old way of doing it, but until all ports are converted, we can't actually implement some of those -- most important, perhaps, is that we could move some of the work done by recog and reload in processing constraints to build time, once all ports are converted. I don't personally have time to convert all ports, and it is better if people who know each individual backend and have access to hardware do the conversions, anyway. So I'd like to invite port maintainers to convert their ports in this development cycle. I see that many of the more popular CPUs have already been done: alpha arm avr i386 ia64 m68k mips rs6000 s390 spu xtensa but there are still a lot left to go: arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore mmix mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax If all ports are converted by, oh, the beginning of August, I'll find time to implement the precalculation of constraint sets for reload and recog. zw
Re: Bribing a reviewer
On 25/05/07, Thomas Neumann <[EMAIL PROTECTED]> wrote: Hi, about two weeks ago I started submitting patches for C++ compatibility. Unfortunately reviewing as been, ahem, a bit slow. Probably because nobody cares about C++ compatibility. As I have only send 4% of the total patch so far, the current acceptance rate (as in 0 patches in 2 weeks) bothers me a bit. Two weeks is a *very* short time for non-critical stuff. The size of the patch matters as well. Also, you should ping patches from time to time (every 1 or 2 weeks). Finally, some maintainers seem to assign a chunk of time for reviewing patches from time to time. Thus, if you have independent patches, send them all (in different emails) or you may miss someone's review window. Nonetheless, I don't want to discourage you in anyway from pursuing your offer. On the contrary, good luck with it. Cheers, Manuel.
special keyword for silent wrong-code bugs
What about a keyword for bugs that - generate wrong code - affect a standard-conforming program - are silent (no error message) ? IMHO, these bugs are especially nasty and should get high visibility (and maybe even special privileges for fixing on a release branch). Thomas
Re: special keyword for silent wrong-code bugs
Thomas Koenig wrote: What about a keyword for bugs that - generate wrong code - affect a standard-conforming program - are silent (no error message) IMHO, these bugs are especially nasty and should get high visibility (and maybe even special privileges for fixing on a release branch). Well I would not *necessarily* give these unconditionally higher priority, since the fourth criterion "- are likely to occur in practice" is an important additional one! Thomas
Re: special keyword for silent wrong-code bugs
On 5/25/07, Thomas Koenig <[EMAIL PROTECTED]> wrote: What about a keyword for bugs that - generate wrong code - affect a standard-conforming program - are silent (no error message) ? IMHO, these bugs are especially nasty and should get high visibility (and maybe even special privileges for fixing on a release branch). It's called 'wrong-code'? Maybe I'm missing something though. Richard.
Re: Dynamically linking against GMP and MPFR
> That just means that it's an application you care about. And now an > upgrade of MPFR which fixes bugs will require you to rebuild the > compiler. Exactly. By design. What goes in the system compiler should be closely scrutinized. -- Eric Botcazou
Re: special keyword for silent wrong-code bugs
Richard Guenther wrote: On 5/25/07, Thomas Koenig <[EMAIL PROTECTED]> wrote: What about a keyword for bugs that - generate wrong code - affect a standard-conforming program - are silent (no error message) ? IMHO, these bugs are especially nasty and should get high visibility (and maybe even special privileges for fixing on a release branch). It's called 'wrong-code'? Maybe I'm missing something though. Perhaps that doesn't connote enough gravitas. David Daney
Re: Call for port conversions to MD define_constraint
> I don't personally have time to convert all ports, and it is better if > people who know each individual backend and have access to hardware > do the conversions, anyway. So I'd like to invite port maintainers to > convert their ports in this development cycle. I see that many of > the more popular CPUs have already been done: > > alpha arm avr i386 ia64 m68k mips rs6000 s390 spu xtensa > > but there are still a lot left to go: > > arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore > mmix mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax OK, I'll do SPARC in the near future. -- Eric Botcazou
Re: special keyword for silent wrong-code bugs
On Friday 25 May 2007, Thomas Koenig wrote: > What about a keyword for bugs that > > - generate wrong code > - affect a standard-conforming program > - are silent (no error message) We already have one: "wrong-code" 1 and 3 mutually exclusive. ie. if we generate an error, then by definition we don't generate bad code because the compilation process never gets that far. 2 is a IMHO fairly academic distinction. We either care about code working (and support no-conforming code as an extension), or we decide that we're ok with that particular code being broken. Paul
Re: special keyword for silent wrong-code bugs
Paul Brook wrote: 2 is a IMHO fairly academic distinction. We either care about code working (and support no-conforming code as an extension), or we decide that we're ok with that particular code being broken. That's a better way to express the concern I had. I would not get excited about some obscure boundary test of some obscure standard rule if it is unlikely it will be run into, but by contrast wrong code for either an out-and-out extension, or a case where we could argue that the "wrong" code is allowed by the standard, but really it was a bug, are much more important if they are likely to affect real programs.
Re: special keyword for silent wrong-code bugs
On Fri, 2007-05-25 at 22:12 +0100, Paul Brook wrote:
> On Friday 25 May 2007, Thomas Koenig wrote:
> > What about a keyword for bugs that
> >
> > - generate wrong code
> > - affect a standard-conforming program
> > - are silent (no error message)
>
> We already have one: "wrong-code"
>
> 1 and 3 mutually exclusive. ie. if we generate an error, then by definition
> we
> don't generate bad code because the compilation process never gets that far.
For 3, I meant a runtime error, segfault, or something else that's
observable.
Trivial example:
If we segfault for printf("%d\n", 2+2), the bug would not be in this
category. If we printed 5, it would be.
Thomas
Re: special keyword for silent wrong-code bugs
On Fri, May 25, 2007 at 02:04:16PM -0700, David Daney wrote: > Richard Guenther wrote: > >On 5/25/07, Thomas Koenig <[EMAIL PROTECTED]> wrote: > >>What about a keyword for bugs that > >> > >>- generate wrong code > >>- affect a standard-conforming program > >>- are silent (no error message) > >> > >>? > >> > >>IMHO, these bugs are especially nasty and should get high visibility > >>(and maybe even special privileges for fixing on a release branch). > > > >It's called 'wrong-code'? Maybe I'm missing something though. > > Perhaps that doesn't connote enough gravitas. Set the keyword to wrong-code and the priority to P1.
insn_code -> tree_code in tree-vect-transform.c
Hi, as of revision 125076, tree-vect-transform.c contains the following code in line 2010: enum tree_code code, code1 = CODE_FOR_nothing, code2 = CODE_FOR_nothing; This most likely wrong, CODE_FOR_nothing is an insn_code, not a tree_code. Unfortunately there is no obvious fix (at least not obvious to me): The usage of code1 implies that code1 should indeed be tree_code. But CODE_FOR_nothing is a non-zero constant (2210), which is larger than MAX_TREE_CODES. Should it perhaps haven been ERROR_MARK instead? Thomas
gcc-4.3-20070525 is now available
Snapshot gcc-4.3-20070525 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070525/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 125076 You'll find: gcc-4.3-20070525.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070525.tar.bz2 C front end and core compiler gcc-ada-4.3-20070525.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070525.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070525.tar.bz2 C++ front end and runtime gcc-java-4.3-20070525.tar.bz2 Java front end and runtime gcc-objc-4.3-20070525.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070525.tar.bz2The GCC testsuite Diffs from 4.3-20070518 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Free 500 MB File Hosting
Now!! You can upload up to 500 MB ! Key features of fileWind.net: - Free and no need to register to use. - Easy to use, upload file, receive link, share. - Files up to 500MB can be uploaded, can split files if too large. - Unlimited storage, upload as many files as you want. - Unlimited downloads, we will never delete for too many downloads. - Fast connection and 24/7 dedicated staff to maintain highest uptime. Just visit us http://www.filewind.net
Re: Dynamically linking against GMP and MPFR
[EMAIL PROTECTED] wrote: However there are two existing options in the mean time: One is build/install gmp/mpfr yourself and specify --disable-shared to both. Then use --with-mpfr= to specify using them instead of the system's shared versions. The second is to drop gmp/mpfr into the top level directory and let the bootstrap process build them. This will automatically do --disable-shared and not install these libraries, IIRC. I spent quite a while getting out of the tangle I got into when I built mpfr and gmp with --disable-shared, leaving older incompatible shared libraries in the path. No doubt, it can be made to work, but with plenty of ways to go wrong.
Re: Call for port conversions to MD define_constraint
On May 25, 2007, at 2:10 PM, Eric Botcazou wrote: I don't personally have time to convert all ports, and it is better if people who know each individual backend and have access to hardware do the conversions, anyway. So I'd like to invite port maintainers to convert their ports in this development cycle. I see that many of the more popular CPUs have already been done: alpha arm avr i386 ia64 m68k mips rs6000 s390 spu xtensa but there are still a lot left to go: arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore mmix mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax OK, I'll do SPARC in the near future. I did mn10300 tonight, I'll post a patch shortly. -eric
