I had posted this at first under a somewhat misleading subject (someone could
say completely wrong) - hope that has improved yet ;-)
Hello,
> Just as an FYI, Kenny and I have replaced the global liveness analyzer
> with one from df.c, and removed the need for make_accurate_live_analysis
> (ie df.
On Fri, 14 Oct 2005, Kaveh R. Ghazi wrote:
> their corresponding svn commands posted on the website? Hmm, I guess
> we would need to update these pages to the svn equivalents which would
> pretty much cover the basics of a how-to guide:
>
> http://gcc.gnu.org/cvs.html
> http://gcc.gnu.org/cvswri
(Sorry for the C-n-P, my regular email is down till sunday afternoon.
Hopefully notes won't screw this email up too badly)
>Has any thought been put into helping the 200+ people with write
>access migrate?
Of course
There is a basic how to guide for CVS users on the wiki, at
http://gcc.gnu.or
On Wed, Oct 12, 2005 at 02:29:56PM +0200, Rainer Emrich wrote:
> Compiler version: 4.0.2
> Platform: mips-sgi-irix6.5
> configure flags:
> - - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
> - - --with-gnu-as
> - - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
>
Hello,
Once I saw a gcc macro that passes variables arguments to another
variable argument function..example:
function_1 (int z, ...);
function_2 (int z, ...);
{
return function_1 (z, MACRO);
}
Does anyone remember the macro name ?
TIA
On Fri, Oct 14, 2005 at 09:49:42AM +0300, Yaroslav Karulin wrote:
> Hello!
>
> I have two files: foo.c and main.c. foo.c is compiled with RVTC 2.2
> compiler. main.c is compiled with gcc compiler (configured with
> --target=arm-elf). I cannot link them together using gcc linker.
> But it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin schrieb:
> On Wed, Oct 12, 2005 at 02:29:56PM +0200, Rainer Emrich wrote:
>
>>Compiler version: 4.0.2
>>Platform: mips-sgi-irix6.5
>>configure flags:
>>- - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
>>- - --with-gnu-as
>>-
obviously, no. __VA_ARGS__ is a identifier for variadic macros.
I'am looking for some way to pass variable arguments to another
function that receives variable arguments without using va_list.
On 10/14/05, Jairo Balart <[EMAIL PROTECTED]> wrote:
> are you looking for __VA_ARGS__?
>
> Regards,
> J
Kalaky <[EMAIL PROTECTED]> writes:
> I'am looking for some way to pass variable arguments to another
> function that receives variable arguments without using va_list.
This is impossible.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409
I'am looking for some way to pass variable arguments to another
function that receives variable arguments without using va_list.
This is impossible.
USL C has a very neat construct called '&...' which was designed
for exactly this purpose. One day when I have idle cycles (yeah right)
I will l
In reference to this on the wiki.
Bitmaps, also called sparse bit sets, are implemented
using a linked list with a cache. This is probably not
the most time-efficient representation, and it is not
unusual for bitmap functions to show up high on the
execution profile. Bitmaps are used for many thi
Brian Makin <[EMAIL PROTECTED]> writes:
> Bitmaps, also called sparse bit sets, are implemented
> using a linked list with a cache. This is probably not
> the most time-efficient representation, and it is not
> unusual for bitmap functions to show up high on the
> execution profile. Bitmaps are us
All,
I am getting a lot of test suite failures with almost all of
the vect/* tests. I am using pr18400.c from the test suite
as an example here, becuase its about the smallest one I
can find. Here is what is generated at -O2:
.file "pr18400.c"
.version"01.01"
.t
On Oct 14, 2005, at 3:11 PM, Kean Johnston wrote:
All,
I am getting a lot of test suite failures with almost all of
the vect/* tests. I am using pr18400.c from the test suite
as an example here, becuase its about the smallest one I
can find. Here is what is generated at -O2:
Can you just fi
On Fri, Oct 14, 2005 at 03:13:55PM -0400, Andrew Pinski wrote:
>
> On Oct 14, 2005, at 3:11 PM, Kean Johnston wrote:
>
> >All,
> >
> >I am getting a lot of test suite failures with almost all of
> >the vect/* tests. I am using pr18400.c from the test suite
> >as an example here, becuase its about
On Oct 13, 2005, at 8:21 PM, Jack Howarth wrote:
What exactly are all of the new libgcc versions created when
building
the current gcc cvs on MacOS X 10.4.
They allow targeting different OS versions with one compiler, from
the doc:
@item [EMAIL PROTECTED]
The earliest version of MacOS
On Oct 14, 2005, at 3:11 PM, Kean Johnston wrote:
All,
I am getting a lot of test suite failures with almost all of
the vect/* tests. I am using pr18400.c from the test suite
as an example here, becuase its about the smallest one I
can find. Here is what is generated at -O2:
Can you try -fno
Can you just fix your OS instead?
My OS is just fine, thank you very much. You disappoint me.
I expected better from you.
It is most likely of absolutely no consequence to you, and
this has nothing to do with GCC so this is the very last I
will say on this subject to you, but you really did hurt
Can you try -fno-optimize-sibling-calls and see if that works?
Yes, it did, thank you.
If so, then the problem is that we sibling calls should not be
done in main. To fix the testcase anyways to be correct is to
put "return 0;" after the call to main1. Since right now the
return of main could
On Oct 14, 2005, at 3:43 PM, Kean Johnston wrote:
What does the fact that -fno-optimize-sibling-calls worked
indicate really? Without that option something really does
seem to be mis-calculating the stack offsets by 4. What may
be of interest here is that aside from the vect/* tests,
the only o
On Oct 14, 2005, at 3:55 PM, Andrew Pinski wrote:
On Oct 14, 2005, at 3:43 PM, Kean Johnston wrote:
What does the fact that -fno-optimize-sibling-calls worked
indicate really? Without that option something really does
seem to be mis-calculating the stack offsets by 4. What may
be of interest
It indicated that sibling calling optimization in main should
be disabled for targets that need to up the stack alignment,
otherwise you get the stack alignment of a lower one than
While that may be true, I think the problem is broader.
I took out the main1() function and put it into a separate
On Fri, Oct 14, 2005 at 11:27:15AM -0700, Brian Makin wrote:
> Can anyone give me some background on the use of
> bitmaps in gcc?
There's pleanty of material in the list archives. This is not
the first time that this topic has come up.
r~
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote:
> >It indicated that sibling calling optimization in main should
> >be disabled for targets that need to up the stack alignment,
> >otherwise you get the stack alignment of a lower one than
> While that may be true, I think the problem
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote:
> However, I dont think the stack being aligned on a 16-byte
> boundary into main will help, unless GCC is assuming (and I
> dont see how it possibly could) that every function would
> likewise be aligned.
Yes, in fact that's *exactly*
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote:
> Also, when you say "stack going into main is 16 byte aligned",
> what specifically do you mean? that its 16-byte aligned before
> the call to main() itself? That at the first insn in main, most
> likely a push %ebp, its 16-byte align
Yes, in fact that's *exactly* what GCC is assuming.
And it will be true for all code that GCC generates.
How can that possibly ever work? Is the assumption then
that the only code GCC will ever work with is code that
GCC compiled? In effect what this implies is that GCC
is re-defining the ABI. It
On Oct 14, 2005, at 4:43 PM, Kean Johnston wrote:
It indicated that sibling calling optimization in main should
be disabled for targets that need to up the stack alignment,
otherwise you get the stack alignment of a lower one than
While that may be true, I think the problem is broader.
This
On Fri, Oct 14, 2005 at 02:14:10PM -0700, Kean Johnston wrote:
> How can that possibly ever work? Is the assumption then
> that the only code GCC will ever work with is code that
> GCC compiled? In effect what this implies is that GCC
> is re-defining the ABI.
Yes. You can thank Intel for this.
One of the classic places that sparse bitmaps were used in GCC in the
past is in register allocation phase, where you essentially have a 2D
sparse matrix with # of basic blocks on one axis and pseudo register
number on the other axis. When you are compiling very large functions,
the number of basi
Yes. You can thank Intel for this.
Thank you Intel :)
With the introduction of SSE1, something had to change in order
to satisfy hardware constraints. Intel initially proposed some
scheme that performed dynamic stack alignment in functions that
use SSE1 instructions, and multiple entry poin
On Fri, Oct 14, 2005 at 04:35:48PM -0700, Kean Johnston wrote:
> This seems far less invasive that redefining an ABI.
No, it isn't less invasive.
Your first case is not too difficult. No more difficult, really,
than supporting alloca. Indeed, this is more or less exactly the
code we emit in mai
Kean Johnston wrote:
Ok I am no compiler expert, so this may be totally impossible,
and if so I'd appreciate an education, but this is what I
instinctively thought of when first thinking about this problem.
Note that never mind SSE1, even conventional 8-byte fpt, while
not requiring fpt for c
33 matches
Mail list logo
