Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
On 30/03/16 00:01, Joseph Myers wrote: If we consider that -Wno-general implies -Wno-specific and -Werror=specific implies -Wspecific,@equal levels of indirection, then the order of the options on the command line is what determines whether -Wspecific is enabled (as an error). If however we consider -Wspecific to be a tristate (disabled, warning, error), then -Werror=specific is a direct setting of the tristate while -Wno-general is only indirect, so -Werror=specific takes precedence whatever the command-line order. Internally, they are tri-state but -Werror= does not seem to update opts_set, which is what is tested by the options machinery for options that imply other options. That is, -Werror=return-type -Wreturn-type -Wno-all is different from -Werror=return-type -Wno-all This seems a bug to me in how -Werror= works. Cheers, Manuel.
gcc-4.9-20160330 is now available
Snapshot gcc-4.9-20160330 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160330/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 234602 You'll find: gcc-4.9-20160330.tar.bz2 Complete GCC MD5=96de107e1cbe54ef0cf1013a0b73ef64 SHA1=bf7f9ffcf107898a53145e0e817a9f104644 Diffs from 4.9-20160323 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: out of bounds access in insn-automata.c
On 03/25/2016 04:43 AM, Aldy Hernandez wrote: If Bernd is fine with this, I'm happy to retract my patch and any possible followups. I'm just interested in having no path causing a possible out of bounds access. If your patch will do that, I'm cool. I'll need to see that patch first to comment :-) Bernd
RE: (MIPS R5900) Adding support for the FPU (COP1) instructions
Woon yung Liu writes: > Hi all, > > Thank you all for the help so far. This is probably the final part of my > efforts to complete support for the R5900 within GCC, but I need help > this time because the existing homebrew GCC version has no support for > this (despite what its README file says). Hence I have nothing to refer > to. > > The R5900 has support for a couple of floating-point arithmetic, with > its FPU (COP1). The FPU instructions are something like these: > MADD.S (rd <- ACC + rs * rt) > MADDA.S (ACC <- ACC + rs * rt) > MSUB.S (rd <- ACC - rs * rt) > MSUBA.S (ACC <- ACC - rs * rt) > ADDA.S (ACC <- rs + rt) > SUBA.S (ACC <- rs - rt) > MULA.S (ACC <- rs * rt) > > These instructions are similar to those floating-point instructions with > similar-looking names, in normal MIPS processors. But they involve the > R5900's FPU accumulator (ACC) register instead. > I didn't find an explicit instruction to move values to/from the ACC > register. How wide is the ACC register on r5900? Is it just 64-bit or does it offer wider precision? The move in to ACC should be achievable with ADDA.S where rt == 0.0 and move out with MADDA.S with rs and rt == 0.0. If ACC is wider than 64-bit then there will be some rounding mode to account for. You will also need to know if the madd/msub instructions are fused or unfused (i.e. with or without intermediate rounding as GCC will use them differently depending on the answer (see fma4 pattern). > I've added instruction patterns (or added new alternatives to existing > patterns) to the pattern file for the R5900, but I have not seen GCC > emit any of these new instructions. I did add a new register (the ACC > register), as well as a matching constraint and predicate. > > Is there a proper way for me to debug this? Or is this not working, > simply because GCC can't support such instructions on its own (it looks > complicated to issue)? Given that the base architecture has support for all the operations you listed (using just FPRs) then there needs to be some way to indicate why the accumulator based patterns should be used instead. (or you could simply only use these patterns when targeting the FPU extension in R5900). So... Under what circumstance is it preferable to use these instructions? Thanks, Matthew > > Thanks and regards, > -W Y
