On Mon, Jan 11, 2010 at 8:14 AM, Wen Li wrote:
> On x86 processors, I think bitwise operators should be optimized for
> individual bit accesses, which should be converted to BT instructions.
>
> For example:
>
> x |= 1< x ^= 1< x &= ~(1< if (x&(1<
> Especially when y is not known at compile time,
Hi,
I've been trying to play with the Neon scheduler description in
config/arm/neon-schedgen.ml.
Running the description through the ocaml compiler gives me the
following errors
cam-bc3-b12:ramrad01 68 > ocamlc -c neon-schedgen.ml
File "neon-schedgen.ml", line 51, characters 0-10:
Unbound m
Hi,
I'm doing some experiments on the STM implementation on GCC, but I
need some info since the documentation is still not available,
What is the syntax currently adopted in STM_GCC, martin told me that
the old syntax "#pragma atomic" is not used in the current
implementation and that possibly it
On Mon, 11 Jan 2010 09:52:59 +
Ramana Radhakrishnan wrote:
> cam-bc3-b12:ramrad01 68 > ocamlc -c neon-schedgen.ml
> File "neon-schedgen.ml", line 51, characters 0-10:
> Unbound module Utils
>
> It sounds like a configuration issue but given my rather rusty ocaml
> skills - I'm not sure wher
On Mon, Jan 11, 2010 at 12:28:38PM +, Julian Brown wrote:
> Another thing which might bite you is that recent OCaml versions don't
> like hyphens in filenames: replacing them with underscores works OK
> though (i.e. neon_schedgen.ml).
Fortunately it's just a warning; you can also ignore it.
-
Hello,
Is the a way to get access to the currently thrown
C++ exception object? cxxabi.h gives me only access
to its std::type_info via __cxa_current_exception_type().
On the other hand, the ABI documentation describes
the struct __cxa_exception, but it is not accessible
via cxxabi.h. Additionally
>
> Would you like to try this out and see how you get on with it?
> Followups set to gcc-patches.
Thanks - that works and I can confirm that those bits generate identical
code to what's auto-generated in cortex-a8-neon.md.
I'll submit a patch to gcc-patches@ unless you beat me to it.
cheers
In the absence of any discussion, I just went ahead and implemented my
new ideas, which are attached as a patch!
Whilst it is tailored to the specifics of our architecture - where we
have 32 C_REGS, of which there are 16 BOTTOM_REGS, and some insns
that only work with BOTTOM_REGS - I believe it co
Hi all,
I am using gcc 4.3.4 to loop through the gimple tree to find
CALL_EXPR. This is what I have (even though I tried several variants,
none of which worked):
tree body_stmt = DECL_SAVED_TREE (current_function_decl);
while (body_stmt) //
{
if (TREE_CODE (body_stmt) == CALL_EXPR)
#g++ --version | head -1
g++ (GCC) 4.4.3 20091228 (prerelease)
#cat test.cc
typedef _Decimal32 my_type;
#gcc -c test.cc
#g++ -c test.cc
test.cc:1: error: '_Decimal32' does not name a type
G++ is unfamiliar with the _DecimalXX types. Is it a "feature", bug or lack
of development?
#cat test.cc
t
On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos wrote:
> Hi all,
>
> I am using gcc 4.3.4 to loop through the gimple tree to find
> CALL_EXPR. This is what I have (even though I tried several variants,
> none of which worked):
> tree body_stmt = DECL_SAVED_TREE (current_function_decl);
> while
On 01/11/2010 04:09 AM, Riyadh Baghdadi wrote:
I found in the testsuit that you are also using "__transaction { }",
but when compiling the testsuite example, it says :
"undefined reference to `_ITM_beginTransaction'", is there any library
that should be used to link ?
libitm, as built in that t
On 01/11/2010 05:24 PM, Roman Kononov wrote:
> #g++ --version | head -1
> g++ (GCC) 4.4.3 20091228 (prerelease)
> #cat test.cc
> typedef _Decimal32 my_type;
> #gcc -c test.cc
> #g++ -c test.cc
> test.cc:1: error: '_Decimal32' does not name a type
>
> G++ is unfamiliar with the _DecimalXX types. Is
On Mon, 2010-01-11 at 10:24 -0600, Roman Kononov wrote:
> #g++ --version | head -1
> g++ (GCC) 4.4.3 20091228 (prerelease)
> #cat test.cc
> typedef _Decimal32 my_type;
> #gcc -c test.cc
> #g++ -c test.cc
> test.cc:1: error: '_Decimal32' does not name a type
>
> G++ is unfamiliar with the _DecimalX
A rebuild test of the current Debian unstable distribution on x86_64-linux-gnu
was done, one rebuild test with the current gcc-4.4 from the branch, and another
one with GCC trunk 20100107. The latter did show about 200 additional build
failures, which are listed in [1] (minus some already known
Thank you,
There is one more "link" problem (for an intrinsic function) :
libitm.so: undefined reference to `__sync_add_and_fetch_8'
I found on the Net that there was a bug related to this on GCC 4.2,
the solution was to specify the architecture (-march=i686) at compile
time, but this doesn't sol
> DJ, can you add these files to the list that we get email about?
Added: ltgcc.m4 ltmain.sh ltoptions.m4 ltsugar.m4 ltversion.m4 lt~obsolete.m4
On Mon, 2010-01-11 at 17:51 +0100, Richard Guenther wrote:
> On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos wrote:
> > Hi all,
> >
> > I am using gcc 4.3.4 to loop through the gimple tree to find
> > CALL_EXPR. This is what I have (even though I tried several variants,
> > none of which worked):
2010/1/11 Piotr Wyderski:
> Hello,
>
> Is the a way to get access to the currently thrown
> C++ exception object? cxxabi.h gives me only access
> to its std::type_info via __cxa_current_exception_type().
> On the other hand, the ABI documentation describes
> the struct __cxa_exception, but it is no
Any thoughts on this? The proposed patch has been applied to newlib's
math.h.
-- Jeff J.
Original Message
Subject: OpenMP vs.
Date: Fri, 08 Jan 2010 12:42:35 -0600
From: Yaakov (Cygwin/X)
To: new...@sources.redhat.com
POSIX allows for functions to also be defined as macro
Hi,
> However, I just encountered tonight a much larger conflict: OpenMP/C++
> and are incompatible. STC attached:
>
> $ g++ -D_GLIBCXX_PARALLEL -fopenmp openmp.cxx -lgomp
> In file included from
> /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/parallel/algobase.h:46,
>from
> /
> Some of the support for those
> classes is in current trunk, but a crucial change to the compiler to
> allow binary compatibility between those classes and the C builtin
> types wasn't approved before the 4.5 feature cutoff (see
> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01321.html).
Am a
22 matches
Mail list logo
