[llvm-bugs] [Bug 34588] New: ARM's clear_cache should not call abort

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34588

Bug ID: 34588
   Summary: ARM's clear_cache should not call abort
   Product: compiler-rt
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: compiler-rt
  Assignee: manojgu...@google.com
  Reporter: manojgu...@google.com
CC: compn...@compnerd.org, lloz...@chromium.org,
llvm-bugs@lists.llvm.org, llvm-bugzi...@jfbastien.com,
renato.go...@linaro.org, srhi...@google.com

clear_cache for ARM is calling abort() when start address is not a NULL
pointer. clear_cache documentation in libgcc does not specify any aborting
behavior. Libgcc implementation does not do abort either.

Calling abort for a non-null start address does not make any sense either and
libgcc docs do not say that the start argument has to be NULL.

This issue was discovered when compiler-rt was enabled for ChromeOS and NaCl
failed since it was making calls to __builtin___clear_cache()
 (https://bugs.chromium.org/p/chromium/issues/detail?id=761103).

-- 
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 17633] -fsanitize=function uses .text relocations

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=17633

Peter Collingbourne  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Collingbourne  ---
This should now be fixed as of r313096.

-- 
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 34587] New: Merge r312447 into the 5.0 branch : [CodeGen] Treat all vector fields as mayalias

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34587

Bug ID: 34587
   Summary: Merge r312447 into the 5.0 branch : [CodeGen] Treat
all vector fields as mayalias
   Product: new-bugs
   Version: 5.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: tstel...@redhat.com
CC: llvm-bugs@lists.llvm.org
Blocks: 34492

Is it OK to merge the following revision(s) to the 5.0 branch?


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=34492
[Bug 34492] [meta] 5.0.1 Release Blockers
-- 
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 34586] New: Merge r312348 into the 5.0 branch : LiveIntervalAnalysis: Fix alias regunit reserved definition

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34586

Bug ID: 34586
   Summary: Merge r312348 into the 5.0 branch :
LiveIntervalAnalysis: Fix alias regunit reserved
definition
   Product: new-bugs
   Version: 5.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: tstel...@redhat.com
CC: llvm-bugs@lists.llvm.org
Blocks: 34492

Is it OK to merge the following revisions to the 5.0 branch?


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=34492
[Bug 34492] [meta] 5.0.1 Release Blockers
-- 
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 34582] [OpenMP 4.5] Array segment mapping to device with default length (e.g. map(array[1:]) ) fails at runtime

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34582

Jose Manuel Monsalve Diaz  changed:

   What|Removed |Added

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

--- Comment #1 from Jose Manuel Monsalve Diaz  ---
The problem boils down to the implicit mapping that occurs in the second
#pragma omp target. This implicit mapping is like having map(tofrom: a1d[0:N]).
Which goes agains the original mapping. 

#pragma omp target data map(from: a1d[1:])
{
#pragma omp target map(tofrom: isHost)
{
  // Some aid[] use.
}
}

Is equal to 

#pragma omp target data map(from: a1d[1:])
{
#pragma omp target map(tofrom: isHost) map(tofrom: a1d[0:N])
{
  // Some aid[] use.
}
}

This is generating a conflict. Even though the specs in the mapping section are
pretty clear what to do with respect to the reference counting, it doesn't say
anything regarding implicit mapping of a variable that is already in the table.

-- 
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 34585] New: test case clang/test/Driver/mingw-useld.c fails with revision 313082 on powerpc64le

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34585

Bug ID: 34585
   Summary: test case clang/test/Driver/mingw-useld.c fails with
revision 313082 on powerpc64le
   Product: new-bugs
   Version: unspecified
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: seu...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org

 TEST 'Clang :: Driver/mingw-useld.c' FAILED

Script:
--
/home/seurer/llvm/build/llvm-test/./bin/clang  -### -target i686-pc-windows-gnu
--sysroot=/home/seurer/llvm/llvm-test/tools/clang/test/Driver/Inputs/mingw_clang_tree/mingw32
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c
-fuse-ld=platform 2>&1 | /home/seurer/llvm/build/llvm-test/./bin/FileCheck
-check-prefix=CHECK_LD_32
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c
/home/seurer/llvm/build/llvm-test/./bin/clang  -### -target i686-pc-windows-gnu
--sysroot=/home/seurer/llvm/llvm-test/tools/clang/test/Driver/Inputs/mingw_clang_tree/mingw32
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c -fuse-ld=lld
2>&1 | /home/seurer/llvm/build/llvm-test/./bin/FileCheck
-check-prefix=CHECK_LLD_32
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c
/home/seurer/llvm/build/llvm-test/./bin/clang  -### -target
x86_64-pc-windows-gnu
--sysroot=/home/seurer/llvm/llvm-test/tools/clang/test/Driver/Inputs/mingw_clang_tree/mingw32
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c -fuse-ld=lld
2>&1 | /home/seurer/llvm/build/llvm-test/./bin/FileCheck
-check-prefix=CHECK_LLD_64
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c
/home/seurer/llvm/build/llvm-test/./bin/clang  -### -target arm-pc-windows-gnu
--sysroot=/home/seurer/llvm/llvm-test/tools/clang/test/Driver/Inputs/mingw_clang_tree/mingw32
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c -fuse-ld=lld
2>&1 | /home/seurer/llvm/build/llvm-test/./bin/FileCheck
-check-prefix=CHECK_LLD_ARM
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c
--
Exit Code: 1

Command Output (stderr):
--
/home/seurer/llvm/llvm-test/tools/clang/test/Driver/mingw-useld.c:8:18: error:
expected string not found in input
// CHECK_LLD_32: "{{[^"]*}}ld.lld{{(.exe)?}}"
 ^
:1:1: note: scanning from here
clang version 6.0.0 (trunk 313082)
^
:5:51: note: possible intended match here
clang-6.0: error: invalid linker name in argument '-fuse-ld=lld'
  ^

--



-- 
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 34583] New: LLVM does not generate correct code on arm

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34583

Bug ID: 34583
   Summary: LLVM does not generate correct code on arm
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: yunl...@chromium.org
CC: llvm-bugs@lists.llvm.org

Created attachment 19150
  --> https://bugs.llvm.org/attachment.cgi?id=19150=edit
The pre-processed file.

We found a LLVM change makes one of our test fail.
https://bugs.chromium.org/p/chromium/issues/detail?id=758878=owner%3Ame=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

The mis-compiled function is show below. If I remove the assertions at the
beginning of this function, the test passes.

I put the pre-processed code in the attachment.
The command line to compile the code is
/usr/bin/clang --sysroot=/build/kevin -Qunused-arguments -grecord-gcc-switches
-fstack-protector-strong -pie -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
-mthumb -c -MD -MF bsdrm/src/egl.pic.d -O2 -O2 -pipe -march=armv8-a+crc
-mtune=cortex-a57.cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -g
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables
-I/build/kevin/usr/include/libdrm -DEGL_EGLEXT_PROTOTYPES -DGL_GLEXT_PROTOTYPES
-Wall -Werror -fno-strict-aliasing -Wformat=2 -fstack-protector-strong
-fvisibility=internal -ggdb3 -Wa,--noexecstack -O2 -std=gnu99
-I/build/kevin/tmp/portage/chromeos-base/drm-tests-0.0.1-r100/work/drm-tests-0.0.1/bsdrm/include
-I/build/kevin/usr/include/libdrm -DEGL_EGLEXT_PROTOTYPES -DGL_GLEXT_PROTOTYPES
-DUSE_ATOMIC_API -D_FORTIFY_SOURCE=2 -fPIC -o a.e test.i
-B/usr/libexec/gcc/armv7a-cros-linux-gnueabi -target
armv7a-cros-linux-gnueabihf -mfloat-abi=hard 



EGLImageKHR bs_egl_image_create_gbm(struct bs_egl *self, struct gbm_bo *bo)
{
assert(self);
assert(self->CreateImageKHR);

int fds[GBM_MAX_PLANES];

EGLint khr_image_attrs[37] ={12375, 2400, 12374, 1600, 12913,
875713112, 0};

initStruct(self, bo, fds,  khr_image_attrs);

size_t attrs_index = 6;
for (size_t plane = 0; plane < gbm_bo_get_num_planes(bo) ;  plane++) {
khr_image_attrs[attrs_index++] = EGL_DMA_BUF_PLANE0_FD_EXT +
plane * 3;
khr_image_attrs[attrs_index++] = fds[plane];
khr_image_attrs[attrs_index++] = EGL_DMA_BUF_PLANE0_OFFSET_EXT
+ plane * 3;
khr_image_attrs[attrs_index++] = gbm_bo_get_plane_offset(bo,
plane);
khr_image_attrs[attrs_index++] = EGL_DMA_BUF_PLANE0_PITCH_EXT +
plane * 3;
khr_image_attrs[attrs_index++] = gbm_bo_get_plane_stride(bo,
plane);
if (self->use_dma_buf_import_modifiers) {
const uint64_t modifier =
gbm_bo_get_format_modifier(bo);
khr_image_attrs[attrs_index++] =
EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT + plane * 2;
khr_image_attrs[attrs_index++] = modifier &
0xul;
khr_image_attrs[attrs_index++] =
EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT + plane * 2;
khr_image_attrs[attrs_index++] = modifier >> 32;
}
}

khr_image_attrs[attrs_index++] = EGL_NONE;

EGLImageKHR image =
self->CreateImageKHR(self->display, EGL_NO_CONTEXT,
EGL_LINUX_DMA_BUF_EXT,
 NULL /* no client buffer */, khr_image_attrs);

return image;
}

-- 
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 34480] clang 6.0.0-svn312520-1~exp1 segfaults while building llvm trunk TransBlockObjCVariable.cpp

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34480

Roman Lebedev  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #3 from Roman Lebedev  ---
Not sure what the problem is.
maybe fixed.
can not be reliably reproduced.

-- 
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 34581] New: LLVM miscompiles calls to "operator delete" under -Oz

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34581

Bug ID: 34581
   Summary: LLVM miscompiles calls to "operator delete" under -Oz
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org

Test case:

void f(char *c) {
  delete c;
}

void g(char *c) {
  if (c)
::operator delete(c);
}

void h(char *c) {
  if (c)
delete c;
}

At -Oz, LLVM optimizes away the implied "if (c)" in f. It's highly questionable
for LLVM to be doing this, but a C++ implementation is permitted to elide the
null check in this case.

LLVM also optimizes away the explicit "if (c)" in g, which is a miscompile. A
user replacement operator delete may have observable effects (for instance,
logging) even when called on a null pointer, so LLVM is not allowed to invent
calls to it. Note that in this case the "operator delete" invocation is
"nobuiltin", making it doubly-clear that this is a miscompile.

Finally, it optimizes away both null checks in h, which again is a miscompile.
Despite being a builtin call, this is still an incorrect transformation, again
because operator delete can have observable side-effects.

-- 
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 33548] coverage-report-server.py: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 106: ordinal not in range(128)

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=33548

Roman Lebedev  changed:

   What|Removed |Added

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

--- Comment #1 from Roman Lebedev  ---
r313063

-- 
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 33923] getGlobalID() always returns 0

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=33923

Michael Haidl  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||michael.haidl@uni-muenster.
   ||de
 Status|NEW |RESOLVED

--- Comment #1 from Michael Haidl  ---

  683   /// \brief Retrieve the global declaration ID associated with this
  684   /// declaration, which specifies where this Decl was loaded from.
  685   unsigned getGlobalID() const {
  686 if (isFromASTFile())
  687   return *((const unsigned*)this - 1);
  688 return 0;
  689   }

getGlobalID is not intend to be used with a generated AST. To identify a Decl
uniquely use the address of the Decl, which is the hex value in the AST dump.

-- 
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 20291] libcxx C++11 regex cpu resource exhaustion

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=20291

Marshall Clow (home)  changed:

   What|Removed |Added

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

--- Comment #4 from Marshall Clow (home)  ---
Fixed by commit 313056.

-- 
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 34021] MS Inline assembly with vector type causes a bad trunc emission.

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34021

Simon Pilgrim  changed:

   What|Removed |Added

  Component|LLVM Codegen|Frontend
 Fixed By Commit(s)||313019,313024,313034
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Simon Pilgrim  ---
rL313019 (with rL313024+rL313034 test fixes)

-- 
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 34045] Regression(r309923): clang crashes compiling chrome/android

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34045

Hans Wennborg  changed:

   What|Removed |Added

 CC||h...@chromium.org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Hans Wennborg  ---
We're hitting a similar crash after r313009 + r313010. See
https://bugs.chromium.org/p/chromium/issues/detail?id=764358#c2 for source and
invocation.

-- 
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 31127] PowerPC backend not parsing vector registers correctly

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=31127

Tom Stellard  changed:

   What|Removed |Added

 Fixed By Commit(s)||r287765
 CC||tstel...@redhat.com
 Status|NEW |RESOLVED
 Resolution|--- |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 34580] New: extra CFGImplicitDtor elements in CFG

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34580

Bug ID: 34580
   Summary: extra CFGImplicitDtor elements in CFG
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: lib...@acm.org
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Created attachment 19146
  --> https://bugs.llvm.org/attachment.cgi?id=19146=edit
demonstration C++ source file with a "noisy" destructor

I am using Clang tooling libraries to build a control-flow graph for C++ code. 
I need this CFG to accurately reflect all implicit calls to destructors, so I
have set both the AddImplicitDtors and AddTemporaryDtors CFG build options. 
Unfortunately, this results in a CFG with *extra* CFGImplicitDtor items that do
not correspond to actual destructor calls in the generated code.

Consider the attached C++11 (or later) test program, "test.cc", with a "noisy"
destructor.  When run, this program prints "destroy" three times.  However, its
CFG includes two CFGTemporaryDtor elements plus two CFGAutomaticObjDtor
elements.  So I have a CFG that shows four destructor calls when only three
will take place.  (The second attached file, "dump-main-cfg.cc", is a
bare-bones Clang-based CFG dumping tool used here to help reproduce the
problem.)

If I comment out lines in main(), leaving only "give();" and the return, then I
have one "destroy" printed and one CFGTemporaryDtor in the CFG. Good.

If instead I leave only "Base base1;" and the return, then I have one "destroy"
printed and one CFGAutomaticObjDtor in the CFG.  Also good.

If instead I leave only "Base base2(give());" and the return, then I have one
"destroy" printed and both one CFGTemporaryDtor *and* one CFGAutomaticObjDtor
in the CFG.  Not good. 

How can I suppress, remove, recognize, or otherwise filter out the extra
CFGImplicitDtor in cases like "Base base2(give());"?  Is there some property I
can check of the CFGTemporaryDtor and/or CFGAutomaticObjDtor instances to
determine which ones will turn into real destructor calls and which will not? 
Should the extra CFGImplicitDtor not be appearing in the CFG in the first
place?  Is this a misunderstanding on my part or a true bug in the CFG-building
code?

Note: this concern was originally posted to the cfe-dev mailing list, and is
archived at . 
There were no replies.  I am therefore inclined to consider this as a bug
rather than just a misunderstanding.  If, however, there is a way for me to
deal with the extra destructors without changes to the underlying CFG logic,
then that's OK with me too.

-- 
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 34579] New: APFloat asserts for x87 long doubles: "Can not have more high bits to fill than integerPartWidth"

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34579

Bug ID: 34579
   Summary: APFloat asserts for x87 long doubles: "Can not have
more high bits to fill than integerPartWidth"
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Support Libraries
  Assignee: unassignedb...@nondot.org
  Reporter: a.sido...@samsung.com
CC: llvm-bugs@lists.llvm.org

A simple unit test:

TEST(APFloatTest, x87Largest) {
  APFloat MaxX87Val = APFloat::getLargest(APFloat::x87DoubleExtended);
  EXPECT_TRUE(MaxX87Val.isLargest()); // Don't crash.
}

Causes an assertion failure in APFloat::isSignificandAllOnes():
  assert(NumHighBits <= integerPartWidth &&
  "Can not have more high bits to fill than integerPartWidth");

-- 
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 34578] New: Extra archive suffix is generated for ARM baremetal builtins.

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34578

Bug ID: 34578
   Summary: Extra archive suffix is generated for ARM baremetal
builtins.
   Product: clang
   Version: 5.0
  Hardware: Other
OS: other
Status: NEW
  Severity: normal
  Priority: P
 Component: Driver
  Assignee: unassignedclangb...@nondot.org
  Reporter: eblot...@gmail.com
CC: llvm-bugs@lists.llvm.org

main.c:
  int main(void) {return 0;}

$ clang-5.0 -target arm-non-eabi main.c
/usr/local/clang50/bin/ld.lld: error: unable to find library -lc
/usr/local/clang50/bin/ld.lld: error: unable to find library -lm
/usr/local/clang50/bin/ld.lld: error: unable to find library
-lclang_rt.builtins-arm.a
clang-5.0: error: ld.lld command failed with exit code 1 (use -v to see
invocation)

Clang generates "-lclang_rt.builtins-arm.a" rather than
"-lclang_rt.builtins-arm", which makes ld.lld to search for
"libclang_rt.builtins-arm.a.a" rather than "libclang_rt.builtins-arm.a"

BTW, is there an option switch to disable standard libraries but keep linking
with builtins?

-- 
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 34577] New: [X86] Bug in shuffle-to-zero-extend transformation

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34577

Bug ID: 34577
   Summary: [X86] Bug in shuffle-to-zero-extend transformation
   Product: libraries
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: ayman.m...@intel.com
CC: llvm-bugs@lists.llvm.org

X86ISD::VZEXT node is defined to work on integer types only.

In the following IR code:

define internal fastcc <8 x float> @test(<8 x float> %inp3, <8 x float> %inp6,
<8 x float> %inp9) #0 {
entry:
  %shuf6 = shufflevector <8 x float> %inp3, <8 x float> %inp9, <8 x i32> 
  %sel6 = select <8 x i1> , <8 x float> %shuf6, <8 x float> zeroinitializer
  %shuf7 = shufflevector <8 x float> zeroinitializer, <8 x float> %sel6, <8 x
i32> 
  %shuf8 = shufflevector <8 x float> %inp6, <8 x float> %shuf7, <8 x i32> 
  ret <8 x float> %shuf8
}

the input for the extract_subvector instruction should be bitcasted to integer
type type before feeding it to zero-extend.

> ../../build/bin/llc -mattr=+avx2 test.ll -o test.s

LLVM ERROR: Cannot select: t126: v4i64 = X86ISD::VZEXT t125
  t125: v4f32 = extract_subvector t2, Constant:i64<0>
t2: v8f32,ch = CopyFromReg t0, Register:v8f32 %vreg0
  t1: v8f32 = Register %vreg0
t124: i64 = Constant<0>
In function: test

-- 
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 34576] [X86] Bug in shuffle-to-zero-extend transformation

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34576

Ayman Musa  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Ayman Musa  ---
The reproducer is again not valid.
Sorry for the mess.

Closing this bug and opening new one with the real reproducer.

-- 
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 33725] std::basic_stringbuf can't handle put areas > 2GB

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=33725

Marshall Clow (home)  changed:

   What|Removed |Added

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

--- Comment #5 from Marshall Clow (home)  ---
Fixed in revision 313031.

-- 
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 34576] New: [X86] Bug in shuffle-to-zero-extend transformation

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34576

Bug ID: 34576
   Summary: [X86] Bug in shuffle-to-zero-extend transformation
   Product: libraries
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: ayman.m...@intel.com
CC: llvm-bugs@lists.llvm.org

X86ISD::VZEXT node is defined to work on integer types only.

In the following IR code:

define internal fastcc <4 x float> @test(<4 x float> %inp) #0 {
entry:
  %shuf = shufflevector <4 x float> %inp, <4 x float> zeroinitializer, <4 x
i32> 
  ret <4 x float> %shuf
}

the input for the shufflevector instruction should be bitcasted to integer type
before feeding it to zero-extend.

> ../../build/bin/llc -mattr=+avx2 test.ll -o test.s

LLVM ERROR: Cannot select: t502: v4i64 = X86ISD::VZEXT t501
  t501: v4f32 = bitcast t500
t500: v2f64 = extract_subvector t466, Constant:i64<0>
  t466: v4f64 = X86ISD::VPERMI t428, Constant:i8<-58>
t428: v4f64 = bitcast t433
  t433: v8f32 = X86ISD::VPERMILPI t27, Constant:i8<108>
t27: v8f32,ch = load t0, FrameIndex:i64<-5>,
undef:i64
  t26: i64 = FrameIndex<-5>
  t18: i64 = undef
t432: i8 = Constant<108>
t465: i8 = Constant<-58>
  t411: i64 = Constant<0>
In function: test

-- 
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 34575] New: __attribute__((__format__(printf()))) doesn't warn about NULL format string

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34575

Bug ID: 34575
   Summary: __attribute__((__format__(printf( doesn't warn
about NULL format string
   Product: clang
   Version: 5.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: shab...@gmail.com
CC: llvm-bugs@lists.llvm.org

Take this code:

#include 

int main()
{
  printf(NULL, "x");
  return 0;
}

gcc helpfully warns that:

: In function 'int main()':
5 : :5:19: warning: null argument where non-null required (argument
1) [-Wnonnull]
   printf(NULL, "x");
   ^
5 : :5:19: warning: too many arguments for format
[-Wformat-extra-args]

while clang doesn't say anything (it doesn't even warn about extra arguments).
It would be nice if it did.

-- 
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 34573] New: OPT crashes with custom pass

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34573

Bug ID: 34573
   Summary: OPT crashes with custom pass
   Product: tools
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: opt
  Assignee: unassignedb...@nondot.org
  Reporter: beryku...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19145
  --> https://bugs.llvm.org/attachment.cgi?id=19145=edit
module pass source code

Hello,

I'm trying to run a simple custom module pass that works fine in LLVM 3.8
through 4.0.1 but that crashes in LLVM 5.0.0.
Whether I run it through opt or load it in Clang, it crashes on a segfault.
I attached the source code of the pass.

The culprit lies in registering the pass using RegisterStandardPasses, if you
uncomment it, it should segfault in 5.0.0 (release).
If I leave it commented, it doesn't crash, but I need to use it to be able to
run the pass with clang using -Xclang -load, which works fine in LLVM 4.0.1 (I
don't know of any way how to run the pass with Clang without the
RegisterStandardPasses, it doesn't allow me to pass -tst as opt does).

This is how I compile the pass:
clang++ -std=c++14 -I/include -fno-rtti -shared -fPIC pass.cpp -o
libpass.so

and then I run it using either
clang++ -Xclang -load -Xclang ./libpass.so test.cpp
or
opt -load ./libpass.so -tst test.bc

Both of them crash.
The test.cpp file is a barebones cpp file with just int main() { return 0; }.

Was there any change in LLVM 5 pass usage that could cause this to fail?
I didn't find anything in the documentation.

-- 
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 34572] New: Failed to fetch http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty/main/source/Sources Unexpected type excepted 21 != 5

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34572

Bug ID: 34572
   Summary: Failed to fetch
http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty
/main/source/Sources  Unexpected type excepted 21 != 5
   Product: Packaging
   Version: unspecified
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: deb packages
  Assignee: unassignedb...@nondot.org
  Reporter: zosrot...@orange.fr
CC: llvm-bugs@lists.llvm.org

Hello

Running Tracis CI jobs on Ubuntu Trusty, one gets always the error below
E: Failed to fetch
http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty/main/source/Sources 
Unexpected type excepted 21 != 5

Here a snippet of the Travis job log

0K$ if [ "$TRAVIS_OS_NAME" == "linux" ]; then wget -O -
http://llvm.org/apt/llvm-snapshot.gpg.key|sudo apt-key add -; fi
--2017-09-12 10:23:23--  http://llvm.org/apt/llvm-snapshot.gpg.key
Resolving llvm.org (llvm.org)... 54.67.122.174
Connecting to llvm.org (llvm.org)|54.67.122.174|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://apt.llvm.org/llvm-snapshot.gpg.key [following]
--2017-09-12 10:23:24--  http://apt.llvm.org/llvm-snapshot.gpg.key
Resolving apt.llvm.org (apt.llvm.org)... 151.101.46.49
Connecting to apt.llvm.org (apt.llvm.org)|151.101.46.49|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3145 (3.1K) [application/pgp-keys]
Saving to: ‘STDOUT’


 0% [   ] 0   --.-K/s  
100%[==>] 3,145   --.-K/s   in 0s  

2017-09-12 10:23:24 (108 MB/s) - written to stdout [3145/3145]

OK

travis_time:end:21830670:start=1505211803806389543,finish=1505211804287925194,duration=481535651
0Ktravis_fold:end:before_install.10
0Ktravis_fold:start:before_install.11
0Ktravis_time:start:03f78ddc
0K$ if [ "$TRAVIS_OS_NAME" == "linux" ]; then sudo apt-get update  -qq; fi
W: http://dl.hhvm.com/ubuntu/dists/trusty/InRelease: Signature by key
36AEF64D0207E7EEE352D4875A16E7281BE7A449 uses weak digest algorithm (SHA1)
W: http://ppa.launchpad.net/couchdb/stable/ubuntu/dists/trusty/Release.gpg:
Signature by key 15866BAFD9BCC4F3C1E0DFC7D69548E1C17EAB57 uses weak digest
algorithm (SHA1)
E: Failed to fetch
http://apt.llvm.org/trusty/dists/llvm-toolchain-trusty/main/source/Sources 
Unexpected type excepted 21 != 5
E: Some index files failed to download. They have been ignored, or old ones
used instead.

travis_time:end:03f78ddc:start=1505211804292420317,finish=1505211807271148152,duration=2978727835
0K
The command "if [ "$TRAVIS_OS_NAME" == "linux" ]; then sudo apt-get update 
-qq; fi" failed and exited with 100 during .[0m

-- 
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 33723] Invalid compiler error: bug.cpp:38:88: error: 'Header' does not refer to a value

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=33723

zosrot...@orange.fr  changed:

   What|Removed |Added

 Status|REOPENED|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 34571] New: Missing mnemonic RDPID

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34571

Bug ID: 34571
   Summary: Missing mnemonic RDPID
   Product: libraries
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: kadircetinkaya.06...@gmail.com
CC: llvm-bugs@lists.llvm.org

RDPID RAX

cannot be assembled, fails with invalid instruction mnemonic 'rdpid' does not
exists. but as mentioned in July 2017 version of the Instruction Set Reference
page 1188. This mnemonic exists with following encoding specificaitons:

F3 0F C7 /7 - RDPID r32
F3 0F C7 /7 - RDPID r64

-- 
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 34570] New: Reparse leads to extra diagnostic and removes skipped ranges

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34570

Bug ID: 34570
   Summary: Reparse leads to extra diagnostic and removes skipped
ranges
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: libclang
  Assignee: unassignedclangb...@nondot.org
  Reporter: nikolai.kos...@qt.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org

The following code outlines the problems in the comments:

#ifdef MYCPLUSPLUS
extern "C" { // On parse this is skipped as expected. On reparse, this is
surprisingly not skipped anymore.
#endif

#ifdef MYCPLUSPLUS
}
#endif

int main()
{
return 0;
} // On reparse a diagnostic is added here: "expected '}' to match this '{'
(line 2)"

Here are some c-index-test invocations for this to make this
testable/reproducible ($FILE does not contain the above comments):

Do a parse and save the tokens:

% ./c-index-test -test-annotate-tokens=$FILE:1:1:7:1 $FILE > /tmp/1

No diagnostics are emitted as expected.

Do a parse and reparse and save also the tokens:

% CINDEXTEST_EDITING=1 ./c-index-test -test-annotate-tokens=$FILE:1:1:7:1
$FILE > /tmp/2
$FILE:12:2: error: expected '}'
Number FIX-ITs = 0
$FILE:2:12: note: to match this '{'
Number FIX-ITs = 0

Note that a new diagnostic is emitted on reparse at the bottom of the file
(issue1).
Also, the first skipped source range is not skipped anymore on reparse
(issue2):

% diff -u /tmp/{1,2}
--- /tmp/1  2017-09-12 09:33:42.210204021 +0200
+++ /tmp/2  2017-09-12 09:33:51.458334870 +0200
@@ -1,4 +1,3 @@
-Skipping: [1:2 - 3:7]
 Skipping: [5:2 - 7:7]
 Punctuation: "#" [1:1 - 1:2] preprocessing directive=
 Identifier: "ifdef" [1:2 - 1:7] preprocessing directive=

-- 
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 34568] New: Cannot encode LSL with REX.W prefix

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34568

Bug ID: 34568
   Summary: Cannot encode LSL with REX.W prefix
   Product: libraries
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: kadircetinkaya.06...@gmail.com
CC: llvm-bugs@lists.llvm.org

LSL RAX, EBX

cannot be assembled, but as mentioned in July 2017 version of the Instruction
Set Reference page 649 it is possible to encode this instruction with

REX.W + 0F 03 /r 
LSL r64, r32/m16* 
Load: r64 ← segment limit, selector r32/m16

this encoding specificaiton.

-- 
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 34547] Reparse with #ifdef leads to error "unterminated conditional directive"

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34547

ibiryu...@google.com 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 34550] Superregs are not automatically inferred into the callee saved regs list

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34550

Jonas Paulsson  changed:

   What|Removed |Added

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

--- Comment #4 from Jonas Paulsson  ---
Thanks Eli, adding that bit to the registers did the trick :-)

-- 
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 34564] Assertion failed: "ShrinkDemandedOp only supports nodes with one result!"

2017-09-12 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34564

Roger Ferrer Ibanez  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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 3358 in oss-fuzz: llvm: Stack-overflow in DiagnoseUninitializedReference

2017-09-12 Thread monor… via monorail via llvm-bugs 

Status: New
Owner: 
CC: k...@google.com,  masc...@google.com,  jdevlieg...@apple.com,   
llvm-b...@lists.llvm.org
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-09-12


New issue 3358 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm: Stack-overflow in DiagnoseUninitializedReference

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3358

Detailed report: https://oss-fuzz.com/testcase?key=6556730458636288

Project: llvm
Fuzzer: libFuzzer_llvm_clang-fuzzer
Fuzz target binary: clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffeea822ff8
Crash State:
  DiagnoseUninitializedReference

Sanitizer: address (ASAN)

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


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


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 have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs