All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dibyendu Majumdar <mobile@majumdar.org.uk>
To: linux-sparse@vger.kernel.org
Subject: Sparse-LLVM issue compiling NULL pointers
Date: Tue, 28 Feb 2017 06:20:43 +0000	[thread overview]
Message-ID: <CACXZuxdav6y9uRC9mavNkVZS173k0ftw-8FpPanKLsoF-ws0Sw@mail.gmail.com> (raw)

I am trying to debug a failure in sparse-llvm when compiling following:

struct mytype {
 int *foo;
};
extern void init_mytype(struct mytype *mt);
void init_mytype(struct mytype *mt) {
 mt->foo = (void *)0;
}

I am new to sparse so do not fully understand how it works, hence my
explanation below could be wrong.

As far as I understand, an integer constant 0 is converted to a value
pseudo in linearize_expression(). As a value pseudo only has a value
and no type the LLVM IR generator does not have enough information to
ensure that the correct type is used when it encounters the value
pseudo.

While trying to work out how to resolve this issue, I also found
following potential additional issues.

When handling (void*) 0, in the function evaluate_cast() in
evaluate.c, the expression type is changed to NULL type. However this
changed type is not returned.

 if (!(t1->ctype.modifiers & MOD_PTRINHERIT) && class1 == TYPE_PTR &&
     !as1 && (target->flags & Int_const_expr)) {
  if (t1->ctype.base_type == &C->S->void_ctype) {
   if (is_zero_constant(C, target)) {
    /* NULL */
    expr->type = EXPR_VALUE;
    expr->ctype = &C->S->null_ctype;
    expr->value = 0;
    return ctype;
   }
  }
 }

Should this be instead:

 if (!(t1->ctype.modifiers & MOD_PTRINHERIT) && class1 == TYPE_PTR &&
     !as1 && (target->flags & Int_const_expr)) {
  if (t1->ctype.base_type == &C->S->void_ctype) {
   if (is_zero_constant(C, target)) {
    /* NULL */
    expr->type = EXPR_VALUE;
    expr->ctype = &C->S->null_ctype;
    expr->value = 0;
    return expr->ctype;
   }
  }
 }

A related question is around the expansion of cast expressions in
cast_value() function in expand.c. The code snippet I was looking at
is this:

 if (old_size == new_size) {
  expr->value = old->value;
  return;
 }

Should this be changed to:

 if (old_size == new_size) {
  expr->value = old->value;
  expr->ctype = oldtype;
  return;
 }

The two changes above appear to help ensure that a VALUE expression's
type shows correctly that the expression is a NULL pointer. Assuming
this is correct then in value_pseudo() function in lineariez.c, it
would be possible to distinguish between integer constants and a NULL
pointer.

My question is this: should a value pseudo have type information also?
This seems like a necessity for LLVM backend.

Thanks and Regards
Dibyendu

             reply	other threads:[~2017-02-28  6:53 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28  6:20 Dibyendu Majumdar [this message]
2017-02-28 15:09 ` Sparse-LLVM issue compiling NULL pointers Luc Van Oostenryck
2017-02-28 16:04   ` Dibyendu Majumdar
2017-02-28 16:47     ` Luc Van Oostenryck
2017-02-28 16:49     ` Dibyendu Majumdar
2017-03-02  6:48       ` Luc Van Oostenryck
2017-02-28 17:03   ` Luc Van Oostenryck
2017-02-28 17:35     ` Luc Van Oostenryck
2017-02-28 17:42       ` Dibyendu Majumdar
2017-02-28 18:08       ` Dibyendu Majumdar
2017-03-01  5:49         ` Luc Van Oostenryck
2017-03-02  7:02         ` [PATCH] llvm: fix getting type of values Luc Van Oostenryck
2017-03-01 10:58     ` Sparse-LLVM issue compiling NULL pointers Dibyendu Majumdar
2017-03-01 14:45       ` Dibyendu Majumdar
2017-03-02  5:21         ` Luc Van Oostenryck
2017-03-02  5:41           ` Dibyendu Majumdar
2017-03-02 13:56             ` Luc Van Oostenryck
2017-03-02 14:05               ` Dibyendu Majumdar
2017-03-02 16:10                 ` Luc Van Oostenryck
2017-03-02 14:33               ` Dibyendu Majumdar
2017-03-02 16:04                 ` Luc Van Oostenryck
2017-03-02 16:29                   ` Dibyendu Majumdar
2017-03-02 16:30                     ` Dibyendu Majumdar
2017-03-02 17:18                       ` Luc Van Oostenryck
2017-03-02 17:36                         ` Dibyendu Majumdar
2017-03-02 20:09                         ` Luc Van Oostenryck
2017-03-03  2:52                           ` Dibyendu Majumdar
2017-03-03  3:01                             ` Dibyendu Majumdar
2017-03-03  4:03                               ` Dibyendu Majumdar
2017-03-03  5:24                                 ` [PATCH] llvm: fix output_op_[ptr]cast() Luc Van Oostenryck
2017-03-03  7:37                                   ` Dibyendu Majumdar
2017-03-03 18:06                                     ` Dibyendu Majumdar
2017-03-03 18:30                                       ` Dibyendu Majumdar
2017-03-03 19:55                                         ` Luc Van Oostenryck
2017-03-06  1:56                                           ` Christopher Li
2017-03-03 19:50                                       ` Luc Van Oostenryck
2017-03-03 19:54                                         ` Dibyendu Majumdar
2017-03-03 20:52                                           ` [PATCH] llvm: fix: do not mix pointers and floats when doing compares Luc Van Oostenryck
2017-03-03  4:16                             ` Sparse-LLVM issue compiling NULL pointers Luc Van Oostenryck
2017-03-03  4:27                             ` Luc Van Oostenryck
2017-03-03  4:38                               ` Dibyendu Majumdar
2017-03-03  7:50                                 ` Luc Van Oostenryck
2017-03-03 12:39                                   ` Dibyendu Majumdar
2017-03-02 17:03                     ` Dibyendu Majumdar
2017-03-02 17:18                       ` Dibyendu Majumdar
2017-03-02 17:43                         ` Luc Van Oostenryck
2017-03-02 18:58                           ` Dibyendu Majumdar
2017-03-02 19:34                             ` Luc Van Oostenryck
2017-03-02 17:50                       ` Luc Van Oostenryck
2017-03-02 17:57                         ` Luc Van Oostenryck
2017-03-02 18:02                           ` Dibyendu Majumdar
2017-03-03  4:21                             ` Luc Van Oostenryck
2017-03-02 17:27                   ` Luc Van Oostenryck
2017-03-02 18:41                   ` Dibyendu Majumdar
2017-03-03  5:35                     ` Luc Van Oostenryck
2017-03-02 16:39           ` Dibyendu Majumdar
2017-03-02 17:21             ` Luc Van Oostenryck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACXZuxdav6y9uRC9mavNkVZS173k0ftw-8FpPanKLsoF-ws0Sw@mail.gmail.com \
    --to=mobile@majumdar.org.uk \
    --cc=linux-sparse@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.