[llvm-bugs] [Bug 27651] New: Link will change global value order
https://llvm.org/bugs/show_bug.cgi?id=27651
Bug ID: 27651
Summary: Link will change global value order
Product: libraries
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Linker
Assignee: unassignedb...@nondot.org
Reporter: xiuli...@outlook.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
We are using a module as library and link the source code in the library and
when the source code has some blocks there are some bugs with the global value.
In debug version the ~Module will assert.
Here is llvm ir for global values before link and after link:
Before link:
@_NSConcreteGlobalBlock = external global i8*
@.str = private unnamed_addr addrspace(2) constant [9 x i8] c"i12@?0i8\00",
align 1
@__block_descriptor_tmp = internal constant { i64, i64, i8 addrspace(2)*, i8
addrspace(2)* } { i64 0, i64 32, i8 addrspace(2)* getelementptr inbounds ([9 x
i8], [9 x i8] addrspace(2)* @.str, i32 0, i32 0), i8 addrspace(2)* null }
@__block_literal_global = internal constant { i8**, i32, i32, i8*,
%struct.__block_descriptor* } { i8** @_NSConcreteGlobalBlock, i32 1342177280,
i32 0, i8* bitcast (i32 (i8*, i32)* @__test_block_invoke to i8*),
%struct.__block_descriptor* bitcast ({ i64, i64, i8 addrspace(2)*, i8
addrspace(2)* }* @__block_descriptor_tmp to %struct.__block_descriptor*) },
align 8
After link:
@__block_literal_global = internal constant { i8**, i32, i32, i8*,
%struct.__block_descriptor* } { i8** @_NSConcreteGlobalBlock, i32 1342177280,
i32 0, i8* bitcast (i32 (i8*, i32)* @__test_block_invoke to i8*),
%struct.__block_descriptor* bitcast ({ i64, i64, i8 addrspace(2)*, i8
addrspace(2)* }* @__block_descriptor_tmp to %struct.__block_descriptor*) },
align 8
@_NSConcreteGlobalBlock = external global i8*
@__block_descriptor_tmp = internal constant { i64, i64, i8 addrspace(2)*, i8
addrspace(2)* } { i64 0, i64 32, i8 addrspace(2)* getelementptr inbounds ([9 x
i8], [9 x i8] addrspace(2)* @.str, i32 0, i32 0), i8 addrspace(2)* null }
@.str = private unnamed_addr addrspace(2) constant [9 x i8] c"i12@?0i8\00",
align 1
As the global valve orders change, the dependency of these global values are
messed.
It seems the bug was caused by ModuleLinker::linkIfNeeded with a recursion call
but with a wrong order.
--
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 27652] New: Tests with syntax errors don't get flagged as erroneous
https://llvm.org/bugs/show_bug.cgi?id=27652 Bug ID: 27652 Summary: Tests with syntax errors don't get flagged as erroneous Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org, todd.fi...@gmail.com Classification: Unclassified If a test case has syntax errors in it, it will fail, but this will not be reported as a failure in the overall summary (probably because the report-test-results-over-socket logic doesn't even get a chance to run). This means the the failure can easily go on unnoticed. The failure should be easily detectable by the fact that the subprocess test runner returns a non-zero exit status. We should probably detect this and flag any test with non-zero return as failed. -- 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 27653] New: BOUND instruction has swapped arguments
https://llvm.org/bugs/show_bug.cgi?id=27653 Bug ID: 27653 Summary: BOUND instruction has swapped arguments Product: tools Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llvm-as Assignee: unassignedb...@nondot.org Reporter: r.ma...@assembler.cz CC: llvm-bugs@lists.llvm.org Classification: Unclassified //./clang-3.8 -c a.S -m32 -save-temps //a.S is this: .section .text .global _start _start: //GCC accept this //bound %eax, (%ecx) //CLANG wants this bound (%ecx), %eax //both generate: //62 01bound %eax,(%ecx) -- 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 27654] New: [AARCH64] lit tests not being run on windows build machines
https://llvm.org/bugs/show_bug.cgi?id=27654 Bug ID: 27654 Summary: [AARCH64] lit tests not being run on windows build machines Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: james.mol...@arm.com, llvm-bugs@lists.llvm.org, vitalyb...@google.com Classification: Unclassified llvm\test\CodeGen\AArch64\lit.local.cfg currently disables tests on windows machines: # For now we don't test arm64-win32. if re.search(r'cygwin|mingw32|win32|windows-gnu|windows-msvc', config.target_triple): config.unsupported = True Removing this snippet and running on a win7/vs2015 build, I saw the tests run and with no resultant failures. However, I don't have a cygwin/mingw machine at hand to check with those. Note: This led to the build failure on D19805/r268504 as the patch had only been tested on windows before commit. -- 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 26076] dllexport vs template instantiation, nested class, and in-class initialization
https://llvm.org/bugs/show_bug.cgi?id=26076 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nico Weber --- I verified that reverting that revision reintroduces the problem. Added the reduced repro as a test in r268625 to make sure this stays 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 22248] clang link fails with undefined reference to `__stack_chk_guard'
https://llvm.org/bugs/show_bug.cgi?id=22248 Marcin Kościelnicki changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marcin Kościelnicki --- The issue should be now fixed on kfreebsd, sparc, sparc64, powerpc, powerpc64, powerpc64le, s390x. Can you try the build with current llvm trunk? -- 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 27656] New: clang-3.8 fails to link against boost libraries while older versions and gcc work
https://llvm.org/bugs/show_bug.cgi?id=27656 Bug ID: 27656 Summary: clang-3.8 fails to link against boost libraries while older versions and gcc work Product: clang Version: 3.8 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: johannesoberm...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Johannes Obermayr 2016-04-27 18:31:51 UTC https://pmbs.links2linux.de/package/show/Extra/FreeCAD $ make [ 1%] Built target SMDS [ 1%] Built target Driver [ 2%] Built target DriverDAT [ 2%] Built target SMESHDS [ 2%] Built target DriverUNV [ 2%] Built target DriverSTL [ 3%] Built target SMESH [ 3%] Built target MEFISTO2 [ 4%] Built target StdMeshers [ 7%] Built target FreeCADBase [ 7%] Linking CXX shared library ../../lib/libFreeCADApp.so clang version 3.8.0 (tags/RELEASE_380/final 262553) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/5 Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/5 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/5 Candidate multilib: .;@m64 Selected multilib: .;@m64 clang-3.8: warning: argument unused during compilation: '-grecord-gcc-switches' "/usr/bin/ld" -z relro --hash-style=gnu --hash-style=both --build-id --enable-new-dtags --eh-frame-hdr -m elf_x86_64 -shared -o ../../lib/libFreeCADApp.so /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../lib64/crti.o /usr/bin/../lib64/gcc/x86_64-suse-linux/5/crtbeginS.o -L/usr/bin/../lib64/gcc/x86_64-suse-linux/5 -L/usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../lib64 -L/usr/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/lib -L/usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../.. -L/usr/bin/../lib -L/lib -L/usr/lib -soname libFreeCADApp.so CMakeFiles/FreeCADApp.dir/Annotation.cpp.o CMakeFiles/FreeCADApp.dir/Document.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObject.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObjectFileIncluded.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObjectGroup.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObjectGroupPyImp.cpp.o CMakeFiles/FreeCADApp.dir/GeoFeaturePyImp.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObjectPyImp.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObserver.cpp.o CMakeFiles/FreeCADApp.dir/DocumentObserverPython.cpp.o CMakeFiles/FreeCADApp.dir/DocumentPyImp.cpp.o CMakeFiles/FreeCADApp.dir/Expression.cpp.o CMakeFiles/FreeCADApp.dir/FeaturePython.cpp.o CMakeFiles/FreeCADApp.dir/FeatureTest.cpp.o CMakeFiles/FreeCADApp.dir/GeoFeature.cpp.o CMakeFiles/FreeCADApp.dir/GeoFeatureGroupPyImp.cpp.o CMakeFiles/FreeCADApp.dir/GeoFeatureGroup.cpp.o CMakeFiles/FreeCADApp.dir/OriginGroupPyImp.cpp.o CMakeFiles/FreeCADApp.dir/OriginGroup.cpp.o CMakeFiles/FreeCADApp.dir/PartPyImp.cpp.o CMakeFiles/FreeCADApp.dir/Part.cpp.o CMakeFiles/FreeCADApp.dir/Origin.cpp.o CMakeFiles/FreeCADApp.dir/Path.cpp.o CMakeFiles/FreeCADApp.dir/InventorObject.cpp.o CMakeFiles/FreeCADApp.dir/MeasureDistance.cpp.o CMakeFiles/FreeCADApp.dir/Placement.cpp.o CMakeFiles/FreeCADApp.dir/OriginFeature.cpp.o CMakeFiles/FreeCADApp.dir/Range.cpp.o CMakeFiles/FreeCADApp.dir/Transactions.cpp.o CMakeFiles/FreeCADApp.dir/VRMLObject.cpp.o CMakeFiles/FreeCADApp.dir/MaterialObject.cpp.o CMakeFiles/FreeCADApp.dir/MergeDocuments.cpp.o CMakeFiles/FreeCADApp.dir/DynamicProperty.cpp.o CMakeFiles/FreeCADApp.dir/ObjectIdentifier.cpp.o CMakeFiles/FreeCADApp.dir/Property.cpp.o CMakeFiles/FreeCADApp.dir/PropertyContainer.cpp.o CMakeFiles/FreeCADApp.dir/PropertyContainerPyImp.cpp.o CMakeFiles/FreeCADApp.dir/PropertyFile.cpp.o CMakeFiles/FreeCADApp.dir/PropertyGeo.cpp.o CMakeFiles/FreeCADApp.dir/PropertyLinks.cpp.o CMakeFiles/FreeCADApp.dir/PropertyPythonObject.cpp.o CMakeFiles/FreeCADApp.dir/PropertyStandard.cpp.o CMakeFiles/FreeCADApp.dir/PropertyUnits.cpp.o CMakeFiles/FreeCADApp.dir/PropertyExpressionEngine.cpp.o CMakeFiles/FreeCADApp.dir/Application.cpp.o CMakeFiles/FreeCADApp.dir/ApplicationPy.cpp.o CMakeFiles/FreeCADApp.dir/Branding.cpp.o CMakeFiles/FreeCADApp.dir/ColorModel.cpp.o CMakeFiles/FreeCADApp.dir/ComplexGeoData.cpp.o CMakeFiles/FreeCADApp.dir/ComplexGeoDataPyImp.cpp.o CMakeFiles/FreeCADApp.dir/Enumeration.cpp.o CMakeFiles/FreeCADApp.dir/Material.cpp.o CMakeFiles/FreeCADApp.dir/MaterialPyImp.cpp.o CMakeFiles/FreeCADApp.dir/PreCompiled.cpp.o ../../lib/libFreeCADBase.so -lboost_filesystem-mt -lboost_program_options-mt -lboost_regex-mt -lboost_signals-mt -lboost_system-mt -lboost_thread-mt -lboost_chrono-mt -lboost_date_time-mt -lboost_atomic-mt -lQtCore -lQtXml -lpython2.7 -lxerces-c -lboost_filesystem-mt -lboost_program_options-mt -lboost_regex-mt -lboost_signals-mt -lboost_system-mt -lboost_th
[llvm-bugs] [Bug 21077] R_AARCH64_ABS64 used with TLS symbol
https://llvm.org/bugs/show_bug.cgi?id=21077 Igor Kudrin changed: What|Removed |Added Status|CLOSED |REOPENED CC||ikudrin@gmail.com Resolution|FIXED |--- --- Comment #16 from Igor Kudrin --- The original issue isn't fixed. It looks like gcc solves this issue by not adding a DW_AT_location record into DIE for TLS variables when targeting AArch64. Shouldn't we do the same? -- 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 27657] New: [IfConverter/BranchFolding] An empty, non-reachable MBB is not removed.
https://llvm.org/bugs/show_bug.cgi?id=27657 Bug ID: 27657 Summary: [IfConverter/BranchFolding] An empty, non-reachable MBB is not removed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: dexonsm...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16312 --> https://llvm.org/bugs/attachment.cgi?id=16312&action=edit llc input The IfConverter should remove a block and its successor/predecessor edges from MF because it is not reachable. BranchFolding fails to assist with this. Interesting is to note that the probability of the edge to that block is 0, which is another observation which means it could be removed. Not having empty blocks is good generally for algorithms (I am experimenting currently with something like global scheduler states to propagate processor resources usage between regions.) BB#0: derived from LLVM BB %entry Live Ins: %R2D CGHI %R2D, 0, %CC BRC 14, 6, , %CC Successors according to CFG: BB#1(0x3000 / 0x8000 = 37.50%) BB#2(0x5000 / 0x8000 = 62.50%) BB#1: derived from LLVM BB %return Predecessors according to CFG: BB#0 %R2D = LGHI 0 Return %R2D BB#2: derived from LLVM BB %if.end Live Ins: %R2D Predecessors according to CFG: BB#0 CallJG => BB#0: derived from LLVM BB %entry Live Ins: %R2D CGHI %R2D, 0, %CC CallBRCL 14, 6, Successors according to CFG: BB#1(0x8000 / 0x8000 = 100.00%) BB#2(0x / 0x8000 = 0.00%) BB#1: derived from LLVM BB %return Predecessors according to CFG: BB#0 %R2D = LGHI 0 Return %R2D BB#2: derived from LLVM BB %if.end Live Ins: %R2D Predecessors according to CFG: BB#0 ./bin/llc ./minperlio.ll -mtriple=s390x-linux-gnu -mcpu=z13 Could this be done in BranchFolder.cpp? I am not sure if there could be cases lika a call to an empty block without successors to replace it..? -- 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 27658] New: std::mutex should be trivially destructible
https://llvm.org/bugs/show_bug.cgi?id=27658 Bug ID: 27658 Summary: std::mutex should be trivially destructible Product: libc++ Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Currently std::mutex has a constexpr constructor, but a non-trivial destruction. The constexpr constructor is required to ensure the construction of a mutex with static storage duration happens at compile time, during constant initialization, and not during dynamic initialization. This means that static mutex's are always initialized and can be used safely during dynamic initialization without the "static initialization order fiasco". A trivial destructor is important for similar reasons. If a mutex is used during dynamic initialization it might also be used during program termination. If a static mutex has a non-trivial destructor it will be invoked during termination. This can introduce the "static deinitialization order fiasco". Additionally, function-local statics emit a guard variable around non-trivially destructible types. This results in horrible codegen and adds a runtime cost to every call to that function. non-local static's also result in slightly worse codegen but it's not as big of a problem. Example codegen can be found here: https://goo.gl/3CSzbM For these reasons I believe we should change 'std::mutex' to be trivially destructible (when possible). This means *NOT* invoking "pthread_mutex_destroy(...)" in the destructor. I believe is a safe change on some pthread implementations. The main purpose of "pthread_mutex_destroy" is to set the lock to an invalid value, allowing use-after-free to be diagnosed. AFAIK mutex's initialized with "PTHREAD_MUTEX_INITIALIZER" own no resources and so omitting the call will not cause leaks. On other pthread implementations this change will not be possible. Note that std::mutex::~mutex is defined in the dylib, so such a change would have to ensure we continue to define it there. -- 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 27659] New: Exception throwing Call instructions (invokes) should be terminator machine instructions.
https://llvm.org/bugs/show_bug.cgi?id=27659 Bug ID: 27659 Summary: Exception throwing Call instructions (invokes) should be terminator machine instructions. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is a clone of rdar://10318439 (for apple people), originally by Jakob Olesen. I am filing this llvm PR for reference: When we lower LLVM IR invoke instructions to machine code, we should model the control flow more accurately. Currently, we do this: BB#1: ADJCALLSTACKDOWN %R0 = COPY %vreg0 %R1 = COPY %vreg1 CALL foo, %R0, %R1, ... %vreg3 = COPY %R0 # Return value ADJCALLSTACKUP BB#2: # preds = BB#1 foo BB#3: EH_LANDING_PAD #preds = BB#1 %R0 = MAGIC %vreg7 = COPY %R0 # exception pointer bar This is inaccurate because the instructions in BB#1 are not executed on the exceptional edge to the landing pad BB#3. Currently, the register allocator has to jump through hoops to avoid inserting split/spill code after the CALL. I propose a call instruction that is also a terminator: BB#1: ADJCALLSTACKDOWN %R0 = COPY %vreg0 %R1 = COPY %vreg1 INVOKE foo, %R0, %R1, ... BB#2: # preds = BB#1 #Live-in: %R0 %vreg3 = COPY %R0 # Return value ADJCALLSTACKUP foo BB#3: EH_LANDING_PAD #preds = BB#1 #Live-in: %R0 %vreg7 = COPY %R0 # exception pointer bar This models the control flow around DWARF exceptions more accurately, and it handles the different 'return values' that show up in physical registers on the two edges from the INVOKE. The register allocator can stick to the standard rule of not inserting code after the first terminator. Machine code verification also becomes easier. Currently we have a lot of trouble verifying exception CFGs because anything goes. With an invoke instruction, we could verify invariants like: - A block terminated by an invoke has exactly one landing pad successor, and one fall-through successor. - A landing pad has only invoke predecessors. -- 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 27660] New: phi node arguments oscillate with passes jump-threading and loop-simplify
https://llvm.org/bugs/show_bug.cgi?id=27660 Bug ID: 27660 Summary: phi node arguments oscillate with passes jump-threading and loop-simplify Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: nwilso...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16313 --> https://llvm.org/bugs/attachment.cgi?id=16313&action=edit jump-threading_loop-simplify.ll When using the flags -jump-threading and -loop-simplify on the attached IR (jump-threading_loop-simplify.ll) the phi nodes will keep flipping. This was produced by using the attached IR and using the output as input back to opt. For example: $ ./opt -S -jump-threading -loop-simplify jump-threading_loop-simplify.ll > out1.ll $ ./opt -S -jump-threading -loop-simplify out1.ll > out2.ll $ ./opt -S -jump-threading -loop-simplify out2.ll > out3.ll diff out2.ll out1.ll 1c1 < ; ModuleID = 'out1.ll' --- > ; ModuleID = 'jump-threading_loop-simplify.ll' 29,30c29,30 < _ZNK4pugi8xml_text5_dataEv.exit.loopexit: ; preds = %for.inc.i, %for.body.i < %.ph = phi %"struct.pugi::xml_node_struct.1.85.421"* [ null, %for.inc.i ], [ undef, %for.body.i ] --- > _ZNK4pugi8xml_text5_dataEv.exit.loopexit: ; preds = %for.body.i, > %for.inc.i > %.ph = phi %"struct.pugi::xml_node_struct.1.85.421"* [ undef, %for.body.i > ], [ null, %for.inc.i ] $ diff out3.ll out2.ll 1c1 < ; ModuleID = 'out2.ll' --- > ; ModuleID = 'out1.ll' 30c30 < %.ph = phi %"struct.pugi::xml_node_struct.1.85.421"* [ undef, %for.body.i ], [ null, %for.inc.i ] --- > %.ph = phi %"struct.pugi::xml_node_struct.1.85.421"* [ null, %for.inc.i ], > [ undef, %for.body.i ] -- 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 27661] New: llvm generates many push and pop
https://llvm.org/bugs/show_bug.cgi?id=27661
Bug ID: 27661
Summary: llvm generates many push and pop
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: hjl.to...@gmail.com
CC: david.l.kreit...@intel.com, llvm-bugs@lists.llvm.org,
zia.ans...@intel.com
Classification: Unclassified
At -O2 for x86-64, llvm generates an extra subq and many push/pop
---
extern void foo1 (void *, void *, void *, void *, void *, void *, int, int,
void *);
extern void foo2 (void *, void *, void *, void *, void *, void *, int, void *);
void
bar (int x)
{
int i1, i2, i3, i4, i5, i6;
int i;
foo1 (&i1, &i2, &i3, &i4, &i5, &i6, 7, 8, &i);
foo2 (&i1, &i2, &i3, &i4, &i5, &i6, 8, &i);
}
---
bar:# @bar
.cfi_startproc
# BB#0:
pushq%rbp
.Ltmp0:
.cfi_def_cfa_offset 16
pushq%r15
.Ltmp1:
.cfi_def_cfa_offset 24
pushq%r14
.Ltmp2:
.cfi_def_cfa_offset 32
pushq%r13
.Ltmp3:
.cfi_def_cfa_offset 40
pushq%r12
.Ltmp4:
.cfi_def_cfa_offset 48
pushq%rbx
.Ltmp5:
.cfi_def_cfa_offset 56
subq$40, %rsp
.Ltmp6:
.cfi_def_cfa_offset 96
.Ltmp7:
.cfi_offset %rbx, -56
.Ltmp8:
.cfi_offset %r12, -48
.Ltmp9:
.cfi_offset %r13, -40
.Ltmp10:
.cfi_offset %r14, -32
.Ltmp11:
.cfi_offset %r15, -24
.Ltmp12:
.cfi_offset %rbp, -16
subq$8, %rsp <<< Extra subq.
.Ltmp13:
.cfi_adjust_cfa_offset 8
leaq20(%rsp), %rax
leaq44(%rsp), %rbx
leaq40(%rsp), %r14
leaq36(%rsp), %r15
leaq32(%rsp), %r12
leaq28(%rsp), %r13
leaq24(%rsp), %rbp
movq%rbx, %rdi
movq%r14, %rsi
movq%r15, %rdx
movq%r12, %rcx
movq%r13, %r8
movq%rbp, %r9
pushq%rax
.Ltmp14:
.cfi_adjust_cfa_offset 8
pushq$8
.Ltmp15:
.cfi_adjust_cfa_offset 8
pushq$7
.Ltmp16:
.cfi_adjust_cfa_offset 8
callqfoo1
addq$32, %rsp
.Ltmp17:
.cfi_adjust_cfa_offset -32
movq%rbx, %rdi
movq%r14, %rsi
movq%r15, %rdx
movq%r12, %rcx
movq%r13, %r8
movq%rbp, %r9
leaq12(%rsp), %rax
pushq%rax
.Ltmp18:
.cfi_adjust_cfa_offset 8
pushq$8
.Ltmp19:
.cfi_adjust_cfa_offset 8
callqfoo2
addq$56, %rsp
.Ltmp20:
.cfi_adjust_cfa_offset -16
popq%rbx
popq%r12
popq%r13
popq%r14
popq%r15
popq%rbp
retq
GCC 5.3.1 generates
bar:
.LFB0:
.cfi_startproc
pushq%rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
subq$40, %rsp
.cfi_def_cfa_offset 56
leaq36(%rsp), %rbx
pushq%rbx
.cfi_def_cfa_offset 64
pushq$8
.cfi_def_cfa_offset 72
pushq$7
.cfi_def_cfa_offset 80
leaq56(%rsp), %r9
leaq52(%rsp), %r8
leaq48(%rsp), %rcx
leaq44(%rsp), %rdx
leaq40(%rsp), %rsi
leaq36(%rsp), %rdi
callfoo1
addq$32, %rsp
.cfi_def_cfa_offset 48
pushq%rbx
.cfi_def_cfa_offset 56
pushq$8
.cfi_def_cfa_offset 64
leaq40(%rsp), %r9
leaq36(%rsp), %r8
leaq32(%rsp), %rcx
leaq28(%rsp), %rdx
leaq24(%rsp), %rsi
leaq20(%rsp), %rdi
callfoo2
addq$48, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
--
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 26871] sitofp conversion to half-precision float generates single-precision float without truncating
https://llvm.org/bugs/show_bug.cgi?id=26871 Ahmed Bougacha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ahmed Bougacha --- Should be fixed by: r268700 [CodeGen] Round [SU]INT_TO_FP result when promoting from f16. -- 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 27662] New: PowerPC64 isn't building builtins library
https://llvm.org/bugs/show_bug.cgi?id=27662 Bug ID: 27662 Summary: PowerPC64 isn't building builtins library Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: an...@samba.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16314 --> https://llvm.org/bugs/attachment.cgi?id=16314&action=edit Build builtins library on powerpc64 and powerpc64le When bootstrapping rust, I noticed the builtins library wasn't being built for powerpc64 and powerpc64le. Attached is a simple patch to enable it, is there any reason it was disabled? -- 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 27663] New: __builtin_va_arg stack-walk short
https://llvm.org/bugs/show_bug.cgi?id=27663
Bug ID: 27663
Summary: __builtin_va_arg stack-walk short
Product: clang
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: zenith...@users.sourceforge.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I've marked this as clang 3.8, but code was compiled on Apple's Xcode 7.3.1.
Sample code
va_sum.c
int va_sum(unsigned int count, ...)
{
int sum = 0;
__builtin_ms_va_list ap;
__builtin_ms_va_start(ap, count);
while (count) {
sum += __builtin_va_arg(ap, int);
--count;
}
__builtin_ms_va_end(ap);
return sum;
}
==
Compiled with
clang -S -Os -fno-unwind-tables -target x86_64-pc-win32-macho va_sum.c
generates this code
va_sum.s
.section__TEXT,__text,regular,pure_instructions
.globl_va_sum
_va_sum:## @va_sum
## BB#0:
pushq%rax
movq%r9, 40(%rsp)
movq%r8, 32(%rsp)
movq%rdx, 24(%rsp)
leaq24(%rsp), %rax
movq%rax, (%rsp)
xorl%eax, %eax
testl%ecx, %ecx
jeLBB0_2
LBB0_1: ## %.lr.ph
## =>This Inner Loop Header: Depth=1
movq(%rsp), %r8
addq$3, %r8
andq$-4, %r8
leaq4(%r8), %rdx
movq%rdx, (%rsp)
addl(%r8), %eax
decl%ecx
jneLBB0_1
LBB0_2: ## %._crit_edge
popq%rdx
retq
.subsections_via_symbols
The stack walk is wrong (leaq, 4(%r8), %rdx). It advances the pointer by 4
bytes each time - the sizeof(int). On x86_64 the stack needs to be walked by
steps of 8 bytes.
--
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 27664] New: __INT_FAST_TYPE__ predefined macros incorrect
https://llvm.org/bugs/show_bug.cgi?id=27664 Bug ID: 27664 Summary: __INT_FAST_TYPE__ predefined macros incorrect Product: clang Version: 3.8 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: andyg1...@hotmail.co.uk CC: llvm-bugs@lists.llvm.org Classification: Unclassified Ok, I'll qualify the statement that "__INT_FAST_TYPE__ predefined macros are incorrect" as "incorrect compared to gcc", which I realise is itself not necessarily a bug! However, please compare the two outputs from gcc and clang: gcc -E -dM -xc - < /dev/null | grep -i '\(fast\|least\).*type' | sort #define __INT_FAST16_TYPE__ long int #define __INT_FAST32_TYPE__ long int #define __INT_FAST64_TYPE__ long int #define __INT_FAST8_TYPE__ signed char #define __INT_LEAST16_TYPE__ short int #define __INT_LEAST32_TYPE__ int #define __INT_LEAST64_TYPE__ long int #define __INT_LEAST8_TYPE__ signed char #define __UINT_FAST16_TYPE__ long unsigned int #define __UINT_FAST32_TYPE__ long unsigned int #define __UINT_FAST64_TYPE__ long unsigned int #define __UINT_FAST8_TYPE__ unsigned char #define __UINT_LEAST16_TYPE__ short unsigned int #define __UINT_LEAST32_TYPE__ unsigned int #define __UINT_LEAST64_TYPE__ long unsigned int #define __UINT_LEAST8_TYPE__ unsigned char clang -E -dM -xc /dev/null | grep -i '\(fast\|least\).*type' | sort #define __INT_FAST16_TYPE__ short #define __INT_FAST32_TYPE__ int #define __INT_FAST64_TYPE__ long int #define __INT_FAST8_TYPE__ signed char #define __INT_LEAST16_TYPE__ short #define __INT_LEAST32_TYPE__ int #define __INT_LEAST64_TYPE__ long int #define __INT_LEAST8_TYPE__ signed char #define __UINT_FAST16_TYPE__ unsigned short #define __UINT_FAST32_TYPE__ unsigned int #define __UINT_FAST64_TYPE__ long unsigned int #define __UINT_FAST8_TYPE__ unsigned char #define __UINT_LEAST16_TYPE__ unsigned short #define __UINT_LEAST32_TYPE__ unsigned int #define __UINT_LEAST64_TYPE__ long unsigned int #define __UINT_LEAST8_TYPE__ unsigned char Note that in clang all the "fast" types match types of the exact width, unlike gcc that often chooses larger, and one would assume, more optimal types. Now, I observe that most implementations of stdint.h totally ignore these compiler defines, but this raises the question, why have these defines at all if they cannot be trusted to be correct? Or, is clang doing optimisations behind the scenes that means that the code generated by using "short" will always be as fast as using "int_fast16_t", for example? Unfortunately, I am currently porting embedded code using a minimal libc (worse, from a proprietary source!) which itself makes use of these defines and I'm getting quite a number of performance regressions which appear to be related to 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
