Re: C++98/C++11 ABI compatibility for gcc-4.7
On 06/15/2012 10:12 PM, James Y Knight wrote: Whether or not this particular incompatibility was intended or not, the point remains. You cannot say that GCC devs are taking the C++11 binary incompatibility issue seriously while: a) there exist serious ABI incompatibilities between the modes. b) there is essentially no notice to users about the problem (and lots of users already brokenly compiling in C++11 mode!) c) there are no recommendations or plans for how users and distros are expected to deal with the issue. Trying to understand what the status quo (in GCC 4.7) is exactly: The source of libstdc++ contains code conditional on __GXX_EXPERIMENTAL_CXX0X__ (to differentiate -std=c++11 from -std=c++98 behavior), but such conditional code happens to remain confined to "inline-only" header code for now. Therefore, a single version of libstdc++.so.6 is enough for both -std=c++11 and -std=c++98 applications (without needing to resort to additional tricks in the implementation of libstdc++). Is that right? Stephan
Re: C++98/C++11 ABI compatibility for gcc-4.7
On 18 June 2012 08:52, Stephan Bergmann wrote: > On 06/15/2012 10:12 PM, James Y Knight wrote: >> >> Whether or not this particular incompatibility was intended or not, the >> point remains. You cannot say that GCC devs are taking the C++11 binary >> incompatibility issue seriously while: >> a) there exist serious ABI incompatibilities between the modes. >> b) there is essentially no notice to users about the problem (and lots of >> users already brokenly compiling in C++11 mode!) >> c) there are no recommendations or plans for how users and distros are >> expected to deal with the issue. > > > Trying to understand what the status quo (in GCC 4.7) is exactly: The > source of libstdc++ contains code conditional on __GXX_EXPERIMENTAL_CXX0X__ > (to differentiate -std=c++11 from -std=c++98 behavior), but such conditional > code happens to remain confined to "inline-only" header code for now. There is some non-header-only code compiled into libstdc++.so which uses -std=c++11, but it's for new classes or functions such as std::thread or the std::fstream::fstream(const std::string&) constructor which are only defined when -std=c++11 is used. i.e. there's only one version of that code and it's not even declared in the headers without __GXX_EXPERIMENTAL_CXX0X__. Conditional code where something is defined in both c++98 and c++11 mode, but the definitions are incompatible, is confined to headers. > Therefore, a single version of libstdc++.so.6 is enough for both -std=c++11 > and -std=c++98 applications (without needing to resort to additional tricks > in the implementation of libstdc++). Is that right? Yes. The problems arise when user code that uses the "inline-only" code is linked to other user-code that has a different definition of that inline-only code.
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Mon, Jun 18, 2012 at 3:46 AM, Jonathan Wakely wrote: > The problems arise when user code that uses the "inline-only" code is > linked to other user-code that has a different definition of that > inline-only code. Indeed. A related question is whether for GCC-4.8 we should still continue to claim that C++11 is only experimental? That is at which point are we going to stop claiming that? Is it just a cover for not having to decide anything ABI-wise? If so, I think we can just say that and drop the "experimental" disclaimer. (we don't fully implement C++03, but that does not prompt to claim experimental support.) -- Gaby
Re: C++98/C++11 ABI compatibility for gcc-4.7
On 06/16/2012 12:46 PM, Michael Matz wrote: A soname change for a basic system library is a _major_ PITA and should be avoided even at large costs. In that light: do you have a plan of action of how to never change the soname again, at least on targets where that is reasonably possible with symversions? I'd like to echo this. In my discussions shops doing large C++ development, they've made it clear that the disruption caused by a soname bump would be immense and should be avoided at all costs. In fact, as we already use symversions also for libstdc++, a soname bump should be avoidable already now. Perhaps requiring some extensions to mangling, or giving the "new" classes a different assembler name for mangling purposes, or simply via the new namespace (I'm not sure that solves all issues). But even implementing special magic in the compiler usable by the library to control its ABI/API would be worthwhile if a soname bump can be avoided. Agreed. It's probably worth noting that at least some of the desire to bump the soname expressed to me was to enable moving forward from -fabi-version=2. I don't think we've seen any viable plan to get us away from the V2 abi without a soname bump. jeff
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Mon, Jun 18, 2012 at 7:55 AM, Jeff Law wrote: > On 06/16/2012 12:46 PM, Michael Matz wrote: >>> >>> >> A soname change for a basic system library is a _major_ PITA and should be >> avoided even at large costs. In that light: do you have a plan of action >> of how to never change the soname again, at least on targets where that is >> reasonably possible with symversions? > > I'd like to echo this. In my discussions shops doing large C++ development, > they've made it clear that the disruption caused by a soname bump would be > immense and should be avoided at all costs. Jeff, please note that the path that Michael took from what was said ealier (in particular the quote he provided in his message) and the conclusion of "enthusiasm for soname bump" is still a mystery. -- Gaby
Re: C++98/C++11 ABI compatibility for gcc-4.7
On 06/18/2012 07:16 AM, Gabriel Dos Reis wrote: On Mon, Jun 18, 2012 at 7:55 AM, Jeff Law wrote: On 06/16/2012 12:46 PM, Michael Matz wrote: A soname change for a basic system library is a _major_ PITA and should be avoided even at large costs. In that light: do you have a plan of action of how to never change the soname again, at least on targets where that is reasonably possible with symversions? I'd like to echo this. In my discussions shops doing large C++ development, they've made it clear that the disruption caused by a soname bump would be immense and should be avoided at all costs. Jeff, please note that the path that Michael took from what was said ealier (in particular the quote he provided in his message) and the conclusion of "enthusiasm for soname bump" is still a mystery. You'll note that I didn't include that portion of Michael's message. My comments were meant to echo just the parts of Michael's message that I included inline. Namely that a soname bump is a huge problem and great lengths should be taken to avoid it. jeff
Re: [patch][rfc] How to handle static constructors on linux
ccing the gcc list and Cary Coutant.
The issue comes from gcc pr46770. Cary, have you tried implementing
the --reverse-init-array option? Does it solve the problems you were
seeing?
Can libstdc++ be fixed to work with the iostream static constructors
being in .ctor or .init_array? Would you be interested in such a fix?
From llvm's point of view the main concern is if this ABI change
should be considered a hiccup to be worked around in systems like
fedora 17 or it is something more permanent.
If I understand it correctly, gcc's configure checks if the target
support .init_array and uses it unconditionally if it does, is that
correct?
On 17 June 2012 23:15, Rafael Espíndola wrote:
> I recently upgraded to fedora 17 and now found out that libstdc++ 4.7
> requires c++ constructors to be handled with .init_array instead of
> .ctors. I have not produced a self contained testcase, but when
> building the google protocol buffer compiler (part of chromium) if the
> static constructor for
>
>
> namespace std __attribute__ ((__visibility__ ("default")))
> {
> ...
> static ios_base::Init __ioinit;
>
> }
> .
>
> ends up .ctors, the compiler crashes during startup. Patching the
> clang produced assembly to use .init_array fixes the problem.
>
> This is unfortunate, as the semantics of both are not exactly the
> same, since the runtime process them in reverse order. My first
> intention was to ask for approval for the attached patch, but I was
> told by Chandler that this ABI change caused enough problems for them
> that they reverted it internally. It looks like there are now two ABIs
> and we will have to support both.
>
> On the clang side, we can reuse the logic for detecting the gcc
> installation to know which ABI to use, but it is not clear what the
> best way to forward that to llvm is. Traditionally this is handled in
> the triple, the eabi suffix for example, but fedora 16 and 17 share
> the same triple (x86_64-redhat-linux) and have different ABIs. This is
> also a problem for llc: It doesn't know anything about which gcc
> installation is being used, if any, and the IL represents static
> constructors at a higher level and it is codegen's job to select a
> section.
>
> The best I could think of so far is
>
> * Add a command line option to codegen for using .init_array (defaults
> to false).
> * Have clang produce that option when it detects a gcc 4.7 based distro.
>
> This would mean that without any options llc would produce the wrong
> result on fedora 17 (and other gcc 4.7 distros?), but hopefully cases
> that depend on cross TU construction order are not common enough for
> this to be a big problem for users. Clang would still produce the
> correct results.
>
> Diego, do you know if it is the intention that the new ABI will be
> maintained? If so, do you think all users will be able to upgrade to
> it or will we (gcc and clang) have to keep both for the foreseeable
> future?
>
> Cheers,
> Rafael
Re: C++98/C++11 ABI compatibility for gcc-4.7
Hi, On Mon, 18 Jun 2012, Gabriel Dos Reis wrote: > Jeff, please note that the path that Michael took from what was said > ealier (in particular the quote he provided in his message) and the > conclusion of "enthusiasm for soname bump" is still a mystery. The quoted part suggested switching std::string to the new format for c++11 only, on which I read three agreeing answers (one of them enthusiastic). We have released a libstdc++.so.6 (that contains APIs referring to std::string) with the old format, also for c++11. Changing the API hence requires bumping the soname or doing any of the other tricks I mentioned. As std:string isn't changed already I assume that those other tricks aren't implemented (yet?), hence soname bump it is. So, the enthusiasm transfers to the soname bump (you can't have one without the other in short term). A std:string change for c++11 only also would require installing two libstdc++ in parallel with all the associated considerations (how to make the link editor and the dynamic linker use the right one depending on compilation mode). In that sense changing the layout for std::string for c++11 but not c++98 would be even worse than a soname bump. Ciao, Michael.
Re: C++98/C++11 ABI compatibility for gcc-4.7
Hi, On 06/18/2012 06:01 PM, Michael Matz wrote: Hi, On Mon, 18 Jun 2012, Gabriel Dos Reis wrote: Jeff, please note that the path that Michael took from what was said ealier (in particular the quote he provided in his message) and the conclusion of "enthusiasm for soname bump" is still a mystery. The quoted part suggested switching std::string to the new format for c++11 only, on which I read three agreeing answers (one of them enthusiastic). Uhmm, actually now I agree that switching to the new std::string for C++11 only would be very tricky to do, for the usual reasons (it's used also by , etc). For C++11, the last week I may have envisaged switching only the internals, without changing the exports, but then it would not be able to interoperate with , thus it would not lead to a consistent C++11 library. I suppose that for 4.8.0 we really want to bump the ABI, for many other reasons too, and be done with it. Paolo.
Re: [patch][rfc] How to handle static constructors on linux
On Mon, Jun 18, 2012 at 7:20 AM, Rafael Espíndola
wrote:
> ccing the gcc list and Cary Coutant.
>
> The issue comes from gcc pr46770. Cary, have you tried implementing
> the --reverse-init-array option? Does it solve the problems you were
> seeing?
>
> Can libstdc++ be fixed to work with the iostream static constructors
> being in .ctor or .init_array? Would you be interested in such a fix?
The GNU linker has support to merge .ctor's into init_array. Does the
gold linker have the same feature? This seems more like the real fix
rather than just hacking around the issue.
Thanks,
Andrew Pinski
>
> From llvm's point of view the main concern is if this ABI change
> should be considered a hiccup to be worked around in systems like
> fedora 17 or it is something more permanent.
>
> If I understand it correctly, gcc's configure checks if the target
> support .init_array and uses it unconditionally if it does, is that
> correct?
>
> On 17 June 2012 23:15, Rafael Espíndola wrote:
>> I recently upgraded to fedora 17 and now found out that libstdc++ 4.7
>> requires c++ constructors to be handled with .init_array instead of
>> .ctors. I have not produced a self contained testcase, but when
>> building the google protocol buffer compiler (part of chromium) if the
>> static constructor for
>>
>>
>> namespace std __attribute__ ((__visibility__ ("default")))
>> {
>> ...
>> static ios_base::Init __ioinit;
>>
>> }
>> .
>>
>> ends up .ctors, the compiler crashes during startup. Patching the
>> clang produced assembly to use .init_array fixes the problem.
>>
>> This is unfortunate, as the semantics of both are not exactly the
>> same, since the runtime process them in reverse order. My first
>> intention was to ask for approval for the attached patch, but I was
>> told by Chandler that this ABI change caused enough problems for them
>> that they reverted it internally. It looks like there are now two ABIs
>> and we will have to support both.
>>
>> On the clang side, we can reuse the logic for detecting the gcc
>> installation to know which ABI to use, but it is not clear what the
>> best way to forward that to llvm is. Traditionally this is handled in
>> the triple, the eabi suffix for example, but fedora 16 and 17 share
>> the same triple (x86_64-redhat-linux) and have different ABIs. This is
>> also a problem for llc: It doesn't know anything about which gcc
>> installation is being used, if any, and the IL represents static
>> constructors at a higher level and it is codegen's job to select a
>> section.
>>
>> The best I could think of so far is
>>
>> * Add a command line option to codegen for using .init_array (defaults
>> to false).
>> * Have clang produce that option when it detects a gcc 4.7 based distro.
>>
>> This would mean that without any options llc would produce the wrong
>> result on fedora 17 (and other gcc 4.7 distros?), but hopefully cases
>> that depend on cross TU construction order are not common enough for
>> this to be a big problem for users. Clang would still produce the
>> correct results.
>>
>> Diego, do you know if it is the intention that the new ABI will be
>> maintained? If so, do you think all users will be able to upgrade to
>> it or will we (gcc and clang) have to keep both for the foreseeable
>> future?
>>
>> Cheers,
>> Rafael
Re: [patch][rfc] How to handle static constructors on linux
> The GNU linker has support to merge .ctor's into init_array. Does the > gold linker have the same feature? This seems more like the real fix > rather than just hacking around the issue. Recent version have it. I found the bug when using gold 2.21 which doesn't. What seems to happen is: * In an old linux system, the linker leaves ctors in .ctors, crtbeginS.o has a call to __do_global_dtors_aux. The net result is that _init calls the constructors. * In an all new linux system, the compiler uses .init_array (or the linker moves it there) and crtbeginS.o has nothing to do with constructors. * If we have a compiler that doesn't use .init_array and gold 2.21 in a new linux system, we hit the bug. So this is not as bad as I was expecting (old programs still work), but it is still a somewhat annoying ABI change to handle. I think we can add support for this in clang in 3 ways: 1) Require new linkers when using gcc 4.7 libraries. 2) Ship our own versions of crtbeginS.o (and similars). 3) Use .init_array when using gcc 4.7 libraries. I have most of option 3 implemented. Chandler, do you still think that this is a big enough ABI breakage that it should not be supported? > Thanks, > Andrew Pinski Cheers, Rafael
Re: [patch][rfc] How to handle static constructors on linux
> So this is not as bad as I was expecting (old programs still work), > but it is still a somewhat annoying ABI change to handle. I think we > can add support for this in clang in 3 ways: > > 1) Require new linkers when using gcc 4.7 libraries. > 2) Ship our own versions of crtbeginS.o (and similars). > 3) Use .init_array when using gcc 4.7 libraries. > > I have most of option 3 implemented. Chandler, do you still think > that this is a big enough ABI breakage that it should not be > supported? You keep using the terms "ABI change" and "ABI breakage", but I think you're using those terms a little too freely. The ABI does not specify the order of initializers across compilation units, so the difference in behavior -- while perhaps unfriendly -- does not even qualify as an ABI change, and certainly not as an ABI "breakage". Furthermore, if you're working in chromium, you should be aware that the new behavior is exactly what the Chrome developers are arguing for, as it makes the startup faster. It sounds to me like you're working at cross purposes with the other developers on that project. If the change in behavior is breaking the protocol compiler, I think the best solution would be to fix it so that it doesn't depend on behavior that is explicitly undefined by the ABI. Otherwise, it's going to be fragile and non-portable. Having said all that, I'm still very much in favor of reversing the .init_array, as I believe that makes much more sense than the current behavior. It does, however, change existing behavior for (non-ctor uses of) .init_array, so there will be changes in behavior either way. The only way to preserve the exact status ante is to disable GCC from placing ctors in .init_array and to use the linker's --no-ctors-in-init-array option. Sorry, I have not yet implemented the --reverse-init-array option in gold. -cary
Re: [patch][rfc] How to handle static constructors on linux
[Re-sending this to try to got through to the GCC mailing list... Sorry for the duplication to others... My reply is at the bottom] On Mon, Jun 18, 2012 at 11:08 AM, Chandler Carruth wrote: > On Mon, Jun 18, 2012 at 10:49 AM, Rafael Espíndola > wrote: >> >> > The GNU linker has support to merge .ctor's into init_array. Does the >> > gold linker have the same feature? This seems more like the real fix >> > rather than just hacking around the issue. >> >> Recent version have it. I found the bug when using gold 2.21 which >> doesn't. What seems to happen is: >> >> * In an old linux system, the linker leaves ctors in .ctors, >> crtbeginS.o has a call to __do_global_dtors_aux. The net result is >> that _init calls the constructors. >> * In an all new linux system, the compiler uses .init_array (or the >> linker moves it there) and crtbeginS.o has nothing to do with >> constructors. >> * If we have a compiler that doesn't use .init_array and gold 2.21 in >> a new linux system, we hit the bug. >> >> So this is not as bad as I was expecting (old programs still work), >> but it is still a somewhat annoying ABI change to handle. > > > Thanks to Andrew for explaining some of this to Rafael, and thanks to Rafael > for breaking it down and getting it through my thick skull. =] I now > understand what's going on much better. It is indeed not as bad as I was > expecting. > > However, as Rafael says, this is an annoying ABI change to handle. It seems > that the song-and-dance to maintain backwards compatibility has been > achieved, but the cost has been to introduce a pretty nasty dependency on > newer versions of ld / gold in order to cope with '.o' files built by old > compilers (which we are sometimes stuck with). > > In figuring out how best to support this situation, the question I'm left > with, and would love if someone from the GCC community familiar with the > initial change could answer is: why was this change worth the cost we're now > paying? What is the expected upside to putting constructors in .init_array? > > Thanks, > -Chandler
Re: [patch][rfc] How to handle static constructors on linux
On Mon, Jun 18, 2012 at 11:08 AM, Cary Coutant wrote: >> So this is not as bad as I was expecting (old programs still work), >> but it is still a somewhat annoying ABI change to handle. I think we >> can add support for this in clang in 3 ways: >> >> 1) Require new linkers when using gcc 4.7 libraries. >> 2) Ship our own versions of crtbeginS.o (and similars). >> 3) Use .init_array when using gcc 4.7 libraries. >> >> I have most of option 3 implemented. Chandler, do you still think >> that this is a big enough ABI breakage that it should not be >> supported? > > You keep using the terms "ABI change" and "ABI breakage", but I think > you're using those terms a little too freely. The ABI does not specify > the order of initializers across compilation units, so the difference > in behavior -- while perhaps unfriendly -- does not even qualify as an > ABI change, and certainly not as an ABI "breakage". Not at all. The ordering is not the problem from an ABI stance. My concern was with a mixture of object code or dynamic libraries compiled in both the old and the new world. Rafael had indicated that this mixture produced a crashing program. However, he has clarified all of the various layers of compatibility present, and I agree the problem is much less bad than it originally seemed. It seems all that remains is a rather firm version dependency -- a recent linker with support for migrating '.ctors' -> '.init_array' is required to support old object files. > Furthermore, if you're working in chromium, you should be aware that > the new behavior is exactly what the Chrome developers are arguing > for, as it makes the startup faster. It sounds to me like you're > working at cross purposes with the other developers on that project. Ah, perhaps this goes to answer my question from the other mail: why switch to '.init_array'? I agree that reversing the order is essentially orthogonal, and has a straight forward fix, which is largely a convenience to avoid changing behavior needlessly.
Re: [patch][rfc] How to handle static constructors on linux
>> Furthermore, if you're working in chromium, you should be aware that >> the new behavior is exactly what the Chrome developers are arguing >> for, as it makes the startup faster. It sounds to me like you're >> working at cross purposes with the other developers on that project. > > Ah, perhaps this goes to answer my question from the other mail: why > switch to '.init_array'? This has a long and complicated history. I tried to explain some of that here: http://gcc.gnu.org/ml/gcc-bugs/2010-12/msg01493.html I wasn't part of the GCC community at the time, but I think that .ctors was originally used instead of .init or .init_array precisely because the order of execution of .init/.init_array was backwards from the desired order of execution for constructors (leaving aside the fact that it was backwards from the desired order of execution for *any* kind of initializer). Now that GCC has finally moved from .init to .init_array, they're simply trying to consolidate on the One True Initializer Mechanism. In doing so, it would be desirable to correct that mistake we made so long ago in the gABI, but that's where we ran up against the concerns of the Chrome and Firefox developers who care more about startup performance than about constructor ordering (but, apparently, not enough to use linker options to reorder the code in order to get both good performance *and* proper execution order). -cary
Re: [patch][rfc] How to handle static constructors on linux
> This has a long and complicated history. I tried to explain some of that here: > > http://gcc.gnu.org/ml/gcc-bugs/2010-12/msg01493.html > > I wasn't part of the GCC community at the time, but I think that > .ctors was originally used instead of .init or .init_array precisely > because the order of execution of .init/.init_array was backwards from > the desired order of execution for constructors (leaving aside the > fact that it was backwards from the desired order of execution for > *any* kind of initializer). Now that GCC has finally moved from .init > to .init_array, they're simply trying to consolidate on the One True > Initializer Mechanism. In doing so, it would be desirable to correct > that mistake we made so long ago in the gABI, but that's where we ran > up against the concerns of the Chrome and Firefox developers who care > more about startup performance than about constructor ordering (but, > apparently, not enough to use linker options to reorder the code in > order to get both good performance *and* proper execution order). Just a bit of context: I tried to build chrome in order to test a completely unrelated change (it is an awesome compiler test case) and got a protocol compiler crash, which is where all this started. I don't work with chrome or know why they are using gold 2.21. I do work on firefox and we are using centos 5's linker and gcc 4.5 :-( But I am still missing something, why is the performance so different? Code layout putting the constructors' body in the reverse order they are called? > -cary Cheers, Rafael
Re: [patch][rfc] How to handle static constructors on linux
> But I am still missing something, why is the performance so different? > Code layout putting the constructors' body in the reverse order they > are called? Yes, as I understand it. Cache and TLB prefetching works better when code executes from lower to higher addresses than when executing from higher to lower. -cary
Re: Re: C++98/C++11 ABI compatibility for gcc-4.7
On 06/18/12, Paolo Carlini wrote: > > ... I suppose that for 4.8.0 we really want to bump the ABI, for many other > reasons too, and be done with it. > > Paolo. Would this bump include everything? Such as rebasing std::ios_base::failure from std::exception to std::system_error and everything else? I think we'd best get the whole thing over with at once. How is libstdcxx_so_7-2-branch? Perhaps instead of messing with tr2 I should help here? Ed
C Metaprogramming
Yes, my topic sounds crazy huh? But you guys made it possible when you
started optimizing out constant function pointers. (Thank you!!) This
didn't mature to "full power" until 4.6.? (works in 4.6.2, not sure
about earlier 4.6). Now that you can populate a struct with const
pointers to inline functions and pass a pointer to that struct to a
generic inline function, full C type-injection is now possible. (Well,
you probably didn't need to be able to do it via a struct, but it sure
cleans up the interface).
Example here: http://lwn.net/Articles/500757/ (patches last sent to LKML
on June 7th, don't have them posted elsewhere atm, sorry)
However, the process of verifying that your calls by
constant-function-pointer (much less, one that is a struct member) is
one of examining the generated code, since __builtin_constant_p will
always return zero when passed a function pointer (or any pointer I've
given it thus far). This simple program demonstrates the problem:
#include
static inline int myfunc(int a) {
return a + 42;
}
static int (*const myptr)(int) = myfunc;
int main(int argc, char *argv[]) {
printf("is const = %d\n", __builtin_constant_p(myptr));
/* same result if I dereference it: __builtin_constant_p(*myptr) */
}
So before filing any feature request bugs, I figured I should bring my
discussion here first, as I believe some enhancements to gcc can better
enable this type of programming.
First off, we need a mechanism to verify constness of a function pointer
at build time and generate an error when the value is non-const, similar
to the construct:
#define BUILD_BUG_ON_NON_CONST(arg) \
do { \
extern void __value_non_constant(void)\
__attribute__((error("value not constant"))); \
if (!__builtin_constant_p(arg)) \
__not_constant_error(); \
} while (0)
Second, it will be helpful to have a mechanism to generate a -Winline
warning when a function call by pointer cannot be inlined. Obviously,
this is impossible if you can't first determine that it's a const
function pointer and resolve that to the actual function. I'm sorry to
say that I don't have a suggestion for doing this other than some
__builtin_isinlineable() type of function (that accepts a function
pointer). Perhaps solving the above problem and assuring that, after
this test for function pointer constness succeeds and the const function
pointer can be resolved to an inline function, the compiler can just
emit a warning as it would when a normal function call to an inline
cannot be inlined. Here's an example:
#include
static inline int myfunc(int a) {
return a + 42;
}
static inline void jack(int (*const fnptr)(int)) {
/* macro from above, except working for function pointers */
BUILD_BUG_ON_NON_CONST(fnptr);
/* if the above test passes, any inability to inline myfunc should
* produce a -Winline warning
*/
fnptr(0);
}
int main(int argc, char *argv[]) {
jack(myfunc);
}
Thanks
Daniel
building libstdc++ standalone
Hi, Posted this query (attached below) to gcc-help. Did not get response yet so posting it here. Appreciate your help. http://gcc.gnu.org/ml/gcc-help/2012-06/msg00156.html (Copy attached below). Thanks, Kannan -Original Message- From: Mailaripillai, Kannan Jeganathan Sent: Tuesday, June 19, 2012 1:02 AM To: 'gcc-h...@gcc.gnu.org' Subject: building libstdc++ standalone Hi, I want to build libstdc++ separately (i.e without building toplevel gccsrcdir). Please let me know whether it is possible to do so? In the configure page of libstc++ there is a mention that I need to do start with the configure of the entire gccsrcdir and issue make. But this will start making the entire tool chain. I just want to fire the build of libstdc++. Any suggestions? For the build I am using 4.6.3 GCC compiler installed in ia64 hp-ux system. Regards, Kannan
decimal floating point
Hi, I am investigating the possibilities of using decimal floating point arithmetic with gcc (on Linux / x86_64 to be explicit). Are _Decimal32/_Decimal64/_Decimal128 available as builtin types without further action or do i as a DFP consumer have to issue the correspondent typedef/float/attributeS by myself (as is done in the testcases and the std::decimal headerS)? How do i convert _Decimal32/_Decimal64/_Decimal128/std::decimal from/to string/char* (and do cout/stdout I/O)? Can the (internal?) std::decimal method __getval (giving one of _Decimal32/_Decimal64/_Decimal128) be used by me as a user? Are there plans to add DFP support to glibc? Are there good examples out there showing the superiority of DFP arithmetic over ordinary (binary) FP arithmetic in the domain of monetary calculations? Many thanks in advance Franz
