[llvm-bugs] [Bug 27322] New: Objective-C protocol enhancement and abstract classes
https://llvm.org/bugs/show_bug.cgi?id=27322 Bug ID: 27322 Summary: Objective-C protocol enhancement and abstract classes Product: clang Version: unspecified Hardware: All OS: All Status: NEW Keywords: new-feature Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: su.chan.z...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Objective-C have not accomplished protocol structure. There is exist mess, if you want make class object (not object of class) to conform to protocol. For example, if I want, that UITableViewDelegate should be implemented by class methods, not instance methods, then I get set of problems: 1. I shouldn't declare, that my class conform to protocol UITableViewDelegate, or I'll get methods, that I have unimplemented methods 2. I need write methods with + instead of -, and IDE will not show tips with method prototypes and I can make typos. 3. As because I can't declare, that class object conform to protocol, I need use runtime functions, to make `conformToProtocol` work. 4. There is mess with Class record. Actually I don't know, is it class object conform to protocol or it's instances. What I suggest: 1. Protocols shouldn't have class methods. 2. There is should be syntax that protocol is implemented with class method, instead of instance methods. I suggest syntax with + and - sign. For example: @interface MyViewController:UIViewController<+UITableViewDelegate> thats mean, that protocols methods should be implemented with class methods. Old syntax without + and - we leave as it was. Minus syntax used for convenience, In common cases it's like without -, but it can also force class methods from protocol to be implemented by instance methods (it's need if you decide leave class methods in protocols for backward compatibility) When work with variables, this code shouldn't show warnings: id delegate = [MyViewController class]; Class<+UITableViewDelegate> classDelegate = [MyViewController class]; //Actually id is more preferable, but such syntax can be used. delegate = classDelegate; classDelegate = (Class<+UITableViewDelegate>)delegate; Class<-UITableViewDelegate> classOfDelegate = [delegate class]; id<+UITableViewDelegate> instanceOfDelegate = [[MyViewController alloc] init]; classDelegate = [instanceOfDelegate class]; delegate = [instanceOfDelegate class]; 3. And method in `NSObject` `+classConformToProtocol:` and `-instanceConformToProtocol:`. [MyViewController classConformToProtocol:] and [[MyViewController class] instanceConformToProtocol:] give the same result. I think `+conformToProtocol:` should be deprecated, because it adds confusion here. By the way, you can apply +/- syntax for generics: NSArray *arrayOfStrings; //don't need * in <> NSArray *arrayOfStringAndTableViewDelegate; Also there is lack of abstract classes in Objective-C. To make abstract class I usually write: @protocol MyClass //some methods @end @interface _MyClass : NSObject @end typedef _MyClass MyClass; @inteface _MyClass() //if I want add some standard implementations @end It's really mess, looks ugly, not clear from first view. I suggest make @interface MyClass : NSObject @end just abstract. What does it mean: - don't show warnings if some methods not implemented - don't allow instantiate such class if some methods not implemented (show error or warnings in place, where user trying to instantiate such class) but I suggest leave old behavior if protocol is declared in class extension: @interface MyClass() @end shows error and warnings if some methods not implemented That's it. I hope you will find my ideas as "must have". -- 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 27323] New: Make usable instancetype Objective-C's keyword in generic arguments
https://llvm.org/bugs/show_bug.cgi?id=27323 Bug ID: 27323 Summary: Make usable instancetype Objective-C's keyword in generic arguments Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Keywords: new-feature Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: su.chan.z...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Currently I can't create class with such method for example: @interface MyClass : NSObject + (NSArray *)arrayOfMyClassesFromArray:(NSArray *)dictArray; @end Maximum that I can achieve is @interface MyClass : NSObject + (NSArray<__kindof MyClass *> *)arrayOfMyClassesFromArray:(NSArray *)dictArray; @end But it's not as type safety as wanted. Thanks. -- 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 27324] New: libclang/Windows: exceptions are not supported by default [regression from 3.6.2]
https://llvm.org/bugs/show_bug.cgi?id=27324
Bug ID: 27324
Summary: libclang/Windows: exceptions are not supported by
default [regression from 3.6.2]
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: nikolai.kos...@theqtcompany.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
libclang 3.6.2 on Windows can parse code with exceptions just fine, whereas lib
clang 3.8.0 produces "error: cannot use 'try' with exceptions disabled".
Providing -### as argument shows that libclang 3.8.0 does not have the
corresponding options -fcxx-exceptions and -fexceptions internally (libclang
3.6.2 did).
This forces libclang clients to explicitly pass in those options in order to
parse MSVC headers.
Details:
Given the following program making use of libclang:
#include
#include
#include
int main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, "Usage: $0 \n");
return 0;
}
CXIndex index = clang_createIndex(0, /*displayDiagnostics*/ 1);
clang_parseTranslationUnit(index, argv[1], 0, 0, NULL, 0, 0);
return 0;
}
and the sample "inputfile.cpp":
int main()
{
try { } catch (...) {}
}
shows that:
libclang 3.8.0:
$ libclangclient.exe intputfile.cpp:
inputfile.cpp:3:5: error: cannot use 'try' with exceptions disabled
$
libclang 3.6.2:
$ libclangclient.exe intputfile.cpp:
$
--
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 27246] r261346 causes this test case to fail
https://llvm.org/bugs/show_bug.cgi?id=27246 Matthew Simpson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matthew Simpson --- This issue has been fixed by r265980. The "previous", loop-varying value of a first-order recurrence cannot also be a phi node. -- 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 27326] New: Provide a way to exit lldb with a non-zero exit status
https://llvm.org/bugs/show_bug.cgi?id=27326 Bug ID: 27326 Summary: Provide a way to exit lldb with a non-zero exit status Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: john.fireba...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Please provide a way to exit scripted lldb interactions with a non-zero exit status. This is necessary for, e.g. running a debugged program in an automated test environment, and printing diagnostics and then exiting with a non-zero exit status if a crash occurs. This could take several forms: * An equivalent of GDB's "-return-child-result" option. * An argument form of "quit", e.g. "quit 1". (GDB also supports this.) For instance, I would like the following command to work as expected: lldb --batch -o 'run' -k 'thread backtrace all' -k 'quit 1' -- 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 27327] New: Arguments converted to WASM .S incorrectly by LLC
https://llvm.org/bugs/show_bug.cgi?id=27327 Bug ID: 27327 Summary: Arguments converted to WASM .S incorrectly by LLC Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: gareth_morga...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16207 --> https://llvm.org/bugs/attachment.cgi?id=16207&action=edit The input LL and output S The attached .LL file will be incorrectly converted to .s by WASM back end. Specifically on line 3566 %call16 = call zeroext i1 @_ZN22MarchingSquaresFunctorI4Vec414MSVec4AccessorE3RunERKiS4_(%class.MarchingSquaresFunctor* nonnull %f, i32* nonnull dereferenceable(4) %i, i32* nonnull dereferenceable(4) %j) This gets converted to this code in the .s. Where the constants 4 and 8 are passed in as addresses. These should be __stackPointer+4 and __stackPointer+8: i32.const$18=, 4 i32.add $18=, $18, $18 i32.const$19=, 8 i32.add $19=, $18, $19 i32.call$discard=, _ZN22MarchingSquaresFunctorI4Vec414MSVec4AccessorE3RunERKiS4_@FUNCTION, $1, $18, $19 Compiled with following command line: LLC Ashara.opt.ll -o Ashara.s -mtriple="wasm32-unknown-unknown" -- 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 27101] llc crashes while bootstraping LTO (Debug)
https://llvm.org/bugs/show_bug.cgi?id=27101 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Davide Italiano --- r266102. -- 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 27328] New: [ARM] missed pattern for and-not + compare (bics)
https://llvm.org/bugs/show_bug.cgi?id=27328
Bug ID: 27328
Summary: [ARM] missed pattern for and-not + compare (bics)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
define i1 @andnot_cmp(i32 %x, i32 %y) {
%noty = xor i32 %y, -1
%and = and i32 %x, %noty
%cmp = icmp eq i32 %and, 0
ret i1 %cmp
}
I don't know ARM very well, but couldn't this be "bics"?
$ ./llc -o - andn.ll -mtriple=armv7-apple-darwin -mcpu=cortex-a8
_andnot_cmp:
@ BB#0:
mvnr2, r1
movr1, #0
tstr0, r2
movweqr1, #1
movr0, r1
bxlr
--
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 27329] New: ""Node emitted out of order - late" compiling to WASM
https://llvm.org/bugs/show_bug.cgi?id=27329 Bug ID: 27329 Summary: ""Node emitted out of order - late" compiling to WASM Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: gareth_morga...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16209 --> https://llvm.org/bugs/attachment.cgi?id=16209&action=edit Test case with CPP, LL and .s files (with makefile) The attached Basic.ll file will cause this assert in LLC: Assertion failed: I != VRBaseMap.end() && "Node emitted out of order - late", file E:\testcode\llvm\llvm-3.8.0.src\lib\CodeGen\SelectionDAG\InstrEmitter.cpp, line 302 Changing the argument to the Bar function to pass by value, rather than reference makes the assert go away (Basic.works.cpp and Basic.opt.works.ll attached). Testcase (and makefile showing build steps) attached. Callstack below > llc.exe!llvm::InstrEmitter::getVR(llvm::SDValue Op, > llvm::DenseMap int,llvm::DenseMapInfo,llvm::detail::DenseMapPair int> > & VRBaseMap) Line 302 C++ llc.exe!llvm::InstrEmitter::EmitSpecialNode(llvm::SDNode * Node, bool IsClone, bool IsCloned, llvm::DenseMap,llvm::detail::DenseMapPair > & VRBaseMap) Line 901C++ llc.exe!llvm::InstrEmitter::EmitNode(llvm::SDNode * Node, bool IsClone, bool IsCloned, llvm::DenseMap,llvm::detail::DenseMapPair > & VRBaseMap) Line 124C++ llc.exe!llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineBasicBlock::bundle_iterator > & InsertPos) Line 848C++ llc.exe!llvm::SelectionDAGISel::CodeGenAndEmitDAG() Line 867C++ llc.exe!llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator Begin, llvm::ilist_iterator End, bool & HadTailCall) Line 669C++ llc.exe!llvm::SelectionDAGISel::SelectAllBasicBlocks(const llvm::Function & Fn) Line 1362C++ llc.exe!llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction & mf) Line 507C++ llc.exe!`anonymous namespace'::WebAssemblyDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction & MF) Line 55C++ llc.exe!llvm::MachineFunctionPass::runOnFunction(llvm::Function & F) Line 44C++ llc.exe!llvm::FPPassManager::runOnFunction(llvm::Function & F) Line 1550 C++ llc.exe!llvm::FPPassManager::runOnModule(llvm::Module & M) Line 1571 C++ llc.exe!`anonymous namespace'::MPPassManager::runOnModule(llvm::Module & M) Line 1627C++ llc.exe!llvm::legacy::PassManagerImpl::run(llvm::Module & M) Line 1730 C++ llc.exe!llvm::legacy::PassManager::run(llvm::Module & M) Line 1762C++ llc.exe!compileModule(char * * argv, llvm::LLVMContext & Context) Line 408 C++ llc.exe!main(int argc, char * * argv) Line 211C++ -- 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 27330] New: Gas and MC disagree on TLSCALL
https://llvm.org/bugs/show_bug.cgi?id=27330 Bug ID: 27330 Summary: Gas and MC disagree on TLSCALL Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Reported by Rafael: >>> I just noticed that MC and GAS disagree on what format to use for the call >>> >>> MC: >>> ff 90 00 00 00 00 callq *0x0(%rax) >>> >>> Gas: >>> ff 10 callq *(%rax) >>> >>> Looks like MC thinks there is an "actual" relocation that will write a >>> value. Open a bug so this doesn't get lost. -- 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 27327] Arguments converted to WASM .S incorrectly by LLC
https://llvm.org/bugs/show_bug.cgi?id=27327 Derek Schuff changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Derek Schuff --- It turns out this code is generated by LLVM 3.8. The stackpointer lowering code in particular is much improved since then. You should just use tip of tree for WebAssembly, as there has been a lot of development still going on,and we expect plenty more. -- 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 27329] ""Node emitted out of order - late" assert compiling to WASM
https://llvm.org/bugs/show_bug.cgi?id=27329 Derek Schuff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Derek Schuff --- It turns out this code is generated by LLVM 3.8. The stackpointer lowering code in particular is much improved since then. You should just use tip of tree for WebAssembly, as there has been a lot of development still going on,and we expect plenty more. -- 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 27331] New: LiveRange not updated correctly in RegisterCoalescer
https://llvm.org/bugs/show_bug.cgi?id=27331 Bug ID: 27331 Summary: LiveRange not updated correctly in RegisterCoalescer Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: tstel...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16213 --> https://llvm.org/bugs/attachment.cgi?id=16213&action=edit Failing test case Compiling the attached test case results in a verifier error. Command ot reproduce: llc -mtriple=amdgcn--amdhsa -mcpu=fiji coalescer-bug.ll -verify-machineinstrs -o - qcolombet helped be debug this on IRC, and it appears the problem is that the live range information is not updated correctly during this transformation: **BEFORE** %vreg23 = 0 %vreg24:sub0 = %vreg23 %vreg24:sub1 = 2146435072 USE %vreg24 %vreg80:sub0 = %vreg23 %vreg80:sub1 = 1076494336 USE %vreg80 **AFTER** %vreg80:sub0 = 0 %vreg80:sub1 = 2146435072 USE %vreg80 %vreg80:sub1 = 1076494336 USE %vreg80 -- 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 27332] New: Mesa llvmpipe piglit glsl-vs-abs-attribute regression
https://llvm.org/bugs/show_bug.cgi?id=27332 Bug ID: 27332 Summary: Mesa llvmpipe piglit glsl-vs-abs-attribute regression Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: v...@freedesktop.org CC: brian.e.p...@gmail.com, jfons...@vmware.com, llvm-bugs@lists.llvm.org, srol...@vmware.com Classification: Unclassified $ ./bin/shader_runner tests/shaders/glsl-vs-abs-attribute.shader_test -auto shader_runner: /home/vlee/workspace/llvm/lib/IR/Value.cpp:375: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed. Aborted (core dumped) -- 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 26720] [ppc64] int16, int8 are not supported by vec_vsx_ld/vec_vsx_st
https://llvm.org/bugs/show_bug.cgi?id=26720 cycheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from cycheng --- (In reply to comment #8) > Yes, this patch works. Thanks very much! I saw your patch, thanks :) I also committed my posted patch. clang revision: r266166. -- 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
