On Nov 11, 2006, at 10:45 PM, Howard Chu wrote:
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exem
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exemption, it would be impossible to write
malloc in
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
>
> Your code will be safe on all counts if you change buf from int[] to
> char[]. The language standard grants a special exemption to char*
> pointers. Without that exemption, it would be impossible to write
> malloc in C.
Actually it
Howard Chu <[EMAIL PROTECTED]> writes:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> struct foo
On 12 November 2006 04:16, Howard Chu wrote:
> Dave Korn wrote:
>> On 12 November 2006 03:35, Howard Chu wrote:
>>
>>
>>> If we go through the temporary variable v, there's no warning. If we
>>> don't use the temporary variable, we get the "might break" message.
>>>
>>
>> Try
>>
>>
>>>
Ross Ridge wrote:
>Umm... those 80 processors that Intel is talking about are more like the
>8 coprocessors in the Cell CPU.
Michael Eager wrote:
>No, the Cell is asymmetrical (vintage 2000) architecture.
The Cell CPU as a whole is asymmetrical, but I'm only comparing the
design to the 8 identic
On 12 November 2006 03:35, Howard Chu wrote:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> str
Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a
Ian Lance Taylor wrote:
Howard Chu <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
We ask the TBAA analyzer "can a store to a short * touch i.
In this case, it says "no", because it's not legal.
If you know the code is not legal, why don't you abort the compilation
with an er
Howard Chu wrote:
It also somewhat blurs the
distinction between a fully linked executable file and an intermediate
relocatable object, since executables can also be incrementally
relinked. It's a real timesaver when you just need to fix one file in a
very large program.
a proper fix-and-con
* /From/: Bud Davis
* /Date/: Sat, 11 Nov 2006 16:06:44 -0800 (PST)
it is a rare single file that takes more than 30
seconds to compile (at least with gcc3 and higher).
linking the largest executable takes about 3 minutes.
(sorry to be so long-winded getting to the topic!!)
ordinar
my 'day job' is a medium sized software operation. we
have between 5 and 50 programmers assigned to a given
project; and a project is usually a couple of thousand
source files (mix of f77,c,c++, ada). all this source
get's stuck in between 50 and 100 libraries, and the
end result is less than a d
On Sat, 11 Nov 2006, Paul Thomas wrote:
> Steven and Jerry,
> >
> >
> > If someone can confirm that this patch causes the drop, I can help
> > trying to find a fix.
> >
> amd64/Cygwin_NT
>
> $ /irun/bin/gfortran -O3 -funroll-loops -ffast-math -march=opteron ac.f90
>
> 118372 20.2s
> 118475
On 11/11/06, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
-fno-rounding-math enables the transformation of (-(X - Y)) -> (Y - X)
in simplify-rtx.c which seems to be the same transformation
that enabled by -funsafe-math-optimizations in fold-const.c.
If I understand currently -frounding-mat
Steven and Jerry,
If someone can confirm that this patch causes the drop, I can help
trying to find a fix.
amd64/Cygwin_NT
$ /irun/bin/gfortran -O3 -funroll-loops -ffast-math -march=opteron ac.f90
118372 20.2s
118475 20.4s Bonzini's patch
118704 16.2s
I believe that the improv
Hello,
-fno-rounding-math enables the transformation of (-(X - Y)) -> (Y - X)
in simplify-rtx.c which seems to be the same transformation
that enabled by -funsafe-math-optimizations in fold-const.c.
If I understand currently -frounding-math means that the rounding mode is
important.
In that cas
On 11/11/06, Paul Thomas <[EMAIL PROTECTED]> wrote:
Richard,
>
> If I had to guess I would say it was the forwprop merge...
The what? :-)
fwprop, see
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00141.html
If someone can confirm that this patch causes the drop, I can help
trying to find a fix.
Richard,
If I had to guess I would say it was the forwprop merge...
The what? :-)
Paul
On Sat, 11 Nov 2006, FX Coudert wrote:
> >Just wanted to note to the list that Tobias spotted a performance regression
> >on Polyhedron ac.
> >
> >http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
>
> Hum, the performance change on ac is significant. Anyway we can ge
On 11/11/06, FX Coudert <[EMAIL PROTECTED]> wrote:
> Just wanted to note to the list that Tobias spotted a performance
> regression on Polyhedron ac.
>
> http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-
> summary.txt-2-0.html
Hum, the performance change on ac is significant. Anyway we
Just wanted to note to the list that Tobias spotted a performance
regression on Polyhedron ac.
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-
summary.txt-2-0.html
Hum, the performance change on ac is significant. Anyway we can get
the revision numbers before and after the jump
> Each of the functions in a C/C++ program is dependent on
> the global environment, but each is independent of each other.
> Separate threads could process the tree/RTL for each function
> independently, with the results merged on completion. This
> may interact adversely with some global optimiz
Jack Howarth wrote:
Does anyone know how the changes for gcc to require gmp/mpfr will effect the
multilib builds? In the past, gmp/mpfr in gfortran appeared to only be linked
into
the compiler itself so that a 32-bit/64-bit multilib build on Darwin PPC only
required gmp/mpfr for 32-bit to be
Howard Chu <[EMAIL PROTECTED]> writes:
> Daniel Berlin wrote:
> >
> > We ask the TBAA analyzer "can a store to a short * touch i.
> > In this case, it says "no", because it's not legal.
> >
> If you know the code is not legal, why don't you abort the compilation
> with an error code?
It's not act
Geert Bosch wrote:
Most of my compilations (on Linux, at least) use close
to 100% of CPU. Adding more overhead for threading and
communication/synchronization can only hurt.
On a single-processor system, adding overhead for multi-
threading does reduce performance. On a multi-processor
system
Mike Stump wrote:
Thoughts?
Parallelizing GCC is an interesting problem for a couple
reasons: First, the problem is inherently sequential.
Second, GCC expects that each step in the process happens
in order, one after the other.
Most invocations of GCC are part of a "cluster" of similar
invoc
Does anyone know how the changes for gcc to require gmp/mpfr will effect the
multilib builds? In the past, gmp/mpfr in gfortran appeared to only be linked
into
the compiler itself so that a 32-bit/64-bit multilib build on Darwin PPC only
required gmp/mpfr for 32-bit to be installed. Will any of
Ross Ridge wrote:
Mike Stump writes:
We're going to have to think seriously about threading the compiler. Intel
predicts 80 cores in the near future (5 years). [...] To use this many
cores for a single compile, we have to find ways to split the work. The
best way, of course is to have make -j80
> > whole-program optimisation and SMP machines have been around for a
> > fair while now, so I'm guessing not.
>
> I don't know of anything that is particularly hard about it, but, if
> you know of bits that are hard, or have pointer to such, I'd be
> interested in it.
You imply you're consider
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program "int main() { return 0; }". GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
(http://sourceware.org/ml/newlib/2006/msg0
Snapshot gcc-4.3-2006 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-2006/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Sat, Nov 11, 2006 at 04:16:19PM +, Paul Brook wrote:
> I don't know how much of the memory allocated is global readonly data (ie.
> suitable for sharing between threads). I wouldn't be surprised if it's a
> relatively small fraction.
I don't have numbers on global readonly, but in typical
> Let's just say, the CPU is doomed.
So you're building consensus for something that is doomed?
> > Seriously thought I don't really understand what sort of response
> > you're expecting.
>
> Just consensus building.
To build a consensus you have to have something for people to agree or
disagre
Howard Chu wrote:
> extern void getit( void **arg );
>
> main() {
>union {
>int *foo;
>void *bar;
>} u;
>
>getit( &u.bar );
>printf("foo: %x\n", *u.foo);
> }
Rask Ingemann Lambertsen wrote:
> As far as I know, memcpy() is the answer
> I don't know whether there are any functions nested inside nested
> functions which do non-local gotos in the Ada testsuite.
There aren't now. But there will be plenty when a transformation that changes
raises of exceptions to gotos to a visible exception handler is finished.
I'll use the C te
Howard Chu <[EMAIL PROTECTED]> writes:
> That's good to know, thanks. But frankly that's braindead to require
> someone to add all these new union declarations all over their code,
There is no need for any union trick in your example. Just use a
temporary with the correct type, and you have stri
* /From/: Mike Stump
* /To/: GCC Development
* /Date/: Fri, 10 Nov 2006 12:38:07 -0800
* /Subject/: Threading the compiler
We're going to have to think seriously about threading the compiler.
Intel predi
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote:
I'd guess we win more by writing object files directly to disk like
virtually every other compiler on the planet.
The cost of my assembler is around 1.0% (ppc) to 1.4% (x86) overhead
as measured with -pipe -O2 on expr.c,. If it was converted,
38 matches
Mail list logo
