>
> I was looking in to a degradation for perlbmk on PowerPC and tracked it
> down to a mispredicted branch within a loop ( if (...) return 0; within
> the loop). GCC is statically predicting the loop exit as not taken "bne-",
> but it is obviously being taken the greatest share of the time be
Geoff,
I am still puzzled by your statement that ".1.dylib files should never be
used
directly in a link". With both gcc trunk and Xcode 2.3, the following...
[Jack-Howarths-Computer:~] howarth% gcc -O3 -m64 modulo.c -shared-libgcc
[Jack-Howarths-Computer:~] howarth% otool64 -L ./a.out
./a.ou
Eric Botcazou wrote:
> Obvious question: what of the RTL expander(s)?
They're specifically excluded from your purview. (That's not a judgment
on your competence; just that the definition we used when discussing
your appointment restricted itself to RTL passes only.)
Thanks,
--
Mark Mitchell
C
I was looking in to a degradation for perlbmk on PowerPC and tracked it
down to a mispredicted branch within a loop ( if (...) return 0; within
the loop). GCC is statically predicting the loop exit as not taken "bne-",
but it is obviously being taken the greatest share of the time because when
> And back to my original answer: it's up to each language to decide
> that.
Hence my original question: is it legal or not? What did the C++
developers decide?
>That puts it back to the original question. Is the program legal or
>not? I.e. do we support multiple simultaneous pointer sizes?
And back to my original answer: it's up to each language to decide that. We
provide the infrastructure for a language to provide it if it wants it.
> I'd say so, but is more likely is in the ICE-on-illegal-program
> class.
That puts it back to the original question. Is the program legal or
not? I.e. do we support multiple simultaneous pointer sizes?
> > The middle-end and relevant back-ends support it, but clearly not
> > all the front ends. C and Ada does but your experiment seems to
> > show that C++ does not.
>
> Does this mean that there's a bug in the C++ front end?
I'd say so, but is more likely is in the ICE-on-illegal-program class.
> Who's "we"?
"We" means "gcc".
> The middle-end and relevant back-ends support it, but clearly not
> all the front ends. C and Ada does but your experiment seems to
> show that C++ does not.
Does this mean that there's a bug in the C++ front end?
Geoff,
Looking at this from Xcode 2.3, which doesn't have a dylib for ppc64,
"nm libgcc.a | grep ti" doesn't show anything whereas on x86_64 FC5 Linux
this shows all the TImode symbols. This result isn't surprising since
the gcc 4.0.1 in Xcode 2.3 can't resolve the symbols as well when the
stati
Geoff,
So does that make it a linker bug (ie in odcctools 590-20060608)?
I would note that I see the same problem with the modulo.c and division.c
test cases if I disable fink (remove it from my path) and compile those
sources with the Xcode 2.3 gcc compiler using -m64.
Also I am puzzled by y
On 06/08/2006, at 8:11 PM, David Edelsohn wrote:
I believe that Andrew Pinski diagnosed the problem as divti3 and
modti3 not being listed in the symbol export file for Darwin when
64-bit
support was added.
It is unfortunate that these files cannot have comments, because it
seems
On 06/08/2006, at 9:10 PM, Jack Howarth wrote:
David,
My understanding was that only libgcc_s.10.4.dylib and libgcc_s.
10.5.dylib
required the entries in their .ver files for exporting symbols. The
-m64
flag on Darwin causes libgcc_s_ppc64.1.dylib to be used for the linked
libgcc.
The
> Jack Howarth writes:
Jack> A few questions. Does linuxppc64 use the libgcc-ppc64.ver in
Jack> gcc/config/rs6000 or does it use the stock libgcc-std.ver in the
Jack> gcc directory? I am still unclear which 'owns' libgcc-ppc64.ver
Jack> since it doesn't have darwin explicitly in its name. Also
Hi List
I am very much confused about Increment Operator implementation. Can
somebody send me a link about the gcc implementation.
On 8/6/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Is there a way to enable such exotic codegen for 32bit environments?
With libgcc-math you didn't have exotic instructions, but you had
trascendental operations compiled with -mfpmath=sse and with a special
ABI. -mfpmath=sse won about 8% over
16 matches
Mail list logo
