Query about DWARF output for recursively nested inlined subroutines
Hi all, I have noticed the following construct appearing in some DWARF output and I'm don't understand what it means, or whether it is actually a bug: .uleb128 0x1c ;# (DIE (0x80a) DW_TAG_inlined_subroutine) .long 0x635;# DW_AT_abstract_origin .word _picoMark_LBB23 ;# DW_AT_low_pc .word _picoMark_LBE23 ;# DW_AT_high_pc .byte 0x1 ;# DW_AT_call_file (/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd) .byte 0xaf ;# DW_AT_call_line .uleb128 0x17 ;# (DIE (0x815) DW_TAG_formal_parameter) .long 0x650;# DW_AT_abstract_origin .long _picoMark_LLST15 ;# DW_AT_location .uleb128 0x1c ;# (DIE (0x81e) DW_TAG_inlined_subroutine) .long 0x635;# DW_AT_abstract_origin .word _picoMark_LBB25 ;# DW_AT_low_pc .word _picoMark_LBE25 ;# DW_AT_high_pc .byte 0x1 ;# DW_AT_call_file (/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd) .byte 0x47 ;# DW_AT_call_line .uleb128 0x17 ;# (DIE (0x829) DW_TAG_formal_parameter) .long 0x650;# DW_AT_abstract_origin .long _picoMark_LLST16 ;# DW_AT_location .uleb128 0x1e ;# (DIE (0x832) DW_TAG_lexical_block) .word _picoMark_LBB26 ;# DW_AT_low_pc .word _picoMark_LBE26 ;# DW_AT_high_pc There are two puzzling things about this little fragment. Firstly the inlined subroutine contains another inline instance of the same subroutine within itself (i.e., the first inlined subroutine has abstract origin 0x635, and it contains another inlined subroutine child with the same abstract origin). This seems to imply that the subroutine is recursive, which it isn't. Nowhere in the source code does the subroutine call itself. Secondly, the DWARF contains call site information for the two subroutines, but the second one is simply wrong. The source line for the supposed call site (0x47 above) is the first line of the definition of `main', and isn't even a call site. I can supply a test case (for the picochip port) if necessary, but I just wanted to get an idea of whether this really is a problem, or I'm just misinterpreting what is going on. thanks, dan.
GCC 4.7.0 Status Report (2012-03-02)
The GCC 4.7 branch has been created and a first release candidate is being prepared right now. The branch is closed for now. Previous Report === http://gcc.gnu.org/ml/gcc/2012-02/msg00441.html The next report will announce the release candidate.
Re: GCC 4.7.0 Status Report (2012-03-02)
On 03/02/2012 12:15 PM, Richard Guenther wrote: The GCC 4.7 branch has been created and a first release candidate is being prepared right now. The branch is closed for now. Just be clear (I think the information could be useful in general): mainline can be already considered open for Stage 1 commits? Thanks, Paolo.
GCC 4.8.0 Status Report (2012-03-02), Stage 1 starts now
Status == The trunk has branched for the GCC 4.7 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 4.7 so it is possible to test important fixes for 4.7.0 on it. Quality Data Priority # Change from Last Report --- --- P10 - 2 P2 69 - 1 P31 - 1 --- --- Total70 - 4 Previous Report === http://gcc.gnu.org/ml/gcc/2012-02/msg00441.html The next report will be sent by Jakub.
gcc-4.8-20120302 is now available
Snapshot gcc-4.8-20120302 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120302/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 184782 You'll find: gcc-4.8-20120302.tar.bz2 Complete GCC MD5=99738587c160f04b2fef57269aae4f01 SHA1=4932a396e8f063cff7a160fbdda1c12769bd7657 Diffs from gcc-4.7-20120225 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GCC 4.7.0
GCC 4.7.0 listed, but there isn't link for download!
GCC 4.7.0 Release Candidate available from gcc.gnu.org
GCC 4.7.0 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.7.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 and shortly its mirrors. It has been generated from SVN revision 184777. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.7.0 in about three weeks.
Partly rewriting gengtype in C++ ?
Hello All,
I'm quite tempted to start working on a rewrite of gengtype in C++ (using
C++03 standard).
One of the reasons is that gengtype is really in bad shape, and nobody
understands it well. Another reason is that gengtype needs to be enhanced to
accept at least common C++ containers (like std::vector or std::map, or
probably a GCC specific variant of them whiwh would be notably
gcc_vector)
If I start working on that (very probably inside the MELT branch at first)
do I have a reasonable chance for that to be accepted in some trunk?
(I do strongly believe that a better garbage collector would be useful even
if part of GCC is going C++)
Or is improving gengtype not even worth any effort?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: GCC 4.7.0
On Fri, Mar 02, 2012 at 02:35:52PM +0100, Mioljub Ivanovic wrote: > GCC 4.7.0 listed, but there isn't link for download! 4.7.0 hasn't been released yet, just a release candidate - 4.7.0-rc1. The actual release will happen in a few weeks. If you want to try the release candidate, the link for it has been posted already. Jakub
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> > GCC 4.7.0 Release Candidate available from gcc.gnu.org > > The first release candidate for GCC 4.7.0 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 > > and shortly its mirrors. It has been generated from SVN revision 184777. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. > > If all goes well, I'd like to release 4.7.0 in about three weeks. I'll drop it on Solaris. Give it a push. Do we realy really need that ppl/cloog stuff? I have never seen it build and pass any tests, ever, even once, on Solaris with or without Sun Studio compilers or GCC or prayer and geek magic under a full moon. Seriously. So really, it that stuff a "need" or a "nice to have" ? dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
[Ann] GCC MELT plugin 0.9.4 for GCC 4.6 & 4.7
Hello All
It is my pleasure to announce the GCC MELT plugin version 0.9.4 for GCC 4.6 &
4.7.
MELT is a high level domain specific language to extend GCC.
See http://gcc-melt.org/ for more
The MELT plugin 0.9.4 for GCC 4.6 and 4.7 is available as a gzipped source tar
archive
from http://gcc-melt.org/melt-0.9.4-plugin-for-gcc-4.6-or-4.7.tgz of size
4353062 bytes
and md5sum 3949d71132c79e833f68b3f35e2d1f9c (march 2nd 2012).
It is extracted from MELT branch svn revision 184792.
The version number 0.9.4 of the MELT plugin is unrelated to the version of the
GCC
compiler (4.6 or 4.7) for which it is supposed to work. Bug reports and patches
are
welcome (to the gcc-m...@googlegroups.com list).
NEWS for 0.9.4 MELT plugin for GCC 4.6 (and 4.7 when available)
released on March 02nd, 2012
Language improvements
=
Add CHEADER macro to insert header c-code. For example
(cheader #{#include }#)
or
(cheader #{inline int succ(int x) { return x+1;}}#)
[you still need dirty tricks to link an external library into a MELT
module; as a temporary workaround, consider editing melt-module.mk for
them, perhaps defining GCCMELT_MODULE_EXTRALIBES there, or link
manually the library into melt.so meta-plugin]
Runtime
===
Hash maps have an auxiliary data value, which can be accessed and set
at will.
Translator
==
All C-generating devices (primitives, c-iterators, ...) emit their
code in a syntax checking C function, which is never called, but is
emitted to ensure the emittable C code is syntactically correct. This
catch typos in (defprimitive ...) etc... even for e.g. yet unused
primitives.
Bugs
Many bugs have been corrected.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Partly rewriting gengtype in C++ ?
Basile - > I'm quite tempted to start working on a rewrite of gengtype in C++ (using > C++03 standard). > > One of the reasons is that gengtype is really in bad shape, and nobody > understands it well. Another reason is that gengtype needs to be enhanced to > accept at least common C++ containers (like std::vector or std::map, or > probably a GCC specific variant of them whiwh would be notably > gcc_vector Keytype,typename Elemtype,bool GGCed>) > If I start working on that (very probably inside the MELT branch at first) > do I have a reasonable chance for that to be accepted in some trunk? Since no other GCC part is using C++ currently, I believe this would be rather poor first module choice to convert to C++. If C++ was already a non-optional requirement, then C++ conversion would be OK, but I believe this rewrite should be made in conjunction with current requirements and not in anticipation of some future requirement (or you risk rewriting it twice). -- Laurynas
Re: Partly rewriting gengtype in C++ ?
On 02/03/12 12:56 , Laurynas Biveinis wrote: Since no other GCC part is using C++ currently, I believe this would be rather poor first module choice to convert to C++. If C++ was already a non-optional requirement, then C++ conversion would be OK, It already is. We bootstrap in C++ mode. I don't see a problem starting to move some code to C++. Whether this is a good chunk of code to convert is another question. Basile, I don't see a problem with your plan, in principle. Diego.
Re: Partly rewriting gengtype in C++ ?
2012/3/2 Diego Novillo : > It already is. We bootstrap in C++ mode. I don't see a problem starting to > move some code to C++. Whether this is a good chunk of code to convert is > another question. Sorry, I should have been more precise and said "not the best first module choice to convert to C++ and lose the ability to go back to building in C." I agree that such conversion will have to be done at some point, but I'm not sure if a big rewrite should happen way before the rest of the code will start to use gengtype-annotated C++ data structures. -- Laurynas
Re: Partly rewriting gengtype in C++ ?
On Fri, Mar 2, 2012 at 13:45, Laurynas Biveinis wrote: > 2012/3/2 Diego Novillo : >> It already is. We bootstrap in C++ mode. I don't see a problem starting to >> move some code to C++. Whether this is a good chunk of code to convert is >> another question. > > Sorry, I should have been more precise and said "not the best first > module choice to convert to C++ and lose the ability to go back to > building in C." I do not think we should look back. Trying to retain the ability to go back to C should not influence our design. > I agree that such conversion will have to be done at some point, but > I'm not sure if a big rewrite should happen way before the rest of the > code will start to use gengtype-annotated C++ data structures. Wait, I don't follow. gengtype supporting C++ data structures is different than writing gengtype in C++. Diego.
Re: Partly rewriting gengtype in C++ ?
On Fri, 2 Mar 2012 19:56:19 +0200
Laurynas Biveinis wrote:
> Basile -
>
> > I'm quite tempted to start working on a rewrite of gengtype in C++ (using
> > C++03 standard).
> >
> > One of the reasons is that gengtype is really in bad shape, and nobody
> > understands it well. Another reason is that gengtype needs to be enhanced to
> > accept at least common C++ containers (like std::vector or std::map, or
> > probably a GCC specific variant of them whiwh would be notably
> > gcc_vector > Keytype,typename Elemtype,bool GGCed>)
Actually, this brings another question: is vec.h deprecated (or at least do we
want to
get rid of it for next release), or not yet?
>
> > If I start working on that (very probably inside the MELT branch at first)
> > do I have a reasonable chance for that to be accepted in some trunk?
>
> Since no other GCC part is using C++ currently, I believe this would
> be rather poor first module choice to convert to C++. If C++ was
> already a non-optional requirement, then C++ conversion would be OK,
> but I believe this rewrite should be made in conjunction with current
> requirements and not in anticipation of some future requirement (or
> you risk rewriting it twice).
I don't understand that last sentence. Gengtype is precisely a utility
independent of GCC usage (outside of plugin development), in the sense that
once GCC has
been built you don't need it (except for plugins). So I would believe that it
is the
less risky part to "rewrite" in C++ (because it is an independent executable,
not needed
for the vast majority of GCC users, e.g. for all users of a Linux-distribution
packaged
GCC not compiling GCC plugins).
And my feeling is that C++ is now in principle required for GCC. For instance,
you need
it to compile the Go front-end.
Diego Novillo wrote:
> It already is. We bootstrap in C++ mode. I don't see a problem
> starting to move some code to C++. Whether this is a good chunk of code
> to convert is another question.
Well, I think it is a good code to convert, because it has a limited
dependency, and
because gengtype is really really ugly today. Few people understand it (I am
partly of
them) and those who do, think it is ugly code (and very few people really can
understand
it, because most questions about gengtype remain unanswered.).
>
> Basile, I don't see a problem with your plan, in principle.
(I have not fully decided yet yo work on it; currently it is a wish mostly; is
it ok to
use the MELT branch for that also??? I believe I don't want to work on two
branches!)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Query about DWARF output for recursively nested inlined subroutines
On 03/02/2012 02:49 AM, Dan Towner wrote: Hi all, I have noticed the following construct appearing in some DWARF output and I'm don't understand what it means, or whether it is actually a bug: .uleb128 0x1c ;# (DIE (0x80a) DW_TAG_inlined_subroutine) .long 0x635;# DW_AT_abstract_origin .word _picoMark_LBB23 ;# DW_AT_low_pc .word _picoMark_LBE23 ;# DW_AT_high_pc .byte 0x1 ;# DW_AT_call_file (/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd) .byte 0xaf ;# DW_AT_call_line .uleb128 0x17 ;# (DIE (0x815) DW_TAG_formal_parameter) .long 0x650;# DW_AT_abstract_origin .long _picoMark_LLST15 ;# DW_AT_location .uleb128 0x1c ;# (DIE (0x81e) DW_TAG_inlined_subroutine) .long 0x635;# DW_AT_abstract_origin .word _picoMark_LBB25 ;# DW_AT_low_pc .word _picoMark_LBE25 ;# DW_AT_high_pc .byte 0x1 ;# DW_AT_call_file (/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd) .byte 0x47 ;# DW_AT_call_line .uleb128 0x17 ;# (DIE (0x829) DW_TAG_formal_parameter) .long 0x650;# DW_AT_abstract_origin .long _picoMark_LLST16 ;# DW_AT_location .uleb128 0x1e ;# (DIE (0x832) DW_TAG_lexical_block) .word _picoMark_LBB26 ;# DW_AT_low_pc .word _picoMark_LBE26 ;# DW_AT_high_pc There are two puzzling things about this little fragment. Firstly the inlined subroutine contains another inline instance of the same subroutine within itself (i.e., the first inlined subroutine has abstract origin 0x635, and it contains another inlined subroutine child with the same abstract origin). This seems to imply that the subroutine is recursive, which it isn't. Nowhere in the source code does the subroutine call itself. > Secondly, the DWARF contains call site information for the two subroutines, but the second one is simply wrong. The source line for the supposed call site (0x47 above) is the first line of the definition of `main', and isn't even a call site. I can supply a test case (for the picochip port) if necessary, but I just wanted to get an idea of whether this really is a problem, or I'm just misinterpreting what is going on. It's a bit difficult to tell what is going on. Can you post a small program which creates output like this, along with output from readelf -w or dwarfdump? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Partly rewriting gengtype in C++ ?
>> I agree that such conversion will have to be done at some point, but >> I'm not sure if a big rewrite should happen way before the rest of the >> code will start to use gengtype-annotated C++ data structures. > > Wait, I don't follow. gengtype supporting C++ data structures is > different than writing gengtype in C++. Unless I misunderstood it, Basile's stated reason for the C++ rewrite is to implement C++ data structure support at the same time? -- Laurynas
Re: Partly rewriting gengtype in C++ ?
On Fri, Mar 02, 2012 at 01:06:59PM -0500, Diego Novillo wrote: > On 02/03/12 12:56 , Laurynas Biveinis wrote: > > >Since no other GCC part is using C++ currently, I believe this would > >be rather poor first module choice to convert to C++. If C++ was > >already a non-optional requirement, then C++ conversion would be OK, > > It already is. We bootstrap in C++ mode. I don't see a problem > starting to move some code to C++. Whether this is a good chunk of > code to convert is another question. We don't, we are only using C++ for stage2 and stage3 compilation by default, not for stage1, so you can still bootstrap without C++ compiler. And --disable-build-poststage1-with-cxx works just fine too. I think it would be a bad idea if it was gengtype that started requiring C++, if it is for something useful, perhaps (though you know my position on it). Jakub
Re: Partly rewriting gengtype in C++ ?
On Fri, 2 Mar 2012 13:56:24 -0500
Diego Novillo wrote:
>
> > I agree that such conversion will have to be done at some point, but
> > I'm not sure if a big rewrite should happen way before the rest of the
> > code will start to use gengtype-annotated C++ data structures.
>
> Wait, I don't follow. gengtype supporting C++ data structures is
> different than writing gengtype in C++.
In principle I fully agree (gengtype could even be a GCC plugin -at least if we
restrict
ourselves to hosts having a GCC-, or a MELT extension). Unfortunately, I don't
think that
a gengtype implemented as a GCC plugin would be accepted (because it would
require that
the compiler compiling GCC is a GCC).
I practice, gengtype is so messy today that any significant work on it (notably
support of ggc-ed vectors using C++ vectors or templates, not vec.h) requires
to rewrite
big parts of it. Nobody really understands it very well... And its coding
conventions are
horrible!
So in fact the two are silently related; to enhance gengtype for C++ data
structures I
would be tempted to rewrite it in MELT (but that means a GCC plugin required to
build GCC)
or in C++.
BTW, we could adopt a terminology: gengtype++ would be an enhanced gengtype
able to GTY
types like C++ [GTY-ed] classes or [GTY-ed] vectors
(it is indeed an increment of gengtype,
providing extra functionality). While gengtypexx would be a rewrite of gengtype
in C++.
My feeling is that gengtypexx is a useful step towards gengtype++ ; another
option would
be to make gengtype++ a GCC plugin or MELT extension, but while it is much
simpler (it
can take advantage of all GCC infrastructure, notably all GCC C++ frontend) I
believe it
wont be accepted any soon, because it would require GCC to be hacked with GCC
(we could
put the generated gt-*.[ch] files inside the repository, so GCC would then
still be
compilable by any C++03 compiler).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
Dennis Clarke writes: >> GCC 4.7.0 Release Candidate available from gcc.gnu.org >> >> The first release candidate for GCC 4.7.0 is available from >> >> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >> >> and shortly its mirrors. It has been generated from SVN revision 184777. >> >> I have so far bootstrapped and tested the release candidate on >> x86_64-linux. Please test it and report any issues to bugzilla. >> >> If all goes well, I'd like to release 4.7.0 in about three weeks. > > I'll drop it on Solaris. Give it a push. Do we realy really need that > ppl/cloog stuff? I have never seen it build and pass any tests, ever, > even once, on Solaris with or without Sun Studio compilers or GCC or > prayer and geek magic under a full moon. Seriously. Given that PPL is a C++ library, you need to build it with g++ since Studio CC and g++ aren't ABI-compatible. That said, I'm using them in my Solaris GCC bootstraps, although it admittedly took some effort to build initially and using it requires you to jump through hoops to get the configure options right. I agree that this is an incredible mess right now. > So really, it that stuff a "need" or a "nice to have" ? install.texi documents them as optional: Necessary to build GCC with the Graphite loop optimizations. but that sentence could probably be clarified. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>> If all goes well, I'd like to release 4.7.0 in about three weeks. >> >> I'll drop it on Solaris. Give it a push. Do we realy really need that >> ppl/cloog stuff? I have never seen it build and pass any tests, ever, >> even once, on Solaris with or without Sun Studio compilers or GCC or >> prayer and geek magic under a full moon. Seriously. > > Given that PPL is a C++ library, you need to build it with g++ since > Studio CC and g++ aren't ABI-compatible. > > That said, I'm using them in my Solaris GCC bootstraps, although it > admittedly took some effort to build initially and using it requires you > to jump through hoops to get the configure options right. I agree that > this is an incredible mess right now. I found it too be entirely too much work to be trusted and considered stable long term. So therefore I generally kick ppl/cloog to the curb and focus on core c,c++ gfortan and ada with objc thrown in without the ppl/cloog bits at all. I have been very happy with my results and the recent 4.6.3 RC was the most clean and pure results I have seen to date, on Solaris 8 old Sparc no less : http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02786.html >> So really, it that stuff a "need" or a "nice to have" ? > > install.texi documents them as optional: > > Necessary to build GCC with the Graphite loop optimizations. > > but that sentence could probably be clarified. Would be cool to say "entirely optional". dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> Dennis Clarke writes: > >>> GCC 4.7.0 Release Candidate available from gcc.gnu.org >>> >>> The first release candidate for GCC 4.7.0 is available from >>> >>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >>> >>> and shortly its mirrors. It has been generated from SVN revision 184777. >>> >>> I have so far bootstrapped and tested the release candidate on >>> x86_64-linux. Please test it and report any issues to bugzilla. >>> >>> If all goes well, I'd like to release 4.7.0 in about three weeks. >> >> I'll drop it on Solaris. Give it a push. Do we realy really need that >> ppl/cloog stuff? I have never seen it build and pass any tests, ever, >> even once, on Solaris with or without Sun Studio compilers or GCC or >> prayer and geek magic under a full moon. Seriously. > > Given that PPL is a C++ library, you need to build it with g++ since > Studio CC and g++ aren't ABI-compatible. > > That said, I'm using them in my Solaris GCC bootstraps, although it > admittedly took some effort to build initially and using it requires you > to jump through hoops to get the configure options right. I agree that > this is an incredible mess right now. > >> So really, it that stuff a "need" or a "nice to have" ? > > install.texi documents them as optional: > > Necessary to build GCC with the Graphite loop optimizations. > > but that sentence could probably be clarified. > > Rainer Well this topic is in play for me right now and I'd love your input also. I just finished a prep for bootstrapping gcc 4.6.3 and 4.7.0-RC1 on Solaris 8 sparc and i386 here. One of the initial steps is to ensure we have gmp/mpfr/mpc flawless which I do : . . . PASS: tsub_ui PASS: ttan PASS: ttanh PASS: tui_div PASS: tui_ui_sub GMP: include 5.0.4, lib 5.0.4 MPFR: include 3.1.0, lib 3.1.0 MPC: include 0.9, lib 0.9 PASS: tget_version === All 60 tests passed === gmake[2]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/tests' gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/tests' Making check in doc gmake[1]: Entering directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/doc' gmake[1]: Nothing to be done for `check'. gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/doc' gmake[1]: Entering directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001' gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001' $ $ uname -a SunOS titan 5.8 Generic_127722-03 i86pc i386 i86pc $ cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 $ psrinfo -v Status of virtual processor 0 as of: 03/02/12 20:25:50 on-line since 04/28/11 17:39:44. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 03/02/12 20:25:50 on-line since 04/28/11 17:39:48. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. $ So I have had no issues with old Solaris 8 and Sparc32 or Sparc 64-bit regardless if it is Sparc64 Fujitsu, Niagara T2 or old UltraSparc II. I know I have to compile for x86_64 on Solaris 10. That is a given. The question on my mind that requires ( or begs ) your input is should I continue to trust the golden rule of the ABI and build, test and release based on Solaris 8? I don't really want to do the same process over and over on Solaris 10 or 11 when I *know* that old Solaris 8 is rock solid stable and the baseline ABI to be used. Your thoughts ? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC: OpenMP posix pthread
Hi, I have found the solution i.e. the developers of GCC have found it. The latest version of GCC 4.6.3 can be used with Helgrind. See here for more detail http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.races Best Regards Salvatore
gcc-4.6-20120302 is now available
Snapshot gcc-4.6-20120302 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120302/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 184837 You'll find: gcc-4.6-20120302.tar.bz2 Complete GCC MD5=00581c9995b24aa6817034e48f72db28 SHA1=562c515dc108c1a868152b47280685a8bcc7f0dd Diffs from 4.6-20120224 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: random commentary on -fsplit-stack (and a bug report)
> > "Jay Freeman (saurik)" writes: > "Ian Lance Taylor" wrote: > > After getting more sleep, I realize that this problem is actually much > > more endemic than I had even previously thought. Most any vaguely > > object-oriented library is going to have tons of function pointers in > > it, and you often interact solely with those function pointers (as in, > > you have no actual symbol references anywhere). A simple example: in > > the case of C++, any call to a non-split-stack virtual function will > > fail. > > Certainly true in principle, but unlikely in practice. Why would you > compile part of your C++ program with split-stack and part without? > Implementing child classes that define virtual methods for classes > defined in a precompiled library seems like an unusual case to me. That is actually incredible common, due to object-oriented GUI libraries such as Qt or MFC. Most development for systems like Symbian, or kernel drivers for Darwin (and I personally believe split stacks could be a great boon in kernel development) are also going to involve subclassing code compiled by someone else and overriding virtual methods. The Qt "Getting Started" one-pager actually does this. That said, the specific situation I was describing was even simpler: just using a library compiled by someone else, not subclassing it. If you call a virtual method it will be a call via a function pointer without a symbol reference. Any and all C++ language bindings are thereby off-limits to code that has been compiled with -fsplit-stack until the function pointer issue is addressed. > The abstraction break exists not because I thought it was a good idea, > but because I couldn't see any other way to do it. The split-stack > system needs to work in a world with precompiled libraries and where > people will not change their source code. Any approach that requires > people to rebuild the world, or to edit their source code, is a > non-starter for me. I don't mind if there is some more efficient > mechanism which works if we require those steps, but I wanted a system > that would work where we do not require them. I'm willing to impose > restrictions like "you must compile all your source code with > -fsplit-stack;" I'm not willing to say "you must not use precompiled > libraries." I feel like there was some misunderstanding here, mostly because I agree with your constraints. ;P That said, I feel the current implementation does not quit provide this dream: the function-pointer restriction alone makes it impossible to use numerous standard precompiled libraries. FWIW, though: I certainly do not want to go in a direction that requires /more/ intervention than I feel like I am having to make currently, and I agree that it is possible with none and that should be the target. > > Part of me (and I realize that this causes other tradeoffs, and I'm > > therefore not even recommending it: more just musing) feels like the > > notion of "supports split stack" is more of a calling convention. In > > the same way that gcc currently supports regparm, stdcall, thiscall, > > fastcall... it seems like it might simply be a new attribute (probably > > orthogonal to the calling convention) a function can have (and would > > not have by default): splitcall. > > I'm fine with that, but it requires a source code change, so I want the > system to work without it. Accepted. I believe that the extension of this idea can actually be pulled off with compiler flags and a feature I'm calling "fallback symbols" in the linker, which the linker may already support (although a long time ago I spent a lot of time looking at the linker and don't remember it), but I think would be easy to add and something a lot of other projects an interesting tool), but I will not mention this idea again unless I have a solid proposal that actually manages to accomplish that. > > Actually, thinking about it more: it seems like 99% of these problems > > could be solved by providing a second symbol definition for the > > split-stack prologue and binding that as part of the type > > signature. So, you could either call the "original implementation" of > > a function using its normal symbol, or you could call the split-stack > > prologue version of the same function using one that had been mangled > > with some prefix. ... > It's an interesting idea, but my immediate reaction is to ask how this > helps us in the world where we do not require source code changes. So, imagine a more general linker feature (again, one which may already exist) that allowed you to have a "low-priority symbol" in your object file. As in, one which if you find a copy elsewhere the linker will use that one, but if it doesn't then it will "fall back" to using the one defined locally in this object file. I think that this fairly general mechanism is easy to specify and can probably be used for all sorts of other tasks that people may come up with; it also is not architec
