Ira Rosen wrote:
>
> > Here is the documentation for the data dependence analysis.
>
> I can add a description of data-refs creation/analysis if it is useful.
>
That's a good idea, thanks.
Sebastian
It is probably too late to get this resolved before gcc trunk branches
but we have an outstanding patch for building gcj on Darwin/386 awaiting
on Sandro Tolaini's paperwork being processed. He told me that he scanned
the form back to [EMAIL PROTECTED] but still hasn't heard back yet.
The refer
The snapshot gcc-4.2.0-20060902 stops compiling jikes-1.22.tar.bz2.
The snapshot gcc-4.2.0-20060906 stops compiling jikes-1.22.tar.bz2 too.
It doesn't ocurr with gcc-3.3.6, gcc-4.1.2-20060901 and
gcc-4.0.4-20060831, they are OK.
$ gcc -v
Using built-in specs.
Target: i486-slackware-linux
Configu
On Fri, 2006-09-08 at 15:40 +0200, Anny Blackyew wrote:
> The snapshot gcc-4.2.0-20060902 stops compiling jikes-1.22.tar.bz2.
> The snapshot gcc-4.2.0-20060906 stops compiling jikes-1.22.tar.bz2 too.
I think I just fixed this last night. Can you try again?
Thanks,
Andrew Pinski
Sorry for my own slow response -- I've been doing more digging through
code, and didn't want to respond without a reasonable understanding...
Richard Kenner wrote:
>> However, in the case where we're passing the address of a temp slot to a
>> function, it doesn't make sense to me that this is the
I am confused with gcc configuration, and I cannot determine if I have a bug
or if I am misconfiguring the compiler. Here is the situation:
gcc sources: 4.2 snapshot of 20060905
If compiler is configured with:
--target=powerpc-*-linux-gnualtivec
then I have the following libraries and everythin
On Fri, 8 Sep 2006, Edmar Wienskoski wrote:
> So the key questions are:
> 1 - What should I expect in regards to __lttf2 (and similar symbols).
> (like, when they should be defined, referenced, and when not)
They should not be defined or used at all. IBM long double should use
__gcc_*, and IEEE
Soft-float implementation of long double support is in development
but not complete. Long double requires double precision registers, so it
only will work with e500 double. It also requires floating point
multiply-subtract (fmsub), which e500 double does not appear to
implement. This is
Hello ALL!
I'm working in a project to automatic create parallel code for anthill
program model
http://homepages.dcc.ufmg.br/~dorgival/artigos/sbac2005.pdf
the goal is to translate a C uniq source into various C source files
that represent the parallelized code. I've been looking for a compiler
GCC accepts the -T
On Fri, 8 Sep 2006, David Edelsohn wrote:
> Soft-float implementation of long double support is in development
> but not complete. Long double requires double precision registers, so it
> only will work with e500 double. It also requires floating point
> multiply-subtract (fmsub), which e5
Ok. I am starting to see the whole picture now.
So the whole thing appears to work with --disable-shared, just because
the way the linker
loads symbols in presence of libgcc_s.so versus libgcc.a.
Follow up question:
The e500 abi actualy defines long double to be 128bits floats.
On rs6000.c, rs6
On Fri, 8 Sep 2006, Edmar Wienskoski wrote:
> Ok. I am starting to see the whole picture now.
> So the whole thing appears to work with --disable-shared, just because the way
> the linker
> loads symbols in presence of libgcc_s.so versus libgcc.a.
>
> Follow up question:
> The e500 abi actualy de
Michael Eager <[EMAIL PROTECTED]> writes:
> GCC accepts the -T
Snapshot gcc-4.1-20060908 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060908/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hallo,
I sent to binutils the patch for the new x86_64-pc-mingw64 as cross
target.I was asked to post about this patch also to you. May this new
target is of some interest to you and you can help me to verify this
patch, because at the binutils there are not much windows users :|
Best regards,
Hi...
[EMAIL PROTECTED] wrote on 08.09.2006 10:33:04:
> Hallo,
>
> I sent to binutils the patch for the new x86_64-pc-mingw64 as cross
> target.I was asked to post about this patch also to you. May this new
> target is of some interest to you and you can help me to verify this
> patch, because a
Andrew Pinski wrote:
On Wed, 2006-09-06 at 15:00 -0700, Michael Eager wrote:
GCC passes a linker script to the linker for some
targets (e.g., powerpc-eabi with -mads). If you specify a
linker script using -Wl,-T,script.ld, you get both
passed to the linker and there may be conflicts.
Is there
Kenny Simpson wrote:
What is the status of the 4.1 branch? Any word on 4.1.2?
My current plan is to do a 4.1.2 along with 4.2.0. My concern has been
that with 4.2.0 moving slowly, trying to organize another release might
just distract the developer community.
However, I realize that's a p
I don't know if this is related to Eric's checkins tonight
but I can no longer build libgfortran on Darwin PPC. The build fails
at...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/dar
To correct the typo in the last message, I am now rebuilding
without the reduced TImode patch to confirm it is not at fault.
As I said, since the build craps out in the 32-bit sections, I
doubt it is the source of the libgfortran build failure.
Jack
I should add that the last good build I have is from last
night at revision r116774.
Jack
Okay. The problem with the libgfortran build failing is
unrelated to the remaining sections of the TImode patch.
I see the same failure with an unpatched version of current
gcc trunk. Time to file a PR.
Jack
ps I am currently building (for the last couple of days)
with --disable-boo
I notice a warning in the Darwin PPC build of gcc trunk against
libiconv 1.10. There appears to be a duplicate symbol for _locale_charset
in both ./../intl/libintl.a(localcharset.o) and
/sw/lib/libiconv.dylib(localcharset.o).
Shouldn't the presence of duplicate symbols in the linkage of cc1plu
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00667.html
-- Pinski
Andrew,
Thanks for the hint. I make the patch as being only...
===
--- intl/localcharset.c (revision 116795)
+++ intl/localcharset.c (working copy)
@@ -23,6 +23,13 @@
# include
#endif
+#if !HAVE_ICONV
+
+/* Provide our varian
Andrew,
Doesn't the proposed patch to intl/localcharset.c pretty
much fall under the obvious rule?
Jack
27 matches
Mail list logo
