[llvm-bugs] [Bug 30616] New: clang: clang/AST/Expr.h: Assertion `Arg < NumArgs && "Arg access out of range!"' failed.

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30616

Bug ID: 30616
   Summary: clang: clang/AST/Expr.h: Assertion `Arg < NumArgs &&
"Arg access out of range!"' failed.
   Product: clang
   Version: 3.9
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Static Analyzer
  Assignee: kreme...@apple.com
  Reporter: mar...@oberhumer.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The following simple C program triggers an assertion with scan-build-3.9:


char alloca();
int main(int ac, char *av[]) {
alloca();
if (ac > 1000) {
return *av[0];
}
return 0;
}


Assertion failed:

clang-3.9:
/home/hosts/cc-i386-linux/build/llvm/llvm-3.9-git/src/llvm/tools/clang/include/clang/AST/Expr.h::
const clang::Expr *clang::CallExpr::getArg(unsigned int) const: Assertion `Arg
< NumArgs && "Arg access out of range!"' failed.

Command line:

0.  Program arguments:
/opt/cc-i386-linux/llvm/llvm-3.9/clang-3.9.0-20160902-pristine/bin/clang-3.9
-cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name
scan_build_crash.c -analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=unix
-analyzer-checker=deadcode
-analyzer-checker=security.insecureAPI.UncheckedReturn
-analyzer-checker=security.insecureAPI.getpw
-analyzer-checker=security.insecureAPI.gets
-analyzer-checker=security.insecureAPI.mktemp
-analyzer-checker=security.insecureAPI.mkstemp
-analyzer-checker=security.insecureAPI.vfork
-analyzer-checker=nullability.NullPassedToNonnull
-analyzer-checker=nullability.NullReturnedFromNonnull -analyzer-output plist -w
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -resource-dir
/opt/cc-i386-linux/llvm/llvm-3.9/clang-3.9.0-20160902-pristine/bin/../lib/clang/3.9.0
-internal-isystem /usr/local/include -internal-isystem
/opt/cc-i386-linux/llvm/llvm-3.9/clang-3.9.0-20160902-pristine/bin/../lib/clang/3.9.0/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /home/mfx/pp/bugs/llvm-bugs/scan-build-crash
-ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc
-fdiagnostics-show-option -analyzer-display-progress -analyzer-output=html -o
/tmp/scan-build-2016-10-05-103146-24994-1 -x c scan_build_crash.c 


Stack trace:

[...]
#5 0x2b2a9bf9b227 __assert_fail_base (/lib64/libc.so.6+0x2d227)
#6 0x2b2a9bf9b2d2 (/lib64/libc.so.6+0x2d2d2)
#7 0x01308a6a void
clang::ento::check::PostStmt::_checkStmt<(anonymous
namespace)::MallocChecker>(void*, clang::Stmt const*,
clang::ento::CheckerContext&)
(/opt/cc-i386-linux/llvm/llvm-3.9/clang-3.9.0-20160902-pristine/bin/clang-3.9+0x1308a6a)
#8 0x013d8528 clang::ento::CheckerManager::runCheckersForStmt(bool,
clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNodeSet const&, clang::Stmt
const*, clang::ento::ExprEngine&, bool)
(/opt/cc-i386-linux/llvm/llvm-3.9/clang-3.9.0-20160902-pristine/bin/clang-3.9+0x13d8528)
#9 0x0140afa4 clang::ento::ExprEngine::VisitCallExpr(clang::CallExpr
const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
(/opt/cc-i386-linux/llvm/llvm-3.9/clang-3.9.0-20160902-pristine/bin/clang-3.9+0x140afa4
[...]

-- 
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 30617] New: 3.9 performance regression in sudoku solver [ARM/AARCH64]

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30617

Bug ID: 30617
   Summary: 3.9 performance regression in sudoku solver
[ARM/AARCH64]
   Product: libraries
   Version: 3.9
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: ARM
  Assignee: unassignedb...@nondot.org
  Reporter: tulip...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17403
  --> https://llvm.org/bugs/attachment.cgi?id=17403&action=edit
benchmark source files

Just a heads-up, e.g. on ARM the rust benchmark takes:

$ ./sudoku > /dev/null

llvm 3.8: 1.35s
llvm 3.9: 1.62s

Should reproduce in clang, both C and Rust sources attached.

-- 
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 30449] Segfault when move-assigning a std::map with an aligned Key

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30449

arpha...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||arpha...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from arpha...@gmail.com ---
After investigating, I found that this issue was caused by the undefined
behaviour in libc++, which was fixed in r276003
(http://llvm.org/viewvc/llvm-project?view=revision&revision=276003). I'm
closing this issue because it no longer reproduces since the aforementioned
commit fixed 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 30618] New: Compile boost::has_nothrow_constructor have Segmentation fault (core dump)

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30618

Bug ID: 30618
   Summary: Compile boost::has_nothrow_constructor have
Segmentation fault (core dump)
   Product: clang
   Version: 3.9
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: C++11
  Assignee: unassignedclangb...@nondot.org
  Reporter: volodymyrsur...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17404
  --> https://llvm.org/bugs/attachment.cgi?id=17404&action=edit
original and preprocess file

OS: Linux Mint, Mac OS
Compiler: pre build binaries clang 3.9.0

Hi, I find problem with compiling code in our project. I reproduce this problem
separately (in attach main.cpp). After that i get preprocess file and using
delta cut part unused code (main-min4.cpp).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30619] New: segfault in ConvertTypeToDiagnosticString when compiling

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30619

Bug ID: 30619
   Summary: segfault in ConvertTypeToDiagnosticString when
compiling
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: dkee...@mozilla.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17405
  --> https://llvm.org/bugs/attachment.cgi?id=17405&action=edit
testcase-7d508f.cpp

Compiling the attached testcase (with -ferror-limit set to something large)
crashes clang.

-- 
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 30378] ARM/Windows calls to unavailable function __moddi3

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30378

Martin Storsjö  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Storsjö  ---
Fixed in SVN r283383.

-- 
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 22845] [C++14] new expression should cause compilation error if expression in a noptr-new-declarator is erroneous

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=22845

Richard Smith  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||richard-l...@metafoo.co.uk
 Resolution|--- |FIXED

--- Comment #1 from Richard Smith  ---
Fixed in r283406.

-- 
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 28276] Unittest DebugInfoPDBTests is not built

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=28276

Reid Kleckner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Reid Kleckner  ---
Assuming this is 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

[llvm-bugs] [Bug 22924] support braced-init-list of exact size + array new with no default ctor as an extension

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=22924

Richard Smith  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Richard Smith  ---
As of r283406, we now choose to treat this as a defect in the standard, and no
longer require default-constructibility for the array element type in a
fixed-size array new if all elements have an explicit initializer.


(In reply to comment #9)
> Attached is patch to solve this issue.

Thank you, but please send patches to cfe-commits in future. Patches attached
to bugzilla are likely not to be seen by anyone in a timely fashion.

-- 
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 30613] std::type_info::hash_code violates strict aliasing

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30613

Eric Fiselier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|All Bugs|All Bugs
 Resolution|--- |FIXED
   Assignee|mclow.li...@gmail.com   |unassignedclangbugs@nondot.
   ||org
Product|libc++abi   |libc++

--- Comment #4 from Eric Fiselier  ---
Fixed in r283408.

-- 
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 30620] New: clang emits code for constructors that causes debuggers to behave unexpectedly

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30620

Bug ID: 30620
   Summary: clang emits code for constructors that causes
debuggers to behave unexpectedly
   Product: clang
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: edmu...@microsoft.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

This is reported by jacda...@microsoft.com (he's waiting for his account on
lldvm.org/bugs to be created):

clang emits a wrapper constructor whose purpose is to invoke child
constructors, copy constructors, and ultimately, the real constructor of a
class.
This wrapper constructor is mapped to the same source code as the real
constructor and is not marked with a trampoline symbol (which would tell the
debugger to continue stepping through that code) or the target no-stmt flag in
the line info.

Unfortunately, this means that both gdb and lldb (when debugging this clang
compiled binary) stop in the wrapper constructor rather than the targets.  Now,
when a bp is set in the source of the real constructor, the debugger will stop
when that bp is hit. The logical callstack (not displayed in the window) then
looks like this:



real_ctor

wrapper_ctor

main



Stepping off the end of the real constructor stops in the wrapper constructor.


Interesting symbols:

wrapper constructor disassem

a.out`CSquid::CSquid:
0x10f60 <+0>:  pushq  %rbp
0x10f61 <+1>:  movq   %rsp, %rbp
0x10f64 <+4>:  subq   $0x10, %rsp
0x10f68 <+8>:  movq   %rdi, -0x8(%rbp)
0x10f6c <+12>: movq   -0x8(%rbp), %rdi
0x10f70 <+16>: callq  0x10fa0   ; call to real
constructor CSquid::CSquid at constructorbug.cpp:8
0x10f79 <+25>: popq   %rbp
0x10f7a <+26>: retq
0x10f7b <+27>: nopl   (%rax,%rax)



real constructor disassem:

.out`CSquid::CSquid:
0x10fa0 <+0>:  pushq  %rbp
0x10fa1 <+1>:  movq   %rsp, %rbp
0x10fa4 <+4>:  movq   %rdi, -0x8(%rbp)
0x10fa8 <+8>:  movq   -0x8(%rbp), %rdi
0x10fb2 <+18>: popq   %rbp
0x10fb3 <+19>: req

Wrapper constructor subprogram symbol:

0x00b8: TAG_subprogram [11] *
 AT_low_pc( 0x00010f60 )
 AT_high_pc( 0x00010f7b )
 AT_frame_base( rbp )
 AT_object_pointer( {0x00db} )
 AT_MIPS_linkage_name( "_ZN6CSquidC1Ev" )
 AT_specification( {0x0044}"CSquid" )

0x00db: TAG_formal_parameter [12]  
 AT_location( fbreg -8 )
 AT_name( "this" )
 AT_type( {0x0165} ( CSquid* ) )
 AT_artificial( 0x01 )


0x00ec: NULL

Real constructor subprogram symbol:

0x0130: TAG_subprogram [11] *
 AT_low_pc( 0x00010fa0 )
 AT_high_pc( 0x00010fb4 )
 AT_frame_base( rbp )
 AT_object_pointer( {0x0153} )
 AT_MIPS_linkage_name( "_ZN6CSquidC2Ev" )
 AT_specification( {0x0044}"CSquid" )


0x0153: TAG_formal_parameter [12]  
 AT_location( fbreg -8 )
 AT_name( "this" )
 AT_type( {0x0165} ( CSquid* ) )
 AT_artificial( 0x01 )

0x0164: NULL

Line table for both:

0x004f: DW_LNE_set_address( 0x00010f60 )
0x005a: address += 0,  line += 7
0x00010f60  1  8  0 is_stmt

0x005b: DW_LNS_set_column( 5 )
0x005d: DW_LNS_set_prologue_end

0x005e: address += 10,  line += 0
0x00010f70  1  8  5 is_stmt prologue_end

0x005f: address += 5,  line += 2
0x00010f75  1 10  5 is_stmt

0x0060: DW_LNS_advance_pc( 6 )
0x0062: DW_LNE_end_sequence
0x00010f7b  1 10  5 is_stmt

0x0082: DW_LNE_set_address( 0x00010fa0 )
0x008d: address += 0,  line += 7
0x00010fa0  1  8  0 is_stmt

0x008e: DW_LNS_set_column( 13 )
0x0090: DW_LNS_set_prologue_end
0x0091: address += c,  line += 1
0x00010fac  1  9 13 is_stmt prologue_end

0x0092: DW_LNS_set_column( 5 )
0x0094: address += 6,  line += 1
0x00010fb2  1 10  5 is_stmt

0x0095: DW_LNS_advance_pc( 2 )
0x0097: DW_LNE_end_sequence
0x00010fb4  1 10  5 is_stmt

-- 
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.l

[llvm-bugs] [Bug 30404] bubble sort flakiness

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30404

Chandler Carruth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||chandl...@gmail.com
 Resolution|--- |INVALID

--- Comment #6 from Chandler Carruth  ---
This bug has fragmented the discussion from a patch review. Please don't do
that. I will continue to make comments in the code review thread.

Either way, there is not a bug here, so closing.

-- 
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 30621] New: Code generation for __atomic_and_fetch() contains duplicates

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30621

Bug ID: 30621
   Summary: Code generation for __atomic_and_fetch() contains
duplicates
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: yunzhong_...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

I was testing with trunk r283366.

Here is the test program (atomic.c)
short test(short *ptr, short val, int model) {
  return __atomic_and_fetch(ptr, val, model);
}

=
Here is the code generated by GCC 4.8.4
test:
movzwl(%rdi), %eax
movzwl%si, %esi
.L2:
movl%eax, %edx
andl%esi, %edx
lock cmpxchgw%dx, (%rdi)
jne.L2
movl  %edx, %eax
ret

=
Here is the code generated by clang:
test:   # @test
decl%edx
cmpl$4, %edx
ja.LBB0_2
jmpq*.LJTI0_0(,%rdx,8)
.LBB0_4:# %acquire
movw(%rdi), %ax
.p2align4, 0x90
.LBB0_5:# %atomicrmw.start6
# =>This Inner Loop Header: Depth=1
movl%eax, %ecx
andl%esi, %ecx
# kill: %AX %AX %EAX
lockcmpxchgw%cx, (%rdi)
# kill: %AX %AX %EAX
jne.LBB0_5
jmp.LBB0_12
.LBB0_2:# %monotonic
movw(%rdi), %ax
.p2align4, 0x90
.LBB0_3:# %atomicrmw.start
# =>This Inner Loop Header: Depth=1
movl%eax, %ecx
andl%esi, %ecx
# kill: %AX %AX %EAX
lockcmpxchgw%cx, (%rdi)
# kill: %AX %AX %EAX
jne.LBB0_3
jmp.LBB0_12
.LBB0_6:# %release
movw(%rdi), %ax
.p2align4, 0x90
.LBB0_7:# %atomicrmw.start12
# =>This Inner Loop Header: Depth=1
movl%eax, %ecx
andl%esi, %ecx
# kill: %AX %AX %EAX
lockcmpxchgw%cx, (%rdi)
# kill: %AX %AX %EAX
jne.LBB0_7
jmp.LBB0_12
.LBB0_8:# %acqrel
movw(%rdi), %ax
.p2align4, 0x90
.LBB0_9:# %atomicrmw.start18
# =>This Inner Loop Header: Depth=1
movl%eax, %ecx
andl%esi, %ecx
# kill: %AX %AX %EAX
lockcmpxchgw%cx, (%rdi)
# kill: %AX %AX %EAX
jne.LBB0_9
jmp.LBB0_12
.LBB0_10:   # %seqcst
movw(%rdi), %ax
.p2align4, 0x90
.LBB0_11:   # %atomicrmw.start24
# =>This Inner Loop Header: Depth=1
movl%eax, %ecx
andl%esi, %ecx
# kill: %AX %AX %EAX
lockcmpxchgw%cx, (%rdi)
# kill: %AX %AX %EAX
jne.LBB0_11
.LBB0_12:   # %atomic.continue
andl%esi, %eax
retq


It looks to me that many of these loop bodies are identical and can
be merged? For example, the .LBB0_5 block, the .LBB0_3 block, the
.LBB0_7 block, the .LBB0_9 block and the .LBB0_11 block.

Using a size optimization switch like -Os or -Oz does not seem to help.

-- 
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 30622] New: wrong code at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

2016-10-05 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30622

Bug ID: 30622
   Summary: wrong code at -Os and above in both 32-bit and 64-bit
modes on x86_64-linux-gnu
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: chengnian...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

$ clang-trunk -v
clang version 4.0.0 (trunk 28)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.0
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.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
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$ clang-trunk -Os small.c ; ./a.out
-3
$ clang-trunk -O1 small.c ; ./a.out
3
$ cat small.c
static int a = -3L, h;
int *b = &a;
int c[3];
char d, e;
char *g = &d;
int **i = &b;
void fn1() {
  int *f = &c[2];
  for (;;) {
if (e)
  f = 0;
f == &a ? (void)0 : fn1();
  }
}

int main() {
  if (a)
*b = 3;
  h = a;
  b = &h;
  *g = **i;
  __builtin_printf("%d\n", d);
  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