On 8/30/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
...
I guess my overriding concern is that we're focusing heavily on the data
format here (DWARF? Something else? Memory-mappable? What compression
scheme?) and we may not have enough data. I guess we just have to pick
something and run with
Geoff,
I am assuming that quite a few of the remaining regressions at -m64
on Darwin PPC with your TImode patch applied will be resolved when Eric
posts his x86_64 patches. However there are a few in gcc.target/powerpc
which likely won't be addressed by those patches. I am seeing the following
t
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions that
are going to be inlined into the function being compiled. Getting at
those functions that are going to be inlined is where the do
Bradley,
Something still is as astray with your build configuration.
Look at my last set of results.
http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01333.html
I only have 28 unexpected failures for g++ at -m64 and you
have 1350. Likewise for libstdc++ at -m64, I only have 6
unexpected fail
After some discussion with Jack Howarth, I have found that the
gfortran and libgomp executable tests on powerpc-apple-darwin8.7.0
(at least) do not link the correct, just-built-using-"make
bootstrap", libraries until those libraries have first been installed
in $prefix/lib/...
I filed a b
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>
>
>> This
>> will be more cumbersome if we have to keep reloading each object
>> file's abbrev table just to tear apart a single function in that .o
>> file. While the abbrev sections average slightly less than %2 of the
>> of the size of the GIMPLE
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
[I'm sorry for not replying to this sooner. I've been on a plane or in
a meeti
Hello,
> I have been trying to insert function calls during a new pass in the
> compiler but it does not seem to like my way of doing it. The basic
> idea is to insert a function call before any load in the program
> (later on I'll be selecting a few loads but for now I just want to do
> i
In create_omp_child_function, an identifier for the new function is
created. We then create a call to it using build_function_call_expr in
expand_parallel_call.
Ok so that's what I saw, is this call necessary for what I'd need :
decl = lang_hooks.decls.pushdecl (decl);
Then simplifying the
Follows the build info:
config.guess:
i386-pc-mingw32
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../source/gcc-4.1.1/configure --prefix=/mingw
--host=mingw32 --target=mingw32 --program-prefix="" --with-gcc --with-gnu-ld
--with-gnu-as --enable-threads --disable-nls --enab
[EMAIL PROTECTED] wrote on 08/30/06 16:41:
> Is that a necessary process for the declaration of a function ? I ask
> because I do not want the compiler to compile directly my function but
> rather ask the linker to take care of that (it will be an external
> function).
>
Oh, so you only want to i
Browse through omp-low.c. In particular create_omp_child_function
I understand the beginning of the function with its declaration of the
function but I have a question about these lines :
/* Allocate memory for the function structure. The call to
allocate_struct_function clobbers CFUN
Sorry,
I made a mistake with the printf()-formatting-
charcters.
Greetings, Uwe
Hi,
I compiled the follwing code with gcc -shared buglib.c -o buglib.dll:
>>> buglib.h is:
struct T
{
double x[256];
double y[256];
int i;
};
struct T fun(int a);
>>> buglib.c is
#include "buglib.h"
struct T fun(int a)
{
struct T retval;
i
Andrew Pinski wrote:
It happened again. This checkin:
Yes, we did discuss it before - sorry, HJ; I am trying to get as much
done before I am forced to reduce my work on gfortran. It is much easier
to do multiple patches but I will desist.
Yes the standard thing is one checkin pre fix
> [...]
> KZ> +case TRUTH_NOT_EXPR:
> KZ> +case VIEW_CONVERT_EXPR:
> KZ> +#if STUPID_TYPE_SYSTEM
> KZ> + output_type_ref (ob, TREE_TYPE (expr));
> KZ> +#endif
>
> I think VIEW_CONVERT_EXPR needs to be treated like NOP_EXPR and
> CONVERT_EXPR in the STUPID_TYPE_SYSTEM case. VIEW_CONVE
> "KZ" == Kenneth Zadeck <[EMAIL PROTECTED]> writes:
KZ> 2) To have a discussion about the use of DWARF3. I am now against the
KZ> use of DWARF3 for encoding the GIMPLE.
FWIW your arguments convinced me.
I think what matters most is that the resulting format be relatively
well documented (s
[EMAIL PROTECTED] wrote on 08/30/06 14:44:
> Does anyone have any ideas on to how I can modify my function and get it
> to insert the functions correctly ?
>
Browse through omp-low.c. In particular create_omp_child_function and
expand_omp_parallel. The new function needs to be added to the call
> It happened again. This checkin:
Yes the standard thing is one checkin pre fix. but it also annoying that you
(HJL)
don't understand how to file a bug report which is actually documented.
-- Pinski
On Sun, Jul 30, 2006 at 04:38:38PM -0700, H. J. Lu wrote:
> When one checkin is used to fix multiple bugs, it isn't easy to back
> out just the offending bug fix only if one of the bug fixes causes
> regression. Can we limit one bug fix per checkin?
>
> Thanks.
It happened again. This checkin:
h
Dear all,
I have been trying to insert function calls during a new pass in the
compiler but it does not seem to like my way of doing it. The basic
idea is to insert a function call before any load in the program
(later on I'll be selecting a few loads but for now I just want to do
it for
On Wed, Aug 30, 2006 at 06:18:06PM +0100, Dave Korn wrote:
> Do you know if the included copy of $prefix/man/man7/gpl.7 counts as a
> "written offer"?
We're way off topic, so I'll reply to Dave offline. It appears otherwise
we'll have a big gnu.misc.discuss thread here.
Sebastian Pop wrote:
> In my opinion the patch needs major rework and improvements to be
> included in trunk.
Here is my short review of the mygcc patch that lists some possible
improvements and things that have to be redesigned:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00616.html
Joe Buck wrote:
> On Wed, Aug 30, 2006 at 06:52:59PM +0200, Basile STARYNKEVITCH wrote:
> > Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
> > >
> > > Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
> > > seems to be an extended GCC to add some kind of static an
On 30 August 2006 17:53, Joe Buck wrote:
> On Wed, Aug 30, 2006 at 06:36:19PM +0200, Basile STARYNKEVITCH wrote:
>> Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
>> seems to be an extended GCC to add some kind of static analysis.
>>
>> I'm quite surprised that the mygcc page g
On Wed, Aug 30, 2006 at 06:52:59PM +0200, Basile STARYNKEVITCH wrote:
> Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
> >
> > Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
> > seems to be an extended GCC to add some kind of static analysis.
> >
> > I'm quite
Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
>
> Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
> seems to be an extended GCC to add some kind of static analysis.
>
> I'm quite surprised that the mygcc page gives x86/linux binaries, but
> no source tarball o
On Wed, Aug 30, 2006 at 06:36:19PM +0200, Basile STARYNKEVITCH wrote:
> Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
> seems to be an extended GCC to add some kind of static analysis.
>
> I'm quite surprised that the mygcc page gives x86/linux binaries, but
> no source tarball
Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
seems to be an extended GCC to add some kind of static analysis.
I'm quite surprised that the mygcc page gives x86/linux binaries, but
no source tarball of their compiler (this seems to me against the
spirit of the GPL licence, but
On 30 August 2006 15:11, kernel coder wrote:
> hi,
> I'm having some problem during build up of libgcc2 in function
> __floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
> backend.The error is
>
> ../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
> ../../gcc-4.1.0/gcc/l
hi,
I'm having some problem during build up of libgcc2 in function
__floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
backend.The error is
../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation fault
Using:
> ../gcc-4.1.1/configure --host=mingw32 --build=mingw32 --target=mingw32
> --enab
le-threads --enable-optimize --disable-nls --enable-languages=c,c++,fortran
--p
refix=/c/prog/mingw4 --with-cpu=pentium4 --with-ld=/c/prog/mingw4/bin/ld.exe
--
with-as=/c/prog/mingw4/bin/as.exe --with-gmp=/c/
On 8/30/06, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> bits/atomicity.h has volatile qualifiers on the _Atomic_word* arguments to
> the __*_single and __*_dispatch variants of the atomic operations. This
> huts especially the single-threaded optimization variants which are usually
> inlined.
> bits/atomicity.h has volatile qualifiers on the _Atomic_word* arguments to
> the __*_single and __*_dispatch variants of the atomic operations. This
> huts especially the single-threaded optimization variants which are usually
> inlined. Removing those qualifiers allows to reduce code size sig
34 matches
Mail list logo
