Bug 206066 - base/projects/clang380-import's clang crashed targeting armv6 and requested a submittal [test involved use of -Oz]
Summary: base/projects/clang380-import's clang crashed targeting armv6 and requested a...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-09 10:32 UTC by Mark Millard
Modified: 2020-03-08 02:38 UTC (History)
0 users

See Also:


Attachments
.zip of the /tmp/*.c and *.sh that clang left for the report (354.47 KB, application/zip)
2016-01-09 10:32 UTC, Mark Millard
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-01-09 10:32:00 UTC
Created attachment 165306 [details]
.zip of the /tmp/*.c and *.sh that clang left for the report

I tried -Oz (for smaller code) to see if I could get linking involving cc1_main to work for armv6 during buildworld of -r293430 (amd64 cross build targeting armv6). clang crashed and requested a submittal. (buildworld gets relocation truncations while linking and stops with default optimizations in my context.)

# gdb clang /var/crash/clang.40580.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
. . .
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `clang'.
Program terminated with signal 6, Aborted.
#0  0x00000000026550aa in thr_kill ()
[New Thread 80381b000 (LWP 100729/<unknown>)]
(gdb) bt
#0  0x00000000026550aa in thr_kill ()
#1  0x0000000002655086 in raise ()
#2  0x0000000002655046 in abort ()
#3  0x000000000267497a in __assert ()
#4  0x00000000022aa13c in llvm::CallGraphNode::~CallGraphNode ()
#5  0x00000000022aa1ad in std::__1::__tree<std::__1::__value_type<llvm::Function const*, std::__1::unique_ptr<llvm::CallGraphNode, std::__1::default_delete<llvm::CallGraphNode> > >, std::__1::__map_value_compare<llvm::Function const*, std::__1::__value_type<llvm::Function const*, std::__1::unique_ptr<llvm::CallGraphNode, std::__1::default_delete<llvm::CallGraphNode> > >, std::__1::less<llvm::Function const*>, true>, std::__1::allocator<std::__1::__value_type<llvm::Function const*, std::__1::unique_ptr<llvm::CallGraphNode, std::__1::default_delete<llvm::CallGraphNode> > > > >::erase
    ()
#6  0x00000000022a8020 in llvm::CallGraph::removeFunctionFromModule ()
#7  0x00000000014e943b in llvm::Inliner::removeDeadFunctions ()
#8  0x00000000021d3b58 in (anonymous namespace)::CGPassManager::runOnModule ()
#9  0x00000000024149be in llvm::legacy::PassManagerImpl::run ()
#10 0x0000000000672910 in clang::EmitBackendOutput ()
#11 0x0000000000670569 in clang::BackendConsumer::HandleTranslationUnit ()
#12 0x000000000087c462 in clang::ParseAST ()
#13 0x000000000043f709 in clang::FrontendAction::Execute ()
#14 0x0000000000461e21 in clang::CompilerInstance::ExecuteAction ()
#15 0x0000000000409fc6 in clang::ExecuteCompilerInvocation ()
#16 0x00000000004008ae in cc1_main (Argv0=0x7fffffffda70 "/usr/bin/clang", MainAddr=0x405650) at /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:116
#17 0x000000000040831e in main (argc_=<value optimized out>, argv_=<value optimized out>) at /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/driver.cpp:301
#18 0x000000000040031f in _start ()
Comment 1 Mark Millard 2020-03-08 02:38:00 UTC
Even if an analogous problem existing in llvm9 or later,
the evidence from this far back would be of little help.

I'm closing this report as Overcome By Events.