Re: Simplifying Gimple Generation
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, in most cases, be reduced and
> managed automatically.
>
> We will add a set of helper classes to be used as local variables
> to manage the details of handling the existing types. That is,
> a layer over 'gimple_build_*'. We intend to provide helpers for
> those facilities that are both commonly used and have room for
> significant simplification.
>
>
> Generating an Expression
>
> Suppose one wants to generate the expression (shadow != 0) &
> (((base_addr & 7) + offset) >= shadow), where offset is a value and
> the other identifiers are variables. The current code to generate
> this expression is as follows.
>
> /* t = shadow != 0 */
> g = gimple_build_assign_with_ops (NE_EXPR,
> make_ssa_name (boolean_type_node, NULL),
> shadow,
> build_int_cst (shadow_type, 0));
> gimple_set_location (g, location);
> gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> t = gimple_assign_lhs (g);
>
> /* a = base_addr & 7 */
> g = gimple_build_assign_with_ops (BIT_AND_EXPR,
> make_ssa_name (uintptr_type, NULL),
> base_addr,
> build_int_cst (uintptr_type, 7));
> gimple_set_location (g, location);
> gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>
> /* b = (shadow_type)a */
> g = gimple_build_assign_with_ops (NOP_EXPR,
> make_ssa_name (shadow_type, NULL),
> gimple_assign_lhs (g),
> NULL_TREE);
> gimple_set_location (g, location);
> gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>
> /* c = b + offset */
> g = gimple_build_assign_with_ops (PLUS_EXPR,
> make_ssa_name (shadow_type, NULL),
> gimple_assign_lhs (g),
> build_int_cst (shadow_type, offset));
> gimple_set_location (g, location);
> gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>
> /* d = c >= shadow */
> g = gimple_build_assign_with_ops (GE_EXPR,
> make_ssa_name (boolean_type_node, NULL),
> gimple_assign_lhs (g),
> shadow);
> gimple_set_location (g, location);
> gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>
> /* r = t & d */
> g = gimple_build_assign_with_ops (BIT_AND_EXPR,
> make_ssa_name (boolean_type_node, NULL),
> t,
> gimple_assign_lhs (g));
> gimple_set_location (g, location);
> gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> r = gimple_assign_lhs (g);
>
> We propose a simplified form using new build helper classes ssa_seq
> and ssa_stmt that would allow the above code to be written as
> follows.
>
> ssa_seq q;
Can it be more abstract, such as stmt_builder?
> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
> ssa_stmt b = q.stmt (shadow_type, a);
> ssa_stmt c = q.stmt (PLUS_EXPR, b, offset);
> ssa_stmt d = q.stmt (GE_EXPR, c, shadow);
> ssa_stmt e = q.stmt (BIT_AND_EXPR, t, d);
seq_seq::stmt(...) sounds like a getter interface, not a creator.
x = q.new_assignment (...);
x = q.new_call (..);
x.add_arg(..);
x = q.new_icall (..);
l1 = q.new_label ("xx");
l2 = q.new_label ("xxx");
join_l = q.new_label ("...");
x = new_if_then_else (cond, l1, l2, join_l);
q.insert_label (l1);
q.new_assignment (...);
q.insert_label(l2);
...
q.insert_label(join_l);
q.close_if_then_else(x);
> q.set_location (location);
> r = e.lhs ();
>
> There are a few important things to note about this example.
>
> .. We have a new class (ssa_seq) that knows how to sequence
> statements automatically and can build expressions out of types.
>
> .. Every statement created produces an SSA name. Referencing an
> ssa_stmt instance in a an argument to ssa_seq::stmt retrieves the
> SSA name generated by that statement.
>
> .. The statement result type is that of the arguments.
>
> .. The type of integral constant arguments is that of the other
> argument. (Which implies that only one argument can be constant.)
>
> .. The 'stmt' method handles linking the statement into the sequence.
>
> .. The 'set_location' method iterates over all statements.
>
> There will be another class of builders for generating GIMPLE
> in normal form (gimple_stmt). We expect that this will mostly
> affect all transformations that need to generate new expressions
> and statements, like instrumentation passes.
What are the uses of the raw forms?
>
> We also expect to reduce calls to tree expression builders by
> allowing the use of numeric and string constants to be converted
> to the appropriate tree _CST node. This will only work when the
> type of the constant can be deduced from the other argument in some
> expressions, of course.
>
>
> Generating a Type
>
> Consider the generation of the following type.
>
> struct __asan_global {
> const_ptr_type_node __beg;
> inttype __size;
> intty
Re: Simplifying Gimple Generation
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 that can, in most cases, be reduced and
> managed automatically.
>
> We will add a set of helper classes to be used as local variables
> to manage the details of handling the existing types. That is,
> a layer over 'gimple_build_*'. We intend to provide helpers for
> those facilities that are both commonly used and have room for
> significant simplification.
I do agree (in principle) on this and the previous (debugging-like) proposal,
but:
do you target the 4.8 release? (I believe not, since its stage 1 is ending)
do you intend to remove the current way of doing?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [Android] -fpic default option
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 } */
> /* { dg-options "-O2" } */
>
> void exit (int);
> void noreturn_autodetection_failed ();
> __attribute__ ((noinline))
> detect_noreturn ()
> {
> exit (0);
> }
> int
> main (void)
> {
> detect_noreturn ();
> noreturn_autodetection_failed ();
> return 0;
> }
>
> If gcc knew, that we are not going to make a shared library (which is
> implied if we are using pic option), then it would delete the call of
> noreturn_autodetection_failed as a dead code. But in case of pic we
> cannot rely on the fact that detect_noreturn () will not be
> overwritten on runtime, eventhough we are compiling executable and
> that will never happen! So in addition to several testfails, it seems
> that we are losing an optimization opportunity here also.
> I'm wondering, maybe we can use -fpie instead of -fpic by default in
> the compiler (of course if there are no -shared or -c options; those
> cases will mean that we cannot rely on the fact that we will have an
> executable after linking)? It seems that it would solve the problem..
> Of course we always can add something like { target nonpic } to all
We should add { target nonpic } independent of Android.
> tests that fail on Android, but probably the problem is deeper than
> that and that would be only hiding our head in the sand.
Using -fPIE to compile executables is a good idea.
--
H.J.
Re: [Android] -fpic default option
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-options "-O2" } */
>
> void exit (int);
> void noreturn_autodetection_failed ();
> __attribute__ ((noinline))
> detect_noreturn ()
> {
> exit (0);
> }
> int
> main (void)
> {
> detect_noreturn ();
> noreturn_autodetection_failed ();
> return 0;
> }
>
> If gcc knew, that we are not going to make a shared library (which is
> implied if we are using pic option), then it would delete the call of
> noreturn_autodetection_failed as a dead code. But in case of pic we
> cannot rely on the fact that detect_noreturn () will not be
> overwritten on runtime, eventhough we are compiling executable and
> that will never happen! So in addition to several testfails, it seems
> that we are losing an optimization opportunity here also.
> I'm wondering, maybe we can use -fpie instead of -fpic by default in
> the compiler (of course if there are no -shared or -c options; those
> cases will mean that we cannot rely on the fact that we will have an
> executable after linking)? It seems that it would solve the problem..
> Of course we always can add something like { target nonpic } to all
> tests that fail on Android, but probably the problem is deeper than
> that and that would be only hiding our head in the sand.
The canonical way of building native applications for Android is to add
-fno-pic to the compiler flags. The intent was to make the most common
behavior the default, and for Android that happens to be building shared
libraries that can then be called through JNI.
I think the right fix here is to add "-fno-pic" to dg-options for affected
tests in gcc.target/i386. For architecture-independent test, it may be more
prudent to use { target nonpic }, as you suggested, since we can't be sure that
a given target / multilib can handle non-pic code.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
Re: Unifying the GCC Debugging Interface
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 interface to a small > set of function names. Every major data type should have associated > debug/dump functionality. We will unify the current *_dump/*_debug > functions under the same common overloaded name. > > We intend to only apply this approach to functions that take the > type to display as an argument, and that are routinely used in > debugging. > > We propose to provide several function overload sets, as below. Here is my proposal though I don't have time to work on it. Make some python scripts which do the basic function of the debug_* functions. This way you can use them while debugging a core file and when the stack has become full. As I said I don't have time to work on this and really don't know python well enough to do it either. But I think would be more useful than changing the debug functions inside gcc. Thanks. Andrew Pinski > > > dump_pretty > > This function overload set provides the bulk of the printing. > They will use the existing pretty-printer functions in their > implementation. > > dump_raw > > This function overload set provides the raw oriented dump, > e.g. a tuple. > > dump_verbose > > This function overload set provides the extra details dump. > > > All of these functions come in two forms. > > function (FILE *, item_to_dump, formatting) > function (item_to_dump, formatting) > > If the FILE* is not specified, the output is to stderr. The > formatting argument is optional, with a default suitable to the kind > of item to dump. > > > We should remove tree-browser.c. It is not used at all and it is > likely broken. > > -- > Lawrence Crowl
Simplifying Gimple Generation
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 set of helper classes to be used as local variables
to manage the details of handling the existing types. That is,
a layer over 'gimple_build_*'. We intend to provide helpers for
those facilities that are both commonly used and have room for
significant simplification.
Generating an Expression
Suppose one wants to generate the expression (shadow != 0) &
(((base_addr & 7) + offset) >= shadow), where offset is a value and
the other identifiers are variables. The current code to generate
this expression is as follows.
/* t = shadow != 0 */
g = gimple_build_assign_with_ops (NE_EXPR,
make_ssa_name (boolean_type_node, NULL),
shadow,
build_int_cst (shadow_type, 0));
gimple_set_location (g, location);
gsi_insert_after (&gsi, g, GSI_NEW_STMT);
t = gimple_assign_lhs (g);
/* a = base_addr & 7 */
g = gimple_build_assign_with_ops (BIT_AND_EXPR,
make_ssa_name (uintptr_type, NULL),
base_addr,
build_int_cst (uintptr_type, 7));
gimple_set_location (g, location);
gsi_insert_after (&gsi, g, GSI_NEW_STMT);
/* b = (shadow_type)a */
g = gimple_build_assign_with_ops (NOP_EXPR,
make_ssa_name (shadow_type, NULL),
gimple_assign_lhs (g),
NULL_TREE);
gimple_set_location (g, location);
gsi_insert_after (&gsi, g, GSI_NEW_STMT);
/* c = b + offset */
g = gimple_build_assign_with_ops (PLUS_EXPR,
make_ssa_name (shadow_type, NULL),
gimple_assign_lhs (g),
build_int_cst (shadow_type, offset));
gimple_set_location (g, location);
gsi_insert_after (&gsi, g, GSI_NEW_STMT);
/* d = c >= shadow */
g = gimple_build_assign_with_ops (GE_EXPR,
make_ssa_name (boolean_type_node, NULL),
gimple_assign_lhs (g),
shadow);
gimple_set_location (g, location);
gsi_insert_after (&gsi, g, GSI_NEW_STMT);
/* r = t & d */
g = gimple_build_assign_with_ops (BIT_AND_EXPR,
make_ssa_name (boolean_type_node, NULL),
t,
gimple_assign_lhs (g));
gimple_set_location (g, location);
gsi_insert_after (&gsi, g, GSI_NEW_STMT);
r = gimple_assign_lhs (g);
We propose a simplified form using new build helper classes ssa_seq
and ssa_stmt that would allow the above code to be written as
follows.
ssa_seq q;
ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
ssa_stmt b = q.stmt (shadow_type, a);
ssa_stmt c = q.stmt (PLUS_EXPR, b, offset);
ssa_stmt d = q.stmt (GE_EXPR, c, shadow);
ssa_stmt e = q.stmt (BIT_AND_EXPR, t, d);
q.set_location (location);
r = e.lhs ();
There are a few important things to note about this example.
.. We have a new class (ssa_seq) that knows how to sequence
statements automatically and can build expressions out of types.
.. Every statement created produces an SSA name. Referencing an
ssa_stmt instance in a an argument to ssa_seq::stmt retrieves the
SSA name generated by that statement.
.. The statement result type is that of the arguments.
.. The type of integral constant arguments is that of the other
argument. (Which implies that only one argument can be constant.)
.. The 'stmt' method handles linking the statement into the sequence.
.. The 'set_location' method iterates over all statements.
There will be another class of builders for generating GIMPLE
in normal form (gimple_stmt). We expect that this will mostly
affect all transformations that need to generate new expressions
and statements, like instrumentation passes.
We also expect to reduce calls to tree expression builders by
allowing the use of numeric and string constants to be converted
to the appropriate tree _CST node. This will only work when the
type of the constant can be deduced from the other argument in some
expressions, of course.
Generating a Type
Consider the generation of the following type.
struct __asan_global {
const_ptr_type_node __beg;
inttype __size;
inttype __size_with_redzone;
const_ptr_type_node __name;
inttype __has_dynamic_init;
};
The current code to generate it is as follows.
tree inttype = build_nonstandard_integer_type (POINTER_SIZE, 1);
tree ret = make_node (RECORD_TYPE);
TYPE_NAME (ret) = get_identifier ("__asan_global");
tree beg = build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier ("__beg"), const_ptr_type_node);
DECL_CONTEXT (beg) = ret;
TYPE_FIELDS (ret) = beg;
tree size = build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier ("__size"), inttype);
DECL_CONTEXT (size) = ret;
DECL_CHAIN (beg) = size;
tree red = build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier ("__size_with_redzone"), inttype);
DECL_CONTEXT
Unifying the GCC Debugging Interface
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 should have associated debug/dump functionality. We will unify the current *_dump/*_debug functions under the same common overloaded name. We intend to only apply this approach to functions that take the type to display as an argument, and that are routinely used in debugging. We propose to provide several function overload sets, as below. dump_pretty This function overload set provides the bulk of the printing. They will use the existing pretty-printer functions in their implementation. dump_raw This function overload set provides the raw oriented dump, e.g. a tuple. dump_verbose This function overload set provides the extra details dump. All of these functions come in two forms. function (FILE *, item_to_dump, formatting) function (item_to_dump, formatting) If the FILE* is not specified, the output is to stderr. The formatting argument is optional, with a default suitable to the kind of item to dump. We should remove tree-browser.c. It is not used at all and it is likely broken. -- Lawrence Crowl
Re: Using -ffunction-sections and -p
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 objects in the next 24 hours. I think the target to check would be 32 bit HPUX. -ffunction-sections was largely driven by issues we wanted to resolve on the PA. Does anybody still have access to a 32-bit HPUX machine? :-) I've got one gathering dust downstairs... If David doesn't have one anymore, I'll fire up mine up and see what I can find... jeff
Re: [C++] Possible GCC bug
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;
};
};
compiles without a warning on Comeau and MSVC, but GCC (4.6.1 and
4.7.1) failes with the following message:
$ gcc -c bug.cpp
bug.cpp:18:24: error: declaration of ‘typedef class B::X C::X::super’
[-fpermissive]
bug.cpp:14:14: error: changes meaning of ‘super’ from ‘typedef class B
C::super’ [-fpermissive]
Should I file a report?
Best regards, Piotr
Here's a two-line TC:
typedef struct { typedef int type; } s1;
struct S2 { s1::type s1; };
Fails with GCC 4.6.3; succeeds with clang 3.0. Looks like a bug to me.
/Ulf
In your example, GCC is in fact right. Basically, you mustn't have a name refer
to two things in a class:
3.3.6/1: ... A name N used in a class S shall refer to the same declaration in
its context and when re-evaluated in the
completed scope of S. No diagnostic is required for a violation of this rule.
...
Regards
Jiří Paleček
Re: bootstrap comparison failure ppc64 FreeBSD
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 succesfully. I just fired off a --disable-checking build and I see the same thing on powerpc64-linux. > -9658:e8 89 00 09 ldu r4,8(r9) > -965c:39 08 00 01 addir8,r8,1 > +9658:39 08 00 01 addir8,r8,1 > +965c:e8 89 00 09 ldu r4,8(r9) Looks like a harmless scheduling difference, but enough trigger the stage2/stage3 comparison. :( Peter
Re: Using -ffunction-sections and -p
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 think the target to check would be 32 bit HPUX. > > -ffunction-sections was largely driven by issues we wanted to resolve on the > PA. Does anybody still have access to a 32-bit HPUX machine? Ian
Re: Using -ffunction-sections and -p
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 was largely driven by issues we wanted to resolve on the PA. jeff
Re: Using -ffunction-sections and -p
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 compiling the kernel. This is >>> discussed in this thread: >>> >>> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html >>> >>> Ian's reply suggests this warning is no longer necessary and can be >>> removed. Is this patch alright to commit with all tests passing: >>> >>> * toplev.c (process_options): Do not warn when -ffunction-sections >>> and -fprofile are used together. >> >> In that thread Jeff suggested that this be tested on Solaris and PA. >> I don't know how to test on PA, but could somebody test the patch on >> Solaris? > > Is it reasonable to gate this using a target hook and start allowing > this on selected targets? For instance, i386 does not seem to have a > problem with this. At this point I don't know that any target at all has a problem with this. 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. Ian
Re: [C++] Possible GCC bug
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;
>};
> };
>
> compiles without a warning on Comeau and MSVC, but GCC (4.6.1 and
> 4.7.1) failes with the following message:
>
> $ gcc -c bug.cpp
> bug.cpp:18:24: error: declaration of ‘typedef class B::X C::X::super’
> [-fpermissive]
> bug.cpp:14:14: error: changes meaning of ‘super’ from ‘typedef class B
> C::super’ [-fpermissive]
>
> Should I file a report?
>
> Best regards, Piotr
Here's a two-line TC:
typedef struct { typedef int type; } s1;
struct S2 { s1::type s1; };
Fails with GCC 4.6.3; succeeds with clang 3.0. Looks like a bug to me.
/Ulf
Re: Using -ffunction-sections and -p
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: >> >> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html >> >> Ian's reply suggests this warning is no longer necessary and can be >> removed. Is this patch alright to commit with all tests passing: >> >> * toplev.c (process_options): Do not warn when -ffunction-sections >> and -fprofile are used together. > > In that thread Jeff suggested that this be tested on Solaris and PA. > I don't know how to test on PA, but could somebody test the patch on > Solaris? Is it reasonable to gate this using a target hook and start allowing this on selected targets? For instance, i386 does not seem to have a problem with this. Thanks, -Sri. > > Ian
Re: RFC: Updating boehm-gc to verion 7.2 (alpha 5)
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. This blocks the waiting >>> patches for libjava support for this target and some other features >>> depending on boehm-gc. Additional I saw that recently more and more >>> not upstream pushed patches getting applied to boehm-gc, which of >>> course makes an update even more worse. So, I would like to know how >>> boehm-gc shall be handled on gcc's tree. Is the gcc tree version a >>> fork for itself and shall be maintained seperately? Or, shall the >>> patches of boehm-gc done locally to gcc's tree sent upstream? >> >> Please send everything upstream. Once that's done we can copy >> the upstream branch directly into gcc. >> >> There may be problems with the testsuite, but we can deal with >> them as they arise. >> >> Andrew. >> > > Ok, I've posted the diffs to Ivan. I separated them into two pieces. > One all before testsuite patch (was last recent one) and the other > changes. Due the fact that a lot of files in boehm-gc have changed > places, I think it is better that Ivan does the diff here manually, as > it is sometime hard to find where file has gone, or if it is still > present. what's the status of this work? I'd like to see this update in 4.8, asked about this on the java list. Matthias
bootstrap comparison failure ppc64 FreeBSD
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=stage2-gcc/xgcc Target: powerpc64-unknown-freebsd10.0 Configured with: /export/devel/net/src/gcc/head/gcc/configure --prefix=/export/build/src/gcc/head/testbin --with-gmp=/usr/local --disable-lto --disable-nls --enable-languages=c,c++,fortran --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --disable-multilib --disable-checking Thread model: posix --- Below the diff of objdump -dS of the two files. Anyone an idea what's going wrong? TIA, Andreas --- stage2-tree-ssa-forwprop.dump 2012-11-14 18:40:23.0 +0100 +++ stage3-tree-ssa-forwprop.dump 2012-11-14 18:40:33.0 +0100 @@ -1,5 +1,5 @@ -stage2-gcc/tree-ssa-forwprop.o: file format elf64-powerpc +stage3-gcc/tree-ssa-forwprop.o: file format elf64-powerpc Disassembly of section .text: @@ -9664,8 +9664,8 @@ 964c: 40 9e f4 e8 bne+cr7,8b34 <._ZL33ssa_forward_propagate_and_combinev+0x1974> 9650: 38 a0 00 00 li r5,0 9654: 42 40 00 b4 bdz-9708 <._ZL33ssa_forward_propagate_and_combinev+0x2548> -9658: e8 89 00 09 ldu r4,8(r9) -965c: 39 08 00 01 addir8,r8,1 +9658: 39 08 00 01 addir8,r8,1 +965c: e8 89 00 09 ldu r4,8(r9) 9660: 4b ff ff d0 b 9630 <._ZL33ssa_forward_propagate_and_combinev+0x2470> 9664: 38 c0 00 00 li r6,0 9668: 4b ff ff ec b 9654 <._ZL33ssa_forward_propagate_and_combinev+0x2494>
Re: RFH - VEC API overhaul - Need testers
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/cxx-vec Diego.
[C++] Possible GCC bug
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) failes with the following message:
$ gcc -c bug.cpp
bug.cpp:18:24: error: declaration of ‘typedef class B::X C::X::super’
[-fpermissive]
bug.cpp:14:14: error: changes meaning of ‘super’ from ‘typedef class B
C::super’ [-fpermissive]
Should I file a report?
Best regards, Piotr
RFH - VEC API overhaul - Need testers
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 cloog to enable graphite. I'm testing on x86_64, ppc64, sparc and ia64. I'm also using config-list.mk to check all the targets for syntax errors. I would like to add other arches to the mix, so if you have any target other than the ones I'm testing on, I need your help. The code is currently in the git branch dnovillo/vec-rewrite. It is trunk current as of today. Thanks. Diego.
Re: -fPIC -fPIE
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 should use the one that >> appears last on the command line. >> >> Do we have an existing mechanism in options processing for one option >> to turn off another, where the options are not exact inverses? I >> looked for one but I didn't see one. There is support for that for >> options with the Mask property, but I don't see it for non-target >> options. > > pic and pie are mostly the same, but the pre-emption rules are different. > For fpie we don't have to permit pre-emption of global definitions. > > I hope we don't loose that distinction. No, of course not. All I'm talking about here is option processing when both -fPIC and -fPIE are provided. There is no change to the normal case of providing just -fPIC or just -fPIE. Ian
Re: lto is streamable?
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 true; > #endif > > sorts the problem out but my question is, why do we need to exclude > is_lang_specific(expr) from streamable trees Easy: because the lto1 compiler (then one that reads in those lto files again and compiles them all together into asm code) simply doesn't contain any code from the various language frontends, so language specific trees couldn't be handled anyway. If your tree can be handled by generic code then it isn't language specific. > and is there a workaround to allow this without changing the core? It doesn't make sense to change this. Ciao, Michael.
Re: -fPIC -fPIE
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 existing mechanism in options processing for one option to turn off another, where the options are not exact inverses? I looked for one but I didn't see one. There is support for that for options with the Mask property, but I don't see it for non-target options. Ian pic and pie are mostly the same, but the pre-emption rules are different. For fpie we don't have to permit pre-emption of global definitions. I hope we don't loose that distinction. R.
[Android] -fpic default option
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 ();
__attribute__ ((noinline))
detect_noreturn ()
{
exit (0);
}
int
main (void)
{
detect_noreturn ();
noreturn_autodetection_failed ();
return 0;
}
If gcc knew, that we are not going to make a shared library (which is
implied if we are using pic option), then it would delete the call of
noreturn_autodetection_failed as a dead code. But in case of pic we
cannot rely on the fact that detect_noreturn () will not be
overwritten on runtime, eventhough we are compiling executable and
that will never happen! So in addition to several testfails, it seems
that we are losing an optimization opportunity here also.
I'm wondering, maybe we can use -fpie instead of -fpic by default in
the compiler (of course if there are no -shared or -c options; those
cases will mean that we cannot rely on the fact that we will have an
executable after linking)? It seems that it would solve the problem..
Of course we always can add something like { target nonpic } to all
tests that fail on Android, but probably the problem is deeper than
that and that would be only hiding our head in the sand.
Re: lto is streamable?
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) >return true; > #endif > > sorts the problem out but my question is, why do we need to exclude > is_lang_specific(expr) from > streamable trees and is there a workaround to allow this without changing the > core? Because the LTO streamer only (well, mostly) deals with language-independent tree expressions. In the PPH branch we added support for streaming C++ trees. This makes use of the streaming call back mechanism you see in streamer-hooks.[ch], but you need to implement your own streaming if you want to write out language nodes. Diego.
lto is streamable?
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, why do we need to exclude is_lang_specific(expr) from streamable trees and is there a workaround to allow this without changing the core? Paulo Matos
Question on find_def_preds in tree-ssa-uninit.c
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 chain */
VEC_free (edge, heap, cur_chain);
cur_chain = 0;
/* Now update the newly added chains with
the phi operand edge: */
if (EDGE_COUNT (opnd_edge->src->succs) > 1)
{
if (prev_nc == num_chains
&& num_chains < MAX_NUM_CHAINS)
num_chains++;
for (j = prev_nc; j < num_chains; j++)
{
VEC_safe_push (edge, heap, dep_chains[j], opnd_edge);
}
}
If condition "prev_nc == num_chains", it means we have no control
dependent chain computed by compute_control_dep_chain this round. The
question is why we still apeend opnd_edge to the PREV_NCth chain? Is
it wrong or I missed something important.
Thanks
--
Best Regards.
