Workshop on Essential Abstractions in GCC
Workshop on Essential Abstractions in GCC, 2011 (http://www.cse.iitb.ac.in/grc/gcc-workshop-11) --- Organized by: GCC Resource Center (http://www.cse.iitb.ac.in/grc). Venue:Department of Computer Science and Engineering, IIT Bombay (http://www.cse.iitb.ac.in). Dates:30 June to 3 July (Thursday to Sunday) 2011. Last date of registration: 31 May 2011 --- Our apologies if - you have received multiple copies of this notification, or - if this notification has reached you erroneously. Please forward this to people who you think might be interested. GCC Resource Center Team
[GSOC] how to give arguments to a simple checks plugin?
Hello, the official starting date for the GSOC coding is today. My project (http://pvittet.com/GSOC/GSOC.pdf) is to code a plugin which allows the user to make some simple checks (such as monitoring that a call to pthread_mutex_lock() is followed by a test on pthread_mutex_unlock() on the same mutex in the same function) and to displays resulting warnings. It is important to think about how the user can transmit arguments to the plugin, I see three possibilities: * Using pragma informations in the code: o pro: It might help to solve name mangling problems (http://en.wikipedia.org/wiki/Name_mangling) o cons: You have to modify the source code to check something, checks are not meant to be easily changed. * Putting them as a list of arguments: o pro: Easily editable by the user. o cons: Possible mangle problem if his code is not C language (we can't expect the user to know the mangle name of the function he wants to check). Arguments list might be long. * Putting them in a separate file: o pro: Easily editable by the user. o cons: Possible mangle problem is it is not C language (we can't expect the user to know the mangle name of the function he wants to check). So I would like to know which possibility you think to be the best ? At first I thought to use a separate file, but the mangling problem has to be taken in account. I guess it heavily depends of how we wants the plugin to be use (list of arguments is good for a quick try without much real use, pragma would be more serious but also requires more willingness from the user). Thanks! Pierre Vittet
RE: X32 project status update
The eventual goal is to merge it with the x86-64 syscall table, although we're still working out exactly where we can do it. -hpa -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Saturday, May 21, 2011 8:28 To: H.J. Lu Cc: GCC Development; GNU C Library; LKML; x32-...@googlegroups.com; Anvin, H Peter Subject: Re: X32 project status update On Saturday 21 May 2011 17:01:33 H.J. Lu wrote: > This is the x32 project status update: > > https://sites.google.com/site/x32abi/ > I've had another look at the kernel patch. It basically looks all good, but the system call table appears to diverge from the x86_64 list for no (documented) reason, in the calls above 302. Is that intentional? I can see why you might want to keep the numbers identical, but if they are already different, why not use the generic system call table from asm-generic/unistd.h for the new ABI? Arnd
Deprecating mips-openbsd
According to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47110 mips-openbsd does not build in 4.6. I haven't seen any activity on this port for years. Would anyone object to its deprecation? Richard
Re: mips-elf-gcc -fno-delayed-branch problem
The -O1 sounds like a reasonable choice. Thanks for looking at the problem. Toshi --- On Sat, 5/21/11, Richard Sandiford wrote: > From: Richard Sandiford > Subject: Re: mips-elf-gcc -fno-delayed-branch problem > To: "Toshi Morita" > Cc: gcc@gcc.gnu.org > Date: Saturday, May 21, 2011, 12:37 AM > Toshi Morita > writes: > > Maybe GAS could recognize -fno-delayed-branch to > selectively disable > > branch slot filling? > > I'd agree if it was -mno-delayed-branch. I think -f* > options are > generally compiler options, while -m* options are target > options that > could in principle be passed down to either the assembler > or the linker. > > > Is there a list of optimizations performed by MIPS GAS > listed somewhere? > > It would be nice if these could be selectively > enabled. > > The only other optimisation (if it can even be called that) > is increased > accuracy regarding nop insertion. Suppose we have > something like: > > .text > lw $4,foo > addiu $5,$5,1 > jr $31 > .data > foo: > .word 1 > > When GAS sees the LW, it doesn't know whether the LW should > use a > HI/LO pair or a GP-relative access. It therefore > creates a variant > "frag" that describes both possibilities. As far as > GAS is concerned, > the following ADDIU starts a new subblock of code. > > With -Wa,-O0, GAS doesn't try to handle dependencies > between these subblocks, > and just assumes the worst. So if you assemble with > -mips1, GAS has to > assume that the next subblock after the LW might use $4 > straight away, > and that a nop is needed: > > <.text>: > 0: 3c04 > lui a0,0x0 > > 0: R_MIPS_HI16 .data > 4: 8c84 > lw a0,0(a0) > > 4: R_MIPS_LO16 .data > 8: > nop > c: 24a50001 > addiu a1,a1,1 > 10: 03e8 > jr ra > 14: > nop > > At -Wa,-O1 and above it does the sensible thing: > > <.text>: > 0: 3c04 > lui a0,0x0 > > 0: R_MIPS_HI16 .data > 4: 8c84 > lw a0,0(a0) > > 4: R_MIPS_LO16 .data > 8: 24a50001 > addiu a1,a1,1 > c: 03e8 > jr ra > 10: > nop > > TBH, I think the cases where you'd want the -O0 behaviour > are > vanishingly rare. It does in principle need less > memory, and does > in principle assemble slightly quicker, but I don't think > anyone would > notice unless they looked hard. > > So -Wa,-O1 is better than the -Wa,-O0 that I mentioned > previously. > > Richard >
