bootstrap failure on powerpc-linux
Anyone else seeing this? libtool: compile: /scratch/bje/bootstrap/./gcc/xgcc -shared-libgcc -B/scratch/bje/bootstrap/./gcc -nostdinc++ -L/scratch/bje/bootstrap/powerpc-linux/libstdc++-v3/src -L/scratch/bje/bootstrap/powerpc-linux/libstdc++-v3/src/.libs -B/usr/local/powerpc-linux/bin/ -B/usr/local/powerpc-linux/lib/ -isystem /usr/local/powerpc-linux/include -isystem /usr/local/powerpc-linux/sys-include -I/scratch/bje/bootstrap/powerpc-linux/libstdc++-v3/include/powerpc-linux -I/scratch/bje/bootstrap/powerpc-linux/libstdc++-v3/include -I/home/bje/source/gcc-trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -std=gnu++0x -c /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc -fPIC -DPIC -o .libs/date_time.o /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:28:21: error: date_time: No such file or directory /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:32: error: 'system_time' does not name a type /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:39: error: 'nanoseconds' has not been declared /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:39: error: expected initializer before 'nanoseconds' /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:40: error: 'nanoseconds' has not been declared /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:40: error: expected initializer before 'nanoseconds' /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:41: error: 'nanoseconds' has not been declared /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:41: error: uninitialized const 'std::is_subsecond' /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:43: error: 'system_time' has not been declared /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:43: error: expected initializer before 'system_time' /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:44: error: 'system_time' has not been declared /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:44: error: expected initializer before 'system_time' /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:45: error: 'system_time' has not been declared /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:45: error: redefinition of 'const bool std::is_subsecond' /home/bje/source/gcc-trunk/libstdc++-v3/src/date_time.cc:41: error: 'const bool std::is_subsecond' previously declared here Ben
Re: bootstrap failure on powerpc-linux
On Mon, Mar 17, 2008 at 12:58 AM, Ben Elliston <[EMAIL PROTECTED]> wrote: > Anyone else seeing this? The file was forgotten in the original commit it was fixed by the following revision: r133278 | paolo | 2008-03-16 11:35:44 -0700 (Sun, 16 Mar 2008) | 34 lines Changed paths: A /trunk/libstdc++-v3/include/std/date_time Thanks, Andrew Pinski
Re: gcc-4.1-20080303 is now available
Kaveh R. GHAZI wrote: I too think that it would be a bad idea to switch the 4.1 branch to GPLv3, Can you please elabortate why? I think it's a bad idea to change the license on a release branch in deep maintenance mode. That would be a surprise to users. The idea of such branches has always been that you could get the latest bits and just pick up some bug fixes. GPLv3 is not a bug fix in the usual sense. I argued against changing the license for 4.2.x for the same reasons, but was overruled by RMS. But, there, for all practical purposes, we had to make a new release. It would be in keeping with our past practice to let 4.1.x slowly wither away at this point. That said, I'm not going to argue this too forcefully. If someone wants to do all the work to update everything to GPLv3 and do a release, so be it. I would just ask that the GPLv3-ness of the release be made aggressively obvious. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
An error occured when building gcc4.3.0
Hi I am new to this list. I try compiling gcc4.3.0 on mips machine
with the follow command :
../gcc-4.3.0/configure --prefix=/home/lpeng/install/gcc-4.3.0
--target=mipsel-linux --host=mipsel-linux --bui\
ld=mipsel-linux --enable-threads=posix --enable-shared --disable-checking
--with-gmp=/home/lpeng/install/gcc-4.3.\
0/gmp/ --with-mpfr=/home/lpeng/install/gcc-4.3.0/mpfr/ -v
but an error as follow described happened when making gcc :
checking for suffix of object files... configure: error: cannot compute
suffix of object files: cannot compile
See `config.log' for more details.
and I have read config.log ,there are three errors;
1,conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'me'
2,conftest.cc:13: error: 'exit' was not declared in this scope
3,configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }
please help me! thanks!
peng liang
RE: gcc-4.1-20080303 is now available
Eric Botcazou wrote on : > > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago. > > By accident I presume? As an epiphenonmenal side-effect of being regenerated with the latest version of autogen rather than an older one. It could always be reverted and/or re-regenerated with an older version. cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc-4.1-20080303 is now available
On Mon, Mar 17, 2008 at 9:07 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Kaveh R. GHAZI wrote: > > >> I too think that it would be a bad idea to switch the 4.1 branch to > >> GPLv3, > > > > Can you please elabortate why? > > I think it's a bad idea to change the license on a release branch in > deep maintenance mode. That would be a surprise to users. The idea of > such branches has always been that you could get the latest bits and > just pick up some bug fixes. GPLv3 is not a bug fix in the usual sense. > > I argued against changing the license for 4.2.x for the same reasons, > but was overruled by RMS. But, there, for all practical purposes, we > had to make a new release. It would be in keeping with our past > practice to let 4.1.x slowly wither away at this point. > > That said, I'm not going to argue this too forcefully. If someone wants > to do all the work to update everything to GPLv3 and do a release, so be > it. I would just ask that the GPLv3-ness of the release be made > aggressively obvious. You mean like calling it gcc 4.4.0? :P Honestly let's not offer this to someone who likes to do the work. Richard.
Re: An error occured when building gcc4.3.0
On Mon, 2008-03-17 at 18:09 +0800, [EMAIL PROTECTED] wrote: > Hi I am new to this list. I try compiling gcc4.3.0 on mips machine > with the follow command : This list is for discussing the development of GCC, not building and installing it. Please direct your question to [EMAIL PROTECTED] Thanks, Ben
Re: Been Looking how gcc operates there is a major weaknesses in its optimiser.
Peter Dolding wrote: > Ian Lance Taylor wrote: >> "Peter Dolding" <[EMAIL PROTECTED]> writes: >> >> >>> Since test is in a different object file it gets completely skiped >>> from optimising even that it should be optimised out. >>> >> >> http://gcc.gnu.org/wiki/LTO_Driver >> >> Ian >> > Ok that is half my idea. Let it sort out at link stage. But that does > not cover like libc and dynamic dependencies. And it can't, either, at least not on GNU/Linux. When a bug fix is imported into glibc, every user of glibc immediately benefits. That's one of the reasons we don't link statically on that system. This is far more important than the performance issue. Andrew.
insn appears multiple times
Hi!
For my architecture with 4 branch delay slots I get the following
RTL in my target dependent reorg pass:
(insn 966 361 364 ../src/XXX.c:1666 (sequence [
(jump_insn 362 361 381 ../src/XXX.c:1666 (set (pc)
(if_then_else (ne (reg:CC 49 CONDSEL)
(const_int 0 [0x0]))
(label_ref:SI 965)
(pc))) 40 {bCOND_internal}
(insn_list:REG_DEP_TRUE 361 (nil))
(expr_list:REG_BR_PRED (const_int 4 [0x4])
(expr_list:REG_DEAD (reg:CC 49 CONDSEL)
(expr_list:REG_BR_PROB (const_int 8100
[0x1fa4])
(nil)
(insn 381 362 364 (set (reg:SI 3 R3 [orig:135 refIdxL0A.
100 ] [135])
(mem/c/i:SI (reg/f:SI 44 A12) [0 refIdxL0A+0 S32
A32])) 2 {load_register_internal} (nil)
(nil))
]) -1 (nil)
(nil))
(note 364 966 366 [bb 34] NOTE_INSN_BASIC_BLOCK)
...
(note 372 370 375 [bb 35] NOTE_INSN_BASIC_BLOCK)
...
(note 380 967 381 [bb 36] NOTE_INSN_BASIC_BLOCK)
(insn 381 380 965 ../src/XXX.c:1666 (set (reg:SI 3 R3 [orig:135
refIdxL0A.100 ] [135])
(mem/c/i:SI (reg/f:SI 44 A12) [0 refIdxL0A+0 S32 A32])) 2
{load_register_internal} (nil)
(nil))
insn 381 appears in the delay slot and later in another basic block
(but same function). These insns are equal but they are not the same,
two disjunct pieces of memory.
Is this possible?
Thanks,
Boris
Basic block infrastructure after dbr pass
Hi! I inspect code after branch delay slot scheduling by dumping the insn-list to a VCG-file: for(insn = get_insns(), NULL_RTX != insn; insn = NEXT_INSN(insn)) dump_insn_and_prev_and_next(insn); FOR_EACH(bb) dump_bb_and_head_and_end(bb) But some basic blocks seem to point to insns which are not in the insn-list. I had a short look at dbr_schedule() in reorg.c and the basic blocks are not updated. Are they evaluated in a later pass? Thanks, Boris
Re: Been Looking how gcc operates there is a major weaknesses in its optimiser.
On Mon, Mar 17, 2008 at 7:34 PM, Andrew Haley <[EMAIL PROTECTED]> wrote: > Peter Dolding wrote: > > Ian Lance Taylor wrote: > >> "Peter Dolding" <[EMAIL PROTECTED]> writes: > >> > >> > >>> Since test is in a different object file it gets completely skiped > >>> from optimising even that it should be optimised out. > >>> > >> > >> http://gcc.gnu.org/wiki/LTO_Driver > >> > >> Ian > >> > > Ok that is half my idea. Let it sort out at link stage. But that does > > not cover like libc and dynamic dependencies. > > And it can't, either, at least not on GNU/Linux. When a bug fix is > imported into glibc, every user of glibc immediately benefits. That's one > of the reasons we don't link statically on that system. This is far > more important than the performance issue. > > Andrew. > That would be in the same class as saying cannot optimize out sqrt out of libm because a update might change it. Not all uses of GNU/Linux are like Distributions Andrew. Sections of glibc passed constants should give 100 percent constant results. I am just proposing a automatic system to find and built data to allow them to be optimize out. Of course even just in a advisement roll to a programmer could be handy. Ok you have just asked for a constant here to be converted to a MD5 password hash. Might be a good idea to make that a internal constant instead of wasting processor time every time at this point. Adviser option or full blown both can be useful to coders. At least some of the same data would have to remain for Adviser. Ie what functions optimize out when passed constants. Full blown could even tell the coder what the possible replacement is even if it don't do it automatically. Its in the same class as lot of other optimizations. Almost no Distribution go and build with every optimization option on. So this one will be no different. Usefulness to programmers looking for blocks of code that should not be there is high as well as useful for speed hunters. I guess you want it done like math functions. Functions selected 1 at a time to be added to the optimizer fix. This is not really useful to a person doing there own internal projects. Peter Dolding
Re: gcc-4.1-20080303 is now available
On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote: > Eric Botcazou wrote on : > > > > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago. > > > > By accident I presume? > > > As an epiphenonmenal side-effect of being regenerated with the latest > version of autogen rather than an older one. It could always be reverted > and/or re-regenerated with an older version. The fixincl.x change on 4.1 branch should be IMNSHO reverted. Jakub
RE: gcc-4.1-20080303 is now available
Jakub Jelinek wrote on 17 March 2008 12:00: > On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote: > > Eric Botcazou wrote on : > > > > > > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago. > > > > > > By accident I presume? > > > > > > As an epiphenonmenal side-effect of being regenerated with the latest > > version of autogen rather than an older one. It could always be > > reverted and/or re-regenerated with an older version. > > The fixincl.x change on 4.1 branch should be IMNSHO reverted. > > Jakub I tend to agree. I'll revert this change under the own-patches rule. Bruce, have you been following this thread? Just a heads-up. cheers, DaveK -- Can't think of a witty .sigline today
RE: gcc-4.1-20080303 is now available
Dave Korn wrote on : > Jakub Jelinek wrote on 17 March 2008 12:00: > > The fixincl.x change on 4.1 branch should be IMNSHO reverted. > > I tend to agree. I'll revert this change under the own-patches rule. Done: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01004.html Apologies for the inconvenience. cheers, DaveK -- Can't think of a witty .sigline today
Re: Auto-vectorization: need to know what to expect
On Mon, Mar 17, 2008 at 3:45 PM, Benoît Jacob <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> I am currently (co-)developing a Free (GPL/LGPL) C++ library for
> vector/matrix
> math.
>
> A major decision that we need to take is, what to do regarding vectorization
> instructions (SSE). Either we rely on GCC to auto-vectorize, or we control
> explicitly the vectorization using GCC's special primitives. The latter
> solution is of course more difficult, and would to some degree obfuscate our
> source code, so we wish to know whether or not it's really necessary.
>
> GCC 4.3.0 does auto-vectorize our loops, but the resulting code has worse
> performance than a version with unrolled loops and no vectorization. By
> contrast, ICC auto-vectorizes the same loops in a way that makes them
> significantly faster than the unrolled-loops non-vectorized version.
>
> If you want to know, the loops in question typically look like:
> for(int i = 0; i < COMPILE_TIME_CONSTANT; i++)
> {
> // some abstract c++ code with deep recursive templates and
> // deep recursive inline functions, but resulting in only a
> // few assembly instructions
> a().b().c().d(i) = x().y().z(i);
> }
>
> As said above, it's crucial for us to be able to get an idea of what to
> expect, because design decisions depend on that. Should we expect large
> improvements regarding autovectorization in 4.3.x, in 4.4 or 4.5 ?
In general GCCs autovectorization capabilities are quite good, cases
where we miss opportunities do of course exist. There were improvements
regarding autovectorization capabilities in every GCC release and I expect
that to continue for future releases (though I cannot promise anything
as GCC is a volunteer driven project - but certainly testcases where we
miss optimizations are welcome - often we don't know of all corner cases).
If you require to get the absolute most out of your CPU I recommend to
provide special routines tuned for the different CPU families and I
recommend the use of the standard intrinsics headers (*mmintr.h) for
this. Of course this comes at a high cost of maintainance (and initial work),
so autovectorization might prove good enough. Often tuning the
source for a given compiler has a similar effect than producing vectorized
code manually. Looking at GCC tree dumps and knowing a bit about
GCC internals helps you here ;)
> A roadmap or a GCC developer sharing his thoughts would be very helpful.
Thanks,
Richard.
Auto-vectorization: need to know what to expect
Dear All,
I am currently (co-)developing a Free (GPL/LGPL) C++ library for vector/matrix
math.
A major decision that we need to take is, what to do regarding vectorization
instructions (SSE). Either we rely on GCC to auto-vectorize, or we control
explicitly the vectorization using GCC's special primitives. The latter
solution is of course more difficult, and would to some degree obfuscate our
source code, so we wish to know whether or not it's really necessary.
GCC 4.3.0 does auto-vectorize our loops, but the resulting code has worse
performance than a version with unrolled loops and no vectorization. By
contrast, ICC auto-vectorizes the same loops in a way that makes them
significantly faster than the unrolled-loops non-vectorized version.
If you want to know, the loops in question typically look like:
for(int i = 0; i < COMPILE_TIME_CONSTANT; i++)
{
// some abstract c++ code with deep recursive templates and
// deep recursive inline functions, but resulting in only a
// few assembly instructions
a().b().c().d(i) = x().y().z(i);
}
As said above, it's crucial for us to be able to get an idea of what to
expect, because design decisions depend on that. Should we expect large
improvements regarding autovectorization in 4.3.x, in 4.4 or 4.5 ?
A roadmap or a GCC developer sharing his thoughts would be very helpful.
Cheers,
Benoit
P.S. I have noticed huge improvements in GCC recently and would like to thank
all the developers for that. This is what makes me hope that GCC might soon
handle auto-vectorization in a way that allows me to rely on it!
signature.asc
Description: This is a digitally signed message part.
Re: Auto-vectorization: need to know what to expect
On Mon, Mar 17, 2008 at 03:45:49PM +0100, Benoît Jacob wrote:
> Dear All,
>
> I am currently (co-)developing a Free (GPL/LGPL) C++ library for
> vector/matrix
> math.
>
> A major decision that we need to take is, what to do regarding vectorization
> instructions (SSE). Either we rely on GCC to auto-vectorize, or we control
> explicitly the vectorization using GCC's special primitives. The latter
> solution is of course more difficult, and would to some degree obfuscate our
> source code, so we wish to know whether or not it's really necessary.
>
> GCC 4.3.0 does auto-vectorize our loops, but the resulting code has worse
> performance than a version with unrolled loops and no vectorization. By
> contrast, ICC auto-vectorizes the same loops in a way that makes them
> significantly faster than the unrolled-loops non-vectorized version.
>
> If you want to know, the loops in question typically look like:
> for(int i = 0; i < COMPILE_TIME_CONSTANT; i++)
> {
> // some abstract c++ code with deep recursive templates and
> // deep recursive inline functions, but resulting in only a
> // few assembly instructions
> a().b().c().d(i) = x().y().z(i);
> }
Are they for 64bit or 32bit targets? Are a/b/c/d/x/y/z arrays on
stack? I suggest you open a bug report so that gcc vectorizer
people can take a look.
H.J.
Re: Auto-vectorization: need to know what to expect
Thanks Richard for the answer.
It sounds like it's worth betting on gcc's autovectorizer and submitting bug
reports -- so expect to hear again from us :)
Cheers,
Benoît
On Monday 17 March 2008 15:59:21 Richard Guenther wrote:
> On Mon, Mar 17, 2008 at 3:45 PM, Benoît Jacob <[EMAIL PROTECTED]> wrote:
> > Dear All,
> >
> > I am currently (co-)developing a Free (GPL/LGPL) C++ library for
> > vector/matrix math.
> >
> > A major decision that we need to take is, what to do regarding
> > vectorization instructions (SSE). Either we rely on GCC to
> > auto-vectorize, or we control explicitly the vectorization using GCC's
> > special primitives. The latter solution is of course more difficult, and
> > would to some degree obfuscate our source code, so we wish to know
> > whether or not it's really necessary.
> >
> > GCC 4.3.0 does auto-vectorize our loops, but the resulting code has
> > worse performance than a version with unrolled loops and no
> > vectorization. By contrast, ICC auto-vectorizes the same loops in a way
> > that makes them significantly faster than the unrolled-loops
> > non-vectorized version.
> >
> > If you want to know, the loops in question typically look like:
> > for(int i = 0; i < COMPILE_TIME_CONSTANT; i++)
> > {
> > // some abstract c++ code with deep recursive templates and
> > // deep recursive inline functions, but resulting in only a
> > // few assembly instructions
> > a().b().c().d(i) = x().y().z(i);
> > }
> >
> > As said above, it's crucial for us to be able to get an idea of what to
> > expect, because design decisions depend on that. Should we expect large
> > improvements regarding autovectorization in 4.3.x, in 4.4 or 4.5 ?
>
> In general GCCs autovectorization capabilities are quite good, cases
> where we miss opportunities do of course exist. There were improvements
> regarding autovectorization capabilities in every GCC release and I expect
> that to continue for future releases (though I cannot promise anything
> as GCC is a volunteer driven project - but certainly testcases where we
> miss optimizations are welcome - often we don't know of all corner cases).
>
> If you require to get the absolute most out of your CPU I recommend to
> provide special routines tuned for the different CPU families and I
> recommend the use of the standard intrinsics headers (*mmintr.h) for
> this. Of course this comes at a high cost of maintainance (and initial
> work), so autovectorization might prove good enough. Often tuning the
> source for a given compiler has a similar effect than producing vectorized
> code manually. Looking at GCC tree dumps and knowing a bit about
> GCC internals helps you here ;)
>
> > A roadmap or a GCC developer sharing his thoughts would be very helpful.
>
> Thanks,
> Richard.
signature.asc
Description: This is a digitally signed message part.
Re: -B vs Multilib
Greg Schafer wrote: Currently, -B doesn't add the multilib search paths when processing startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in $prefix/lib/../lib64 GCC has two different schemes for multilib search dirs. One that is used in the gcc build tree, and one that is used in the OS install dirs. See the difference between multilib_dir and multilib_os_dir. We are doing multilib searches for startfile_prefix. See find_file. However, we are using the gcc build tree form. This is necessary because -B options are used during the gcc build. Perhaps what you need is to make -B options work both ways, so that they are also useful when pointing into OS dirs like /lib. Or maybe we need yet another option which is like -B but meant to be used in OS dirs instead of in the gcc build tree. Jim
Re: insn appears multiple times
Boris Boesler wrote: insn 381 appears in the delay slot and later in another basic block (but same function). These insns are equal but they are not the same, two disjunct pieces of memory. Is this possible? Yes. Reorg calls copy_rtx to avoid having shared RTL. Unsharing the insns means that we can do things like set flag bits in one without accidentally changing the other. Jim
Re: Basic block infrastructure after dbr pass
Boris Boesler wrote: But some basic blocks seem to point to insns which are not in the insn-list. I had a short look at dbr_schedule() in reorg.c and the basic blocks are not updated. Are they evaluated in a later pass? No. See pass_free_cfg, which is the third pass before pass_delay_slots. Jim
Re: Auto-vectorization: need to know what to expect
I have looked more closely at the messages generated by the gcc 4.3 vectorizer
and it seems that they fall into two categories:
1) complaining about aligmnent.
For example:
Unknown alignment for access: D.33485
Unknown alignment for access: m
I don't understand, as all my data is statically allocated doubles (no dynamic
memory allocation) and I am using -malign-double. What more can I do?
2) complaining about "possible dependence" between some data and itself
Example:
not vectorized, possible dependence between data-refs
m.m_storage.m_data[D.43225_112] and m.m_storage.m_data[D.43225_112]
I am wondering what to do about all that? Surely there must be documentation
about the vectorizer and its messages somewhere but I can't find it?
Cheers,
Benoit
On Monday 17 March 2008 15:59:21 Richard Guenther wrote:
> On Mon, Mar 17, 2008 at 3:45 PM, Benoît Jacob <[EMAIL PROTECTED]> wrote:
> > Dear All,
> >
> > I am currently (co-)developing a Free (GPL/LGPL) C++ library for
> > vector/matrix math.
> >
> > A major decision that we need to take is, what to do regarding
> > vectorization instructions (SSE). Either we rely on GCC to
> > auto-vectorize, or we control explicitly the vectorization using GCC's
> > special primitives. The latter solution is of course more difficult, and
> > would to some degree obfuscate our source code, so we wish to know
> > whether or not it's really necessary.
> >
> > GCC 4.3.0 does auto-vectorize our loops, but the resulting code has
> > worse performance than a version with unrolled loops and no
> > vectorization. By contrast, ICC auto-vectorizes the same loops in a way
> > that makes them significantly faster than the unrolled-loops
> > non-vectorized version.
> >
> > If you want to know, the loops in question typically look like:
> > for(int i = 0; i < COMPILE_TIME_CONSTANT; i++)
> > {
> > // some abstract c++ code with deep recursive templates and
> > // deep recursive inline functions, but resulting in only a
> > // few assembly instructions
> > a().b().c().d(i) = x().y().z(i);
> > }
> >
> > As said above, it's crucial for us to be able to get an idea of what to
> > expect, because design decisions depend on that. Should we expect large
> > improvements regarding autovectorization in 4.3.x, in 4.4 or 4.5 ?
>
> In general GCCs autovectorization capabilities are quite good, cases
> where we miss opportunities do of course exist. There were improvements
> regarding autovectorization capabilities in every GCC release and I expect
> that to continue for future releases (though I cannot promise anything
> as GCC is a volunteer driven project - but certainly testcases where we
> miss optimizations are welcome - often we don't know of all corner cases).
>
> If you require to get the absolute most out of your CPU I recommend to
> provide special routines tuned for the different CPU families and I
> recommend the use of the standard intrinsics headers (*mmintr.h) for
> this. Of course this comes at a high cost of maintainance (and initial
> work), so autovectorization might prove good enough. Often tuning the
> source for a given compiler has a similar effect than producing vectorized
> code manually. Looking at GCC tree dumps and knowing a bit about
> GCC internals helps you here ;)
>
> > A roadmap or a GCC developer sharing his thoughts would be very helpful.
>
> Thanks,
> Richard.
signature.asc
Description: This is a digitally signed message part.
Re: xscale-elf-gcc: compilation of header file requested
Ajit Mittal wrote: This command $(CC) -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h > [EMAIL PROTECTED] xscale-elf-gcc: compilation of header file requested Looks like an old bug fixed long ago, sometime around the gcc-3.3 time frame. You should always include the gcc version number in a bug report. Jim
Re: DFA state and arc explosion
Bingfeng Mei wrote: However, if I also want to model the resource for writing back register file, the number of states and arcs just explodes. It is especially true for long pipeline instruction. The usual solution is to have two DFAs, one used for most instructions, and one used just for the long pipeline instructions. See for instance the gcc/config/mips/sb1.md file which has the sb1_cpu_div automaton which is only used for divide instructions. DFA stands for deterministic finite automaton, which is a type of finite state machine. NDFA is non-deterministic finite automaton. Any good book on the theory of computing should cover this. Jim
Re: Auto-vectorization: need to know what to expect
On Mon, Mar 17, 2008 at 06:33:23PM +0100, Benoît Jacob wrote: > I have looked more closely at the messages generated by the gcc 4.3 > vectorizer > and it seems that they fall into two categories: The absolute best thing you can do in cases like this is to make a small program which shows the message, and send that to Bugzilla. -- Daniel Jacobowitz CodeSourcery
Re: Auto-vectorization: need to know what to expect
OK. It's nontrivial as this uses a 2500-line c++ template library, but I'll do my best to come up with something self-contained. Cheers, Benoit On Monday 17 March 2008 18:51:57 Daniel Jacobowitz wrote: > On Mon, Mar 17, 2008 at 06:33:23PM +0100, Benoît Jacob wrote: > > I have looked more closely at the messages generated by the gcc 4.3 > > vectorizer and it seems that they fall into two categories: > > The absolute best thing you can do in cases like this is to make a > small program which shows the message, and send that to Bugzilla. signature.asc Description: This is a digitally signed message part.
Re: [trunk] Addition to subreg section of rtl.text.
Hi Richard,
Thanks for the message.
[EMAIL PROTECTED] (Richard Kenner) writes:
>> It is seldom necessary to wrap hard registers in @code{subreg}s;
>> such registers would normally reduce to a single @code{reg} rtx.
>
> Are these valid? I know we've gone back and forth, but I thought the
> current position is that SUBREGs of hard regs are only allowed
> transitorily (e.g., during reload), but must be converted into a hard
> reg by the end of the pass.
That's my understanding too as far as insn operands are concerned.
But some backends use things like "(subreg (match_operand ...) ...)";
see config/rs6000/spe.md for an example. We need to define what those
subregs mean when the inner register has been reloaded.
Or I suppose we could say that such define_insns are in error and
use another construct instead.
Richard
Re: gcc-4.1-20080303 is now available
On Mon, 17 Mar 2008, Mark Mitchell wrote: > Kaveh R. GHAZI wrote: > > >> I too think that it would be a bad idea to switch the 4.1 branch to > >> GPLv3, > > > > Can you please elabortate why? > > I think it's a bad idea to change the license on a release branch in > deep maintenance mode. That would be a surprise to users. I'm not trying to beat a dead horse. But I'd like to clarify something, maybe I have a fundamental misunderstanding of how the GPL operates. If so, I'll thank you in all seriousness for educating me and drop the issue, but otherwise I think a clarification should be made where you said: "That would be a surprise to users." My understanding is that *users* of GCC are not impacted by the license change. When users compile their code, they only care about the runtime licenses as written into the GPL+exception clauses. These pieces of text are still GPLv2 anyway (even on mainline), so there is zero change for users. The people who get impacted by switching gcc-4.1 to GPLv3 are only distributors of GCC. And they maintain their own branches with local patches anyway. Assuming distributors are up to date with e.g. today's 4.1 branch, all their patches are covered by GPLv2. If we then later switch the license, then distributors are not affected either. Well okay, they lose the ability to coodinate new fixes in a central repo on gcc.gnu.org. If the branch is truly in its last phase, there shouldn't be much of anything getting installed going forward, especially given Richard G's desire to severely limit the kinds of changes allowed. [1] So what really is the negative impact of the license change especially if we immediately close the 4.1 branch after one last release? Thanks, --Kaveh [1] http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00058.html -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [trunk] Addition to subreg section of rtl.text.
> That's my understanding too as far as insn operands are concerned. > But some backends use things like "(subreg (match_operand ...) ...)"; > see config/rs6000/spe.md for an example. We need to define what those > subregs mean when the inner register has been reloaded. > > Or I suppose we could say that such define_insns are in error and > use another construct instead. I would consider such things dubious at best. I'm kind of surprised they work.
Re: gcc-4.1-20080303 is now available
> My understanding is that *users* of GCC are not impacted by the license > change. When users compile their code, they only care about the runtime > licenses as written into the GPL+exception clauses. You mean they only *should* care about that. But in practice, many corporate legal departments don't have the understanding that we have and think they *do* need to care. This has been a serious issue with adopting GPL'ed software in many large companies. The transition to GPLv3 makes this worse because they may have to do the analysis all over again.
Re: gcc-4.1-20080303 is now available
On Mon, Mar 17, 2008 at 02:41:18PM -0400, Kaveh R. GHAZI wrote: > My understanding is that *users* of GCC are not impacted by the license > change. When users compile their code, they only care about the runtime > licenses as written into the GPL+exception clauses. These pieces of text > are still GPLv2 anyway (even on mainline), so there is zero change for > users. It has been my experience that the legal departments of a number of large companies have reacted very strongly and negatively against the GPL v3. I don't know why but I would guess it has to do with the patent clauses. This has resulted in some cases in the creation of site policies forbidding the use of GPL v3 software. We do what we can to educate legal staffs on these issues, and other distributors have been doing the same; but it's clear that the license change is not a no-op for our users - even if simply because they don't think that it is. In other words, users do care. So if the branch is relicensed, maintenance patches for the branch can no longer be merged into any distributor's (or user's) tree that cares about this issue. -- Daniel Jacobowitz CodeSourcery
Re: bootstrap failure on powerpc-linux
> The file was forgotten in the original commit it was fixed by the > following revision: > r133278 | paolo | 2008-03-16 11:35:44 -0700 (Sun, 16 Mar 2008) | 34 lines > Changed paths: >A /trunk/libstdc++-v3/include/std/date_time I could have sworn my tree was sufficiently up to date. Nonetheless, a complete rebuild of my tree seems to have worked. Thanks, Ben
Re: [trunk] Addition to subreg section of rtl.text.
> 1) Is it possible to have a MODE_PARTIAL_INT inner register that is bigger
> than a word?
Yes. You might have a 20 bit register, which is considered Pmode == PHImode,
with a lower half QImode (16 bit, word addressed) which can be accessed
separately by arithmetic instructions.
> If so, what restrictions (if any) apply to subregs that access the partial
> word? Is the inner register implicitly extended so that it is a whole number
> of words? If not, are we effectively allowing non-contiguous byte ranges when
> WORDS_BIG_ENDIAN != BYTES_BIG_ENDIAN?
As far as GCC is concerned, the partial integer mode has the same size as
the underlying integral mode, but the upper bits are undefined or defined
in a machine-dependent manner. That makes sense when you consider that in
the example above, the 20 bit register has to be stored in a 32 bit memory
location. So as far as GCC is concerned, it is a value that is accomodated
in the same storage space as a HImode value, hut some bits behave in a way
it can't quite predict.
Still, you can get two QImode halves out of a PHImode value. Or you could
choose to take two PQImode halves.
At least that the theory. I don't know if it still works, as a number of
DSP processors have been removed in the last years, and some new ports
were never contributed.
> E.g., suppose we have a 16-bit WORDS_BIG_ENDIAN, !BYTES_BIG_ENDIAN target in
> which PSImode is a 24-bit value. Is the layout of 0x543210 "45..0123"?
The most natural layout would be 0x45??0123 .
But you could also have 0x345?012? , or even more exotic mappings.
The SH uses PSImode for the floating point control registyer because
only bits 20 and 19 - the size and precision bits - are handled like
ordinary data bits, while some other bits have to be preserved when
mode switching, and other bits are reserved.
> 2) Is it possible for the outer register in a normal subreg to be a superword
> MODE_PARTIAL_INT? (Our rules say "no".)
It is needed for some processors, currently not officially supported.
In the example above with the 20 bit addresses, some C++ address arithmetic
is performed in SImode, and then at some stage this is converted to PSImode.
> 3) What about things like 80-bit FP modes on a 32-bit or 64-bit target? Is it
> valid to refer to pieces of an 80-bit FP pseudo? If so, are the rules we've
> got here right?
Where the 80-bit mode is stored in multiple words like for x86, you
should be able to refer to word_mode subregs the way the value is
stored in memory. This is the only way you can get a sane equivalence
between reloads via secondary memory and direct register-register
moves invollving word_mode GENERAL_REGS.
> 4) Do stores to subregs of hardreg invalidate just the registers mentioned in
> the outer mode or do they invalidate the entire set of registers mentioned in
> the inner mode? (our rules say only the outer mode).
Where the hardreg is actually a single hardware register, all of it is
clobbered. If it is a concatenation
of multiple actual hard registers, the idea is that only the one that
corresponds to the word that is stored into gets clobbered.
If more than one word is stored into, that would logically translate to
changing each of the registers that each word corresponds to.
What seems less defined is what happens when the underlying hard registers
are smaller than a word, and either the mode size or SUBREG_BYTE
is not a multiple of a word.
> It is seldom necessary to wrap
> hard registers in @code{subreg}s; such registers would normally
> reduce to a single @code{reg} rtx.
reload handling of matching operands of different size is broken for
big endian, hence paradoxical subregs of hard registers are essential
to express such matching operands.
Re: Auto-vectorization: need to know what to expect
On Mon, Mar 17, 2008 at 06:33:23PM +0100, Benoît Jacob wrote: > I have looked more closely at the messages generated by the gcc 4.3 > vectorizer > and it seems that they fall into two categories: > > 1) complaining about aligmnent. > > For example: > > Unknown alignment for access: D.33485 > Unknown alignment for access: m > > I don't understand, as all my data is statically allocated doubles (no > dynamic > memory allocation) and I am using -malign-double. What more can I do? However, SSE instructions need 128-bit alignment, not 64-bit alignment that -malign-double would give. You can align the arrays yourself with the __attribute__((__aligned__(16))) declaration, or use a union that has an element with 16-byte alignment (vector element, such as __m128, __m128d, __m128i or long double and -m128bit-long-double). Note, if the arrays are auto rather than static, you probably need to use the -mstackrealign and -mpreferred-stack-boundary=16 as well. It might be nice to think about an option that automatically aligns large arrays without having to do the declaration (or even have the vectorizer override the alignment for statics/auto). -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: gcc-4.1-20080303 is now available
Kaveh R. GHAZI wrote: My understanding is that *users* of GCC are not impacted by the license change. Some users certainly are impacted by the license change -- there are in fact quite a few companies that disallow their users using any GPLv3 software! I think you're right that GPLv3 has no substantial impact on what you can or cannot do with GCC, and therefore that most users -- once they and their legal departments understand GPLv3 -- can go on using GCC in exactly the ways they did when it was GPLv2. But, that doesn't mean that it's not a major surprise to have an update release have a new and different license, with which you might not be familiar. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Auto-vectorization: need to know what to expect
Thanks a lot Michael for the detailed help! Thanks also n8tm, and sorry to have posted on the wrong list. Well that's a lot of food for thought and it'll keep me busy for some time, so thanks again to all, and bye! Benoit On Monday 17 March 2008 20:08:43 Michael Meissner wrote: > However, SSE instructions need 128-bit alignment, not 64-bit alignment that > -malign-double would give. You can align the arrays yourself with the > __attribute__((__aligned__(16))) declaration, or use a union that has an > element with 16-byte alignment (vector element, such as __m128, __m128d, > __m128i or long double and -m128bit-long-double). Note, if the arrays are > auto rather than static, you probably need to use the -mstackrealign and > -mpreferred-stack-boundary=16 as well. > > It might be nice to think about an option that automatically aligns large > arrays without having to do the declaration (or even have the vectorizer > override the alignment for statics/auto). signature.asc Description: This is a digitally signed message part.
Status of Mercurial mirror
Hi, the Mercurial repository has not been updated since svn revision 133268 which happened yesterday morning GMT. With all this talk about git recently, I'm wondering if the Mercurial repository is still alive? Cheers, - Tobi
Google Summer of Code 2008 mentors
GCC has been approved as a supported project for Google's Summer of Code 2008. Summer of Code is a program in which Google pays students to work on open source projects. Now we need people to sign up as mentors. As in past years, I think mentors should be restricted to people listed in the MAINTAINERS file, which still gives us plenty to choose from. If you are interested, please sign up at http://code.google.com/soc/mentor_step1.html You will need to have a gmail.com account. The benefits of being a mentor for a student are the chance to help him or her learn about gcc and increase the number of people who work on it. And, of course, gcc will improve. Plus, if you mentor a student, you get a T-shirt. If you sign up as a mentor, you will be able to vote on the projects submitted to Summer of Code for gcc. That will be helpful even if you don't wind up acting as a mentor for any specific project. For each approved and completed project, the student will receive $4500, and the gcc project will receive $500. As we did last year, our share of the money will go to the Free Software Foundation. That URL again: http://code.google.com/soc/mentor_step1.html Thanks! Ian
Re: gcc-4.1-20080303 is now available
On Mon, Mar 17, 2008 at 5:54 AM, Dave Korn <[EMAIL PROTECTED]> wrote: > Dave Korn wrote on : > > > > Jakub Jelinek wrote on 17 March 2008 12:00: > > > > > The fixincl.x change on 4.1 branch should be IMNSHO reverted. > > > > > I tend to agree. I'll revert this change under the own-patches rule. > > Done: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01004.html > > Apologies for the inconvenience. OK, and for the _next_ installment of autogen, I'll restore gpl-v2 generation and the template can be modified to produce the v2 variation. It'll be something fun like: (if (version-compare >= autogen-version "5.9.6") (gpl "-v2" "fixincludes" " * ") (gpl "fixincludes" " * ") ) "Yummy". :) Cheers - Bruce [[P.S. you could do that now and all currently released autogens should yield #f for the expression (version-compare >= autogen-version "5.9.6") ]]
gcc-4.1-20080317 is now available
Snapshot gcc-4.1-20080317 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080317/ 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/gcc-4_1-branch revision 133293 You'll find: gcc-4.1-20080317.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080317.tar.bz2 C front end and core compiler gcc-ada-4.1-20080317.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080317.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080317.tar.bz2 C++ front end and runtime gcc-java-4.1-20080317.tar.bz2 Java front end and runtime gcc-objc-4.1-20080317.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080317.tar.bz2The GCC testsuite Diffs from 4.1-20080310 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
cc1plus-dummy linkage
On Darwin, we have discovered that the new Xcode 3.1 in the iPhone beta SDK apparently exposed a linkage problem when building gcc 4.3.0. The failure we see with the newer darwin linker is... /sw/src/fink.build/gcc43-4.3.0-1000/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc43-4.3.0-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.3/i686-apple-darwin9/bin/ -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros-Wno-overlength-strings -DHAVE_CONFIG_H -o cc1plus-dummy \ cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o darwin-c.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o tree-inline.o dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -L/sw/lib -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/sw/lib -lmpfr -lgmp ld: duplicate symbol _init_inline_once in libbackend.a(tree-inline.o) and tree-inline.o collect2: ld returned 1 exit status make[3]: *** [cc1plus-dummy] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 If the occurance of tree-inline.o is removed from the link line above, the linakge succeeds. Why does gcc link in tree-inline.o a second time for cc1plus-dummy when it already exists in libbackend.a? Is this an error in the gcc Makefiles? Jack
Re: cc1plus-dummy linkage
On Mon, Mar 17, 2008 at 07:47:56PM -0400, Jack Howarth wrote: > >On Darwin, we have discovered that the new Xcode 3.1 in the iPhone beta SDK > apparently exposed a linkage problem when building gcc 4.3.0. The failure we > see > with the newer darwin linker is... > ... > ld: duplicate symbol _init_inline_once in libbackend.a(tree-inline.o) and > tree-inline.o > If the occurance of tree-inline.o is removed from the link line above, the > linakge succeeds. > Why does gcc link in tree-inline.o a second time for cc1plus-dummy when it > already exists > in libbackend.a? Is this an error in the gcc Makefiles? Actually, I don't understand how this error could be produced. If tree-inline.o is specified on the command line, and also exists in libbackend.a, then shouldn't the occurrence in libbackend.a just be ignored? Static libraries are only searched to satisfy undefined symbols, and all symbols defined in tree-inline.o should already be satisfied. But maybe Darwin's linker works differently than standard Unix-style linkers?
Re: Status of Mercurial mirror
The mirroring job started failing, i'm working on it. On Mon, Mar 17, 2008 at 5:48 PM, Tobias Schlüter <[EMAIL PROTECTED]> wrote: > > Hi, > > the Mercurial repository has not been updated since svn revision 133268 > which happened yesterday morning GMT. With all this talk about git > recently, I'm wondering if the Mercurial repository is still alive? > > Cheers, > - Tobi > > >
Re: Status of Mercurial mirror
Should be fixed now On Mon, Mar 17, 2008 at 10:27 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > The mirroring job started failing, i'm working on it. > > > > > On Mon, Mar 17, 2008 at 5:48 PM, Tobias Schlüter > <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > the Mercurial repository has not been updated since svn revision 133268 > > which happened yesterday morning GMT. With all this talk about git > > recently, I'm wondering if the Mercurial repository is still alive? > > > > Cheers, > > - Tobi > > > > > > >
