On Wed, Nov 14, 2012 at 5:13 PM, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> Generating gimple and tree expressions require lots of detail,
> which is hard to remember and easy to get wrong. There is some
> amount of boilerplate code that can, i
On Wed, Nov 14, 2012 at 05:13:12PM -0800, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> Generating gimple and tree expressions require lots of detail,
> which is hard to remember and easy to get wrong. There is some
> amount of boilerplate code t
On Wed, Nov 14, 2012 at 5:26 AM, Alexander Ivchenko wrote:
> By default in Android we always compile with -fpic or -fPIC, even when
> compiling executable. Because of that we have some test fails on
> Android:
>
> For example:
> gcc/testsuite/gcc.target/i386/pr47312.c
> /* { dg-do run } */
> /* {
On 15/11/2012, at 2:26 AM, Alexander Ivchenko wrote:
> By default in Android we always compile with -fpic or -fPIC, even when
> compiling executable. Because of that we have some test fails on
> Android:
>
> For example:
> gcc/testsuite/gcc.target/i386/pr47312.c
> /* { dg-do run } */
> /* { dg-op
On Wed, Nov 14, 2012 at 5:12 PM, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> It is sometimes hard to remember which printing function is used
> for debugging a type, or even which type you have.
>
> We propose to rely on overloading to unify the
Diego and I seek your comments on the following (loose) proposal.
Generating gimple and tree expressions require lots of detail,
which is hard to remember and easy to get wrong. There is some
amount of boilerplate code that can, in most cases, be reduced and
managed automatically.
We will add a
Diego and I seek your comments on the following (loose) proposal.
It is sometimes hard to remember which printing function is used
for debugging a type, or even which type you have.
We propose to rely on overloading to unify the interface to a small
set of function names. Every major data type
On 11/14/2012 01:32 PM, Ian Lance Taylor wrote:
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law wrote:
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains. I'll approve the patch unless
somebody
Ulf Magnusson wrote:
On Wed, Nov 14, 2012 at 6:10 PM, Piotr Wyderski
wrote:
The following snippet:
class A {};
class B : public A {
typedef A super;
public:
class X {};
};
class C : public B {
typedef B super;
class X : public super::X {
typedef super::X super;
On Wed, 2012-11-14 at 18:51 +0100, Andreas Tobler wrote:
> Hello,
>
> on trunk (193501) I get a comparison failure:
> ---
> Bootstrap comparison failure!
> gcc/tree-ssa-forwprop.o differs
> ---
>
> This is with --disable-checking. Leaving disable-checking away, the
> bootstrap completes succesful
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law wrote:
> On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
>>
>> Given that nobody has stepped forward to test it, let's just remove
>> the code and see if anybody complains. I'll approve the patch unless
>> somebody objects in the next 24 hours.
>
> I thi
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains. I'll approve the patch unless
somebody objects in the next 24 hours.
I think the target to check would be 32 bit HPUX.
-ffunction-sections
On Wed, Nov 14, 2012 at 10:58 AM, Sriraman Tallam wrote:
> On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor wrote:
>> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>>>
>>>Currently, using -ffunction-sections and -p together results in a
>>> warning. I ran into this problem when comp
On Wed, Nov 14, 2012 at 6:10 PM, Piotr Wyderski
wrote:
> The following snippet:
>
> class A {};
> class B : public A {
>
>typedef A super;
>
> public:
>
>class X {};
> };
>
>
> class C : public B {
>
>typedef B super;
>
>class X : public super::X {
>
> typedef super::X super;
On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor wrote:
> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>>
>>Currently, using -ffunction-sections and -p together results in a
>> warning. I ran into this problem when compiling the kernel. This is
>> discussed in this thread:
>>
>> htt
Am 01.04.2011 13:01, schrieb Kai Tietz:
> 2011/4/1 Andrew Haley :
>> On 04/01/2011 10:05 AM, Kai Tietz wrote:
>>
>>> I would like to update boehm-gc in gcc's tree to more recent version
>>> (7.2 - alpha 5). It has shown now that we wait for x64 windows
>>> support of boehm-gc more then one year. T
Hello,
on trunk (193501) I get a comparison failure:
---
Bootstrap comparison failure!
gcc/tree-ssa-forwprop.o differs
---
This is with --disable-checking. Leaving disable-checking away, the
bootstrap completes succesfully.
---
andreast% stage2-gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=stage
On Wed, Nov 14, 2012 at 10:41 AM, Diego Novillo wrote:
> The code is currently in the git branch dnovillo/vec-rewrite. It is
> trunk current as of today.
I forgot to add that I have created a wiki page that describes the
transition into the new interface:
http://gcc.gnu.org/wiki/cxx-conversion/
The following snippet:
class A {};
class B : public A {
typedef A super;
public:
class X {};
};
class C : public B {
typedef B super;
class X : public super::X {
typedef super::X super;
};
};
compiles without a warning on Comeau and MSVC, but GCC (4.6.1 and
4.7.1) fai
I am almost ready to send the patches for the VEC API overhaul. This
patch affects a very large number of files (342). I am testing the
patch in various configurations:
--checking=release
--checking=yes
--checking=gc,gcac
I've enabled all languages including ada and go. I've also added isl
and
On Wed, Nov 14, 2012 at 5:36 AM, Richard Earnshaw wrote:
> On 13/11/12 14:56, Ian Lance Taylor wrote:
>>
>> Currently -fPIC -fPIE seems to be the same as -fPIE. Unfortunately,
>> -fPIE -fPIC also seems to be the same as -fPIE. It seems to me that,
>> as is usual with conflicting options, we shou
Hi,
On Wed, 14 Nov 2012, Paulo Matos wrote:
> There's a function in lto-streamer-out.c which determines if a tree is
> streamable.
> This is lto_is_streamable? I have a LANG_TYPE that I want to stream and
> adding to that function:
> #ifdef TARGET_MYPORT
> if (code == LANG_TYPE)
>return tr
On 13/11/12 14:56, Ian Lance Taylor wrote:
Currently -fPIC -fPIE seems to be the same as -fPIE. Unfortunately,
-fPIE -fPIC also seems to be the same as -fPIE. It seems to me that,
as is usual with conflicting options, we should use the one that
appears last on the command line.
Do we have an e
By default in Android we always compile with -fpic or -fPIC, even when
compiling executable. Because of that we have some test fails on
Android:
For example:
gcc/testsuite/gcc.target/i386/pr47312.c
/* { dg-do run } */
/* { dg-options "-O2" } */
void exit (int);
void noreturn_autodetection_failed
On Wed, Nov 14, 2012 at 5:41 AM, Paulo Matos wrote:
> Hi,
>
> There's a function in lto-streamer-out.c which determines if a tree is
> streamable.
> This is lto_is_streamable? I have a LANG_TYPE that I want to stream and
> adding to that function:
> #ifdef TARGET_MYPORT
> if (code == LANG_TYPE)
Hi,
There's a function in lto-streamer-out.c which determines if a tree is
streamable.
This is lto_is_streamable? I have a LANG_TYPE that I want to stream and adding
to that function:
#ifdef TARGET_MYPORT
if (code == LANG_TYPE)
return true;
#endif
sorts the problem out but my question is,
Hi,
In function find_def_preds from tree-ssa-uninit.c there is following code:
prev_nc = num_chains;
compute_control_dep_chain (cd_root, opnd_edge->src,
dep_chains, &num_chains,
&cur_chain);
/* Free individual chai
27 matches
Mail list logo
