HJ's regression tester shows the new test gcc.dg/iec-559-macros-9.c
failing for 32-bit x86. It turns out the excess precision handling
for determining the value of __GCC_IEC_559 has two problems:
flag_excess_precision hasn't been initialized at the point it's
tested, so
Hi Peter.
Does this also mean that asan in llvm trunk is broken for Power?
We'll need to fix it there too (or, in fact, first).
--kcc
On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner berg...@vnet.ibm.com wrote:
On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote:
This patch has not
On 11/04/13 06:19, Richard Biener wrote:
On Thu, Oct 31, 2013 at 7:11 AM, Jeff Law l...@redhat.com wrote:
I've incorporated the various suggestions from Marc and Richi, except for
Richi's to integrate this into jump threading.
I've also made the following changes since the last version:
On Mon, 2013-11-04 at 17:48 -0800, Konstantin Serebryany wrote:
Hi Peter.
Does this also mean that asan in llvm trunk is broken for Power?
We'll need to fix it there too (or, in fact, first).
I'm not sure. Bill, can you fire off a quick LLVM trunk build on
powerpc64-linux and see you see the
I've applied this patch to C11-atomic branch to add support for
handling x87 floating-point exceptions for atomic compound assignment.
With this applied, c11-atomic-exec-5.c now passes on
x86_64-unknown-linux-gnu. I consider the branch now feature-complete
regarding _Atomic support (as opposed to
Hi,
This fixes the two companion patterns vec_pack_[su]fix_trunc_v2df in the
same manner as the recent fix for vec_pack_trunc_v2df. The same fix
obviously applies here as well. Bootstrapped and tested on
powerpc64{,le}-unknown-linux-gnu with no regressions. Is this ok for
trunk?
Thanks,
Bill
Hi Peter,
The buildbot shows the latest LLVM ppc64 build is working ok:
http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/8086
This build completed about two hours ago.
Hope this helps,
Bill
On Mon, 2013-11-04 at 20:02 -0600, Peter Bergner wrote:
On Mon, 2013-11-04 at 17:48 -0800,
On Mon, Nov 4, 2013 at 10:21 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
This fixes the two companion patterns vec_pack_[su]fix_trunc_v2df in the
same manner as the recent fix for vec_pack_trunc_v2df. The same fix
obviously applies here as well. Bootstrapped and tested on
Hello Everyone,
Attached, please find a patch to fix PR 58951. The usage of -ldl is not
necessary. The patch is tested in x86_64 and x86. It is committed as obvious.
Thanks,
Balaji V. Iyer.
Index: Makefile.in
===
---
It also breaks x32 build.
On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Hi Peter.
Does this also mean that asan in llvm trunk is broken for Power?
We'll need to fix it there too (or, in fact, first).
--kcc
On Mon, Nov 4, 2013 at 4:33 PM,
Is this the same failure or different?
On Mon, Nov 4, 2013 at 9:49 PM, H.J. Lu hjl.to...@gmail.com wrote:
It also breaks x32 build.
On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Hi Peter.
Does this also mean that asan in llvm trunk is broken
Bill,
This build does not seem to be testing any of the asan code: you need
check-asan
--kcc
On Mon, Nov 4, 2013 at 7:30 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi Peter,
The buildbot shows the latest LLVM ppc64 build is working ok:
On Mon, Nov 04, 2013 at 11:56:38PM +0100, Tobias Burnus wrote:
gcc/
* doc/invoke.texi (-fopenmp-simd): Document new option.
* gimplify.c (gimplify_body): Accept -fopenmp-simd.
* omp-low.c (execute_expand_omp, execute_lower_omp): Ditto.
* tree.c (attribute_value_equal):
On Tue, Nov 05, 2013 at 01:14:46AM +, Joseph S. Myers wrote:
HJ's regression tester shows the new test gcc.dg/iec-559-macros-9.c
failing for 32-bit x86. It turns out the excess precision handling
for determining the value of __GCC_IEC_559 has two problems:
flag_excess_precision hasn't
On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote:
Hi Peter.
Does this also mean that asan in llvm trunk is broken for Power?
We'll need to fix it there too (or, in fact, first).
I bet on all targets, not just PPC. By including kernel headers directly,
you are entering
301 - 315 of 315 matches
Mail list logo