Re: gcc miscompiling duff's device (probaby two different bugs)
Dear all,
Although I probably shouldn't have been so harsh calling this
"mis-compiling", do you see any chance of back-porting this warning back
into the mainline?
P.S. The rationale of this exercise is of course that the "switch",
being a goto in disguise needs careful attention, just like the goto.
So combining it a-la Tom Duff with another construct blessed by
Dijkstra, the for loop, can sometimes lead to unexpected results.
Pjotr
On Tue, 2010-03-02 at 14:07 +0100, Peter Kourzanov wrote:
> On Tue, 2010-03-02 at 12:26 +0100, Richard Guenther wrote:
> > On Tue, Mar 2, 2010 at 12:00 PM, Pjotr Kourzanov
> > wrote:
> > > On Tue, 2010-03-02 at 10:47 +, Andrew Haley wrote:
> > >> On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
> > >>
> > >> >> int duff4_fails(char * dst,const char * src,const size_t n)
> > >> >> {
> > >> >> const size_t rem=n % 4, a=rem + (!rem)*4;
> > >> >> char * d=dst+=a;
> > >> >> const char * s=src+=a;
> > >> >> /* gcc bug? dst+=n; */
> > >> >>
> > >> >> switch (rem) {
> > >> >> case 0: for(dst+=n;d > >> >> /*case 0:*/d[-4]=s[-4];
> > >> >> case 3:d[-3]=s[-3];
> > >> >> case 2:d[-2]=s[-2];
> > >> >> case 1:d[-1]=s[-1];
> > >> >> }
> > >> >> }
> > >> >>return 0;
> > >> >> }
> > >> >> The first time around the loop the initializer (d+=n) is jumped
> > >> >> around, so
> > >> >> d == dst. At the end of the loop, d+=4, so d > dst. Therefore the
> > >> >> loop
> > >> >> exits.
> > >> >
> > >> > And its wrong since it shouldn't jump around the initializer.
> > >>
> > >> Sure it should. On entry to that loop, rem == 3.
> > >
> > > I agree, this is one of the places where referential transparency
> > > breaks in C. I wouldn't have expected that the compiler could or
> > > would put the first expression before the switch in this case:
> > >
> > > switch (rem) {
> > > for(dst+=n;d > > case 0: d[-4]=s[-4]; ...
> > > }}
> > >
> > > However, the warning is still due, since a combination of a switch with a
> > > for loop results in code that is completely ignored, i.e., is
> > > inaccessible.
> > > As I said, gcc-3.x used to issue a warning for this one...
> >
> > Neither 2.95 nor 3.3.6 or 3.4.6 warn for me.
>
> That's weird. I am having:
>
> gcc-3.3 (GCC) 3.3.6 (Ubuntu 1:3.3.6-15ubuntu6)
> Configured with: ../src/configure -v --enable-languages=c,c++
> --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
> --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
> --enable-__cxa_atexit --with-system-zlib --enable-nls
> --without-included-gettext --enable-clocale=gnu --enable-debug
> i486-linux-gnu
> Thread model: posix
> gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-8ubuntu2)
> Configured with: ../src/configure -v --enable-languages=c,f77
> --prefix=/usr --libexecdir=/usr/lib
> --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared
> --with-system-zlib --enable-nls --without-included-gettext
> --program-suffix=-3.4 --enable-__cxa_atexit --with-tune=pentium4
> i486-linux-gnu
> Thread model: posix
>
> Are you sure you test the following variant?
>
> switch (rem) {
> for(dst+=n;d case 0: d[-4]=s[-4]; ...
> }}
>
> >
> > Richard.
> >
> > >>
> > >> Andrew.
> > >>
> > >
> > >
> > >
> >
>
>
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
引述 Andrew Haley : There is no reason in principle this shouldn't be part of gcc. I think no-one has responded yet because they don't know what it would be for, and how much work it would involve. What compiler doing is: c -> intermediate language -> asm(ex. x86). And then, c compiler for efi byte code is: c -> intermediate language -> efi byte code. For the c -> intermediate language part, I hope to use original source code of gcc,so the main point of the project is implementing intermediate language -> efi byte code part In my opinion,the project has some how similarity with compiling c language to java byte code. And in fact,it has been done by some open source project(ex. egcs-jvm[http://sourceforge.net/projects/egcs-jvm/]). I am wondering to know that trace some existing c to java byte code project would give direction to implement this project or not. Is there an EFI interpreter that is free software? EFI,the specification[http://download.intel.com/technology/efi/docs/EFI_1-10_Update.zip] which is a replacement for the older BIOS that defines EBC virtual machine. So BIOS in the future will contain this part. In additional some present BIOS (ex.BIOS of MAC, BIOS of virtualbox) has already support EFI. Is this in any way related to plans for a free BIOS? YES, coreboot[http://www.coreboot.org/Welcome_to_coreboot]and gnufi[http://www.gnu.org/software/gnufi/] Who would maintain this EFI back-end? The EFI specification was originally developed by Intel, and is now managed by the Unified EFI Forum[http://www.uefi.org/home/]. ... etc. Andrew. thanks yi-hong
gcc-4.5-20100304 is now available
Snapshot gcc-4.5-20100304 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100304/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 157233 You'll find: gcc-4.5-20100304.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100304.tar.bz2 C front end and core compiler gcc-ada-4.5-20100304.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100304.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100304.tar.bz2 C++ front end and runtime gcc-java-4.5-20100304.tar.bz2 Java front end and runtime gcc-objc-4.5-20100304.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100304.tar.bz2The GCC testsuite Diffs from 4.5-20100225 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Definition of an instruction
Dear all, I've been trying to define this instruction but am having difficulties. This instruction does 3 things: - Updates an internal accumulator (depending on two arguments) - Returns the value of that update in an output register - Updates the internal accumulator after that I first wrote : (define_insn "myInst" [ (set (match_operand:DI 0 "register_operand" "=r") (unspec:DI [(match_operand:DI 1 "register_operand" "r") (match_operand:DI 2 "register_operand" "r") (reg:DI 66)] 5)) (clobber (reg:DI 66)) ] "" "myInst\\t%0,%1,%2" [(set_attr "type" "arith") (set_attr "mode" "DI") (set_attr "length" "1")]) Therefore saying that the unspec was dependent on the accumulator and the two values and that the result was operand 0. I added a clobber to the accumulator to say: it's been changed. However, now if I have two myInst, the first gets optimized out... I therefore need to define this instruction differently, any ideas ? Thanks a lot, Jean Christophe Beyler
Re: Definition of an instruction
Maybe try this: (define_insn "myInst" [ (set (match_operand:DI 0 "register_operand" "=r") (unspec:DI [(match_operand:DI 1 "register_operand" "r") (match_operand:DI 2 "register_operand" "r") (reg:DI 66)] 5)) (set (reg:DI 66) (unspec:DI [(match_operand:DI 1 "register_operand" "r") (match_operand:DI 2 "register_operand" "r") (reg:DI 66)] 6)) ] "" "myInst\\t%0,%1,%2" [(set_attr "type" "arith") (set_attr "mode" "DI") (set_attr "length" "1")]) Which basically means op[0] = unspec:5(op[1], op[2], reg:66); [reg:66] = unspec:6(op[1], op[2], reg:66) So when you have two in a row, the second depends on the first as you have the set of reg:66. The clobber in your original code does not do that, it says reg 66 cannot be depended on the value across the instruction. Thanks, Andrew Pinski
Re: Definition of an instruction
Yeah that's what I had tried first but I get : genextract: Internal error: abort in VEC_safe_set_locstr And I can't seem to get rid of that error. Any idea why this happens? Jc On Thu, Mar 4, 2010 at 6:28 PM, Andrew Pinski wrote: > Maybe try this: > > (define_insn "myInst" > [ > (set (match_operand:DI 0 "register_operand" "=r") > (unspec:DI [(match_operand:DI 1 "register_operand" "r") > (match_operand:DI 2 "register_operand" "r") > (reg:DI 66)] 5)) > (set (reg:DI 66) > (unspec:DI [(match_operand:DI 1 "register_operand" "r") > (match_operand:DI 2 "register_operand" "r") > (reg:DI 66)] 6)) > ] > "" > "myInst\\t%0,%1,%2" > [(set_attr "type" "arith") > (set_attr "mode" "DI") > (set_attr "length" "1")]) > > > Which basically means op[0] = unspec:5(op[1], op[2], reg:66); [reg:66] > = unspec:6(op[1], op[2], reg:66) > So when you have two in a row, the second depends on the first as you > have the set of reg:66. The clobber in your original code does not do > that, it says reg 66 cannot be depended on the value across the > instruction. > > Thanks, > Andrew Pinski >
Re: Definition of an instruction
On Thu, Mar 4, 2010 at 3:38 PM, Jean Christophe Beyler wrote: > Yeah that's what I had tried first but I get : > > genextract: Internal error: abort in VEC_safe_set_locstr > > And I can't seem to get rid of that error. > > Any idea why this happens? Oh because the second time for the match_operand, you should be using match_dup (and yes the error message should be better). I had forgot about that :). So try this: (define_insn "myInst" [ (set (match_operand:DI 0 "register_operand" "=r") (unspec:DI [(match_operand:DI 1 "register_operand" "r") (match_operand:DI 2 "register_operand" "r") (reg:DI 66)] 5)) (set (reg:DI 66) (unspec:DI [(match_dup 1) (match_dup 2) (reg:DI 66)] 6)) ] "" "myInst\\t%0,%1,%2" [(set_attr "type" "arith") (set_attr "mode" "DI") (set_attr "length" "1")]) Thanks, Andrew Pinski
Use the wctype builtins functions
Hi, I want to use the the wctype builtins ISWALPHA and the other ISW* functions to handle the wide character string, but I get the following error: /home/gcc/build/gcc/../../trunk/gcc/opts.c:1190: undefined reference to `ISWALPHA' collect2: ld returned 1 exist status I have tried to grep some examples that use the ISW* builtins, but didn't find any one. Does anyone know how to use them? Thanks Pearly
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
Hello. I'm actually an EFI engineer so this project is of great interest to me. I would be willing to lend a hand off hours if this goes through, so please keep me in the loop. I think the biggest hurdle would be the c front end since EBC (EFI byte code) introduces variable sized pointers as well as a (u)intn (natural sized integer). The idea was you could have an addin card with an option rom compiled with EBC that would work in any system using EFI. From my limited experience with the Intel EBC compiler they just changed sizeof to a function. For instance using iec the following could fail to compile: int array_mask[sizeof(my_array)/sizeof(array_entry)]; If array_entry had a pointer or natural sized integer the compiler would complain and exit. I did a little research to see if I could just change sizeof to a function for gcc but found it would break quite a few things, and even more optimizations (although it's interpreted so optimization is not a priority). I'm no gcc guru but it seemed like quite a bit of work to the front end to deal with it. The other hurdle would be the ABI. It's very particular since it has to accommodate calling into and from EBC, x86, x86_64, ia64, and any other architecture available. It's structured mainly on Microsoft's stdcall ABI. EBC's instruction set is fairly simple so I don't think it would be very hard to create another target for gas. There is an open source interpreter available from the EDK. I'm not 100% sure if you can use it in the emulated environment, but there are quite a few platforms to work on. 2010/3/4 : > 引述 Andrew Haley : > >> There is no reason in principle this shouldn't be part of gcc. >> >> I think no-one has responded yet because they don't know what it would >> be for, and how much work it would involve. > > What compiler doing is: c -> intermediate language -> asm(ex. x86). > And then, c compiler for efi byte code is: c -> intermediate language -> efi > byte code. > For the c -> intermediate language part, I hope to use original source code > of gcc,so the main point of the project is implementing intermediate > language -> efi byte code part > > In my opinion,the project has some how similarity with compiling c language > to java byte code. And in fact,it has been done by some open source > project(ex. egcs-jvm[http://sourceforge.net/projects/egcs-jvm/]). I am > wondering to know that trace some existing c to java byte code project would > give direction to implement this project or not. > >> Is there an EFI interpreter that is free software? > > EFI,the > specification[http://download.intel.com/technology/efi/docs/EFI_1-10_Update.zip] > which is a replacement for the older BIOS that defines EBC virtual machine. > So BIOS in the future will contain this part. In additional some present > BIOS (ex.BIOS of MAC, BIOS of virtualbox) has already support EFI. > >> Is this in any way related to plans for a free BIOS? > > YES, coreboot[http://www.coreboot.org/Welcome_to_coreboot]and > gnufi[http://www.gnu.org/software/gnufi/] > >> Who would maintain this EFI back-end? > > The EFI specification was originally developed by Intel, and is now managed > by the Unified EFI Forum[http://www.uefi.org/home/]. > >> ... etc. >> >> Andrew. >> > > > thanks > > yi-hong > >
