Re: Miscompilation of remainder expressions
Paolo Bonzini wrote: Compared to the slow idivl, abs could be negligible, right. However, abs does introduce new data dependence which might add a noticeable cost. Is there an abs instruction in the i386 instruction set? No, the closest thing (input in eax, output in edx) is cltq addl %edx, %eax xorl %eax, %edx But the register allocations constraints are pretty heavy considering that idivl already puts strain on the RA. Paolo Paolo, what does the cltq instruction do? I cannot find it in my x86 reference manuals...
Re: Help for warning: type attributes are honored only at type definition
You're right, this isn't the correct list for this question, try posting it to gcc-help Francesco Montorsi wrote: Maybe this is not the right list for such question? Should I directly use gcc bugzilla? Thanks, Francesco Francesco Montorsi ha scritto: Hi all, I'm getting a lot of warnings of type: warning: type attributes are honored only at type definition when building a library which uses the __attribute__((visibility(default))) also on forward declarations... While I greatly appreciate the new C++ visibility support in GCC, I think the above warning is a big malus for cross-platform projects which need the M$'s __declspec() attribute also on forward declarations in fact reading http://gcc.gnu.org/wiki/Visibility I see that this feature was designed with win32's declspec() attribute-compatibility in mind. This has definitively been a Good Thing but that warning does not make GCC fully compatible with __declspec. To remove all those warnings from the sources of my apps I'd need to use a DLLEXPORT_FORWARD macro when forward-declaring stuff (which would be defined as __declspec(dllexport) for win32 compilers like MSVC or Borland and which would expand to nothing for GCC). And that would require me to change thousands of lines by hand :( Looking around for a solution (e.g. suppress that specific warning) I've found: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345 and I wonder if the patch referenced there (http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html) does fix my problem, too. Does anyone know that? In that case, which is the first GCC version which will include that patch? Last, if that patch does not fix the warning, would it be possible to add a -Wno-type-attribute-declaration (or something like that) switch to suppress it? Thanks a lot and keep up the good work! Francesco Montorsi PS: I'm using the following CC version: [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Re: Segment registers support for i386
It would take a massive target-specific backend hack to make that happen, as GCC currently only supports flat address spaces. ;-) Rémy Saissy wrote: Hi everybody, I'm looking for gcc support of x86-32 segment registers but the only information I've found about it is in this old thread: http://gcc.gnu.org/ml/gcc/1999-12/msg00526.html I was wondering what happened since this thread, does somebody have integrated the segment register support for i386 in gcc ? There is nothing about it in the manual pages and gcc 4.0.3 doesn't seem to support it. Thank for your precisions. Have a great day. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie. J.-J. Rousseau, Emile.
Re: executables in gcc4.0.2
The gen* family of executables is used during the build process to make various .h files from the .md files for the chosen target (and nowhere else AFAIK) sean yang wrote: If we do a search of main function in gcc4..0.2/gcc directory, we can find several. I understand collect2.c--collect2, main.c (wrapper of toplev.c) --cc1, gcov.c--gcov. Can someone give a brief introduction what gen*() is ued for? For example, genattr is compiled to destgcc/gcc/build/genattr, but I don't see anything else calls this executable. Thanks, Sean gcc grep main (int *.c collect2.c:main (int argc, char **argv) fix-header.c:main (int argc, char **argv) gcc.c:main (int argc, const char **argv) gcov.c:main (int argc, char **argv) gcov-dump.c:main (int argc ATTRIBUTE_UNUSED, char **argv) gcov-iov.c:main (int argc ATTRIBUTE_UNUSED, char **argv ATTRIBUTE_UNUSED) genattr.c:main (int argc, char **argv) genattrtab.c:main (int argc, char **argv) gencheck.c:main (int argc, char ** ARG_UNUSED (argv)) gencodes.c:main (int argc, char **argv) genconditions.c:main (int argc, char **argv) genconfig.c:main (int argc, char **argv) genconstants.c:main (int argc, char **argv) genemit.c:main (int argc, char **argv) genextract.c:main (int argc, char **argv) genflags.c:main (int argc, char **argv) gengenrtl.c:main (int argc, char **argv) gengtype.c:extern int main (int argc, char **argv); genmddeps.c:main (int argc, char **argv) genopinit.c:main (int argc, char **argv) genoutput.c:main (int argc, char **argv) genpeep.c:main (int argc, char **argv) genpreds.c:main (int argc, char **argv) gen-protos.c:main (int argc ATTRIBUTE_UNUSED, char **argv) genrecog.c:main (int argc, char **argv) main.c:int main (int argc, char **argv); main.c:main (int argc, char **argv) mips-tdump.c:main (int argc, char **argv) mips-tfile.c:main (int argc, char **argv) protoize.c:main (int argc, char **const argv) _ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Most existing GCC ports for microcontrollers rely on a matching Binutils port in order to provide an assembler (GAS) and linker (GNU ld). GCC itself always produces assembler output (which may or may not be saved to a file). Colm O' Flaherty wrote: All, I've been thinking a bit more about this (no code yet: I was busy trying to find and fix a bug in gpsim), and I'm still not sure what the optimal development mode is.. by this, I mean.. what should the proposed PIC port of GCC produce? .c - .asm .c - .hex (or .ihx) There are pros and cons to both approaches. Producing a hex file is (a lot?) more work, and would duplicate the work of gputils, but would leave gcc as a standalone tool, which I presume is desirable! Producing .asm files would also be viable. These files could then be fed into gputils (gpasm, gplink), which would produce the hex file. This is how SDCC operates. The issue here is that that gcc would then become bound to gputils, or some tool like it. An added advantage of this approach would be that the result could be visually simulated on a PIC in gpsim (a terrific advantage, if you ask me), with the knowledge of what line of C code is being executed (but running the assembly code). The real issue here, for me, is the level of duplication / overlap with the SDCC project. Any thoughts or preferences? What view would the gcc purists take of these two approaches? How does the existing gcc microcontroller ports operate? Do they produce hex files, or assembly? Colm From: François Poulain [EMAIL PROTECTED] To: Gabriele Caracausi [EMAIL PROTECTED] CC: 'Colm O' Flaherty' [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: RE: GCC Port (gcc backend) for Microchip PICMicro microcontroller Date: Wed, 08 Mar 2006 20:16:39 +0100 I am interested by your work, you can share it. What was your Gcc development version ? Le mercredi 08 mars 2006 à 18:56 +0100, Gabriele Caracausi a écrit : Hi Francois, Colm, I've read your emails and I'd like to be involved in this project. As you can read in my past emails in the GCC ML, I've tried two years ago to create a porting of GCC to PIC 18FXXX. The project was developed when I was student without a truly and strong guide in all involved activities. My proposal is: I could share the code I've developed but, keep in mind, that the code should contain some error. Starting from it, we could continue / modify / correct / improve the porting all together. What do you think about it ? Ciao! Gabriele. -Original Message- From: Franзois Poulain [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 7:56 PM To: Colm O' Flaherty Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller Like you, I'm still studying the internals of gcc, but I'm close to being confident enough to start making some changes. Nice ! Le lundi 06 mars 2006 а 17:17 +, Colm O' Flaherty a йcrit : Francois, There are only 35 instructions in the 14 bit instruction set, and given that, in gcc, the main initial work seems to be in describing the targets instruction set, it might not take much to find out what implementation issues will occur, by just taking to the time to describe the instructions. For me, the things that I suspect to be issues are: -8 bit ALU -small memory space -limited stack space (8 levels on 16F) -the number of PIC devices (configurations) that would need to be supported (with the various number of banks, and memory configs) Like you, I'm still studying the internals of gcc, but I'm close to being confident enough to start making some changes. Colm
Re: Problem with pex-win32.c
I'll happily test a patch to that file for you...the only box at my house runs Windows... =-O Ian Lance Taylor wrote: Mark Mitchell [EMAIL PROTECTED] writes: The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things are fine. The reason for this problem is that the current code uses MSVCRT's spawn to create the process, and that function doesn't provide fine enough control. You have to use CreateProcess to make this work as desired. When invoking CreateProcess, you must set bInheritHandle to TRUE and pass a long a STARTUPINFO structure with dwFlags set to STARTF_USESTDHANDLES, and the various hStd* handle fields set to the values from the calling process. (I'm pretty sure that CodeSourcery posted patches that did that at one point; they were in our 3.4-based toolchains.) You might think that linking with -mwindows would work, and, indeed that avoids the DOS windows popping up in Cygwin -- but they you get no output at all under Windows. I guess I have two questions: (a) do you feel like fixing this, and (b) if not, do you have any objection to using CreateProcess? I just copied the use of spawn from the earlier pex-win32 implementation. The pex_win32_exec_child function is basically exactly the same code as before. I certainly have no objection to using CreateProcess instead. I could try a patch, but I can't test it, because I don't have a Windows system. So it might be better if somebody else tackled it. Ian
Re: huge compile time on head
This is somewhat of a gcc-help@ question, but I'll try to help anyway :) First, did cc1 just do this to you or can you reliably duplicate the segfault? If you can't duplicate this error, it's probably a sign of a hardware problem. If you can, then there's a bug in your host compiler...which is what version of gcc? I don't have a FC3 box at my disposal (yet). -- bsdfan3 Joel Sherrill wrote: Hi, I am building m68k-rtems (m68k-elf) right now on the head and seeing a cc1 which has been running 17:37.05 according to top on a fast machine running Fedora Core 3. It is a AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ at 2Ghz. The last thing I see in the build log is this: -c ../../gcc/gcc/crtstuff.c -DCRT_END \ -o crtend.o ../../gcc/gcc/crtstuff.c: In function '__do_global_ctors_aux': ../../gcc/gcc/crtstuff.c:519: internal compiler error: Segmentation fault Is this a known issue? --joel
Re: Microchip PIC
I'm sorry about my e-mail client mangling your name in the To: field. I don't know about the Microchip source, but I'd be happy to help with the GCC-PIC18Fxxx port...however, PIC's have 1 true accumulator (W) and everything else in data memory (which they use in the manner of a register file)...IDK how well GCC's register allocator would handle such a thing... François Poulain wrote: Hello, I am talking about porting GCC on PIC18Fxxx, by Microchip. I found some source code from Microchip to support the PIC30F. Anyone can tell me why this code isn't in the gcc tree ? Is it dirty code ? I ask this question, cause I maybe re-use that source code for testing. Best Regards,
Re: Successful built of 3.4.5, failing gctest from testsuite
Sounds like /bin/sh puked...What shell was that GCC configured with? P.S. That looks to be a boehm-gc test that failed...which really doesn't matter much (from an end-user perspective) unless you use GCJ... David Fang wrote: Hi all, In reply to an earlier posting this month, from: From: Michal Dovciak dovciak at mbox dot troja dot mff dot cuni dot cz To: gcc at gcc dot gnu dot org Date: Thu, 05 Jan 2006 16:41:10 +0100 Subject: Successful built of 3.4.5, failing gctest from testsuite A colleague (CC'd, not subscribed) experienced the same problem, described in the referenced message below, with a nearly identical configuration SUSE Linux 10.0, on i686, which only contained a prerelease of gcc-4.0.2 (20050901). He was not able to acquire ANY other release gcc version from the SUSE package manager, which is a SERIOUS problem. He acquired the gcc-3.4.5 and built it from 4.0.2 prelease, and experience the same testsuite failure. Now we're suspecting possible wrong code generated by gcc-3.4.5, possibly miscompiled by 4.0.2-pre. Has anyone looked into this? I've seen no follow ups so far. And I realize many are busy with 4.1. On a side note, why does SUSE only provide one unofficial release of gcc? I'd be VERY CONCERNED if there is no other way to get a stable compiler built from a widely used distro (I'm not a SUSE user myself). Regards, David Clint reference message Hi all, here is a specification of my successful installation of gcc-3.4.5 1. Output from running srcdir/config.guess: i686-pc-linux-gnu 2. The output of gcc -v for my newly installed gcc: Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.5/specs Configured with: /local/install/gcc-3.4.5/gcc-3.4.5/configure --program-suffix=-3.4.5 --enable-threads=posix --enable-shared --enable-languages=c,c++,objc,f77,java --disable-checking --enable-libgcj --enable-__cxa_atexit --with-system-zlib --enable-java-awt=gtk Thread model: posix gcc version 3.4.5 3. I downloaded and enabled c, c++, objc, f77 and java. Firstly I tried to include ada as well but it failed, I had a distribution (i.e. higher version of) ada installed. 4. The distribution name and version: SUSE Linux 10.0 (this distribution includes gcc version 4.0.2 20050901 prerelease) 5. The version of the Linux kernel: 2.6.13-15.7-smp (i.e. SUSE Linux kernel) 6. The version of glibc I used: glibc-2.3.5-40 Two additional notes: 1. I have succesfully compiled all HEASAD (LHEASOFT) package used by astronomy community (quite substantional package) without any error. 2. Although the testsuite ran fine throughout I think almost all tests (gcc, g77, objc, java and libraries), it finished with a following error (WHY?): creating gctest make AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-O2 -g -O2 CXXFLAGS=-g -O2 -D_GNU_SOURCE CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=/usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS= LIBCFLAGS=-O2 -g -O2 LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=/local/install/gcc-3.4.5/gcc-3.4.5/missing makeinfo --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh EXPECT=expect RUNTEST=runtest RUNTESTFLAGS= exec_prefix=/usr/local infodir=/usr/local/info libdir=/usr/local/lib prefix=/usr/local tooldir=/usr/local/i686-pc-linux-gnu AR=ar AS=as CC=/local/install/gcc/gcc/xgcc -B/local/install/gcc/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include CXX=/local/install/gcc/gcc/g++ -B/local/install/gcc/gcc/ -nostdinc++ -nostdinc++ -I/local/install/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/local/install/gcc/i686-pc-linux-gnu/libstdc++-v3/include -I/local/install/gcc-3.4.5/gcc-3.4.5/libstdc++-v3/libsupc++ -I/local/install/gcc-3.4.5/gcc-3.4.5/libstdc++-v3/libsupc++ -I/local/install/gcc-3.4.5/gcc-3.4.5/libstdc++-v3/include/backward -I/local/install/gcc-3.4.5/gcc-3.4.5/libstdc++-v3/testsuite -L/local/install/gcc/i686-pc-linux-gnu/libstdc++-v3/src -L/local/install/gcc/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include LD=ld LIBCFLAGS=-O2 -g -O2 NM=nm PICFLAG= RANLIB=ranlib DESTDIR= check-TESTS make[3]: Entering directory `/local/install/gcc/i686-pc-linux-gnu/boehm-gc' Switched to incremental mode Emulating dirty bits with mprotect/signals /bin/sh: line 1: 16525 Segmentation fault LD_LIBRARY_PATH=../../gcc $dir/$tst FAIL: gctest === 1 of 1 tests failed === make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/local/install/gcc/i686-pc-linux-gnu/boehm-gc'
reg-stack.c potpourri
1) What would need to be done to reg-stack.c to allow other ports besides i386 to use it? (support for multiple-stack machines would be REALLY nice, but rather far off) (any other ideas?) 2) I found a minor bug in the header comment for reg-stack.c -- when whoever wrote the comment documented push insns, they said SET_DEST was two things at the same time and never said what SET_SRC was! Is the SET_DEST supposed to be FIRST_STACK_REG, or a plain REG or MEM?
