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/l
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++-
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 al
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/
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
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
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
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
>>
>
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)
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 a
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 sh
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 rathe
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
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 i
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 rel
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 specia
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
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]> w
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
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
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.
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 al
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 i
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
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 mes
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
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
> curren
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 wo
> 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
> 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 departmen
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 stil
> 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. Nonethele
> 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 r
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
> U
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
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 i
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
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 MAINT
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
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
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-100
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 _
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
> recentl
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 no
44 matches
Mail list logo
