[llvm-bugs] [Bug 28750] New: Handle special cases in AArch64InstrInfo::GetInstSizeInBytes
https://llvm.org/bugs/show_bug.cgi?id=28750 Bug ID: 28750 Summary: Handle special cases in AArch64InstrInfo::GetInstSizeInBytes Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: diana.pi...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified This function tends to return 4 for just about any instruction. This isn't always the case (see PR24234). Looking through AArch64AsmPrinter, it seems STACKMAP and PATCHPOINT may need special handling. The heuristic for inline asm may also need to be brushed up a bit. -- 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 28751] New: MI Parser can't read in block frequencies
https://llvm.org/bugs/show_bug.cgi?id=28751 Bug ID: 28751 Summary: MI Parser can't read in block frequencies Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: diana.pi...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16829 --> https://llvm.org/bugs/attachment.cgi?id=16829&action=edit mir file that can't be read by llc llc -mtriple=aarch64-unknown buggy.mir error: buggy.mir:50:39: unexpected character '/' successors: %bb.1.true(0x4000 / 0x8000 = 50.00%), %bb.2.false(0x4000 / 0x8000 = 50.00%) ^ LLVM ERROR: Unable to initialize machine function The input mir file was obtained by running llc -mtriple=aarch64-unknown -stop-after=block-placement -o buggy.mir. If we remove the block frequencies from the file, it manages to read it, but the output that it produces also contains block frequencies, so it can't be read back in. -- 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 28752] New: Assertion `Parent->isHidden() && "unexpectedly hidden decl"' failed.
https://llvm.org/bugs/show_bug.cgi?id=28752 Bug ID: 28752 Summary: Assertion `Parent->isHidden() && "unexpectedly hidden decl"' failed. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: biancacristinacriste...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified This is seen in the context of building ROOT & Cling with modules using libstdc++. The stack trace is the following: clang-4.0: /home/biancacr/root_GSOC/src/tools/clang/lib/Sema/SemaLookup.cpp:1342: clang::Module* clang::Sema::getOwningModule(clang::Decl*): Assertion `Parent->isHidden() && "unexpectedly hidden decl"' failed. #0 0x01404378 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x1404378) #1 0x0140234e llvm::sys::RunSignalHandlers() (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x140234e) #2 0x014024c4 SignalHandler(int) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x14024c4) #3 0x7ffa08cdcd10 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d10) #4 0x7ffa07ac71c7 gsignal /build/glibc-qbmteM/glibc-2.21/signal/../sysdeps/unix/sysv/linux/raise.c:55:0 #5 0x7ffa07ac8e2a abort /build/glibc-qbmteM/glibc-2.21/stdlib/abort.c:91:0 #6 0x7ffa07ac00bd __assert_fail_base /build/glibc-qbmteM/glibc-2.21/assert/assert.c:92:0 #7 0x7ffa07ac0172 (/lib/x86_64-linux-gnu/libc.so.6+0x2e172) #8 0x02402df3 clang::Sema::getOwningModule(clang::Decl*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x2402df3) #9 0x0240bd57 clang::LookupResult::isVisibleSlow(clang::Sema&, clang::NamedDecl*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x240bd57) #10 0x0240fc6d clang::LookupResult::getAcceptableDecl(clang::NamedDecl*) const (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x240fc6d) #11 0x0240fd6b LookupDirect(clang::Sema&, clang::LookupResult&, clang::DeclContext const*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x240fd6b) #12 0x024108d6 clang::Sema::LookupQualifiedName(clang::LookupResult&, clang::DeclContext*, bool) [clone .part.1297] (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x24108d6) #13 0x0233d87f clang::Sema::BuildQualifiedDeclarationNameExpr(clang::CXXScopeSpec&, clang::DeclarationNameInfo const&, bool, clang::Scope const*, clang::TypeSourceInfo**) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x233d87f) #14 0x025a8f02 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDependentScopeDeclRefExpr(clang::DependentScopeDeclRefExpr*, bool, clang::TypeSourceInfo**) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x25a8f02) #15 0x025a98ad clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDependentScopeDeclRefExpr(clang::DependentScopeDeclRefExpr*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x25a98ad) #16 0x0258bca7 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x258bca7) #17 0x025b35f0 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformUnaryOperator(clang::UnaryOperator*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x25b35f0) #18 0x0258bf6b clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x258bf6b) #19 0x025a4085 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&, bool) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x25a4085) #20 0x025a7ad2 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x25a7ad2) #21 0x0259e0cd clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTSIInObjectScope(clang::TypeLoc, clang::QualType, clang::NamedDecl*, clang::CXXScopeSpec&) [clone .isra.3469] (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x259e0cd) #22 0x0259ea14 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformNestedNameSpecifierLoc(clang::NestedNameSpecifierLoc, clang::QualType, clang::NamedDecl*) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x259ea14) #23 0x025ab9df clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformDependentNameType(clang::TypeLocBuilder&, clang::DependentNameTypeLoc) (/home/biancacr/root_GSOC/inst/bin/clang-4.0+0x25ab9df) #24 0x02595989 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTyp
[llvm-bugs] [Bug 28723] Can't have OpenMP enabled while compiling CUDA (even without any OpenMP constructs)
https://llvm.org/bugs/show_bug.cgi?id=28723 Samuel Antao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Samuel Antao --- Fixed in r276979. -- 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 28725] instcombine/const folding segfaults with attached module
https://llvm.org/bugs/show_bug.cgi?id=28725 Reid Kleckner changed: What|Removed |Added Status|REOPENED|RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #12 from Reid Kleckner --- Reclosing, this was fixed in r276827 -- 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 28753] New: SystemZ backend: failing assert in ScheduleDAGRRList
https://llvm.org/bugs/show_bug.cgi?id=28753 Bug ID: 28753 Summary: SystemZ backend: failing assert in ScheduleDAGRRList Product: new-bugs Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: colp...@ca.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16831 --> https://llvm.org/bugs/attachment.cgi?id=16831&action=edit C source To reproduce, compile bug.c with clang -O1 -target s390x-linux-gnu -c bug.c Compilation aborts during "DAG->DAG Pattern Instruction Selection" with this failed assert: llvm/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp:1197: llvm::MVT getPhysicalRegisterVT(llvm::SDNode*, unsigned int, const llvm::TargetInstrInfo*): Assertion `MCID.ImplicitDefs && "Physical reg def must be in implicit def list!"' failed. Compiling at -O0 does not reproduce the failure. Changing "shift" in bug.c to a value lower than 64 also causes compilation to pass. LLVM/Clang is from SVN trunk 276984. -- 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 28754] New: UBSan reports false positives on unaligned memory accesses on MS ABI
https://llvm.org/bugs/show_bug.cgi?id=28754 Bug ID: 28754 Summary: UBSan reports false positives on unaligned memory accesses on MS ABI Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: resis...@mac.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Microsoft explicitly documents unaligned memory accesses on scalar types to be allowed under their ABI, though natural alignment is still recommended for performance reasons. UBSan still reports errors on unaligned scalar accesses, leading to false positives on code that is compliant with the MS ABI. Note that Microsoft's document does still require natural alignment for members of unions and aggregates. MS alignment documentation for scalar types: https://msdn.microsoft.com/en-us/library/94z15h2c.aspx MS alignment documentation for unions and aggregates: https://msdn.microsoft.com/en-us/library/9dbwhz68.aspx -- 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 28755] New: Codegen faiilure: ran out of registers during register allocation
https://llvm.org/bugs/show_bug.cgi?id=28755 Bug ID: 28755 Summary: Codegen faiilure: ran out of registers during register allocation Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: pir...@google.com CC: llvm-bugs@lists.llvm.org, srhi...@google.com Classification: Unclassified Created attachment 16832 --> https://llvm.org/bugs/attachment.cgi?id=16832&action=edit Zip archive with files to reproduce the crash File class_linker.cc in a pending AOSP CL (https://android-review.googlesource.com/#/c/251065/1/runtime/class_linker.cc) fails CodeGen with the following error: fatal error: error in backend: ran out of registers during register allocation clang++: error: clang frontend command failed with exit code 70 (use -v to see invocation) Android clang version 3.8.271374 (based on LLVM 3.8.271374) Target: i686--linux-android Thread model: posix InstalledDir: prebuilts/clang/host/linux-x86/clang-3016494/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: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++: note: diagnostic msg: /tmp/class_linker-1e703f.cpp clang++: note: diagnostic msg: /tmp/class_linker-1e703f.sh clang++: note: diagnostic msg: A .zip file with class_linker-1e703f.cpp and class_linker-1e703f.sh is attached. Also attached is a reduced IR from bugpoint. With this IR, the following command reproduces the crash: llc class_linker-reduced.ll Note that while the original source has inline assembly, the reduced test case doesn't. -- 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 28756] New: Xbox Tech 1 855 338 0710 Xbox Customer Support Number
https://llvm.org/bugs/show_bug.cgi?id=28756 Bug ID: 28756 Summary: Xbox Tech 1 855 338 0710 Xbox Customer Support Number Product: new-bugs Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: samitasinh...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified xbox live customer service number,, xbox help,, xbox live customer service,, xbox live phone number,, xbox customer service,, xbox number,, xbox tech support,, xbox customer service number,, xbox support,, xbox 360 customer support number,, xbox company phone number,, xbox one customer service number,, xbox help number,, xbox phone number,, xbox 360 customer service number,, xbox contact number,, xbox live contact number,, xbox 360 phone number,, xbox live number,, xbox live number to call,, xbox customer support number,, xbox live help number,, xbox 360 support phone number,, phone number for xbox,, xbox live telephone number,, phone number for xbox live support,, xbox helpline,, xbox live support phone number,, xbox 800 number,, xbox support phone number,, xbox 360 tech support phone number,, contact xbox live,, xbox one support phone number,, xbox 1800 number,, phone number for xbox one support,, xbox customer support,, xbox tech support number,, xbox 360 support number,, xbox live customer service phone number,, xbox nuWQ mn6mbers to call -- 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 28757] New: Preserveall Calling convention breaks libunwind stack walking
https://llvm.org/bugs/show_bug.cgi?id=28757 Bug ID: 28757 Summary: Preserveall Calling convention breaks libunwind stack walking Product: new-bugs Version: 3.9 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: alk...@microsoft.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The mono project has found that when the calling convention is set to preserveall on linux, the stack is corrupted in such a way that new frames appear in a stacktrace. These frames have ip addresses which are usually not in any mapped memory range. This causes libgcc's exception handling unwinder to abort stack walking upon hitting the garbage frame. -- 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 27867] PGO data for "static" functions invalidated if different build directories are used.
https://llvm.org/bugs/show_bug.cgi?id=27867 Jake VanAdrighem changed: What|Removed |Added Status|NEW |RESOLVED CC||jvanadrig...@gmail.com Resolution|--- |FIXED --- Comment #1 from Jake VanAdrighem --- A fix for this was committed in r275193. -- 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 28758] New: Silently allows the erroneous type 'restrict void *' to conditional expression.
https://llvm.org/bugs/show_bug.cgi?id=28758
Bug ID: 28758
Summary: Silently allows the erroneous type 'restrict void *'
to conditional expression.
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: kylesheilastew...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
A conditional expression with second operand of type `void*` and third operand
`int* restrict*` would, by the rules of the conditional operator, have type
`restrict void *`. This type is not allowed, and so should produce a diagnostic
message. However, the following compiles without any diagnostic messages:
#include
int main(void){
int* restrict* A = malloc(8);
A ? A : malloc(8);
return 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 28760] New: [ThinLTO] assert(GS != DefinedGlobals.end()) failed
https://llvm.org/bugs/show_bug.cgi?id=28760
Bug ID: 28760
Summary: [ThinLTO] assert(GS != DefinedGlobals.end()) failed
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: t...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Encountered assert(GS != DefinedGlobals.end()) failure while running ThinLTO.
The assertion statement is in MustPreserveGV lambda function in
llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp).
It seems that the assertion fails because it fails to recover the "original
name" of the global value. ModuleSummaryIndex::getOriginalNameBeforePromote
attempts to get the original name by stripping .llvm.{MODHASH}, but what I
observe is that ".1" is still appended to the expected original name.
Then where this extra ".1" comes from? It is appended when the global value is
materialized. IRLinker::materialize function calls
IRLinker::linkGlobalValueProto function, and inside that function if DGV is
nullptr or ShouldLink is true then IRLinker::copyGlobalValueProto function is
called to create a global variable in the destination module that corresponds
to SGV. I found that newly created global variable has the extra ".1" added to
the name of the SGV.
When this thing happens? I don't have a complete understanding about it but I
observed that the same global value is materialized twice during the single
invocation of IRLinker::run function, once with GlobalValueMaterializer and
once with LocalValueMaterializer. First, the global value
; Materializable
; Function Attrs: nounwind uwtable
define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2
personality i32 (...)* @__gxx_personality_v0 {}
(I renamed the function and comdat)
it materialized with GlobalValueMaterializer, (so the IRLinker::materialize
function is called with ForAlias == false), and the materialized value is
; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2
Then, later, the same value is materialized again with LocalValueMaterializer
(so ForAlias == true for IRLinker::materialize), and the materialized value is
; Function Attrs: nounwind uwtable
define internal void @foo.1(%"type 0x7efb6ee89d80"*) unnamed_addr #2
comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 !dbg
!12345 {
// function definition
}
--
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 28761] New: unused variable '__O' in avx512fintrin.h
https://llvm.org/bugs/show_bug.cgi?id=28761
Bug ID: 28761
Summary: unused variable '__O' in avx512fintrin.h
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Headers
Assignee: unassignedclangb...@nondot.org
Reporter: lon...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In https://llvm.org/svn/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h
static __inline__ __m256i __DEFAULT_FN_ATTRS
_mm512_cvtsepi64_epi32 (__m512i __A)
{
__v8si __O;
return (__m256i) __builtin_ia32_pmovsqd512_mask ((__v8di) __A,
(__v8si) _mm256_undefined_si256 (),
(__mmask8) -1);
}
__O is not used. This is annoying when compiling with -Werror:
clang/intrinsics/avx512fintrin.h:7505:10: error: unused variable '__O'
[-Werror,-Wunused-variable]
__v8si __O;
^
1 error generated.
This is present in 3.9.0 and 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 28762] New: clang-format: add a style option for disabling all function arguments on one line
https://llvm.org/bugs/show_bug.cgi?id=28762
Bug ID: 28762
Summary: clang-format: add a style option for disabling all
function arguments on one line
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: jaco...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The style option `AllowAllParametersOfDeclarationOnNextLine` allows me to
prevent clang-format from pulling all parameters in a function declaration onto
a single line when I have intentionally put them on separate lines. This is
great.
But there doesn't appear to be a corresponding option for function calls.
`clang-format` is happy to pull function arguments onto a single line, even
when I've intentionally put them on separate lines and disabled bin packing.
Small example that reproduces this:
% cat .clang-format
ColumnLimit: 80
BinPackArguments: false
BinPackParameters: false
AllowAllParametersOfDeclarationOnNextLine: false
AlignAfterOpenBracket: AlwaysBreak
% cat foo.cc
extern int arg_0, arg_1, arg_2;
void
DoSomethingWithThreeIntsThatRequiresAVeryLongFunctionNameSeriouslyLong(
int a,
int b,
int c);
void foo() {
// I'm intentionally putting these one per line; I want them to align.
DoSomethingWithThreeIntsThatRequiresAVeryLongFunctionNameSeriouslyLong(
arg_0,
arg_1,
arg_2);
}
% clang-format -style=file foo.cc
extern int arg_0, arg_1, arg_2;
void
DoSomethingWithThreeIntsThatRequiresAVeryLongFunctionNameSeriouslyLong(
int a,
int b,
int c);
void foo() {
// I'm intentionally putting these one per line; I want them to align.
DoSomethingWithThreeIntsThatRequiresAVeryLongFunctionNameSeriouslyLong(
arg_0, arg_1, arg_2);
}
--
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 28763] New: wrong code at -Os on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=28763
Bug ID: 28763
Summary: wrong code at -Os on x86_64-linux-gnu
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
The following code is miscompiled by the current clang trunk on
x86_64-linux-gnu at -Os in both the 32-bit and 64-bit modes.
This is a regression from 3.8.x.
$ clang -v
clang version 4.0.0 (trunk 276903)
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.3
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.3
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.1.1
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 -O1 small.c; ./a.out
0
$ clang-3.8 -Os small.c; ./a.out
0
$
$ clang -Os small.c
$ ./a.out
1
$
--
int printf (const char *, ...);
int a, c = 1;
static short b;
void fn1 ()
{
c = 2;
}
int fn2 (int p1)
{
for (; a < 1; a++)
printf ("%d\n", c);
return p1;
}
int main ()
{
int d = c && b;
c = d;
fn2 (0);
fn1 ();
return 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 28764] New: IRCE breaks simplified of loops
https://llvm.org/bugs/show_bug.cgi?id=28764 Bug ID: 28764 Summary: IRCE breaks simplified of loops Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: michael.v.zolotuk...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16833 --> https://llvm.org/bugs/attachment.cgi?id=16833&action=edit Patch for enabling verification in loop-simplify IRCE seems to break simplified form of loops, i.e. after it loops might be missing a preheader or their exits might be not dedicated (i.e. exits have a predecessors outside the loop). That (along with some other problems) stops us from enabling loop-simplify verification in the pass pipeline. To reproduce the issue apply the attached patch (it enables verification in loop-simplify) and then run 'ninja check'. I get the following failures: Failing Tests (8): LLVM :: Transforms/IRCE/conjunctive-checks.ll LLVM :: Transforms/IRCE/decrementing-loop.ll LLVM :: Transforms/IRCE/multiple-access-no-preloop.ll LLVM :: Transforms/IRCE/only-upper-check.ll LLVM :: Transforms/IRCE/single-access-no-preloop.ll LLVM :: Transforms/IRCE/single-access-with-preloop.ll LLVM :: Transforms/IRCE/skip-profitability-checks.ll LLVM :: Transforms/IRCE/with-parent-loops.ll -- 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 28765] New: Post-RA scheduler moves code across asm sideeffect
https://llvm.org/bugs/show_bug.cgi?id=28765
Bug ID: 28765
Summary: Post-RA scheduler moves code across asm sideeffect
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: matthew.arsena...@amd.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
define void @loop(i32 addrspace(1)* %arg) nounwind {
bb:
br label %bb2
bb2:
%loop.idx = phi i32 [ 0, %bb ], [ %inc, %bb2 ]
call void asm sideeffect "
v_nop_e64
v_nop_e64", ""()
%inc = add nsw i32 %loop.idx, 1
%cmp = icmp slt i32 %inc, 10
br i1 %cmp, label %bb2, label %bb3 ; -
bb3:
ret void
}
llc -march=amdgcn on this testcase shows the add and compare are moved before
the inlineasm by the post-RA scheduler:
BB0_1: ; %bb2
; =>This Inner Loop Header: Depth=1
v_add_i32_e32 v0, vcc, 1, v0
v_cmp_gt_i32_e32 vcc, 10, v0
;;#ASMSTART
v_nop_e64
v_nop_e64
;;#ASMEND
s_and_b64 vcc, exec, vcc
s_cbranch_vccnz BB0_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 28756] Xbox Tech 1 855 338 0710 Xbox Customer Support Number
https://llvm.org/bugs/show_bug.cgi?id=28756 George Burgess changed: What|Removed |Added Status|ASSIGNED|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 28763] wrong code at -Os on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=28763 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Component|-New Bugs |Scalar Optimizations Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | Product|clang |libraries --- Comment #5 from David Majnemer --- Fixed in r277114. -- 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 28709] lldb-mi: break-insert not working when using absolute paths
https://llvm.org/bugs/show_bug.cgi?id=28709 Ilia changed: What|Removed |Added Status|NEW |RESOLVED CC||ki.s...@gmail.com 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
