[llvm-bugs] [Bug 28612] Clang occasionally crashes when running with ccache and icecc

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

tsniatowski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from tsniatowski  ---
This was narrowed down to an icecc misconfiguration where the distributed
compiler would mix clang versions, not a clang problem.

-- 
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 30651] New: Sever bug in clang-tidy for readability-else-after-return

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

Bug ID: 30651
   Summary: Sever bug in clang-tidy for
readability-else-after-return
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Static Analyzer
  Assignee: kreme...@apple.com
  Reporter: abramo.bagn...@bugseng.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

$ cat p.c
int f(int x) {
  if (x == 0) {
++x;
  }
  else if (x <= 1) {
return 2;
  }
  else {
return 3;
  }
  return 0;
}
$ clang-tidy-4.0 -checks=readability-else-after-return p.c --
1 warning generated.
/tmp/p.c:8:3: warning: do not use 'else' after 'return'
[readability-else-after-return]
  else {
  ^

The proposed change would alter the semantic of program.

-- 
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 30651] Sever bug in clang-tidy for readability-else-after-return

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

Abramo Bagnara  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
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 30653] New: Opcode dressing on MOV instruction with segment register is the wrong size

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

Bug ID: 30653
   Summary: Opcode dressing on MOV instruction with segment
register is the wrong size
   Product: libraries
   Version: 3.9
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: njholc...@wi.rr.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The result of decoding bytes 8E1E is:
movl (%rsi), %ds

However, the segment register is 16 bits wide. The opcode should be movw.

-- 
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 30654] New: [LoopVectorizer/SCEV] induction with truncation prevents vectorization. Need runtime overflow test.

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

Bug ID: 30654
   Summary: [LoopVectorizer/SCEV] induction with truncation
prevents vectorization. Need runtime overflow test.
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Saw this missed optimization in a Geekbench workload:
We have a signed int index ‘w_ix’ which is incremented by an unsigned long
‘step’.
When compiling with -m32 all is well.
However when compiling with -m64 the result of the ulong addition may not fit
in back into the sint index and so we may have sint overflow (the index may
wrap).

for.body:
  %w_ix.014 = phi i64 [ %add3, %for.body ], [ 0, %for.body.preheader ]
  %sext = shl i64 %w_ix.014, 32
  %idxprom = ashr exact i64 %sext, 32
  %add3 = add i64 %idxprom, %step

As a result the loop vectorizer fails with
“LV: PHI is not a poly recurrence… Found an unidentified PHI”.
"loop not vectorized: value that could not be identified as reduction is used
outside the loop."

In order to guarantee that the induction behaves nicely we need to identify
this pattern (addition with 64-to-32-bit truncation), and generate a runtime
sint overflow check (e.g. check that step*loopTripCount is small enough).

This is a reduced testcase:

#include 
float in[1000];
float out[1000];
void test(size_t out_start, size_t size, size_t step)
{
int w_ix = 0;
for (size_t out_offset = 0; out_offset < size; ++out_offset)
{
size_t out_ix = out_start + out_offset;
float w = in[w_ix];
out[out_ix] += w;
w_ix += step;
}
}

(I compiled it with -m64 -Ofast -static -march=core-avx2 ).

-- 
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 30655] New: clang 3.9 release and 4.0 trunk ICE with -fsanitize-coverage=trace-pc on Windows

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

Bug ID: 30655
   Summary: clang 3.9 release and 4.0 trunk ICE with
-fsanitize-coverage=trace-pc on Windows
   Product: clang
   Version: 3.9
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: release blocker
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: s_bugzi...@nedprod.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17421
  --> https://llvm.org/bugs/attachment.cgi?id=17421&action=edit
crash dump

For smaller programs -fsanitize-coverage=trace-pc works very well with clang
targeting the MSVC ABI on Windows. Unfortunately more complex programs ICEs the
compiler:

C:\Users\ned\Documents\boostish\kerneltest\test>clang++ -shared -fexceptions -o
test_output.dll coverage_main.cpp -I.. -DUNICODE -fsanitize-coverage=trace-pc
Wrote crash dump file "C:\Users\ned\AppData\Local\Temp\clang++.exe-4df732.dmp"
0x7FF6AEA72CF6 (0x017E203C0C80 0x 0x
0x2F61F001923C)
0x7FF6AEA72C76 (0x017E2021CCB8 0x017E2038FA10 0x017E2021CCB8
0x)
0x7FF6B0123F5F (0x202D4301 0x0855 0x017E20460950
0x017E18709E90)
0x7FF6B0122ED8 (0x00A1 0x017E20270DC0 0x017E204348D8
0x00A1)
0x7FF6AEA489D1 (0x017E1F1D8901 0x7FF6B01DD4D0 0x001F
0x08A6)
0x7FF6AEECCF13 (0x 0x 0x
0x017E1A7FD708)
0x7FF6B01B7665 (0x7FF6B0CE8920 0x7FF6AF18B72A 0x0008
0x7FF6ADF01001)
0x7FF6AF6A8E82 (0x 0x 0x0008
0x017E18678AA0)
0x7FF6AF1C0AD7 (0x0004 0x017E0013 0x7FF6B087
0x0004)
0x7FF6AF18E077 (0x017E18684DC0 0x7FF6B01DD547 0x2535323EB0BD
0x7FF6B0CE9188)
0x7FF6AF1FE8E2 (0x0001FF01 0x 0x0940
0x0001)
0x7FF6ADF05B14 (0x0001 0x017E1868B310 0x001AA9D8E680
0x7FF9DB18BDFF)
0x7FF6ADF03BEC (0x 0x 0x
0x)
0x7FF6B01DE1F4 (0x 0x 0x
0x)
0x7FF9D9598364 (0x 0x 0x
0x), BaseThreadInitThunk() + 0x14 bytes(s)
0x7FF9DB1C5E91 (0x 0x 0x
0x), RtlUserThreadStart() + 0x21 bytes(s)
clang++.exe: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.9.0 (branches/release_39)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
clang++.exe: 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++.exe: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++.exe: note: diagnostic msg:
C:\Users\ned\AppData\Local\Temp\coverage_main-ae94ef.cpp
clang++.exe: note: diagnostic msg:
C:\Users\ned\AppData\Local\Temp\coverage_main-ae94ef.sh
clang++.exe: note: diagnostic msg:



-- 
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 30644] ROTATE by 1 instruction is preferable over ROTATE with immediate

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

Zvi Rackover  changed:

   What|Removed |Added

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

--- Comment #2 from Zvi Rackover  ---
Fix in r283758

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

Re: [llvm-bugs] Building Dragonegg for use with LLVM 3.6.2

2016-10-10 Thread James Molloy via llvm-bugs 
Hi Kurt,

This is the wrong mailing list. This mailing list is automated and is only for 
bugzilla traffic. The right mailing list for your question is 
llvm-...@lists.llvm.org.

Cheers,

James
On 29 Sep 2016, at 21:42, Kurt Harper via llvm-bugs 
mailto:llvm-bugs@lists.llvm.org>> wrote:

We are attempting to build Dragonegg 3.6.2 with LLVM 3.6.2 in order to 
benchmark using the SPEC2006 benchmarks; however, we are unable to build 
Dragonegg successfully using either GCC 4.6, 4.7, and 4.8. We get the 
compilation error:

In function ‘llvm::MDNode* describeAliasSet(tree)’:
DRAGONEGG_DIR/src/Aliasing.cpp:140:16: error: ‘class llvm::MDNode’ has no 
member named ‘replaceAllUsesWith’
   LeafTag->replaceAllUsesWith(getTBAARoot());

Is there a fix for this error? If there is not, is there an alternative way to 
run the SPEC2006 benchmark programs, including the Fortran benchmarks, with 
LLVM?

Thanks
-Kurt
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Re: [llvm-bugs] Building Dragonegg for use with LLVM 3.6.2

2016-10-10 Thread Duncan Sands via llvm-bugs 

Hi Kurt,

On 09/29/2016 10:42 PM, Kurt Harper via llvm-bugs wrote:

We are attempting to build Dragonegg 3.6.2 with LLVM 3.6.2 in order to benchmark
using the SPEC2006 benchmarks; however, we are unable to build Dragonegg
successfully using either GCC 4.6, 4.7, and 4.8. We get the compilation error:

In function ‘llvm::MDNode* describeAliasSet(tree)’:
DRAGONEGG_DIR/src/Aliasing.cpp:140:16: error: ‘class llvm::MDNode’ has no member
named ‘replaceAllUsesWith’
   LeafTag->replaceAllUsesWith(getTBAARoot());


dragonegg hasn't been updated in a long time: the project is dead.  This error 
comes from the LLVM version, not the GCC version.  If no-one steps up with a fix 
then you need to use an older version of LLVM.


Best wishes, Duncan.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30656] New: setting MacroBlockBegin / MacroBlockEnd slows down clang-format 4x

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

Bug ID: 30656
   Summary: setting MacroBlockBegin / MacroBlockEnd slows down
clang-format 4x
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: nicolaswe...@gmx.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified

clang-formatting all files in blink takes about 15s on my machine. We recently
deleted the blink-specific .clang-format file which makes it fall back to the
global chromium .clang-format file. That one sets MacroBlockBegin/End, and with
that .clang-format file, reformatting all files in blink now takes about 60s.
(Deleting the MacroBlockBegin / MacroBlockEnd from our global .clang-format
file makes things fast again.)

Here's our .clang-format file:

BasedOnStyle: Chromium
Standard: Cpp11
MacroBlockBegin: "^\
BEGIN_MSG_MAP|\
BEGIN_MSG_MAP_EX|\
BEGIN_SAFE_MSG_MAP_EX|\
CR_BEGIN_MSG_MAP_EX|\
IPC_BEGIN_MESSAGE_MAP|\
IPC_BEGIN_MESSAGE_MAP_WITH_PARAM|\
IPC_PROTOBUF_MESSAGE_TRAITS_BEGIN|\
IPC_STRUCT_BEGIN|\
IPC_STRUCT_BEGIN_WITH_PARENT|\
IPC_STRUCT_TRAITS_BEGIN|\
POLPARAMS_BEGIN|\
PPAPI_BEGIN_MESSAGE_MAP$"
MacroBlockEnd: "^\
CR_END_MSG_MAP|\
END_MSG_MAP|\
IPC_END_MESSAGE_MAP|\
IPC_PROTOBUF_MESSAGE_TRAITS_END|\
IPC_STRUCT_END|\
IPC_STRUCT_TRAITS_END|\
POLPARAMS_END|\
PPAPI_END_MESSAGE_MAP$"


This looks reasonably short and shouldn't slow down formatting 4x. (I'm not
sure if ^ has higher precedence than |, but changing the regexen to "^(a|b|c)$"
didn't change performance)

-- 
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 30657] New: DAG-Level reassociation makes expression trees deeper

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

Bug ID: 30657
   Summary: DAG-Level reassociation makes expression trees deeper
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

As part of the DAG combiner's efforts to perform constant-folding, we have the
following two combines:

// (op (op x, c1), y) -> (op (op x, y), c1) iff x+c1 has one use
// (op x, (op y, c1)) -> (op (op x, y), c1) iff x+c1 [sic] has one use

These combines take constants and bring them closer to the expression tree's
root. This works well if we have several constants in the expression tree, but
makes the tree deeper for no good reason if there's only one constant - which
serves to reduce available ILP.

For example, consider:

define i32 @better(i32 %a, i32 %b) {
  %r1 = xor i32 %a, 14
  %r2 = xor i32 %b, 11
  %r3 = xor i32 %r1, %r2
  ret i32 %r3
}

define i32 @worse(i32 %a, i32 %b, i32 %c) {
  %r1 = xor i32 %a, 14
  %r2 = xor i32 %b, %c
  %r3 = xor i32 %r1, %r2
  ret i32 %r3
}

With the current reassociation step we get, with bin/llc -mtriple=x86_64
-mcpu=nehalem: 
(Note that without specifying a CPU we get the same bad re-association from the
machine combiner, but that's justifiable, since without scheduling information,
it can't make a reasonable decision):

better:
xorl%esi, %edi
xorl$5, %edi
movl%edi, %eax
retq

worse:
xorl%edx, %esi
xorl%edi, %esi
xorl$14, %esi
movl%esi, %eax
retq

Without reassociation, we get:

better:
xorl$14, %edi
xorl$11, %esi
xorl%edi, %esi
movl%esi, %eax
retq

worse:
xorl$14, %edi
xorl%edx, %esi
xorl%edi, %esi
movl%esi, %eax
retq

So, for the 'worse' case, we now have a 3-instruction critical path, instead of
a 2-instruction one.

I'm not really sure what we should do about this. The three options I see:

1) Stop doing re-association in DAG. We already perform reassociation in the
IR, and should come out of the IR with good, balanced trees. Lowering may
introduce additional constants, but at least the common case of GEP lowering
doesn't seem to create patterns that require this transformation.

2) Do better re-association in DAG - try to push all constants together, but,
say, towards, the rightmost leaf, instead of towards the root. I don't quite
see how to do this with local transformations, though.

3) Leave the DAG combine as is, and let the MachineCombiner undo this
per-target. I think that's not very appealing. While, in a sense, this is the
MachineCombiner's job - what the DAG combiner does seems decidedly
"non-canonical" - it's intentionally making the expression tree worse. 
More practically speaking, fixing this post-selection will not be very easy -
for example, on x86, we may need to undo LEA selection.

Any thoughts?

-- 
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 30197] Scheduler disregards aliasing for stack slots resulting in miscompilation

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

Simon Dardis  changed:

   What|Removed |Added

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

--- Comment #8 from Simon Dardis  ---
Yeah, my apologies for not closing this promptly. The problem was MIPS
specific, in that a tail call site was not marked as such. Fix committed as
r282063.

-- 
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 28957] constant function parameter is set to existing value

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

Sanjay Patel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||james.mol...@arm.com
 Resolution|--- |FIXED

--- Comment #3 from Sanjay Patel  ---
Thanks, Zvi! This is now optimized differently in IR:

define i32 @foo(i32 %x) local_unnamed_addr #0 {
entry:
  %cmp = icmp eq i32 %x, 1
  %.sink = select i1 %cmp, i32 1, i32 -1
  %call1 = tail call i32 @bar(i32 %.sink) #2
  ret i32 %call1
}

declare i32 @bar(i32) local_unnamed_addr #1
-

This is likely due to one of James Molloy's (cc'ing) improvements to
SimplifyCFG. https://reviews.llvm.org/D22143 ?

Resolving as 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 28964] [SimplifyCFG] failure to sink common function call below if/else

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

Sanjay Patel  changed:

   What|Removed |Added

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

--- Comment #5 from Sanjay Patel  ---
Assuming that this was fixed with whichever commit stuck and corresponds to:
https://reviews.llvm.org/D22143

-- 
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 30216] GVNHoist hoists a store above a load of the same memory location

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #13 from Sebastian Pop  ---
Reopening, as the fix was reverted in:

commit 579bab4252d27fec369fca49aab7fda023775307
Author: Hans Wennborg 
Date:   Thu Sep 22 21:20:53 2016 +

Revert r282168 "GVN-hoist: fix store past load dependence analysis
(PR30216)"

and also the dependent r282175 "GVN-hoist: do not dereference null
pointers"

It's causing compiler crashes building Harfbuzz (PR30499).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282199
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
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 14879] "Ran out of registers during register allocation" for very constrained regclasses

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

Dylan McKay  changed:

   What|Removed |Added

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

--- Comment #1 from Dylan McKay  ---
This was fixed in r283838

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