public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* (no subject)
@ 2024-03-21 15:12 Centurion
  2024-03-21 15:26 ` your mail Segher Boessenkool
  0 siblings, 1 reply; 4+ messages in thread
From: Centurion @ 2024-03-21 15:12 UTC (permalink / raw)
  To: gcc-help

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

HI, I am new in gcc codebase. Can you explain please why we can't just use
TREE_TYPE(parm) for TEMLATE_TEMPLATE_PARM and why DECL_INITIAL is needed
for it? I tried to debug Bug 114377 and it seems to work fine. Thanks

--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -11032,10 +11032,7 @@ find_template_parameter_info::found (tree parm)
 {
   if (TREE_CODE (parm) == TREE_LIST)
     parm = TREE_VALUE (parm);
-  if (TREE_CODE (parm) == TYPE_DECL)
-    parm = TREE_TYPE (parm);
-  else
-    parm = DECL_INITIAL (parm);
+  parm = TREE_TYPE(parm);
   gcc_checking_assert (TEMPLATE_PARM_P (parm));
   return parms.contains (parm);
 }

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: your mail
  2024-03-21 15:12 Centurion
@ 2024-03-21 15:26 ` Segher Boessenkool
  2024-03-24  9:30   ` Centurion
  0 siblings, 1 reply; 4+ messages in thread
From: Segher Boessenkool @ 2024-03-21 15:26 UTC (permalink / raw)
  To: Centurion; +Cc: gcc-help

On Thu, Mar 21, 2024 at 07:12:23PM +0400, Centurion via Gcc-help wrote:
> HI, I am new in gcc codebase. Can you explain please why we can't just use
> TREE_TYPE(parm) for TEMLATE_TEMPLATE_PARM and why DECL_INITIAL is needed
> for it? I tried to debug Bug 114377 and it seems to work fine. Thanks

You cannot use TREE_TYPE if that would just access nonsense data.

The wrong thing might still work, in many cases.  If you have no
substantiation why your proposed change would work fine, chances are it
does not.  Sorry.


Segher


> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -11032,10 +11032,7 @@ find_template_parameter_info::found (tree parm)
>  {
>    if (TREE_CODE (parm) == TREE_LIST)
>      parm = TREE_VALUE (parm);
> -  if (TREE_CODE (parm) == TYPE_DECL)
> -    parm = TREE_TYPE (parm);
> -  else
> -    parm = DECL_INITIAL (parm);
> +  parm = TREE_TYPE(parm);
>    gcc_checking_assert (TEMPLATE_PARM_P (parm));
>    return parms.contains (parm);
>  }

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: your mail
  2024-03-21 15:26 ` your mail Segher Boessenkool
@ 2024-03-24  9:30   ` Centurion
  0 siblings, 0 replies; 4+ messages in thread
From: Centurion @ 2024-03-24  9:30 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: gcc-help

[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]

```
bool
find_template_parameter_info::found (tree parm)
{
  if (TREE_CODE (parm) == TREE_LIST)
    parm = TREE_VALUE (parm);
  if (TREE_CODE (parm) == TYPE_DECL)
    parm = TREE_TYPE (parm);
  else
    parm = DECL_INITIAL (parm);
  gcc_checking_assert (TEMPLATE_PARM_P (parm));
  return parms.contains (parm);
}
```

Is there a reason why TREE_TYPE used only for TYPE_DECL, but not for
TEMPLATE_DECL ? process_template_parm initializes DECL_INITIAL for non type
template parameters, but  TYPE_DECL and TEMPLATE_DECL, stayed with nullptr,
on the other hand as I understood it always initializes TREE_TYPE.

cp/pt.cc::tree process_template_parm:
```
 if (parm && TREE_CODE (parm) == TEMPLATE_DECL)
{
 t = cxx_make_type (TEMPLATE_TEMPLATE_PARM);
...
 TREE_TYPE (result) = t;
...
}
      else
{
 t = cxx_make_type (TEMPLATE_TYPE_PARM);
 /* parm is either IDENTIFIER_NODE or NULL_TREE.  */
 decl = build_decl (parm_loc,
    TYPE_DECL, parm, t);
}
```
In other similar pieces of code the condition is for both for TYPE_DECL and
TEMLATE_DECL:

cp/pt.cc::tree template_parm_to_arg:
```
 if (DECL_P (t) && DECL_TEMPLATE_PARM_P (t))
    {
      if (TREE_CODE (t) == TYPE_DECL
 || TREE_CODE (t) == TEMPLATE_DECL)
t = TREE_TYPE (t);
      else
t = DECL_INITIAL (t);
    }
```
cp/pt.cc::tree get_template_parm_index:
```
if (TREE_CODE (parm) == PARM_DECL
      || TREE_CODE (parm) == CONST_DECL)
    parm = DECL_INITIAL (parm);
  else if (TREE_CODE (parm) == TYPE_DECL
  || TREE_CODE (parm) == TEMPLATE_DECL)
    parm = TREE_TYPE (parm);
```

Sorry if I ask stupid question.

On Thu, Mar 21, 2024 at 7:28 PM Segher Boessenkool <
segher@kernel.crashing.org> wrote:

> On Thu, Mar 21, 2024 at 07:12:23PM +0400, Centurion via Gcc-help wrote:
> > HI, I am new in gcc codebase. Can you explain please why we can't just
> use
> > TREE_TYPE(parm) for TEMLATE_TEMPLATE_PARM and why DECL_INITIAL is needed
> > for it? I tried to debug Bug 114377 and it seems to work fine. Thanks
>
> You cannot use TREE_TYPE if that would just access nonsense data.
>
> The wrong thing might still work, in many cases.  If you have no
> substantiation why your proposed change would work fine, chances are it
> does not.  Sorry.
>
>
> Segher
>
>
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -11032,10 +11032,7 @@ find_template_parameter_info::found (tree parm)
> >  {
> >    if (TREE_CODE (parm) == TREE_LIST)
> >      parm = TREE_VALUE (parm);
> > -  if (TREE_CODE (parm) == TYPE_DECL)
> > -    parm = TREE_TYPE (parm);
> > -  else
> > -    parm = DECL_INITIAL (parm);
> > +  parm = TREE_TYPE(parm);
> >    gcc_checking_assert (TEMPLATE_PARM_P (parm));
> >    return parms.contains (parm);
> >  }
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: your mail
       [not found] <20040223154755.23916.qmail@web41606.mail.yahoo.com>
@ 2004-02-23 16:42 ` Michael Matz
  0 siblings, 0 replies; 4+ messages in thread
From: Michael Matz @ 2004-02-23 16:42 UTC (permalink / raw)
  To: kripa shankar; +Cc: gcc, gcc-help, crossgcc

Hi,

On Mon, 23 Feb 2004, kripa shankar wrote:

> ;; Start of basic block 2, registers live: 11 [fp] 13 [sp]
> (note 62 41 45 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 45 62 46 (set (reg/i:SI 0 r0)        (const_int 0 [0x0])) 176 {*movsi_insn} (nil)    (expr_list:REG_EQUAL (const_int 0 [0x0])        (nil)))
> (insn 46 45 76 (use (reg/i:SI 0 r0)) -1 (insn_list 45 (nil))    (nil))
> (insn 76 46 77 (set (reg:SI 7 r7)        (plus:SI (reg:SI 5 r5)            (const_int 2 [0x2]))) -1 (nil)    (nil))
> (insn 77 76 50 (set (reg:SI 6 r6)        (plus:SI (reg:SI 4 r4)            (const_int 2 [0x2]))) -1 (nil)    (nil))
> ;; End of basic block 2
> (note 50 77 63 0 NOTE_INSN_BLOCK_END)
> (note 63 50 0 "" NOTE_INSN_DELETED)
> 
> The instructions inserted are r7 = r5 + 2;r6 = r4 + 2; But the problem
> is that the inserted instructions are not present in both asm file
> (fourth.s) and the output binary file (fourth.o).. I have inserted these
> instructions right after all the optimization passess and before the
> final pass (final.c) where RTL gets converted into Assembly. Kindly help
> me.

There is not enough information.  Where exactly have you added the code to
add those insns?  About which compiler version do you speak?  Produce all 
dump files (-da) and look which dump misses them first.  The problem is, 
that you include those instructions without updating lifeness (i.e. the 
compiler doesn't see, that r6 and r7 really are required after you've set 
them.  So, if there is any pass deleting useless insns after you inserted 
them, they will get deleted.


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-03-24  9:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-21 15:12 Centurion
2024-03-21 15:26 ` your mail Segher Boessenkool
2024-03-24  9:30   ` Centurion
     [not found] <20040223154755.23916.qmail@web41606.mail.yahoo.com>
2004-02-23 16:42 ` Michael Matz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).