Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

[Vladislav Ivanishin]

Jonathan Wakely  writes:

> On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge  wrote:
>>
>> Hi!
>>
>> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely  
>> wrote:
>> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely  
>> > wrote:
>> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge  
>> > > wrote:
>> > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely 
>> > > >  wrote:
>> > > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge 
>> > > > >  wrote:
>> > > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't 
>> > > > > > correspond to
>> > > > > > the actual GCC 9.1 release.  The GCC 9.1 release (as per 
>> > > > > > 'gcc-9.1.0.tar'
>> > > > > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release',
>> > > > > > r272156)
>> > > >
>> > > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked out
>> > > > revision 272156", but the GCC 9.1 release actually is r270840, and
>> > > > r272156 is GCC trunk from a moment ago.)
>> > > >
>> > > > > > would correspond to Git commit
>> > > > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and 
>> > > > > > version
>> > > > > > files for release", but the Git 'gcc-9_1_0-release' tag points one 
>> > > > > > commit
>> > > > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a 
>> > > > > > "BASE-VER:
>> > > > > > Set to 9.1.1".  (That's not a big problem; the 'BASE-VER' update is
>> > > > > > indeed the only difference.)
>> > > > >
>> > > > > That's probably my fault, I think I created the tag.
>> > > > >
>> > > > > > The Git tag can't be corrected now (would it make sense to push a 
>> > > > > > Git
>> > > > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to 
>> > > > > > get it
>> > > > > > into the mighty Internet archives; may this note help others who 
>> > > > > > stumble
>> > > > > > over the same thing.
>> > > > >
>> > > > > Can't we just delete the tag and add it at the right commit?
>> > > >
>> > > > I don't think that'll be useful: as far as I remember (but please 
>> > > > correct
>> > > > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so
>>
>> Right, see the "DISCUSSION" "On Re-tagging" in 'git tag --help'.
>>
>> > > I think that's right, but 'git fetch --tags' would update it.
>>
>> Sure, but who's running that?  ;-)
>>
>> (We shall see if the GitHub etc. mirrors will pick up the updated tag
>> automatically.)
>>
>> > > > different clones might then have different 'gcc-9_1_0-release' tags.
>> > >
>> > > Which doesn't seem like a problem to me.
>> > >
>> > > I could create a local tag with that name for any arbitrary revision.
>> > > It wouldn't match what's in everybody else's clone, but that's fine.
>> >
>> > It seems to me that having the master repo have the correct tag is
>> > more valuable than everybody having the same tag.
>> >
>> > And because, as you say, the difference is just one commit, it's not
>> > like doing diffs or other commands using the old value of the tag
>> > would look at a completely wrong branch or completely different
>> > histories.
>>
>> Note that I'm not objecting to re-tagging.  (I had just proposed
>> 'gcc-9_1_0-release-corrected' to make obvious what's going on.)
>>
>> Is there sufficient consensus, or who's going to make a decision?
>
> After some more discussion on IRC, and with Jakub's approval, I fixed
> the tag by running this on the server:
>
> git update-ref refs/tags/gcc-9_1_0-release
> 3defceaa1a2987fa90296abfbcc85d7e9ad59684
> 1f54d412a517f3a4b82f3dd77517842fb4de099a
>
> The same command can be run in a clone to update local tags.

Or `git fetch --tags -f` (not particularly well documented in the git
manual, but intuitive; worked for me).

-- 
Vlad

>
> Running 'git fetch --tags' will give an error if you already have that tag:
>
>  ! [rejected]gcc-9_1_0-release -> gcc-9_1_0-release
> (would clobber existing tag)

Re: LTO remapping/deduction of machine modes of types/decls

[Vladislav Ivanishin]

Hi


In general I think they should match.  But without seeing concrete
examples of where they do not I can't comment on whether such 
exceptions

make sense.  For example if you adjust a DECLs alignment and then
re-layout it I'd expect you might get a non-BLKmode mode for an
aggregate in some circumstances -- but then decl and type are not 1:1
compatible (due to different alignment), but this case is clearly 
desired

as requiring type copies for the sake of alignment would be wasteful.


The C++ FE lays out base classes as FIELD_DECLs. In build_base_field_1 
the

mode for such decls is set:

gcc/cp/class.c
4528  SET_DECL_MODE (decl, TYPE_MODE (basetype));

Before this the type of this decl is set to CLASSTYPE_AS_BASE (basetype) 
via a
call to build_decl. Thus in general DECL_MODE (decl) != TYPE_MODE (its 
type)

(and it does happen e.g. TYPE_MODE (basetype) == BLKmode and
TYPE_MODE (CLASSTYPE_AS_BASE (basetype)) == DImode in the example 
below).


Moreover, the types of such fields are later re-set in layout_class_type 
to

values unrelated to both basetype and CLASSTYPE_AS_BASE (basetype):

gcc/cp/class.c
6692 /* Now that we're done with layout, give the base fields the real 
types.

6693 for (field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
6694   if (DECL_ARTIFICIAL (field) && IS_FAKE_BASE_TYPE (TREE_TYPE 
(field)))

6695 TREE_TYPE (field) = TYPE_CONTEXT (TREE_TYPE (field));

So the modes of the decl and its type don't match and we've lost the
information needed to deduce the mode of the decl.

Here is the aforementioned example:

  struct operand
  {
  virtual void gen_transform () {}
  };

  struct c_expr : public operand {};

Here is another one (demonstrates a different kind of mismatch):

  class hsa_op_base
  {
public:
  hsa_op_base *m_next;
  unsigned m_brig_op_offset;
protected:
  hsa_op_base (int k);
  };

  class hsa_op_reg: public hsa_op_base {};

In the latter example TYPE_MODE (CLASSTYPE_AS_BASE (basetype)) == 
BLKmode and

TYPE_MODE (basetype) == TImode.

To be clear: in the examples above the problem (mismatch between 
streamed
type's mode and decl's mode if we are doing LTO) is with the implicit 
field in

the derived class corresponding to an instance of the base class.
--
Vlad