> It's not yet checked in :)
So, I'll wait!-)
Dominique
On Mar 17, 2007, at 4:31 PM, Dominique Dhumieres wrote:
The new method will be that the default will be the system that
you are
currently on. It's not the default now.
How new is new? As far as I can tell, it did not work for the
20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and
> The new method will be that the default will be the system that you are
> currently on. It's not the default now.
How new is new? As far as I can tell, it did not work for the
20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and
friends which do not pass for the 20070316 snapshot, it is
On Mar 17, 2007, at 4:15 PM, Dominique Dhumieres wrote:
Eric,
Thanks for the explanations.
The idea, I believe, is that the default will be the system that you
are currently on.
It would be nice, but it is not the way it seems to work (at least
for gcc,
for g++ and gfortran it may, but
Eric,
Thanks for the explanations.
> The idea, I believe, is that the default will be the system that you
> are currently on.
It would be nice, but it is not the way it seems to work (at least for gcc,
for g++ and gfortran it may, but I am not sure). For instance
I have a version of 4.3.0 on 10
Thanks for the answer, but I understand very little of it.
The above can be read as:
If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
is true, otherwise, TARGET_C99_FUNCTIONS is false.
So far so good.
we are ta
Mike,
Thanks for the answer, but I understand very little of it.
> The above can be read as:
>
> If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
> otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
> is true, otherwise, TARGET_C99_FUNCTIONS is false.
So far so g
On Mar 17, 2007, at 2:22 PM, Dominique Dhumieres wrote:
Following the discussions for PR30969, PR30980, and PR31161,
it appears that TARGET_C99_FUNCTIONS is not set on OSX 10.3.9
nor OSX 10.4.9. Is this in line with the comment
/* Old versions of Mac OS/Darwin don't have C99 functions
availabl
Following the discussions for PR30969, PR30980, and PR31161,
it appears that TARGET_C99_FUNCTIONS is not set on OSX 10.3.9
nor OSX 10.4.9. Is this in line with the comment
/* Old versions of Mac OS/Darwin don't have C99 functions available. */
in gcc/config/rs6000/darwin.h? and
#undef TARGET_C9
Now filed under
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
at David's request.
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
pgpmJBx7yF8Fe.pgp
Description: PGP signature
This is the project proposal that I am planning to submit to Google
Summer of Code 2007. It is based on previous work of Jeffrey Laws,
Diego Novillo and others. I hope someone will find it interesting and
perhaps would like to act as mentor. Feedback is very welcome (eve
negative feedback!!). I ha
GCC 4.2.0 RC1 is now on ftp://gcc.gnu.org and its mirrors.
(Although this is marked as "RC1", I don't consider it a "release
candidate", quite. It's more a "beta" than a "release candidate"; we
still have quite a number of GCC 4.2.0 P1s which concern me. I plan a
full status report tomorrow.)
T
Paolo Bonzini wrote:
> Mark Mitchell wrote:
>> Paolo Bonzini wrote:
>>
>>> IIUC, the problem only manifests while *building* the release candidates,
>>> not for users of the release candidate.
>>>
>>> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
>> That's an attractive
On 3/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Are there any performance issues to consider? Is using libffi
slower/faster than the builtins?
It is most likely slower but these APIs in libobjc are not used as
much as the other ones, plus GNUStep already uses libffi as the
forwarding mech
Hi,
this is my simple test proggie:
#include
#include
union __u128i {
unsigned int u[4];
__m128i v;
};
static const union __u128i mask = {{0xU, 0xU, 0xU,
0xU}};
static void test1()
{
union __u128i input = {{1, 2, 3, 4}};
int
Steven Bosscher writes:
> On 3/16/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> > > My thinking is that if libobjc was changed then we could put in a
> > > depreciated message on these builtins for 4.3 and maybe remove them for
> > > 4.4
Andrew Pinski wrote:
> On 3/16/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> Do you mean this patch:
>> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html
>
> Yes, thanks for finding the patch.
>
> I will look over it this weekend and apply it if it is good.
Build parts are ok, except t
17 matches
Mail list logo
