llvm dev - Mar 2006 - [LLVMdev] Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM

On Wed, 15 Mar 2006, Vladimir Prus wrote:
>> Please give it a try and let me know if it works any better for you!
>
> Here we go:
Wow, you are good at finding problems!  Thanks!
> -fvisibility=hidden -DHIDE_EXPORTS
> -c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o
> cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void
> llvm::AllocationInst::setAlignment(unsigned int): Assertion `(Align &
> (Align-1)) == 0 && "Alignment is not a power of 2!"'
failed.
> ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c: In function
'__fixunsxfdi':
> ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c:1205: internal compiler error:
> Aborted
> Please submit a full bug report,
> with preprocessed source if appropriate.
I can't reproduce this on darwin-ppc or darwin-x86, so this is a stab in 
the dark.  Can you try this patch:

==================================================================--- i386.h    
(revision 112156)
+++ i386.h      (working copy)
@@ -764,7 +764,13 @@ extern int x86_prefetch_sse;


  /* target machine storage layout */

+/* APPLE LOCAL begin LLVM */
+#ifdef ENABLE_LLVM
+#define LONG_DOUBLE_TYPE_SIZE 64
+#else
  #define LONG_DOUBLE_TYPE_SIZE 80
+#endif
+/* APPLE LOCAL end LLVM */

  /* Set the value of FLT_EVAL_METHOD in float.h.  When using only the
     FPU, assume that the fpcw is set to extended precision; when using


Applied to gcc/gcc/config/i386/i386.h

If that doesn't help, please send me a stack trace of the crash.  To do 
this, pass -v to the failing GCC command line, then debug the cc1 
invocation.  In addition, please go up to the first stack frame with a GCC 
tree, and 'call debug_tree(exp)' on it from within GDB.  That will help
me
understand what is going on.

Thanks, sorry this is taking so many iterations. :(

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Hi,

Here is the follow on patch for this problem. Please apply this from  
the top of the tree and rebuild.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: op
Type: application/octet-stream
Size: 2548 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060315/eee8a766/attachment.obj>
-------------- next part --------------

Thanks,

Evan

On Mar 15, 2006, at 10:01 AM, Chris Lattner wrote:
> On Wed, 15 Mar 2006, Vladimir Prus wrote:
>>> Please give it a try and let me know if it works any better for
you!
>>
>> Here we go:
>
> Wow, you are good at finding problems!  Thanks!
>
>> -fvisibility=hidden -DHIDE_EXPORTS
>> -c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./ 
>> _fixunsxfdi.o
>> cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h: 
>> 72: void
>> llvm::AllocationInst::setAlignment(unsigned int): Assertion `(Align
&
>> (Align-1)) == 0 && "Alignment is not a power of
2!"' failed.
>> ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c: In function  
>> '__fixunsxfdi':
>> ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c:1205: internal compiler  
>> error:
>> Aborted
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>
> I can't reproduce this on darwin-ppc or darwin-x86, so this is a  
> stab in the dark.  Can you try this patch:
>
> ==================================================================> ---
i386.h      (revision 112156)
> +++ i386.h      (working copy)
> @@ -764,7 +764,13 @@ extern int x86_prefetch_sse;
>
>
>  /* target machine storage layout */
>
> +/* APPLE LOCAL begin LLVM */
> +#ifdef ENABLE_LLVM
> +#define LONG_DOUBLE_TYPE_SIZE 64
> +#else
>  #define LONG_DOUBLE_TYPE_SIZE 80
> +#endif
> +/* APPLE LOCAL end LLVM */
>
>  /* Set the value of FLT_EVAL_METHOD in float.h.  When using only the
>     FPU, assume that the fpcw is set to extended precision; when using
>
>
> Applied to gcc/gcc/config/i386/i386.h
>
> If that doesn't help, please send me a stack trace of the crash.   
> To do this, pass -v to the failing GCC command line, then debug the  
> cc1 invocation.  In addition, please go up to the first stack frame  
> with a GCC tree, and 'call debug_tree(exp)' on it from within GDB.
> That will help me understand what is going on.
>
> Thanks, sorry this is taking so many iterations. :(
>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Evan Cheng wrote:
> Hi,
> 
> Here is the follow on patch for this problem. Please apply this from
> the top of the tree and rebuild.
With the patch from Chris and then the patch from you combined, the previous
error disappeared, but I get another error, reduced to this:

 ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro
-auxbase-strip libgcc/./_clz.o -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fPIC -fvisibility=hidden -o libgcc2.s
.....
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

And this time the crash does not seem very misterious:


Program received signal SIGSEGV, Segmentation fault.
llvm::PATypeHolder::get (this=0x8) at Type.h:249
249       const Type *getForwardedType() const {

(gdb) where
#0  llvm::PATypeHolder::get (this=0x8) at Type.h:249
#1  0x08514f1f in llvm::PATypeHolder::operator llvm::Type* (this=0x8) at
AbstractTypeUser.h:140
#2  0x08514734 in llvm::Value::getType (this=0x0) at Value.h:76
#3  0x087a8f8a in ConstantStruct (this=0x8b28038, T=0x8b25730,
V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:275
#4  0x087e9058 in llvm::ConstantCreator<llvm::ConstantStruct,
llvm::StructType, std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> > >::create (Ty=0x8b25730,
V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:531
#5  0x087e6eaf in (anonymous
namespace)::ValueMap<std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> >, llvm::StructType,
llvm::ConstantStruct,
true>::getOrCreate (this=0x8af8060,
    Ty=0x8b25730, V=@0xbf8adef0)
at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:624
#6  0x087aa821 in llvm::ConstantStruct::get (Ty=0x8b25730, V=@0xbf8adef0)
    at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:994
#7  0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834,
DD=0x8b54480)
    at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204

The real problem is this:

#7  0x08714182 in llvm::DISerializer::Serialize (this=0x8b17834,
DD=0x8b54480)
    at /home/ghost/Work/llvm-cvs/lib/CodeGen/MachineDebugInfo.cpp:1204
1204      GV->setInitializer(ConstantStruct::get(Ty, Elements));
(gdb) p Elements[2]
$7 = (class llvm::Constant * const&) @0x8afbcf0: 0x0

This null pointer comes from line 274 of MachineDebugInfo.cpp:

  virtual void Apply(std::string &Field) {
    if (Field.empty()) {
      Elements.push_back(NULL);
    } else {
      Elements.push_back(SR.getString(Field));
    }
  }

Which comes from this:

  void TypeDesc::ApplyToFields(DIVisitor *Visitor) {
    DebugInfoDesc::ApplyToFields(Visitor);
  
    Visitor->Apply(Context);
    Visitor->Apply(Name);

Name is empty. Here's a minimal testcase that reproduces the crash:

   unsigned __clz_tab[] = {0};

just invoke cc1 as given in the beginning of this email with this text as
input. 

The problem is that llvm-debug.cpp:GetNodeName returns "" for the name
of
type of "__clz_tab", which is the root cause of the crash. I don't
know why
TYPE_NAME returns NULL, but I attach two possible patches.

First one just special cases arrays and integer variables. Again, don't know
why, but TYPE_NAME returns 0 even if 'tree' is a 'unsigned'
type.

Second one makes GetNodeName return non-empty string if it fails to
determine the name.

Neither patch is reasonable, but at least we know the problem. Now I get
crash in this (minimal) testcase:

   struct gcov_info
   {
      const char *filename;
   };

   struct gcov_info gcov_list;

This time the crash happens because DerivedTypeDesc corresponding to 
   DW_TAG_const_type<
         char*
   >
has no name. What follows from that is already explained above.

So, it looks either the snapshot is not in stable state, or there's
something seriously wrong with type name handling. At this point I gave up
on quickly fixing this, so I've applied the third attached patch to LLVM,
which "fixes" this issue completely.

After that, the frontend itself builds (the gcc directory), and "llvm-g++
-emit-llvm -S some_file.cpp") works. I did not do deep testing.

On the other hand, I still get segfaults when building libstdc++. I'll look
at them as soon as this "type name in debug info" is solved or
workarounded
either in LLVM CVS or in your frontend.

Sorry for the long email, this is basically a debugging log ;-)


- Volodya



-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-debug-patch1.diff
Type: text/x-diff
Size: 2063 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060316/3e705068/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-debug-patch2.diff
Type: text/x-diff
Size: 328 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060316/3e705068/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-debug-patch3.diff
Type: text/x-diff
Size: 606 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060316/3e705068/attachment-0002.diff>