[llvm-bugs] [Bug 26432] Archive name is not printed in diagnostic.

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

Rui Ueyama  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r...@google.com
 Resolution|--- |FIXED

--- Comment #1 from Rui Ueyama  ---
Implemented in r259475.

-- 
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 26150] [ELF] unknown argument -Bsymbolic-functions

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

George Rimar  changed:

   What|Removed |Added

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

--- Comment #3 from George Rimar  ---
Implemented in r259481

-- 
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 26434] New: [Polly] -polly-parallel miscompiles two LNT benchmarks

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

Bug ID: 26434
   Summary: [Polly] -polly-parallel miscompiles two LNT benchmarks
   Product: Polly
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Optimizer
  Assignee: polly-...@googlegroups.com
  Reporter: tob...@grosser.es
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

We see currently two miscompiles in LNT with -polly-parallel:

http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-parallel-fast/builds/15119

-- 
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 26435] New: CWG 1388; Invalid deduction of non-trailing template parameter pack

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

Bug ID: 26435
   Summary: CWG 1388; Invalid deduction of non-trailing template
parameter pack
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++14
  Assignee: unassignedclangb...@nondot.org
  Reporter: r...@gmx.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

template 
void f(T..., U...) {}

int main() {f();}

---

This shouldn't compile. Although U is deduced to the empty pack via
[temp.arg.explicit]/3, T isn't, because it isn't trailing. I.e. this code
should yield a deduction failure.

-- 
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 26436] New: End of non-void function reached behavior

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

Bug ID: 26436
   Summary: End of non-void function reached behavior
   Product: clang
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: kre...@email.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

When there's no return outside of conditional/loop/switch statement, but a
function expects a return type, clang will generate a warning, as expected.

There is one special case, and that's a switch statement where one statement
will always be true because every possible input value has been covered. In
such case, clang shouldn't return a warning, much like gcc does at the moment.

An example for such code can be found at [1]. See also [2].

[1]
https://github.com/systemd/systemd/blob/61f32bff6130a44d077886d38cff89ad161bf177/src/resolve/dns-type.c#L242
[2] https://github.com/systemd/systemd/issues/2504

Linux, clang 3.8.0rc1.

-- 
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 26437] New: TestProcessIO.test_stdin_redirection is flaky on android

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

Bug ID: 26437
   Summary: TestProcessIO.test_stdin_redirection is flaky on
android
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

(At least) in build 5110 of the ubuntu->android buildbot it failed the start
the inferior.

==
FAIL: test_stdin_redirection_dwo (TestProcessIO.ProcessIOTestCase)
Exercise SBLaunchInfo::AddOpenFileAction() for STDIN without specifying
STDOUT or STDERR.
--
Traceback (most recent call last):
  File
"/home/lldb_build/lldbSlave/lldb-cross-compile/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2299, in dwo_test_method
return attrvalue(self)
  File
"/home/lldb_build/lldbSlave/lldb-cross-compile/llvm/tools/lldb/packages/Python/lldbsuite/test/python_api/process/io/TestProcessIO.py",
line 47, in test_stdin_redirection
self.run_process(False)
  File
"/home/lldb_build/lldbSlave/lldb-cross-compile/llvm/tools/lldb/packages/Python/lldbsuite/test/python_api/process/io/TestProcessIO.py",
line 165, in run_process
self.assertTrue(error.Success(), "Make sure process launched successfully")
AssertionError: False is not True : Make sure process launched successfully
Config=aarch64-/home/lldb_build/Toolchains/aarch64-21/bin/aarch64-linux-android-gcc

The logs seems to indicate that the server returned an error response to the $A
packet. It is hard to diagnose the exact error without access to the server
logs.

-- 
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 8901] Attribute mode rejected for enum types.

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

Denis Zobnin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Denis Zobnin  ---
Fixed in r259497 (http://reviews.llvm.org/rL259497).

Denis Zobnin

Software Engineer
Intel Compiler Team
Intel

-- 
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 26438] New: [mcu] Assertion `NumBits >= MIN_INT_BITS && "bitwidth too small"' failed

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

Bug ID: 26438
   Summary: [mcu]  Assertion `NumBits >= MIN_INT_BITS && "bitwidth
too small"' failed
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: andrey.kules...@intel.com
CC: 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 26439] New: android adb connection can sometimes fail

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

Bug ID: 26439
   Summary: android adb connection can sometimes fail
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

I have observed this happen on the darwin->android buildbot, build #8401


==
FAIL: test_c_global_variables_dwo (TestGlobalVariables.GlobalVariablesTestCase)
   Test 'frame variable --scope --no-args' which omits args and shows scopes.
--
Traceback (most recent call last):
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2299, in dwo_test_method
return attrvalue(self)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 617, in wrapper
func(*args, **kwargs)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 617, in wrapper
func(*args, **kwargs)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py",
line 44, in test_c_global_variables
'stop reason = breakpoint'])
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2677, in expect
self.runCmd(str, msg=msg, trace = (True if trace else False), check = not
error, inHistory=inHistory)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2603, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Process should be stopped due to breakpoint
Config=aarch64-/Users/lldb_build/Toolchains/aarch64-21/bin/aarch64-linux-android-gcc


Logs are a bit scarce, but they seem to indicate this was caused by a failed
adb connection while attempting to install liba.so.
1454384745.166052000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::ConnectionFileDescriptor ()
1454384745.166061000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::Connect (url = 'connect://localhost:5037')
1454384745.166066000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::CloseCommandPipe()
1454384745.166078000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::OpenCommandPipe() - success readfd=16 writefd=17
1454384745.166085000 [ced5/0713]: Socket::TcpConnect (host/port =
localhost:5037)
1454384745.166098000 [ced5/0713]: TCPSocket::Connect (host/port =
localhost:5037)
1454384745.166318000 [ced5/0713]: 0x7fcfec5099d0 Socket::Close (fd = 18)
1454384745.166341000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::~ConnectionFileDescriptor ()
1454384745.166348000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::Disconnect ()
1454384745.166353000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::Disconnect(): Nothing to disconnect
1454384745.166359000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::CloseCommandPipe()
1454384745.166379000 [ced5/0713]: SBTarget(0x7fcfee005400)::Launch (...) =>
SBProcess(0x7fcfef82ea00)

Normally, the TCPSocket::Connect should be followed by a bunch of socket
traffic. Instead, we seem to be closing the socket without sending any data.

It's hard to tell what to do at the moment, but I'll try to add more logging to
better understand the 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 26440] New: Using PCH doesn't auto-link "libcpmt.lib" as happend without PCH

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

Bug ID: 26440
   Summary: Using PCH doesn't auto-link "libcpmt.lib" as happend
without PCH
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows XP
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: filte...@psychosanity.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

I'm using trunk clang along with the libraries/headers/etc from VS 2015. When I
tried to put all the system headers I use (windows.h, plus several c++ headers
like vector) into a precompiled header, linking started failing. After turning
on the linker's verbose option, I found the culprit: Without using PCH,
"libcpmt.lib" is automatically linked into the executable, but using the PCH
does not include that library automatically.

-- 
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 26441] New: TestConsecutiveBreakpoints.test_single_step_thread_specific fails on OSX

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

Bug ID: 26441
   Summary: TestConsecutiveBreakpoints.test_single_step_thread_spe
cific fails on OSX
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

FAIL: test_single_step_thread_specific
(TestConsecutiveBreakpoints.ConsecutiveBreakpointsTestCase)
   Test that single step stops, even though the second breakpoint is not valid.
--
Traceback (most recent call last):
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 552, in wrapper
return func(self, *args, **kwargs)
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoints/TestConsecutiveBreakpoints.py",
line 96, in test_single_step_thread_specific
self.bkpt_address.GetLoadAddress(self.target))
AssertionError: 4497530763L != 4497530757L


It is not yet clear why r259488 (which fixed the issue on linux and added the
test) does not work on osx.

-- 
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 26425] clang crashes on valid code at -O2 and above on x86_64-linux-gnu running pass “X86 DAG-?=>=?UTF-8?Q?DAG Instruction Selection”

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

David Majnemer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||david.majne...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from David Majnemer  ---


*** This bug has been marked as a duplicate of bug 15941 ***

-- 
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 26442] New: -m32 -miamcu doesn't work for Linux/x86 clang

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

Bug ID: 26442
   Summary: -m32 -miamcu doesn't work for Linux/x86 clang
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

GCC 6 targeting Linux/x86 supports "-m32 -miamcu" which generates codes
conforming to IA MCU psABI.  With clang, I got

[hjl@gnu-6 tmp]$
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -c
-m32 -miamcu -S e.i
clang-3.9: error: unknown argument: '-miamcu'
[hjl@gnu-6 tmp]$

-- 
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 26389] [x86-64] clang generate wrong instruction for cygwin

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

Reid Kleckner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r...@google.com
 Resolution|--- |INVALID

--- Comment #1 from Reid Kleckner  ---
Windows doesn't support executables or DLLs larger than 2GB, so cout must be
coming from another DLL.

In that case, data imported from another DLL must be annotated as dllimport.
This is not required for functions as import libraries generally provide thunks
to make sure things work out.

-- 
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 25199] [BranchFolding][AArch64] AArch64LoadStoreOpt uses MMOs which are dropped during tail merge

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

Chad Rosier  changed:

   What|Removed |Added

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

--- Comment #1 from Chad Rosier  ---
Fixed in r257317.

-- 
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 26443] New: Can't find my own posts/comments

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

Bug ID: 26443
   Summary: Can't find my own posts/comments
   Product: Bugzilla Admin
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: UI
  Assignee: unassignedb...@nondot.org
  Reporter: andrew.penneba...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Please make it easier for users to find their own interactions after they
comment or post, and close their Web browser.

* Index comment text
* Provide a link like My Posts, that queries for my interactions with Bugzilla.

-- 
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 26444] New: [Regression] Clang crashes on structs with large alignment

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

Bug ID: 26444
   Summary: [Regression] Clang crashes on structs with large
alignment
   Product: clang
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: yunzhong_...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Hi,

Clang 3.8 (and trunk) crashes on the following test case, but clang 3.7.1 works
fine.

$ cat align.cc
struct A {
  A();
} a __attribute__((aligned(0x1)));

$ clang --version
clang version 3.9.0 (trunk 259447)
Target: x86_64-unknown-linux-gnu

$ clang -S -o - align.cc
clang: Address.h:32: clang::CodeGen::Address::Address(llvm::Value*,
clang::CharUnits): Assertion `(!alignment.isZero() || pointer == nullptr) &&
"creating valid address with invalid alignment"' failed.

Could someone take a look?

-- 
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 26356] PowerPC64: fast isel creates bad constant

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

Anton Blanchard  changed:

   What|Removed |Added

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

--- Comment #4 from Anton Blanchard  ---
Thanks Eric, Nemanja. I think we still have an issue in PPCMaterializeInt:


target datalayout = "e-m:e-i64:64-n32:64"
target triple = "powerpc64le-unknown-linux-gnu"

; Function Attrs: nounwind
define internal i32 @foo() #0 {
  ret i32 32768
}


# llc -O1 testcase.ll
...
foo:
li 3, 0
ori 3, 3, 32768
blr


# llc -O1 -fast-isel testcase.ll
...
foo:
li 3, -32768
blr

-- 
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 26445] New: [ppc] inefficient code generated for std::max(float, float)

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

Bug ID: 26445
   Summary: [ppc] inefficient code generated for std::max(float,
float)
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: PowerPC
  Assignee: unassignedb...@nondot.org
  Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Compile following code with options: $ ~/llvm/obj2/bin/clang++ 
--target=powerpc64le-grtev4-linux-gnu -m64 -mvsx -mcpu=power8 -O2 -c -o t9.o
t9.cc -fno-unroll-loops

#include 

float foo(float* input, int s) {
  float max_value = input[0];
  for (int j = 1; j <= s; ++j)
  max_value = std::max(max_value, input[j]);

  return max_value;
}


I got following code for the loop body

.LBB0_2:# %for.body
# =>This Inner Loop Header: Depth=1
lfsu 0, 4(3)
fcmpu 0, 1, 0
isel 5, 3, 4, 0
lwz 5, 0(5)
mtvsrd 34, 5
stw 5, -12(1)
xxsldwi 13, 34, 34, 1
xscvspdpn 1, 13
bdnz .LBB0_2


There are several problems in this code snippet

1. instead of compare and choose maximum float value, the generated code uses
isel to choose the address of larger value, then load it into integer register,
then move it to fp register, then expand it to double type.

2. no need to store the max value to memory.


It causes one of our internal applications more than 2x slower.

-- 
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 24989] Regression: Lambda with no return behaves differently from lambda with empty return

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

Richard Smith  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Smith  ---
Reduced to:

  auto x = [](auto){};
  void (decltype(x)::*p)(int) const = &decltype(x)::operator();

Some of our C++11 lambda return type inference machinery was accidentally being
used in C++14 mode (where we intend to just use normal 'auto' return type
deduction).

Fixed in r259609.

-- 
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 26446] New: std::numeric_limits::max_digits10 massively wrong for ppc

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

Bug ID: 26446
   Summary: std::numeric_limits::max_digits10
massively wrong for ppc
   Product: libc++
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified

libc++ thinks that std::numeric_limits::max_digits10 is 33 for
ppc64-linux. However, both DBL_MAX + DBL_DENORM_MIN and DBL_MAX +
DBL_DENORM_MIN*2 can be exactly represented by a PPC double double, and you
need around 633 decimal digits to distinguish those two values.

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