This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: assertify mn10300


On May  8, 2005, Nathan Sidwell <nathan@codesourcery.com> wrote:

> Alexandre Oliva wrote:
>> The problem was not the inversion of the condition, but rather the
>> fact that, with checking disabled, the gcc_assert would be completely
>> optimized away, thus enabling the broken situation to skip the abort()
>> call and proceed to code that might fail to handle it properly.

> I fail to understand the state of mind that complains about the fact
> that when configured with 'please disable all consistency checks', then
> gosh darn it, all the consistency checks are removed.  It's like
> complaining that when I take the safety off a gun, well gosh darn it,
> I can shoot things.

At least in my mind, there's a difference between verifying some
internal consistency and double-checking that the operands of the asm
instruction you're about to output match the way the assembler is
going to interpret them.

Sure enough, both cases would stem from internal errors in the
compiler, but I'd rather report failures of the latter kind as errors
in the compiler, and not in the assembler, since otherwise people
might overlook the actual problem and try to fix it at the wrong
place.

That said, since assertion checking is enabled unless you actively
request it to be disabled, I'm no longer concerned about this
difference.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]