[llvm-bugs] [Bug 47731] Several Mips, X86 CodeGen tests FAIL on Solaris/sparcv9

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=47731

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #21 from Rainer Orth  ---
(In reply to Eli Friedman from comment #20)
> It looks like StackSlotColoring has one other possibly relevant flag: you
> could try "-ssc-dce-limit=0".  I think that will remove the diff noted in
> the comment.
> 
> Beyond that, I think you could add a mechanism to limit the number of stack
> slots that are colored by StackSlotColoring, and bisect using that?
> 
> Thinking about it a bit more, I have another theory for what might be going
> wrong: some code could be using uninitialized data, and we're getting
> lucky/unlucky. This can be nasty to diagnose... one trick I've used in the
> past is hacking the assembly to memset the stack to zero before returning.

I didn't get back to this in a while, but recently found that the bug has
gone away.  Looing at the new Linux/sparc64 buildbot
(http://lab.llvm.org:8014/#/builders/134)
which unlike my Solaris/sparcv9 one runs 2-stage builds), one can see that the
failures went away betweens builds 38 and 40.  Given the large number of
changes
included in those two, it's difficult to tell exactly which patch fixed the
issue,
but it seems plausible that one of Simon's did.

Given that the failures haven't resurfaced since, I guess we can safely close
this PR.

> (In reply to Rainer Orth from comment #15)
> > I can't help but feel that this is a total waste of my time: this is a
> > spare-time
> > activity and the result won't even be seen in the Solaris/sparcv9 buildbot
> > which is native-only.  I think this is something for some SPARC maintainer 
> > to
> > look into.
> 
> There is no SPARC maintainer, really; it's just various people keeping it
> limping in their spare time.  So if you don't look, nobody is going to look.
> (The primary reason we haven't just killed off the backend is that SPARC is
> widely used in academia.)

I wasn't aware of that, given that the the llvm/CODE_OWNERS.TXT still lists
a SPARC maintainer.  Fortunately, the GCC situation is different here: we do
have an active SPARC maintainer and Oracle contributed several large patches to
support newer SPARC CPUs in recent years.

-- 
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 48110] New: Incorrect Cost Calculations for Shuffle Ports on Icelake-client / Icelake-server

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=48110

Bug ID: 48110
   Summary: Incorrect Cost Calculations for Shuffle Ports on
Icelake-client / Icelake-server
   Product: tools
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: llvm-mca
  Assignee: unassignedb...@nondot.org
  Reporter: dwe...@gmail.com
CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org,
matthew.da...@sony.com

Hi there,

It looks like llvm-mca is treating icelake-client and icelake-server as having
only one shuffle port.  This causes incorrect cost calculations for any
operation that would use said shuffle ports.  A block diagram showing the
architecture can be found here:
https://en.wikichip.org/wiki/intel/microarchitectures/sunny_cove (sunny cove is
the core used by both icelake-server and icelake-client).  Similarly, you can
find the uops usage for any given shuffle here: 
https://uops.info/table.html?search=shuf&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SKL=on&cb_ICL=on&cb_measurements=on&cb_base=on&cb_avx=on

If the code generating the costs for LLVM-MCA is used by anything else in the
toolchain, it's likely this will yield a performance benefit for other users
targeting icelake-server and icelake-client.

-- 
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 48111] New: Clang mistakes gnu::nothrow attribute for noexcept(true)

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=48111

Bug ID: 48111
   Summary: Clang mistakes gnu::nothrow attribute for
noexcept(true)
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Keywords: compile-fail
  Severity: normal
  Priority: P
 Component: C++17
  Assignee: unassignedclangb...@nondot.org
  Reporter: hst...@ca.ibm.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

Clang seems to treat [[gnu::nothrow]] like `noexcept(true)` even in the type
system. GCC does not do so, and the distinction seems to be reasonable.

Compiler Explorer link: https://godbolt.org/z/heGWWb


### SOURCE ():
void f [[gnu::nothrow]]();
template  struct A;
template <> struct A {};
A a;


### COMPILER INVOCATION:
clang -cc1 -fsyntax-only -xc++ -std=c++17 -


### EXPECTED OUTPUT:
(clean compile)


### ACTUAL OUTPUT:
:4:16: error: implicit instantiation of undefined template 'A'
A a;
   ^
:2:28: note: template is declared here
template  struct A;
   ^
1 error generated.


### COMPILER VERSION INFO (clang++ -v):
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
1c19900f9417bd0b832c1cb70863b2439a18647f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/wandbox/clang-head/bin
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.5.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64

-- 
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 48112] New: Linking against Watcom code

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=48112

Bug ID: 48112
   Summary: Linking against Watcom code
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: crosserbac...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

Is it possible to officially add the Watcom calling convention to LLVM and
Clang in order to support calling code from legacy libraries and DLLs without
any inline assembly hacks to pass parameters correctly?

Basically the issue is that parameters are passed left-to-right into EAX, ECX,
EDX, and EBX, then everything else right-to-left onto the stack. Using
__fastcall or __stdcall doesn't help either, even though the conventions behave
pretty much like Watcom's.

-- 
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 48113] New: [LoopInterchange] Tightly nested checking issue

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=48113

Bug ID: 48113
   Summary: [LoopInterchange] Tightly nested checking issue
   Product: libraries
   Version: trunk
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: chenge...@huawei.com
CC: llvm-bugs@lists.llvm.org

$clang -Os -mllvm -enable-loopinterchange=true issue.c && ./a.out
9

clang -Os -mllvm -enable-loopinterchange=false issue.c && ./a.out
3

issue.c:

#include 
char a, d;
int b[][2];
char c[][9];
char *e;
static unsigned f;
short g;
static long h() {
  for (; f <= 2; f++) {
char *i = &d;
int j = 0;
for (; j <= 2; j++)
  b[j][1] = c[j][f];
++*i;
if (a)
  g = *e;
  }
}
int main() {
  h();
  printf("%lX\n", d);
}

-- 
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 27336 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in TransformTypos::RecursiveTransformLoop

2020-11-08 Thread ClusterFuzz-External via monorail via llvm-bugs 
Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, 
d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, 
llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, 
mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com 
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible 
Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-09
Type: Bug

New issue 27336 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in 
TransformTypos::RecursiveTransformLoop
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27336

Detailed Report: https://oss-fuzz.com/testcase?key=5732711763017728

Project: llvm
Fuzzing Engine: libFuzzer
Fuzz Target: clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffc4106fa48
Crash State:
  TransformTypos::RecursiveTransformLoop
  TransformTypos::CheckForRecursiveTypos
  
Sanitizer: address (ASAN)

Regressed: 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006110252:202006121812

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5732711763017728

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing 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. 
Comments on individual Monorail issues are not monitored.

-- 
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 48114] New: neon: vqshl scalar functions use wrong type for b parameter

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=48114

Bug ID: 48114
   Summary: neon: vqshl scalar functions use wrong type for b
parameter
   Product: new-bugs
   Version: 11.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

According to Arm's documentation
(),
the second parameter should be signed for the following functions:

  vqshlb_u8
  vqshlh_u16
  vqshls_u32
  vqshld_u64

However, clang-11 uses unsigned values.

The vector versions are signed (e.g., vqshl_u8 uses int8x8_t not uint8x8_t),
and passing negative values is completely sensible.

GCC also has the same problem, I'll file a bug there soon.  I don't currently
have access to armcc.

-- 
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 48114] neon: vqshl scalar functions use wrong type for b parameter

2020-11-08 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=48114

Evan Nemerson  changed:

   What|Removed |Added

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