From bugzilla-daemon at llvm.org Wed Feb 1 01:02:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 07:02:02 +0000
Subject: [LLVMbugs] [Bug 11900] [AVX] cannot select v4i32 =
X86ISD::VBROADCAST error
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11900
Craig Topper changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Craig Topper 2012-02-01 01:02:02 CST ---
Fixed in r149478. Though I may try to do better.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 03:48:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 09:48:35 +0000
Subject: [LLVMbugs] [Bug 11901] New: [cygwin] clang++ 3.0 silently ignores
C++ exception handling
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11901
Bug #: 11901
Summary: [cygwin] clang++ 3.0 silently ignores C++ exception
handling
Product: clang
Version: 3.0
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: C++
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: franke at computer.org
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Cygwin clang++ 3.0-1 does not produce any exception handling code. Unwind
tables and code within catch blocks are not generated. Throw always abort()s
program.
See testcase in original report on Cygwin mailing list:
http://cygwin.com/ml/cygwin/2012-01/msg00490.html
Package maintainer suggested to send this upstream:
http://cygwin.com/ml/cygwin/2012-02/msg00000.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 04:02:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 10:02:16 +0000
Subject: [LLVMbugs] [Bug 11901] [cygwin] clang++ 3.0 silently ignores C++
exception handling
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11901
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |asl at math.spbu.ru
Resolution| |DUPLICATE
--- Comment #1 from Anton Korobeynikov 2012-02-01 04:02:16 CST ---
*** This bug has been marked as a duplicate of bug 11285 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 04:34:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 10:34:24 +0000
Subject: [LLVMbugs] [Bug 11902] New: Scheduler produces bogus machine code
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11902
Bug #: 11902
Summary: Scheduler produces bogus machine code
Product: libraries
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
AssignedTo: unassignedbugs at nondot.org
ReportedBy: asl at math.spbu.ru
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 7980
--> http://llvm.org/bugs/attachment.cgi?id=7980
Testcase
Consider the attached .ll file.
If one will feed it to llc -arm-enable-ehabi then one will see that the .vsave
entry contains spurious s18 register added to the register list. This is
because post-ra scheduler adds bogus s18 impdef operand to VSTMDDB_UPD. Adding
-disable-post-ra fixes this problem.
I can surely ignore imp-def operands in the ARM unwinding stuff emitter. But I
think this is a symptom of some bug inside the scheduler or some passes around
(I must admit, I have another testcase which is fails w/o -disable-post-ra and
passes otherwise, but I failed to reduce it yet since it's several KLOCs of
heavy vector NEON code).
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 14:26:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 20:26:31 +0000
Subject: [LLVMbugs] [Bug 11903] New: make install failed Config/config.h No
such file or directory
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11903
Bug #: 11903
Summary: make install failed Config/config.h No such file or
directory
Product: Build scripts
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Makefiles
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bkirby at mips.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
I just built LLVM and clang against trunk. When I run make install, it fails
with:
llvm[4]: Making install directory
/scratch/bb-slaves/mipssw004/LLVM_optimize_install/install/include/clang/Frontend
/usr/bin/install: cannot create regular file
`/scratch/bb-slaves/mipssw004/LLVM_optimize_install/install/include/clang/Config/config.h':
No such file or directory
make[4]: *** [install-local] Error 1
make[4]: Leaving directory
`/scratch/bb-slaves/mipssw004/LLVM_optimize_install/build/tools/clang/include/clang'
make[3]: *** [install] Error 1
make[3]: Leaving directory
`/scratch/bb-slaves/mipssw004/LLVM_optimize_install/build/tools/clang/include'
make[2]: *** [install] Error 1
make[2]: Leaving directory
`/scratch/bb-slaves/mipssw004/LLVM_optimize_install/build/tools/clang'
make[1]: *** [clang/.makeinstall] Error 2
make[1]: Leaving directory
`/scratch/bb-slaves/mipssw004/LLVM_optimize_install/build/tools'
make: *** [install] Error 1
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 16:24:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 22:24:15 +0000
Subject: [LLVMbugs] [Bug 11903] make install failed Config/config.h No such
file or directory
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11903
nobled at dreamwidth.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from nobled at dreamwidth.org 2012-02-01 16:24:15 CST ---
I tested it; r149551 fixes it for me.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 17:43:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 Feb 2012 23:43:11 +0000
Subject: [LLVMbugs] [Bug 11822] Clang doesn't check that "#pragma GCC
visibility push" and "pragma GCC visibility pop" are matched
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11822
Rafael ?vila de Esp?ndola changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Rafael ?vila de Esp?ndola 2012-02-01 17:43:11 CST ---
Fixed in r149559.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Wed Feb 1 18:49:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 00:49:39 +0000
Subject: [LLVMbugs] [Bug 11904] New: Ordered FP compare converted to
unordered compares on X86
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11904
Bug #: 11904
Summary: Ordered FP compare converted to unordered compares on
X86
Product: new-bugs
Version: 2.9
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: jjones at transcella.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 7982
--> http://llvm.org/bugs/attachment.cgi?id=7982
IR source file with fcmp olt
Given the IR source file o2.ll,, llc produces o2.s. In the input, an
fcmp olt
is turned into an unordered compare in the output x86 code:
ucomiss
when using "llc o2.bc".
If either argument to the fcmp olt is a QNaN, then the semantics of
the original IR aren't explicitly stated by the LVM Language Reference Manual.
I would assume that the intent is to mimic IEEE floating point. There, a
comparison predicate that isn't equality or inequality (as is the olt here)
should signal if they receive a NaN operand of either type. Thus, fcmp olt
should always fault if given 1 or more QNaNs as operands.
However, the ucomiss instruction, as defined in the "Intel? 64 and IA-32
Architectures Software Developer?s Manual Volume 2B:Instruction Set Reference,
N-Z" states
The UCOMISS instruction differs from the COMISS instruction in that
it signals a SIMD floating-point invalid operation exception (#I)
only when a source operand is an SNaN.
Thus, llc produces a transformation that turns a program that always
signals when receiving QNaN into one that will not. Instead, a "comiss"
instruction should be generated.
After examination, a partial solution is to modify the code in
ISD::CondCode ISD::getSetCCInverse (lib\CodeGen\SelectionDAG\SelectionDAG.cpp
from:
if (isInteger)
Operation ^= 7; // Flip L, G, E bits, but not U.
else
Operation ^= 15; // Flip all of the condition bits.
to just
Operation ^= 7; // Flip L, G, E bits, but not U.
However, this does not appear to be sufficient, as the transformation
still occurs. The issue seems to be in:
SelectionDAGISel::MorphNode(lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp)
with the line:
SDNode *Res = CurDAG->MorphNodeTo(Node, ~TargetOpc, VTList, Ops, NumOps);
where all the bits of TargetOpc are inverted. This line is executed for more
than compares and the like, so it isn't clear what further changes are needed.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 02:02:56 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 08:02:56 +0000
Subject: [LLVMbugs] [Bug 11868] Assertion with -verify-coalescing
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11868
Lang Hames changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 05:56:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 11:56:35 +0000
Subject: [LLVMbugs] [Bug 11904] Ordered FP compare converted to unordered
compares on X86
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11904
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |sharparrow1 at yahoo.com
Resolution| |DUPLICATE
--- Comment #2 from Eli Friedman 2012-02-02 05:56:35 CST ---
If there is an issue here, it's a small part of a much more general issue...
*** This bug has been marked as a duplicate of bug 6050 ***
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 06:57:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 12:57:58 +0000
Subject: [LLVMbugs] [Bug 11905] New: struct{bool} -> int function argument
coercion emits an invalid store on ARM
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11905
Bug #: 11905
Summary: struct{bool} -> int function argument coercion emits
an invalid store on ARM
Product: clang
Version: trunk
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: eugeni.stepanov at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
# cat 1.cc
struct S {
bool qq;
};
bool f(S a) {
return a.qq;
}
# clang++ -target arm-linux-gnueabi 1.cc -O0 -S -emit-llvm -o 1.ll
# cat 1.ll
; ModuleID = '1.cc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32-S64"
target triple = "armv4t--linux-gnueabi"
%struct.S = type { i8 }
define zeroext i1 @_Z1f1S([1 x i32] %a.coerce0) nounwind {
entry:
%a = alloca %struct.S, align 4
%0 = bitcast %struct.S* %a to { [1 x i32] }*
%1 = getelementptr { [1 x i32] }* %0, i32 0, i32 0
store [1 x i32] %a.coerce0, [1 x i32]* %1
%qq = getelementptr inbounds %struct.S* %a, i32 0, i32 0
%2 = load i8* %qq, align 1
%tobool = trunc i8 %2 to i1
ret i1 %tobool
}
Store at the fourth line of the function copies 4-byte %a.coerce0 into 1-byte
%a.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 07:09:36 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 13:09:36 +0000
Subject: [LLVMbugs] [Bug 11906] New: dragonegg-trunk/gcc-4.6.2 fails to
build blender
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11906
Bug #: 11906
Summary: dragonegg-trunk/gcc-4.6.2 fails to build blender
Product: dragonegg
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: New Bugs
AssignedTo: baldrick at free.fr
ReportedBy: danielpgb_vasquez at hotmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Hello dragonegg developpers!
I'm trying to build Blender with dragonegg optimizers. I have succeeded by
disabling some modules that didn't build (there is a slight speed up in
rendering, which is nice). However, I'd like to build the disabled modules and
have run into problems. I'm using fedora 16 32 bits, dragonegg and llvm from
trunk.
Checking out current blender trunk:
svn checkout https://svn.blender.org/svnroot/bf-blender/trunk
Configure with ccmake:
- add dragonegg.so to the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS)
- release optimization is O4
- toggle WITH_LIBMV to ON
- configure and generate
Build:
$> make extern_libmv
...
[ 66%] Building CXX object
extern/libmv/CMakeFiles/extern_libmv.dir/third_party/glog/src/signalhandler.cc.o
cc1plus: /home/da/Devel/llvm/dragonegg/dragonegg/src/Convert.cpp:2629: virtual
void
{anonymous}::FunctionCallArgumentConversion::HandleScalarArgument(llvm::Type*,
tree, unsigned int): Assertion `type && "Inconsistent parameter types?"'
failed.
c++: internal compiler error: Aborted (program cc1plus)
The error is located in file
${blenderroot}/extern/libmv/third_party/glog/src/signalhandler.cc at line 340:
CHECK_ERR(sigaction(kFailureSignals[i].number, &sig_action, NULL));
As I said, I can disable this module and Blender remains usable and gains some
speed. However, adding -fplugin-arg-dragonegg-enable-gcc-optzns to the flags
makes the compiler fail on core files.
$> make bf_blenkernel
[ 50%] Building C object
source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/key.c.o
cc1: /home/da/Devel/llvm/dragonegg/dragonegg/src/Convert.cpp:7892: llvm::Value*
TreeToLLVM::EmitAssignRHS(gimple): Assertion `RHS->getType() ==
getRegType(((gimple_assign_rhs1(stmt))->common.type)) && "RHS has wrong type!"'
failed.
gcc: internal compiler error: Aborted (program cc1)
I tracked down the errors to while statements whose condition made the compiler
fail: In ${blenderroot}/source/blender/blenkernel/intern/key.c, the cp_key,
do_rel_key and do_key functions each contain a "while( cp[0] )" statement that
triggers the error. Replacing cp[0] by 1 or 0 makes it compile.
Hmmm, just noticed I have -mtune enabled too. I can try to reduce the test case
if needed.
Daniel
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 07:55:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 13:55:14 +0000
Subject: [LLVMbugs] [Bug 11907] New: GCC's '-dumpbase' commandline argument
not treated/ignored correctly
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11907
Bug #: 11907
Summary: GCC's '-dumpbase' commandline argument not
treated/ignored correctly
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: thebeing+llvm at halbordnung.de
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Hi,
I encountered a little problem recently when I tried to replace gcc with clang
in an external tool I unfortunately don't have control over (qcc from QNX, a
wrapper around the compiler you want their build system to use) which didn't
work due to clang aborting with a 'cannot specify -o when generating multiple
output files' error. I could narrow down the problem to the fact that apart
from '-o' qcc also adds a '-dumpbase' argument to the cc1 command line. So the
following works fine with gcc:
cc -S -dumpbase test.c -o test.s test.c
While the following
clang -v -cc1 -S -dumpbase test.c -o test.s test.c
aborts with 'clang: error: cannot specify -o when generating multiple output
files' (test.c is just "int main() {return 0;}")
If I remove the '-S' switch, I instead get a linker error:
/tmp/user/5001/test-dovJ2O.o: In function `main':
test.c:(.text+0x0): multiple definition of `main'
/tmp/user/5001/test-UzyGh5.o:test.c:(.text+0x0): first defined here
I thus speculate that clang (at r149605) is only ignoring '-dumpbase' and
treating the filename afterwards as a second file to compile. I'm not sure
whether the '-dumpbase'-functionality is actually worth supporting. (If I
understood it correctly it only replaces the actual source filename with the
one specified after -dumpbase in diagnostics) But it would be great if it could
at least be ignored in a way that clang can still be used as a drop-in
replacement to gcc even if '-dumpbase' is present on the commandline.
Many thanks,
Niels
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 10:35:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 16:35:29 +0000
Subject: [LLVMbugs] [Bug 11908] New: DFAEmitter in TableGen doesn't handle
sentinel transition row properly
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11908
Bug #: 11908
Summary: DFAEmitter in TableGen doesn't handle sentinel
transition row properly
Product: new-bugs
Version: trunk
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bcahoon at codeaurora.org
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
When the DFAPacketizerEmitter code is generating the DFAStateEntryTable from a
target's .td file, the code is not handling the sentinel transition state
properly and generates incorrect index values for the states that occurs after
the sentinel state. I think only the Hexagon target is affected by this bug.
For example, here's the incorrect entry table.
const unsigned int HexagonDFAStateEntryTable[] = {
0, 7, 13, 19, 25, 31, 38, 45, 52, 58, 62, 68, 75, 82, 86, 90, 97, 97, 103,
109,\
112, 115, 119, 125, 131, 138, 144, 150, 153, 156, 162, 168, 174, 180, 187,
192\
, 197, 202, 207, 212, 217, 222,
};
There are two entries numbered '97'. This represents the sentinel transition
state in the DFAStateInputTable. The second entry needs to be '98' in this
case.
Here's the code in DFAPacketizerEmitter.cpp:
// If there are no valid transitions from this stage, we need a sentinel
// transition.
if (ValidTransitions == StateEntry[i])
OS << "{-1, -1},";
Although the sentinel state is not valid, we still need to increment
ValidTransitions since that is the index into the DFAStateInputTable.
I have a simple fix for the bug, which I'm going to sent to the commits mailing
list.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 14:16:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 20:16:52 +0000
Subject: [LLVMbugs] [Bug 11909] New: Incorrect error generated for a valid
case
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11909
Bug #: 11909
Summary: Incorrect error generated for a valid case
Product: clang
Version: 3.0
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: Headers
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: christopher at lord.ac
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Just looked into this in our compiler, and noticed clang suffers the same
problem:
# clang -v
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix
The following case:
#include
using namespace std;
int main() {
valarray y0(4, 3);
valarray res(2 == y0);
return 0;
}
fails with error:
# clang t.cpp
In file included from t.cpp:1:
/usr/include/c++/4.2.1/valarray:1027:1: error: no viable conversion from
'_Expr<_Closure, int>' to
'_Expr<_BinClos,
typename __fun<__equal_to,
int>::result_type>'
_DEFINE_BINARY_OPERATOR(==, __equal_to)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/4.2.1/valarray:1012:14: note: instantiated from:
return _Expr<_Closure, _Tp>(_Closure(__t, __v)); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.cpp:5:25: note: in instantiation of function template specialization
'std::operator==' requested
here
valarray res(2 == y0);
^
/usr/include/c++/4.2.1/bits/valarray_after.h:164:11: note: candidate
constructor
(the implicit copy constructor) not viable: no known conversion from
'_Expr<_Closure, int>' to 'const
std::_Expr, bool> &' for 1st argument
class _Expr
^
/usr/include/c++/4.2.1/bits/valarray_after.h:169:7: note: candidate
constructor not viable: no known
conversion from '_Expr<_Closure, int>' to 'const
std::_BinClos &' for 1st argument
_Expr(const _Clos&);
^
reversing the arguments of operator==() makes the case pass.
#include
using namespace std;
int main() {
valarray y0(4, 3);
valarray res(y0 == 2); // ok!
return 0;
}
Opening against headers since that's where it went in our case.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 14:46:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 20:46:25 +0000
Subject: [LLVMbugs] [Bug 11910] New: Storage-class extern inside function
body on tentatively static symbols breaks later definitions
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11910
Bug #: 11910
Summary: Storage-class extern inside function body on
tentatively static symbols breaks later definitions
Product: clang
Version: 3.0
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Frontend
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: snaury at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
When a symbol is tentatively defined static, and later inside a function is is
declared extern, then it later confuses clang about its linkage. For example:
static int var;
int func() {
extern int var;
return var;
}
static int var = 0; /* static declaration of 'var' follows non-static
declaration */
The error message is wrong, because var is still tentatively static. Even more:
static int var;
int func() {
extern int var;
return var;
}
int var = 0;
The above example compiles, when it should actually give an error "non-static
declaration of 'var' follows static declaration". Compiling with -S shows that
linkage was somehow changed to external. However:
static int var;
int func() {
extern int var;
return var;
}
The above example compiles fine, however compiling with -S shows that linkage
of var is kept internal. It looks like extern in function body doesn't change
symbol linkage by itself, but something about previous declarations clearly
becomes changed/forgotten.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 14:49:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 20:49:46 +0000
Subject: [LLVMbugs] [Bug 11428] errc,
io_errc and future_errc constants should really be scoped enums
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11428
Howard Hinnant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #8 from Howard Hinnant 2012-02-02 14:49:46 CST ---
Fix Committed revision 149630.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 15:40:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 21:40:11 +0000
Subject: [LLVMbugs] [Bug 11909] Incorrect error generated for a valid
case
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11909
Eli Friedman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hhinnant at apple.com,
| |sharparrow1 at yahoo.com
Resolution| |INVALID
--- Comment #1 from Eli Friedman 2012-02-02 15:40:11 CST ---
As far as I can tell, clang is doing the right thing here. And the given
testcase correctly compiles if libc++ is used. The only bug is in the version
of libstdc++ distributed with OSX, and that isn't part of the LLVM project.
In general, please report issues with the OSX developer tools at
bugreporter.apple.com.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 16:40:36 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 02 Feb 2012 22:40:36 +0000
Subject: [LLVMbugs] [Bug 11911] New: gmp 5.0.3 on x86_64 Linux compiled with
clang in 32-bit mode fails checks due to bug in clang assembler
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11911
Bug #: 11911
Summary: gmp 5.0.3 on x86_64 Linux compiled with clang in
32-bit mode fails checks due to bug in clang assembler
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: neunhoef at mcs.st-and.ac.uk
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 7987
--> http://llvm.org/bugs/attachment.cgi?id=7987
Result of m4 translated assembler source, this is fed into clang.
I work on Ubuntu Linux 11.04 on x86_64, I have used both clang 3.0 and clang
svn-head to compile gmp-5.0.3 from
ftp://ftp.gmplib.org/pub/gmp-5.0.3/gmp-5.0.3.tar.bz2
in the following way:
tar xjvf gmp-5.0.3.tar.bz2
cd gmp-5.0.3
./configure ABI=32 CC=clang CFLAGS="-m32"
make
make check
The result is that the checks tests/mpz/t-hamdist and tests/mpz/t-popcount fail
with segfaults.
I traced it down to the following problem:
The critical function is __gmpn_popcount, which is coded in assembler for x86.
The original source (for the CPU "Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz"
I am using) is in
gmp-5.0.3/mpn/x86/pentium4/sse2/popcount.asm
which is first translated by the m4 macro processor to the file
tmp-popcount.s
which I attach to this bug report. This is then (for building the shared
library libgmp.so) in turn assembled by clang by the following command:
clang -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
-DOPERATION_popcount -m32 -O0 -g -Wa,--noexecstack tmp-popcount.s
-fPIC -DPIC -o .libs/popcount.o
Note in particular the -fPIC! The two following assembler lines (close to the
top of the attaced file) are then processed in a way such that the access to
the data table with label "cnsts" in the .rodata section (same source file)
does not work and indeed produces the segfault in the end:
addl $_GLOBAL_OFFSET_TABLE_, %ebx
movl cnsts at GOT(%ebx), %ebx
I do not understand the full details of the PIC-business for shared libraries
but it seems that the global offset table is not properly accessed by the code
produced.
Note that if I compare the outputs of clang and gcc on this assembler source
the single difference is the offset in the movl command. The file assembled by
gcc works, even if I compile the complete rest of gmp with clang. The problem
seems to occur only when using the shared library libgmp.so and not with static
linking.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 18:23:33 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 00:23:33 +0000
Subject: [LLVMbugs] [Bug 11912] New: Segmentation fault in
clang::CFG::buildCFG
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11912
Bug #: 11912
Summary: Segmentation fault in clang::CFG::buildCFG
Product: clang
Version: 3.0
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: nerijus at users.sourceforge.net
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 7988
--> http://llvm.org/bugs/attachment.cgi?id=7988
Preprocessed source
Compiling wxWidgets svn head (CC=clang CXX=clang++ ../wxWidgets/configure
--enable-debug --with-gtk; make) segfaults:
0 libLLVM-3.0.so 0xb66c4159
1 libLLVM-3.0.so 0xb66c4814
2 0xb7782400 __kernel_sigreturn + 0
3 clang 0x088bffe6
4 clang 0x088c0d8b
5 clang 0x088c38d0
6 clang 0x088c16c3
7 clang 0x088c1ea6
8 clang 0x088c390a
9 clang 0x088c16c3
10 clang 0x088c407c clang::CFG::buildCFG(clang::Decl const*,
clang::Stmt*, clang::ASTContext*, clang::CFG::BuildOptions const&) + 700
11 clang 0x088b87ed clang::AnalysisContext::getCFG() + 109
12 clang 0x0875f934
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::BlockExpr const*) +
1412
13 clang 0x084d94c8
clang::Sema::PopFunctionOrBlockScope(clang::sema::AnalysisBasedWarnings::Policy
const*, clang::Decl const*, clang::BlockExpr const*) + 200
14 clang 0x08557275 clang::Sema::ActOnFinishFunctionBody(clang::Decl*,
clang::Stmt*, bool) + 325
15 clang 0x085577a4 clang::Sema::ActOnFinishFunctionBody(clang::Decl*,
clang::Stmt*) + 52
16 clang 0x08466e07
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 215
17 clang 0x08483654
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 948
18 clang 0x08492f9e
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 606
19 clang 0x0847e0d9
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 217
20 clang 0x0847e7c7
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 615
21 clang 0x08480849
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2905
22 clang 0x08480ed5
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) +
18123 clang 0x084546fc clang::ParseAST(clang::Sema&, bool) + 300
24 clang 0x082243a8 clang::ASTFrontendAction::ExecuteAction() + 104
25 clang 0x083211e3 clang::CodeGenAction::ExecuteAction() + 67
26 clang 0x08224d83 clang::FrontendAction::Execute() + 275
27 clang 0x08207a25
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 325
28 clang 0x081edcec
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1052
29 clang 0x081e50ae cc1_main(char const**, char const**, char const*,
void*) + 814
30 clang 0x081e2425 main + 693
31 libc.so.6 0x4a1d96b3 __libc_start_main + 243
32 clang 0x081e4c01
Stack dump:
0. Program arguments: /usr/bin/clang -cc1 -triple i386-redhat-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
filectrl.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -g
-coverage-file coredll_filectrl.o -resource-dir /usr/bin/../lib/clang/3.0
-dependency-file coredll_filectrl.d -MT coredll_filectrl.o -D __WXGTK__ -D
WXBUILDING -D WXUSINGDLL -D WXMAKINGDLL_CORE -D wxUSE_BASE=0 -D PIC -D
_FILE_OFFSET_BITS=64 -D WX_PRECOMP -I ./.pch/wxprec_coredll -I
../wxWidgets/src/regex -I
/a/M/wxWindows.29/build.gtk2.clang/lib/wx/include/gtk2-unicode-2.9 -I
../wxWidgets/include -I /usr/include/gtk-2.0 -I /usr/lib/gtk-2.0/include -I
/usr/include/atk-1.0 -I /usr/include/cairo -I /usr/include/gdk-pixbuf-2.0 -I
/usr/include/pango-1.0 -I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include -I
/usr/include/pixman-1 -I /usr/include/freetype2 -I /usr/include/libpng12 -I
/usr/include/gstreamer-0.10 -I /usr/include/glib-2.0 -I
/usr/lib/glib-2.0/include -I /usr/include/libxml2 -I /usr/include/libsoup-2.4
-I /usr/include/webkit-1.0 -I /usr/include/libgnomeprintui-2.2 -I
/usr/include/libgnomeprint-2.2 -I /usr/include/libgnomecanvas-2.0 -I
/usr/include/libart-2.0 -I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include
-I /usr/include/libxml2 -I /usr/include/pango-1.0 -I /usr/include/gail-1.0 -I
/usr/include/gtk-2.0 -I /usr/include/freetype2 -I /usr/include/atk-1.0 -I
/usr/lib/gtk-2.0/include -I /usr/include/cairo -I /usr/include/gdk-pixbuf-2.0
-I /usr/include/pixman-1 -I /usr/include/libpng12 -I
/usr/include/gtk-unix-print-2.0 -I /usr/include/gtk-2.0 -I /usr/include/atk-1.0
-I /usr/include/cairo -I /usr/include/gdk-pixbuf-2.0 -I /usr/include/pango-1.0
-I /usr/lib/gtk-2.0/include -I /usr/include/glib-2.0 -I
/usr/lib/glib-2.0/include -I /usr/include/pixman-1 -I /usr/include/freetype2 -I
/usr/include/libpng12 -fmodule-cache-path /var/tmp/clang-module-cache
-internal-isystem
/usr/bin/../lib/gcc/i686-redhat-linux/4.6.2/../../../../include/c++/4.6.2
-internal-isystem
/usr/bin/../lib/gcc/i686-redhat-linux/4.6.2/../../../../include/c++/4.6.2/i686-redhat-linux
-internal-isystem
/usr/bin/../lib/gcc/i686-redhat-linux/4.6.2/../../../../include/c++/4.6.2/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include -O0
-Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual
-fdeprecated-macro -ferror-limit 19 -fmessage-length 107 -pthread -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
coredll_filectrl.o -x c++ ../wxWidgets/src/gtk/filectrl.cpp
1. ../wxWidgets/src/gtk/filectrl.cpp:171:1: current parser token 'void'
2. ../wxWidgets/src/gtk/filectrl.cpp:111:1: parsing function body
'SetWildcard'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/filectrl-6cZeXT.ii
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 19:12:38 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 01:12:38 +0000
Subject: [LLVMbugs] [Bug 11913] New: error in backend: Cannot select:
0x9fcdbe8: f80 = ConstantFP [ID=12]
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11913
Bug #: 11913
Summary: error in backend: Cannot select: 0x9fcdbe8: f80 =
ConstantFP [ID=12]
Product: clang
Version: 2.9
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: tydeman at tybor.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
The full error message in the listing is:
APInt(80b, 302240678275694148452352u 302240678275694148452352s)fatal error:
error in backend: Cannot select: 0x9fcdbe8: f80 = ConstantFP [ID=12]
I believe it is involved with floating-point, _Bool, and *= operator.
This is C99 code being compiled with 2.9-6
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 19:59:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 01:59:05 +0000
Subject: [LLVMbugs] [Bug 11914] New: llvm/clang bootstrap powerpc-darwin8
dies during codegen
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11914
Bug #: 11914
Summary: llvm/clang bootstrap powerpc-darwin8 dies during
codegen
Product: new-bugs
Version: 3.0
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: fang at csl.cornell.edu
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
I'm attempting to bootstrap clang-3.0 on powerpc-darwin8.
Stage 1 built with g++-4.0.1 ok, a few test failures with details found at:
http://www.csl.cornell.edu/~fang/sw/llvm/logs/llvm-clang-release-3.0-patched-1-powerpc-darwin8-g++-4.0.1-fink-build-log.txt
(+ .bz2 for compressed)
at stage 2, building with stage-1-built clang:
[ 1%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o
cd /sw/src/fink.build/llvm30-3.0-0.3/build/stage2/lib/Support &&
/sw/src/fink.build/llvm30-3.0-0.3/opt-bin/cc-st1-clang++
-DLLVMSupport_EXPORTS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -fno-common -fPIC -O3 -DNDEBUG -fPIC
-I/sw/src/fink.build/llvm30-3.0-0.3/build/stage2/lib/Support
-I/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/lib/Support
-I/sw/src/fink.build/llvm30-3.0-0.3/build/stage2/include
-I/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/include -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fno-exceptions
-o CMakeFiles/LLVMSupport.dir/APFloat.cpp.o -c
/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/lib/Support/APFloat.cpp
Stack dump:
0. Program arguments:
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.3/build/stage1/bin/clang-3.0
-cc1 -triple powerpc-apple-darwin8.11.0 -S -disable-free -disable-llvm-verifier
-main-file-name APFloat.cpp -pic-level 2 -mdisable-fp-elim -coverage-file
/tmp/APFloat-0oHd2f.s -resource-dir
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.3/build/stage1/bin/../lib/clang/3.0
-D LLVMSupport_EXPORTS -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D
__STDC_LIMIT_MACROS -D NDEBUG -I
/sw/src/fink.build/llvm30-3.0-0.3/build/stage2/lib/Support -I
/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/lib/Support -I
/sw/src/fink.build/llvm30-3.0-0.3/build/stage2/include -I
/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/include -fmodule-cache-path
/var/tmp/clang-module-cache -O3 -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wno-long-long -pedantic -fconst-strings -fdeprecated-macro -fno-dwarf2-cfi-asm
-ferror-limit 19 -fmessage-length 80 -fobjc-fragile-abi -fno-common
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/APFloat-0oHd2f.s -x c++
/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/lib/Support/APFloat.cpp
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module
'/sw/src/fink.build/llvm30-3.0-0.3/llvm-3.0.src/lib/Support/APFloat.cpp'.
4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on
function
'@_ZN4llvm7APFloat28convertFromHexadecimalStringENS_9StringRefENS0_12roundingModeE'
clang-3: error: unable to execute command: Bus error
clang-3: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang-3: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang-3: note: diagnostic msg: Preprocessed source(s) are located at:
clang-3: note: diagnostic msg: /tmp/APFloat-oISpPA.ii
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o] Error 254
make[1]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/all] Error 2
make: *** [all] Error 2
Will attach .ii file shortly.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Thu Feb 2 23:32:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 05:32:09 +0000
Subject: [LLVMbugs] [Bug 11915] New: [llvm][llc]slatallocator memory full
error
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11915
Bug #: 11915
Summary: [llvm][llc]slatallocator memory full error
Product: new-bugs
Version: 3.0
Platform: Other
OS/Version: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: bogon82.kim at samsung.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 7990
--> http://llvm.org/bugs/attachment.cgi?id=7990
gcc test case which generate slatallocator memory full error
Log:
When passing a huge parameter using the byval mechanism, a long
sequence of loads and stores was being generated to perform the
copy on the arm targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101101/111138.html
This problem is similar testcase as above link.
However, the dying point is different like below callstacks
I assume that this comes from invalid NumValues which obtains by ValueVTs
ComputeValueVTs(TLI, Ty, ValueVTs, &Offsets);
unsigned NumValues = ValueVTs.size();
I attached testcase I used.
Please test it.
Call stack
llc.exe!llvm::MallocSlabAllocator::Allocate(unsigned int Size) Line 171
C++
llc.exe!llvm::BumpPtrAllocator::StartNewSlab() Line 53 + 0x1b bytes
C++
llc.exe!llvm::BumpPtrAllocator::Allocate(unsigned int Size, unsigned int
Alignment) Line 125 C++
llc.exe!llvm::Recycler::Allocate(llvm::BumpPtrAllocator
& Allocator) Line 97 + 0x38 bytes C++
llc.exe!llvm::Recycler::Allocate(llvm::BumpPtrAllocator
& Allocator) Line 103 C++
llc.exe!llvm::RecyclingAllocator::Allocate()
Line 46 + 0x1d bytes C++
llc.exe!operator new(unsigned
int __formal,
llvm::RecyclingAllocator &
Allocator) Line 64 C++
> llc.exe!llvm::SelectionDAG::getNode(unsigned int Opcode, llvm::DebugLoc DL, llvm::EVT VT, llvm::SDValue N1, llvm::SDValue N2) Line 3096 + 0xe bytes C++
llc.exe!llvm::SelectionDAGBuilder::visitLoad(const llvm::LoadInst & I)
Line 3227 C++
llc.exe!llvm::SelectionDAGBuilder::visit(unsigned int Opcode, const
llvm::User & I) Line 134 + 0xc bytes C++
llc.exe!llvm::SelectionDAGBuilder::visit(const llvm::Instruction & I)
Line 920 C++
llc.exe!llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator Begin, llvm::ilist_iterator End, bool &
HadTailCall) Line 413 + 0x14 bytes C++
llc.exe!llvm::SelectionDAGISel::SelectAllBasicBlocks(const llvm::Function
& Fn) Line 992 C++
llc.exe!llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction
& mf) Line 294 C++
llc.exe!llvm::MachineFunctionPass::runOnFunction(llvm::Function & F) Line
33 + 0x13 bytes C++
llc.exe!llvm::FPPassManager::runOnFunction(llvm::Function & F) Line 1512
+ 0x17 bytes C++
llc.exe!llvm::FPPassManager::runOnModule(llvm::Module & M) Line 1534 +
0x15 bytes C++
llc.exe!llvm::MPPassManager::runOnModule(llvm::Module & M) Line 1588 +
0x17 bytes C++
llc.exe!llvm::PassManagerImpl::run(llvm::Module & M) Line 1672 + 0x1b
bytes C++
llc.exe!llvm::PassManager::run(llvm::Module & M) Line 1717 C++
llc.exe!main(int argc, char * * argv) Line 375 C++
llc.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
llc.exe!mainCRTStartup() Line 371 C
kernel32.dll!76deed6c()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!773f37f5()
ntdll.dll!773f37c8()
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 01:14:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 07:14:21 +0000
Subject: [LLVMbugs] [Bug 7200] Provide -f flags to turn on individual C++0x
features
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=7200
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #1 from Douglas Gregor 2012-02-03 01:14:21 CST ---
We've decided that we aren't going to do this. Instead, we've introduced
-Wc++98-compat and -Wc++98-compat-pedantic to allow C++11 users to get warnings
when they do something that isn't compatible with C++98.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 01:35:07 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 07:35:07 +0000
Subject: [LLVMbugs] [Bug 9021] Pack expansion into a template-argument-list
corresponding to no parameter packs fails
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=9021
Douglas Gregor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Douglas Gregor 2012-02-03 01:35:07 CST ---
Fixed in Clang r149685.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 07:11:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 13:11:15 +0000
Subject: [LLVMbugs] [Bug 11906] dragonegg-trunk/gcc-4.6.2 fails to build
blender
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11906
Duncan Sands changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Duncan Sands 2012-02-03 07:11:15 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136224.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136225.html
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 11:10:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 17:10:43 +0000
Subject: [LLVMbugs] [Bug 11916] New: Problem compiling against GCC 4.7.0:
use of undeclared identifier '__int128'; did you mean '__int128_t'?
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11916
Bug #: 11916
Summary: Problem compiling against GCC 4.7.0: use of undeclared
identifier '__int128'; did you mean '__int128_t'?
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: salimma at fedoraproject.org
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
When either compiling LLVM (both 3.0 and trunk) on GCC 4.7.0 x86_64, or
compiling third-party software that uses LLVM (e.g. Pure,
http://code.google.com/p/pure-lang/), I get the pasted error. Against GCC 4.6.2
LLVM (and Pure) builds fine.
Complete build logs:
llvm -- http://koji.fedoraproject.org/koji/taskinfo?taskID=3627742
pure -- http://koji.fedoraproject.org/koji/taskinfo?taskID=3759766
In file included from /usr/include/llvm/ExecutionEngine/ExecutionEngine.h:24:
In file included from /usr/include/llvm/ADT/ValueMap.h:29:
In file included from /usr/include/llvm/ADT/DenseMap.h:17:
In file included from /usr/include/llvm/Support/MathExtras.h:17:
In file included from /usr/include/llvm/Support/SwapByteOrder.h:20:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1404:27:
error: use of undeclared identifier '__int128'; did you mean '__int128_t'?
struct numeric_limits<__int128>
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:36:
error: expected '>'
struct numeric_limits
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:5:
error: cannot combine with previous '(error)' declaration specifier
struct numeric_limits
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:44:
error: expected unqualified-id
struct numeric_limits
^
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 11:36:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 17:36:13 +0000
Subject: [LLVMbugs] [Bug 11917] New: Crash while parsing non-existent union
field
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11917
Bug #: 11917
Summary: Crash while parsing non-existent union field
Product: clang
Version: 3.0
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: rgacogne-free at valombre.net
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Hi,
clang revision 149695 is crashing while trying to parse an erroneous,
non-existent union field in a C source code.
This is fixed by the following patch:
Index: lib/Sema/SemaInit.cpp
===================================================================
--- lib/Sema/SemaInit.cpp (revision 149695)
+++ lib/Sema/SemaInit.cpp (working copy)
@@ -1510,7 +1510,8 @@
IdentifierInfo *FieldName) {
assert(AnonField->isAnonymousStructOrUnion());
Decl *NextDecl = AnonField->getNextDeclInContext();
- while (IndirectFieldDecl *IF = dyn_cast(NextDecl)) {
+ IndirectFieldDecl *IF = NULL;
+ while (NextDecl && (IF = dyn_cast(NextDecl))) {
if (FieldName && FieldName == IF->getAnonField()->getIdentifier())
return IF;
NextDecl = NextDecl->getNextDeclInContext();
After fixing the offending code, the error generated by the parser is : "field
designator '_erroneous_field_name_' does not refer to any field in type".
Backtrace is:
#0 clang::Decl::getKind (this=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Frontend/../../include/clang/AST/DeclBase.h:346
#1 0x00000000008984d5 in clang::IndirectFieldDecl::classof (D=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Frontend/../../include/clang/AST/Decl.h:2206
#2 0x00000000008984b5 in llvm::isa_impl::doit (Val=...) at
/data/sources/clang_llvm/llvm/include/llvm/Support/Casting.h:50
#3 0x0000000000898495 in llvm::isa_impl_cl::doit (Val=0x0) at
/data/sources/clang_llvm/llvm/include/llvm/Support/Casting.h:68
#4 0x0000000000898468 in llvm::isa_impl_wrap::doit (Val=@0x7fffffff4520: 0x0) at
/data/sources/clang_llvm/llvm/include/llvm/Support/Casting.h:99
#5 0x0000000000898425 in llvm::isa
(Val=@0x7fffffff4520: 0x0) at
/data/sources/clang_llvm/llvm/include/llvm/Support/Casting.h:110
#6 0x0000000000db5135 in llvm::dyn_cast (Val=@0x7fffffff4520: 0x0) at
/data/sources/clang_llvm/llvm/include/llvm/Support/Casting.h:220
#7 0x0000000000ec01c3 in FindIndirectFieldDesignator (AnonField=0x38e3520,
FieldName=0x38327a0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit.cpp:1513
#8 0x0000000000ebd279 in (anonymous
namespace)::InitListChecker::CheckDesignatedInitializer (this=0x7fffffff5930,
Entity=..., IList=0x3913ec8, DIE=0x3913e80, DesigIdx=0, CurrentObjectType=...,
NextField=0x7fffffff52c0, NextE
lementIndex=0x0, Index=@0x7fffffff5858: 2, StructuredList=0x0,
StructuredIndex=@0x7fffffff5854: 4, FinishSubobjectInit=true,
TopLevelObject=true) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit.cpp:1678
#9 0x0000000000ebb64b in (anonymous
namespace)::InitListChecker::CheckStructUnionTypes (this=0x7fffffff5930,
Entity=..., IList=0x3913ec8, DeclType=..., Field=...,
SubobjectIsDesignatorContext=true, Index=@0x7fffffff5858: 2,
StructuredList=0x0, StructuredIndex=@0x7fffffff5854: 4, TopLevelObject=true) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit.cpp:1365
#10 0x0000000000eb9eec in (anonymous
namespace)::InitListChecker::CheckListElementTypes (this=0x7fffffff5930,
Entity=..., IList=0x3913ec8, DeclType=..., SubobjectIsDesignatorContext=true,
Index=@0x7fffffff5858: 2, StructuredL
ist=0x0, StructuredIndex=@0x7fffffff5854: 4, TopLevelObject=true) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit.cpp:690
#11 0x0000000000eb879a in (anonymous
namespace)::InitListChecker::CheckExplicitInitList (this=0x7fffffff5930,
Entity=..., IList=0x3913ec8, T=..., Index=@0x7fffffff5858: 2,
StructuredList=0x0, StructuredIndex=@0x7fffffff5854:
4, TopLevelObject=true) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit.cpp:603
#12 0x0000000000eb800a in (anonymous
namespace)::InitListChecker::InitListChecker (this=0x7fffffff5930, S=...,
Entity=..., IL=0x3913ec8, T=..., VerifyOnly=true, AllowBraceElision=true) at
/data/sources/clang_llvm/llvm/tools/c
lang/lib/Sema/SemaInit.cpp:481
#13 0x0000000000ead0c3 in TryListInitialization (S=..., Entity=..., Kind=...,
InitList=0x3913ec8, Sequence=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit.cpp:3019
#14 0x0000000000eac39d in clang::InitializationSequence::InitializationSequence
(this=0x7fffffff60c0, S=..., Entity=..., Kind=..., Args=0x7fffffff77c8,
NumArgs=1) at /data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaInit
.cpp:3915
#15 0x0000000000d43a3a in clang::Sema::AddInitializerToDecl (this=0x36fcc70,
RealDecl=0x3913d20, Init=0x3913ec8, DirectInit=false, TypeMayContainAuto=false)
at /data/sources/clang_llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:6
132
#16 0x0000000000c5bdd2 in
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes (this=0x36fe690,
D=..., TemplateInfo=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1311
#17 0x0000000000c5ae52 in clang::Parser::ParseDeclGroup (this=0x36fe690,
DS=..., Context=7, AllowFunctionDefinitions=false, DeclEnd=0x7fffffff86d8,
FRI=0x0) at /data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseDecl.cpp
:1118
#18 0x0000000000c582a4 in clang::Parser::ParseSimpleDeclaration
(this=0x36fe690, Stmts=..., Context=7, DeclEnd=..., attrs=...,
RequireSemi=true, FRI=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseDecl.cpp:97
6
#19 0x0000000000c580ac in clang::Parser::ParseDeclaration (this=0x36fe690,
Stmts=..., Context=7, DeclEnd=..., attrs=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseDecl.cpp:930
#20 0x0000000000c2e1ca in clang::Parser::ParseStatementOrDeclaration
(this=0x36fe690, Stmts=..., OnlyStatement=false, TrailingElseLoc=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:212
#21 0x0000000000c34438 in clang::Parser::ParseCompoundStatementBody
(this=0x36fe690, isStmtExpr=false) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:765
#22 0x0000000000c33e7f in clang::Parser::ParseCompoundStatement
(this=0x36fe690, attrs=..., isStmtExpr=false, ScopeFlags=8) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:700
#23 0x0000000000c2f9d1 in clang::Parser::ParseCompoundStatement
(this=0x36fe690, Attr=..., isStmtExpr=false) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:658
#24 0x0000000000c2e359 in clang::Parser::ParseStatementOrDeclaration
(this=0x36fe690, Stmts=..., OnlyStatement=true, TrailingElseLoc=0x7fffffff9348)
at /data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:231
#25 0x0000000000c3711e in clang::Parser::ParseStatement (this=0x36fe690,
TrailingElseLoc=0x7fffffff9348) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/../../include/clang/Parse/Parser.h:1492
#26 0x0000000000c2fcc9 in clang::Parser::ParseIfStatement (this=0x36fe690,
attrs=..., TrailingElseLoc=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:940
#27 0x0000000000c2e3f8 in clang::Parser::ParseStatementOrDeclaration
(this=0x36fe690, Stmts=..., OnlyStatement=false, TrailingElseLoc=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:238
#28 0x0000000000c34438 in clang::Parser::ParseCompoundStatementBody
(this=0x36fe690, isStmtExpr=false) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:765
#29 0x0000000000c33e7f in clang::Parser::ParseCompoundStatement
(this=0x36fe690, attrs=..., isStmtExpr=false, ScopeFlags=8) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:700
#30 0x0000000000c2f9d1 in clang::Parser::ParseCompoundStatement
(this=0x36fe690, Attr=..., isStmtExpr=false) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:658
#31 0x0000000000c2e359 in clang::Parser::ParseStatementOrDeclaration
(this=0x36fe690, Stmts=..., OnlyStatement=true, TrailingElseLoc=0x7fffffffa178)
at /data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:231
#32 0x0000000000c3711e in clang::Parser::ParseStatement (this=0x36fe690,
TrailingElseLoc=0x7fffffffa178) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/../../include/clang/Parse/Parser.h:1492
#33 0x0000000000c2fcc9 in clang::Parser::ParseIfStatement (this=0x36fe690,
attrs=..., TrailingElseLoc=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:940
#34 0x0000000000c2e3f8 in clang::Parser::ParseStatementOrDeclaration
(this=0x36fe690, Stmts=..., OnlyStatement=false, TrailingElseLoc=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:238
#35 0x0000000000c34438 in clang::Parser::ParseCompoundStatementBody
(this=0x36fe690, isStmtExpr=false) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:765
#36 0x0000000000c35c33 in clang::Parser::ParseFunctionStatementBody
(this=0x36fe690, Decl=0x3913520, BodyScope=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseStmt.cpp:1956
#37 0x0000000000c4837f in clang::Parser::ParseFunctionDefinition
(this=0x36fe690, D=..., TemplateInfo=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/Parser.cpp:979
#38 0x0000000000c5ab36 in clang::Parser::ParseDeclGroup (this=0x36fe690,
DS=..., Context=0, AllowFunctionDefinitions=true, DeclEnd=0x0, FRI=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1081
#39 0x0000000000c47379 in clang::Parser::ParseDeclarationOrFunctionDefinition
(this=0x36fe690, DS=..., AS=clang::AS_none) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/Parser.cpp:795
#40 0x0000000000c473fc in clang::Parser::ParseDeclarationOrFunctionDefinition
(this=0x36fe690, attrs=..., AS=clang::AS_none) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/Parser.cpp:808
#41 0x0000000000c46819 in clang::Parser::ParseExternalDeclaration
(this=0x36fe690, attrs=..., DS=0x0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/Parser.cpp:679
#42 0x0000000000c45b49 in clang::Parser::ParseTopLevelDecl (this=0x36fe690,
Result=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/Parser.cpp:492
#43 0x0000000000c1b2f2 in clang::ParseAST (S=..., PrintStats=false) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Parse/ParseAST.cpp:85
#44 0x0000000000866c28 in clang::ASTFrontendAction::ExecuteAction
(this=0x36be8e0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:414
#45 0x0000000000a2f883 in clang::CodeGenAction::ExecuteAction (this=0x36be8e0)
at /data/sources/clang_llvm/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:407
#46 0x0000000000866877 in clang::FrontendAction::Execute (this=0x36be8e0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:334
#47 0x000000000083afa1 in clang::CompilerInstance::ExecuteAction
(this=0x36ba0b0, Act=...) at
/data/sources/clang_llvm/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:653
#48 0x000000000080316f in clang::ExecuteCompilerInvocation (Clang=0x36ba0b0) at
/data/sources/clang_llvm/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:175
#49 0x00000000007ee3e9 in cc1_main (ArgBegin=0x7fffffffd3e0,
ArgEnd=0x7fffffffd718, Argv0=0x36b76c8
"/data/sources/clang_llvm/build/Debug+Asserts/bin/clang", MainAddr=0x7fcee0) at
/data/sources/clang_llvm/llvm/tools/clang/too
ls/driver/cc1_main.cpp:165
#50 0x00000000007fd12d in main (argc_=105, argv_=0x7fffffffdd18) at
/data/sources/clang_llvm/llvm/tools/clang/tools/driver/driver.cpp:352
I can produce a core dump and the offending source code or any other
information if needed.
Regards,
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 15:02:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 21:02:12 +0000
Subject: [LLVMbugs] [Bug 11535] Clang miscompiles simple C code
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11535
Dan Gohman changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Dan Gohman 2012-02-03 15:02:12 CST ---
Fixed in r149654.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From bugzilla-daemon at llvm.org Fri Feb 3 16:06:06 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 03 Feb 2012 22:06:06 +0000
Subject: [LLVMbugs] [Bug 11918] New: clang on windows compiles functions
with varargs incorrectly. osx is fine.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=11918
Bug #: 11918
Summary: clang on windows compiles functions with varargs
incorrectly. osx is fine.
Product: clang
Version: trunk
Platform: PC
OS/Version: other
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: lucas.meijer at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
clang (msvc10 cmake built) on trunk (as well as the 3.0 release) creates an
invalid llvm program for the following wikipedia example of stdarg.h. (clang
-emit-llvm -c test.c -o test.bc).
#include
#include
/* print all non-negative args one at a time;
all args are assumed to be of int type */
void printargs(int arg1, ...)
{
va_list ap;
int i;
va_start(ap, arg1);
for (i = arg1; i >= 0; i = va_arg(ap, int))
printf("%d ", i);
va_end(ap);
putchar('\n');
}
int main(void)
{
printargs(5, 2, 14, 84, 97, 15, 24, 48, -1);
printargs(84, 51, -1);
printargs(-1);
printargs(1, -1);
return 0;
}
according to efriedma on irc, the generated llvm ir should always contain calls
to @llvm.va_start. clang on osx creates these just fine. clang on windows
however outputs the following program, whose output is incorrect, and contains
no calls to @llvm.va_start()
ModuleID = '\temp\test.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32"
target triple = "i686-pc-win32"
@.str = private unnamed_addr constant [4 x i8] c"%d \00", align 1
define void @printargs(i32 %arg1, ...) nounwind {
%1 = alloca i32, align 4
%ap = alloca i8*, align 4
%i = alloca i32, align 4
store i32 %arg1, i32* %1, align 4
%2 = bitcast i32* %1 to i8*
%3 = getelementptr inbounds i8* %2, i32 4
store i8* %3, i8** %ap, align 4
%4 = load i32* %1, align 4
store i32 %4, i32* %i, align 4
br label %5
;