llvm dev - Feb 2013 - [LLVMdev] Possible issue with DenseMap when using AliasSetTracker

Dear All,

while willing to assist developers to adhere strictly to coding guidelines, I
wrote the attached program called "alias-detector". The program's
intent is to
utilize the BasicAliasAnalysis to get a list of aliases for each pointer in a
certain program code. First it initializes clang as frontend, executes the
EmitLLVMOnlyAction, and then processes the produced Module with the following
three passes:
1. BasicAliasAnalysis -- The basic alias analysis
2. AliasTrackerPass -- BasicBlockPass that creates an AliasSet for each pointer
in the analyzed code (line 261 and line 94 respectively)
3. AliasDetectorPass -- BasicBlockPass that prints the AliasSet of each pointer
in the analyzed code (line 264 and line 133 respectively)

The first Pass seems to work flawlessly. However, the 2nd Pass fails due to a
segmentation fault that somehow seems to be related to the DenseMap data
structure. However, I wasn't able to pin down the issue. Accordingly,
I'd like
to ask for an advise. Maybe someone with more knowledge of the code basis could
have a closer look on the topic and could tell whether this is really an issue
of the DenseMap or me using it incorrectly.

I'm currently using llvm and clang in release version 3.2.
Please find attached the "alias-detector" program and its backtrace.

Best regards
Oliver Horst
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alias-detector.cpp
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/6eefc12c/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: backtrace.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/6eefc12c/attachment.txt>

Oliver Horst wrote:
> Dear All,
>
> while willing to assist developers to adhere strictly to coding guidelines,
I
> wrote the attached program called "alias-detector". The
program's intent is to
> utilize the BasicAliasAnalysis to get a list of aliases for each pointer in
a
> certain program code. First it initializes clang as frontend, executes the
> EmitLLVMOnlyAction, and then processes the produced Module with the
following
> three passes:
> 1. BasicAliasAnalysis -- The basic alias analysis
> 2. AliasTrackerPass -- BasicBlockPass that creates an AliasSet for each
pointer
> in the analyzed code (line 261 and line 94 respectively)
> 3. AliasDetectorPass -- BasicBlockPass that prints the AliasSet of each
pointer
> in the analyzed code (line 264 and line 133 respectively)
>
> The first Pass seems to work flawlessly. However, the 2nd Pass fails due to
a
> segmentation fault that somehow seems to be related to the DenseMap data
> structure. However, I wasn't able to pin down the issue. Accordingly,
I'd like
> to ask for an advise. Maybe someone with more knowledge of the code basis
could
> have a closer look on the topic and could tell whether this is really an
issue
> of the DenseMap or me using it incorrectly.
>
> I'm currently using llvm and clang in release version 3.2.
> Please find attached the "alias-detector" program and its
backtrace.
The problem is that you never added a DataLayout object to the 
PassManager (it's an ImmutablePass) and AliasSetTracker appears to be 
assuming you have one.

However, I don't see such a bug with llvm on trunk, and the line numbers 
don't line up. Perhaps this has already been fixed?

Nick

Dear Nick,

I followed your advise and added a DataLayout Pass, as well as updated to the
trunk version of llvm and clang.
However, the issue stays the same.

Please find attached the updated program source  and backtrace.

Best Regards
Oliver
> -----Ursprüngliche Nachricht-----
> Von: Nick Lewycky [mailto:nicholas at mxc.ca]
> Gesendet: Montag, 11. Februar 2013 11:19
> An: Oliver Horst
> Cc: llvmdev at cs.uiuc.edu
> Betreff: Re: [LLVMdev] Possible issue with DenseMap when using
> AliasSetTracker
> 
> Oliver Horst wrote:
> > Dear All,
> >
> > while willing to assist developers to adhere strictly to coding
> > guidelines, I wrote the attached program called
"alias-detector". The
> > program's intent is to utilize the BasicAliasAnalysis to get a
list of
> > aliases for each pointer in a certain program code. First it
> > initializes clang as frontend, executes the EmitLLVMOnlyAction, and
> > then processes the produced Module with the following three passes:
> > 1. BasicAliasAnalysis -- The basic alias analysis 2. AliasTrackerPass
> > -- BasicBlockPass that creates an AliasSet for each pointer in the
> > analyzed code (line 261 and line 94 respectively) 3. AliasDetectorPass
> > -- BasicBlockPass that prints the AliasSet of each pointer in the
> > analyzed code (line 264 and line 133 respectively)
> >
> > The first Pass seems to work flawlessly. However, the 2nd Pass fails
> > due to a segmentation fault that somehow seems to be related to the
> > DenseMap data structure. However, I wasn't able to pin down the
issue.
> > Accordingly, I'd like to ask for an advise. Maybe someone with
more
> > knowledge of the code basis could have a closer look on the topic and
> > could tell whether this is really an issue of the DenseMap or me using
it
> incorrectly.
> >
> > I'm currently using llvm and clang in release version 3.2.
> > Please find attached the "alias-detector" program and its
backtrace.
> 
> The problem is that you never added a DataLayout object to the PassManager
> (it's an ImmutablePass) and AliasSetTracker appears to be assuming you
have
> one.
> 
> However, I don't see such a bug with llvm on trunk, and the line
numbers don't
> line up. Perhaps this has already been fixed?
> 
> Nick
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alias-detector.cpp
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130211/cf63092b/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: backtrace.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130211/cf63092b/attachment.txt>