No reply from the maintainer . Can anyone please make this
configuration change to trunk or should I open a bugreport for this?
Thanks
- Jan
On Fri, Jan 4, 2013 at 5:13 PM, Rainer Orth
wrote:
> Hi Jan,
>
>> I'm running a heavily modified version of vxworks and we implement
>> floating point op
Hello Diego,
There still appears to be an issue with the vec.h changes, the
detailed memory stats are not very informative. The allocation lines
are shown in vec.h without further details:
t8000.log:vec.h:1268 ((null)) 0:
0.0% 40 4: 0.0
On Sat, 26 Jan 2013, Hongtao Yu wrote:
> How can I set up a new project under GCC and make it open-sourced?
> Thanks!
That depends on what you mean by "under GCC", I'd say. If you
have improvements for GCC, submitting those as patches against
GCC will be best, cf. http://gcc.gnu.org/contribute.h
Snapshot gcc-4.8-20130127 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi, dear friends.
I am testing floating-points macros in C language, under the standard C99.
My compiler is GCC 4.6.1. (with 4.7.1, I have the same result).
I have two computers:
My system (1) is Windows XP SP2 32bit, in an "Intel (R) Celeron (R) 420" @ 1.60
GHz.
My system (2) is Windows 7 Ultim
this looks good to me. does your patch also address the vec_concat
issue that marc raised?
On 01/26/2013 09:59 PM, Hans-Peter Nilsson wrote:
From: Kenneth Zadeck
Date: Sat, 26 Jan 2013 16:19:40 +0100
the definition of vec_duplicate in section 10.12 seems to restrictive.
i have seen examples w
On 1/27/2013 5:04 PM, Gerald Pfeifer wrote:
On Sat, 26 Jan 2013, Hongtao Yu wrote:
How can I set up a new project under GCC and make it open-sourced?
Thanks!
That depends on what you mean by "under GCC", I'd say. If you
have improvements for GCC, submitting those as patches against
GCC will be
On 1/27/2013 6:02 PM, Argentinator Rincón Matemático wrote:
Hi, dear friends.
I am testing floating-points macros in C language, under the standard C99.
My compiler is GCC 4.6.1. (with 4.7.1, I have the same result).
I have two computers:
My system (1) is Windows XP SP2 32bit, in an "Intel (R)
To some up again (I've kept the quotes so it can be seen what's already
been talked about) I propose something that is almost identical to a
typedef as it exists now, all behaviour of this hard typedef is almost
identical except:
1) the "hard" type is never implicitly 'cast' to anything else o
On Sun, Jan 27, 2013 at 6:19 PM, Alec Teal wrote:
> To some up again (I've kept the quotes so it can be seen what's already been
> talked about) I propose something that is almost identical to a typedef as
> it exists now, all behaviour of this hard typedef is almost identical
> except:
>
> 1) the
On Sat, Jan 26, 2013 at 5:44 PM, Matt Davis wrote:
> This question is similar to my last; however, I think it provides a
> bit more clarity as to how I am obtaining offsets from the frame
> pointer. I have an RTL pass that is processed after expand passes. I
> keep track of a list of stack alloc
On 28/01/13 02:38, James Dennett wrote:
That's a cast -- an explicit request in code for a type conversion.
The fact that it's a pure compile-time operation and a no-op at
runtime has no bearing on whether it "is a cast", just as we can
static_cast beween enumerators and integers today with no
I've thought of how to phrase it.
Yes n3515 does allow more than the 'hard-typedef', they do (in part) do
the same job, but the context where you'd use one and not the other is
very clear, I like clean notations, I think that's a mathematician
thing, as I am sure you know (or have touched on) t
13 matches
Mail list logo
