[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

2020-01-23 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from David Malcolm  ---
Ought to be fixed by above patch; marking this as resolved.  Please reopen if
there's still an issue.

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

2020-01-23 Thread cvs-commit at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:a0b935ac66bc9804b0864151e5f1bfde5ac1ddeb

commit r10-6195-ga0b935ac66bc9804b0864151e5f1bfde5ac1ddeb
Author: David Malcolm 
Date:   Thu Jan 23 17:46:12 2020 -0500

analyzer: avoid relying on system  in testsuite (PR 93367)

PR analyzer/93367 reports a testsuite failure in abort.c on
hppa64-hp-hpux11.11 when detecting if the analyzer "knows" that the
condition holds after the assert.

The root cause is that the assertion failure function in that
configuration's  is not marked with
__attribute__ ((__noreturn__)).

This patch reworks the test to avoid  in favor of a custom
implementation of assert, so that the test demonstrates the idea without
relying on properties of .

gcc/testsuite/ChangeLog:
PR analyzer/93367
* gcc.dg/analyzer/abort.c: Remove include of .
Replace use of assert with a custom assertion implementation.

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

2020-01-22 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #3 from David Malcolm  ---
Thanks.

I think I'll use a custom assert macro to avoid depending on the vagaries of
all of the various  out there.

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

2020-01-22 Thread dave.anglin at bell dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367

--- Comment #2 from dave.anglin at bell dot net ---
On 2020-01-21 9:55 p.m., dmalcolm at gcc dot gnu.org wrote:
> What's the definition of assert for this system?
   extern void __assert(char *, char *, int);

#  if defined(__cplusplus) && !defined(__STDCPP__)
#    define assert(_EX) \
    ((_EX) ? (void)0 : __assert("_EX", __FILE__, __LINE__))
#  else
#    define assert(_EX) \
    ((_EX) ? (void)0 : __assert(#_EX, __FILE__, __LINE__))
#  endif

I suppose an include hack could be done to add __attribute__((__noreturn__)).

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

2020-01-22 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

2020-01-21 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93367

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

The failing test is a:

  __analyzer_eval (i < 10);

after a:

  assert (i < 10);

which expects TRUE, but is emitting UNKNOWN.

What's the definition of assert for this system?

The test is assuming that the assertion handler has __attribute__
((__noreturn__)), which I'm guessing isn't the case here.

I guess I could rewrite the test to use a custom assert macro, or skip the test
on certain targets, etc.