On Tue, Mar 22, 2011 at 03:29:26PM -0700, Ian Lance Taylor wrote:
> Mike Stump writes:
>
> > So, I was trying to debug some stuff with the top of the tree on a suse
> > linux x86_64 box and got:
> >
> > (gdb) p mode
> > Unhandled dwarf expression opcode 0xf3
> >
> > which I don't find entertaini
On Tue, Mar 22, 2011 at 8:43 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> Simple. Just make them registers anyway (I did that in the past
>> when working on middle-end arrays). You'd set DECL_GIMPLE_REG_P
>> on the decl.
>
> OK, thanks, I'll give that a go. TBH, I'm still hopeful
Georg-Johann Lay writes:
> 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and
> for REG-REG moves, no word about REG-CONST moves. So is using
> secondary reloads for CONST_INT (or other consts) like outlined
> above a defined use case I can rely on?
Yeah, it should
I heard you would like to release gtcc4.6.0 next week, so I quickly set up
a new pass 1 from LFS. With gcc-4.6-20110205, I Manage to compile
coreutils (and almost the all set of ports of NuTyX) but with this
version of gcc I get stuck at coreutils in the first pass. May be it's me
but I prefer to
On Wed, Mar 23, 2011 at 10:30:46AM +0100, t...@nutyx.com wrote:
> I heard you would like to release gtcc4.6.0 next week, so I quickly set up
> a new pass 1 from LFS. With gcc-4.6-20110205, I Manage to compile
> coreutils (and almost the all set of ports of NuTyX) but with this
> version of gcc I g
>> ...Ira would know best, but I don't think it would be used for this
>> kind of loop. It would be more something like:
>>
>> for (i=0; i> X[i] = Y[i].red + Y[i].blue + Y[i].green;
>>
>> (not a realistic example). You'd then have:
>>
>> compoundY = __builtin_load_lanes (Y);
>> red =
Richard Guenther writes:
> But as you have partial defs of the vector lane array the simplest
> approach is probably to not make them a register. Be prepared
> for some surprises during RTL expansion though ;)
OK. It's there I'd like to start, specifically with:
These arrays of vectors would
"Joseph S. Myers" writes:
> (And why (CC to maintainer) do some CRIS and MMIX targets list Fortran
> in unsupported languages? I didn't think the Fortran libraries had
> any porting issues, unlike Java and Go and Ada.)
For the record, builds with mipsisa64-elf fail with:
libgfortran/intrinsics/
On Tue, Mar 22, 2011 at 6:07 PM, Ian Lance Taylor wrote:
> "Joseph S. Myers" writes:
>
>> Why do a great many targets disable libgcj by default in the toplevel
>> configure.ac?
>
> I believe that it's just a hack: libgcj doesn't build on the target, but
> gcc/java does. Disabling libgcj lets the
On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> But as you have partial defs of the vector lane array the simplest
>> approach is probably to not make them a register. Be prepared
>> for some surprises during RTL expansion though ;)
>
> OK. It's there I'
Richard Guenther writes:
> On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
>>> But as you have partial defs of the vector lane array the simplest
>>> approach is probably to not make them a register. Be prepared
>>> for some surprises during RTL expansio
On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
> Hello All,
>
> I have been trying to build a cross compiler (for PowerPC) on x86_64
> linux host. I followed the build procedure given in the link below:
>
> http://www.eglibc.org/archives/patches/msg00078.html
You should be referring to the current
On Wed, Mar 23, 2011 at 1:18 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
>> wrote:
>>> Richard Guenther writes:
But as you have partial defs of the vector lane array the simplest
approach is probably to not make them a
Richard Guenther writes:
>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>
> Most of the tree passes shouldn't care about TYPE_MODE (nor
> DECL_MODE) and on RTL we shouldn't need to care about trees.
It sounds like you think it would be better to get rid of TYPE_MODE.
I can se
On Wed, Mar 23, 2011 at 2:01 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>>
>> Most of the tree passes shouldn't care about TYPE_MODE (nor
>> DECL_MODE) and on RTL we shouldn't need to care about trees.
>
> It sounds
Richard Guenther writes:
>>> For your case in question the vectorizer would create local vars with
>>> that mode, knowing it is supported, so I don't see big problems for
>>> that particular case.
>>
>> The problem is that I'd like to use this for intrinsics as well as for
>> automatic vectorisati
On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
>>>
>>> The problem is that I'd like
Richard Guenther writes:
> On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
> For your case in question the vectorizer would create local vars with
> that mode, knowing it is supported, so I don't see big problems for
> that particular case.
>>>
Over at the PPH branch we are starting to re-use the LTO streaming
routines to save front end trees. Clearly, there are things that need
to be extended and/or replaced since LTO streaming assumes that we are
in GIMPLE. However, there is a large intersection that I think can be
commoned out.
- AS
On Wed, 23 Mar 2011, Diego Novillo wrote:
> Over at the PPH branch we are starting to re-use the LTO streaming
> routines to save front end trees. Clearly, there are things that need
> to be extended and/or replaced since LTO streaming assumes that we are
> in GIMPLE. However, there is a large i
On Wed, Mar 23, 2011 at 10:53, Richard Guenther wrote:
> Yes, Micha has a load of patches cleaning up streaming and removing
> unecessary abstraction. So, why'd you need to share any of it?
Removing unnecessary abstraction is fine. But there is a bunch of
code that will be common, in particula
> On Wed, 23 Mar 2011, Diego Novillo wrote:
>
> > Over at the PPH branch we are starting to re-use the LTO streaming
> > routines to save front end trees. Clearly, there are things that need
> > to be extended and/or replaced since LTO streaming assumes that we are
> > in GIMPLE. However, there
On Wed, Mar 23, 2011 at 12:38, Jan Hubicka wrote:
>> think it would be much easier if you worked with a copy (ugh,
>> streaming trees again).
>
> I also think using same machinery for FE/gimple is a mistake. Trees are
> making
> life hard since they are interface in between FE<->gimplifier,
On 03/22/2011 08:51 PM, Joseph S. Myers wrote:
Why do a great many targets disable libgcj by default in the toplevel
configure.ac?
Because that dates to before 2004, which IIRC is when toplevel
configure.ac started looking at config-lang.in files.
Paolo
On Wed, 23 Mar 2011 08:51:25 +0100, Jakub Jelinek wrote:
> http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval
> is the git branch with gdb support for this, though as I was told
> it is a GDB 7.4 material rather than 7.3 (the msg00268.html
> commit is hope
This thread spilled into IRC chatter. I think we stopped talking past
each other now:
(2011-03-23 12:51:34) froydnj: dnovillo: gimple gets rid of trees?
how does that work?
(2011-03-23 12:52:29) dnovillo: froydnj: we've been talking about
tuplifying more, but i don't think it makes sense past cer
I've turned on all warnings to have clean program.
Turn on -Wconversion but it will not care about BIG trouble in C++:
conversion.
class A{
public:
A(unsigned int){}
};
class B{
public:
B(A){}
};
B b(-1); //OK without warnings
int main(void){}
-1 => A(FF..FF) => B(FF..FF)
I want
On 23 March 2011 17:58, Lisp2D wrote:
>
> I've turned on all warnings to have clean program.
> Turn on -Wconversion but it will not care about BIG trouble in C++:
> conversion.
>
> class A{
> public:
> A(unsigned int){}
> };
>
> class B{
> public:
> B(A){}
> };
>
> B b(-1); //OK without warnin
Hi Iain,
> On Darwin, we have a number of gcc.c-torture fails reported for both ppc
> and i386 which are bogus (nothing to do with gcc - but simply warning
> output from a system tool).
>
> For dg-based tests these are pruned - I wonder if it would be worth adding
> a prune capability to the tort
Hi Rainer,
On 23 Mar 2011, at 18:45, Rainer Orth wrote:
On Darwin, we have a number of gcc.c-torture fails reported for
both ppc
and i386 which are bogus (nothing to do with gcc - but simply
warning
output from a system tool).
For dg-based tests these are pruned - I wonder if it would be
Hi Iain,
>> IMO this is the wrong approach. I'd like us to move away from the
>> non-dg testsuites if at all possible.
>
> I personally agree...
>
> ... but when I suggested this for the (relatively small) ObjC set of
> torture tests, it was not greeted enthusiastically...
>
> (the problem voice
On Wed, 23 Mar 2011, Rainer Orth wrote:
> indeed, and I wouldn't certainly advocate moving the tests around, just
> using a different dg-based driver for the torture testsuites.
gcc.c-torture/compile.exp was moved to using the dg driver a long time
ago, moving the others (so that .x files are no
Hello,
My name is Nikolay Merinov, I am magistracy student at Ural State
University (Russia). I hope to participate in GSoC and I am interesting
in working on interprocedural data flow analysis. I would like to ask
potential mentors about simple project that will help me to familiarize
myself with
33 matches
Mail list logo
