[llvm-bugs] [Bug 27158] AArch64InstrInfo::optimizeCompareInstr incorrectly removes compare instructions
https://llvm.org/bugs/show_bug.cgi?id=27158 Evgeny Astigeevich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Evgeny Astigeevich --- Committed revision 266969. -- 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 27444] New: Do not supply -Wbitwise-op-parentheses by default
https://llvm.org/bugs/show_bug.cgi?id=27444 Bug ID: 27444 Summary: Do not supply -Wbitwise-op-parentheses by default Product: clang Version: 3.7 Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: fuz...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified clang seems to have -Wbitwise-op-parentheses enabled by default, causing hundreds of suprious warnings to appear when compiling perfectly fine code. I request that clang should not warn about things like "&& within ||" or "& within |" by default as these things appear often in normal C code and are usually not an indication of incorrect code. After all, most C programmers are able to remember that & has higher precedence than | by analogy to * and + as has been the case in mathematics since the 18th century. -- 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 25077] BBVectorizer crashes when trying to combine an extract element with non-const 2nd arg
https://llvm.org/bugs/show_bug.cgi?id=25077 Anastasia Stulova changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Anastasia Stulova --- Thanks! Closing it 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 27445] New: Regression(266932:266938): Assertion failed: Layout && "Unable to find record layout information for type" when building chromium with clang-cl
https://llvm.org/bugs/show_bug.cgi?id=27445 Bug ID: 27445 Summary: Regression(266932:266938): Assertion failed: Layout && "Unable to find record layout information for type" when building chromium with clang-cl Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 27446] New: Regression(266932:266938): Assertion failed: Layout && "Unable to find record layout information for type" when building chromium with clang-cl
https://llvm.org/bugs/show_bug.cgi?id=27446 Bug ID: 27446 Summary: Regression(266932:266938): Assertion failed: Layout && "Unable to find record layout information for type" when building chromium with clang-cl Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified repro to follow -- 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 27446] Regression(266932:266938): Assertion failed: Layout && "Unable to find record layout information for type" when building chromium with clang-cl
https://llvm.org/bugs/show_bug.cgi?id=27446 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Nico Weber --- *** This bug has been marked as a duplicate of bug 27445 *** -- 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 13559] clang fails to apply constructor alias optimization
https://llvm.org/bugs/show_bug.cgi?id=13559
Rafael Ávila de Espíndola changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Rafael Ávila de Espíndola ---
(In reply to comment #1)
> (In reply to comment #0)
> > On this testcase:
> >
> > struct X {
> > X(int j) : i(j) {}
> > int i;
> > };
> >
> > int main() {
> > X x(10);
> > }
> >
> > $ clang b6940259.cc -flto -S -o - -O3 -mllvm -disable-llvm-optzns
> >
> > emits a @_ZN1XC1Ei that calls @_ZN1XC2Ei. It should just be an alias.
>
> FWIW we currently don't produce C1 at all in this example at the moment, if
> I'm testing this correctly.
I see the same. Closing the bug as fixed. Please reopen if you have a testcase
that still fails.
--
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 27445] Regression(266932:266938): Assertion failed: Layout && "Unable to find record layout information for type" when building chromium with clang-cl
https://llvm.org/bugs/show_bug.cgi?id=27445 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Nico Weber --- Hm, I can repro this with older clangs too, but our pinned bots look happy. I'll file this again once I have a better idea what's going on. -- 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 19957] OpenCL incorrectly accepts implicit address space conversion with ternary operator
https://llvm.org/bugs/show_bug.cgi?id=19957
yaxun@amd.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #21 from yaxun@amd.com ---
Bug fixed.
Now emit errors for the testcase:
bad_implicit_address_space_conversion.cl:9:21: error: conditional operator with
the second and third operands of type ('__global int *' and '__local int *')
which are pointers to non-overlapping address spaces
int *ptr = cond ? gint : lint;
^
bad_implicit_address_space_conversion.cl:19:27: error: conditional operator
with the second and third operands of type ('__global int *' and '__local int
*') which are pointers to non-overlapping address spaces
local int *ptr = cond ? gint : lint;
^
bad_implicit_address_space_conversion.cl:28:28: error: conditional operator
with the second and third operands of type ('__global int *' and '__local int
*') which are pointers to non-overlapping address spaces
global int *ptr = cond ? gint : lint;
^
3 errors generated.
--
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 27447] New: [LTO] Symbol lookup error when linking with shared libraries
https://llvm.org/bugs/show_bug.cgi?id=27447
Bug ID: 27447
Summary: [LTO] Symbol lookup error when linking with shared
libraries
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat try.sh
rm -rf main-lld libshlld.so
./clang shared.cpp -o libshlld.so -shared -fPIC -fuse-ld=lld -flto
./clang main.cpp -L. -o main-lld -fuse-ld=lld -flto -lshlld
./main-lld
./main-lld: symbol lookup error: ./libshlld.so: undefined symbol: _ZSt4cout
$ cat main.cpp
int
main(void)
{
return (0);
}
[davide@localhost bin]$ cat shared.cpp
#include
int f(); // forward declaration
int g(); // forward declaration
int x = f();
int y = g();
int f()
{
std::cout << "using 'y' (which is " << y << ")\n";
return 3*y + 7;
}
int g()
{
std::cout << "initializing 'y'\n";
return 5;
}
--
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 27448] New: LLD/ELF does not support `--no-undefined-version`
https://llvm.org/bugs/show_bug.cgi?id=27448 Bug ID: 27448 Summary: LLD/ELF does not support `--no-undefined-version` Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: compn...@compnerd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified >From the documentation: Normally when a symbol has an undefined version, the linker will ignore it. This option disallows symbols with undefined version and a fatal error will be issued instead. -- 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 27443] [CWG 734] Nonconforming aliasing of block scope objects
https://llvm.org/bugs/show_bug.cgi?id=27443 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #3 from Richard Smith --- *** This bug has been marked as a duplicate of bug 18538 *** -- 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 27449] New: Retire the non-deterministic ASTFileSignature
https://llvm.org/bugs/show_bug.cgi?id=27449
Bug ID: 27449
Summary: Retire the non-deterministic ASTFileSignature
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Modules
Assignee: unassignedclangb...@nondot.org
Reporter: apra...@apple.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Implicitly-built modules currently contain a random 32-bit ASTFileSignature.
This makes clang modules nondeterministic which is generally undesirable.
ASTReader has a comment that explains how we arrived at the status quo nicely:
// For implicit modules we output a signature that we can use to ensure
// duplicate module builds don't collide in the cache as their output order
// is non-deterministic.
// FIXME: Remove this when output is deterministic.
if (Context.getLangOpts().ImplicitModules) {
Signature = getSignature();
RecordData::value_type Record[] = {Signature};
Stream.EmitRecord(SIGNATURE, Record);
}
static ASTFileSignature getSignature() {
while (1) {
if (ASTFileSignature S = llvm::sys::Process::GetRandomNumber())
return S;
// Rely on GetRandomNumber to eventually return non-zero...
}
}
The existence of test/Modules/stress1.cpp seems to indicate that we were able
to remove all(?) sources of nondeterminism in the mean time, so we should be
able to retire this hack.
A minor complication is that module debug info currently uses the module
signature as the DWO_id to uniquely identify a module, but we should be able to
replace this by an actual hash of the serialized AST (which won't be
deterministic until after the ASTFileSignature is 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 27450] New: clang-cl /c /dev/null crashes driver if /Yc is passed
https://llvm.org/bugs/show_bug.cgi?id=27450 Bug ID: 27450 Summary: clang-cl /c /dev/null crashes driver if /Yc is passed Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified thakis@thakis:~/src/llvm-build$ bin/clang-cl /c /dev/null /FIfoo.h /Ycfoo.h clang-cl: /usr/local/google/home/thakis/src/llvm-rw/tools/clang/lib/Driver/Driver.cpp:1705: clang::driver::Action* clang::driver::Driver::ConstructPhaseAction(clang::driver::Compilation&, const llvm::opt::ArgList&, clang::driver::phases::ID, clang::driver::Action*) const: Assertion `OutputTy != types::TY_INVALID && "Cannot preprocess this input type!"' failed. 0 clang-cl0x01be9a25 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 clang-cl0x01be77d6 llvm::sys::RunSignalHandlers() + 54 -- 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 27450] clang-cl /c /dev/null crashes driver if /Yc is passed
https://llvm.org/bugs/show_bug.cgi?id=27450 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nico Weber --- 267040. -- 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 27451] New: Clang doesn't add LLVM lifetime markers for temporaries created by lifetime extension
https://llvm.org/bugs/show_bug.cgi?id=27451
Bug ID: 27451
Summary: Clang doesn't add LLVM lifetime markers for
temporaries created by lifetime extension
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: timshe...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
// RUN: clang++ -O2 -S -emit-llvm -fno-exceptions -std=c++11 %s -o - |
FileCheck %s
// CHECK: @llvm.lifetime.start
#include
extern void Bar(const std::string&);
void Foo() {
// Both string objects should share the same stack slot, but they don't.
{
const std::string& v = {"asdf"};
Bar(v);
}
{
const std::string& v = {"adsf"};
Bar(v);
}
}
--
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 27451] Clang doesn't add LLVM lifetime markers for temporaries created by lifetime extension
https://llvm.org/bugs/show_bug.cgi?id=27451 Tim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Tim --- Just need to find the right search term to duplicate the bug. :) *** This bug has been marked as a duplicate of bug 5629 *** -- 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 27451] Clang doesn't add LLVM lifetime markers for temporaries created by lifetime extension
https://llvm.org/bugs/show_bug.cgi?id=27451 Tim changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #3 from Tim --- I found that this bug is different from PR 5629, since now only having a lifetime extended temporary (rather than a variable with value type) triggers 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 27453] New: [ASan] Implement use-after-scope check.
https://llvm.org/bugs/show_bug.cgi?id=27453
Bug ID: 27453
Summary: [ASan] Implement use-after-scope check.
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: vitalyb...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Some local variables can have lifetime smaller then function execution.
E.g.:
int main() {
int *p = nullptr;
{
int x = 0;
p = &x;
}
return *p;
}
Usually such cases does not crash, as stack frame still has region allocated
for such variables. Still content of such variables after lifetime end is
undefined.
Asan is can detect such cases by poisoning/poisoning memory according lifetime
markers.
--
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 27454] New: [Cyclone] Register spills related to FeatureZCZeroing
https://llvm.org/bugs/show_bug.cgi?id=27454
Bug ID: 27454
Summary: [Cyclone] Register spills related to FeatureZCZeroing
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: haich...@codeaurora.org
CC: gbe...@codeaurora.org, llvm-bugs@lists.llvm.org,
mcros...@codeaurora.org
Classification: Unclassified
Created attachment 16245
--> https://llvm.org/bugs/attachment.cgi?id=16245&action=edit
a .ll test case that has extra register spills if using -mcpu=cyclone
I am trying to port FeatureZCZeroing from Cyclone to Kryo. Using immediate #0
to zero out W and X registers works great in Kryo. But using #0 to zero out
float registers sometimes causes extra register spills or move instructions on
either Cyclone or Kryo.
I attached a reduced IR test case which basically corresponds to the following
C code
double foo(int n) {
double r=-1;
for (int i=0;iThis Inner Loop Header: Depth=1
strq0, [sp]// 16-byte Folded Spill
ldrq0, [sp]// 16-byte Folded Reload
blsin
fmaxnmd8, d8, d0
ldrq0, [sp]// 16-byte Folded Reload
faddd0, d0, d9
addw20, w20, #1// =1
cmpw20, w19
b.lt.LBB0_1
If FeatureZCZeroing is disabled (together with FeatureZCRegMove) on Cyclone,
the translated assembly does not have these load/store instructions:
.LBB0_1:// %for.body
// =>This Inner Loop Header: Depth=1
movv0.16b, v8.16b
blsin
fmaxnmd9, d9, d0
faddd8, d8, d10
addw20, w20, #1// =1
cmpw20, w19
b.lt.LBB0_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 27455] New: disagreement with GCC about ABI of libgcc functions on hard-float ARM
https://llvm.org/bugs/show_bug.cgi?id=27455
Bug ID: 27455
Summary: disagreement with GCC about ABI of libgcc functions on
hard-float ARM
Product: clang
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: br...@peloton-tech.com
CC: an...@korobeynikov.info, compn...@compnerd.org,
jonat...@codesourcery.com, kristof.be...@arm.com,
llvm-bugs@lists.llvm.org, tzuhsiang.ch...@gmail.com
Classification: Unclassified
Created attachment 16246
--> https://llvm.org/bugs/attachment.cgi?id=16246&action=edit
A simple program which demonstrates the affects
Clang and GCC disagree about the calling convention for the helper functions in
libgcc/compiler-rt on ARM with hardware floating point. Clang passes the
floating point arguments in integer registers (like with -mfloat-abi=soft), but
GCC calls them like other functions with the hard-float ABI. The only reference
to this I can find online is an LLVM development mailing list post [1]
discussing why Clang switched to always using soft-float. At least one of the
Clang developers thought GCC did this too, but it doesn't seem to currently.
Complex arithmetic is implemented with these functions even when hardware
floating point is supported, which means complex arithmetic is pretty
completely broken on platforms like this when using libgcc.
[1] http://lists.llvm.org/pipermail/llvm-dev/2014-October/077898.html
I found the code in clang's lib/CodeGen/TargetInfo.cpp which sets BuiltinCC to
CallingConv::ARM_AAPCS and the __attribute__((pcs("aapcs"))) in compiler-rt's
lib/builtins/int_lib.h which compiles the relevant functions that way. I can't
find any evidence of GCC doing either of those.
In all three copies of libgcc.a I've disassembled (Debian Jessie armhf and both
of the ones from gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf) __divdc3
(for example) definitely uses the hard-float ABI. In
clang+llvm-3.8.0-armv7a-linux-gnueabihf/lib/clang/3.8.0/lib/linux/libclang_rt.builtins-armhf.a
(downloaded from llvm.org), __divdc3 is definitely using the soft-float ABI.
Attached is a simple program which demonstrates the effects.
I've tried with Clang 3.7.1 I cross-compiled for armhf myself and 3.8.0
binaries downloaded from llvm.org.
$ gcc -lm test_complex.c -O3 && ./a.out
works
$ clang -lm test_complex.c -O3 && ./a.out
broken
On 4/21/16 2:36 PM, Renato Golin via cfe-dev wrote:
> I checked with the GCC folks, and the behaviour is:
>
> * arm-linux-gnueabi has *only* soft-float
> * arm-linux-gnueagihf has *only* hard float
> * arm-none-eabi has *all* variations (above) with the default being
> soft-float
--
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 27457] New: Possible regression: "invalid explicitly-specified argument" on enum value as template parameter
https://llvm.org/bugs/show_bug.cgi?id=27457
Bug ID: 27457
Summary: Possible regression: "invalid explicitly-specified
argument" on enum value as template parameter
Product: clang
Version: 3.6
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: trpri...@synopsys.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org,
sig-rnd-sat-clang-b...@synopsys.com
Classification: Unclassified
Some time prior to clang 3.6.2, clang accepted the following snippet, but now
rejects it:
$ cat t.cpp
enum MyEnum { e };
class A {};
template void foo(A) { }
#ifndef HIDE
template void foo(int) { }
#endif
void bar() { foo(A()); }
$
Clang 3.5:
$ clang-3.5 -v
clang version 3.5.2 (tags/RELEASE_352/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
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.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ clang-3.5 -c t.cpp
$
Clang 3.6:
$ clang-3.6 -v
clang version 3.6.2 (tags/RELEASE_362/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
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.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ clang-3.6 -c t.cpp
t.cpp:7:14: error: no matching function for call to 'foo'
void bar() { foo(A()); }
^~
t.cpp:5:21: note: candidate function [with $0 = 0] not viable: no known
conversion from 'A' to 'int' for 1st argument
template void foo(int) { }
^
t.cpp:3:24: note: candidate template ignored: invalid explicitly-specified
argument for 1st template parameter
template void foo(A) { }
^
1 error generated.
$
When the second template is omitted, both clang versions accept the snippet:
$ clang-3.5 -DHIDE -c t.cpp
$ clang-3.6 -DHIDE -c t.cpp
$
I can reproduce this with a recent svn build 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 27456] New: PPC make check has a bunch of machine verifier errors
https://llvm.org/bugs/show_bug.cgi?id=27456 Bug ID: 27456 Summary: PPC make check has a bunch of machine verifier errors Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Switching the machine verifier ON by default (lib/CodeGen/Passes.cpp then change the default value of the cl::opt related to the machine verifier) leads to a bunch of machine verifier errors for make check: LLVM :: CodeGen/PowerPC/2006-10-17-ppc64-alloca.ll LLVM :: CodeGen/PowerPC/2007-10-21-LocalRegAllocAssert.ll LLVM :: CodeGen/PowerPC/2007-10-21-LocalRegAllocAssert2.ll LLVM :: CodeGen/PowerPC/2007-11-16-landingpad-split.ll LLVM :: CodeGen/PowerPC/2012-10-11-dynalloc.ll LLVM :: CodeGen/PowerPC/2016-01-07-BranchWeightCrash.ll LLVM :: CodeGen/PowerPC/Frames-alloca.ll LLVM :: CodeGen/PowerPC/aantidep-inline-asm-use.ll LLVM :: CodeGen/PowerPC/atomic-2.ll LLVM :: CodeGen/PowerPC/atomics.ll LLVM :: CodeGen/PowerPC/cr-spills.ll LLVM :: CodeGen/PowerPC/cr_spilling.ll LLVM :: CodeGen/PowerPC/crsave.ll LLVM :: CodeGen/PowerPC/ctr-cleanup.ll LLVM :: CodeGen/PowerPC/ctrloop-intrin.ll LLVM :: CodeGen/PowerPC/ctrloop-large-ec.ll LLVM :: CodeGen/PowerPC/ctrloop-udivti3.ll LLVM :: CodeGen/PowerPC/dyn-alloca-offset.ll LLVM :: CodeGen/PowerPC/early-ret2.ll LLVM :: CodeGen/PowerPC/emutls_generic.ll LLVM :: CodeGen/PowerPC/fast-isel-fcmp-nan.ll LLVM :: CodeGen/PowerPC/fast-isel-load-store-vsx.ll LLVM :: CodeGen/PowerPC/indirectbr.ll LLVM :: CodeGen/PowerPC/merge-st-chain-op.ll LLVM :: CodeGen/PowerPC/negctr.ll LLVM :: CodeGen/PowerPC/p8-scalar_vector_conversions.ll LLVM :: CodeGen/PowerPC/ppc-shrink-wrapping.ll LLVM :: CodeGen/PowerPC/ppc-vaarg-agg.ll LLVM :: CodeGen/PowerPC/ppc32-pic-large.ll LLVM :: CodeGen/PowerPC/ppc32-pic.ll LLVM :: CodeGen/PowerPC/ppc64-anyregcc-crash.ll LLVM :: CodeGen/PowerPC/ppc64-anyregcc.ll LLVM :: CodeGen/PowerPC/ppc64-patchpoint.ll LLVM :: CodeGen/PowerPC/ppc64-stackmap.ll LLVM :: CodeGen/PowerPC/pr25157-peephole.ll LLVM :: CodeGen/PowerPC/pr25157.ll LLVM :: CodeGen/PowerPC/pr26180.ll LLVM :: CodeGen/PowerPC/pr26690.ll LLVM :: CodeGen/PowerPC/sj-ctr-loop.ll LLVM :: CodeGen/PowerPC/sjlj.ll LLVM :: CodeGen/PowerPC/stack-realign.ll LLVM :: CodeGen/PowerPC/stwux.ll LLVM :: CodeGen/PowerPC/vsx-fma-mutate-undef.ll LLVM :: CodeGen/PowerPC/vsx-self-copy.ll This may be latent bugs. -- 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 27458] New: Mips make check has a bunch of machine verifier errors
https://llvm.org/bugs/show_bug.cgi?id=27458 Bug ID: 27458 Summary: Mips make check has a bunch of machine verifier errors Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: MIPS Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Switching the machine verifier ON by default (lib/CodeGen/Passes.cpp then change the default value of the cl::opt related to the machine verifier) leads to a bunch of machine verifier errors for make check: LLVM :: CodeGen/Mips/Fast-ISel/callabi.ll LLVM :: CodeGen/Mips/Fast-ISel/fastalloca.ll LLVM :: CodeGen/Mips/Fast-ISel/fpcmpa.ll LLVM :: CodeGen/Mips/Fast-ISel/memtest1.ll LLVM :: CodeGen/Mips/adjust-callstack-sp.ll LLVM :: CodeGen/Mips/align16.ll LLVM :: CodeGen/Mips/alloca16.ll LLVM :: CodeGen/Mips/atomic.ll LLVM :: CodeGen/Mips/atomicops.ll LLVM :: CodeGen/Mips/brsize3.ll LLVM :: CodeGen/Mips/cannot-copy-registers.ll LLVM :: CodeGen/Mips/cmplarge.ll LLVM :: CodeGen/Mips/dsp-r1.ll LLVM :: CodeGen/Mips/ex2.ll LLVM :: CodeGen/Mips/extins.ll LLVM :: CodeGen/Mips/fpbr.ll LLVM :: CodeGen/Mips/hf16call32.ll LLVM :: CodeGen/Mips/hf1_body.ll LLVM :: CodeGen/Mips/hfptrcall.ll LLVM :: CodeGen/Mips/insn-zero-size-bb.ll LLVM :: CodeGen/Mips/jtstat.ll LLVM :: CodeGen/Mips/largeimmprinting.ll LLVM :: CodeGen/Mips/lb1.ll LLVM :: CodeGen/Mips/lbu1.ll LLVM :: CodeGen/Mips/lcb2.ll LLVM :: CodeGen/Mips/lh1.ll LLVM :: CodeGen/Mips/lhu1.ll LLVM :: CodeGen/Mips/llvm-ir/add.ll LLVM :: CodeGen/Mips/llvm-ir/sdiv.ll LLVM :: CodeGen/Mips/llvm-ir/select-dbl.ll LLVM :: CodeGen/Mips/llvm-ir/select-flt.ll LLVM :: CodeGen/Mips/llvm-ir/sqrt.ll LLVM :: CodeGen/Mips/llvm-ir/srem.ll LLVM :: CodeGen/Mips/llvm-ir/udiv.ll LLVM :: CodeGen/Mips/llvm-ir/urem.ll LLVM :: CodeGen/Mips/longbranch.ll LLVM :: CodeGen/Mips/lw16-base-reg.ll LLVM :: CodeGen/Mips/micromips-addiu.ll LLVM :: CodeGen/Mips/micromips-addu16.ll LLVM :: CodeGen/Mips/micromips-and16.ll LLVM :: CodeGen/Mips/micromips-andi.ll LLVM :: CodeGen/Mips/micromips-atomic1.ll LLVM :: CodeGen/Mips/micromips-compact-branches.ll LLVM :: CodeGen/Mips/micromips-delay-slot-jr.ll LLVM :: CodeGen/Mips/micromips-delay-slot.ll LLVM :: CodeGen/Mips/micromips-gp-rc.ll LLVM :: CodeGen/Mips/micromips-jal.ll LLVM :: CodeGen/Mips/micromips-load-effective-address.ll LLVM :: CodeGen/Mips/micromips-not16.ll LLVM :: CodeGen/Mips/micromips-or16.ll LLVM :: CodeGen/Mips/micromips-subu16.ll LLVM :: CodeGen/Mips/micromips-sw-lw-16.ll LLVM :: CodeGen/Mips/micromips-xor16.ll LLVM :: CodeGen/Mips/mips16_fpret.ll LLVM :: CodeGen/Mips/mips16ex.ll LLVM :: CodeGen/Mips/mips16fpe.ll LLVM :: CodeGen/Mips/msa/basic_operations.ll LLVM :: CodeGen/Mips/msa/basic_operations_float.ll LLVM :: CodeGen/Mips/msa/elm_cxcmsa.ll LLVM :: CodeGen/Mips/msa/i10.ll LLVM :: CodeGen/Mips/msa/vecs10.ll LLVM :: CodeGen/Mips/o32_cc.ll LLVM :: CodeGen/Mips/optimize-pic-o0.ll LLVM :: CodeGen/Mips/return_address.ll LLVM :: CodeGen/Mips/select.ll LLVM :: CodeGen/Mips/selgt.ll LLVM :: CodeGen/Mips/tailcall.ll LLVM :: CodeGen/Mips/tnaked.ll This may be latent bugs. -- 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 27459] New: CodeGen/MSP430/vararg.ll fails with the machine verifier ON
https://llvm.org/bugs/show_bug.cgi?id=27459 Bug ID: 27459 Summary: CodeGen/MSP430/vararg.ll fails with the machine verifier ON Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: MSP430 Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Switching the machine verifier ON by default (lib/CodeGen/Passes.cpp then change the default value of the cl::opt related to the machine verifier) leads to CodeGen/MSP430/vararg.ll to fail. This may be a latent bug. -- 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 27460] New: PTX make check has a bunch of machine verifier errors
https://llvm.org/bugs/show_bug.cgi?id=27460 Bug ID: 27460 Summary: PTX make check has a bunch of machine verifier errors Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: PTX Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Switching the machine verifier ON by default (lib/CodeGen/Passes.cpp then change the default value of the cl::opt related to the machine verifier) leads to a bunch of machine verifier errors for make check: LLVM :: CodeGen/NVPTX/MachineSink-call.ll LLVM :: CodeGen/NVPTX/MachineSink-convergent.ll LLVM :: CodeGen/NVPTX/access-non-generic.ll LLVM :: CodeGen/NVPTX/addrspacecast.ll LLVM :: CodeGen/NVPTX/arg-lowering.ll LLVM :: CodeGen/NVPTX/arithmetic-fp-sm20.ll LLVM :: CodeGen/NVPTX/arithmetic-int.ll LLVM :: CodeGen/NVPTX/atomics.ll LLVM :: CodeGen/NVPTX/bfe.ll LLVM :: CodeGen/NVPTX/branch-fold.ll LLVM :: CodeGen/NVPTX/bug17709.ll LLVM :: CodeGen/NVPTX/bug26185.ll LLVM :: CodeGen/NVPTX/call-with-alloca-buffer.ll LLVM :: CodeGen/NVPTX/combine-min-max.ll LLVM :: CodeGen/NVPTX/compare-int.ll LLVM :: CodeGen/NVPTX/convert-fp.ll LLVM :: CodeGen/NVPTX/convert-int-sm20.ll LLVM :: CodeGen/NVPTX/ctlz.ll LLVM :: CodeGen/NVPTX/ctpop.ll LLVM :: CodeGen/NVPTX/cttz.ll LLVM :: CodeGen/NVPTX/disable-opt.ll LLVM :: CodeGen/NVPTX/div-ri.ll LLVM :: CodeGen/NVPTX/envreg.ll LLVM :: CodeGen/NVPTX/fast-math.ll LLVM :: CodeGen/NVPTX/fma-assoc.ll LLVM :: CodeGen/NVPTX/fma-disable.ll LLVM :: CodeGen/NVPTX/fma.ll LLVM :: CodeGen/NVPTX/fp-contract.ll LLVM :: CodeGen/NVPTX/fp-literals.ll LLVM :: CodeGen/NVPTX/i1-int-to-fp.ll LLVM :: CodeGen/NVPTX/i8-param.ll LLVM :: CodeGen/NVPTX/imad.ll LLVM :: CodeGen/NVPTX/implicit-def.ll LLVM :: CodeGen/NVPTX/inline-asm.ll LLVM :: CodeGen/NVPTX/intrinsic-old.ll LLVM :: CodeGen/NVPTX/intrinsics.ll LLVM :: CodeGen/NVPTX/isspacep.ll LLVM :: CodeGen/NVPTX/ld-addrspace.ll LLVM :: CodeGen/NVPTX/ld-generic.ll LLVM :: CodeGen/NVPTX/ldu-i8.ll LLVM :: CodeGen/NVPTX/ldu-ldg.ll LLVM :: CodeGen/NVPTX/ldu-reg-plus-offset.ll LLVM :: CodeGen/NVPTX/load-with-non-coherent-cache.ll LLVM :: CodeGen/NVPTX/local-stack-frame.ll LLVM :: CodeGen/NVPTX/lower-aggr-copies.ll LLVM :: CodeGen/NVPTX/lower-alloca.ll LLVM :: CodeGen/NVPTX/machine-sink.ll LLVM :: CodeGen/NVPTX/misaligned-vector-ldst.ll LLVM :: CodeGen/NVPTX/mulwide.ll LLVM :: CodeGen/NVPTX/pr16278.ll LLVM :: CodeGen/NVPTX/refl1.ll LLVM :: CodeGen/NVPTX/reg-copy.ll LLVM :: CodeGen/NVPTX/rotate.ll LLVM :: CodeGen/NVPTX/rsqrt.ll LLVM :: CodeGen/NVPTX/sext-params.ll LLVM :: CodeGen/NVPTX/simple-call.ll LLVM :: CodeGen/NVPTX/symbol-naming.ll LLVM :: CodeGen/NVPTX/texsurf-queries.ll LLVM :: CodeGen/NVPTX/vec-param-load.ll LLVM :: CodeGen/NVPTX/vector-args.ll LLVM :: CodeGen/NVPTX/vector-call.ll LLVM :: CodeGen/NVPTX/vector-return.ll LLVM :: CodeGen/NVPTX/weak-global.ll This may be latent bugs. -- 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 27461] New: Sparc make check has a few of machine verifier errors
https://llvm.org/bugs/show_bug.cgi?id=27461 Bug ID: 27461 Summary: Sparc make check has a few of machine verifier errors Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: Sparc Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Switching the machine verifier ON by default (lib/CodeGen/Passes.cpp then change the default value of the cl::opt related to the machine verifier) leads to a few of machine verifier errors for make check: LLVM :: CodeGen/SPARC/2011-01-11-CC.ll LLVM :: CodeGen/SPARC/reserved-regs.ll This may be latent bugs. -- 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 27462] New: SROA changes the value name when nothing else has changed
https://llvm.org/bugs/show_bug.cgi?id=27462 Bug ID: 27462 Summary: SROA changes the value name when nothing else has changed 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 I run opt with the attached IR, bugpoint-reduced-simplified.ll, and the flags -basicaa -sroa -S outputting the IR to a file, output1.ll. I then use the output1.ll as input to opt again with the same flags (-basicaa -sroa -S) and redirect the output to output2.ll. The only difference is the value names: $ diff output1.ll output2.ll 1c1 < ; ModuleID = 'bugpoint-reduced-simplified.ll' --- > ; ModuleID = 'output1.ll' 369,370c369,370 < %.0..sroa_cast = bitcast %struct.Vdbe.70.195.1240* %1 to i8* < call void @llvm.lifetime.end(i64 488, i8* %.0..sroa_cast) --- > %.0..0..sroa_cast = bitcast %struct.Vdbe.70.195.1240* %1 to i8* > call void @llvm.lifetime.end(i64 488, i8* %.0..0..sroa_cast) -- 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 27463] New: Privatizing struct fields with array type causes code generation failure.
https://llvm.org/bugs/show_bug.cgi?id=27463
Bug ID: 27463
Summary: Privatizing struct fields with array type causes code
generation failure.
Product: OpenMP
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: sfan...@us.ibm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Repro:
###
struct SS {
int a[2];
int b[2];
int c;
void inc(void) {
#pragma omp parallel firstprivate(a) private(b)
{
c = a[0] + b[0];
}
}
};
int foo(int a){
SS s;
for (int i=0; i<2; ++i) {
s.a[i] = a;
s.b[i] = 2*a;
}
s.c = 0;
s.inc();
return s.c;
}
Trace:
clang-3.9:
/home/sfantao/local/llvm-trunk/src/tools/clang/lib/CodeGen/CGExprAgg.cpp:1430:
void clang::CodeGen::CodeGenFunction::EmitAggExpr(const clang::Expr *,
clang::CodeGen::AggValueSlot): Assertion `E &&
hasAggregateEvaluationKind(E->getType()) && "Invalid aggregate expression to
emit"' failed.
0 clang-3.9 0x118d30e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
+ 120
1 clang-3.9 0x118d3668
2 clang-3.9 0x118d12b4 llvm::sys::RunSignalHandlers() + 132
3 clang-3.9 0x118d3a48
40x3fff9ad40478 __kernel_sigtramp_rt64 + 0
5 libc.so.6 0x3fff9a830a88 gsignal + 72
6 libc.so.6 0x3fff9a83693c abort + 620
7 libc.so.6 0x3fff9a8265b4
8 libc.so.6 0x3fff9a8266a4 __assert_fail + 100
9 clang-3.9 0x11c45be0
clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot) + 800
10 clang-3.9 0x11c13ed0
clang::CodeGen::CodeGenFunction::EmitExprAsInit(clang::Expr const*,
clang::ValueDecl const*, clang::CodeGen::LValue, bool) + 1200
11 clang-3.9 0x11c12608
clang::CodeGen::CodeGenFunction::EmitAutoVarInit(clang::CodeGen::CodeGenFunction::AutoVarEmission
const&) + 984
12 clang-3.9 0x11c0e834
clang::CodeGen::CodeGenFunction::EmitVarDecl(clang::VarDecl const&) + 436
13 clang-3.9 0x11c0e540
clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 448
14 clang-3.9 0x11ac4dcc
15 clang-3.9 0x11aacce8
16 clang-3.9 0x11aad72c
clang::CodeGen::CodeGenFunction::EmitOMPFirstprivateClause(clang::OMPExecutableDirective
const&, clang::CodeGen::CodeGenFunction::OMPPrivateScope&) + 1788
17 clang-3.9 0x11ac9d2c
18 clang-3.9 0x11ce94ec
19 clang-3.9 0x11aab85c
clang::CodeGen::CodeGenFunction::GenerateOpenMPCapturedStmtFunction(clang::CapturedStmt
const&) + 4604
20 clang-3.9 0x11cd2cc8
clang::CodeGen::CGOpenMPRuntime::emitParallelOrTeamsOutlinedFunction(clang::OMPExecutableDirective
const&, clang::VarDecl const*, clang::OpenMPDirectiveKind,
clang::CodeGen::RegionCodeGenTy const&) + 472
21 clang-3.9 0x11ab1e54
22 clang-3.9 0x11ab1cd0
clang::CodeGen::CodeGenFunction::EmitOMPParallelDirective(clang::OMPParallelDirective
const&) + 96
23 clang-3.9 0x11a97c04
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1428
24 clang-3.9 0x11aa1b8c
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) + 204
25 clang-3.9 0x11ad8880
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 1872
26 clang-3.9 0x11af1d54
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 564
27 clang-3.9 0x11aec2fc
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 508
28 clang-3.9 0x11ae5090 clang::CodeGen::CodeGenModule::EmitDeferred() +
320
29 clang-3.9 0x11ae46b0 clang::CodeGen::CodeGenModule::Release() + 64
30 clang-3.9 0x121da518
31 clang-3.9 0x121d8d84
32 clang-3.9 0x1264b098 clang::ParseAST(clang::Sema&, bool, bool) + 824
33 clang-3.9 0x11e392c8 clang::ASTFrontendAction::ExecuteAction() + 232
34 clang-3.9 0x121d75f8 clang::CodeGenAction::ExecuteAction() + 328
35 clang-3.9 0x11e38a18 clang::FrontendAction::Execute() + 152
36 clang-3.9 0x11df9378
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1688
37 clang-3.9 0x11ede710
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 4752
38 clang-3.9 0x103a1c50 cc1_main(llvm::ArrayRef, char
const*, void*) + 1664
39 clang-3.9 0x1039fd64 main + 13956
40 libc.so.6 0x3fff9a814d00
41 libc.so.6 0x3fff9a814ef8 __libc_start_main + 200
--
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
[llvm-bugs] [Bug 27464] New: clang doesn't unescape \(\) in response correctly
https://llvm.org/bugs/show_bug.cgi?id=27464
Bug ID: 27464
Summary: clang doesn't unescape \(\) in response correctly
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat test.c
void bar() {}
void f() { FOO; }
$ cat foo.rsp
-DFOO=bar\(\)
$ gcc -c test.c @foo.rsp # works
@ clang -c test.c @foo.rsp
test.c:3:3: error: expected ';' after expression
FOO;
^
:1:16: note: expanded from here
#define FOO bar\(\)
rsp files (on posix) should be unescaped like shell, and `echo bar\(\)` prints
"bar()" 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 27466] New: test/DebugInfo/PDB/Inputs/empty.pdb broken on some bots
https://llvm.org/bugs/show_bug.cgi?id=27466 Bug ID: 27466 Summary: test/DebugInfo/PDB/Inputs/empty.pdb broken on some bots Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3883/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Apdbdump-headers.test TEST 'LLVM :: DebugInfo/PDB/pdbdump-headers.test' FAILED Script: -- llvm-pdbdump --dump-headers /home/buildbots/ppc64be-clang-test/clang-ppc64be/llvm/test/DebugInfo/PDB/Inputs/empty.pdb | /home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/./bin/FileCheck /home/buildbots/ppc64be-clang-test/clang-ppc64be/llvm/test/DebugInfo/PDB/pdbdump-headers.test -- Exit Code: 2 Command Output (stderr): -- FileCheck error: '-' is empty. Maybe the test needs some REQUIRES line? -- 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 27393] libClang Cannot Locate Header Files Of User Made Libraries And Projects
https://llvm.org/bugs/show_bug.cgi?id=27393 Nkosi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Nkosi --- Okay, this is not a bug, but a mistake on my part. I figured that would be the case. There are two things I learned: 1. Clang either includes the standard C++ library automatically, or it includes the standard C++ library included with Visual Studio automatically. In any case, removing all the includes for the various C++ library and Windows API header file locations did not change anything. 2. The actual issue. I just realized Clang expects each command line argument identifier to be concatenated, WITH NO EXTRA SPACE, to the actual command line argument. In other words "-I D:\Libraries\ConsoleMenu\include" <- WRONG "-ID:\Libraries\ConsoleMenu\include" <- RIGHT I set the status to resolved and invalid, since this was a mistake on my part. If Invalid is the wrong status, just change it to whatever it needs to be. -- 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 27467] New: BasicAA says "PartialAlias" for access to two different record fields
https://llvm.org/bugs/show_bug.cgi?id=27467
Bug ID: 27467
Summary: BasicAA says "PartialAlias" for access to two
different record fields
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Analyses
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Running
opt -S -lint ./alias.ll
gives
Unusual: noalias argument aliases another argument
on the (silly) function:
%rec7 = type { i16, i16, i16 }
define void @fn1(i16* noalias %p1.1.par, i16* noalias %p2.2.par) {
%s.3 = alloca %rec7
%_tmp1 = getelementptr %rec7, %rec7* %s.3, i16 0, i32 1
%_tmp2 = getelementptr %rec7, %rec7* %s.3, i16 0, i32 2
call void @fn1(i16* %_tmp1, i16* %_tmp2)
ret void
}
If accessing fields 0 and 1 instead, with
%_tmp1 = getelementptr %rec7, %rec7* %s.3, i16 0, i32 0
%_tmp2 = getelementptr %rec7, %rec7* %s.3, i16 0, i32 1
we don't see the Lint complaint.
--
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
