On Mar 7, 2007, at 11:16 AM, Mike Stump wrote:
Does -fobjc-gc work for you now? It's been on mainline for a while
now. As for accelerated message dispatch, I'm not exactly certain
which feature you're
Option may be recognized. But it entirely depends on Leopard runtime
for support.
On Mar 7, 2007, at 9:13 AM, Eric Christopher wrote:
Hi Michael,
Two questions about Apple's Objective-C 2.0 work:
1) Does anyone know when the syntax extensions will be available &
working
in the gcc compiler?
It is work in progress. For current status, you can check out Apple's
4.0
On Jul 24, 2006, at 3:07 PM, Andrew Pinski wrote:
gcc generates two separate trees for compound literals in c and c++.
As in this test case:
struct S {
int i,j;
};
void foo (struct S);
int main ()
{
foo((struct S){1,1});
}
On the other hand, such a guard does not e
On Jul 24, 2006, at 3:07 PM, Andrew Pinski wrote:
gcc generates two separate trees for compound literals in c and c++.
As in this test case:
struct S {
int i,j;
};
void foo (struct S);
int main ()
{
foo((struct S){1,1});
}
On the other hand, such a guard does not e
gcc generates two separate trees for compound literals in c and c++.
As in this test case:
struct S {
int i,j;
};
void foo (struct S);
int main ()
{
foo((struct S){1,1});
}
In c it generates compound_literal_expr and in c++ it generates
target_expr. But gimplifier treats
On Sep 23, 2005, at 12:41 PM, Richard Henderson wrote:
On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote:
/* Avoid creating invalid subregs, for example when
simplifying (x>>32)&255. */
! if (final_word >=
On Sep 23, 2005, at 12:41 PM, Richard Henderson wrote:
On Thu, Sep 22, 2005 at 01:21:06PM -0700, Fariborz Jahanian wrote:
/* Avoid creating invalid subregs, for example when
simplifying (x>>32)&255. */
! if (final_word >=
In a given test case with 128 bit mmx intrinsics, routine
make_compound_operation (in combine.c) attempts to do a sign-extract
of the middle 64bit of the 128 bit (TImode) register. Pattern we have
is:
(lshiftrt:TI (ashift:TI (subreg:TI (reg/v:V2DI 75
[ vu16YPrediction3 ]) 0) (const_int 32
I ran into a problem when chasing down an -mfix-and-continue (an
apple specialty :) code-gen problem.
In a test case, ivopts creates a symbol_ref via a call to
produce_memory_decl_rtl; as in:
if (TREE_STATIC (obj) || DECL_EXTERNAL (obj))
{
const char *name = IDENTIFIER_POI
You can start off by looking into how -fsyntax-only option is
implemented.
- fariborz
On Sep 12, 2005, at 12:55 PM, Ashwin Bharambe wrote:
Hmm. Ok fine, I can live with having to keep all extraneous code lying
around. But it seems like there must be a way to:
- stop gcc once the cp front
On Aug 25, 2005, at 12:47 PM, H. J. Lu wrote:
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
Fariborz Jahanian <[EMAIL PROTECTED]> writes:
Forgot to attach the patch:
Index: i386.c
===
RCS file: /c
11:09 AM, Fariborz Jahanian wrote:
(Note! I am starting a new thread of an old thread because of old
thread's corruption which prevented me from responding).
Following test case:
struct S {
double d1, d2, d3;
};
struct S ms()
{
struct S s = {0,0,0};
ret
(Note! I am starting a new thread of an old thread because of old
thread's corruption which prevented me from responding).
Following test case:
struct S {
double d1, d2, d3;
};
struct S ms()
{
struct S s = {0,0,0};
return s;
}
Compiled with -O1 -mdynamic-no-pic -march
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This patch results in generating worse code for the foll
Today's checkout and bootstrap on apple-x86-darwin resulted in the
following:
stage1/xgcc -Bstage1/ -B/usr/local/i686-apple-darwin8.1.0/bin/ -O2 -
g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-
variadic-m
On Jul 8, 2005, at 5:41 PM, Andrew Pinski wrote:
On Jul 8, 2005, at 8:13 PM, Fariborz Jahanian wrote:
Tried building fsf mainline on x86-darwin. Syntax error compiling
c-common.c. The preprocessed file shows the following:
This is a darwin specific bug and was introduced by Geoff K.&#
On Jul 8, 2005, at 5:36 PM, Daniel Berlin wrote:
On Fri, 2005-07-08 at 17:13 -0700, Fariborz Jahanian wrote:
Tried building fsf mainline on x86-darwin. Syntax error compiling c-
common.c. The preprocessed file shows the following:
as of when?
I bootstrapped and tested x86_64-unknown
Tried building fsf mainline on x86-darwin. Syntax error compiling c-
common.c. The preprocessed file shows the following:
if ("__builtin_" "acosf" && 1)
{ tree decl;
((void)(!((!1 && !1) || !strncmp ("__builtin_" "acosf",
"__builtin_", strlen ("__builtin_"))) ? fancy_abort ("../../gcc-
On Jun 30, 2005, at 12:47 PM, Steven Bosscher wrote:
Well, maybe so, but it would be a pretty lame workaround. Why are you
so worried about bugs? This flag was always disabled at -O1, and we
have never seen any bug reports that got fixed with -fforced-mem. And
besides, it is better to fix b
On Jun 30, 2005, at 11:23 AM, Jeffrey A Law wrote:
On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
Jeffrey A Law wrote:
I'd tend to agree. I'd rather see the option go away than linger on
if the option is no longer useful.
I wouldn't mind that, but I'd also like to point out tha
On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote:
Hmm. I would suspect this is obsolete now. We'll have forced
everything into "registers" (or something equivalent that we
can work with) during tree optimization. Any CSEs that can be
made should have been made.
I will do sanity chec
this behavior is as expected but not ideal
for x86 where a couple of 'movl $0x0, mem' may be preferred to a
single 'movsd %xmm7, mem' for 252.eon on x86-darwin.
- fariborz
On Jun 24, 2005, at 3:07 PM, Fariborz Jahanian wrote:
A source file mrSurfaceList.cc of 2
A source file mrSurfaceList.cc of 252.eon produces less efficient
code initializing instance objects to 0 at -O2 than at -O1. Behavior
is random and it does not happen on all x86 platforms and making the
test smaller makes the problem go away. But here is what I found out
is the cause.
W
One of our internal apps fails due to problem in folding of vec_mergeh
of unsigned char of zeros and ones. It produces a new vector of zeros
followed
by ones. I traced the problem to the 3rd operand for the
"altivec_vmrghb" pattern defined in altivec.md file. It is 255 (0xff).
I think it
should
Today, I tried bootstrapping gcc mainline on/for apple-ppc-darwin. It
fails in stage1.
Is this known?
- Thanks, fariborz
./xgcc -B./ -B/usr/local/powerpc-apple-darwin8.0.0/bin/ -isystem
/usr/local/powerpc-apple-darwin8.0.0/include -isystem
/usr/local/powerpc-apple-darwin8.0.0/sys-include
-L/Vo
Thanks Andrew. Yes, standard actually mentions this that I missed.
- fariborz
On Mar 11, 2005, at 11:25 AM, Andrew Pinski wrote:
On Mar 11, 2005, at 2:16 PM, Fariborz Jahanian wrote:
So, is g++ correct in rejecting this seemingly good user code?
Yes you need a place to store the data.
So for an
Section 9.4.2 of c++ standard "Static data members" does not directly
address this issue. But there is
a dejagnu c++ test case which explicitly disallows (by issuing a
link-time error) taking address of a static
const data member. Test case is const2.C.
This question has come up because, g++-4.
On Feb 25, 2005, at 1:16 PM, Joe Buck wrote:
I duplicated this on a i686-pc-linux-gnu system: the compiler is built
from last night's trunk.
% /usr/localdisk/gcc-cvs/trunk/bin/gcc -c -O1 bad.c
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.
Hi,
There gotta be a PR on this because it is so easy to reproduce.
Following test case runs out of stack space when
gcc tries to compute factorial (159). I have a patch which does two
simple things. 1) it rewrites tree_fold_factorial
function into its non-recursive version, and 2) it sets a
29 matches
Mail list logo
