search for: __t

...code/compilers/build/llvm/include -DL_powitf2 -c /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c -o libgcc/./_powitf2.o cc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64((__extension__ ({...

...XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64((__extension__ ({...

.../include -DL_powitf2 -c > /home/chandlerc/code/compilers/llvm-gcc/gcc/libgcc2.c -o > libgcc/./_powitf2.o > cc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: > const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): > Assertion `(!(__extension__ ({ const tree __t = (Tr); if > (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != > (tcc_type)) tree_class_check_failed (__t, (tcc_type), > "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, > __FUNCTION__); __t; })->type.size) || !Ty->isSized() || > !i...

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call

On Wednesday 10 October 2007 12:53, Chris Lattner wrote: > On Mon, 8 Oct 2007, Evan Cheng wrote: > > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > > perfectly legal. Both > > leal (%esi,%edi), %eax > > leal (%rsi,%rdi), %eax > > are legal assembly. It's just the former requires a 67H prefix due to > > the 32-bit address size. >

...le sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm- types.cpp", 81, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64((__extension__ ({...

...or a 32-bit processor requested. [x86_64-off-dbg]: Warning: 64-bit processors all have at least SSE2. [x86_64-off-dbg]: cc1: /llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp:82: const llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(! (__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp", 82, __FUNCTION__); __t; })->type.size) || !Ty->isSized() || !isInt64 ((__extension...

On Mon, 8 Oct 2007, Evan Cheng wrote: > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > perfectly legal. Both > leal (%esi,%edi), %eax > leal (%rsi,%rdi), %eax > are legal assembly. It's just the former requires a 67H prefix due to > the 32-bit address size. > > This does point to a performance problem in the 3 address conversion > code (which I

Hello, Duncan. > 3-fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const

.../null +++ b/usr/include/sys/auxv.h @@ -0,0 +1,16 @@ +#ifndef _SYS_AUXV_H +#define _SYS_AUXV_H + +#include <klibc/compiler.h> +#include <elf.h> + +#define _AUXVAL_MAX AT_SYSINFO_EHDR + +__extern unsigned long __auxval[_AUXVAL_MAX]; + +__static_inline unsigned long getauxval(unsigned long __t) +{ + return (__t >= _AUXVAL_MAX) ? 0 : __auxval[__t]; +} + +#endif /* _SYS_AUXV_H */ diff --git a/usr/include/sys/elfcommon.h b/usr/include/sys/elfcommon.h index 300ff4e..603b0ce 100644 --- a/usr/include/sys/elfcommon.h +++ b/usr/include/sys/elfcommon.h @@ -107,6 +107,8 @@ #define AT_CLKTCK 1...

...r/lib/libgobject-2.0.so.0 No symbol table info available. #1 0xb753e746 in g_object_unref () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #2 0xb5023c7a in swfdec_gtk_player_set_missing_plugins_window ( player=0xb1161a8, window=0x8bd1800) at swfdec_gtk_player.c:443 __t = <value optimized out> priv = (SwfdecGtkPlayerPrivate *) 0xad8ada4 __PRETTY_FUNCTION__ = "swfdec_gtk_player_set_missing_plugins_window" #3 0xb50431e9 in swfmoz_player_set_target (player=0xb1161a8, target=0xa4c0130, x=0, y=0, width=776, height=178) at swfmoz_pl...

...4.6/../../../../include/c++/4.6/condition_variable:38: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:535:6: error: no matching constructor for initialization of 'duration' (aka 'std::chrono::duration<long, std::ratio<1, 1000000> >') : __d(__t.time_since_epoch()) On Tue, Sep 10, 2013 at 1:28 PM, Alexey Samsonov <samsonov at google.com> wrote: > FYI We have an upstream bootstrap bot > (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap) that > does a number of things including running llvm/clang tests under...

...x-gnu/4.6/../../../../include/c++/4.6/thread:38: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:535:6: error: no matching constructor for initialization of 'duration' (aka 'std::chrono::duration<long, std::ratio<1, 1000000> >') : __d(__t.time_since_epoch()) ^ ~~~~~~~~~~~~~~~~~~~~~~ /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/condition_variable:106:42: note: in instantiation of function template specialization 'std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<lo...

...de/c++/4.6/condition_variable:38: > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:535:6: > error: no matching constructor for initialization of 'duration' (aka > 'std::chrono::duration<long, std::ratio<1, 1000000> >') > : __d(__t.time_since_epoch()) > > On Tue, Sep 10, 2013 at 1:28 PM, Alexey Samsonov <samsonov at google.com> wrote: >> FYI We have an upstream bootstrap bot >> (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap) that >> does a number of things including running l...

..../include/c++/4.6/thread:38: > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:535:6: > error: no matching constructor for initialization of 'duration' (aka > 'std::chrono::duration<long, std::ratio<1, 1000000> >') > : __d(__t.time_since_epoch()) > ^ ~~~~~~~~~~~~~~~~~~~~~~ > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/condition_variable:106:42: > note: in instantiation of function template specialization > 'std::chrono::time_point<std::chrono::system_clock, > st...

...sr/lib/xen-common/xapi/sm/blktap2.py", line 582, in find found = list(cls.list(**args)) File "/usr/lib/xen-common/xapi/sm/blktap2.py", line 557, in list for row in TapCtl.list(**args): File "/usr/lib/xen-common/xapi/sm/blktap2.py", line 67, in loop return f(*__t, **__d) File "/usr/lib/xen-common/xapi/sm/blktap2.py", line 271, in list return list(cls.__list(**args)) File "/usr/lib/xen-common/xapi/sm/blktap2.py", line 247, in __list key, val = field.split(''='') ValueError: need more than 1 value to unpack ]...

FYI We have an upstream bootstrap bot ( http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap) that does a number of things including running llvm/clang tests under ASan/MSan. Probably we can add a couple of steps that would checkout lld and run check-lld in ASan-ified/MSan-ified build trees. On Mon, Sep 9, 2013 at 9:00 AM, Shankar Easwaran <shankare at codeaurora.org>wrote:

On 15/10/13 22:22, C K Kashyap wrote: > Hi, > I'd like to try out the new c++11 features using clang. However, I am > running into some issue or the other on both Windows and Linux. In both > cases, it looks like the problem is due to headers from VC/g++. > I was wondering if someone can point me to some steps on setting up a > Windows or Linux(ubuntu 12.04 LTS) box for

Hi, I'd like to try out the new c++11 features using clang. However, I am running into some issue or the other on both Windows and Linux. In both cases, it looks like the problem is due to headers from VC/g++. I was wondering if someone can point me to some steps on setting up a Windows or Linux(ubuntu 12.04 LTS) box for exploring clang. I was able to successfully build clang on my ubuntu but

On 9/8/2013 11:48 PM, Chandler Carruth wrote: > On Sun, Sep 8, 2013 at 9:29 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Do you know if llvm itself gets tested as a complete build with the >> fsanitize options ? >> >> Enabling tsan seems to be a good idea too. >> > We test it very regularly with all of the sanitizers. We've not been