Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
David Brown writes: > If the compiler can generate fractional arithmetic code directly > from such expressions, then it is indeed a good step towards > implementing such types as a pure C++ class without needing to use > compiler extensions. ... > I am not saying the compiler couldn't generate optimal code (on a > target with hardware support for these operations) out from > carefully written generic C++ code - but I do think it would be > easier to get good code if the compiler views these types as > "native". Of course, even if a special compiler representation turns out to be necessary for optimal performance, that doesn't mean that the _syntax_ has to be something wacky (whereas C has little choice). It would be perfectly reasonable to have the public interface be a thin library wrapper around unadvertised builtin types -- and that's probably quite preferable as it would enable a portable pure library solution for compilers that do not contain special support. -Miles -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Re: transactional-memory branch has been merged into trunk
The merge breaks bootstrap in 3 different ways (at least) on x86_64-darwin11: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031 FX
Re: implementation of std::thread::hardware_concurrency()
Hi Jonathan. I test your patch on OpenBSD-5.0 and mingw. Everywhere works correctly. Regards, niXman.
gcc vs. glibc bootstrapping of libgcc_eh.a
I've run into a bootstrapping issue which I'd like to solve "the right way", instead of continuing to hack around it. Briefly: I can't build glibc without libgcc_eh.a, which is provided by gcc. However, libgcc_eh.a is not built, unless I configure gcc with --enable-shared. But doing so causes gcc to attempt to build libgcc_s.so, which fails because it wants to link to libc.so, which hasn't been built yet. And so it goes The "obvious" fix, to me, is to change the libgcc/Makefile.in to always build libgcc_eh.a (and install it) Would such a patch be acceptable? BTW, this is for the "hexagon" architecture, being cross-built. Perhaps there's some other work-around that I missed... (our current work-around is to build uClibc first, install that, and then finish building gcc, then build glibc. Seems pretty yucky to me.) --linas
Troubleshooting with gcc 4.6
Hi everyone, I recently updated my Ubuntu 10.10 to 11.10 and since then I have been having problems with my compiler. I have seen that this new Ubuntu distribution uses gcc 4.6 whilest my old 10.10 used gcc 4.4.5 or 4.4.6. The main problem I have nowadays is with the math.h library when I need to use functions as sqrt() or pow() that I used to use without any problem in the old distribution (well, I had to write the -lm option when I tried to compile my source files but it did run perfectly). Today I'm getting and unresolve refernce to 'sqrt' when I comile my files even though I'm using the -lm option. Can anyone help me? Thanks, Santi Sabaté NOTE: I'm using the Netbeans 7.0.1 IDE
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
On Wed, 9 Nov 2011, Linas Vepstas wrote: > I've run into a bootstrapping issue which I'd like to solve > "the right way", instead of continuing to hack around it. > > Briefly: I can't build glibc without libgcc_eh.a, which is > provided by gcc. However, libgcc_eh.a is not built, unless > I configure gcc with --enable-shared. But doing so causes > gcc to attempt to build libgcc_s.so, which fails because it > wants to link to libc.so, which hasn't been built yet. And > so it goes The usual approach involves building three compilers and configuring glibc twice. http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/EGLIBC.cross-building?revision=2037 NB this involves EGLIBC features not in FSF glibc to make bootstrapping easier. For FSF glibc you may need to use a config.cache with libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes in it (both times you configure glibc), for the initial headers installation install bits/stdio_lim.h manually and also create gnu/stubs.h manually. It would be good to be able to configure GCC just once, build the compilers just once and have separate targets to configure/build/install the initial version of libgcc (before target headers and libc.so are available) and then the full set of target libraries (one install would install compilers and minimal libraries, later install would replace them with the final builds of the libraries). I'm not sure if the toplevel libgcc transition (a prerequisite of such a feature) is now far enough along for that, but an obvious complication would be the various cases where the compiler's configure script looks into the sysroot's headers to determine how to configure the compiler; you'd need to make sure all the defaults are right for new glibc. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
Hi Joeseph, On 9 November 2011 11:39, Joseph S. Myers wrote: > On Wed, 9 Nov 2011, Linas Vepstas wrote: > >> I've run into a bootstrapping issue which I'd like to solve >> "the right way", instead of continuing to hack around it. >> >> Briefly: I can't build glibc without libgcc_eh.a, which is >> provided by gcc. However, libgcc_eh.a is not built, unless >> I configure gcc with --enable-shared. But doing so causes >> gcc to attempt to build libgcc_s.so, which fails because it >> wants to link to libc.so, which hasn't been built yet. And >> so it goes > > The usual approach involves building three compilers and configuring glibc > twice. > > http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/EGLIBC.cross-building?revision=2037 > > NB this involves EGLIBC features not in FSF glibc to make bootstrapping > easier. For FSF glibc you may need to use a config.cache with > > libc_cv_forced_unwind=yes > libc_cv_c_cleanup=yes > > in it (both times you configure glibc), for the initial headers > installation install bits/stdio_lim.h manually and also create gnu/stubs.h > manually. I'll try that. Currently, even an infinite number of gcc/glibc rebuilds didn't get me out of this bootstrapping loop, and yes, I was building against FSF not eglibc. I know that the current FSF policy is to support only the major arches, but I'd like to see the FSF code fix up bootstrapping issues like this. --linas
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
On 11/9/2011 12:28 PM, Linas Vepstas wrote: I've run into a bootstrapping issue which I'd like to solve "the right way", instead of continuing to hack around it. Briefly: I can't build glibc without libgcc_eh.a, which is provided by gcc. However, libgcc_eh.a is not built, unless I configure gcc with --enable-shared. But doing so causes gcc to attempt to build libgcc_s.so, which fails because it wants to link to libc.so, which hasn't been built yet. And so it goes The "obvious" fix, to me, is to change the libgcc/Makefile.in to always build libgcc_eh.a (and install it) Would such a patch be acceptable? BTW, this is for the "hexagon" architecture, being cross-built. Perhaps there's some other work-around that I missed... (our current work-around is to build uClibc first, install that, and then finish building gcc, then build glibc. Seems pretty yucky to me.) Take a look at the "gcc and glibc from scratch" section of http://www.tilera.com/scm/source.html . I don't know if this will handle your problem, but we do end up with libgcc_eh.a when the dust settles, and it avoids having to build uClibc :-) -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: GCC 4.7.0 Status Report (2011-11-08), Stage 1 is over, Stage 3 in effect immediately
On Tue, 8 Nov 2011, Jakub Jelinek wrote: > during the last minute, patches submitted during stage1 > may be still accepted, if they don't need significant rewrites, > but please try to get them in soon. Otherwise only bugfixes > and documentation fixes are allowed for the trunk. To be clear since we have several new ports out there: new ports are generally low-risk if they don't require significant changes to target-independent code beyond the standard bits such as config.gcc that are listed in doc/sourcebuild.texi, and can often go in even in stage 4. I believe we currently have at least the CR16, Tile and RL78 ports pending, plus the resurrection of the Interix OS port. I believe all four (or five, since Tile is really two ports) of those ports currently need the people submitting them to send new versions against current trunk that address the most recent review comments - and to be pinged as needed until reviewed. (Take care to ensure they are updated for all the libgcc build system changes that have gone in recently.) If maintainers haven't been explicitly proposed to the SC for these ports, they should be (although a port may sometimes go in without a maintainer being approved - I think the SC are still considering Epiphany maintainership - and depending on the author's GCC experience they may not always be approved as a maintainer initially until they have a reasonable record of good patches). -- Joseph S. Myers jos...@codesourcery.com
[GCC steering committee] RL78 port maintainership
I would like to propose myself as the RL78 GCC port maintainer. The RL78 GCC port is currently being reviewed, and the corresponding binutils port has been accepted. In addition to being the primary author of this port, I also have RL78 hardware to test against and an extensive history with Renesas parts in general. Thanks, DJ
Re: [GCC steering committee] RL78 port maintainership
Yes. On 11/09/2011 12:26 PM, DJ Delorie wrote: I would like to propose myself as the RL78 GCC port maintainer. The RL78 GCC port is currently being reviewed, and the corresponding binutils port has been accepted. In addition to being the primary author of this port, I also have RL78 hardware to test against and an extensive history with Renesas parts in general. Thanks, DJ -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: [GCC steering committee] RL78 port maintainership
> Yes. Thanks! /me wishes all his reviews went this quickly... ;-)
Re: [GCC steering committee] RL78 port maintainership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/11 11:35, DJ Delorie wrote: >> Yes. > > Thanks! > > /me wishes all his reviews went this quickly... ;-) BTW, I forwarded the request to the committee... Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuspwAAoJEBRtltQi2kC7X+AH/33/nnmVcZ7oLRvnw05WeoKA qsA8973bZLhYQzrAXDJ36u7hXvqHne/Ypo09mvEpPpnXd/y+uk36KZuOpD5gqGqp bs87UIvKJVk+omVtnAMoTB9Tfv+gMhjoqGciXG0+2ED3Qbk5mDtbgdpbsUDvBBZI bk+k8ePWSZT9wcrGnaCdafYXMYVvxuY/R55j43NAildX8gpjignJrpSV2yxMHce2 AzUMx/vaZ7oRMms5kjpTX+wOVHvXKTpXWyqdVhEEuDOD/RBhYggl0U6UA0FR8ujN O86CsdXLaYSKUuAP8fZ8y8Nhb0guCS2ciJvLKXxwTk/tFvR18Hjmot95ZngORnU= =D0Xq -END PGP SIGNATURE-
Re: Troubleshooting with gcc 4.6
santi writes: > I recently updated my Ubuntu 10.10 to 11.10 and since then I have been > having problems with my compiler. I have seen that this new Ubuntu > distribution uses gcc 4.6 whilest my old 10.10 used gcc 4.4.5 or > 4.4.6. > > The main problem I have nowadays is with the math.h library when I > need to use functions as sqrt() or pow() that I used to use without > any problem in the old distribution (well, I had to write the -lm > option when I tried to compile my source files but it did run > perfectly). Today I'm getting and unresolve refernce to 'sqrt' when I > comile my files even though I'm using the -lm option. This question is not appropriate for the mailing list gcc@gcc.gnu.org. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. When asking a question of this sort, it helps a lot if you show us precisely what you did and precisely what happened. Without seeing that, I am going to guess that you are running into multiarch libraries. Debian, and therefore Ubuntu, decided to move the system libraries from the locations where all GNU/Linux distros have put them for many years. They have updated their own versions of gcc, but the mainstream gcc releases have not been updated. This is going to be an ongoing problem for many years for people who use Debian or Ubuntu. I do not know how to resolve it. Ian
Re: template class with default parameter in template parameter declaration
On Tue, 8 Nov 2011, Marc Glisse wrote:
On Tue, 8 Nov 2011, Ulrich Drepper wrote:
Complicated title, here's a bit of code:
#ifdef FIX
# define PARM2 , class T5
#else
# define PARMS2
#endif
template
struct cl1 {
};
template class T4 = cl1>
struct cl2 {
};
cl2<> var;
If compiled without FIX defined this will fail with gcc 4.3 and later.
Haven't checked 4.2 but it works without the fix with gcc 4.1. The
strange thing is that it also worked with ancient compilers before the
C++ frontend rewrite (gcc 3.2). In short, when a expecting a template
class in a template parameter list it now is not possible anymore to
skip the default parameters. Since this is an actual use of the class
(in case the default is used) and the programmer declares to have no
interest in the type of the second template parameter I wouldn't say
it is needed but I haven't tracked a statement in the standard.
Before changing too much code I want to make sure this new and very
old behavior is what is required by the standard and not a bug which
slipped in again.
It is announced in:
http://gcc.gnu.org/gcc-4.2/changes.html
It broke quite a bit of code (in particular with std::vector as cl1), but
there were some exotic pieces of legal code that were broken by this
extension, so it had to go.
Notice that in C++11 mode, g++ accepts:
#include
template class V> struct A {
typedef V T;
};
int main(){
A::T t;
}
where it matches vector as V having 2 parameters but lets you use it with
one. Don't know if you can rely on it though.
--
Marc Glisse
building trunk fails due to C++
With top of tree, I'm seeing % ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \ --disable-libmudflap --disable-bootstrap % gmake libtool: compile: g++ -B/usr/home/kargl/work/i386-unknown-freebsd10.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd10.0/lib/ -isystem /usr/home/kargl/work/i386-unknown-freebsd10.0/include -isystem /usr/home/kargl/work/i386-unknown-freebsd10.0/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc4x/libitm -I../../../gcc4x/libitm/config/x86 -I../../../gcc4x/libitm/config/posix -I../../../gcc4x/libitm/config/generic -I../../../gcc4x/libitm -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -march=i486 -mtune=i386 -fomit-frame-pointer -Wall -pthread -Werror -fabi-version=4 -g -O2 -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c ../../../gcc4x/libitm/aatree.cc -fPIC -DPIC -o .libs/aatree.o cc1plus: error: unrecognized command line option "-std=gnu++0x" gmake[4]: *** [aatree.lo] Error 1 gmake[4]: Leaving directory `/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd10.0/libitm' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd10.0/libitm' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd10.0/libitm' gmake[1]: *** [all-target-libitm] Error 2 gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x' gmake: *** [all] Error 2 Please fix. -- Steve
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
comes up every few years http://sourceware.org/ml/libc-help/2011-08/msg00073.html -mike signature.asc Description: This is a digitally signed message part.
