Re: Should -Wmaybe-uninitialized be included in -Wall?

On Thu, Jul 11, 2013 at 12:42 AM, Ryan Hill wrote: > On Wed, 10 Jul 2013 07:49:18 -0500 > Gabriel Dos Reis wrote: > >> If we include a warning in -Wall then it is because we believe it to be >> generally useful and likely to uncover common bugs/mistakes. It is therefore >> reasonable for users t

Re: Should -Wmaybe-uninitialized be included in -Wall?

Jeff Law writes: > On 07/10/2013 04:51 AM, Andreas Arnez wrote: >> OK, I may be biased, because I have *only* seen false positives with >> this warning so far. Others may have made better experience with it. > It's found numerous bugs across many projects. The reduction in bug > reports against

RE: Inter register constraints

> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: 05 July 2013 18:03 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Inter register constraints > > > have 64 registers that will give you 22 pairs. I could, of course, > > create all of these by hand by def

Re: Should -Wmaybe-uninitialized be included in -Wall?

On Thu, Jul 11, 2013 at 11:11:28AM +0200, Andreas Arnez wrote: > > On 07/10/2013 04:51 AM, Andreas Arnez wrote: > >> OK, I may be biased, because I have *only* seen false positives with > >> this warning so far. Others may have made better experience with it. > > It's found numerous bugs across ma

Re: Calculating instruction costs

Hi, On Wed, 10 Jul 2013, David Given wrote: > Michael Matz wrote: > [...] > > As you didn't adjust any cost I would guess the high value comes from the > > default implementation of address_cost, which simply uses arithmetic cost, > > and the MULT in there is quite expensive by default. > > >

Re: Should -Wmaybe-uninitialized be included in -Wall?

Hi, On Thu, 11 Jul 2013, Gabriel Dos Reis wrote: > > Arg, no. -Werror is very useful for development and I'm sure that > > code quality increases because of it, but it should never be enabled > > by default for releases. I think about 80% of the bugs we've had > > filed so far for packages f

rl78-elf: Compilation broken due to missing constraint

Hi! I guess you forgot a small patch to constraints.md, because since this commit which uses a new "U" constraint, the rl78-elf target won't build: 2013-05-31 Kaushik Phatak * config/rl78/rl78.md (mulqi3,mulhi3): New define_expands. (*mulqi3_rl78,*mulhi3_rl78,*mulhi3_g13): New

Re: Porting from old to new GCC versions

On 7/11/13 4:23 AM, Hendrik Greving wrote: Hi, I have a hard time finding a good description of how old, obsolete and now poisoned target macros and backend switches had been replaced with. Examples are TARGET_SWITCHES, or CAN_DEBUG_WITHOUT_FP. I am porting from a very old compiler version. Is th

Re: HAVE_ATTR_enabled mishandling?

On 7/10/13 5:51 AM, David Given wrote: I think I have found a bug. This is in stock gcc 4.8.1... My backend does not use the 'enabled' attribute; therefore the following code in insn-attr.h kicks in: #ifndef HAVE_ATTR_enabled #define HAVE_ATTR_enabled 0 #endif Therefore the following

gcc-4.8-20130711 is now available

Snapshot gcc-4.8-20130711 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130711/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

RE: rl78-elf: Compilation broken due to missing constraint

> I guess you forgot a small patch to constraints.md, because since this commit > which uses a new "U" constraint, the rl78-elf target won't > build: > 2013-05-31 Kaushik Phatak > > * config/rl78/rl78.md (mulqi3,mulhi3): New define_expands. > (*mulqi3_rl78,*mulhi3_rl78,*mulhi3_g13):