[llvm-bugs] [Bug 18323] Clang++ 3.4 of Ubuntu 13.10 miscompiles simd_fast_mersenne_twister_engine of gcc 4.8.1
https://llvm.org/bugs/show_bug.cgi?id=18323 John Steele Scott changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from John Steele Scott --- Looks like this was fixed in r229065. The _mm_slli_si128 macro no longer declares an '__a' variable. -- 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 27236] New: Instcombine tries to create invalid IR
https://llvm.org/bugs/show_bug.cgi?id=27236
Bug ID: 27236
Summary: Instcombine tries to create invalid IR
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: an...@korobeynikov.info
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16174
--> https://llvm.org/bugs/attachment.cgi?id=16174&action=edit
Testcase
Consider the attached IR.
opt -instcombine -debug yields:
IC: Replacing %.sroa.4.0 = select i1 %4, float %3, float 0.00e+00
with %2 = select i1 %1, i32 1, i32 %0
Assertion failed: (New->getType() == getType() && "replaceAllUses of value with
new value of different type!"), function replaceAllUsesWith, file
/Users/asl/Projects/llvm/2commit/llvm/lib/IR/Value.cpp, line 375.
Which is certainly incorrect. I believe the problem was exposed by the recent
changes in min/max optimizations and min(min) / max(max) folding.
The "big hammer" fix is to have something like this:
Index: lib/Transforms/InstCombine/InstCombineSelect.cpp
===
--- lib/Transforms/InstCombine/InstCombineSelect.cpp(revision 265487)
+++ lib/Transforms/InstCombine/InstCombineSelect.cpp(working copy)
@@ -642,6 +642,9 @@
Value *A, Value *B,
Instruction &Outer,
SelectPatternFlavor SPF2, Value *C) {
+ if (Outer.getType() != Inner->getType())
+return nullptr;
+
if (C == A || C == B) {
// MAX(MAX(A, B), B) -> MAX(A, B)
// MIN(MIN(a, b), a) -> MIN(a, b)
However, I believe we need to make sure we never call stuff this way
--
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 27237] New: Cannot link lldb-server on a i386 system
https://llvm.org/bugs/show_bug.cgi?id=27237 Bug ID: 27237 Summary: Cannot link lldb-server on a i386 system Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: sylves...@debian.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Looks like we are using too much memory during the link for a i386 system : cd "/tmp/buildd/llvm-toolchain-snapshot-3.9~svn265476/build-llvm/tools/lldb/tools/lldb-server" && /tmp/cmake/bin/cmake -E cmake_symlink_executable ../../../../bin/lldb-server-3.9.0 ../../../../bin/lldb-server make[4]: Leaving directory `/tmp/buildd/llvm-toolchain-snapshot-3.9~svn265476/build-llvm' [ 98%] Built target lldb-server /usr/bin/ld: final link failed: Memory exhausted collect2: error: ld returned 1 exit status make[4]: *** [lib/liblldb-3.9.so.1] Error 1 -- 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 27238] New: Python API: Unable to detach a process in running state.
https://llvm.org/bugs/show_bug.cgi?id=27238 Bug ID: 27238 Summary: Python API: Unable to detach a process in running state. Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: alexis.kof...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The following code used to work before xcode 7.3 lldb-350.0.21.3. Now it seems that the process can't be detached anymore. There is no error, it just hangs when trying to detach and never execute the os._exit(0). Any thought ? safequit_command(debugger, command, result, internal_dict): process = lldb.target.process listener = debugger.GetListener() listener.StartListeningForEvents(process.GetBroadcaster(), lldb.SBProcess.eBroadcastBitStateChanged | lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR) event = lldb.SBEvent() while True: if listener.WaitForEvent(1, event) and lldb.SBProcess.EventIsProcessEvent(event): state = lldb.SBProcess.GetStateFromEvent(event) else: state = process.GetState() if state == lldb.eStateRunning: process.Detach() os._exit(0) elif state > lldb.eStateRunning: os._exit(state) -- 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 27239] New: apt cannot authenticate llvm-3.8 Ubuntu 12.04 packages
https://llvm.org/bugs/show_bug.cgi?id=27239 Bug ID: 27239 Summary: apt cannot authenticate llvm-3.8 Ubuntu 12.04 packages Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: l...@henning-thielemann.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified > $ sudo apt-get upgrade > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut > Statusinformationen werden eingelesen... Fertig > Die folgenden Pakete werden aktualisiert (Upgrade): > libllvm3.8 llvm-3.8 llvm-3.8-dev llvm-3.8-doc llvm-3.8-examples > llvm-3.8-runtime > 6 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert. > Es müssen 47,3 MB an Archiven heruntergeladen werden. > Nach dieser Operation werden 259 kB Plattenplatz freigegeben. > Möchten Sie fortfahren [J/n]? > WARNUNG: Die folgenden Pakete können nicht authentifiziert werden! > libllvm3.8 llvm-3.8-examples llvm-3.8-dev llvm-3.8 llvm-3.8-runtime > llvm-3.8-doc > Diese Pakete ohne Überprüfung installieren [j/N]? > E: Einige Pakete konnten nicht authentifiziert werden I have already added the key and it works this way on Ubuntu 14.04 but fails on Ubuntu 12.04. -- 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 27240] New: lld fails to link openssl
https://llvm.org/bugs/show_bug.cgi?id=27240
Bug ID: 27240
Summary: lld fails to link openssl
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: jbulow-l...@jongel.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Trying to build OpenSSL (1.0.1s) using lld as linker fails with:
> ./config
> make depend
> make
...
shlib_target=; if [ -n "" ]; then \
shlib_target="linux-shared"; \
elif [ -n "" ]; then \
FIPSLD_CC="clang"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o
crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o
app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o
pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o
srp.o" \
LIBDEPS=" $LIBRARIES -ldl" \
link_app.${shlib_target}
make[2]: Entering directory `/media/ssd/jonasbu/openssl/openssl-1.0.1s/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl}";
LDCMD="${LDCMD:-clang}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O3 -Wall -Qunused-arguments
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
-DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in
$LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo
$LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o
crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o
app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o
pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o
srp.o ${LIBDEPS} )
undefined symbol: EVP_idea_cbc in genrsa.o
undefined symbol: EVP_mdc2 in speed.o
undefined symbol: idea_cbc_encrypt in speed.o
undefined symbol: idea_options in speed.o
undefined symbol: idea_set_encrypt_key in speed.o
clang-3.9: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [link_app.] Error 1
make[2]: Leaving directory `/media/ssd/jonasbu/openssl/openssl-1.0.1s/apps'
make[1]: *** [openssl] Error 2
make[1]: Leaving directory `/media/ssd/jonasbu/openssl/openssl-1.0.1s/apps'
make: *** [build_apps] Error 1
It works fine with GNU ld.
--
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 27241] New: X86 call frame optimization should be generalized to support 64-bit targets
https://llvm.org/bugs/show_bug.cgi?id=27241
Bug ID: 27241
Summary: X86 call frame optimization should be generalized to
support 64-bit targets
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: david.l.kreit...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
On 64-bit Linux, we should use pushes to store outgoing arguments to the stack
just like we do for 32-bits (subject to profitability checks). For example, in
the calls to f2 below, the last 3 arguments could be passed via push.
t.ll
target triple = "x86_64-unknown-linux-gnu"
define void @f1() {
entry:
tail call void @f2(i32 42, i32 43, i32 44, i32 45, i32 46, i32 47, i32 48,
i32 49, i32 50)
ret void
}
declare void @f2(i32, i32, i32, i32, i32, i32, i32, i32, i32)
--
Like this:
t.s
f1: # @f1
.cfi_startproc
# BB#0: # %entry
pushq%rax
.Ltmp0:
.cfi_def_cfa_offset 16
subq$8, %rsp
.Ltmp1:
.cfi_adjust_cfa_offset 8
movl$42, %edi
movl$43, %esi
movl$44, %edx
movl$45, %ecx
movl$46, %r8d
movl$47, %r9d
pushq$50
.Ltmp2:
.cfi_adjust_cfa_offset 8
pushq$49
.Ltmp3:
.cfi_adjust_cfa_offset 8
pushq$48
.Ltmp4:
.cfi_adjust_cfa_offset 8
callqf2
addq$32, %rsp
.Ltmp5:
.cfi_adjust_cfa_offset -32
popq%rax
retq
-
--
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 27242] New: [PPC] Missing optimization opportunity for VMS loads
https://llvm.org/bugs/show_bug.cgi?id=27242 Bug ID: 27242 Summary: [PPC] Missing optimization opportunity for VMS loads Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ameh...@ca.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified With this patch http://reviews.llvm.org/D18562 the following testcase: test/CodeGen/PowerPC/unal-altivec.ll generates code with an extra VMX load. I believe (but has not yet confirmed) that VMX load and stores are not used frequently on processors after Power 7, so this should be low priority. -- 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 27221] member function of template instantiated even though only declaration is needed
https://llvm.org/bugs/show_bug.cgi?id=27221
David Blaikie changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC||dblai...@gmail.com
Resolution|--- |INVALID
--- Comment #4 from David Blaikie ---
(In reply to comment #3)
> Sorry, if I am a bit obnoxious about this. But I am having trouble with the
> given explanation:
>
> If I remove the definition of the move constructor, the code compiles and
> links just fine with every compiler I could get my hands on (gcc, clang,
> msvc).
>
> template
> struct X
> {
> X() = default;
>
> X(X&&);
> };
>
> auto impl() -> X
> {
> return {};
> }
>
> auto test() -> decltype(impl())
> {
> return impl();
> }
>
> int main()
> {
> test();
> }
>
>
> Thus, the implementation does not seem to be required.
It is required by the standard, but not by any specific implementation you've
found so far (& perhaps any implementation that exists).
> Thus, it is not deterministic whether or not this code can be compiled.
It is deterministic with the current compiler behavior - it checks that the
implementation is valid whether or not it chooses to use that implementation.
That makes it more deterministic than the behavior you're suggesting (where it
doesn't check the implementation unless it chooses to use it - so your code
could flap between compiling and not compiling depending on whether the
compiler chose to elide the copy or not)
This isn't a bug in the standard either, but quite intentional that the
standard describes a set of possible executions, not one specific one.
Implementations may provide anything within that set at any time.
For example: f(g(), h()); the standard does not require that g execute before
h, or that h execute before g. Just that one of those two things happens (g and
h cannot execute concurrently, for example). These things are built into the
standard quite intentionally to allow implementation choices that may be better
on a given platform, or may be sufficient to implement the language, but not
the most advanced behavior (eg: a simple compiler that does no RVO would be a
valid implementation - so the standard doesn't force the compiler to do RVO
heroics for it to meant the minimum bar for being a valid C++ compiler)
--
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 27243] New: lld -t doesn't print which archive members are used
https://llvm.org/bugs/show_bug.cgi?id=27243 Bug ID: 27243 Summary: lld -t doesn't print which archive members are used Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified With lld I get just lib/libLLVMSupport.a with gold I get lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/StringSaver.cpp.o) lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o) lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.c.o) -- 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 27244] New: clang C++ error passing an std::function to std::stable_sort with --std=c++14
https://llvm.org/bugs/show_bug.cgi?id=27244
Bug ID: 27244
Summary: clang C++ error passing an std::function to
std::stable_sort with --std=c++14
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: malcolm.pars...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang reports an error when compiling this code as C++14.
Clang reports no errors when compiling it as C++11.
GCC reports no errors for C++11 or C++14.
$ cat functiontest.cpp
#include
#include
#include
class Foo
{
};
void sortMyVector(std::vector& foos,
std::function fn)
{
std::stable_sort(begin(foos), end(foos), fn);
}
$ g++ --version
g++ (GCC) 5.3.0
...
$ clang++ --version
clang version 3.8.0 (tags/RELEASE_380/final)
...
$ g++ -c --std=c++11 functiontest.cpp
$ g++ -c --std=c++14 functiontest.cpp
$ clang++ -c --std=c++11 functiontest.cpp
$ clang++ -c --std=c++14 functiontest.cpp
In file included from functiontest.cpp:1:
In file included from
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/algorithm:61:
In file included from
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/stl_algobase.h:71:
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/predefined_ops.h:123:31:
error:
indirection requires pointer operand ('Foo' invalid)
{ return bool(_M_comp(*__it1, *__it2)); }
^~
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/functional:1981:27:
note: in
instantiation of function template specialization
'__gnu_cxx::__ops::_Iter_comp_iter
>::operator()' requested here
using _Invoke = decltype(__callable_functor(std::declval<_Functor&>())
^
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/functional:1990:2:
note: in
instantiation of template type alias '_Invoke' requested here
using _Callable
^
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/functional:2057:30:
note: in
instantiation of template type alias '_Callable' requested here
typename = _Requires<_Callable<_Functor>, void>>
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/functional:2058:2:
note: in
instantiation of default argument for
'function<__gnu_cxx::__ops::_Iter_comp_iter > >'
required here
function(_Functor);
^~~~
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/predefined_ops.h:130:14:
note:
while substituting deduced template arguments into function template
'function' [with _Functor =
__gnu_cxx::__ops::_Iter_comp_iter >, $1 = (no value)]
{ return _Iter_comp_iter<_Compare>(__comp); }
^
gcc-5.3.0/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/bits/stl_algo.h:4933:27:
note: in
instantiation of function template specialization
'__gnu_cxx::__ops::__iter_comp_iter >'
requested here
__gnu_cxx::__ops::__iter_comp_iter(__comp));
^
functiontest.cpp:12:10: note: in instantiation of function template
specialization 'std::stable_sort<__gnu_cxx::__normal_iterator > >, std::function >' requested here
std::stable_sort(begin(foos), end(foos), fn);
^
1 error generated
--
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 27245] New: x86 ASan tests hang after r265450
https://llvm.org/bugs/show_bug.cgi?id=27245 Bug ID: 27245 Summary: x86 ASan tests hang after r265450 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: ahmed.bouga...@gmail.com, llvm-bugs@lists.llvm.org Classification: Unclassified To reproduce, configure the build so the ASan run-time is built with the just-built Clang: $ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_BUILD_EXTERNAL_COMPILER_RT=ON .. $ ninja check-asan (hangs) -- 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 27246] New: r261346 causes this test case to fail
https://llvm.org/bugs/show_bug.cgi?id=27246
Bug ID: 27246
Summary: r261346 causes this test case to fail
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: kevin.b.sm...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Starting with r261346 the following test case will fail when compiled
with clang/llvm for intel64 linux.
cat >t1.cpp <
int main ()
{
unsigned int i = 4;
unsigned int k = 17;
unsigned int n = 60;
unsigned int e = 0;
for (i = 1; i < 49; i++)
{
for (k = i; k > 1; --k) {
e = k;
}
n = e;
}
if (n == 2)
printf("Passed\n");
else
printf("Failed\n");
return 0;
}
EOF
Compile using
clang -c -O2 t1.cpp
clang -o t1.exe t1.c
--
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 27247] New: ObjectFileELF should parse ".ARM" section headers to help determine the triple for ARM ELF files
https://llvm.org/bugs/show_bug.cgi?id=27247 Bug ID: 27247 Summary: ObjectFileELF should parse ".ARM" section headers to help determine the triple for ARM ELF files Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: clayb...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified There are some sections described in the ARM ELF spec that contain extra information that can help us to correctly determine the variant of ARM core in sections like ".ARM.attributes". This is described in the ARM ELF spec: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf in section 4.3.6 Build Attributes. Seems like there is some good stuff that we can use in this section. I am posting this in case anyone that uses ARM ELF files can get to this before I can fix it. -- 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 27248] New: [PATCH] Make mcount function names match gcc on arm and arm64 Linux
https://llvm.org/bugs/show_bug.cgi?id=27248 Bug ID: 27248 Summary: [PATCH] Make mcount function names match gcc on arm and arm64 Linux Product: clang Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: b...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16175 --> https://llvm.org/bugs/attachment.cgi?id=16175&action=edit Adjust mcount name to match gcc Currently, clang names the mcount function from -pg "_mcount" on PPC Linux and "mcount" on any other Linux. In gcc, this matches the behavior on PPC and x86 (both 32 and 64); but on aarch64 the function is called "_mcount" and on arm32 it's called "__gnu_mcount_nc". This mismatch in naming causes the Linux kernel to miscompile for arm (32 and 64) if CONFIG_FUNCTION_TRACER is enabled. The attached patch fixes this by matching the expected name of the mcount function. -- 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 26941] section / global name conflict: error in backend: symbol 'xxx' is already defined
https://llvm.org/bugs/show_bug.cgi?id=26941 Evgeniy Stepanov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Evgeniy Stepanov --- This was fixed in r264649. -- 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 27249] New: llvm-objdump --dwarf=frames printing wrong values
https://llvm.org/bugs/show_bug.cgi?id=27249 Bug ID: 27249 Summary: llvm-objdump --dwarf=frames printing wrong values Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16176 --> https://llvm.org/bugs/attachment.cgi?id=16176&action=edit test In the attached file llvm-objdump print 0018 0014 001c FDE cie=001c pc=0e18...0e19 ... 0030 0014 0034 FDE cie=0034 pc=0e02...0e04 ... 0048 0014 004c FDE cie=004c pc=0de9...0dea while the gnu one prints 0018 0014 001c FDE cie= pc=1000..1001 0030 0014 0034 FDE cie= pc=1002..1004 0048 0014 004c FDE cie= pc=1001..1002 The addresses in the second output are correct: [ 6] foo PROGBITS1000 001000 02 00 AX 0 0 1 [ 7] bar PROGBITS1002 001002 02 00 AX 0 0 1 -- 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 26841] [accepts-invalid] Member template inside a local class
https://llvm.org/bugs/show_bug.cgi?id=26841 Erik Pilkington changed: What|Removed |Added Status|NEW |RESOLVED CC||erik.pilking...@gmail.com Resolution|--- |FIXED --- Comment #1 from Erik Pilkington --- Fixed in r265571. Thanks for the report! -- 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 27248] [PATCH] Make mcount function names match gcc on arm and arm64 Linux
https://llvm.org/bugs/show_bug.cgi?id=27248 Renato Golin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Renato Golin --- *** This bug has been marked as a duplicate of bug 23969 *** -- 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 27186] Assertion failed: (DeclKind != Decl::LinkageSpec && "Should not perform lookups into linkage specs!")
https://llvm.org/bugs/show_bug.cgi?id=27186 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vassil Vassilev --- Fixed r265597 and r265599. -- 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 27235] lib/asan/tests/asan_test_main.cc is miscompiled by clang/llvm
https://llvm.org/bugs/show_bug.cgi?id=27235 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from H.J. Lu --- *** This bug has been marked as a duplicate of bug 27245 *** -- 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 27250] New: aarch64 inline assembly adds number as "#24" instead of plain "24" in the context of .set
https://llvm.org/bugs/show_bug.cgi?id=27250
Bug ID: 27250
Summary: aarch64 inline assembly adds number as "#24" instead
of plain "24" in the context of .set
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: b...@linaro.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This piece of inline assembly (extracted from the Linux kernel):
asm(".globl test; .set test, %0" :: "I"(24));
generates working code in gcc:
.globl test; .set test, 24
but clang generates invalid code:
.globl test; .set test, #24
Probably gcc checks for .set and friends before emitting the #.
--
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 27251] New: r261024 causes incorrect code for checkSum in this example
https://llvm.org/bugs/show_bug.cgi?id=27251 Bug ID: 27251 Summary: r261024 causes incorrect code for checkSum in this example Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: kevin.b.sm...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16177 --> https://llvm.org/bugs/attachment.cgi?id=16177&action=edit Simple reproducer To reproduce: clang -S -O2 simp.c clang -o simp.exe simp.s Good version (prior to r261024) prints 4294948211 incorrect version prints 19085 -- 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 27252] New: [ppc] missed vectorization of simple loop
https://llvm.org/bugs/show_bug.cgi?id=27252
Bug ID: 27252
Summary: [ppc] missed vectorization of simple loop
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 the following code with command line
~/llvm/obj3/bin/clang --target=powerpc64le-grtev4-linux-gnu -mvsx -mcpu=power8
-O2 -c t12.c -o t12.o
int foo(unsigned int* buf, unsigned int end, unsigned int endmask){
unsigned int* p;
int sum = 0;
for (p = buf; p < buf + end; ++p) {
sum += __builtin_popcount(*p);
}
return sum + __builtin_popcount(*p & endmask);
}
The simple loop is unrolled but not vectorized. If I change the last line to
return sum;
Then the loop can be vectorized.
--
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 27157] opt -O3 crashes with debug-only=loop-unroll
https://llvm.org/bugs/show_bug.cgi?id=27157 Michael Zolotukhin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Zolotukhin --- Should be fixed in r265605. -- 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 27254] New: LWG2577 incorrectly implemented
https://llvm.org/bugs/show_bug.cgi?id=27254 Bug ID: 27254 Summary: LWG2577 incorrectly implemented Product: libc++ Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: rs2...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified All the '__m_(addressof(__m))' calls need to be '__m_(_VSTD::addressof(__m))', to avoid picking up a different "addressof" via ADL. -- 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 27255] New: NULL-based pointer arithmetic generates ud2
https://llvm.org/bugs/show_bug.cgi?id=27255 Bug ID: 27255 Summary: NULL-based pointer arithmetic generates ud2 Product: clang Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: s...@list.ru CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16178 --> https://llvm.org/bugs/attachment.cgi?id=16178&action=edit a test case Attached is the test-case. $ gcc -m32 -Wall -O2 -o null null.c $ ./null 1 $ clang -m32 -Wall -O2 -o null null.c $ ./null Illegal instruction (core dumped) -- 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 27255] NULL-based pointer arithmetic generates ud2
https://llvm.org/bugs/show_bug.cgi?id=27255 Sean Silva changed: What|Removed |Added Status|NEW |RESOLVED CC||chisophu...@gmail.com Resolution|--- |INVALID --- Comment #1 from Sean Silva --- I believe this is UB: http://stackoverflow.com/a/17979772 `(unsigned char *)(uintptr_t)(a)` should work though. -- 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 27255] NULL-based pointer arithmetic generates ud2
https://llvm.org/bugs/show_bug.cgi?id=27255 Reid Kleckner changed: What|Removed |Added Status|RESOLVED|REOPENED CC||r...@google.com Resolution|INVALID |--- --- Comment #2 from Reid Kleckner --- So, doing pointer arithmetic off of null may be UB in C strictly speaking, but I think optimizing based on that at the LLVM level has soundness issues. I would expect the following LLVM transform to be semantics preserving, but you are saying it isn't: %0 = ptrtoint i8* %myptr, i64 %1 = add i64 0, i64 %0 %2 = inttoptr i64 %1, i8* %3 = load i8, i8* %2 => %0 = ptrtoint i8* %myptr, i64 %1 = getelementptr i8* null, i64 %0 %2 = load i8, i8* %1 Why should it matter to instcombine whether the valid pointer comes from the base or the index of the GEP? -- 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 27256] New: lldb doesn't support powerpc64 ELFv1 function descriptors
https://llvm.org/bugs/show_bug.cgi?id=27256 Bug ID: 27256 Summary: lldb doesn't support powerpc64 ELFv1 function descriptors Product: lldb Version: unspecified Hardware: Macintosh OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: chmeeed...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified LLDB is nearly complete for powerpc, but powerpc64 support needs function descriptors to get proper symbol tracking. PowerPC64 doesn't use normal function pointers in ELFv1 (big-endian, little endian now uses ELFv2, which does use normal function pointers), but instead uses function descriptors. LLDB can't quite parse this correctly, so disassembly doesn't work quite right. This is one of the last pieces needed for supporting powerpc64. -- 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 27257] New: Integer division expression not correctly evaluated
https://llvm.org/bugs/show_bug.cgi?id=27257
Bug ID: 27257
Summary: Integer division expression not correctly evaluated
Product: lldb
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: tgfb...@me.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16180
--> https://llvm.org/bugs/attachment.cgi?id=16180&action=edit
output with logging enabled.
In lldb bundled with Xcode 7.3 and Swift 2.2 Release for Ubuntu 14.04, integer
division expression is not correctly evaluated.
When debugging the following code:
$ cat /tmp/a.cpp
#include
int main() {
int b = 800;
printf("%d\n", b);
return 0;
}
$ clang -o /tmp/x -g /tmp/a.cpp
, integer division in expr is not evaluated correctly, while floating point
division seems to be good:
$ lldb /tmp/x
(lldb) target create "/tmp/x"
Current executable set to '/tmp/x' (x86_64).
(lldb) b 4
Breakpoint 1: where = x`main + 29 at a.cpp:4, address = 0x00010f6d
(lldb) run
Process 46865 launched: '/tmp/x' (x86_64)
Process 46865 stopped
* thread #1: tid = 0x5e9061, 0x00010f6d x`main + 29 at a.cpp:4, queue =
'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f6d x`main + 29 at a.cpp:4
1 #include
2 int main() {
3 int b = 800;
-> 4 printf("%d\n", b);
5 return 0;
6 }
(lldb) p b / 1
(int) $0 = 0
(lldb) p b / 2
(int) $1 = 0
(lldb) p b / 6
(int) $2 = 1
(lldb) p b / 13
(int) $3 = 1
(lldb) p b / 4.0
(double) $4 = 200
--
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 27245] x86 ASan tests hang after r265450
https://llvm.org/bugs/show_bug.cgi?id=27245 Ahmed Bougacha changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ahmed Bougacha --- Recommitted r265636. Hans, let me know if there's a bot I should be watching. -- 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 27258] New: clang crashes on valid code with vector_size attribute
https://llvm.org/bugs/show_bug.cgi?id=27258 Bug ID: 27258 Summary: clang crashes on valid code with vector_size attribute Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified The current clang trunk (as well 3.1.x and later) crashes when compiling the following test case on x86_64-linux-gnu in both 32-bit and 64-bit modes. $ clang++ -v clang version 3.9.0 (trunk 265520) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang++ -c small.cpp #0 0x01d66e05 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-3.9+0x1d66e05) #1 0x01d64d96 llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-3.9+0x1d64d96) #2 0x01d64fb4 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-3.9+0x1d64fb4) #3 0x7f3db6363340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x02b88879 clang::Sema::GetSignedVectorType(clang::QualType) (/usr/local/clang-trunk/bin/clang-3.9+0x2b88879) #5 0x02ba8013 clang::Sema::CheckVectorCompareOperands(clang::ActionResult&, clang::ActionResult&, clang::SourceLocation, bool) (/usr/local/clang-trunk/bin/clang-3.9+0x2ba8013) #6 0x02ba88c8 clang::Sema::CheckCompareOperands(clang::ActionResult&, clang::ActionResult&, clang::SourceLocation, clang::BinaryOperatorKind, bool) (/usr/local/clang-trunk/bin/clang-3.9+0x2ba88c8) #7 0x02bb2f33 clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) (/usr/local/clang-trunk/bin/clang-3.9+0x2bb2f33) #8 0x02bb3b8a clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) (/usr/local/clang-trunk/bin/clang-3.9+0x2bb3b8a) #9 0x02bb3eab clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) (/usr/local/clang-trunk/bin/clang-3.9+0x2bb3eab) #10 0x0284e3f5 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) (/usr/local/clang-trunk/bin/clang-3.9+0x284e3f5) #11 0x0284dcf9 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284dcf9) #12 0x0284dd69 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284dd69) #13 0x02852f95 clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, bool, clang::OpaquePtr&, clang::SourceLocation&) (/usr/local/clang-trunk/bin/clang-3.9+0x2852f95) #14 0x0284b5bc clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284b5bc) #15 0x0284dc5d clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284dc5d) #16 0x0284dce9 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284dce9) #17 0x0284e14c clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) (/usr/local/clang-trunk/bin/clang-3.9+0x284e14c) #18 0x0284dcf9 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284dcf9) #19 0x0284dd69 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x284dd69) #20 0x0288a906 clang::Parser::ParseExprStatement() (/us
[llvm-bugs] [Bug 27259] New: std::move_iterator::pointer type defined in a non-standard way
https://llvm.org/bugs/show_bug.cgi?id=27259
Bug ID: 27259
Summary: std::move_iterator::pointer type defined in a
non-standard way
Product: libc++
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ionelpopesc...@yahoo.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
Libc++ defines move_iterator::pointer like this:
typedef typename iterator_traits::pointer pointer;
According to the C++11 standard it should be defined like:
template
class _LIBCPP_TYPE_VIS_ONLY move_iterator
{
...
typedef Iterator pointer;
...
}
--
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 27261] New: wrong code at -O3 on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=27261
Bug ID: 27261
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the current clang trunk on
x86_64-linux-gnu at -O3 in both the 32-bit and 64-bit modes.
This is a regression from 3.8.x.
$ clang-trunk -v
clang version 3.9.0 (trunk 265520)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang-3.8 -O3 small.c; ./a.out
2
$ clang-trunk -O2 small.c; ./a.out
2
$
$ clang-trunk -O3 small.c; ./a.out
0
$
--
int printf (const char *, ...);
int a, b, c, d;
char e;
void
fn1 (int p1)
{
for (a = 1; a >= 0; a--)
{
e = p1;
for (;;)
{
for (c = 0; c < 1; c++)
{
d = a ? d / a : d;
for (; e < 2; e++)
p1 = 1;
if (p1)
break;
b = 1;
}
if (p1 >= 0)
break;
for (;;)
;
}
}
}
int
main ()
{
fn1 (0);
printf ("%d\n", e);
return 0;
}
--
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 27260] New: libc++ is missing std::vector static void swap(reference __x, reference __y) _NOEXCEPT
https://llvm.org/bugs/show_bug.cgi?id=27260
Bug ID: 27260
Summary: libc++ is missing std::vector static void
swap(reference __x, reference __y) _NOEXCEPT
Product: libc++
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ionelpopesc...@yahoo.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
This method is missing from vector class. It could be implemented as:
template
class _LIBCPP_TYPE_VIS_ONLY vector
: private __vector_base_common
{
...
static void swap(reference __x, reference __y) _NOEXCEPT
{
_VSTD::swap(__x, __y);
}
...
}
--
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
