An Rvalue references for g++ patch
Hello. I would like to point out to those that may be interested and don't read comp.std.c++: http://russ.hn.org/rref/ The thread is: http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/64bf775bdf069dad/de55703ebbe063ce#de55703ebbe063ce -- Pedro Lamarão
[c++] stuff proposed for C++0x
Hello list. I've recently been toying with the "rref" patch found here: http://mndfck.org/~pedro.lamarao/projects/c++0x/ As part of my learning process I've modified it and broken it in three parts: new flags to activate c++0x syntax and semantics, "reference collapsing" as per DR #106 proposed resolution, and the "r-value references" proposal as in N1855. I'd like to also try and implement the new "auto" semantics as in N1894. These are online for your viewing pleasure here: http://mndfck.org/~pedro.lamarao/projects/c++0x/ Would any of this be acceptable for 4.2? -- Pedro Lamarão
Re: svn access on RHEL 4.0
Bradley Lucier wrote: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' > > I first got that message when I tried contrib/gcc_update after doing a > svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. Have you tried doing "svn cleanup" as the error message suggests? -- Pedro Lamarão
Re: svn access on RHEL 4.0
Bradley Lucier wrote: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' I'm sorry, I'm a little sleepy, in the hurry of trying to "help" I totally missed these lines. :-( -- Pedro Lamarão
[gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
Current trunk (revision 150381) fails to bootstrap with the following configuration: [pedro.lama...@larissa trunk-obj]$ ../trunk/configure --prefix=/opt/gcc-4.5 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --enable-build-with-cxx --with-tune=generic --with-arch=i586 --build=i586-redhat-linux giving the following error: g++ -I../../trunk/libcpp -I. -I../../trunk/libcpp/../include -I../../trunk/libcpp/include -g -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I../../trunk/libcpp -I. -I../../trunk/libcpp/../include -I../../trunk/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../trunk/libcpp/charset.c In file included from ../../trunk/libcpp/system.h:342, from ../../trunk/libcpp/charset.c:23: ../../trunk/libcpp/../include/libiberty.h:106: error: new declaration ‘char* basename(const char*)’ /usr/include/string.h:601: error: ambiguates old declaration ‘const char* basename(const char*)’ Am I missing something? -- P.
[cxx0x-lambdas] Bootstrap fails
Revision 150382 of the cxx0x-lambdas-branch fails to bootstrap with the following error: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/gengtype-lex.o build/gengtype-parse.o build/errors.o ../build-i586-redhat-linux/libiberty/libiberty.a /bin/sh ../../cxx0x-lambda/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype ../../cxx0x-lambda/gcc gtyp-input.list ../../cxx0x-lambda/gcc/cp/cp-tree.h:571: parse error: GTY must be specified before identifier make[3]: ** [s-gtype] Erro 1 when configured like this: [pedro.lama...@larissa cxx0x-lambda-obj]$ ../cxx0x-lambda/configure --prefix=/opt/gcc-lambda --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --with-tune=generic --with-arch=i586 --build=i586-redhat-linux on a Fedora 11 system. -- P.
[gcc-in-cxx] replacing qsort with std::sort
I've recently started my contributions to the gcc-in-cxx project, and eventually decided on the qsort suggestion because it seems the easiest one. I've made the change in three places in cp/classes.c; the patch can be found here: http://code.google.com/p/ccppbrasil/wiki/GccInCxx Is this the way to go? Some questions occurred to me: in order to support a C and a C++ compiler at the same time, what "portability" mechanism should be used? #ifdef guards to switch between qsort and std::sort on the spot, based on __cplusplus? Should a helper function be declared somewhere? Also, std::sort requires a "less" function on reference-tovalue-type, so the current foo_cmp functions can't be reused. Would a separate patch to introduce foo_less variants be acceptable for GCC 4.5 right now? Also, is the gcc-in-cxx branch still active? Should my objective be to contribute patches to this branch? On a side note, I've studied vec.h and found it hard to change. One reason is because this header is included by the gen*.c stuff, which is still being compiled by a C compiler, even when building with a C++ compiler is enabled. I've considered providing a separate version of vec.h when C++ is being used, to avoid infinite #ifdefs. Is this a good idea? -- Pedro Lamarão
Re: [gcc-in-cxx] replacing qsort with std::sort
2009/8/12 Richard Guenther : > On Wed, Aug 12, 2009 at 2:03 AM, Pedro > Lamarão wrote: >> I've recently started my contributions to the gcc-in-cxx project, and >> eventually decided on the qsort suggestion because it seems the >> easiest one. >> I've made the change in three places in cp/classes.c; the patch can be >> found here: >> >> http://code.google.com/p/ccppbrasil/wiki/GccInCxx >> >> Is this the way to go? > > Please attach patches in the future. Sorry. I thought policy on this list was against attachments. > +#include > + > #include "config.h" > #include "system.h" > > The includes need to come after config.h and system.h at least. I agree, but including last causes many "poisoned" warnings that I don't understand -- using names like "calloc". >> Also, std::sort requires a "less" function on reference-tovalue-type, >> so the current foo_cmp functions can't be reused. >> Would a separate patch to introduce foo_less variants be acceptable >> for GCC 4.5 right now? > > No, I don't see the need for them. I'll maintain these changes elsewhere, then. Will GCC ever require support for both a C and a C++ compiler at the same time? If it is reasonable to assume a C++ compiler things become easier for me. -- P.
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
2009/8/26 Ralf Wildenhues : >> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration >> >‘char* basename(const char*)’ >> >/usr/include/string.h:601: error: ambiguates old declaration ‘const >> >char* basename(const char*)’ >> >> The problem is that AC_CHECK_DECLS gets confused by overloaded >> functions, and glibc 2.10 has overloaded declarations of basename >> and some other string functions for const-correctness. > > Could you show the config.log snippet that shows the failed test? > Is this a new error due to the autotools upgrade, or new due to > glibc 2.10? I think this is new in glibc 2.10, for the reasons given by Jason Merrill above. I've discussed this problem with Jerry Quinn before, and he had a tentative patch that worked for me. As I understand things, this patch is on hold waiting for a solution to the bootstrap comparison problem being discussed in another thread. I am waiting for a solution to these problems to continue work on the std::sort gcc-in-cxx subproject; keeping all these patches up to date with trunk is too difficult for me right now. Currently, I have a patch to an old revision of the trunk. -- P.
Re: [gcc-in-cxx] replacing qsort with std::sort
2009/8/29 Magnus Fromreide : > > Why the changes to gcc/system.h where you unpoision malloc and realloc? > Why the changes to libcpp/system.h where you unpoision malloc, realloc, > calloc and strdup? Including requires them for some reason. I haven't really looked into it. -- P.
Re: [gcc-in-cxx] replacing qsort with std::sort
2009/8/31 Richard Henderson : > On 08/29/2009 03:49 PM, Pedro Lamarão wrote: >> >> 2009/8/29 Magnus Fromreide: >>> >>> Why the changes to gcc/system.h where you unpoision malloc and realloc? >>> Why the changes to libcpp/system.h where you unpoision malloc, realloc, >>> calloc and strdup? >> >> Including requires them for some reason. >> I haven't really looked into it. > > You should simply include in system.h before > the poisoning. Oh. Right. :-) For the record, this is the error message I get: In file included from /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_algo.h:60, from /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/algorithm:62, from ../../libcpp/pch.c:26: /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:78:8: error: attempt to use poisoned "calloc" /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:85:8: error: attempt to use poisoned "malloc" /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:91:8: error: attempt to use poisoned "realloc" /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:112:11: error: attempt to use poisoned "calloc" /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:119:11: error: attempt to use poisoned "malloc" /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:127:11: error: attempt to use poisoned "realloc" I'll try to include cstdlib in system.h to see if that's enough. -- P.
Re: [gcc-in-cxx] replacing qsort with std::sort
2009/8/28 Pedro Lamarão : > I have not yet made complete size and execution speed measurements, though. > I've run the test suite and there are some failures; I think many of > them are not regressions when compared with a pure build with C++. Comparing trunk -r151160 and trunk -t151160 --enable-build-with-cxx + patches, these are the sizes of xgcc and g++ before strip: [psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++ -rwxrwxr-x. 1 psilva psilva 481K Ago 31 12:58 gcc/g++ -rwxrwxr-x. 1 psilva psilva 477K Ago 31 12:58 gcc/xgcc [psi...@joana obj]$ ls -lh ../../std_sort/obj/gcc/xgcc ../../std_sort/obj/gcc/g++ -rwxrwxr-x. 1 psilva psilva 491K Ago 31 12:33 ../../std_sort/obj/gcc/g++ -rwxrwxr-x. 1 psilva psilva 487K Ago 31 12:33 ../../std_sort/obj/gcc/xgcc and after strip: [psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++ -rwxrwxr-x. 1 psilva psilva 221K Ago 31 13:08 gcc/g++ -rwxrwxr-x. 1 psilva psilva 218K Ago 31 13:08 gcc/xgcc [psi...@joana obj]$ ls -lh ../../std_sort/obj/gcc/xgcc ../../std_sort/obj/gcc/g++ -rwxrwxr-x. 1 psilva psilva 219K Ago 31 13:08 ../../std_sort/obj/gcc/g++ -rwxrwxr-x. 1 psilva psilva 216K Ago 31 13:08 ../../std_sort/obj/gcc/xgcc Both configurations are basically like this: [psi...@joana obj]$ gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/opt/gcc-in-cxx --disable-bootstrap --enable-checking --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20090828 (experimental) (GCC) -- P.
Re: [gcc-in-cxx] replacing qsort with std::sort
2009/9/1 Michael Matz : >> [psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++ >> -rwxrwxr-x. 1 psilva psilva 481K Ago 31 12:58 gcc/g++ >> -rwxrwxr-x. 1 psilva psilva 477K Ago 31 12:58 gcc/xgcc > > That's not the real compiler, only the compiler driver. Look for files > named cc1 (the C compiler) and cc1plus (the C++ compiler) :-) Ah... So the real numbers for stripped binaries are: -rwxrwxr-x. 1 psilva psilva 42M Ago 31 17:54 std_sort/obj/gcc/cc1plus -rwxrwxr-x. 1 psilva psilva 38M Ago 31 12:59 trunk/obj/gcc/cc1plus also: textdata bss dec hex filename 12174791 23020 986004 13183815 c92b47 std_sort/obj/gcc/cc1plus 11308791 546960 461684 12317435 bbf2fb trunk/obj/gcc/cc1plus -- P.
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
2009/9/10 Ralf Wildenhues : > * Pedro Lamarão wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST: >> 2009/8/26 Ralf Wildenhues: >> I think this is new in glibc 2.10, for the reasons given by Jason Merrill >> above. >> I've discussed this problem with Jerry Quinn before, and he had a >> tentative patch that worked for me. >> As I understand things, this patch is on hold waiting for a solution >> to the bootstrap comparison problem being discussed in another thread. >> >> I am waiting for a solution to these problems to continue work on the >> std::sort gcc-in-cxx subproject; keeping all these patches up to date >> with trunk is too difficult for me right now. >> Currently, I have a patch to an old revision of the trunk. > > Well, can you post the patch, or did I somehow miss it on the list? > I'd be particularly interested if it tries to fix the Autoconf test > in some sensible way. I don't have it with me right now, but the solution is basically to replace AC_CHECK_DECL(basename) with AC_CHECK_FUNC(basename) in configure.ac. -- P.
Some C++0x experiments
I've been doing some experimenting with gcc, more specifically to g++, and finally got something to actually work. Currently I have implemented in g++ the "Static Assertions" and the "Right Angle Brackets" C++0x features in g++. Those are the simplest ones that got into the working draft, or so I thought; it took me a while to learn the source code nevertheless. I just set up this page with patches and other stuff: http://mndfck.org/~pedro.lamarao/projects/c++0x/ I intend to try next to implement the "Delegating Constructors" feature. Any feedback is welcome! There is a lot of talk on "branches" in that page, but currently I'm working on a file:// Subversion repository. Soon I'll try (again) to put that one up in a public place. I'd like to eventually contribute these to the project; but feel it is very early, the next C++ standard itself is still far away from us. -- Pedro Lamarão
Re: Some C++0x experiments
Mike Stump escreveu: > On Jun 9, 2006, at 6:31 PM, Pedro Lamarão wrote: >> Currently I have implemented in g++ the "Static Assertions" and the >> "Right Angle Brackets" C++0x features in g++. Those are the simplest >> ones that got into the working draft > >> Any feedback is welcome! > > Well, I hope that you are able to do up the paperwork to contribute the > changes and to contribute them. From what I read in contribute.html I believe I should need a personal assignment and an employer disclaimer. I'm willing, and I think my employer won't mind. How should I proceed? -- Pedro Lamarão
Re: GCC 5 & modularity
Em 21/03/2012 08:58, Peter Dolding escreveu: If there is a grey area you have broken into modules wrong. Module based code has no grey. No grey equals less errors of person editing a file they think is exclusive to some part that turns out to be shared with another part so causing nasty failure. This seems a Game of Words [tm]. Of course a modularized system can have a grey area. You just pack all of your gray area files and call them "grey module" to satisfy the bureaucracy. There is no perfect taxinomy in this world. Searching for one is interesting; demanding one is useless. -- P.
__attribute__((packed)) and trivial types
With GCC 4.7 and the following program:
--
struct byte
{
unsigned char _;
byte () = default;
explicit operator unsigned char () { return _; }
};
struct wyde
{
unsigned short _;
wyde () = default;
constexpr wyde (unsigned short r) : _(r) { }
};
struct foo
{
byte one;
wyde two;
}
__attribute__((packed));
auto main (int argc, char * argv[]) -> int
{
foo f;
return 0;
}
--
I am receiving this warning:
../main.cpp:22:8: warning: ignoring packed attribute because of unpacked
non-POD field ‘wyde foo::two’ [enabled by default]
Should this decision be adjusted to take trivial types into account?
--
P.
Re: Switching to C++ by default in 4.8
On 04/04/2012 08:20 AM, Diego Novillo wrote: On 4/4/12 5:06 AM, Richard Guenther wrote: Btw, I think we should only start forcing C++ when 1) there is a branch/patch out that shows benefit from using C++. I previously mentioned that I'd like to see 2) a patch that _properly_ wraps a C++ class for consumption by our garbage collector (thus, not a hack that works for a specific case but infrastructure that we think will work for _all_ cases, including libstdc++ container use). My idea was to start with something like converting VEC() which would require dealing with GC. Is anyone currently working or this? I'm not experienced in the code base, but this project seems fascinating. -- P.
Re: RFC: -Wall by default
On 04/05/2012 11:29 AM, Gabriel Dos Reis wrote: this is drifting, but since we talking about teaching (which is part of my daytime job) On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar wrote: Wouldn't it be better in a "moderately basic programming course" to provide standard canned scripts that set things up nicely for students including the switches they need? you are assuming that all students have the same programming environement or that we can force them, or that the environment they are programming in can run "standard canned scripts that set things up". The reality is that far from these ideal situations. If people should be wrapped inside scripts which enable -Wall for them, just enable -Wall for them, right? Eclipse CDT and Visual Studio turn warnings on by default for new projects. You could ask them if anyone is requesting this default to be turned off. -- P.
Re: Switching to C++ by default in 4.8
2012/4/5 Diego Novillo > I will be, after the switch to C++ is done. Pedro, if you do have a > copyright assignment, feel free to start working on this. I suggest > creating a branch for this (I can handle that today). If you need > forms for the copyright assignment, let me know and I'll forward them > to you. (Second attempt, to avoid text/html in Gmail.) I think I have an appropriate copyright assignment for contributing to GCC -- recently, an old patch of mine was reused an applied. Perhaps I misunderstood some of the conditions and would have to submit more documentation this time. I'm not sure. I think I have a viable approach to refactor VEC into a template class while keeping all files intact. The only implication is changing CC_FOR_BUILD to use COMPILER etc. Perhaps someone wiser might want to do something better to ensure genflags etc. compile with C++. Whenever the branch is ready, or people want to review, or both, I can submit patches. -- Pedro Lamarão ∷ http://www.pedro.lamarao.nom.br/ "Sanity consists in the faculty of adjusting ideas in proper proportion." - Aleister Crowley
[cxx-conversion] is enable_if ok?
Hello, currently proposed C++ Coding Conventions imply a very strict weird-is-forbidden style, which I like. But if defining new templates should in general be avoided, I'm unsure what is the best path in converting VEC. VEC interface optimizes element acessors to copy primitive types and point-to object types. If VEC is to be a template class, default accessors in C++ would naturally return a (const-)reference-to anything. It would be possible to optimize accessors to return a copy instead of a const-reference-to with enable_if. All this would allow VEC to be mostly just one thing, with small variations in corresponding to VEC_last and VEC_index. Since enable_if is not part of C++98, it would be added to GCC itself -- perhaps in namespace gcc. This decision will not block work in the branch, of course -- VEC can be converted first unoptimized and then reoptimized with whatever tricks are allowed. -- P.
Re: [cxx-conversion] is enable_if ok?
On 04/14/2012 05:07 PM, Jonathan Wakely wrote: On 14 April 2012 20:55, Pedro Lamarão wrote: Since enable_if is not part of C++98, it would be added to GCC itself -- perhaps in namespace gcc. libstdc++ provides __gnu_cxx::__enable_if in When vec.h is compiled in stage1 by the host compiler, can we include the file you mention? Or perhaps the suggestion is to optimize with enable_if only after stage1? -- P.
