[Bug jit/65691] New: libgccjit documentation typo in gcc_jit_context_one

[rur...@x-ray.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65691

Bug ID: 65691
   Summary: libgccjit documentation typo in gcc_jit_context_one
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rur...@x-ray.at

Copy & Paste problem.

gcc_jit_rvalue *gcc_jit_context_one(gcc_jit_context *ctxt, gcc_jit_type
*numeric_type)

Given a numeric type (integer or floating point), get the rvalue for zero.
Essentially this is just a shortcut for:

gcc_jit_context_new_rvalue_from_int (ctxt, numeric_type, 1)

=> Replace "zero" with "one".

Seen at https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html

[Bug c/64459] New: __attribute__((returns_nonnull)) creates wrong code on amd64

[rur...@x-ray.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64459

Bug ID: 64459
   Summary: __attribute__((returns_nonnull)) creates wrong code on
amd64
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rur...@x-ray.at

I had to disable the new returns_nonnull on parrot with gcc 4.9 on amd64, 
but it does work fine with clang and the MSVC equivalent __notnull.
I tried the gcc optimizations O0 - O3.

The symptom is a double size in some io buffer, so it does not look related,
it's just some weird side-effect. 
But it is.
The patch in question https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00405.html
also looked innocent to me for the beginning.

Since we use 992 returns_nonnull annotated functions in parrot, the bisect
which function and asm exactly is the problem will need some time...

gcc (Debian 4.9.1-19) 4.9.1

[Bug c/64459] __attribute__((returns_nonnull)) creates wrong code on amd64

[rur...@x-ray.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64459

Reini Urban  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Reini Urban  ---
This ticket can be closed, not a bug.

My test script finished after some hours of grinding, 
which tested all of the 992 returns_nonnull annotated functions in parrot.
Disabling returns_nonnull on one function made it work. 
I've checked the assembly.

It was Parrot_cx_check_scheduler(), which had a wrong 
if (Parrot_cx_check_scheduler(...) == 0)
check, and consequently this branch was removed by gcc.

So it's really a missed clang and msvc dead-code removal opportunity.

[Bug c/64459] __attribute__((returns_nonnull)) creates wrong code on amd64

[rur...@x-ray.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64459

--- Comment #4 from Reini Urban  ---
maybe the script is of value to anyone:
https://gist.github.com/rurban/b8b951d03ff22734f05b

[Bug middle-end/64463] New: Add warning: returns_nonnull attribute on a function compared against NULL

[rur...@x-ray.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463

Bug ID: 64463
   Summary: Add warning: returns_nonnull attribute on a function
compared against NULL
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rur...@x-ray.at

feature request:

Working on gcc.gnu.org/bugzilla/show_bug.cgi?id=64459 I find it difficult to 
find all occurrences of wrong returns_nonnull attributes.

We get those errors, which are fine:
error: returns_nonnull attribute on a function not returning a pointer

But I'm missing the diagnosis of nonnull return values when they are being
wrongly used.

Such as:

__attribute__((returns_nonnull))
char *myfunc() { ...}

if (!myfunc()) { 
  ...  /* optimized away */
}

I would like to see a warning when a returns_nonnull function is compared
against a NULL value, and then actual code is removed or skipped based on that
attribute. Which is either a difficult to diagnose declaration error, or a
logical error in the usage.

warning: returns_nonnull attribute on a function compared against NULL