All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dibyendu Majumdar <mobile@majumdar.org.uk>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>
Subject: Re: Sparse-LLVM issue compiling NULL pointers
Date: Thu, 2 Mar 2017 14:33:09 +0000	[thread overview]
Message-ID: <CACXZuxeiWM9zJZqtUC1YN6tFO6VsHkfTn9CZefr6P5nYUOpoRA@mail.gmail.com> (raw)
In-Reply-To: <20170302135655.s742zcslis5r56if@macpro.local>

Hi Luc,

On 2 March 2017 at 13:56, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Thu, Mar 02, 2017 at 05:41:59AM +0000, Dibyendu Majumdar wrote:
>> On 2 March 2017 at 05:21, Luc Van Oostenryck
>> <luc.vanoostenryck@gmail.com> wrote:
>> >> Anyway have hit a bunch of other issues with sparse-llvm ... :-(
>> >
>> > Each day its problem (and happily its solution too!).
>> >
>>
>> I will submit test cases for the new problems when I get some time.
>

Below is an example that fails for me. I am running a modified version
of Sparse although the modifications are to do with a) removing global
state and b) compiling with Visual C++ on Windows 10 - and all sparse
tests pass so I don't think they have anything to do with the failure
here. I do have Linux build of sparse but without LLVM so I will need
to sort that out to test. Anyway, I would be interested to know if you
get a failure (you will need to have LLVM assertions enabled).

typedef unsigned long long size_t;
struct buffer_type_st {
 struct buffer_type_st    *next_buffer;
 char           *buffer;
};
typedef struct buffer_type_st buffer_type_t;
struct link_st {
 struct link_st           *next;
};
typedef struct link_st link_t;
struct allocator_st {
 buffer_type_t    *buffer_list;
 link_t           *free_list;
 char           *next_avail;
 char           *last;
 size_t          size;
 size_t          n;
};
typedef struct allocator_st allocator;
extern void
grow_allocator(allocator * a);
extern void *
malloc(size_t size);
void
grow_allocator(allocator * a)
{
 buffer_type_t    *tmp;
 tmp = (buffer_type_t *) malloc(sizeof(buffer_type_t));
 tmp->buffer = (char *) malloc(a->size * a->n);
 tmp->next_buffer = a->buffer_list;
 a->buffer_list = tmp;
 a->next_avail = a->buffer_list->buffer;
 a->last = a->next_avail + (a->size * a->n);
}


The failure occurs in the line:

 a->next_avail = a->buffer_list->buffer;

I am guessing it has to do with the nested member access but I have
not yet been able to work out what the code is doing.

LLVM gives me following error:

Assertion failed: S->getType()->isPtrOrPtrVectorTy() && "Invalid
cast", file C:\d\llvm-3.9.0.src\lib\IR\Instructions.cpp, line 2759

This occurs in calc_memop_addr() function when it tries to do following:

 as = LLVMGetPointerAddressSpace(LLVMTypeOf(src));

If I dump insn, insn->src, and the LLVM value and type before this line, I get:

1) insn load.64     %r18 <- 8[%r2]
2) pseudo %r2
3) store %struct.buffer_type_st* %R2, %struct.buffer_type_st** %26
4) void

The type of the LLVM store instruction is 'void'.

My guess is that something is going horribly wrong in the way member
access is handled.

If you are able to reproduce this and have any suggestions then please
let me know.

Thanks and Regards
Dibyendu

  parent reply	other threads:[~2017-03-02 14:34 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28  6:20 Sparse-LLVM issue compiling NULL pointers Dibyendu Majumdar
2017-02-28 15:09 ` 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 [this message]
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=CACXZuxeiWM9zJZqtUC1YN6tFO6VsHkfTn9CZefr6P5nYUOpoRA@mail.gmail.com \
    --to=mobile@majumdar.org.uk \
    --cc=linux-sparse@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    /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.