Re: [buildrobot] ARM: Missing initializers for Cortex A8

[Kyrill Tkachov]

On 24/04/14 22:07, Jan-Benedict Glaw wrote:

Hi!

Seems the new cost model for Cortex A8 is missing two initializer
fields:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace-o arm.o -MT arm.o -MMD -MP -MF 
./.deps/arm.TPo ../../../gcc/gcc/config/arm/arm.c
../../../gcc/gcc/config/arm/arm.c:1714:1: error: missing initializer for member 
‘tune_params::disparage_flag_setting_t16_encodings’ 
[-Werror=missing-field-initializers]
  };
  ^
../../../gcc/gcc/config/arm/arm.c:1714:1: error: missing initializer for member 
‘tune_params::disparage_partial_flag_setting_t16_encodings’ 
[-Werror=missing-field-initializers]
cc1plus: all warnings being treated as errors
make[2]: *** [arm.o] Error 1


I'll fix it up. The problem is the new Cortex-A8 tuning struct rather than the 
cost table itself. The new fields were added very recently and the Cortex-A8 
patch was developed before that.


Thanks for reporting.

Kyrill




(Cf. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=207555)

MfG, JBG

Re: How can I generate a new function at compile time?

[Richard Biener]

On Thu, Apr 24, 2014 at 6:00 PM, Benedikt Huber
 wrote:
> Hi!
>
> I want to uninline some basic blocks to a separate function to aid slp 
> vectorization.
> The new pass runs just before the slp vectorization pass.
> As a first try I create an new and empty function.
> Which in turn will be filled with some copies of basic blocks from the 
> original function.
> As an example I was looking at code in omp-low.c
> The pass itself seem to be successful,
> however I do not see the new function printed when using 
> -fdump-tree-all-details.
> Further more an ipa pass crashes with a segfault at an seemingly unrelated 
> location.
> I call gcc like this.
>
> /home/bhuber/sandbox/gcc/install/bin/gcc -std=c99 -O3 -I . -S 
> -fdump-tree-all-details -fdump-rtl-all-details -fdump-tree-vect=vec.out 
> -fopt-info-vec-missed=missed.out -ftree-vectorizer-verbose=6 
> -funinline-innermost-loops -ftree-slp-vectorize -Wall -Wextra 
> /home/bhuber/sandbox/try/vectorizable.c
> /home/bhuber/sandbox/try/vectorizable.c: In function '_GLOBAL__N_foo':
> /home/bhuber/sandbox/try/vectorizable.c:61:6: internal compiler error: 
> Segmentation fault
>  void foo ( int M
>   ^
> 0x99be1f crash_signal
> ../../src/gcc/toplev.c:337
> 0x9cdaac execute_fixup_cfg()
> ../../src/gcc/tree-cfg.c:8413
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> bhuber@android:~/sandbox/try/foo$
>
> The function to generate the empty function looks like this:
>
> static unsigned int
> make_empty_function (void)
> {
>   tree name, decl, type, t, block;
>   gimple_seq body = NULL;
>   gimple bind;
>
>   type = build_function_type_list (void_type_node, NULL_TREE);
>   name = get_file_function_name ("N");
>   decl = build_decl (input_location,
>  FUNCTION_DECL, name, type);
>
>   TREE_STATIC (decl) = 1;
>   TREE_USED (decl) = 1;
>   DECL_ARTIFICIAL (decl) = 1;
>   DECL_NAMELESS (decl) = 0;
>   DECL_IGNORED_P (decl) = 0;
>   TREE_PUBLIC (decl) = 0;
>   DECL_UNINLINABLE (decl) = 1;
>   DECL_EXTERNAL (decl) = 0;
>   DECL_CONTEXT (decl) = NULL_TREE;
>
>   block = make_node (BLOCK);
>   DECL_INITIAL (decl) = block;
>
>   t = build_decl (DECL_SOURCE_LOCATION (decl),
>   RESULT_DECL, NULL_TREE, void_type_node);
>   DECL_ARTIFICIAL (t) = 1;
>   DECL_IGNORED_P (t) = 1;
>   DECL_CONTEXT (t) = decl;
>   DECL_RESULT (decl) = t;
>
>   push_struct_function (decl);
>
>   pop_cfun ();
>
>   bind = gimple_build_bind (NULL, body, block);
>   gimple_seq_add_stmt (&body, bind);
>   gimple_set_body (decl, body);
>
>   DECL_STRUCT_FUNCTION (decl)->curr_properties = cfun->curr_properties;
>
>   cgraph_add_new_function (decl, true);
>
>   return 0;
> }
>
> I am working on trunk.
> Please note that this is experimental code to get to know gcc internals.
> What am I doing wrong?

Look at move_sese_region_to_fn (and it's user).

RIchard.

> Thank you in advance and best regards,
> Benedikt

Re: [RFC] Meta-description for tree and gimple folding

[Richard Biener]

On Thu, 24 Apr 2014, Jeff Law wrote:

> On 02/28/14 08:21, Kai Tietz wrote:
> > Hmm,  this all reminds me about the approach Andrew Pinski and I came
> > up with two years ago.  All in all I think it might be worth to
> > express folding-patterns in a more abstract way.  So the md-like Lisp
> > syntax for this seems to be just stringent.  We make use of such a
> > script-language already for machine-description.
> > 
> > Nevertheless I doubt that we really want to have same facility for
> > fold-const and gimple.  Instead I got the impression that we would
> > prefer to have all folding-optimizations instead in Middle-end
> > (GIMPLE).  We need folding in front-end (AST) mostly for determination
> > of constant-expression detection. Otherwise we want to keep maximum of
> > original AST to have best results for debugging (and even to think
> > about having alternative FE on our middle/backend) and code-analyzers.
> This is the core of what I want to see happening.  I'm open to whatever
> methods we use to take us in that direction.
> 
> The way I tend to think leads me to a "hmm, fold-const.c does X, move it to
> gimple" and iterate approach.  But again, that's just the way I tend to look
> at problems.
> 
> If we can describe significant hunks of folding using a pattern selection
> language and generate code to recognize and transform the IL, then that seems
> good to me  as long as we keep the goal of moving most folding out of the
> front-ends.
> 
> So if Richi and GSOC students want to experiment in this space, possibly
> baking off with other approaches that delay folding, that's fine with me.

Btw, while there is the possibility to generate GENERIC foldings from
the meta-description for each and every pattern and use that from fold
it is not necessary to do that.

Note that the work also includes adding API that gets rid of most
(if not all) [fold_]buildN and force_gimple_operand_* calls from
GIMPLE passes (thus, not building GENERIC - just for the ability
to fold it - and then gimplifying it).  Instead of

 tree x = fold_build2 (PLUS_EXPR, type, y, build_int_cst (type, 1));
 tree ex = fold_build2 (EQ_EXPR, boolean_type_node, x, y);
 ex = force_gimple_operand (ex, &stmts, true, NULL_TREE);

you do

 tree x = gimple_build (&stmts, PLUS_EXPR, type, y, build_int_cst (type, 1));
 tree ex = gimple_build (&stmts, EQ_EXPR, boolean_type_node, x, y);

where the implementation on the branch (obviously) relies on the
patterns to simplify the built expressions.

This should also help Andrew with his GIMPLE type re-org as it frees
him from touching fold ... (well, if all code is properly converted).

It of course remains to be seen if we can reasonably translate the
main part of the foldings passes rely on to the pattern representation.
Nothing prevents us from providing a "tail" of manually written
simplifications of course, used by the same API, but I'd like to
avoid that.

I hope that for 4.10 we get up to the point of using the machinery
for a gimple-combine pass (currently tree forwprop) and stop adding
simplifications to forwprop and instead extend the pattern description.
I also hope to convert most passes over to gimple_build (requires
mostly simple arithmetic simplification and simplification of
conditionals).

Comments on the actual code are always welcome - we'll do
all the GSOC project discussions on implementation details in
public to invite others to comment.

Richard.

RE: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c

[Dhakshinamoorthy, Soundararajan]

Hi, 

I have attached a patch based on the recommendation. Can you please review and 
apply, if it looks ok ?. I don't have commit access.


gcc/testsuite/ChangeLog

2014-04-25  Soundararajan Dhakshinamoorthy  

* gcc.c-torture/execute/pr58419.c: Adjust the test to work with bare 
metal targets. The 
   test code references to functions that is not implemented for the 
avr target (getpid()).

Thanks,
Soundararajan


From: Jeff Law [l...@redhat.com]
Sent: 23 April 2014 21:59:52
To: Dhakshinamoorthy, Soundararajan; gcc-ow...@gcc.gnu.org
Subject: Re: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c

On 04/23/14 05:50, Dhakshinamoorthy, Soundararajan wrote:
> Hi all,
>
> The test mentioned in the link had a call to getpid which causes the test to 
> fail for bare metal targets. Is it ok to replace it with
> printf("\0") ?
>
> which seems to be the first version of the test.
You want to avoid the printf.  Instead I think a dummy function that is
marked as noinline should be sufficient -- I just haven't had the time
to verify that myself.

Jeff

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr58419.c b/gcc/testsuite/gcc.c-torture/execute/pr58419.c
index 69cc040..78bf437 100644
--- a/gcc/testsuite/gcc.c-torture/execute/pr58419.c
+++ b/gcc/testsuite/gcc.c-torture/execute/pr58419.c
@@ -1,4 +1,9 @@
-int printf(const char *, ...);
+__attribute__((__noinline__))
+void
+dummy ()
+{
+  asm volatile("");
+}
 
 int a, g, i, k, *p;
 signed char b;
@@ -31,6 +36,6 @@ main ()
   *l = a;
   g = foo (*m = k && *d, 1 > i) || bar (); 
 }
-  getpid();
+  dummy();
   return 0;
 }

IPA: Devirtualization versus placement new

[Andrew Haley]

Summary: Devirtualization uses type information to determine if a
virtual method is reachable from a call site.  If type information
indicates that it is not, devirt marks the site as unreachable.  I
think this is wrong, and it breaks some programs.  At least, it should
not do this if the user specifies -fno-strict-aliasing.

Consider this class:

class Container {
  void *buffer[5];
public:
  EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
  Container() { new (buffer) EmbeddedObject(); }
};

Placement new is used to embed an object in a buffer inside another
object.  Its address can be retrieved.  This usage of placement new is
common, and it even appears as the canonical use of placement new in
the in the C++ FAQ at
http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
this is not strictly legal.  For one thing, the memory at buffer may
not be suitably aligned.  Please bear with me.)

The embedded object is an instance of:

class EmbeddedObject {
public:
  virtual int val() { return 2; }
};

And it is called like this:

extern Container o;
int main() {

  cout << o.obj()->val() << endl;
}

The devirtualization pass looks into the call to val() and the type of
o, decides that there is no type inside o that is compatible with
EmbeddedObject, and inserts a call to __builtin_unreachanble().  As a
result, instead of printing 2, the program does nothing.

I'm not sure what this transformation is supposed to achieve.  It does
nothing for strictly compliant code and it silently breaks non-
compliant code like this.  GCC users would be better off if it were
not done.  At least an error message could be printed instead of silently
failing to generate code.

IMO, this transformation should not be performed when
-fno-strict-aliasing is used.

`-fstrict-aliasing'
 Allow the compiler to assume the strictest aliasing rules
 applicable to the language being compiled.  For C (and C++), this
 activates optimizations based on the type of expressions.

I have appended a suggested patch to this message.

Andrew.


Index: gcc/ipa-devirt.c
===
--- gcc/ipa-devirt.c(revision 209656)
+++ gcc/ipa-devirt.c(working copy)
@@ -1362,8 +1362,9 @@

  /* Only type inconsistent programs can have otr_type that is
 not part of outer type.  */
- if (!contains_type_p (TREE_TYPE (base),
-   context->offset + offset2, *otr_type))
+ if (flag_strict_aliasing
+ && !contains_type_p (TREE_TYPE (base),
+  context->offset + offset2, 
*otr_type))
{
  /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
inconsistent
 code sequences; we arrange the calls to be 
builtin_unreachable
@@ -1441,7 +1442,8 @@
  gcc_assert (!POINTER_TYPE_P (context->outer_type));
  /* Only type inconsistent programs can have otr_type that is
 not part of outer type.  */
- if (!contains_type_p (context->outer_type, context->offset,
+ if (flag_strict_aliasing
+ && !contains_type_p (context->outer_type, context->offset,
*otr_type))
{
  /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
inconsistent



embed-test.tar
Description: Unix tar archive

Re: IPA: Devirtualization versus placement new

[Jonathan Wakely]

On 25 April 2014 11:22, Andrew Haley wrote:
> Summary: Devirtualization uses type information to determine if a
> virtual method is reachable from a call site.  If type information
> indicates that it is not, devirt marks the site as unreachable.  I
> think this is wrong, and it breaks some programs.  At least, it should
> not do this if the user specifies -fno-strict-aliasing.
>
> Consider this class:
>
> class Container {
>   void *buffer[5];
> public:
>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>   Container() { new (buffer) EmbeddedObject(); }
> };
>
> Placement new is used to embed an object in a buffer inside another
> object.  Its address can be retrieved.  This usage of placement new is
> common, and it even appears as the canonical use of placement new in
> the in the C++ FAQ at
> http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
> this is not strictly legal.  For one thing, the memory at buffer may
> not be suitably aligned.  Please bear with me.)

I think the program is strictly legal if you define Container like this:

class Container {
  alignas(EmbeddedObject) char buffer[sizeof(EmbeddedObject)];
public:
  EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
  Container() { new (buffer) EmbeddedObject(); }
};

But GCC still does the same transformation and prints nothing, which I
agree is wrong (even with -fstrict-aliasing).

With ubsan that program gives:

sa.cc:9:24: runtime error: load of null pointer of type ' *'
Segmentation fault (core dumped)

Re: IPA: Devirtualization versus placement new

[Martin Jambor]

Hi,


On Fri, Apr 25, 2014 at 11:22:22AM +0100, Andrew Haley wrote:
> Summary: Devirtualization uses type information to determine if a
> virtual method is reachable from a call site.  If type information
> indicates that it is not, devirt marks the site as unreachable.  I
> think this is wrong, and it breaks some programs.  At least, it should
> not do this if the user specifies -fno-strict-aliasing.
> 
> Consider this class:
> 
> class Container {
>   void *buffer[5];
> public:
>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>   Container() { new (buffer) EmbeddedObject(); }
> };
> 
> Placement new is used to embed an object in a buffer inside another
> object.  Its address can be retrieved.  This usage of placement new is
> common, and it even appears as the canonical use of placement new in
> the in the C++ FAQ at
> http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
> this is not strictly legal.  For one thing, the memory at buffer may
> not be suitably aligned.  Please bear with me.)
> 
> The embedded object is an instance of:
> 
> class EmbeddedObject {
> public:
>   virtual int val() { return 2; }
> };
> 
> And it is called like this:
> 
> extern Container o;
> int main() {
> 
>   cout << o.obj()->val() << endl;
> }
> 
> The devirtualization pass looks into the call to val() and the type of
> o, decides that there is no type inside o that is compatible with
> EmbeddedObject, and inserts a call to __builtin_unreachanble().  As a
> result, instead of printing 2, the program does nothing.
> 
> I'm not sure what this transformation is supposed to achieve.  It does
> nothing for strictly compliant code

It can be and often is useful.  Very often such calls are in a branch
that is guarded by a type check and performs a down-cast.
Devirtualization can figure out the branch is unreachable when it
knows that the call in it would be illegal.  (And yes, placement new
has been considered, see PR 45734, especially comment #4.)

In this case, however, I believe that ipa-devirt should not mark its
result as final if the offset with outer_type leads to a
non-artificial field, certainly not if such a field is a POD,
regardless of any compiler option.  I believe you should open a PR for
this.

Martin


> and it silently breaks non-
> compliant code like this.  GCC users would be better off if it were
> not done.  At least an error message could be printed instead of silently
> failing to generate code.
> 
> IMO, this transformation should not be performed when
> -fno-strict-aliasing is used.
> 
> `-fstrict-aliasing'
>  Allow the compiler to assume the strictest aliasing rules
>  applicable to the language being compiled.  For C (and C++), this
>  activates optimizations based on the type of expressions.
> 
> I have appended a suggested patch to this message.
> 
> Andrew.
> 
> 
> Index: gcc/ipa-devirt.c
> ===
> --- gcc/ipa-devirt.c  (revision 209656)
> +++ gcc/ipa-devirt.c  (working copy)
> @@ -1362,8 +1362,9 @@
> 
> /* Only type inconsistent programs can have otr_type that is
>not part of outer type.  */
> -   if (!contains_type_p (TREE_TYPE (base),
> - context->offset + offset2, *otr_type))
> +   if (flag_strict_aliasing
> +   && !contains_type_p (TREE_TYPE (base),
> +context->offset + offset2, 
> *otr_type))
>   {
> /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
> inconsistent
>code sequences; we arrange the calls to be 
> builtin_unreachable
> @@ -1441,7 +1442,8 @@
> gcc_assert (!POINTER_TYPE_P (context->outer_type));
> /* Only type inconsistent programs can have otr_type that is
>not part of outer type.  */
> -   if (!contains_type_p (context->outer_type, context->offset,
> +   if (flag_strict_aliasing
> +   && !contains_type_p (context->outer_type, context->offset,
>   *otr_type))
>   {
> /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
> inconsistent
> 

Re: IPA: Devirtualization versus placement new

[Richard Biener]

On Fri, Apr 25, 2014 at 1:18 PM, Jonathan Wakely  wrote:
> On 25 April 2014 11:22, Andrew Haley wrote:
>> Summary: Devirtualization uses type information to determine if a
>> virtual method is reachable from a call site.  If type information
>> indicates that it is not, devirt marks the site as unreachable.  I
>> think this is wrong, and it breaks some programs.  At least, it should
>> not do this if the user specifies -fno-strict-aliasing.
>>
>> Consider this class:
>>
>> class Container {
>>   void *buffer[5];
>> public:
>>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>>   Container() { new (buffer) EmbeddedObject(); }
>> };
>>
>> Placement new is used to embed an object in a buffer inside another
>> object.  Its address can be retrieved.  This usage of placement new is
>> common, and it even appears as the canonical use of placement new in
>> the in the C++ FAQ at
>> http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
>> this is not strictly legal.  For one thing, the memory at buffer may
>> not be suitably aligned.  Please bear with me.)
>
> I think the program is strictly legal if you define Container like this:
>
> class Container {
>   alignas(EmbeddedObject) char buffer[sizeof(EmbeddedObject)];
> public:
>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>   Container() { new (buffer) EmbeddedObject(); }
> };
>
> But GCC still does the same transformation and prints nothing, which I
> agree is wrong (even with -fstrict-aliasing).

I agree, -fstrict-aliasing has nothing to do with this.  Sounds simply like
a genuine bug (please open a bugzilla).

Thanks,
Richard.

> With ubsan that program gives:
>
> sa.cc:9:24: runtime error: load of null pointer of type ' *'
> Segmentation fault (core dumped)

Re: IPA: Devirtualization versus placement new

[Jonathan Wakely]

On 25 April 2014 13:01, Richard Biener wrote:
> On Fri, Apr 25, 2014 at 1:18 PM, Jonathan Wakely  
> wrote:
>> On 25 April 2014 11:22, Andrew Haley wrote:
>>> Summary: Devirtualization uses type information to determine if a
>>> virtual method is reachable from a call site.  If type information
>>> indicates that it is not, devirt marks the site as unreachable.  I
>>> think this is wrong, and it breaks some programs.  At least, it should
>>> not do this if the user specifies -fno-strict-aliasing.
>>>
>>> Consider this class:
>>>
>>> class Container {
>>>   void *buffer[5];
>>> public:
>>>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>>>   Container() { new (buffer) EmbeddedObject(); }
>>> };
>>>
>>> Placement new is used to embed an object in a buffer inside another
>>> object.  Its address can be retrieved.  This usage of placement new is
>>> common, and it even appears as the canonical use of placement new in
>>> the in the C++ FAQ at
>>> http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
>>> this is not strictly legal.  For one thing, the memory at buffer may
>>> not be suitably aligned.  Please bear with me.)
>>
>> I think the program is strictly legal if you define Container like this:
>>
>> class Container {
>>   alignas(EmbeddedObject) char buffer[sizeof(EmbeddedObject)];
>> public:
>>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>>   Container() { new (buffer) EmbeddedObject(); }
>> };
>>
>> But GCC still does the same transformation and prints nothing, which I
>> agree is wrong (even with -fstrict-aliasing).
>
> I agree, -fstrict-aliasing has nothing to do with this.  Sounds simply like
> a genuine bug (please open a bugzilla).
>
> Thanks,
> Richard.
>
>> With ubsan that program gives:
>>
>> sa.cc:9:24: runtime error: load of null pointer of type ' *'
>> Segmentation fault (core dumped)

I created http://gcc.gnu.org/60963 for the ubsan error. The testcase
there is a single file which crashes with ubsan and returns the wrong
value without.  Changing the return statement to
__builtin_printf("%d\n", o.obj()->val()) prints nothing, like Andrew's
original example.

If it's not really a ubsan problem feel free to re-categorise that as
a devirt bug rather than open a new one, whatever's most appropriate.

SPARC LEON3 and CAS instruction

[Sebastian Huber]

Hello,

recent GCC versions support the C11 atomic operations for the SPARC LEON3 
processor via the CASA instruction.  GCC emits CASA instructions with an ASI of 
0x80.  I think this is due to the usage of "cas" if I get the stuff in sync.md 
right:


"(define_insn "*atomic_compare_and_swap_1"
  [(set (match_operand:I48MODE 0 "register_operand" "=r")
(match_operand:I48MODE 1 "mem_noofs_operand" "+w"))
   (set (match_dup 1)
(unspec_volatile:I48MODE
  [(match_operand:I48MODE 2 "register_operand" "r")
   (match_operand:I48MODE 3 "register_operand" "0")]
  UNSPECV_CAS))]
  "(TARGET_V9 || TARGET_LEON3) && (mode != DImode || TARGET_ARCH64)"
  "cas\t%1, %2, %0"
  [(set_attr "type" "multi")])"

According to the LEON3 manual we have:

"6.2.7 Compare and Swap instruction (CASA)

LEON4 implements the SPARC V9 Compare and Swap Alternative (CASA) instruction. 
The CASA operates as described in the SPARC V9 manual. The instruction is 
privileged, except when setting ASI = 0xA (user data)."


I would like to use atomic operations in user mode.  Is it possible to add a 
machine option to GCC to use an ASI of 0x0A for the atomic operations via CASA 
on LEON3?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: IPA: Devirtualization versus placement new

[Andrew Haley]

On 04/25/2014 01:01 PM, Richard Biener wrote:
> I agree, -fstrict-aliasing has nothing to do with this.  Sounds simply like
> a genuine bug (please open a bugzilla).

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

Andrew.

Stack offset computation for incoming arguments.

[Umesh Kalappa]

Hi All,

Our private backend has the macro  defined as

#define FIRST_PARM_OFFSET(FNDECL)  (get_frame_size() +
STARTING_FRAME_OFFSET  + RETURN_BYTES )

#define STARTING_FRAME_OFFSET  1

#define STACK_POINTER_REGNUM10

#define FRAME_POINTER_REGNUM STACK_POINTER_REGNUM

#define ARG_POINTER_REGNUM STACK_POINTER_REGNUM

#define  RETURN_BYTES  2

The  pass i.e instantiate_virtual_regs  set the  in_arg_offset as

in_arg_offset = FIRST_PARM_OFFSET (current_function_decl);

the computed  frame_size is X and in_arg_offset is X + 1 + 2  i.e X + 3.

And calls the instantiate_virtual_regs_in_rtx function  ,which emits
the insns to access the incoming argumnets (that are passed with
stack) via stack_pointer_rtx  + in_arg_offset (stack grows downward).

But in the reload pass the the alter_reg function (spill the  reg to
stack ) expand the stack frame and update the frame_size i.e  X = X +
allocated space.

For each spill the frame_size is updated  and at the end of the reload
pass the frame_size=frame_size+ total_allocated_spilled _space;

Our prologue  code looks like

void expand_prologue()
{

HOST_WIDE_INT frame_size = get_frame_size ();  //here
frame_size=frame_size+ total_allocated_spilled _space;
rtx reg,insn ;

if(frame_size > 0 )
{
insn =
emit_move_insn(stack_pointer_rtx,gen_rtx_MINUS(GET_MODE(stack_pointer_rtx),stack_pointer_rtx,(GEN_INT(frame_size))
));
RTX_FRAME_RELATED_P (insn) = 1;
}
}


The problem is that the frame_size is not same ,when there is the
spill code between  instantiate_virtual_regs_in_rtx()  and
expand_prologue() ,hence incoming arg offset goes for a  toss like

sub sp ,10// prologue where frame_size =10

ld  R1,sp   // accessing the first argument that is passed
in the stack;
add R1, 11   // the offset should be 13  i.e frame_size + 1 +
2; but it is 11 (stack_pointer_rtx  + (in_arg_offset =11)  where the
frame_size is 8  for locals )
ld  R2, [R1]

ld[sp+9] ,R10  // spill code

add sp,10 // epilogue

In the above asm  the  incoming arguments fetch  going for a  toss
,Any idea what  going wrong with the computation offset for incoming
arguments  here ??

Thank you
~Umesh

Re: IPA: Devirtualization versus placement new

[Volker Simonis]

On Fri, Apr 25, 2014 at 2:05 PM, Jonathan Wakely  wrote:
>On 25 April 2014 13:01, Richard Biener wrote:
>> On Fri, Apr 25, 2014 at 1:18 PM, Jonathan Wakely  
>> wrote:
>>> On 25 April 2014 11:22, Andrew Haley wrote:
 Summary: Devirtualization uses type information to determine if a
 virtual method is reachable from a call site.  If type information
 indicates that it is not, devirt marks the site as unreachable.  I
 think this is wrong, and it breaks some programs.  At least, it should
 not do this if the user specifies -fno-strict-aliasing.

 Consider this class:

 class Container {
   void *buffer[5];
 public:
   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
   Container() { new (buffer) EmbeddedObject(); }
 };

 Placement new is used to embed an object in a buffer inside another
 object.  Its address can be retrieved.  This usage of placement new is
 common, and it even appears as the canonical use of placement new in
 the in the C++ FAQ at
 http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
 this is not strictly legal.  For one thing, the memory at buffer may
 not be suitably aligned.  Please bear with me.)
>>>
>>> I think the program is strictly legal if you define Container like this:
>>>
>>> class Container {
>>>   alignas(EmbeddedObject) char buffer[sizeof(EmbeddedObject)];
>>> public:
>>>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>>>   Container() { new (buffer) EmbeddedObject(); }
>>> };
>>>
>>> But GCC still does the same transformation and prints nothing, which I
>>> agree is wrong (even with -fstrict-aliasing).
>>
>> I agree, -fstrict-aliasing has nothing to do with this.  Sounds simply like
>> a genuine bug (please open a bugzilla).
>>
>> Thanks,
>> Richard.
>>
>>> With ubsan that program gives:
>>>
>>> sa.cc:9:24: runtime error: load of null pointer of type ' *'
>>> Segmentation fault (core dumped)
>
>I created http://gcc.gnu.org/60963 for the ubsan error. The testcase
>there is a single file which crashes with ubsan and returns the wrong
>value without.  Changing the return statement to
>__builtin_printf("%d\n", o.obj()->val()) prints nothing, like Andrew's
>original example.
>
>If it's not really a ubsan problem feel free to re-categorise that as
>a devirt bug rather than open a new one, whatever's most appropriate.
>

Hi Jonathan,

I don't think this is a ubsan bug. I rather think it is an devirt bug.
If you look at the generated code (taking Andrews initial example) you
can see the following:

00400720 :
main():
/tmp/embed-test/embed.cpp:7
  400720:   48 83 ec 08 sub$0x8,%rsp
/tmp/embed-test/embed.cpp:9
  400724:   48 83 3d b4 07 20 00cmpq   $0x0,0x2007b4(%rip)
   # 600ee0 
  40072b:   00
  40072c:   74 00   je 40072e 
  40072e:   31 f6   xor%esi,%esi
  400730:   bf 80 0d 60 00  mov$0x600d80,%edi
  400735:   e8 d6 ff ff ff  callq  400710
<__ubsan_handle_type_mismatch@plt>
  40073a:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)

So because of the devirt bug, the main method unconditionally falls
into the ubsan handler and misleadingly prints the warning. Afterwards
it crashes, but again not because of an ubsan error, but because it
wrongly entered the ubsan handler et all because of the
devirtualization bug.

Notice that this bug was first detected while compiling the OpenJDK
with gcc 4.9.0 (see mail threads at
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/thread.html#13577
and http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013614.html).
We as well compiled OpenJDK with -fsanitze=undefined and got some
warnings. But after a closer look it turned out these were false
positives as well, for exactly the same reason. As you can read in
this mail 
(http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013602.html)
the OpenJDK code executed several ubsan handlers not because the
corresponding NULL-checks failed, but because the code for the
containing method had nor return at the end and just fell over into
the ubsan handlers.

Could you therefore please re-categorize this as devirt bug.

Thank you and best regards,
Volker

Re: IPA: Devirtualization versus placement new

[Andrew Haley]

On 04/25/2014 03:14 PM, Volker Simonis wrote:
> Could you therefore please re-categorize this as devirt bug.

It is an IPA bug.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

Andrew.

[GSoC] TYPE stringfied in call to add_operator

[Prathamesh Kulkarni]

Hi,
I have a daft question to ask. I was looking through genmatch, I
couldn't figure out why is tree code class (TYPE) stringified in call
to add_operator () ?

#define DEFTREECODE (SYM, STRING, TYPE, NARGS) \
add_operator (SYM, #SYM, #TYPE, NARGS)

In add_operator()  tcc (argument corresponding to TYPE) is only used
to check if the tree code belongs to one of (tcc_unary, tcc_binary,
tcc_comparison, tcc_expression, tcc_reference) classes. Why can't we
use enum tree_code_class for tcc ?

Thanks and Regards,
Prathamesh

How to access points-to information for function pointers

[Swati Rathi]

Hello,

I am trying to print points-to information for SSA variables as below.

  for (i = 1; i < num_ssa_names; i++)
{
  tree ptr = ssa_name (i);
  struct ptr_info_def *pi;

  if (ptr == NULL_TREE
  || SSA_NAME_IN_FREE_LIST (ptr))
continue;

  pi = SSA_NAME_PTR_INFO (ptr);
  if (pi)
dump_points_to_info_for (file, ptr);
}

-
My test program is given below :

int main()
{
  int *p, i, j;
  void (*fp1)();

  if (i)
  {
p = &i;
fp1 = fun1;
  }
else
  {
p = &j;
fp1 = fun2;
  }

fp1();

  printf ("\n%d %d\n", *p, i);
  return 0;
}
-
I get the output as :-

p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-

Why is the pointees for function pointer not getting dumped?
How can I access this information?


Regards,
Swati

Re: IPA: Devirtualization versus placement new

[Jan Hubicka]

> Summary: Devirtualization uses type information to determine if a
> virtual method is reachable from a call site.  If type information
> indicates that it is not, devirt marks the site as unreachable.  I
> think this is wrong, and it breaks some programs.  At least, it should
> not do this if the user specifies -fno-strict-aliasing.
> 
> Consider this class:
> 
> class Container {
>   void *buffer[5];
> public:
>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>   Container() { new (buffer) EmbeddedObject(); }
> };
> 
> Placement new is used to embed an object in a buffer inside another
> object.  Its address can be retrieved.  This usage of placement new is
> common, and it even appears as the canonical use of placement new in
> the in the C++ FAQ at
> http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
> this is not strictly legal.  For one thing, the memory at buffer may
> not be suitably aligned.  Please bear with me.)
> 
> The embedded object is an instance of:
> 
> class EmbeddedObject {
> public:
>   virtual int val() { return 2; }
> };
> 
> And it is called like this:
> 
> extern Container o;
> int main() {
> 
>   cout << o.obj()->val() << endl;
> }
> 
> The devirtualization pass looks into the call to val() and the type of
> o, decides that there is no type inside o that is compatible with
> EmbeddedObject, and inserts a call to __builtin_unreachanble().  As a
> result, instead of printing 2, the program does nothing.

I see, the rule I am trying to apply here is that by Jason you can not
use placement new to turn one non-POD to another non-POD.
Here you turn char buffer that happens to be at same address as non-POD.
I actually intedned to implement it as non-polymorphic type to  non-polymorphic
type, will make fix in this sense (i.e. not mark context invalid if the outer
type is non-polymorphic). I think that should also fix your container example
and if container had virtual method in it, we will be all fine since buffer
will not be 0th item. Does that sound OK?
> 
> I'm not sure what this transformation is supposed to achieve.  It does
> nothing for strictly compliant code and it silently breaks non-
> compliant code like this.  GCC users would be better off if it were
> not done.  At least an error message could be printed instead of silently
> failing to generate code.

The pattern is relatively common in a valid code when you do 
upcasting/downcasting.
Imagine we had gimple converted to class hiearchy with virtual methods in it.
We had gimple_label type for labels that got converted to gimple and called to
generic function that does type checking (invisible to the pass) and casts to
gimple_assign (only on path where it is indeed assignment). Then you call
lhs method that is not defined for gimple_label.
We want to detect these cases and not work hard to inline them. It is 
surprisingly
common in C++ code, i.e. over 5% on firefox.
> 
> IMO, this transformation should not be performed when
> -fno-strict-aliasing is used.
> 
> `-fstrict-aliasing'
>  Allow the compiler to assume the strictest aliasing rules
>  applicable to the language being compiled.  For C (and C++), this
>  activates optimizations based on the type of expressions.
> 
> I have appended a suggested patch to this message.

I agree with Richard that we want to keep this independent of -fstrict-aliasing.

Honza
> 
> Andrew.
> 
> 
> Index: gcc/ipa-devirt.c
> ===
> --- gcc/ipa-devirt.c  (revision 209656)
> +++ gcc/ipa-devirt.c  (working copy)
> @@ -1362,8 +1362,9 @@
> 
> /* Only type inconsistent programs can have otr_type that is
>not part of outer type.  */
> -   if (!contains_type_p (TREE_TYPE (base),
> - context->offset + offset2, *otr_type))
> +   if (flag_strict_aliasing
> +   && !contains_type_p (TREE_TYPE (base),
> +context->offset + offset2, 
> *otr_type))
>   {
> /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
> inconsistent
>code sequences; we arrange the calls to be 
> builtin_unreachable
> @@ -1441,7 +1442,8 @@
> gcc_assert (!POINTER_TYPE_P (context->outer_type));
> /* Only type inconsistent programs can have otr_type that is
>not part of outer type.  */
> -   if (!contains_type_p (context->outer_type, context->offset,
> +   if (flag_strict_aliasing
> +   && !contains_type_p (context->outer_type, context->offset,
>   *otr_type))
>   {
> /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
> inconsistent
> 

Re: Stack offset computation for incoming arguments.

[Eric Botcazou]

> #define FIRST_PARM_OFFSET(FNDECL)  (get_frame_size() +
> STARTING_FRAME_OFFSET  + RETURN_BYTES )

I don't think that you can define FIRST_PARM_OFFSET like so, you need to have 
a fixed FIRST_PARM_OFFSET (for some definition of fixed) and eliminate the 
argument pointer during reload.

-- 
Eric Botcazou

Re: SPARC LEON3 and CAS instruction

[Eric Botcazou]

> recent GCC versions support the C11 atomic operations for the SPARC LEON3
> processor via the CASA instruction.  GCC emits CASA instructions with an ASI
> of 0x80.  I think this is due to the usage of "cas" if I get the stuff in
> sync.md right:
> 
> "(define_insn "*atomic_compare_and_swap_1"
>[(set (match_operand:I48MODE 0 "register_operand" "=r")
>   (match_operand:I48MODE 1 "mem_noofs_operand" "+w"))
> (set (match_dup 1)
>   (unspec_volatile:I48MODE
> [(match_operand:I48MODE 2 "register_operand" "r")
>  (match_operand:I48MODE 3 "register_operand" "0")]
> UNSPECV_CAS))]
>"(TARGET_V9 || TARGET_LEON3) && (mode != DImode || TARGET_ARCH64)"
>"cas\t%1, %2, %0"
>[(set_attr "type" "multi")])"

Right, this is a bug, both in the compiler and the assembler, since an ASI of 
0x80 is not allowed for SPARC-V8.

> According to the LEON3 manual we have:
> 
> "6.2.7 Compare and Swap instruction (CASA)
> 
> LEON4 implements the SPARC V9 Compare and Swap Alternative (CASA)
> instruction. The CASA operates as described in the SPARC V9 manual. The
> instruction is privileged, except when setting ASI = 0xA (user data)."
> 
> I would like to use atomic operations in user mode.  Is it possible to add a
> machine option to GCC to use an ASI of 0x0A for the atomic operations via
> CASA on LEON3?

Yes, I guess we actually want to emit an ASI of either 0xA (user data) or 0xB 
(supervisor data), predicated on -muser-mode.  I'll prepare a patch.

-- 
Eric Botcazou

Re: SPARC LEON3 and CAS instruction

[Daniel Gutson]

On Fri, Apr 25, 2014 at 1:31 PM, Eric Botcazou  wrote:
>> recent GCC versions support the C11 atomic operations for the SPARC LEON3
>> processor via the CASA instruction.  GCC emits CASA instructions with an ASI
>> of 0x80.  I think this is due to the usage of "cas" if I get the stuff in
>> sync.md right:
>>
>> "(define_insn "*atomic_compare_and_swap_1"
>>[(set (match_operand:I48MODE 0 "register_operand" "=r")
>>   (match_operand:I48MODE 1 "mem_noofs_operand" "+w"))
>> (set (match_dup 1)
>>   (unspec_volatile:I48MODE
>> [(match_operand:I48MODE 2 "register_operand" "r")
>>  (match_operand:I48MODE 3 "register_operand" "0")]
>> UNSPECV_CAS))]
>>"(TARGET_V9 || TARGET_LEON3) && (mode != DImode || TARGET_ARCH64)"
>>"cas\t%1, %2, %0"
>>[(set_attr "type" "multi")])"
>
> Right, this is a bug, both in the compiler and the assembler, since an ASI of
> 0x80 is not allowed for SPARC-V8.
>
>> According to the LEON3 manual we have:
>>
>> "6.2.7 Compare and Swap instruction (CASA)
>>
>> LEON4 implements the SPARC V9 Compare and Swap Alternative (CASA)
>> instruction. The CASA operates as described in the SPARC V9 manual. The
>> instruction is privileged, except when setting ASI = 0xA (user data)."
>>
>> I would like to use atomic operations in user mode.  Is it possible to add a
>> machine option to GCC to use an ASI of 0x0A for the atomic operations via
>> CASA on LEON3?
>
> Yes, I guess we actually want to emit an ASI of either 0xA (user data) or 0xB
> (supervisor data), predicated on -muser-mode.  I'll prepare a patch.

Since we are using RTEMS on Leon3 (and maybe moving to Leon4),
we're interested in getting this fixed too; feel free to assign us the
issue to fix it if you have no
time.

   Daniel.

>
> --
> Eric Botcazou



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211

Skype: dgutson

Re: [GSoC] TYPE stringfied in call to add_operator

[Richard Biener]

On April 25, 2014 4:54:28 PM CEST, Prathamesh Kulkarni 
 wrote:
>Hi,
>I have a daft question to ask. I was looking through genmatch, I
>couldn't figure out why is tree code class (TYPE) stringified in call
>to add_operator () ?
>
>#define DEFTREECODE (SYM, STRING, TYPE, NARGS) \
>add_operator (SYM, #SYM, #TYPE, NARGS)
>
>In add_operator()  tcc (argument corresponding to TYPE) is only used
>to check if the tree code belongs to one of (tcc_unary, tcc_binary,
>tcc_comparison, tcc_expression, tcc_reference) classes. Why can't we
>use enum tree_code_class for tcc ?

Because there is no .def file for Tcc so we'd have to errors prone duplicate 
the enum.

Richard.

>Thanks and Regards,
>Prathamesh

Re: [GSoC] TYPE stringfied in call to add_operator

[Prathamesh Kulkarni]

On Fri, Apr 25, 2014 at 10:12 PM, Richard Biener
 wrote:
> On April 25, 2014 4:54:28 PM CEST, Prathamesh Kulkarni 
>  wrote:
>>Hi,
>>I have a daft question to ask. I was looking through genmatch, I
>>couldn't figure out why is tree code class (TYPE) stringified in call
>>to add_operator () ?
>>
>>#define DEFTREECODE (SYM, STRING, TYPE, NARGS) \
>>add_operator (SYM, #SYM, #TYPE, NARGS)
>>
>>In add_operator()  tcc (argument corresponding to TYPE) is only used
>>to check if the tree code belongs to one of (tcc_unary, tcc_binary,
>>tcc_comparison, tcc_expression, tcc_reference) classes. Why can't we
>>use enum tree_code_class for tcc ?
>
> Because there is no .def file for Tcc so we'd have to errors prone duplicate 
> the enum.
I was wondering why we couldn't include tree-core.h in genmatch ?
Something similar to the attached patch. Shall that be incorrect ?

Thanks and Regards,
Prathamesh
>
> Richard.
>
>>Thanks and Regards,
>>Prathamesh
>
>
Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revision 209800)
+++ gcc/genmatch.c	(working copy)
@@ -29,7 +29,8 @@ along with GCC; see the file COPYING3.
 #include "hashtab.h"
 #include "hash-table.h"
 #include "vec.h"
-
+#include 
+#include "tree-core.h"
 
 /* Grammar
 
@@ -51,7 +52,7 @@ along with GCC; see the file COPYING3.
(PLUS_EXPR { int_const_binop (PLUS_EXPR, captures[0], captures[2]); } @1))
 */
 
-
+/*
 #define DEFTREECODE(SYM, STRING, TYPE, NARGS)   SYM,
 enum tree_code {
 #include "tree.def"
@@ -65,6 +66,7 @@ enum built_in_function {
 END_BUILTINS
 };
 #undef DEF_BUILTIN
+*/
 
 /* Hashtable of known pattern operators.  This is pre-seeded from
all known tree codes and all known builtin function ids.  */
@@ -126,14 +128,10 @@ struct fn_id : public id_base
 
 static void
 add_operator (enum tree_code code, const char *id,
-	  const char *tcc, unsigned nargs)
+	  enum tree_code_class tcc, unsigned nargs)
 {
-  if (strcmp (tcc, "tcc_unary") != 0
-  && strcmp (tcc, "tcc_binary") != 0
-  && strcmp (tcc, "tcc_comparison") != 0
-  && strcmp (tcc, "tcc_expression") != 0
-  /* For {REAL,IMAG}PART_EXPR and VIEW_CONVERT_EXPR.  */
-  && strcmp (tcc, "tcc_reference") != 0)
+  if (tcc != tcc_unary && tcc != tcc_binary && tcc != tcc_comparison
+  && tcc != tcc_expression && tcc != tcc_reference)
 return;
   operator_id *op = new operator_id (code, id, nargs);
   id_base **slot = operators.find_slot_with_hash (op, op->hashval, INSERT);
@@ -689,15 +687,17 @@ parse_c_expr (cpp_reader *r, cpp_ttype s
   cpp_ttype end;
   unsigned opencnt;
   char *code;
+  std::string cstr;
+
   eat_token (r, start);
   if (start == CPP_OPEN_PAREN)
 {
-  code = xstrdup ("(");
+  cstr += "("; 
   end = CPP_CLOSE_PAREN;
 }
   else if (start == CPP_OPEN_BRACE)
 {
-  code = xstrdup ("({");
+  cstr += "({";
   end = CPP_CLOSE_BRACE;
 }
   else
@@ -714,13 +714,9 @@ parse_c_expr (cpp_reader *r, cpp_ttype s
 	  if (n->type == CPP_NUMBER
 	  && !(n->flags & PREV_WHITE))
 	{
-	  code = (char *)xrealloc (code, strlen (code)
-   + strlen ("captures[") + 4);
 	  if (token->flags & PREV_WHITE)
-		strcat (code, " ");
-	  strcat (code, "captures[");
-	  strcat (code, get_number (r));
-	  strcat (code, "]");
+		cstr += " ";	
+	  cstr.append ("captures[").append (get_number (r)).append ("]");
 	  continue;
 	}
 	}
@@ -734,24 +730,19 @@ parse_c_expr (cpp_reader *r, cpp_ttype s
 
   /* Output the token as string.  */
   char *tk = (char *)cpp_token_as_text (r, token);
-  code = (char *)xrealloc (code, strlen (code) + strlen (tk) + 2);
   if (token->flags & PREV_WHITE)
-	strcat (code, " ");
-  strcat (code, tk);
+	cstr += " ";	
+  cstr += tk;
 }
   while (1);
   if (end == CPP_CLOSE_PAREN)
-{
-  code = (char *)xrealloc (code, strlen (code) + 1 + 1);
-  strcat (code, ")");
-}
+cstr += ")";
   else if (end == CPP_CLOSE_BRACE)
-{
-  code = (char *)xrealloc (code, strlen (code) + 1 + 2);
-  strcat (code, "})");
-}
+cstr += "})"; 
   else
 gcc_unreachable ();
+
+  code = (char *) xstrdup (cstr.c_str ());
   return new c_expr (code);
 }
 
@@ -860,7 +851,7 @@ main(int argc, char **argv)
   /* Pre-seed operators.  */
   operators.create (1024);
 #define DEFTREECODE(SYM, STRING, TYPE, NARGS) \
-  add_operator (SYM, # SYM, # TYPE, NARGS);
+  add_operator (SYM, # SYM, TYPE, NARGS);
 #define END_OF_BASE_TREE_CODES
 #include "tree.def"
 #undef END_OF_BASE_TREE_CODES

Re: How to access points-to information for function pointers

[Richard Biener]

On April 25, 2014 5:54:09 PM CEST, Swati Rathi  
wrote:
>Hello,
>
>I am trying to print points-to information for SSA variables as below.
>
>   for (i = 1; i < num_ssa_names; i++)
> {
>   tree ptr = ssa_name (i);
>   struct ptr_info_def *pi;
>
>   if (ptr == NULL_TREE
>   || SSA_NAME_IN_FREE_LIST (ptr))
> continue;
>
>   pi = SSA_NAME_PTR_INFO (ptr);
>   if (pi)
> dump_points_to_info_for (file, ptr);
> }
>
>-
>My test program is given below :
>
>int main()
>{
>   int *p, i, j;
>   void (*fp1)();
>
>   if (i)
>   {
> p = &i;
> fp1 = fun1;
>   }
>else
>   {
> p = &j;
> fp1 = fun2;
>   }
>
>fp1();
>
>   printf ("\n%d %d\n", *p, i);
>   return 0;
>}
>-
>I get the output as :-
>
>p_1, points-to vars: { i j }
>fp1_2, points-to vars: { }
>-
>
>Why is the pointees for function pointer not getting dumped?

It's just not saved.

>How can I access this information?
>
>
>Regards,
>Swati

Re: [GSoC] TYPE stringfied in call to add_operator

[Richard Biener]

On April 25, 2014 6:56:00 PM CEST, Prathamesh Kulkarni 
 wrote:
>On Fri, Apr 25, 2014 at 10:12 PM, Richard Biener
> wrote:
>> On April 25, 2014 4:54:28 PM CEST, Prathamesh Kulkarni
> wrote:
>>>Hi,
>>>I have a daft question to ask. I was looking through genmatch, I
>>>couldn't figure out why is tree code class (TYPE) stringified in call
>>>to add_operator () ?
>>>
>>>#define DEFTREECODE (SYM, STRING, TYPE, NARGS) \
>>>add_operator (SYM, #SYM, #TYPE, NARGS)
>>>
>>>In add_operator()  tcc (argument corresponding to TYPE) is only used
>>>to check if the tree code belongs to one of (tcc_unary, tcc_binary,
>>>tcc_comparison, tcc_expression, tcc_reference) classes. Why can't we
>>>use enum tree_code_class for tcc ?
>>
>> Because there is no .def file for Tcc so we'd have to errors prone
>duplicate the enum.
>I was wondering why we couldn't include tree-core.h in genmatch ?
>Something similar to the attached patch. Shall that be incorrect ?

Sure, if it doesn't end up including target specifics on the host.

Richard.

>Thanks and Regards,
>Prathamesh
>>
>> Richard.
>>
>>>Thanks and Regards,
>>>Prathamesh
>>
>>

Re: IPA: Devirtualization versus placement new

[Jan Hubicka]

> On 04/25/2014 03:14 PM, Volker Simonis wrote:
> > Could you therefore please re-categorize this as devirt bug.
> 
> It is an IPA bug.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

Now when I have interest from ubsan direction, I wanted to ask. Would it make 
sense to turn
those unreachables into traps with ubsan enabled? (similarly in the loop stuff)

Honza
> 
> Andrew.

Variadic functions arguments passing

[Umesh Kalappa]

Hi All,

In our private port ,we define function_arg hook  to pass the first
three args in the reg and rest will go to stack.

But for variadic  functions the arguments  need  to  pass  through the stack.

How we can achieve this ?? Any inputs will be appreciate.

Thank you
~Umesh

Re: Stack offset computation for incoming arguments.

[Umesh Kalappa]

Thank you Eric for the inputs and will make the required changes.

Thank you Again
~Umesh

On Fri, Apr 25, 2014 at 9:58 PM, Eric Botcazou  wrote:
>> #define FIRST_PARM_OFFSET(FNDECL)  (get_frame_size() +
>> STARTING_FRAME_OFFSET  + RETURN_BYTES )
>
> I don't think that you can define FIRST_PARM_OFFSET like so, you need to have
> a fixed FIRST_PARM_OFFSET (for some definition of fixed) and eliminate the
> argument pointer during reload.
>
> --
> Eric Botcazou

Re: IPA: Devirtualization versus placement new

[Jakub Jelinek]

On Fri, Apr 25, 2014 at 08:23:22PM +0200, Jan Hubicka wrote:
> > On 04/25/2014 03:14 PM, Volker Simonis wrote:
> > > Could you therefore please re-categorize this as devirt bug.
> > 
> > It is an IPA bug.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
> 
> Now when I have interest from ubsan direction, I wanted to ask. Would it make 
> sense to turn
> those unreachables into traps with ubsan enabled? (similarly in the loop 
> stuff)

With -fsanitize=undefined __builtin_unreachable is folded right away into a
library call that will emit a message and then die.

Jakub

Re: IPA: Devirtualization versus placement new

[Jan Hubicka]

> On Fri, Apr 25, 2014 at 08:23:22PM +0200, Jan Hubicka wrote:
> > > On 04/25/2014 03:14 PM, Volker Simonis wrote:
> > > > Could you therefore please re-categorize this as devirt bug.
> > > 
> > > It is an IPA bug.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
> > 
> > Now when I have interest from ubsan direction, I wanted to ask. Would it 
> > make sense to turn
> > those unreachables into traps with ubsan enabled? (similarly in the loop 
> > stuff)
> 
> With -fsanitize=undefined __builtin_unreachable is folded right away into a
> library call that will emit a message and then die.

I see, that sounds good.  Who will ensure that all calls to builtin_unreachable 
we introduce
late will get folded?
The testcase dies with -fsanitize=undefined -fdump-ipa-all, I will look into it.
W/o it I get:
.$ ./a.out
t.C:19:41: runtime error: load of null pointer of type ' *'

I would certainly not really parse this message. It goes away with 
-fno-devirtualize

Honza

Re: Variadic functions arguments passing

[Ian Lance Taylor]

On Fri, Apr 25, 2014 at 11:27 AM, Umesh Kalappa
 wrote:
>
> In our private port ,we define function_arg hook  to pass the first
> three args in the reg and rest will go to stack.
>
> But for variadic  functions the arguments  need  to  pass  through the stack.
>
> How we can achieve this ?? Any inputs will be appreciate.

In INIT_CUMULATIVE_ARGS, which gets the type of the function being
called, set a flag in your CUMULATIVE_ARGS struct, and check it in
FUNCTION_ARG.

Ian