[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

2019-03-05 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 --- Comment #6 from Martin Liška --- (In reply to Taewook Oh from comment #5) > The name of the function is "void llvm::SmallVectorTemplateBase >::grow(size_t) [with T = > std::pair, const > llvm::DICompositeType*>; bool = false]". > > I tried

[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

2019-03-04 Thread twoh at fb dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 --- Comment #5 from Taewook Oh --- The name of the function is "void llvm::SmallVectorTemplateBase >::grow(size_t) [with T = std::pair, const llvm::DICompositeType*>; bool = false]". I tried with GCC 7.4.0, and seems that GCC 7.4.0 doesn't atte

[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

2019-03-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 --- Comment #4 from Martin Liška --- > > So I investigated further to figure out which instruction actually sets > "0x0" to the new location, and found that instruction 202aef4 below is the > one > > 202aed0: 48 c7 00 00 00 00 00 movq $0x0,

[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

2019-03-01 Thread twoh at fb dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 --- Comment #3 from Taewook Oh --- Here's the compiler command and the preprocessed source. command: https://gist.github.com/taewookoh/45e710594497b887e2ac54168c86c17f source: https://gist.github.com/taewookoh/00f38b4a2f617e78b30d33c8103a7703 T

[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

2019-03-01 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

2019-02-28 Thread twoh at fb dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 --- Comment #1 from Taewook Oh --- And I confirmed that this bug doesn't reproduce with GCC5.