Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On 05/11/11 21:43, Gabriel Dos Reis wrote:
On Sat, Nov 5, 2011 at 2:30 PM, David Brown
A C++ template class for "_Fract" support would be straightforward to write,
and could easily support the formats in N1169. But it would be very hard to
do so in a way that generates small and fast code without resorting to
inline assembly for targets that have hardware support for such features.
is this some sort of "here an outlanding statement and you would
have to prove a negative to prove me right" or do you have more
factual evidence to back your statement?
It is an estimation.
Some processors have particular instructions or mode flag settings that
let them handle fixed point data very efficiently, such as by doing
multiplication and shift at the same time, handling saturated
arithmetic, or using special "accumulator" registers for particular
features.
It is certainly /conceivable/ that gcc will generate such instructions
automatically, but I would be very surprised - and extremely impressed.
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
16-bit integer - basically combining an 8-bit x 8-bit to 16-bit multiply
with a left shift. So to do a "signed short _Fract" multiply, you have
a single instruction and discard the least significant byte.
Simulating the same operation in generic C would be something like :
int8_t multShortFract(int8_t a, int8_t b) {
int16_t c = (int16_t) a * b;
return (c >> 7);
}
Now, I have enormous respect for the gcc (and related libraries and
tools) developers, and I am regularly surprised by how smart the
compiler is. But using such features of the target requires specific code.
The advantage of using C's "signed short _Fract" here is that gcc /will/
use the optimal instruction in such cases (assuming, of course, that
support is added for the target in question). If it doesn't have such
support, it can do the calculation using something similar to the C
above - slower but correct.
As you say, it is possible that both could be supported - using a template
class to provide a generic solution, and using the C "_Fract" types for
specialized classes. The first step to that, however, is to allow the
standard C "_Fract" types to work in C++ as a gcc extension.
The same principle applies to the decimal types and extended float types
supported by C.
that is one possibility. However there is a difference between
restricted "extension" and full fledged extensions. I can see
how a restricted version would work in C++ as an extension, but
I doubt that is what you want. I can also see how unrestricted
extension (which you seemed to advocate) brings more headache
where a library solution is seamless.
I am not sure what you mean by a "restricted extension" and a "full
fledged extension". But I do appreciate that extensions cause issues
that libraries do not.
Keeping adding builtin type specifiers to a language is not a
sustainable and responsible way to grow a large language
for the real world. I appreciate we may disagree on that point.
It is always difficult for people to see all aspects of something like
this - and it is important to do so when figuring out what to implement.
That's what discussions like this are for!
Let me try to put forward the viewpoint of the embedded programmer,
since these are the people who would use such features. I fully
appreciate that other people see things differently, and that there are
often good reasons for doing something that seems wrong from my
viewpoint. And I also fully appreciate there is a very big difference
between agreeing that something is the best solution, and actual
implementation.
In embedded systems, C is often used for smaller systems, with bigger
systems using C++. There are also people who use C for big systems, and
those that use C++ for small systems. And lots of code is a mixture.
The key issue is that it is, quite frankly, a pain in the a** that C++
is not closer to a superset of C. Originally, C++ was a superset -
excluding a few points that can easily be avoided in well-written code.
These days, the two language standards have moved gradually further
away from each other. Obviously C++ is going to get features that C
does not - that's fair enough. But it is seldom that there is a good
reason for C++ not supporting the additions to C standards.
Some of the differences are just mind-boggling - C1x has got a
"_Static_assert" addition, while C++11 has "static_assert". They do the
same thing, but have a different keyword. Don't these people /talk/ to
each other? Do they make differences like this deliberately to annoy
people - both users and toolwriters?
gcc has always countered that to some extend, by allowing additional C
features to be used in C++. But even there t
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On Sun, 6 Nov 2011, David Brown wrote: > Some of the differences are just mind-boggling - C1x has got a > "_Static_assert" addition, while C++11 has "static_assert". They do the same > thing, but have a different keyword. Don't these people /talk/ to each other? > Do they make differences like this deliberately to annoy people - both users > and toolwriters? In C1X, defines the static_assert macro to expand to _Static_assert, just as C99 defines bool to _Bool. This way you can include the header and write code compatible with both languages, without automatically breaking any code that previously defined those identifiers in its own way. -- Joseph S. Myers jos...@codesourcery.com
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On 6 November 2011 15:03, David Brown wrote: > Obviously C++ is going to get features that C does not - that's fair > enough. But it is seldom that there is a good reason for C++ not supporting > the additions to C standards. > > Some of the differences are just mind-boggling - C1x has got a > "_Static_assert" addition, while C++11 has "static_assert". They do the > same thing, but have a different keyword. Don't these people /talk/ to each > other? Do they make differences like this deliberately to annoy people - > both users and toolwriters? What usually happens is that if C has claimed a new keyword already C++ will reuse it. When C++ has added a new keyword such as static_assert the C committee has preferred to add keywords in the reserved namespace. That's an engineering decision, based on the risk of breaking user code and weighed up against the reward of having more convenient names. The C++ committee are generally less fond of macros, so less willing to solve the problem via e.g. #define static_assert _Static_assert > gcc has always countered that to some extend, by allowing additional C > features to be used in C++. But even there there are limitations - there > are plenty of gcc extensions to C that are very useful, and for some reason > only work in C and not C++. I don't know how you're using "plenty" but I don't think there are that many, and the reason is obvious: the C and C++ front ends are not the same code. If a useful extension is missing from G++ you can create an enhancement request in bugzilla. > As a programmer, when I write portable code in C I want it to be valid C++ > as well. This gives the most flexibility, and the most efficient use of my > code. I don't want to have to re-write code to do the same thing in each > language, or to re-learn the differences. > > So to make "_Fract" and "_Accum" really useful, I need to be able to use it > in C and C++ code, and know that the types are compatible across the two > languages, and that the generated code will be equally efficient. Frankly, > as a user I don't really care whether it is implemented by a C++ library, a > gcc extension, mind-numbing macros, or whatever. It is absolutely fine if > the details are hidden within a "stdfix.h" header file. But what I /don't/ > want to end up with is a type called "signed short _Fract" in C and > "_fract<8>" in C++, or being unable to pass data between the languages, or > having to have C++ call external C functions just to get efficient > implementations. I think a better example is atomics support in C++11 and C11, where std::atomic aka std::atomic_int can be exactly the same representation as _Atomic int and are compatible, but the C++ library solution also allows std::atomic which C doesn't. A *lot* of work went into ensuring the C++ atomics support included a subset that would be implementable in C. Why couldn't the same be done for _Fract?
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On 6 November 2011 15:40, Jonathan Wakely wrote: > > I think a better example is atomics support in C++11 and C11, where > std::atomic aka std::atomic_int can be exactly the same > representation as _Atomic int and are compatible, but the C++ library > solution also allows std::atomic which C doesn't. A *lot* of > work went into ensuring the C++ atomics support included a subset that > would be implementable in C. > > Why couldn't the same be done for _Fract? My point here, in case it wasn't clear, is that a C++ compiler doesn't need to support _Atomic as a specifier, but code can be written to work with both C and C++ anyway.
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On 11/06/2011 10:40 AM, Jonathan Wakely wrote: On 6 November 2011 15:03, David Brown wrote: What usually happens is that if C has claimed a new keyword already C++ will reuse it. When C++ has added a new keyword such as static_assert the C committee has preferred to add keywords in the reserved namespace. That's an engineering decision, based on the risk of breaking user code and weighed up against the reward of having more convenient names. The C++ committee are generally less fond of macros, so less willing to solve the problem via e.g. #define static_assert _Static_assert As a programmer, when I write portable code in C I want it to be valid C++ as well. This gives the most flexibility, and the most efficient use of my code. I don't want to have to re-write code to do the same thing in each language, or to re-learn the differences. So to make "_Fract" and "_Accum" really useful, I need to be able to use it in C and C++ code, and know that the types are compatible across the two languages, and that the generated code will be equally efficient. Frankly, as a user I don't really care whether it is implemented by a C++ library, a gcc extension, mind-numbing macros, or whatever. It is absolutely fine if the details are hidden within a "stdfix.h" header file. But what I /don't/ want to end up with is a type called "signed short _Fract" in C and "_fract<8>" in C++, or being unable to pass data between the languages, or having to have C++ call external C functions just to get efficient implementations. I think a better example is atomics support in C++11 and C11, where std::atomic aka std::atomic_int can be exactly the same representation as _Atomic int and are compatible, but the C++ library solution also allows std::atomic which C doesn't. A *lot* of work went into ensuring the C++ atomics support included a subset that would be implementable in C. Why couldn't the same be done for _Fract? I think it would be very possible to have a general template library for C++ that would handle a range of sizes and granularities. There would be a few combinations that would correspond to the C types. These would use the hardware implementation by template specialization. I think the deeper issue is that there are two communities who are interested in fixed-point math. 1. Embedded system folks who need an efficient replacement for floating point that matches their hardware. 2. Systems programmers and financial types who want fixed-point like in COBOL and Ada where you specify granularity and number of digits. I'm saying both groups can be accommodated with care. I think even source compatibility could be achieved with home headers.
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On 06/11/11 16:40, Jonathan Wakely wrote: On 6 November 2011 15:03, David Brown wrote: Obviously C++ is going to get features that C does not - that's fair enough. But it is seldom that there is a good reason for C++ not supporting the additions to C standards. Some of the differences are just mind-boggling - C1x has got a "_Static_assert" addition, while C++11 has "static_assert". They do the same thing, but have a different keyword. Don't these people /talk/ to each other? Do they make differences like this deliberately to annoy people - both users and toolwriters? What usually happens is that if C has claimed a new keyword already C++ will reuse it. When C++ has added a new keyword such as static_assert the C committee has preferred to add keywords in the reserved namespace. That's an engineering decision, based on the risk of breaking user code and weighed up against the reward of having more convenient names. The C++ committee are generally less fond of macros, so less willing to solve the problem via e.g. #define static_assert _Static_assert Yes, I can understand that there /are/ good reasons behind these decisions - but it can be quite frustrating for the humble user who merely sees inconsistencies. And I do appreciate that many of these inconsistencies are hidden by using header files (as mentioned by Joseph Myers in his reply), making the differences mostly irrelevant to users. Perhaps I have been getting too worked up about small things here, and missing out on the major points, such as the efforts made to keep things consistent through the use of header files. I still find it odd that features are added in different ways in each language, then headers are used to nullify the differences - but I thank you for your explanation of /why/ there are these differences. gcc has always countered that to some extend, by allowing additional C features to be used in C++. But even there there are limitations - there are plenty of gcc extensions to C that are very useful, and for some reason only work in C and not C++. I don't know how you're using "plenty" but I don't think there are that many, and the reason is obvious: the C and C++ front ends are not the same code. If a useful extension is missing from G++ you can create an enhancement request in bugzilla. I make the assumption that if a feature is in the C front end and not the C++ front end, then there is a reason for that - though the reason may be as simple as "no one has asked for this feature, so no one has made it". I suppose my desire to see a consistent _Fract implementation between C and C++ is such an enhancement request, though it is made in this list rather than bugzilla. As a programmer, when I write portable code in C I want it to be valid C++ as well. This gives the most flexibility, and the most efficient use of my code. I don't want to have to re-write code to do the same thing in each language, or to re-learn the differences. So to make "_Fract" and "_Accum" really useful, I need to be able to use it in C and C++ code, and know that the types are compatible across the two languages, and that the generated code will be equally efficient. Frankly, as a user I don't really care whether it is implemented by a C++ library, a gcc extension, mind-numbing macros, or whatever. It is absolutely fine if the details are hidden within a "stdfix.h" header file. But what I /don't/ want to end up with is a type called "signed short _Fract" in C and "_fract<8>" in C++, or being unable to pass data between the languages, or having to have C++ call external C functions just to get efficient implementations. I think a better example is atomics support in C++11 and C11, where std::atomic aka std::atomic_int can be exactly the same representation as _Atomic int and are compatible, but the C++ library solution also allows std::atomic which C doesn't. A *lot* of work went into ensuring the C++ atomics support included a subset that would be implementable in C. Why couldn't the same be done for _Fract? If it can, then that would be marvellous, giving C++ users the choice of the same efficient _Fract's as C (on platforms that support efficient implementations, of course) and greater flexibility. My original concern in this thread was that if the "r" and "k" _Fract suffixes were freed for general use in C++, it would be difficult to use them later. Thanks, David
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On Sun, 6 Nov 2011, David Brown wrote: My original concern in this thread was that if the "r" and "k" _Fract suffixes were freed for general use in C++, it would be difficult to use them later. The C++ standard already reserves all the suffixes that don't start with an underscore for future normalization. I interpret that as: defining your own suffix k should print a warning instead of an error. I don't believe this is worth changing (if the error message is readable enough) until there is a plan for actually using that suffix. -- Marc Glisse
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On 6 November 2011 16:10, David Brown wrote: > Perhaps I have been getting too worked up about small things here, and > missing out on the major points, such as the efforts made to keep things > consistent through the use of header files. I still find it odd that > features are added in different ways in each language, then headers are used > to nullify the differences - but I thank you for your explanation of /why/ > there are these differences. The main reason is that the committees are composed of different people. People get involved with standardisation efforts for the language(s) they care about, and doing extra work to maintain compatibility with a language you don't care about is hard to find motivation for. > I make the assumption that if a feature is in the C front end and not the > C++ front end, then there is a reason for that - though the reason may be as > simple as "no one has asked for this feature, so no one has made it". Exactly.
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
Quoting David Brown :
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
multiply with a left shift. So to do a "signed short _Fract" multiply,
you have a single instruction and discard the least significant byte.
Simulating the same operation in generic C would be something like :
int8_t multShortFract(int8_t a, int8_t b) {
int16_t c = (int16_t) a * b;
return (c >> 7);
}
If you can make up your mind if the result is 8 or 16 bit, generating the
instruction should be standard fare for the combiner pass.
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On Sun, Nov 6, 2011 at 10:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > I think it would be very possible to have a general template library for C++ > that would handle a range of sizes and granularities. There would be a few > combinations that would correspond to the C types. These would use the > hardware implementation by template specialization. There is widespread (unfounded) belief in some community that a library datatype MUST be inefficient, because otherwise it would have been builtin. By the same token, there is a widespread belief that if a builtin datatype cannot be library based. Often, these people get into complete disbelief disorder when it is reveled to them, that on quite descent platforms, the support for a builtin type will be mostly library. Conversely, they do not want to believe that a library facility can receive special treatment from a compiler. Unless that facility is from C, in which case it is OK, because C is builtin anyway. Someone mentioned _Bool and _Static_assert and wonders whether C and C++ standards committees talk to each other. They do. At least they have formal liaisons. What is less appreciated though is that the two community have different cultures There are lot of reasons why they come to different solutions (and the respective communities would expect different solutions.) The cultures are very different. The C++ community tend to believe in libraries and general abstraction facilities with wide range application. The C community tend to believe more in builtin type specifiers. The fact that the communities intersect is no guarantee that they have to come to the same solutions. Furthermore, it is often under-appreciated that C++ has vibrant embedded system community (even issued embedded system TR) and templates are far more prominent roles there than the urban legends let it know, or one would guess from some depiction of "the" embedded world. Someone mentioned _Complex. But _Complex has its own issues with C++ language rules and library.
bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
Well, dear GCC users I am now seeing behavior that falls in the arean of the bizarre. No sense in talking much about it but here is the error message : /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: ./conf4075subs.sh: file is too large configure: error: could not make ./config.status Since this happens within 60 seconds I may as well post the whole configure report as well as the actual results and then see if anyone can spot the issue here : First a bit of info. titan$ which gstrip /opt/bw/bin/gstrip titan$ gstrip --version GNU strip (Blastwave.org Inc. Wed Jun 29 03:24:53 GMT 2011) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. titan$ which gobjcopy /opt/bw/bin/gobjcopy titan$ gobjcopy --version GNU objcopy (Blastwave.org Inc. Wed Jun 29 03:24:53 GMT 2011) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. titan$ which gcc /opt/bw/bin/gcc titan$ gcc --version gcc (Blastwave.org Inc. Wed Jun 29 15:53:20 GMT 2011) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. That gcc compiler has some pretty good testsuite results : http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html However, configure looks okay but the build fails, fast. titan$ ../gcc-4.6.2/configure --with-as=/opt/bw/bin/gas --prefix=/opt/bw \ > --libdir=/opt/bw/lib/i386 --libexecdir=/opt/bw/lib \ > --with-local-prefix=/opt/bw/include \ > --with-pkgversion=Blastwave.org\ Inc.\ Sun\ Nov\ \ 7\ 00\:56\:22\ GMT\ 2011 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > --enable-languages=ada,c,c++,fortran,objc --enable-bootstrap checking build system type... i386-pc-solaris2.8 checking host system type... i386-pc-solaris2.8 checking target system type... i386-pc-solaris2.8 checking for a BSD-compatible install... /opt/bw/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /opt/bw/bin/gsed checking for gawk... gawk checking for gcc... /opt/bw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/bw/bin/gcc accepts -g... yes checking for /opt/bw/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /opt/bw/bin/g++ accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for bison... bison -y checking for bison... bison checking for gm4... gm4 checking for flex... no checking for lex... lex checking for flex... no checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /opt/bw/bin/gar checking for as... (cached) /opt/bw/bin/gas checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... (cached) /opt/bw/bin/gnm checking for ranlib... (cached) /opt/bw/bin/granlib checking for strip... (cached) /opt/bw/bin/gstrip checking for windres... no checking for windmc... no checking for objcopy... (cached) /opt/bw/bin/gobjcopy checking for objdump... (cached) /opt/bw/bin/gobjdump checking for cc... no checking for gcc... gcc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... /opt/bw/i386-pc-solaris2.8/bin/ar checking for as... /opt/bw/i386-pc-solaris2.8/bin/as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... /opt/bw/i386-pc-solaris2.8/bin/nm checking for objdump... /opt/bw/i386-pc-solaris2.8/bin/objdump checking for ranlib... /opt/bw/i3
Re: # of unexpected failures 768 ?
> Dennis Clarke writes: > >> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am >> seeing a really large increase in the number of "unexpected failures" on >> various tests. >> >> With 4.6.1 and Solaris I was able to get reasonable results : >> >> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html >> >> Then if I use the resultant compiler from a 4.6.1 build I get a massive >> increase in failures on both i386 and Sparc : >> >> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html > > FAIL: g++.dg/ext/visibility/fvisibility-inlines-hidden-2.C scan-not-hidden > > All the scan-not-hidden failures are usually an indication that objdump > isn't in your PATH. Right, thank you. On i386 I rectified that situation with binutils however on Sparc this was not an issue. See results : http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html Only the new "go" language seems to be a major issue now. >> This seems blatantly wrong. At what point does one throw out the result >> of >> a bootstrap as not-acceptable ? With any non-zero value for "unexpected >> failures" ? > > There's no such number, only comparisons to other testsuite results. In > many cases (e.g. in the scan-not-hidden failures above), there's nothing > wrong with the compiler, just with the test environment. And in your > case, only two problems account for the vast majority of the failures. > >> Also, I see bucket loads of these : >> >> FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error) >> >> What should I think about an "internal compiler error" ? > > This seems fundamentally broken on your machine. With the exception of > the largefile.c testcases, those pass everywhere else, so you'd have to > debug what's going on there. Any "internal compiler error" mean throw the whole thing out and start over. At least that is the only safe course of action in my mind. > FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler > error) > [...] > FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess > errors) > WARNING: program timed out. > > Those test cases have excessive stack space or runtime requirements and > are known to fail on slow machines or those with default resource > limits. Those are known testcase bugs, but nobody cared about this so > far ;-( I'm so happy to hit those special cases :-) > Overall, your results don't look bad to me, once you've installed > objdump and investigated the PCH failures. yep ... I have been digging. On Sparc things are going much better but on i386 I have tossed the whole scenario out and am starting over from first principles. Build everything from scratch with the Sun Studio compiler until I hit things that need gcc. Like libgmp etc. > As an asside, I'd suggest to considerably reduce your set of configure > options: many of them are the default (like --without-gnu-ld > --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix, > --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8 > --build=i386-pc-solaris2.8) or unnecessary > (--enable-stage1-languages=c). > > I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it > might be better to keep the default of pentiumpro instead. Yep, did that. Thank you. However on i386 things got worse, not better. I have to toss that out and start over. On Sparc things are much better with the exception of "go". Thank you for the input. 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. | +-+---+
Delegating Constructors?
Hi, I'm wondering whether there's been any progress on the recent "Delegating Constructors" patch: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01202.html The last post on that thread (in gcc-patches) was early last month. There doesn't seem to have been any objection, just minor review-type comments, and it sounded like it was in pretty good shape, but the thread eventually just sort of petered out. Is this likely to go in for 4.7? Thanks, -Miles -- "Yorton, Wressle, and Gospel Oak, the richness of your heritage is ended. We shall not stop at you again; for Dr Beeching stops at nothing."
Re: Delegating Constructors?
On 7 November 2011 03:58, Miles Bader wrote: > Hi, I'm wondering whether there's been any progress on the recent > "Delegating Constructors" patch: > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01202.html > The last post on that thread (in gcc-patches) was early last month. > There doesn't seem to have been any objection, just minor review-type > comments, and it sounded like it was in pretty good shape, but the > thread eventually just sort of petered out. > Is this likely to go in for 4.7? As far as I know, all the review comments have been fixed, I posted a patch that fixed the unwanted whitespace changes and such. It's pending copyright paperwork from the author of the original patch. (my copyright paperwork is in order, but since I didn't write all of it, there's some crossing t's and dotting i's). I don't know about release schedules, so I can't say whether it will make it for 4.7 or not.
Re: Delegating Constructors?
Ville Voutilainen writes: >> Is this likely to go in for 4.7? > > As far as I know, all the review comments have been fixed, I posted a > patch that fixed the unwanted whitespace changes and such. > > It's pending copyright paperwork from the author of the original patch. > (my copyright paperwork is in order, but since I didn't write all of it, > there's some crossing t's and dotting i's). Hmm, has he been contacted recently? The original patch was from ages ago... Thanks, -Miles -- Cynic, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic's eyes to improve his vision.
Need to correct the function declaration.
When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the following error: > gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error: > invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive] Please add the void into arguments list for function __once_proxy();, in file mutex:799. Regards, niXman.
Re: Need to correct the function declaration.
On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote: > When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the > following error: >> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error: >> invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive] > > Please add the void into arguments list for function __once_proxy();, > in file mutex:799. This source file is C++, not C, and so adding "void' should be a no-op. What makes you believe that this is the problem? Could you show the line where the error occurs? -- James
Re: Need to correct the function declaration.
2011/11/7 James Dennett : > On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote: >> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the >> following error: >>> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error: >>> invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive] >> >> Please add the void into arguments list for function __once_proxy();, >> in file mutex:799. > > This source file is C++, not C, and so adding "void' should be a no-op. This is the extern "C" declaration. > > What makes you believe that this is the problem? Could you show the > line where the error occurs? > > -- James >
Re: Need to correct the function declaration.
2011/11/7 niXman : > 2011/11/7 James Dennett : >> On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote: >>> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the >>> following error: gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive] >>> >>> Please add the void into arguments list for function __once_proxy();, >>> in file mutex:799. >> >> This source file is C++, not C, and so adding "void' should be a no-op. > This is the extern "C" declaration. At least adding void solves the problem. > > >> >> What makes you believe that this is the problem? Could you show the >> line where the error occurs? >> >> -- James >> >
Re: # of unexpected failures 768 ?
Dennis Clarke writes: > Only the new "go" language seems to be a major issue now. The implementation of Go in the 4.6 releases does not support Solaris. Go on Solaris works on mainline. Ian
Re: Need to correct the function declaration.
On 7 November 2011 03:02, James Dennett wrote: > On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote: >> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the >> following error: >>> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error: >>> invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive] >> >> Please add the void into arguments list for function __once_proxy();, >> in file mutex:799. > > This source file is C++, not C, and so adding "void' should be a no-op. > > What makes you believe that this is the problem? Could you show the > line where the error occurs? Same problem on AIX: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982#c36 I have no idea why that makes a difference, but I can check in the change.
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
This should probably be on the gcc-help list. On 7 November 2011 01:08, Dennis Clarke wrote: > > Well, dear GCC users I am now seeing behavior that falls in the arean of > the bizarre. No sense in talking much about it but here is the error > message : > > /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: > ./conf4075subs.sh: file is too large > configure: error: could not make ./config.status Have you checked your ulimit? And of course disk space?
Re: Need to correct the function declaration.
On 7 November 2011 07:09, Jonathan Wakely wrote:
> On 7 November 2011 03:02, James Dennett wrote:
>> On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote:
>>> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
>>> following error:
gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error:
invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
>>>
>>> Please add the void into arguments list for function __once_proxy();,
>>> in file mutex:799.
>>
>> This source file is C++, not C, and so adding "void' should be a no-op.
>>
>> What makes you believe that this is the problem? Could you show the
>> line where the error occurs?
>
> Same problem on AIX:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982#c36
>
> I have no idea why that makes a difference, but I can check in the change.
This seems to be caused by the "implicit extern C" hack used on
platforms without C++-clean headers:
/* Parse a parameter-declaration-clause.
parameter-declaration-clause:
parameter-declaration-list [opt] ... [opt]
parameter-declaration-list , ...
Returns a representation for the parameter declarations. A return
value of NULL indicates a parameter-declaration-clause consisting
only of an ellipsis. */
static tree
cp_parser_parameter_declaration_clause (cp_parser* parser)
...
else if (token->type == CPP_CLOSE_PAREN)
/* There are no parameters. */
{
#ifndef NO_IMPLICIT_EXTERN_C
if (in_system_header && current_class_type == NULL
&& current_lang_name == lang_name_c)
return NULL_TREE;
else
#endif
return void_list_node;
}
I suppose I'd better change libstdc++ to use the abominable (void)
parameter list, but I'll also open a bug report, it should be obvious
to G++ that a function explicitly declared extern "C" doesn't need the
implicit extern "C" rules.
Re: Need to correct the function declaration.
Fixed on trunk by revision 181072. Please use bugzilla or the libstdc++ mailing list next time.
