[llvm-bugs] [Bug 31005] inline asm global registers compatibility to gcc+icc
https://llvm.org/bugs/show_bug.cgi?id=31005 Renato Golin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Renato Golin --- Closing this as wontfix because that's our community's current position. If anyone wants to change this position they'll have to: 1. Create a downstream prototype where registers can be allocated and deallocated by the user on a function and module scope without destroying the register allocators (plural) job. 2. Send an RFC to the list, with the design decisions taken to make that work, and work with the community to adapt your downstream implementation to work that way. 3. After addressing all the community's feedback, send a list of small and incremental patches, implementing the functionality with enough tests to cover each step, and making sure none of them break the build on their own, ie. isolated and working changes. 4. Work with the community to push the patches upstream, address reviews, etc. As it stands, the community doesn't need, nor want, arbitrary global named registers, so don't expect people to implement that for you. We have successfully convinced users to change their code, and most of the time to better code, proving that this feature is not needed at all. If it is needed for you, and you can show that to the community, you'll have to go through the proper upstreaming process described above. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 16877] Global register variable support
https://llvm.org/bugs/show_bug.cgi?id=16877 Renato Golin changed: What|Removed |Added Status|NEW |RESOLVED CC||renato.go...@linaro.org Resolution|--- |WONTFIX --- Comment #2 from Renato Golin --- See Bug #31005 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24369] fatal error: error in backend: Invalid register name "r8"
https://llvm.org/bugs/show_bug.cgi?id=24369 Renato Golin changed: What|Removed |Added Status|NEW |RESOLVED CC||renato.go...@linaro.org Resolution|--- |DUPLICATE --- Comment #3 from Renato Golin --- *** This bug has been marked as a duplicate of bug 31005 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 16877] Global register variable support
https://llvm.org/bugs/show_bug.cgi?id=16877 Renato Golin changed: What|Removed |Added Resolution|WONTFIX |DUPLICATE --- Comment #3 from Renato Golin --- *** This bug has been marked as a duplicate of bug 31005 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25899] Loads and Stores are not always coalesced
https://llvm.org/bugs/show_bug.cgi?id=25899 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||apilipe...@azulsystems.com, ||llvm-...@redking.me.uk Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- Fixed in rL289538 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 17603] x86: optimize byte+shift load to unaligned load
https://llvm.org/bugs/show_bug.cgi?id=17603 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||apilipe...@azulsystems.com, ||llvm-...@redking.me.uk Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Fixed in rL289538 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31369] New: Register allocator uses reserved register on MIPS
https://llvm.org/bugs/show_bug.cgi?id=31369 Bug ID: 31369 Summary: Register allocator uses reserved register on MIPS Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: simon.dar...@imgtec.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17752 --> https://llvm.org/bugs/attachment.cgi?id=17752&action=edit Reproduction case as test. The issue demonstrated in the attached test case is the use of a reserved single precision floating point register. One of MIPS' floating point ABIs requires that the odd single precision registers are not used. >From the test case (lines 17-21): %5 = load float, float * @f1 %6 = insertelement <4 x float> undef,float %5, i32 0 %7 = insertelement <4 x float> %6,float %5, i32 1 %8 = insertelement <4 x float> %7,float %5, i32 2 %9 = insertelement <4 x float> %8,float %5, i32 3 After the processing of implicit defs: .. 96B %vreg4 = LWC1 %vreg3, [TF=5]; mem:LD4[@f1](dereferenceable) FGR32:%vreg4 GPR32:%vreg3 112B%vreg12:sub_lo = COPY %vreg4; MSA128W:%vreg12 FGR32:%vreg4 128B%vreg5 = SPLATI_W %vreg12, 0; MSA128W:%vreg5,%vreg12 .. This code is correct as FGR32 has the correct reserved registers. After the joining live intervals: .. 96B %vreg12:sub_lo = LWC1 %vreg3, [TF=5]; mem:LD4[@f1](dereferenceable) MSA128B:%vreg12 GPR32:%vreg3 128B%vreg5 = SPLATI_W %vreg12, 0; MSA128W:%vreg5 MSA128B:%vreg12 .. Here, the copy has been coalesced into the load which is using the sub_lo of a register in the MSA128B class. The greedy register allocator then bases the allocation choice on the MSA128B register class and picks an odd MSA register %W1 and uses the corresponding single precision subregister $F1: .. selectOrSplit MSA128B:%vreg12 [96r,128r:0) 0@96r w=INF assigning %vreg12 to %W1: F1 [96r,128r:0) 0@96r F_HI1 [96r,128r:0) 0@96r .. If the output is emitted directly as an object file, it silently succeeds. Passing the resulting assembly to external assembler results in a bad code. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31370] New: Assertion failed: "Cannot get layout of forward declarations!"
https://llvm.org/bugs/show_bug.cgi?id=31370 Bug ID: 31370 Summary: Assertion failed: "Cannot get layout of forward declarations!" Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: tras...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified typedef struct _IMAGE_RUNTIME_FUNCTION_ENTRY RUNTIME_FUNCTION, PRUNTIME_FUNCTION; PRUNTIME_FUNCTION RtlLookupFunctionEntry( ); $ clang.exe -cc1 -v -triple x86_64-pc-windows-msvc19.0.0 -emit-llvm test.cpp clang -cc1 version 4.0.0 based upon LLVM 4.0.0svn-r289649 default target x86_64-pc-windows-msvc #include "..." search starts here: End of search list. Assertion failed: D && "Cannot get layout of forward declarations!", file ..\tools\clang\lib\AST\RecordLayoutBuilder.cpp, line 2933 0x000141643824 (0x0008 0x 0x00151470 0x), clang::ASTContext::getASTRecordLayout() + 0x84 bytes(s), tools\clang\lib\ast\recordlayoutbuilder.cpp, line 2934 0x0001415F65B5 (0x001518C8 0x00163430 0x0008 0x), clang::ASTContext::getTypeInfoImpl() + 0x805 bytes(s), tools\clang\lib\ast\astcontext.cpp, line 1865 0x0001415F5B80 (0x00165870 0x 0x0015C580 0x0015C4E8), clang::ASTContext::getTypeInfo() + 0xB0 bytes(s), tools\clang\lib\ast\astcontext.cpp, line 1604 0x0001415F5874 (0x0015C580 0x00B2C8F0 0x0015C4E8 0x00146C98), clang::ASTContext::getTypeAlignInChars() + 0x34 bytes(s), tools\clang\lib\ast\astcontext.cpp, line 1977 + 0x15 byte(s) 0x000140425B5C (0x 0x02A89FD0 0x00147DD0 0x), `anonymous namespace'::MicrosoftCXXABI::classifyReturnType() + 0xAC bytes(s), tools\clang\lib\codegen\microsoftcxxabi.cpp, line 1101 0x000140395CD7 (0x 0x00B2C9A8 0x00B2C830 0x), `anonymous namespace'::WinX86_64ABIInfo::computeInfo() + 0x57 bytes(s), tools\clang\lib\codegen\targetinfo.cpp, line 3771 + 0xA byte(s) 0x000140376B0F (0x0015C580 0x0015C580 0x00B2C900 0x0015C6F0), clang::CodeGen::CodeGenTypes::arrangeLLVMFunctionInfo() + 0x2FF bytes(s), tools\clang\lib\codegen\cgcall.cpp, line 711 0x0001403767D2 (0x0015C6F0 0x00010001 0x 0x0015C6F0), arrangeLLVMFunctionInfo() + 0x252 bytes(s), tools\clang\lib\codegen\cgcall.cpp, line 153 + 0x8A byte(s) 0x000140375FAE (0x0015C6F0 0x0015C6F0 0x0134 0x0066), clang::CodeGen::CodeGenTypes::arrangeFreeFunctionType() + 0x3E bytes(s), tools\clang\lib\codegen\cgcall.cpp, line 165 + 0x5 byte(s) 0x0001403763E4 (0x00164778 0x0001 0x0015C6F0 0x), clang::CodeGen::CodeGenTypes::arrangeFunctionDeclaration() + 0x404 bytes(s), tools\clang\lib\codegen\cgcall.cpp, line 404 + 0x53 byte(s) 0x00014037656F (0x0001 0x02A89FD0 0x02A89FD0 0x02A89FD0), clang::CodeGen::CodeGenTypes::arrangeGlobalDeclaration() + 0x15F bytes(s), tools\clang\lib\codegen\cgcall.cpp, line 471 + 0xB byte(s) 0x000140310290 (0x0001 0x02A89FD0 0x 0x00B2D268), clang::CodeGen::CodeGenModule::EmitGlobal() + 0x260 bytes(s), tools\clang\lib\codegen\codegenmodule.cpp, line 1600 0x000140312F94 (0x0001 0x02A89FD0 0x02A89FD0 0x000140C9C8C0), clang::CodeGen::CodeGenModule::EmitTopLevelDecl() + 0xE4 bytes(s), tools\clang\lib\codegen\codegenmodule.cpp, line 3679 0x00014195EC5F (0x02A89FD0 0x02A89FD0 0x00B0 0x), `anonymous namespace'::CodeGeneratorImpl::HandleTopLevelDecl() + 0x12F bytes(s), tools\clang\lib\codegen\modulebuilder.cpp, line 148 + 0xF byte(s) 0x00014195CA85 (0x00163DB0 0x02A89FD0 0x 0x0016DF20), clang::BackendConsumer::HandleTopLevelDecl() + 0xF5 bytes(s), tools\clang\lib\codegen\codegenaction.cpp, line 133 0x000140C956B6 (0x00B2E300 0x 0x000F8370 0x02A89FD0), clang::ParseAST() -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31371] New: crash handler does not find pdb when built with /PDBALTPATH:%_PDB%
https://llvm.org/bugs/show_bug.cgi?id=31371 Bug ID: 31371 Summary: crash handler does not find pdb when built with /PDBALTPATH:%_PDB% Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: tras...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When clang is built with /PDBALTPATH:%_PDB% a relative pdb path is inserted into the executable (i.e. just "clang.pdb"). Then it only prints: Assertion failed: Wrote crash dump file ".dmp" #0 0x000140b30d95 (clang.exe+0xb90d95) #1 0x0001421d547e (clang.exe+0x223547e) ... No stacktrace like without the option: 0x000140148A75 (0x000142573720 0x00B2BAF4 0x00B2B898 0x0001417F2C7B), HandleAbort() + 0x5 bytes(s), lib\support\windows\signals.inc, line 404 0x0001417F301E (0x00B2BD01 0x0001 0x0001 0x), raise() + 0x25E bytes(s), d:\th\minkernel\crts\ucrt\src\appcrt\misc\signal.cpp, line 516 + 0x5 byte(s) 0x0001417E038C (0x0007 0x00B2BF01 0x0001422DECD0 0x0001422B3730), abort() + 0x18 bytes(s), d:\th\minkernel\crts\ucrt\src\appcrt\startup\abort.cpp, line 71 0x0001417DFDF4 (0x 0x 0x 0x76F20996), common_assert_to_stderr() + 0xC8 bytes(s), d:\th\minkernel\crts\ucrt\src\appcrt\startup\assert.cpp, line 138 + 0x84 byte(s) 0x0001417DFF16 (0x0015C4E8 0x00B2BF30 0x00151470 0x), _wassert() + 0x72 bytes(s), d:\th\minkernel\crts\ucrt\src\appcrt\startup\assert.cpp, line 404 + 0x13 byte(s) .. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30945] [AVX512] Failure to flip vector comparison to remove not mask instruction
https://llvm.org/bugs/show_bug.cgi?id=30945 michael changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from michael --- fix in revision 289653 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31372] New: llvm-lib (and `lld-link /lib`) should error out on cl.exe LTCG obj files
https://llvm.org/bugs/show_bug.cgi?id=31372
Bug ID: 31372
Summary: llvm-lib (and `lld-link /lib`) should error out on
cl.exe LTCG obj files
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In https://crbug.com/672229 we accidentally built some of our object files with
cl.exe /GL (which activates their link-time codegen, so .obj files are some
kind of IR, not a real .obj file).
C:\src\llvm-build-2015-mt>type a.cc
void f();
int main() {
f();
}
C:\src\llvm-build-2015-mt>type b.cc
void f() {
}
C:\src\llvm-build-2015-mt>bin\clang-cl.exe /c a.cc
C:\src\llvm-build-2015-mt>cl /c b.cc /GL /nologo
b.cc
In general, lld-link copes well with this:
C:\src\llvm-build-2015-mt>bin\lld-link.exe a.obj b.obj
error: b.obj: is not a native COFF file. Recompile without /GL
C:\src\llvm-build-2015-mt>lib /out:blib.lib b.obj /nologo /ltcg
C:\src\llvm-build-2015-mt>bin\lld-link.exe a.obj blib.lib
error: unknown file type: blib.lib
However, llvm-lib silently produces an empty lib file, which then leads to
confusing error messages with both lld-link.exe and link.exe:
C:\src\llvm-build-2015-mt>lld-link.exe /lib b.obj /out:blib2.lib
C:\src\llvm-build-2015-mt>bin\lld-link.exe a.obj blib2.lib
a.obj: undefined symbol: ?f@@YAXXZ
error: link failed
C:\src\llvm-build-2015-mt>link.exe a.obj blib2.lib /nologo
blib2.lib : warning LNK4003: invalid library format; library ignored
a.obj : error LNK2019: unresolved external symbol "void __cdecl f(void)"
(?f@@YAXXZ) referenced in function main
a.exe : fatal error LNK1120: 1 unresolved externals
llvm-lib should print some error and fail when fed LTCG'd obj files instead of
silently doing the wrong thing.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31216] spill inserted in between the marker and the _objc_retainAutoreleasedReturnValue
https://llvm.org/bugs/show_bug.cgi?id=31216 Saleem Abdulrasool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31366] Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
https://llvm.org/bugs/show_bug.cgi?id=31366 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED CC||nicolaswe...@gmx.de Resolution|--- |FIXED --- Comment #3 from Nico Weber --- r289678 apparently -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31373] New: -Wunused-variable does not detect unused condition variable
https://llvm.org/bugs/show_bug.cgi?id=31373
Bug ID: 31373
Summary: -Wunused-variable does not detect unused condition
variable
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
-Wunused-variable does not warn on this case:
bool f();
void g() {
if (bool b = f()) {
// ...
}
}
GCC's version of the warning does. Presumably we're marking the variable as
'used' in the condition handling code; while that's technically correct, it
doesn't lead to the right outcome here.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28286] gcc POWER include headers- e.g. ppc-asm.h to be in clang
https://llvm.org/bugs/show_bug.cgi?id=28286 Eric Christopher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Eric Christopher --- Since this is a non-standard header I'm going to mark this as wontfix. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31374] New: Regression(likely r289252): Assertion failed: (T->getAs() && "Invalid type"), function isPointerZeroInitializable when building chrome code
https://llvm.org/bugs/show_bug.cgi?id=31374 Bug ID: 31374 Summary: Regression(likely r289252): Assertion failed: (T->getAs() && "Invalid type"), function isPointerZeroInitializable when building chrome code Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified Seeing this on a chromium bot: FAILED: .../gtm_session_fetcher/gtm_session_fetcher/GTMSessionFetcher.o /b/build/slave/cache/cipd/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF ...GTMSessionFetcher.o.d -DV8_DEPRECATION_WARNINGS -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=289575-1 -DCR_XCODE_VERSION=0810 -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -I../../gtm_session_fetcher/Source -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fcolor-diagnostics -arch x86_64 -O0 -gdwarf-2 -isysroot /b/build/slave/trunk-autoroller/build/src/build/mac_files/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.1.sdk -stdlib=libc++ -mios-simulator-version-min=9.0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Werror -Wall -Wno-unused-variable -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -std=c99 -fobjc-arc -Wno-error=deprecated-declarations -c ../../gtm_session_fetcher/Source/GTMSessionFetcher.m -o gtm_session_fetcher/GTMSessionFetcher.o Assertion failed: (T->getAs() && "Invalid type"), function isPointerZeroInitializable, file /b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp, line 740. 0 clang0x00010570dbd6 llvm::sys::PrintStackTraceOnErrorSignal(llvm::StringRef, bool) + 950 1 libsystem_platform.dylib 0x7fff9d49f52a _sigtramp + 26 Stack dump: ../..gtm_session_fetcher/Source/GTMSessionFetcher.m 1.../../gtm_session_fetcher/Source/GTMSessionFetcher.m:3866:1: current parser token '@' 2.../../gtm_session_fetcher/Source/GTMSessionFetcher.m:192:1: LLVM IR generation of declaration 'GTMSessionFetcher::load' clang: error: unable to execute command: Abort trap: 6 clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 4.0.0 (trunk 289575) Target: x86_64-apple-darwin15.6.0 Thread model: posix InstalledDir: /b/build/slave/trunk-autoroller/build/src/out/Debug-iphonesimulator/../../third_party/llvm-build/Release+Asserts/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31375] New: segmentation fault on build
https://llvm.org/bugs/show_bug.cgi?id=31375
Bug ID: 31375
Summary: segmentation fault on build
Product: clang
Version: trunk
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: vbeff...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17753
--> https://llvm.org/bugs/attachment.cgi?id=17753&action=edit
preprocesses file, shell script and stack trace as instructed
I get a segfault when building the attached file.
Line 430124 in the cpp file, replacing {{T(1)}} with {T(1)} makes it compile
fine.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31016] r286884 breaks the build when compiling with an older clang
https://llvm.org/bugs/show_bug.cgi?id=31016 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Fiselier --- Re-committed in r289708. The failing test was XFAIL'ed with Clang-3.7 since that is the last Clang release to show the behavior mentioned in this bug report. @Vedant please do not revert this again due to that failing test. If you need the test marked as XFAIL for your clang version please email or PM me. I know you said your Clang reported as 3.8 but I can't XFAIL this test for 3.8 because actual 3.8 clang works. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23841] uses-allocator construction for std::pair broken
https://llvm.org/bugs/show_bug.cgi?id=23841 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Eric Fiselier --- Fixed in r289710 (Clang 4.0). -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24075] scoped_allocator_adaptor lacks the std::pair construct() overloads!
https://llvm.org/bugs/show_bug.cgi?id=24075 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED CC||e...@efcs.ca Resolution|--- |FIXED Assignee|mclow.li...@gmail.com |e...@efcs.ca --- Comment #2 from Eric Fiselier --- Fixed in r289710 (Clang 4.0). -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31376] New: Segmentation fault at _tree:1098 with -O2 in Mac OS X clang++
https://llvm.org/bugs/show_bug.cgi?id=31376
Bug ID: 31376
Summary: Segmentation fault at _tree:1098 with -O2 in Mac OS X
clang++
Product: libc++
Version: 3.7
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: i...@yoichihirai.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
When I assign a temporary std::map object into an already existing
map, the executable compiled with -O2 causes a segmentation fault. The same
problem happens with std::map. Here u256 denotes a class in
boost::multiprecision.
The OS and the compiler versions:
$ uname -a
Darwin Yoichis-Air.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Sep 1
15:01:16 PDT 2016; root:xnu-3248.60.11~2/RELEASE_X86_64 x86_64
$ clang++ --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
The program that causes the problem:
$ cat main.cpp
#include
#include
#include
int main()
{
using namespace::std;
using u256 =
boost::multiprecision::number>;
map k = {{1, 131264}};
k = {};
cout << "passed" << endl << flush;
return 0;
}
I can observe a segmentation fault with -O2.
$ clang++ -O2 -std=c++11 -stdlib=libc++ main.cpp && ./a.out
Segmentation fault: 11
$ clang++ -O1 -std=c++11 -stdlib=libc++ main.cpp && ./a.out
passed
$ clang++ -O3 -std=c++11 -stdlib=libc++ main.cpp && ./a.out
passed
When I add debugging information and try valgrind, it says the access happens
in __tree:1098.
$ clang++ -g -O2 -std=c++11 -stdlib=libc++ main.cpp
$ valgrind ./a.out
==23530== Process terminating with default action of signal 11 (SIGSEGV)
==23530== General Protection Fault
==23530==at 0x11788: void
std::__1::__tree,
(boost::multiprecision::expression_template_option)0>, int>,
std::__1::__map_value_compare,
(boost::multiprecision::expression_template_option)0>,
std::__1::__value_type,
(boost::multiprecision::expression_template_option)0>, int>,
std::__1::less,
(boost::multiprecision::expression_template_option)0> >, true>,
std::__1::allocator,
(boost::multiprecision::expression_template_option)0>, int> >
>::__assign_unique,
(boost::multiprecision::expression_template_option)0> const, int>
const*>(std::__1::pair,
(boost::multiprecision::expression_template_option)0> const, int> const*,
std::__1::pair,
(boost::multiprecision::expression_template_option)0> const, int> const*)
(__tree:1098)
==23530==by 0x110F3: main (map:986)
The libc++ version is 3.7 when I see _LIBCPP_VERSION.
The Boost version is 1.62.00 when I see BOOST_VERSION.
The same problem can still be observed with the key and the value types
swapped.
$ cat variant.cpp
#include
#include
#include
int main()
{
using namespace::std;
using u256 =
boost::multiprecision::number>;
map k = {{1, 131264}};
k = {};
cout << "passed" << endl << flush;
return 0;
}
$ clang++ -O1 -std=c++11 -stdlib=libc++ variant.cpp && ./a.out
passed
$ clang++ -O2 -std=c++11 -stdlib=libc++ variant.cpp && ./a.out
Segmentation fault: 11
$ clang++ -O3 -std=c++11 -stdlib=libc++ variant.cpp && ./a.out
Segmentation fault: 11
Valgrind points to the same line for these cases as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30736] LLVM fails to load DIA from VS 2015 on clang-x64-ninja-win7 bot
https://llvm.org/bugs/show_bug.cgi?id=30736 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- The bot has DIA now. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30586] Clang-cl Friend class error: elaborated type refers to a type alias
https://llvm.org/bugs/show_bug.cgi?id=30586 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Reid Kleckner --- r289259 should make the diagnostic better here. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31123] [LTO] Reject modules without a datalayout
https://llvm.org/bugs/show_bug.cgi?id=31123 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Davide Italiano --- r289719 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24344] Objective-C++ to C++ Rewriter produces ill-formed C++11 code
https://llvm.org/bugs/show_bug.cgi?id=24344 Paul Robinson changed: What|Removed |Added Status|NEW |RESOLVED CC||paul_robinson@playstation.s ||ony.com Resolution|--- |FIXED --- Comment #2 from Paul Robinson --- Some tests just compile Objective-C++, some (especially Rewriter) compile both Objective-C++ and regular C++. In r289167, I made the tests with regular C++ compilations explicitly specify -std=gnu++98, so they will be insensitive to future changes in the default C++ dialect. I don't think anybody is interested in making Objective-C++ compatible with C++11, going forward. If they are, that's fine; the point of my change is to get us closer to being able to change the C++ default. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31370] Assertion failed: "Cannot get layout of forward declarations!"
https://llvm.org/bugs/show_bug.cgi?id=31370 Trass3r changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Trass3r --- True, sorry something must have gone wrong during conflict resolution. The repo wasn't clean. Works now. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31376] Segmentation fault at _tree:1098 with -O2 in Mac OS X clang++
https://llvm.org/bugs/show_bug.cgi?id=31376 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Eric Fiselier --- OK. So I managed to get the second example segfaulting on Linux at -O2, but only after reverting r276003 which fixes UB in <__tree>. Closing this as a duplicate of "Undefined behavior in __tree", which has been fixed for a couple of releases now. *** This bug has been marked as a duplicate of bug 19302 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://llvm.org/bugs/show_bug.cgi?id=26299 Bug 26299 depends on bug 26302, which changed state. Bug 26302 Summary: [x86] Tail call with conditional jumps https://llvm.org/bugs/show_bug.cgi?id=26302 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26302] [x86] Tail call with conditional jumps
https://llvm.org/bugs/show_bug.cgi?id=26302 Hans Wennborg changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Hans Wennborg --- (In reply to comment #1) > r280832, r281113, r282920 for x86, x86_64 and win64, respectively. The X64 part got reverted in r283329 due to miscompling Chromium. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31377] New: [ppc] unnecessary zero extension / clear left instruction
https://llvm.org/bugs/show_bug.cgi?id=31377
Bug ID: 31377
Summary: [ppc] unnecessary zero extension / clear left
instruction
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compile the following code with options -m64 -O2 -mvsx -mcpu=power8
typedef unsigned long long uint64;
void foo(unsigned char* p, uint64* pval) {
uint64 code = *p;
if (code < 128) {
*pval = code;
}
}
LLVM generates:
foo:# @foo
.Lfunc_begin0:
# BB#0: # %entry
lbz 3, 0(3)// A
extsb. 3, 3// B
bltlr 0
# BB#1: # %if.then
clrldi 3, 3, 56 // C
std 3, 0(4)
blr
Instruction A load a byte from *p and zero extends it, instruction B sign
extends it and set cr accordingly, instruction C clears high bits, the result
should be exactly the result of instruction A.
So if instruction B write the result to a different register, or use cmpli
directly, instruction C can be removed.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31372] llvm-lib (and `lld-link /lib`) should error out on cl.exe LTCG obj files
https://llvm.org/bugs/show_bug.cgi?id=31372 Peter Collingbourne changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Peter Collingbourne --- r289726. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 17550] tuple::operator=(derived_from_tuple)
https://llvm.org/bugs/show_bug.cgi?id=17550 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Fiselier --- Fixed in r289727 (Clang 4.0). -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31378] New: list::remove should not require allocator to have default constructor
https://llvm.org/bugs/show_bug.cgi?id=31378
Bug ID: 31378
Summary: list::remove should not require allocator to have
default constructor
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: luk...@ca.ibm.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
The current libc++ implementation of `std::list::remove` uses the default
constructor of `std::list`:
> list<_Tp, _Alloc> __deleted_nodes; // collect the nodes we're removing
This subsequently calls the default constructor of `_Alloc`. However, reading
through section 17.6.3.5 ("Allocator requirements") of the C++11 standard
draft, it appears allocators are not required to be DefaultConstructable.
I believe the constructor of `__deleted_nodes` should simply be given the
allocator instance of the existing list:
> list<_Tp, _Alloc> __deleted_nodes(get_allocator()); // collect the nodes
> we're removing
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31321] Halide would like to set the .maxnreg directive per PTX kernel.
https://llvm.org/bugs/show_bug.cgi?id=31321 Justin Lebar (:jlebar) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Justin Lebar (:jlebar) --- Landed in r289729. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31379] New: error: instantiation of function required here, but no definition is available
https://llvm.org/bugs/show_bug.cgi?id=31379
Bug ID: 31379
Summary: error: instantiation of function required here, but no
definition is available
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jda...@redhat.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17755
--> https://llvm.org/bugs/attachment.cgi?id=17755&action=edit
Reproducer file message.ii
I encountered the following error when building Apache Qpid Proton C++ binding
with latest clang 4.0 snapshot (from the apt repo)
I obtained the source in the following way
git clone https://github.com/apache/qpid-proton.git
mkdir /qpid-proton/build
cd /qpid-proton/build
CC=clang-4.0 CXX=clang++-4.0 cmake -DCMAKE_BUILD_TYPE=Debug ..
VERBOSE=1 make
The erroring command was
cd /qpid-proton/build/proton-c/bindings/cpp && /usr/bin/clang++-4.0
-Dqpid_proton_cpp_EXPORTS -g -fPIC -I/qpid-proton/build/proton-c/src
-I/qpid-proton/build/proton-c/include -I/qpid-proton/proton-c/src
-I/qpid-proton/proton-c/include -I/qpid-proton/proton-c/bindings/cpp/include
-I/qpid-proton/proton-c/bindings/cpp/src/include -Werror -pedantic -Weverything
-Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-float-equal -Wno-padded
-Wno-sign-conversion -Wno-switch-enum -Wno-weak-vtables
-Wno-exit-time-destructors -Wno-global-constructors -Wno-shorten-64-to-32
-Wno-documentation -Wno-documentation-unknown-command -Wno-old-style-cast
-Wno-missing-noreturn -o CMakeFiles/qpid-proton-cpp.dir/src/message.cpp.o -c
/qpid-proton/proton-c/bindings/cpp/src/message.cpp
In file included from /qpid-proton/proton-c/bindings/cpp/src/message.cpp:25:
/qpid-proton/proton-c/bindings/cpp/include/proton/message.hpp:51:11: error:
instantiation of function
'proton::internal::cached_map,
proton::scalar>::cached_map' required here, but no definition is
available [-Werror,-Wundefined-func-template]
class property_map : public internal::cached_map {};
^
/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/cached_map.hpp:59:19:
note: forward declaration of template entity is here
PN_CPP_EXTERN cached_map();
^
1 error generated.
I reported this to Qpid Proton issue tracker, and got feedback that code looks
fine and it could be a compiller bug.
https://issues.apache.org/jira/browse/PROTON-1375?focusedCommentId=15749247#comment-15749247
I've followed the GCC bug reporting guide https://gcc.gnu.org/bugs/ and ran the
above command with -save-temps
cd /qpid-proton/build/proton-c/bindings/cpp && /usr/bin/clang++-4.0
-Dqpid_proton_cpp_EXPORTS -g -fPIC -I/qpid-proton/build/proton-c/src
-I/qpid-proton/build/proton-c/include -I/qpid-proton/proton-c/src
-I/qpid-proton/proton-c/include -I/qpid-proton/proton-c/bindings/cpp/include
-I/qpid-proton/proton-c/bindings/cpp/src/include -Werror -pedantic -Weverything
-Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-float-equal -Wno-padded
-Wno-sign-conversion -Wno-switch-enum -Wno-weak-vtables
-Wno-exit-time-destructors -Wno-global-constructors -Wno-shorten-64-to-32
-Wno-documentation -Wno-documentation-unknown-command -Wno-old-style-cast
-Wno-missing-noreturn -o CMakeFiles/qpid-proton-cpp.dir/src/message.cpp.o -c
/qpid-proton/proton-c/bindings/cpp/src/message.cpp -save-temps
which created a single file reproducer message.ii, and I modified the clang
command to use message.ii, and this still fails, so I have a single file
reproducer
/usr/bin/clang++-4.0 -Dqpid_proton_cpp_EXPORTS -g -fPIC -Werror -pedantic
-Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-float-equal
-Wno-padded -Wno-sign-conversion -Wno-switch-enum -Wno-weak-vtables
-Wno-exit-time-destructors -Wno-global-constructors -Wno-shorten-64-to-32
-Wno-documentation -Wno-documentation-unknown-command -Wno-old-style-cast
-Wno-missing-noreturn message.ii
If I do the compilation with clang 3.9, I get the same error. If I compile
message.ii with gcc 5.4 (leaving out -Weverything parameter) the compilation
succeeds.
This message.ii file is attached. Thank you for looking into this.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31378] list::remove should not require allocator to have default constructor
https://llvm.org/bugs/show_bug.cgi?id=31378 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Fiselier --- Fixed in r289735 (Clang 4.0). Thanks for the bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31175] [AArch64] unnecessary cmp instruction with subtract and conditional select
https://llvm.org/bugs/show_bug.cgi?id=31175
Sanjay Patel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Sanjay Patel ---
Should be fixed after:
https://reviews.llvm.org/rL289738
This solves the only problem I've seen when trying to canonicalize the min/max
IR pattern:
define i32 @max(i32 %x, i32 %y) {
%sub = sub nsw i32 %x, %y
%cmp = icmp sgt i32 %x, %y
%sel = select i1 %cmp, i32 %sub, i32 0
ret i32 %sel
}
to:
define i32 @max(i32 %x, i32 %y) {
%sub = sub nsw i32 %x, %y
%cmp = icmp sgt i32 %sub, 0
%sel = select i1 %cmp, i32 %sub, i32 0
ret i32 %sel
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31380] New: JIT notifiers called before relocations performed (and pages marked executable)
https://llvm.org/bugs/show_bug.cgi?id=31380 Bug ID: 31380 Summary: JIT notifiers called before relocations performed (and pages marked executable) Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: MCJIT Assignee: unassignedb...@nondot.org Reporter: and...@anarazel.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Hi, Currently the jit notifier's NotifyObjectEmitted() is called by MCJIT::generateCodeForModule(). That's too early, because relocations haven't been performed (making the code debuggers/profiling tools see wrong) and because the page hasn't yet been marked executable (bad, because some profiling tools don't work in that case). It seems to me that generateCodeForModule() should put all notifications into a queue of pending notifications which then is emitted in finalizeLoadedModules(), after Dyld.resolveRelocations() and MemMgr->finalizeMemory(). Are there reasons for the current placement that I missed, or is this just an omission? In the latter case I'll happily provide a patch fixing this. Regards, Andres -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31381] New: clang crashes on valid code at -Os and -O2 (only) with -g on x86_64-linux-gnu in 32-bit mode: running pass 'X86 Assembly Printer'
https://llvm.org/bugs/show_bug.cgi?id=31381 Bug ID: 31381 Summary: clang crashes on valid code at -Os and -O2 (only) with -g on x86_64-linux-gnu in 32-bit mode: running pass 'X86 Assembly Printer' Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang -v clang version 4.0.0 (trunk 289524) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang -m32 -Os -w small.c $ clang -m64 -Os -g -w small.c $ $ clang -m32 -Os -g -w small.c clang-4.0: /tmp/llvm-builder/llvm-source-trunk/lib/CodeGen/AsmPrinter/DwarfExpression.cpp:290: void llvm::DwarfExpression::addFragmentOffset(const llvm::DIExpression*): Assertion `FragmentOffset >= OffsetInBits && "overlapping or duplicate fragments"' failed. #0 0x01f3d795 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1f3d795) #1 0x01f3b87e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1f3b87e) #2 0x01f3b9e0 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1f3b9e0) #3 0x7f4f59ccd330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7f4f58ab9c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f4f58abd028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f4f58ab2bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7f4f58ab2ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x024e7679 (/usr/local/clang-trunk/bin/clang-4.0+0x24e7679) #9 0x025285d7 llvm::DwarfCompileUnit::constructVariableDIEImpl(llvm::DbgVariable const&, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x25285d7) #10 0x0252886c llvm::DwarfCompileUnit::constructVariableDIE(llvm::DbgVariable&, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x252886c) #11 0x02528893 llvm::DwarfCompileUnit::constructVariableDIE(llvm::DbgVariable&, llvm::LexicalScope const&, llvm::DIE*&) (/usr/local/clang-trunk/bin/clang-4.0+0x2528893) #12 0x0252d102 llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&, unsigned int*) (/usr/local/clang-trunk/bin/clang-4.0+0x252d102) #13 0x0252cb3b llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&) (/usr/local/clang-trunk/bin/clang-4.0+0x252cb3b) #14 0x0252d173 llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&, unsigned int*) (/usr/local/clang-trunk/bin/clang-4.0+0x252d173) #15 0x0252cb3b llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&) (/usr/local/clang-trunk/bin/clang-4.0+0x252cb3b) #16 0x0252d173 llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&, unsigned int*) (/usr/local/clang-trunk/bin/clang-4.0+0x252d173) #17 0x0252cc23 llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&) (/usr/local/clang-trunk/bin/clang-4.0+0x252cc23) #18 0x0252d173 llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*, llvm::SmallVectorImpl&, unsigned int*) (/usr/local/clang-trunk/bin/clang-4.0
[llvm-bugs] [Bug 31382] New: r289696 regressed TSan runtime library codegen
https://llvm.org/bugs/show_bug.cgi?id=31382 Bug ID: 31382 Summary: r289696 regressed TSan runtime library codegen Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: eugeni.stepa...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17756 --> https://llvm.org/bugs/attachment.cgi?id=17756&action=edit unminimized test case http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/2442 with r289696 one particularly hot function in the tsan runtime library has 6 spills instead of 5. Test case (2.ii attached): clang++ -std=c++11 -fPIE -O3 -o 1.o -c 2.ii && objdump -drl 1.o | grep -A 10 '__tsan_read1>:' -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31384] New: tuple is *still* nonconforming ;)
https://llvm.org/bugs/show_bug.cgi?id=31384
Bug ID: 31384
Summary: tuple is *still* nonconforming ;)
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ca...@carter.net
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
Changes to tuple in r289727 broke range-v3! Specifically, this program no
longer compiles:
template
struct derived : std::tuple {
using std::tuple::tuple;
template
operator std::tuple() && {
return {};
}
};
int main() {
std::tuple foo = derived{42};
}
derived's conversion operator to std::tuple is an exact match, and should be
preferred by overload resolution to std::tuple's constructor that requires a
conversion-to-base.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31385] New: SimplifyLibCalls should be able to map C99 types -> LLVM IR Types
https://llvm.org/bugs/show_bug.cgi?id=31385 Bug ID: 31385 Summary: SimplifyLibCalls should be able to map C99 types -> LLVM IR Types Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified See https://reviews.llvm.org/D14590. SimplifyLibCalls needs to know how to translate the pair (DataLayout, C99 type) -> LLVM IR Type in order to make some kind of transformations. For example, constant folding fls/flsl/flsll. Without that, there's no reliable way to know how big a long is. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31385] SimplifyLibCalls should be able to map C99 types -> LLVM IR Types
https://llvm.org/bugs/show_bug.cgi?id=31385 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Davide Italiano --- Actually this problem can happen, but not for fls. There's already a bug for that, marking this as duplicate. *** This bug has been marked as a duplicate of bug 22944 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31379] error: instantiation of function required here, but no definition is available
https://llvm.org/bugs/show_bug.cgi?id=31379 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- Thank you for the bug report! The warning is correct, and is detecting exactly the problem it was designed to detect. The definition of message::message() at message.cpp:44 causes the generation of the default constructor of message::property_map, which triggers the instantiation of the default constructor of internal::cached_map. But the default constructor of the internal::cached_map template is not defined in this file, so it will not be instantiated. The program is therefore ill-formed (no diagnostic required) unless that template is explicitly instantiated for that set of template arguments somewhere else. (And if not, in practice whether or not it works depends on how lucky you get: if the default constructor is instantiated in some other source file, the program will typically happen to work unless every use of it is inlined.) The warning can be suppressed by using an explicit instantiation declaration, explicitly stating the intent to explicitly instantiate that template somewhere else. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31384] tuple is *still* nonconforming ;)
https://llvm.org/bugs/show_bug.cgi?id=31384 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Fiselier --- The offending commit was reverted in r289773. And I also added this reproducer as a test case to prevent regressing. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 17550] tuple::operator=(derived_from_tuple)
https://llvm.org/bugs/show_bug.cgi?id=17550 Eric Fiselier changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Eric Fiselier --- Reopening this bug because the fix was reverted in r289773 due to PR31384. I'll work on recommitting in a couple weeks. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
