On Mon, Apr 8, 2024 at 10:47 AM Pierrick Philippe
wrote:
>
> On 06/04/2024 14:53, Richard Biener wrote:
>
> On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe
> wrote:
>
> On 05/04/2024 14:46, Richard Biener wrote:
>
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
> wrote:
>
> Hi all,
>
> I do
On 06/04/2024 14:53, Richard Biener wrote:
> On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe
> wrote:
>> On 05/04/2024 14:46, Richard Biener wrote:
>>
>> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
>> wrote:
>>
>> Hi all,
>>
>> I do have a question regarding ssa_name and result_decl.
>>
>>
On Fri, Apr 5, 2024 at 3:44 PM Pierrick Philippe
wrote:
>
> On 05/04/2024 14:46, Richard Biener wrote:
>
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
> wrote:
>
> Hi all,
>
> I do have a question regarding ssa_name and result_decl.
>
> For example on the following gimple function:
>
> int f
On 05/04/2024 14:46, Richard Biener wrote:
> On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
> wrote:
>> Hi all,
>>
>> I do have a question regarding ssa_name and result_decl.
>>
>> For example on the following gimple function:
>>
>> int f ()
>> {
>> int x;
>> int D.2747;
>> int _2;
>>
>>
On Fri, Apr 5, 2024 at 1:59 PM Pierrick Philippe
wrote:
>
> Hi all,
>
> I do have a question regarding ssa_name and result_decl.
>
> For example on the following gimple function:
>
> int f ()
> {
> int x;
> int D.2747;
> int _2;
>
>:
> x_1 = 42;
> _2 = x_1;
>
>:
> :
> return _2
Hello,
On Tue, 27 Jun 2023, Pierrick Philippe wrote:
> My main problem is regarding uninitialized definition, but still not being
> considered undefined behavior.
> For example, the following code:
>
>int x;
>int *y = &x;
>*y = 6;
>
> What I'm doing is basically looking at each gimp
On 27/06/2023 11:42, Richard Biener wrote:
On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe
wrote:
Hi everyone,
I'm trying to get the gimple * associated to the definition of a given
var_decl.
Basically, I am iterating over the locals of a function (through the
local_decls member) and I nee
On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe
wrote:
>
> Hi everyone,
>
> I'm trying to get the gimple * associated to the definition of a given
> var_decl.
> Basically, I am iterating over the locals of a function (through the
> local_decls member) and I need to be able to get the gimple * o
On Fri, Sep 2, 2022 at 2:03 AM Krister Walfridsson
wrote:
>
> On Thu, 1 Sep 2022, Richard Biener wrote:
>
> > It's generally poorly documented what is considered 'undefined behavior'.
> > We desparately need a section in the internals manual for this.
> > For the {L,R}SHIFT_EXPR case we assume the
On Thu, 1 Sep 2022, Richard Biener wrote:
It's generally poorly documented what is considered 'undefined behavior'.
We desparately need a section in the internals manual for this.
For the {L,R}SHIFT_EXPR case we assume the shift operand is
in range of [0, precision - 1], so in theory value-range
On Thu, Sep 1, 2022 at 1:57 AM Krister Walfridsson via Gcc
wrote:
>
> I'm implementing a tool for translation validation (similar to Alive2 for
> LLVM). The tool uses an SMT solver to verify for each GIMPLE pass that the
> output IR is a refinement of the input IR:
> * That each compiled functio
On Wed, Jun 24, 2020 at 9:05 PM Gary Oblock via Gcc wrote:
>
> Richard,
>
> First off I did suspect INDIRECT_REF wasn't supported, thanks for
> confirming that.
>
> I tried what you said in the original code before I posted
> but I suspect how I went at it is the problem. I'm probably
> doing some
Richard,
First off I did suspect INDIRECT_REF wasn't supported, thanks for
confirming that.
I tried what you said in the original code before I posted
but I suspect how I went at it is the problem. I'm probably
doing something(s) in a glaringly stupid way.
Can you spot it, because everything I'm
On Wed, Jun 24, 2020 at 1:36 AM Gary Oblock via Gcc wrote:
>
> I'm somehow misusing GIMPLE (probably in multiple ways) and I need
> some help in straightening out this little mess I've made.
>
> I'm trying to do the following:
>
> In an attempt at structure reorganization (instance interleaving) a
The clobber means that 'a' no longer has a value, presumably because it has
gone out of scope.
On Tue, Jul 16, 2019, 2:07 PM navya deepika Garakapati <
navyadeepika.garakap...@gmail.com> wrote:
> Hi everyone,
>
> We are investigating the optimization issue with GCC trunk code and we have
> the be
On 27 June 2016 at 14:16, Richard Biener wrote:
> On Sun, Jun 26, 2016 at 5:55 PM, Prasad Ghangal
> wrote:
>> Hi Richard,
>>
>> For the first stage of the project, I have completed the following things -
>> parsed -- assign-statement, labeled-statement, if-statement,
>> switch-statement, goto-sta
On Sun, Jun 26, 2016 at 5:55 PM, Prasad Ghangal
wrote:
> Hi Richard,
>
> For the first stage of the project, I have completed the following things -
> parsed -- assign-statement, labeled-statement, if-statement,
> switch-statement, goto-statement, return-statement;
> handled local declarations and
On Tue, Aug 25, 2015 at 11:22 PM, Abe wrote:
> Dear all,
>
> I have redone the SPEC2006 CPU FP tests again after adding "-march=native".
> Unfortunately, the results are not
> very good for the new if-converter. I believe this is the case because the
> CPU in question [details below] "only"
> has
Dear all,
I have redone the SPEC2006 CPU FP tests again after adding "-march=native".
Unfortunately, the results are not
very good for the new if-converter. I believe this is the case because the CPU in
question [details below] "only"
has first-generation AVX, and, from what I`ve been told, a
On August 10, 2015 11:49:15 AM GMT+02:00, Nathan Sidwell wrote:
>Richard,
>I got the min/max VRP optimization I mentioned working, but it
>uncovered a bug
>in phiopts where that pass is constructing MIN and MAX exprs. (Funnily
>enough,
>I only found that failure due to a broken test of decimal
On Tue, Nov 18, 2014 at 10:04 PM, David Malcolm wrote:
> On Tue, 2014-11-18 at 10:53 +0100, Richard Biener wrote:
>> On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
>> > On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
>> >> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm
>> >> wr
On Tue, 2014-11-18 at 10:53 +0100, Richard Biener wrote:
> On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
> > On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
> >> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm
> >> wrote:
> >> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener
On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
> On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
>> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm wrote:
>> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
>> >> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm
>> >> wro
On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm wrote:
> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
> >> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> >> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On 11/17/14 03:06, Richard Biener wrote:
Also, presumably if this were merged, it would require a followup with
the gimple to gimple * fixup you wanted? (which we talked about doing as
an early stage3 thing IIRC [1]).
Yeah, that would be nice (to remind people - this is about getting rid
of
On 11/14/14 08:27, David Malcolm wrote:
I just don't like all the as_a/is_a stuff enforced everywhere,
it means more typing, more temporaries, more indentation.
So, as I view it, instead of the checks being done cheaply (yes, I think
the gimple checking as we have right now is very cheap) under
On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm wrote:
> On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
>> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
>> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
>> >> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
>>
On Fri, Nov 14, 2014 at 4:27 PM, David Malcolm wrote:
> On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
>> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
>> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
>> >> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
>> >
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
> >> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> >> > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm w
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
> >> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> >> > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm w
On 11/13/2014 09:34 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 3:24 PM, Andrew MacLeod wrote:
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm
wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM,
On Thu, Nov 13, 2014 at 3:24 PM, Andrew MacLeod wrote:
> On 11/13/2014 05:45 AM, Richard Biener wrote:
>>
>> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm
>> wrote:
>>>
>>> On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
>
On 11/13/2014 05:45 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
On Sat, 2014-11-0
On 13 November 2014 10:45, Richard Biener wrote:
>
> Hmm.
>
> struct assign;
> struct base {
> operator assign *() const { return (assign *)this; }
> };
> struct assign : base {
> };
>
> void foo (assign *);
> void bar (base *b)
> {
> foo (b);
> }
>
> doesn't work, but
>
> void bar (base &b)
>
On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
>> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
>> > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
>> >> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrot
On Wed, Nov 12, 2014 at 08:41:02PM -0500, David Malcolm wrote:
> On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
> > On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> > > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
> > >> On Sat, 2014-11-08 at 14:56 +0100, Jakub J
On Tue, 2014-11-11 at 08:26 +0100, Jakub Jelinek wrote:
> On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
> > On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
> > > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
> > > > To be constructive here - the above case
On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
> >> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
> >> > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard
On 11/11/2014 09:30 AM, Eric Botcazou wrote:
I just don't like all the as_a/is_a stuff enforced everywhere,
it means more typing, more temporaries, more indentation.
So, as I view it, instead of the checks being done cheaply (yes, I think
the gimple checking as we have right now is very cheap) un
On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
>> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
>> > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
>> > > To be constructive here - the above case is
> I just don't like all the as_a/is_a stuff enforced everywhere,
> it means more typing, more temporaries, more indentation.
> So, as I view it, instead of the checks being done cheaply (yes, I think
> the gimple checking as we have right now is very cheap) under the
> hood by the accessors (gimple
On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote:
> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
> > On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
> > > To be constructive here - the above case is from within a
> > > GIMPLE_ASSIGN case label
> > > and thus
On Mon, Nov 10, 2014 at 2:27 PM, David Malcolm wrote:
> On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
>> On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
>> > To be constructive here - the above case is from within a
>> > GIMPLE_ASSIGN case label
>> > and thus I'd have exp
On Sat, 2014-11-08 at 14:56 +0100, Jakub Jelinek wrote:
> On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
> > To be constructive here - the above case is from within a
> > GIMPLE_ASSIGN case label
> > and thus I'd have expected
> >
> > case GIMPLE_ASSIGN:
> > {
> >
On Sat, 2014-11-08 at 13:07 +0100, Richard Biener wrote:
> On Fri, Nov 7, 2014 at 10:01 PM, Richard Biener
> wrote:
> > On Fri, Nov 7, 2014 at 4:21 PM, David Malcolm wrote:
> >> gcc/ChangeLog.gimple-classes:
> >> * tree-ssa-tail-merge.c (same_succ_hash): Add checked cast.
> >> (gi
On Sat, Nov 08, 2014 at 01:07:28PM +0100, Richard Biener wrote:
> To be constructive here - the above case is from within a
> GIMPLE_ASSIGN case label
> and thus I'd have expected
>
> case GIMPLE_ASSIGN:
> {
> gassign *a1 = as_a (s1);
> gassign *a2 = as_a (s2);
>
On Fri, Nov 7, 2014 at 10:01 PM, Richard Biener
wrote:
> On Fri, Nov 7, 2014 at 4:21 PM, David Malcolm wrote:
>> gcc/ChangeLog.gimple-classes:
>> * tree-ssa-tail-merge.c (same_succ_hash): Add checked cast.
>> (gimple_equal_p): Add checked casts.
>> ---
>> gcc/ChangeLog.gimple-cla
On Fri, Nov 07, 2014 at 10:01:45PM +0100, Richard Biener wrote:
> Just a comment as these patches flow by - I think this is a huge step
> backwards from "enforcing" s1/s2 being a gimple_assign inside
> gimple_assign_rhs1 to this as_a boilerplate at _each_ callsite!
FWIW, I feel the same way. Mor
On Fri, Nov 07, 2014 at 10:01:45PM +0100, Richard Biener wrote:
> > --- a/gcc/tree-ssa-tail-merge.c
> > +++ b/gcc/tree-ssa-tail-merge.c
> > @@ -484,7 +484,7 @@ same_succ_hash (const_same_succ e)
> >
> >hstate.add_int (gimple_code (stmt));
> >if (is_gimple_assign (stmt))
> > -
On Fri, Nov 7, 2014 at 4:21 PM, David Malcolm wrote:
> gcc/ChangeLog.gimple-classes:
> * tree-ssa-tail-merge.c (same_succ_hash): Add checked cast.
> (gimple_equal_p): Add checked casts.
> ---
> gcc/ChangeLog.gimple-classes | 5 +
> gcc/tree-ssa-tail-merge.c| 8 +---
>
On 21/03/14 17:30, Thomas Schwinge wrote:
> Hi!
>
> Certain GIMPLE codes, such as OpenMP ones, have a structured block
> attached to them, for exmaple, gcc/gimple.def:GIMPLE_OMP_PARALLEL:
>
> /* GIMPLE_OMP_PARALLEL represents
>
>#pragma omp parallel [CLAUSES]
>BODY
>
Thank you so much, Prof. Khedkar !
I will go through the slides and other resources that you pointed out.
GRC workshops/tutorials are great. These helped me get started with
GCC when I knew almost nothing about GCC internals.
I will get back with specific queries (if any) after going through thes
You may also want to go through the slides at
http://www.cse.iitb.ac.in/grc/gcc-workshop-13/index.php?page=slides.
In particular,
http://www.cse.iitb.ac.in/grc/gcc-workshop-13/downloads/slides/Day1/gccw13-gimple-manipulation.pdf
and
http://www.cse.iitb.ac.in/grc/gcc-workshop-13/downloads/slid
Thank you so much for the reply, David !
I am not sure where exactly my pass gets invoked. I will try to find it.
But the pass get invoked somewhere in the GIMPLE stage as shown in the
GCC architecture[1].
How is it that one can dictate where the pass can be invoked? Can you
please provide some po
On Mon, 2013-12-16 at 16:10 -0500, Sandeep K Chaudhary wrote:
> Hi Guys,
>
> I am writing a GIMPLE pass in which I need to inspect the assignments.
> For example, for the below statements, I need to find the value of the
> second and third assignments which are '2' and '7'.
>
> VAR1 = 1;
> VAR1++
On Fri, May 11, 2012 at 02:12:32PM +0200, Michael Matz wrote:
> On Fri, 11 May 2012, Basile Starynkevitch wrote:
>
> > However, the type gimple_seq still appears in a lot of source files
> > (mostly gcc/gimple*.c & gcc/tree*.c)
> >
> > Is this intended, or is this a temporary situation, and
>
Hi,
On Fri, 11 May 2012, Basile Starynkevitch wrote:
> However, the type gimple_seq still appears in a lot of source files
> (mostly gcc/gimple*.c & gcc/tree*.c)
>
> Is this intended, or is this a temporary situation, and
> further patches would remove all occurrences of gimple_seq everywhere?
On Fri, 2011-02-25 at 19:57 +, Dave Korn wrote:
> On 25/02/2011 19:21, Kyle Girard wrote:
>
> > I was hoping to see the assignment.
>
> > Looking at the gimple output there is no way to see that 'a' was
> > assigned in bar(). So that it can be used in wik(). Am I
> > misunderstanding someth
On Fri, Feb 25, 2011 at 11:33:58AM -0800, Andrew Pinski wrote:
> On Fri, Feb 25, 2011 at 11:21 AM, Kyle Girard wrote:
> >
> >> That *is* the content of the bar method. What exactly do you expect to
> >> see
> >> happening when you assign a class with no members? There's nothing to do!
> >
> >
On 25/02/2011 19:21, Kyle Girard wrote:
> I was hoping to see the assignment.
> Looking at the gimple output there is no way to see that 'a' was
> assigned in bar(). So that it can be used in wik(). Am I
> misunderstanding something shouldn't there be a way to see the
> assignment in bar? Do I
On Fri, Feb 25, 2011 at 11:21 AM, Kyle Girard wrote:
>
>> That *is* the content of the bar method. What exactly do you expect to see
>> happening when you assign a class with no members? There's nothing to do!
>
>
> I was hoping to see the assignment. My example might have been a little
> too
> That *is* the content of the bar method. What exactly do you expect to see
> happening when you assign a class with no members? There's nothing to do!
I was hoping to see the assignment. My example might have been a little
too simple. Here's a slightly more complex example:
foo.hh
clas
On 25/02/2011 15:20, Kyle Girard wrote:
> foo.hh
> ==
>
> class A
> {
> };
>
> class foo
> {
> A a;
> public:
> void bar(A & aa);
> };
>
>
> foo.cc
> ==
>
> #include "foo.hh"
>
> void foo::bar(A & aa)
> {
> a = aa;
> }
>
>
> However the gimple generated via g++-4.5 -c -fdum
Jérémie Salvucci writes:
> I am trying to get an access to local variables of a function thanks
> to the GIMPLE representation. When I read the dump file after the CFG
> pass, I can see a new temporary variable added. For example with the
> identity function I would like to get an access to the u
On 06/22/2010 11:39 AM, Jakub Jelinek wrote:
> On Tue, Jun 22, 2010 at 11:34:30AM +0200, Richard Guenther wrote:
>> We should add support for a GIMPLE_TERNARY_RHS class.
>
> It hasn't been added before because ternary ops were considered rare
> (primarily just COND_EXPR). If they are no longer s
On Tue, Jun 22, 2010 at 11:34:30AM +0200, Richard Guenther wrote:
> On Mon, Jun 21, 2010 at 5:25 PM, Bernd Schmidt
> wrote:
> > In PR43902, Jim has posted a patch to add support for widening
> > multiply-accumulate to tree-ssa-math-opts. They are represented as a
> > GIMPLE_SINGLE_RHS with a WID
On Mon, Jun 21, 2010 at 5:25 PM, Bernd Schmidt wrote:
> In PR43902, Jim has posted a patch to add support for widening
> multiply-accumulate to tree-ssa-math-opts. They are represented as a
> GIMPLE_SINGLE_RHS with a WIDEN_MULT_PLUS_EXPR tree which holds the
> actual operands of the multiply-accu
> On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou wrote:
> >> Ugh. This presents a chicken-and-egg problem to symbol resolution
> >> and type-merging.
> >>
> >> To be clear, the issue is sth like
> >>
> >> unit1
> >> -
> >> int size;
> >> int a[size];
> >>
> >> unit2
> >> --
> >> extern in
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou wrote:
>> Ugh. This presents a chicken-and-egg problem to symbol resolution
>> and type-merging.
>>
>> To be clear, the issue is sth like
>>
>> unit1
>> -
>> int size;
>> int a[size];
>>
>> unit2
>> --
>> extern int size;
>> extern a[size];
>
> Ugh. This presents a chicken-and-egg problem to symbol resolution
> and type-merging.
>
> To be clear, the issue is sth like
>
> unit1
> -
> int size;
> int a[size];
>
> unit2
> --
> extern int size;
> extern a[size];
>
> ? And you get the a's merged but a diagnostic about mismatched ty
On Fri, May 14, 2010 at 1:24 PM, Eric Botcazou wrote:
> Hi,
>
> most of the remaining warnings issued by the LTO compiler on object files
> compiled from Ada are caused by a small flaw in the GIMPLE types merging
> process: it is done before symbols are merged so compatible types (typically
> doma
On Thu, Apr 29, 2010 at 11:01 PM, Manuel López-Ibáñez
wrote:
> On 29 April 2010 19:25, Sandeep Soni wrote:
>> I added the following page to the wiki.
>>
>> http://gcc.gnu.org/wiki/GimpleFrontEnd
>>
>> Any comments/suggestions or ideas related to the project are welcome.
>
> Hi Sandy,
>
> It may b
On 29 April 2010 19:25, Sandeep Soni wrote:
> I added the following page to the wiki.
>
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> Any comments/suggestions or ideas related to the project are welcome.
Hi Sandy,
It may be helpful to take a look to wiki pages of previous SoC
projects, such as
ht
You are right. In rev.150316 there are no ICE.
Thanks,
Dmitry
2009/7/31 Richard Guenther :
> On Fri, Jul 31, 2009 at 9:53 AM, Дмитрий Дьяченко wrote:
>> Hello,
>> current (gcc version 4.5.0 20090727 (experimental) [trunk revision
>> 150136] (GCC))
>>
>> for code
>>
>> #include
>>
>> class
On Fri, Jul 31, 2009 at 9:53 AM, Дмитрий Дьяченко wrote:
> Hello,
> current (gcc version 4.5.0 20090727 (experimental) [trunk revision
> 150136] (GCC))
>
> for code
>
> #include
>
> class a;
> class b;
>
> class c {
> public:
> b *p;
> bool isNull() const { return p == 0; }
> };
>
> cla
On Sat, Jul 25, 2009 at 1:28 PM, pms wrote:
>
> Hi Nathan
> I looked into tree.def, I added a case in the new gimple pass to count
> the number of integer variables in the c code. the following is the piece of
> code.
> Here, the first case is working, but I'm not getting the second one. can u
>
Hi Nathan
I looked into tree.def, I added a case in the new gimple pass to count
the number of integer variables in the c code. the following is the piece of
code.
Here, the first case is working, but I'm not getting the second one. can u
pls help in this regard.
How to trace thru the other cod
On Fri, Jul 24, 2009 at 05:20:16AM -0700, pms wrote:
> But I want to know what are the TREE_CODEs for other remaing constructs
> viz declration stmt, conditions, count for constants and how to use them in
> the gimple pass. Can anybody help in this regard
The names are defined in tree.def.
-Na
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> >> Anyway, there must be other uses of types in either the existing middle end
> >> or that people have dreams of adding to the middle end in the future. Now
> >> is the time to raise your hand before the design has been started.
Hi,
for me its grea
On Sat, Jul 19, 2008 at 12:45 AM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>>
>> On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Diego has asked me to look into what would be needed in a gimple type
>>> system. This is an issue
Richard Guenther wrote:
On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
Diego has asked me to look into what would be needed in a gimple type
system. This is an issue that has been brought to a head because now it is
time to merge types for lto.
There are a lot
On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Diego has asked me to look into what would be needed in a gimple type
> system. This is an issue that has been brought to a head because now it is
> time to merge types for lto.
>
> There are a lot of questions that nee
On Thu, Mar 27, 2008 at 19:55, Dasarath Weeratunge <[EMAIL PROTECTED]> wrote:
> Is it possible to map simplified source statements back to the
> original source code in GCC?
Yes, using the debugging information associated with every statement.
Every statement has the file and line number of the o
On Thu, Feb 14, 2008 at 9:39 AM, Andrea Callia D'Iddio
<[EMAIL PROTECTED]> wrote:
> But how can I obtain the list of variables used by a function? (global
> variables and also function local variables)
Once you are in SSA form, the table REFERENCED_VARS contains all the
symbols that are referen
"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:
> When you mean scheduling of the instruction, does it mean that the
> register allocation for ASM is not that advanced than it is for a
> builtin ? For instance the use of register classes, for the
> instruction.
Register allocation for an asm us
When you mean scheduling of the instruction, does it mean that the
register allocation for ASM is not that advanced than it is for a
builtin ? For instance the use of register classes, for the instruction.
I basically would like to translate a gimple node which holds
information about a featur
"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:
> I generate a GIMPLE form extended with new nodes coming from language
> extensions. I would like to generate assembly code directly from those
> nodes. I was thinking of using the GCC builtins system. But I cannot
> find the entry point (hook and
On Tue, May 08, 2007 at 09:43:58PM +0200, J.C. Pizarro wrote:
> Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote:
> >Hi all,
> >
> >I'm writing a new compilation pass in gcc, and I'm working on GIMPLE
> >code. When gcc produce GIMPLE code, it creates new temporary
> >variables, in order to simplify
Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote:
Hi all,
I'm writing a new compilation pass in gcc, and I'm working on GIMPLE
code. When gcc produce GIMPLE code, it creates new temporary
variables, in order to simplify expressions and statements. For
example, if source C file contains
a=a+b+19;
On 5/8/07, Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote:
how can I recognize temporary variables, such as D.1295?
DECL_ARTIFICIAL is set on all compiler-generated symbols and labels.
Daniel Berlin wrote on 04/25/07 14:40:
> It still has the addresses_taken bitmap, remove it :)
Oh, right. Is it gone already?
> Also, I assume for a call with no return, it will be a GS_CALL with lhs ==
> NULL?
Yes. I clarified it. Thanks.
It still has the addresses_taken bitmap, remove it :)
Also, I assume for a call with no return, it will be a GS_CALL with lhs == NULL?
On 4/25/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wi
Geert Bosch wrote on 04/25/07 11:49:
> I'd assume 100% contain 0 or more register operands.
> Did you mean 43% contain 1 or more?
Well, no. I meant 0 or more, but it's badly worded. It means that 43%
of the statements either have no operands or they contain only register
operands. I'll rephras
In 3.1, you write:
The statistics gathered over the programs mentioned in the
previous section show that about 43% of all statements contain 0 or
more
register operands
I'd assume 100% contain 0 or more register operands.
Did you mean 43% contain 1 or more?
-Geert
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wiki/tuples
Aldy
On 4/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There c
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There currently is *no* "aux" field to do this. We
may be for
> PRE is only using stmt_ann->uid as a convenient place to store the uid
> for local dominance for purposes of Load PRE.
> It's making up the UID on it's own :).
>
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's f
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues i
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easi
1 - 100 of 117 matches
Mail list logo
