On 10/1/06, David Edelsohn <[EMAIL PROTECTED]> wrote:
Without such a commitment and follow-through, I am not sure
whether the potential reward of greater involvement from Apple is worth
the risk of unfixed problems dragging down GCC releases.
While I sympathize with your position, consi
Jack Howarth writes:
>I noticed that on Darwin PPC we get warnings of the form...
>
> symbol _fabsf used from dynamic library /usr/lib/libm.dylib(fabs.o) not from
> earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(sf_fabs.o)
> symbol _fabs used from dynamic library /usr/lib/libm.d
Mark Mitchell <[EMAIL PROTECTED]> wrote on 29/09/2006 01:55:24:
> Razya Ladelsky wrote:
>
> > Except for new optimizations, IPCP (currently on mainline) should also
be
> > transformed to SSA.
> > IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3
> > after IPA branch
> >
Im doing a program that reads in stuff from the serial port under linux.
Once read in there is a bit of formatting and it then needs to get piped
to something else. At the end is the cut down code.
anyway the interesting part is in the while loop the rest is just formatting.
while (1)
{
On Sunday 01 October 2006 15:34, Owen Lucas wrote:
>
> Im doing a program that reads in stuff from the serial port under linux.
> Once read in there is a bit of formatting and it then needs to get piped
> to something else. At the end is the cut down code.
>
> anyway the interesting part is in th
On 01 October 2006 14:34, Owen Lucas wrote:
> Im doing a program that reads in stuff from the serial port under linux.
> Once read in there is a bit of formatting and it then needs to get piped
> to something else. At the end is the cut down code.
This is a question for the gcc-help list, not t
Andrew,
I could be wrong here but if you really
intend to avoid using the system version of
those math calls, the appropriate thing to do
is to rename them in java as local versions
(eg java_sf_fabsf, etc).
Jack
Hmm... I just noticed that fixincludes is applying the
strict_ansi_not, strict_ansi_not_ctd and strict_ansi_only fixes on
solaris. Recall, these are the fixes that replace various checks on
__STDC__ with __STRICT_ANSI__. I'm pretty sure it's not supposed to
be applied on solaris. All of these fi
Kaveh R. Ghazi wrote:
Thoughts on fixing it?
Blech! :-)
However I believe since fixincludes moved to the top level directory
we're no longer looking in the target headers and getting that
definition and thus the __STRICT_ANSI__ changes are always applied,
even when they're not supposed to be
Richard Kenner wrote:
That doesn't explain why the bit value isn't normalized to be smaller
than BITS_PER_UNIT; any whole bytes could be incorporated into the
variably sized offset.
It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN since
we are asserting that DECL_FIELD_OFFSET
Daniel Berlin wrote:
I really object to darwin being a primary platform until it is
actually possible to build it on a released darwin system without
passing extra configure flags, etc.
It seems every couple weeks something new is broken in the configure
so that you have to add another flag.
Re
[This is a copy of the mail I sent to the SC regarding primary and
secondary platforms for 4.3. I tried to get everyone's input included;
if I left anything out, it was an oversight. Please feel free to
contact the SC directly, or to ask me to forward additional information,
if you have other
> > However I believe since fixincludes moved to the top level
> > directory we're no longer looking in the target headers and getting
> > that definition and thus the __STRICT_ANSI__ changes are always
> > applied, even when they're not supposed to be.
> > Am I reading the situation corr
Geoff,
Can you explain why we don't have...
Index: unwind-dw2-fde-darwin.c
===
--- unwind-dw2-fde-darwin.c (revision 117350)
+++ unwind-dw2-fde-darwin.c (working copy)
@@ -61,7 +61,7 @@ struct mach_header;
struct mach_hea
> > It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN since
> > we are asserting that DECL_FIELD_OFFSET is aligned to DECL_OFFSET_ALIGN.
>
> That doesn't make sense to me. It seems to me that we can normalize it
> however we please; ultimately, all these representations just give
On Oct 1, 2006, at 7:57 PM, Richard Kenner wrote:
It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN
since
we are asserting that DECL_FIELD_OFFSET is aligned to
DECL_OFFSET_ALIGN.
That doesn't make sense to me. It seems to me that we can
normalize it
however we please; ul
16 matches
Mail list logo
