re: ggdb3 information lost using temporary preprocessed file
You might want to file a bug at http://gcc.gnu.org/bugzilla/ for this.
re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
Ganesh wrote: I work in a company where we have been using gcc-2.95.4 (based cross compiler) for compiling our code. Most of the code is written in c++ and makes extensive use of the stl libraries. We would not be changing our operating system or processor architecture (so portability is not a very good reason to give). [Compiling with gcc-3.x is quite painful. Why should we migrate to a newer gcc? How would you convince someone to?] We went through exactly this. In our case, what convinced everyone was "it runs our app faster" and "we can get bugs fixed". You have to back up that first claim with benchmarks, though! We couldn't prove newer gcc's were faster until gcc-4.1 and until we replaced most uses of std::string with a faster variant (sadly, gcc-4.1's STL is slower than gcc-2.95.3's in some ways; maybe gcc-4.3 will fix that?). The transition is long and hard. You will probably need to port key portions of your codebase yourself to get your benchmarks to run. Having an automated nightly build, and automatically sending out emails to people who check in things that don't compile with the newer gcc is important, otherwise it'll be hard to get your codebase to a clean enough state for an orderly switchover. http://kegel.com/gcc/gcc4.html has some tips for people dealing with the many syntax errors. I wouldn't recommend moving to gcc-3.x, really. It turns out not to save too much effort in the end... - Dan Fun footnote: at the gcc summit in 2004, I mentioned I was going to migrate a large codebase to gcc-3.x, and people said it was refreshing to see such optimism and bravery :-) It turned out to be a lot more work than I bargained for! -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: GCC generating invalid assembly
[EMAIL PROTECTED] wrote: I compiled unexec.c from Emacs 21.3 with -O2, and I got the error from GNU as on line 1498: Fatal error: C_EFCN symbol out of scope I'm on the x86. This only happens if all three of the following are satisfied 1) -gcoff debugging information is being generated 2) -funit-at-a-time is on 3) -O is on Turning off -O caused it to work fine. Turning off -funit-at-a-time caused it to work fine. Using a diffrent debugging information format caused it to work fine. You forgot to say which version of gcc. Is this maybe http://gcc.gnu.org/PR9963 ? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
ICE in gcc-4.0-20050305 for m68k
I tried building glibc-2.3.4 for m68k-unknown-linux-gnu with gcc-4.0-20050305, and the compiler fell over in iconv/skeleton.c: In file included from iso-2022-cn-ext.c:657: ../iconv/skeleton.c: In function 'gconv': ../iconv/skeleton.c:801: internal compiler error: output_operand: invalid expression as operand ... make[2]: Leaving directory `...build/m68k-unknown-linux-gnu/gcc-4.0-20050305-glibc-2.3.4/glibc-2.3.4/iconvdata' I'll post a proper problem report when I get a chance, this is just a little heads-up. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
PCH and moving gcc binaries after installation
Moving an installed gcc/glibc crosstoolchain to a different directory was not allowed for gcc-2.96 and below, I seem to recall, but became permissible around gcc-3.0. (Sure, there are still embedded paths, but they don't seem to be used in practice. I don't really trust it, but that's what I observed.) That sound right? OK, so what's the story with PCH? Does it break the above assumption? I just looked through a gcc-3.4.2 install, and found something that looks like PCH files with embedded paths in e.g. /opt/crosstool/i686-unknown-linux-gnu/gcc-3.4.2-glibc-2.3.3/include/c++/3.4.2/i686-unknown-linux-gnu/bits/stdc++.h.gch/O2g Since I need to handle old versions of gcc, I'm going to code up a little program to fix all the embedded paths anyway, but I was surprised by the paths in the pch file. Guess I shouldn't have been, but now I'm a little less confident that this will work. Has anyone else tried it? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: PCH and moving gcc binaries after installation
Daniel Jacobowitz wrote: On Tue, Mar 29, 2005 at 10:37:33PM -0800, Dan Kegel wrote: Since I need to handle old versions of gcc, I'm going to code up a little program to fix all the embedded paths anyway, but I was surprised by the paths in the pch file. Guess I shouldn't have been, but now I'm a little less confident that this will work. Has anyone else tried it? I would guess that they're just debugging information. The PCH shouldn't care. Thanks, I'll give it a shot and see what happens. I'll probably write a little C program that finds all instances of the old installation prefix, scans forward in the file to figure out how the string is terminated (hopefully NUL for binary files, and whitespace or punctuation for ASCII files), replaces the old path with the new one, scoots anything between the path and the string termination down to fit, and fixes the string termination. If I'm lucky, there won't be any special cases, and I can do it without any particular knowledge of the files being fixed; the search-and-replace program shouldn't even care that the files it's modifying are gcc binaries and spec files. It shouldn't be needed for modern gccs, but it just feels wrong to leave the old path embedded in the binaries :-) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
Nick Rasmussen <[EMAIL PROTECTED]> wrote: I'm running into an ICE in the prerelease, that is proving to be very difficult in reducing to a small testcase. If I preprocess the source (via -E or -save-temps) the code successfully compiles. > ... Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Comment #4 in http://gcc.gnu.org/PR20629 makes it looks like they had the same sort of trouble reproducing from preprocessed source: "I'm still seeing this, but some info... a) I'm only seeing this with LANG=C, export LANG=en_US.UTF-8 and there is no crash b) compiling the dumped proprocessed code isn't crashing in either LANG" So maybe you are in fact running into the same issue. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
re: some problem about cross-compile the gcc-2.95.3
"zouq" <[EMAIL PROTECTED]> wrote: first i download the release the version of gcc-2.95.3, binutils 2.15, and i use the o32 lib, include of gcc3.3.3 . 1. compile the binutils and install it mkdir binutils-build; cd binutils-build; ../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux -v; make;make install; 2. cp -r ../../lib /opt/gcc/mipsel-linux/ cp -r ../../include /opt/gcc/mipsel-linux/ 3. compile the gcc mkdir gcc-build; cd gcc-build; ../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux --enable-languages=c -enable-shared -disable-checking -v; make; then the ERROR happened: ... as: unrecognized option `-O2' make[1]: *** [libgcc2.a] Error 1 Ah, you built binutils, but did you put them on your path? You need PATH=$PATH:/opt/gcc/bin before you configure gcc. Then it should pick up mipsel-linux-as from the path. But as Kai says, this isn't the list for this sort of question. You should take it to the crossgcc list http://sources.redhat.com/ml/crossgcc/ (where we will tell you to try http://kegel.com/crosstool :-) or the etux list http://www.embeddedtux.org/mailman/listinfo/etux (which is explicitly for people who don't like using canned scripts like crosstool. In other words, for people like Kai :-) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: C++ ABI mismatch crashes
Mike Hearn <[EMAIL PROTECTED]> wrote: I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4 based system. All of the C++ libraries it links directly against, like GTKmm, are statically linked. In other words, it dynamically links against no C++ libraries. Inkscape dlopens libgtkspell, which in turn dlopens libaspell (to add a spelling checker). libgtkspell is written in C, but libaspell is written in C++ and exposes a C interface. This causes a crash ... Note that on the first line libaspell is being bound to libstdc++.so.6, which is what I'd expect as libaspell is compiled using gcc 3.4 - and indeed up until this point it's been linked only against libstdc++.so.6. Then for some reason it's linked against libstdc++.so.5, for the following symbol: _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_ [I'm going to regret posting in a hurry, but here goes:] Hmm! Quick question: if you rebuild libaspell (with the same version of g++ as it was built before) to link in the C++ library statically, does that fix the crash? One possible conclusion we could draw might be "Libraries that export only C APIs but are written in C++ should be statically linked against the C++ standard library. Once the gcc C++ ABI stabilizes, i.e. once all the remaining C++ ABI compliance bugs have been flushed out of gcc, this requirement can be relaxed." But I can't shake the feeling that it's crazy that libaspell got linked against two different C++ libraries. Can you try creating a minimal test case demonstrating this without involving inkscape? If so, maybe it's a glibc shared library loader bug? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Problems with MIPS cross compiling for GCC-4.1.0...
Steven J. Hill wrote:
While I am getting closer to full toolchain build, GCC-4.1.0 is still
not behaving the way it should. Below is the output that I am running
up against. I attempted to define a stack variable to hold the value
of zero and tried using that instead of the actual value, but nothing
worked. I had a similar problem with 'do_waitid' and I have attached
the patch just for the sake of discussion. Does anyone have some
insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2
kernel headers and gcc-4.1.0-20050418. Thanks.
../sysdeps/unix/sysv/linux/waitid.c: In function 'do_waitid':
../sysdeps/unix/sysv/linux/waitid.c:52: error: memory input 6 is not directly
addressable
../sysdeps/unix/sysv/linux/waitid.c:55: error: memory input 6 is not directly
addressable
diff -ur glibc-2.3.4/sysdeps/unix/sysv/linux/waitid.c
glibc-2.3.4-patched/sysdeps/unix/sysv/linux/waitid.c
--- glibc-2.3.4/sysdeps/unix/sysv/linux/waitid.c2004-10-30
13:01:02.0 -0500
+++ glibc-2.3.4-patched/sysdeps/unix/sysv/linux/waitid.c2005-04-18
19:01:28.334689002 -0500
@@ -47,12 +47,14 @@
do_waitid (idtype_t idtype, id_t id, siginfo_t *infop, int options)
{
static int waitid_works;
+ struct rusage *sim = NULL;
+
if (waitid_works > 0)
-return INLINE_SYSCALL (waitid, 5, idtype, id, infop, options, NULL);
+return INLINE_SYSCALL (waitid, 5, idtype, id, infop, options, sim);
if (waitid_works == 0)
{
int result = INLINE_SYSCALL (waitid, 5,
- idtype, id, infop, options, NULL);
+ idtype, id, infop, options, sim);
Perhaps INLINE_SYSCALL needs some work to be gcc-4 compatible?
(tap tap tap)
Yep. Check out the recent changes in
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/mips/mips32/sysdep.h?cvsroot=glibc
I bet applying
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/mips/mips32/sysdep.h.diff?r1=1.2&r2=1.3&cvsroot=glibc
and maybe the next one
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/mips/mips32/sysdep.h.diff?r1=1.3&r2=1.4&cvsroot=glibc
will cure what ails ye.
- Dan
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
Re: Interprocedural Dataflow Analysis - Scalability issues
Daniel Berlin wrote: I am working on interprocedural data flow analysis(IPDFA) and need some feedback on scalability issues in IPDFA. Firstly since one file is compiled at a time, we can do IPDFA only within a file. For starters, we're working on this. (I was curious, so I searched a bit. It looks like gcc-4.0 supports building parts of itself in this mode? Though only C and Java stuff right now, not C++. Related keywords are --enable-intermodule (see the thread http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01146.html) --enable-libgcj-multifile (see http://gcc.gnu.org/ml/java-patches/2003-q3/msg00658.html) and IMI. It seems that just listing multiple source files on the commandline is enough to get it to happen?) But that would prevent us from doing analysis for funcitons which are called in file A, but are defined in some other file B. You just have to make conservative assumptions, of course. You almost *never* have the whole program at once, except in benchmarks :) True, but hey, if you really need that one server to run fast, you might actually feed the whole program to the compiler at once. Or at least a big part of it. Morever even if we are able to store information of large number of functions, it would cost heavily in memory, and threfore non scalable. Uh, not necessarily. Speaking as a user, it's ok if whole-program optimization takes more memory than normal compilation. (Though you may end up needing a 64 bit processor to use it on anything really big.) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: GCC 4.1: Buildable on GHz machines only?
Peter Barada wrote: The alternative of course is to do only crossbuilds. Is it reasonable to say that, for platforms where a bootstrap is no longer feasible, a successful crossbuild is an acceptable test procedure to use instead? A successful crossbuild is certainly the minimum concievable standard. Perhaps one should also require bootstrapping the C compiler alone; that would provide at least some sanity-checking. Unfortunately for some of the embedded targets(like the ColdFire V4e work I'm doing), a bootstrap is impossible due to limited memory and no usable mass-storage device on the hardware I have available, so hopefully a successful crossbuild will suffice. How about a successful crossbuild plus passing some regression test suite, e.g. gcc's, glibc's, and/or ltp's? Any one of them would provide a nice reality check. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: GCC 4.1: Buildable on GHz machines only?
Peter Barada wrote: Unfortunately for some of the embedded targets(like the ColdFire V4e work I'm doing), a bootstrap is impossible due to limited memory and no usable mass-storage device on the hardware I have available, so hopefully a successful crossbuild will suffice. How about a successful crossbuild plus passing some regression test suite, e.g. gcc's, glibc's, and/or ltp's? Any one of them would provide a nice reality check. I'm open to running them if there's a *really* clear how-to to do it that takes into account remote hardware. I'm not sure it qualifies as *really* clear, but my doc on doing remote gcc and glibc test runs is at http://kegel.com/crosstool/current/doc/crosstest-howto.html Have you tried that yet? It worked for me on systems with 16 MB of RAM and a network connection. I bet it'd work with less RAM if you ditched the glibc tests. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: libgcc_s.so.1 exception handling behaviour depending on glibc version
[EMAIL PROTECTED] wrote: > [ Things break horribly when I compile them > with a compiler built against glibc-2.3.x > and try to run them on a glibc-2.2.x system. ] This is expected and normal. gcc and glibc have circular dependencies. A gcc tainted with a newer glibc is expected to produce binaries that don't work with older glibc's. Mike Hearn wrote: This policy of not supporting "build on newer, run on older" is a massive pain for developers who distribute Linux binaries even though it's very common: developers often use very new distributions but users often don't. It requires all kinds of stupid hacks to work around. No hacks needed; you just have to embrace reality. As Marcin Dalecki and others pointed out, one way to ship software that needs to run on a range of gcc and glibc versions is to build against the lowest common denominator, either by cross-compiling (in which case http://kegel.com/crosstool is your friend) or by actually building on the older system (in which case http://thomas.apestaart.org/projects/mach/ might be your friend; I haven't used it myself). Another way will be LSB, once it makes the leap forward to the gcc-3.4 ABI for C++. (Did you know that gcc-4.0 uses the gcc-3.4 ABI for C++, too? That's right, there is hope!) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Reporting bugs: there is nothing to gain in frustrating reporters
Scott Robert Ladd wrote: Mark has a valid concern: Why aren't bugs being fixed? One answer is: The GCC community is often less than welcoming, friendly, and helpful. You may not like or believe the answer, but if you want more people to help GCC for free, an attitude adjustment may be required on your part. It's not as if there aren't many other challenging projects for people to participate in. I'm a bug reporter, usually not a bug fixer, and I don't get the feeling that the gcc developers are being rude. The 27 issues I've reported have been dealt with professionally and reasonably. (A few have languished unfixed, but those bugs aren't critical, and it hasn't bothered me too much. And to be fair, I'm sitting on fixes sent me by the gcc developers I've been too busy to verify, so really, I wouldn't have a leg to stand on even if I wanted to complain!) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Reporting bugs: there is nothing to gain in frustrating reporters
Scott Robert Ladd wrote: I have ample evidence that many people feel that the GCC developer community is not very welcoming. I haven't found this to be the case. Perhaps that's because I try to control my urge to post frequently (oops, guess I'm screwing up here!), and because I try hard to come up with minimal test cases when I have problems to report. 1) Bugmasters could be less perfunctory and pejorative in their comments. Examples have been given. Politeness is always a good idea. However, if you poke a bear with a stick often enough, he will growl. If you tell a gcc developer over and over he is wrong, for instance, I think it's understandable for him to becom cross. In any big project, there will always be developers who are sometimes cross and impolite (e.g. certain library maintainers who shall remain nameless) but do stellar work in general. When you run into such a bear, it's best to just grit your teeth, remain polite, and be thankful he's contributing to the project. 2) A mentoring system could help bring along new GCC developers. I'm not talking about hand-holding, I'm suggesting that having some place for people to ask a few questions, one on one, to get over certain conceptual humps. What about the IRC channel mentioned earlier, posted prominently at the top of http://gcc.gnu.org/wiki ? And then there's the GCC summit, if you're really serious. 3) To keep Steven's bloodpressure down, I suggest a new mailing list, gcc-design, where engineers like myself can propose designs and concepts without upsetting those who find such discussions annoying. I think what gets peoples' blood pressure up is endless discussion about how they ought to do their business. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
re: [RFC] gcov tool, comparing coverage across platforms
We are a group of undergrads at Portland State University who accepted as our senior capstone software engineering project a proposed tool for use with gcov for summarizing gcov outputs for a given piece of source code tested on multiple architecture/OS platforms. A summary of the initial proposal is here: http://www.clutchplate.org/gcov/gcov_proposal.txt A rough overview of our proposed design is as follows: We would build a tool which would accept as input: on the command line, paths to each .gcov file to be included in the summary, each of these to be followed by a string which would be the platform identifier for that .gcov file. The .gcov files would be combined so that the format would parallel the existing output, with the summarized report listing each line of the source once, followed immediately by a line for each platform id and the coverage data for that platform. Sounds like a fun project. Rather than taking the path to each .gcov file on the commandline, you might consider searching from them, as lcov does. Come to think of it, maybe you could steal some ideas or even code from lcov. See http://ltp.sourceforge.net/coverage/lcov.php ltp is written in perl, for what it's worth. I like using Bourne shell for projects it's a good fit for, but you may find yourself needing something like perl, since you'll be wrangling lots of files and lots of text. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: A trouble with libssp in one-tree builds
Daniel Jacobowitz wrote: I think we need to finally come up with a way to build the compiler and libraries at different times. Don't tease me. -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517
I can't build gcc-4.1-20050709 for target arm; it fails with
gcc-4.1-20050709/libiberty/cp-demangle.c: In function 'd_print_comp':
gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in
loop_givs_rescan, at loop.c:5517
Compiling the same version of gcc for i686 manages
to avoid that error somehow, but it pops up later
building the Linux kernel:
mm/page_alloc.c: In function 'setup_per_zone_lowmem_reserve':
mm/page_alloc.c:1940: internal compiler error: in loop_givs_rescan, at
loop.c:5517
Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:
{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
Sigh. I'll file bugs with preprocessed source tomorrow.
Stage 3 is certainly starting with a bang.
- Dan
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
Re: gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517
Falk Hueffner wrote:
Dan Kegel <[EMAIL PROTECTED]> writes:
Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:
{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
This doesn't really sound like a gcc bug, rather like an invalid asm,
or bad options passed to as. But it's impossible to tell without a
test case.
I'll try to post one today for that and for the sparc ICE below.
For those trying to keep score, here are all the ICEs I run into with
4.1-20050709.
Three have PRs already, and one appears to be new:
No PR yet?:
sparc-gcc-4.1-20050709-glibc-2.3.2:
arch/sparc/kernel/process.c:204: internal compiler error: in compare_values,
at tree-vrp.c:445
http://gcc.gnu.org/PR22384 :
arm-gcc-4.1-20050709-glibc-2.3.2
arm-xscale-gcc-4.1-20050709-glibc-2.3.2
arm9tdmi-gcc-4.1-20050709-glibc-2.3.2:
gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in
loop_givs_rescan, at loop.c:5517
i686-gcc-4.1-20050709-glibc-2.3.2
mm/page_alloc.c:1940: internal compiler error: in loop_givs_rescan, at
loop.c:5517
http://gcc.gnu.org/PR22379 :
mips-gcc-4.1-20050709-glibc-2.3.2
mipsel-gcc-4.1-20050709-glibc-2.3.2
powerpc-405-gcc-4.1-20050709-glibc-2.3.2
powerpc-750-gcc-4.1-20050709-glibc-2.3.2
powerpc-860-gcc-4.1-20050709-glibc-2.3.2
powerpc-970-gcc-4.1-20050709-glibc-2.3.2
x86_64-gcc-4.1-20050709-glibc-2.3.2:
drivers/char/random.c:1813: internal compiler error: in
cgraph_early_inlining, at ipa-inline.c:990
http://gcc.gnu.org/PR22258
sh4-gcc-4.1-20050709-glibc-2.3.2:
libstdc++-v3/include/ext/bitmap_allocator.h:1085: internal compiler error: in
spill_failure, at reload1.c:1889
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel
Falk Hueffner wrote:
Dan Kegel <[EMAIL PROTECTED]> writes:
Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:
{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
This doesn't really sound like a gcc bug, rather like an invalid asm,
or bad options passed to as. But it's impossible to tell without a
test case.
OK, I extracted a minimal test case. This is from compiling
arch/alpha/kernel/core_cia.c from linux-2.6.11.3 for alpha.
Works fine with gcc-4.0.1. Can somebody familiar with
inline assembly guess whether the source or the compiler are wrong here?
--- snip ---
inline unsigned int
cia_bwx_ioread8(void *a)
{
return ({ unsigned char __kir; __asm__("ldbu %0,%1" : "=r"(__kir) :
"m"(*(volatile unsigned char *)a)); __kir; });
}
--- snip ---
$ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
-mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c core_cia.i
/tmp/ccmvyEzr.s: Assembler messages:
/tmp/ccmvyEzr.s:16: Error: macro requires $at register while noat in effect
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
gcc-4.1-20050709: ICE in compare_values, at tree-vrp.c:445 (was: Re: gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517)
Dan Kegel wrote: sparc-gcc-4.1-20050709-glibc-2.3.2: arch/sparc/kernel/process.c:204: internal compiler error: in compare_values, at tree-vrp.c:445 Filed as http://gcc.gnu.org/PR22398 -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel
Paul Koning wrote: "Falk" == Falk Hueffner <[EMAIL PROTECTED]> writes: >> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \ >> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c >> core_cia.i Falk> I don't see any fault on gcc's side here. You could argue that Falk> the command line option for as should override the ".arch", but Falk> I think it's been like this forever. So you should probably Falk> just add ".arch ev6" inside the asm (annoyingly, gas doesn't Falk> seem to have ".arch any" or similar). More appropriate would be to make the command line consistent with the code. If there's inline assembly that requires ev6, then -mcpu=ev6 is appropriate. Conversely, if the code really is supposed to run on an ev5, then -Wa,mev5 is the right fix and the inline assembly should stick to instructions that exist on that machine. The code is in linux-2.6.*/asm-alpha/compiler.h. Inspection shows that the code really is supposed to run on an ev5; it uses the LDBU in inline assembly and expects the assembler to expand that to something that can run on ev4, which should work according to http://msdn.microsoft.com/library/en-us/aralpha98/html/load_byte_unsigned_ldbu.asp The problem is then the -Wa,-mev6. And voila, linux-2.6.*/arch/alpha/Makefile seems to add that unconditionally: # For TSUNAMI, we must have the assembler not emulate our instructions. # The same is true for IRONGATE, POLARIS, PYXIS. # BWX is most important, but we don't really want any emulation ever. CFLAGS += $(cflags-y) -Wa,-mev6 I'll punt this to the alpha linux kernel folks. Thanks for the help! - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel
Richard Henderson wrote: On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote: More appropriate would be to make the command line consistent with the code. If there's inline assembly that requires ev6, then -mcpu=ev6 is appropriate. No, this code is protected by various system checks. We want -mcpu=ev5 such that the kernel as a whole will run everywhere, but we require these specific instructions on specific ev56/ev6 systems for i/o. rth, can you eyeball the summary I posted at http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ? My limited understanding is that gcc is fine, no need to revert anything, but the linux kernel configury needs to stop doing -mcpu=ev5 -Wa,-mev6 for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions really aren't there on real ev5 machines, and passing -Wa,-mev6 keeps it from substituting a macro. (Or are there no pure ev5 machines in the world?) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel
Richard Henderson wrote:
On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:
No, this code is protected by various system checks.
We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
but we require these specific instructions on specific ev56/ev6 systems
for i/o.
rth, can you eyeball the summary I posted at
http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?
My limited understanding is that gcc is fine, no need to revert anything,
but the linux kernel configury needs to stop doing
-mcpu=ev5 -Wa,-mev6
for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
really aren't there on real ev5 machines, and passing
-Wa,-mev6 keeps it from substituting a macro.
Absolutely not. While one can argue about which in the gcc+binutils
pair is buggy, the kernel is *not* buggy.
Please re-read my problem description above, and recall that this is
for a GENERIC kernel, that runs on ALL alpha systems.
Maybe I'm missing something. include/asm-alpha/compiler.h says:
#if defined(__alpha_bwx__)
#define __kernel_ldbu(mem) (mem)
...
#else
#define __kernel_ldbu(mem) \
({ unsigned char __kir; \
__asm__("ldbu %0,%1" : "=r"(__kir) : "m"(mem));\
__kir; })
For -mcpu=ev5, the #else branch is taken, and the ldbu instruction
is given to the assembler, right?
And since arch/alpha/Makefile does
CFLAGS += $(cflags-y) -Wa,-mev6
unconditionally, real ldbu instructions are used instead of
the emulation. And that means that __kernel_ldbu(mem) won't
work on pure ev5 machines. Are you saying that __kernel_ldbu(mem)
is never called on pure ev5 machines, then?
Thanks,
Dan
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
Re: libstdc++ required binutils version [was: Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures]
Jonathan Wakely wrote: The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. ... and IMHO testresults look quite good except abi_check, don't they? i.e. do you mean updating binutils will resolve abi_check issue in libstdc++ testsuite? I'd assume yes, based on Benjamin's statement here: http://gcc.gnu.org/ml/libstdc++/2005-06/msg00132.html Does 2.16 satisfy the minimum requirement? This should be clearly spelled out in the doc. 2.15.90.0.1.1 is linux-only. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
gcc-4.1-20050702: ICE in force_decl_die, at dwarf2out.c:12618
I'm seeing the following two instances of the same ICE building a large app with gcc-4.1-20050702 for i686-linux: bits/stl_list.h:396: internal compiler error: in force_decl_die, at dwarf2out.c:12618 ext/rope:1469: internal compiler error: in force_decl_die, at dwarf2out.c:12618 If it still happens with the next snapshot, I'll submit a bug (unless someone tells me not to bother). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
gcc-4.1-20050702: ICE
I'm seeing the following ICE building a large app with gcc-4.1-20050702 for i686-linux: ext/mt_allocator.h:450: internal compiler error: in write_template_arg_literal, at cp/mangle.c:2228 If it still happens with the next snapshot, I'll submit a bug (unless someone tells me not to bother). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
gcc-4.1-20050702: ICE in write_template_arg_literal, at cp/mangle.c:2228
[resending - forgot to finish subject line before] I'm seeing the following ICE building a large app with gcc-4.1-20050702 for i686-linux: ext/mt_allocator.h:450: internal compiler error: in write_template_arg_literal, at cp/mangle.c:2228 If it still happens with the next snapshot, I'll submit a bug (unless someone tells me not to bother). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Need help creating a small test case for g++ 4.0.0 bug
"Paul C. Leopardi" <[EMAIL PROTECTED]> wrote: > So I seem to be left with a large ( >2.5MB ) preprocessed source file. Should > I try to report the bug using this large file as a test case? Sure. But you might want to try using an automated tool to reduce the test case first. There's one called delta (or maybe there are several by that name, I'm not sure) that can do it. I haven't tried them myself yet, but see: Original implementation: http://www.st.cs.uni-sb.de/dd/ http://programming.newsforge.com/article.pl?sid=05/06/30/1549248&from=rss http://www.stanford.edu/class/cs295/asgns/asgn1/asgn.pdf 2nd implementation?: http://www.cs.berkeley.edu/~dsw/ -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
ICE hunting in gcc-4.1
Geez, 'delta' from http://www.cs.berkeley.edu/~dsw really does seem to make it easy to track down near-minimal testcases for ICEs. It's tempting to continually beat the crap out of gcc-4.1 snapshots by compiling all the sources I can find, then for each ICE that occurs, using delta to find a minimal testcase, and reporting it to bugzilla if it's not already there. Would that be useful, or is it overkill? -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
re: [GCC 4.2 Project] Omega data dependence test
Sebastian Pop wrote: > [http://gcc.gnu.org/wiki/Omega%20data%20dependence%20test] > ... I can't understand a word of the proposal. Mabe you were trying to be funny, but it ended up being obscure. If the average gcc developer can understand it, then it doesn't matter that I can't, but I have a feeling others might find it hard to read, too. But this part caught my eye: In a further future, when GCC will finally have a proper intermediate representation that can be stored to disk and then loaded back to memory, we will transform the SEB into GCC contributors. The plan is to propose the integration of a delta debugger (DD) into GCC such that the regression flags will directly output a reduced pattern that will show the regression. A pattern-zilla will collect the optimal solution and a testcase that show the weakness of a heuristic function. Since I started playing with delta debugging for tracking down ICEs, I've been thinking it might be nice to have an option to gcc to perform delta debugging automatically if an ICE occurs, and have it automatically submit the minimized testcase. Sounds like you're talking about something similar, but not for ICEs. I wish I understood your proposal better. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
re: C++ vs. pthread_cancel
Peter Zijlstra <[EMAIL PROTECTED]> wrote: On this controversial subject, could somebody please - pretty please with a cherry on top - tell me what the current status is: - in general, - as implemented in the 3.4 series and - as implemented in the 4.0 series. At work we're using 3.4 and we have managed to shoot our foot of with this issue :-(, google gives a lot of hits on the issue but it is a bit hard to get the current impl. status for 3.4. Which in turn makes it hard to decide on how to bandage our foot. Could you provide a link to a description of the particular problem? I looked around, and all I could find was https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111548 I suppose the controversial part is that you're using pthread_cancel, which is somewhat frowned upon as inherently unsafe. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
missed-optimization issue count
For fun, I counted the number of open missed-optimization issues: all versions: 423 gcc-3.4.x: 55 gcc-4.0.x: 170 gcc-4.1-x: 93 It looks like many of them, even those filed four years ago, are getting some recent attention, which is encouraging. Thanks to everyone pushing these along. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
re: M16C development using GCC, Is It Possible?
> i am currently working on a project of building M16C programs. i have an IRA > M16C/I8C C/C++ compiler on hand, but it is for Windows and i just can not live > w/o my Linux box. Could you perhaps run the compiler under Wine?
re: Performance comparison of gcc releases
Ronny Peine wrote: >> > -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because >> > it leads to an endless loop in neural net in nbench. >> >> Could you fill a bug report for this one? > >Done. Your PR is a bit short on details. For instance, it'd be nice to include a link to the source for nbench, so people don't have to guess what version you're using. Was it http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz ? It'd be even more helpful if you included a recipe a sleepy person could use to reproduce the problem. In this case, something like wget http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz tar -xzvf nbench-byte-2.2.2.tar.gz cd nbench-byte-2.2.2 make CC=gcc-4.0.1 CFLAGS="-ftree-loop-linear" Unfortunately, I couldn't reproduce your problem with that command. Can you give me any tips? Finally, it's helpful when replying to the list about filing a PR to include the PR number or a link to the PR. The shortest link is just gcc.gnu.org/PR%d, e.g. http://gcc.gnu.org/PR25449 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: An odd behavior of dynamic_cast
[EMAIL PROTECTED] wrote: > [ Why doesn't dynamic_cast work when I dlopen a shared library? ] I think the right place for this question might have been gcc-help (http://gcc.gnu.org/ml/gcc-help/). Nevertheless, I think http://gcc.gnu.org/faq.html#dso should answer your question. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: conversion warnings in c++
Hi Eric! I agree, moving warnings on benign conversions to -Wconversion would help groups porting large codebases from earlier versions of gcc. As long as you're in that area, got any opinion on http://gcc.gnu.org/PR9072 ? -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: Patch policy for branches
Some projects have a time-based release strategy (e.g. "we release once every six months"). Would it make sense for gcc to do that for all maintenance releases? e.g. leave the current process the same for .0 versions, which users are scared of anyway, but coordinate all other releases to occur once per quarter? -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Upated memory hog patch for make
Gerald wrote: >On Wed, 1 Feb 2006, H. J. Lu wrote: >> My memory hog patch for make has 2 typos. This patch fixes them. >Thanks, H. J. What's the upstream status of your patches? I think they're in upstream (hopefully H.J. will confirm that). I know that the O(N^2) bug that Jeff Evarts found and fixed is in upstream. If you want to try, there's a release candidate out now: > From: [EMAIL PROTECTED] > Sent: 20 February 2006 04:25 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: GNU make 3.81rc1 released -- please test. > > Please find the first release candidate for GNU make 3.81, 3.81rc1, > available now for download from ftp://alpha.gnu.org/gnu/make: > > c907a044ebe7dff19f56f8dbb829cd3f > ftp://alpha.gnu.org/gnu/make/make-3.81rc1.tar.bz2 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Disabling pch checking?
gcc-4.1-rc1 seems nice so far - it's the first version of gcc that can beat gcc-2.95.3 on one particular app - but it seems to be slow at preprocessing C++ source. This matters quite a bit when running distcc. In fact, it seems to take three times as long to build large C++ apps as gcc-2.95.3 did. (Your milage may vary.) The app I measured this on has a rather large number of -I options, so there are lots and lots of stat calls looking for .h files, and lots and lots of stat calls looking for precompiled headers. We plan to get rid of most of the -I flags, but in the meantime, it'd be nice to be able to disable the stat for the pch (since we know we aren't using pch at all). Is there an option to do that? I couldn't see one in a quick scan. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Disabling pch checking?
On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote: > On Feb 23, 2006, at 9:05 PM, Dan Kegel wrote: > > it seems to be slow at preprocessing C++ source. > > This matters quite a bit when running distcc. > > One way to mitigate this would be to use a precompiled header, and > use -fpch-preprocess with distcc and ship the .gch across instead. That's painful to set up, though (it requires changing the application's source to be effective, doesn't it?) > You're not building on an nfs mount are you? If so, the first > order of business it to not do that. No nfs anywhere near this, and $DISTCC_DIR is pointing to a non-nfs directory. I guess I'll stop whining and measure whether comment out the stat that looks for .gch files provides any speedup. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Disabling pch checking?
On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote: > On Feb 24, 2006, at 1:25 PM, Dan Kegel wrote: > > That's painful to set up, though (it requires changing the > > application's source to be effective, doesn't it?) > > No. After reading http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Precompiled-Headers.html I get the impression that, to start using precompiled headers, the procedure is: 1) create a single all.h that includes all the needed .h's 2) precompile all.h 3) edit all your app's sources to include all instead of the individual .h's That sounds like a source change to me. Or am I misunderstanding how precompiled headers are usually used? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Request to become moderator of crossgcc mailing list
The crossgcc mailing list really needs some moderator lovin'. e.g. an address on the crossgcc mailing list is bouncing, and needs removal. Worse, the blurb at the bottom of each post has needed updating for the last four years or so. I seem to be one of the main players on that list these days, and I'm willing. Any chance I could become a moderator of the crossgcc list? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: GCC 4.1.0 Released
Mark wrote: > 1. GNU TAR 1.14 is required to unpack the source releases. Other > versions of tar are likely to report errors or silently unpack the > file incorrectly. Now hold on there, bubaloo. I thought the warnings from older versions of tar were benign. The warnings I'm seeing from tar-1.13.19 are tar: pax_global_header: Unknown file type 'g', extracted as normal file Searching for this error message, I find a quote from Linus Torvalds, (http://lkml.org/lkml/2005/6/18/5): >Yes, git creates tar-archives that use the extended pax headers, and I >think you need tar-1.14 to fully understand them. They should not hurt >(apart from the warning) on older versions of tar. > >The extended header just contains a hidden comment record that tells the >git commit ID that was used to generate the tar-tree. > >Because it's extracted as a regular file (instead of tar knowing that it's >a comment header), you will now have a file called "pax_global_header" >that has the contents > 52 comment=9ee1c939d1cb936b1f98e8d81aeffab57bae46ab > >in it (where "9ee1c939d1cb936b1f98e8d81aeffab57bae46ab" is the git SHA1 >name of the Linux-2.6.12 commit). > >So it's not entirely "harmless" in that it causes a bogus file to be >created, but it's not like it's a huge problem either, and that bogus file >actually does contain real information (although it's not useful unless >you're a git user). So perhaps the release notes should say 1. GNU TAR 1.14 is recommended to unpack the source releases. Other versions of tar may issue the warning tar: pax_global_header: Unknown file type 'g', extracted as normal file and/or silently create spurious files named 'pax_global_header'. These are artifacts reflecting the fact that the tarballs were created with git. Or something like that. Or is tar-1.14 really required? That would be highly annoying. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: GCC 4.1.0 Released
On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > > 1. GNU TAR 1.14 is required to unpack the source releases. Other > > > versions of tar are likely to report errors or silently unpack the > > > file incorrectly. > > The problem has nothing to do with warnings from tar, which are neither > errors nor silent failures. I believe a file either got skipped or > unpacked with the wrong name. Egads. Can you point me to more info? I've been building with older versions of tar without any problem beyond the warnings. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: gcc-4.0.3 released
http://gcc.gnu.org/gcc-4.0/changes.html#4.0.3 is missing a link to http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.0.3 with text This is the list of problem reports (PRs) from GCC's bug tracking system that are known to be fixed in the 4.0.3 release. ... This was done for the previous two releases, and it's a nice touch. Can someone make the change? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: 100x perfomance regression between gcc 3.4.5 and gcc 4.X
Is there a bugzilla entry describing the bug Richard is fixing? If not, it'd be nice to have, if for no other reason than it would show up naturally when people look for bugs fixed in gcc-4.1.1. I can create one, but it'd be better if someone actually involved in the action did. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: Any resolution to the C++ symbol conflict problems?
Mike Hearn wrote: > [So, what does > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660 > Versioning weak symbols in libstdc++ > mean for ISVs? Will it solve the backwards compatibility problems > mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405 ? How?] I'd love to know, too. I gather that this stuff is disabled unless you configure with --enable-symvers=gnu-versioned-namespaces Presumably this won't be on by default in gcc-4.2, since no ABI breakage was planned for that release, but perhaps it'll be on by default in gcc-4.3 (along with libstdc++-v7 and non-COW strings and all that stl-ABI-changing goodness that makes my favorite app run several percent faster)? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: Toolchain relocation
Hi Dave. I hope you find and squash the relocation bug the right way, but until then, perhaps you could use my cheezy program that fixes embedded paths in gcc toolchains. It's at http://kegel.com/crosstool/current/fix-embedded-paths.c I haven't tested it on mingw toolchains, so some assembly may be required. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: Summer of Code: proposal to participate with Partial Transitions
Eder wrote: Partial Transitions[http://gcc.gnu.org/wiki/Partial%20Transitions] called my attention. I am very interested in submitting a project for the SoC in this category. I read the general ideas and have a project in my mind to execute the task listed in the wiki. You might want to start by picking just one of the "Partial Transitions" tasks and trying to work on it, even before submitting a proposal; that will help you write a better proposal... - Dan
Re: Summer of Code: proposal to participate with Partial Transitions
On 4/29/06, Eder L. Marques <[EMAIL PROTECTED]> wrote: > You might want to start by picking just one of the "Partial Transitions" > tasks and trying to work on it, even before submitting a proposal; that > will help you write a better proposal... Its a good idea Dan. :) May be I can start with define_peephole to define_peephole2 ? Where I can found specific documentation about this? GIYF. Searching for define_peephole2 got me quite a few interesting hits, starting with http://gcc.gnu.org/onlinedocs/gccint/define_005fpeephole2.html And, when I will have doubts, ask in the list or exists anyone interested in help-me, by mentoring this tasks? Ask the list (after googling*, of course). The best way to attract a mentor is by teaching yourself and making a bit of progress, I think. I will get the code from svn and start the "cleaning". :) Good luck... - Dan *) googling is a registered trademark of Xerox, or some other big company, I forget.
re: GCC 4.0.1 compilation errors
Ginil wrote: code that compiled easily with gcc-3.2.1 would not compile with gcc-4.0.1. ... The major errors are with template, name lookup but there are also certain errors with finding definitions from header files which are included and are in include path. Your code is probably not C++ standard compliant; the new gcc is stricter. I maintain a collection of links about this at http://kegel.com/gcc/gcc4.html including an excellent pair of documents from someone who built all of Debian with gcc-4.1. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Getting to the GCC Summit web page
Thanks! I put an updated page up at http://kegel.com/gcc/summit2006.html I won't be attending myself this year (I needed a break from travel), but if anyone's blogging the event, please let me know and I'll link to their blog from my page. - Dan On 6/23/06, Andrey Belevantsev <[EMAIL PROTECTED]> wrote: Hi Daniel, Last year, when I was at the GCC Summit for the first time, I've found your web page with directions on how to get there really helpful (http://kegel.com/gcc/summit2005.html). By now, some links from the page are not working: 1. The transitway info and map is now at the same page at http://www.octranspo.com/mapscheds/transitway/transitway_map.html instead of http://www.octranspo.com/mapscheds/transitway/tway_map.html 2. Mackenzie King is now http://www.octranspo.com/mapscheds/transitway/station_layout.asp?station_id=MAC instead of http://www.octranspo.com/mapscheds/transitway/mackenzie_king.htm 3. Area walking map is now http://www.octranspo.com/mapscheds/transitway/area_map.asp?station_id=MAC instead of http://www.octranspo.com/mapscheds/transitway/areamaps/mackenzie_king_area.htm All the others seem to be ok. Hope that helps. Andrey -- Wine for Windows ISVs: http://kegel.com/wine/isv
gcc-4.3 projects page?
Is it time to create a GCC_4.3_Projects page like http://gcc.gnu.org/wiki/GCC_4.2_Projects ? I imagine several projects are already in progress, but not yet mentioned on the wiki... - Dan
Re: Automated Toolchain Building and Testing
On Wed, Aug 28, 2013 at 5:52 PM, Samuel Mi wrote: >> This looks like a SSH connector for the Jenkins server side, no? > No. Actually, Jenkins implements a built-in SSH server within itself. Doesn't really help platforms that can boot linux but that don't have a sufficient version of Java/python. For them, one really wants a buildbot/jenkins/whatever build node written in C/C++, since those are the languages most likely to be universally available on such machines. - Dan
Re: gnu software bugs
Please don't crosspost. It would probably also help if you posted just one bug per message, and included the commandline, source, and error message for your smallest test case inline, and used a more descriptive subject line. On Sat, Nov 2, 2013 at 10:26 AM, Mischa Baars wrote: > Hi, > > I found these two small bugs in the gnu software. Anyone who would like to > try to fix these? > > Regards, > Mischa.
re: Should build-sysroot be considered for setting inhibit_libc?
Stephen M. Kenton asked: > Should specifiying newlib in the absence of the newlib source continue > to be treated as meaning "force inhibit_libc" in some cases, or should > inhibit_libc just be exposed if that is desirable? FWIW, crosstool.sh has this little snippet in it: # Building the bootstrap gcc requires either setting inhibit_libc, or # having a copy of stdio_lim.h... see # http://sources.redhat.com/ml/libc-alpha/2003-11/msg00045.html cp bits/stdio_lim.h $HEADERDIR/bits/stdio_lim.h If it'd be cleaner to let the caller directly force inhibit_libc, please do. - Dan
