[llvm-bugs] [Bug 42193] New: hasName AST matcher is confused by extern "C" in namespace
https://bugs.llvm.org/show_bug.cgi?id=42193
Bug ID: 42193
Summary: hasName AST matcher is confused by extern "C" in
namespace
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: kpreis...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Given the following code:
namespace foo {
extern "C" void test() {}
}
... I expect an AST matcher declared as functionDecl(hasName("::foo::test")) to
match the function, but functionDecl(hasName("::test")) should not match.
However, the opposite is the case. (see the example on Compiler Explorer:
http://ce.steveire.com/z/VDTi_g)
When I do this locally with a build with assertions, I get an assertion failure
at
https://github.com/llvm/llvm-project/blob/bca56ab073a00cdec8e0995e3119baf25cf775b8/clang/lib/ASTMatchers/ASTMatchersInternal.cpp#L540,
so I think the problem is that matchesNodeFullFast does not correctly handle
extern "C" functions.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #64 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c64 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-60d38924-21c8-467e-889c-298d21374ff8.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42194] New: "Write Bitcode" pass crashes with "opt -inline -licm -strip-dead-prototypes -early-cse -jump-threading -loop-extract-single": Assertion `I != ValueMap.end() && "Value not
https://bugs.llvm.org/show_bug.cgi?id=42194
Bug ID: 42194
Summary: "Write Bitcode" pass crashes with "opt -inline -licm
-strip-dead-prototypes -early-cse -jump-threading
-loop-extract-single": Assertion `I != ValueMap.end()
&& "Value not in slotcalculator!"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Bitcode Writer
Assignee: unassignedb...@nondot.org
Reporter: csz...@163.com
CC: llvm-bugs@lists.llvm.org
Created attachment 22081
--> https://bugs.llvm.org/attachment.cgi?id=22081=edit
.bc file of the source code
$clang -v
clang version 9.0.0 (trunk 362492)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.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.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$clang -O3 -c -emit-llvm -mllvm -disable-llvm-optzns small.c
$opt -inline -licm -strip-dead-prototypes -early-cse -jump-threading
-loop-extract-single small.bc -o small-opt.bc
opt:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/lib/Bitcode/Writer/ValueEnumerator.cpp:462:
unsigned int llvm::ValueEnumerator::getValueID(const llvm::Value*) const:
Assertion `I != ValueMap.end() && "Value not in slotcalculator!"' failed.
Stack dump:
0. Program arguments:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt -inline -licm
-strip-dead-prototypes -early-cse -jump-threading -loop-extract-single small.bc
-o small-opt.bc
1. Running pass 'Bitcode Writer' on module 'small.bc'.
#0 0x55a9a8580cea llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x255bcea)
#1 0x55a9a857e9a4 llvm::sys::RunSignalHandlers()
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x25599a4)
#2 0x55a9a857eae2 SignalHandler(int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x2559ae2)
#3 0x7f80fd9d2890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x7f80fc684e97 raise
/build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7f80fc686801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
#6 0x7f80fc67639a __assert_fail_base
/build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
#7 0x7f80fc676412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
#8 0x55a9a7a63c83 llvm::ValueEnumerator::getValueID(llvm::Value const*)
const (/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x1a3ec83)
#9 0x55a9a7a48be0 (anonymous
namespace)::ModuleBitcodeWriter::writeInstruction(llvm::Instruction const&,
unsigned int, llvm::SmallVectorImpl&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x1a23be0)
#10 0x55a9a7a5e75d llvm::BitcodeWriter::writeModule(llvm::Module const&,
bool, llvm::ModuleSummaryIndex const*, bool, std::array*)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x1a3975d)
#11 0x55a9a7a5fc6f llvm::WriteBitcodeToFile(llvm::Module const&,
llvm::raw_ostream&, bool, llvm::ModuleSummaryIndex const*, bool,
std::array*)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x1a3ac6f)
#12 0x55a9a7a3e7da (anonymous
namespace)::WriteBitcodePass::runOnModule(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x1a197da)
#13 0x55a9a7f3d1c1 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x1f181c1)
#14 0x55a9a6837889 main
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x812889)
#15 0x7f80fc667b97 __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0
#16 0x55a9a68bbaba _start
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build/bin/opt+0x896aba)
Aborted (core dumped)
struct c {
signed d;
} e, *g;
int f, h;
volatile struct c i;
int j();
int k(int, int, int *, struct c *, struct c *);
struct c *l() {
for (;;) {
signed char m = 5;
j();
}
}
int j() {
int p = 1;
for (;;)
k(p, e.d, , l(), g);
}
int k( int q, int r, int *s, struct c *a, struct c *b) {
for
[llvm-bugs] [Bug 42196] New: -Wunused-member-function default move
https://bugs.llvm.org/show_bug.cgi?id=42196
Bug ID: 42196
Summary: -Wunused-member-function default move
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: m-l...@bodyfour.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Note this is similar to #25084, but I believe it is distinct, since it involves
-Wunused-member-function instead of -Wunneeded-member-function
Take this code for example:
namespace {
class F {
public:
explicit F(int x) : x_(x)
{
}
F(const F&) = default;
F& operator=(const F&) = default;
F(F&&) = default;
F& operator=(F&&) = default;
int get() const { return x_; }
private:
int x_;
};
}
int main(void)
{
F f(123);
return f.get();
}
Compiling it reveals these warnings:
$ bin/clang --std=c++11 -fsyntax-only -Wunused-member-function
rvalue-moveop-unused.cpp
rvalue-moveop-unused.cpp:10:2: warning: unused member function 'F'
[-Wunused-member-function]
F(F&&) = default;
^
rvalue-moveop-unused.cpp:11:5: warning: unused member function 'operator='
[-Wunused-member-function]
F& operator=(F&&) = default;
^
So it complains about the "=default" move operator/ctor being unused.
Interestingly, it does not do the same for the "=default" *copy* operator/ctor
even though it's just as unused.
Ultimately this warning isn't very useful, since it's complaining about a
function that isn't actually defined but just indicates that the same copy/move
that the class gets by default can be used.
This is especially annoying when these annotations are added via compiler
macros, since it means you get warnings whenever a class is put into the
anonymous namespace.
I'm far from an expert on clang internals, but I can see that the warning is
generated by lib/Sema/Sema.cpp which does:
if (!Diags.hasErrorOccurred() && TUKind != TU_Module) {
[...]
if (const FunctionDecl *FD = dyn_cast(*I)) {
const FunctionDecl *DiagD;
if (!FD->hasBody(DiagD))
DiagD = FD;
if (DiagD->isDeleted())
continue; // Deleted functions are supposed to be unused.
So maybe it should also include ->isDeleted() there? Or maybe ->isTrivial()
too? But it's not clear to me why this affects move-ctor and not copy-ctor.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42197] New: Canonicalize OR with operands which do not have shared bits to ADD
https://bugs.llvm.org/show_bug.cgi?id=42197
Bug ID: 42197
Summary: Canonicalize OR with operands which do not have shared
bits to ADD
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
typedef unsigned char byte;
byte add_no_common_bits(byte x, byte y) {
// hint, no common bits
__builtin_assume((x & y) == 0);
return x | y;
}
byte or_no_common_bits(byte x, byte y) {
// hint, no common bits
__builtin_assume((x & y) == 0);
return x + y;
}
add_no_common_bits(unsigned char, unsigned char):
mov eax, edi
or eax, esi
ret
or_no_common_bits(unsigned char, unsigned char):
lea eax, [rsi + rdi]
ret
If we can prove that there are no shared bits between X and Y, maybe we could
turn OR to ADD.
Or ADD to OR.. not sure which form is better.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42195] New: roundf lowering under fast math
https://bugs.llvm.org/show_bug.cgi?id=42195
Bug ID: 42195
Summary: roundf lowering under fast math
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
-Ofast -mfma -march=skylake
float rf(float B) {
return roundf(B);
}
Clang:
rf(float):
jmp roundf
GCC generates:
rf(float):
vmovaps xmm1, xmm0
vandps xmm0, xmm0, XMMWORD PTR .LC1[rip]
vorps xmm0, xmm0, XMMWORD PTR .LC0[rip]
vaddss xmm0, xmm0, xmm1
vroundssxmm0, xmm0, xmm0, 3
ret
ICC:
rf(float):
vxorpsxmm1, xmm1, xmm1 #7.12
vmovssxmm3, xmm1, xmm0 #7.12
vandpsxmm4, xmm3, XMMWORD PTR .L_2il0floatpacket.0[rip] #7.12
vcmpeqps xmm2, xmm4, XMMWORD PTR .L_2il0floatpacket.1[rip] #7.12
vroundps xmm9, xmm4, 0 #7.12
vxorpsxmm11, xmm3, xmm4 #7.12
vblendvps xmm5, xmm9, XMMWORD PTR .L_2il0floatpacket.2[rip], xmm2 #7.12
vsubpsxmm6, xmm4, xmm5 #7.12
vcmpeqps xmm7, xmm6, XMMWORD PTR .L_2il0floatpacket.3[rip] #7.12
vandpsxmm8, xmm7, XMMWORD PTR .L_2il0floatpacket.4[rip] #7.12
vaddpsxmm10, xmm8, xmm9 #7.12
vxorpsxmm0, xmm10, xmm11#7.12
ret
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42121] lld doesn't seem to work with g++ on MinGW
https://bugs.llvm.org/show_bug.cgi?id=42121 Martin Storsjö changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Storsjö --- The -u option was implemented in SVN r362882. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42200] New: -emit-llvm accepts wrong code
https://bugs.llvm.org/show_bug.cgi?id=42200
Bug ID: 42200
Summary: -emit-llvm accepts wrong code
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
My clang is 9.0.0, and my code is:
int pixels;
void test() {
asm volatile("%0 %1" : "+r" (pixels) : : "%eax");
}
With other parameters, clang rejects the code:
source>:3:15: error: unexpected token at start of statement
asm volatile("%0 %1" : "+r" (pixels) : : "%eax");
^
:1:2: note: instantiated into assembly here
%ecx %ecx
^
1 error generated.
Compiler returned: 1
However, with -emit-llvm, it accepts the code. It seems to be incorrect?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 14117] Mangler closing scope too many times?
https://bugs.llvm.org/show_bug.cgi?id=14117 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #2 from Richard Smith --- This is a GCC bug, per the Itanium ABI spec. See: http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.unresolved-name ::= sr ::= [gs] sr + E ::= [ ] ::= ::= ::= ::= [ ] Here, 13IsConvertible is an , not an , so an E must be inserted after the qualifiers even if there's only one of them. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42203] New: clang accepts invalid code
https://bugs.llvm.org/show_bug.cgi?id=42203
Bug ID: 42203
Summary: clang accepts invalid code
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
My clang is 9.0.0, and the code is:
enum class A : unsigned long long {
z = (unsigned long long)-1
};
const A c{ A::z };
template struct Q {};
Q j;
clang accepts the code. ICC rejects it:
(5): error: an opaque enum declaration cannot be part of another
declaration
template struct Q {};
^
(6): error: argument of type "A" is incompatible with template
parameter of type "A"
Q j;
^
compilation aborted for (code 2)
Compiler returned: 2
gcc also rejects it:
:5:39: error: expected ';' or '{' before '>' token
5 | template struct Q {};
| ^
:5:39: error: expected class-key before '>' token
:6:4: note: invalid template non-type parameter
6 | Q j;
|^
Compiler returned: 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42201] New: clang accept wrong code after with -Ox
https://bugs.llvm.org/show_bug.cgi?id=42201
Bug ID: 42201
Summary: clang accept wrong code after with -Ox
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
My clang is 9.0.0, and my code is:
int main(void) {
int value;
__asm__("test" : "=l" (value));
}
clang rejects the code:
source>:3:10: error: unknown use of instruction mnemonic without a size suffix
__asm__("test" : "=l" (value));
^
:1:2: note: instantiated into assembly here
test
^
1 error generated.
Compiler returned: 1
However, it accepts the code, with the following parameters:
clang++ -O3 | clang++ -O2 | clang++ -O1
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42202] New: [mca] modelling decoder unit throttling
https://bugs.llvm.org/show_bug.cgi?id=42202 Bug ID: 42202 Summary: [mca] modelling decoder unit throttling Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-mca Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org, matthew.da...@sony.com This is two-fold issue: * Instructions that generate two macro-ops are called double instructions. The decoders in the Piledriver, Steamroller, and Excavator can handle four single instructions (1-1-1-1) or one double instruction and two single (2-1-1) or two double instructions (2-2) in one clock cycle. The Bulldozer can handle (1-1-1-1) and (2-1-1), but not (2-2). I.e. e.g. this is incorrect: https://godbolt.org/z/pT2Tgz * Instructions that generate more than two macro-ops are using microcode. The decoders cannot do anything else while microcode is generated. This means that a decoder can stop decoding for several clock cycles after meeting an instruction that generates more than two macro-ops. Interestingly, this seems to be already handled? https://godbolt.org/z/HUJH1R -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42192] Mangler incorrectly handles templated decltype in parameter type
https://bugs.llvm.org/show_bug.cgi?id=42192 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Smith --- *** This bug has been marked as a duplicate of bug 14117 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42197] Canonicalize OR with operands which do not have shared bits to ADD
https://bugs.llvm.org/show_bug.cgi?id=42197 David Bolvansky changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42198] New: incorrect instcombine fold for icmp sgt
https://bugs.llvm.org/show_bug.cgi?id=42198
Bug ID: 42198
Summary: incorrect instcombine fold for icmp sgt
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: nunoplo...@sapo.pt
CC: lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
reg...@cs.utah.edu
The following instcombine rewrite seems incorrect
(test/Transforms/InstCombine/canonicalize-constant-low-bit-mask-and-icmp-sgt-to-icmp-sgt.ll):
define i1 @cv0_GOOD(i8 %y) {
%0:
%x = call i8 @gen8()
%tmp0 = lshr i8 255, %y
%tmp1 = and i8 %tmp0, %x
%ret = icmp sgt i8 %x, %tmp1
ret i1 %ret
}
=>
define i1 @cv0_GOOD(i8 %y) {
%0:
%x = call i8 @gen8()
%tmp0 = lshr i8 255, %y
%1 = icmp sgt i8 %x, %tmp0
ret i1 %1
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
i8 %y = #x00 (0)
Source:
i8 %x = #x7f (127, -129)
i8 %tmp0 = #xff (255, -1)
i8 %tmp1 = #x7f (127, -129)
i1 %ret = #x0 (0)
Target:
i8 %x = #x7f (127, -129)
i8 %tmp0 = #xff (255, -1)
i1 %1 = #x1 (1)
Source value: #x0 (0)
Target value: #x1 (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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12375 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-indvars: Timeout in llvm_llvm-opt-fuzzer--x86_64-indvars
Updates: Status: WontFix Comment #6 on issue 12375 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-indvars: Timeout in llvm_llvm-opt-fuzzer--x86_64-indvars https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12375#c6 ClusterFuzz testcase 5706064570351616 is flaky and no longer crashes, so closing issue. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42199] New: Wrong implementation for regex_constants in clang
https://bugs.llvm.org/show_bug.cgi?id=42199
Bug ID: 42199
Summary: Wrong implementation for regex_constants in clang
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: youkaic...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following code:
```
#include
#include
using namespace std;
int main()
{
regex re0("^cd");
string str = "cd";
cout << regex_search(str, re0, regex_constants::match_prev_avail) <<
endl;
cout << regex_search(str, re0) << endl;
}
```
gives the output:
```
1
1
```
But as specified in the c++ standard, the output should be:
```
0
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15183 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-06-09 Type: Bug New issue 15183 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15183 Detailed report: https://oss-fuzz.com/testcase?key=5709498641022976 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe695aab48 Crash State: ConvertDeclSpecToType GetDeclSpecTypeForDeclarator clang::Sema::GetTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201906070207:201906080206 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5709498641022976 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
