Re: Test GCC conversion with reposurgeon available
22.12.2019 16:56, Joseph Myers wrote: On Thu, 19 Dec 2019, Joseph Myers wrote: And two more. git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4b.git Two more. git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5b.git The main changes are: * The author map used now avoids timezone-only entries also remapping email addresses, so the email addresses from the ChangeLogs are used whenever a commit adds ChangeLog entries from exactly one author. Hello. Sorry if I have missed some part of discussion and now describe known issue about "author map", but in gcc-reposurgeon-5b.git I see this: gcc-reposurgeon-5b.git$ git log --pretty=format:"%h%x09 %ae%x09%ad" --author=zhroma ff96b83 zhr...@ispras.ru Fri Dec 20 15:40:46 2019 + 17a6791 zhr...@ispras.ru Fri Dec 13 17:33:38 2019 + 86f05d3 zhr...@ispras.ru Fri Dec 13 17:17:31 2019 + 7103c52 zhr...@ispras.ru Fri Dec 13 17:02:53 2019 + 1e035ae zhr...@ispras.ru Tue Apr 23 13:14:57 2019 + cea94d2 zhr...@gcc.gnu.org Tue Apr 23 12:53:43 2019 + 28635d5 zhr...@ispras.ru Mon Apr 22 16:05:36 2019 + 2f59c1e zhr...@ispras.ru Fri Mar 29 12:44:01 2019 -0600 1cc4c09 zhr...@ispras.ru Fri Feb 10 16:00:30 2012 +0400 9839b87 zhr...@ispras.ru Mon Jul 25 13:43:01 2011 +0400 gcc-reposurgeon-5b.git$ git log --pretty=format:"%h%x09 %ae%x09%ad" --author=zhroma releases/gcc-8 40cc006 zhr...@ispras.ru Fri Dec 20 15:52:02 2019 + 4cf66d9 zhr...@ispras.ru Fri Dec 20 15:07:58 2019 + 9240950 zhr...@gcc.gnu.org Fri Apr 26 16:04:54 2019 + 1cc4c09 zhr...@ispras.ru Fri Feb 10 16:00:30 2012 +0400 9839b87 zhr...@ispras.ru Mon Jul 25 13:43:01 2011 +0400 I've never used zhr...@gcc.gnu.org email in ChangeLog files. So, it seems odd that it is used in r270511 (my first commit as maintainer), but not in next r270512 or later commits. Moreover, it is also used once in r270609 on 8 branch. I think it's better to use zhr...@ispras.ru everywhere. Another option may be using @gcc.gnu.org everywhere since r270511. I also see this discussion https://gcc.gnu.org/ml/gcc/2019-09/msg00216.html, but it was about wwwdocs repo. Committer field is correct in repo, "Roman Zhuykov " is used everywhere. -- Roman
Question about sizeof after struct change
Hi,
I am working on an LTO pass which drops unused fields on structs. On my
tests, I found that the gimple generated for `sizeof` is a constant. For
example, for the following C code:
```
struct astruct_s { _Bool c; _Bool a; _Bool b; };
struct astruct_s astruct;
int
main()
{
int size = sizeof(astruct);
return 0;
}
```
Produces the following gimple code:
```
size_1 = 3;
_2 = 0;
:
return _2;
```
Is there a way to determine where the value assigned to size_1 is
obtained from? I would like to
1. inspect sizeof statements
2. determine whether the argument of sizeof is struct astruct_s
3. substitute struct astruct_s with a modified version of struct
astruct_s which has field `a` removed.
Therefore, at the end of this transformation we would have size_1 = 2;
Similary, I would like pointer arithmetic to be affected. For example:
```
struct astruct_s { _Bool c; _Bool a; _Bool b; };
struct astruct_s astruct;
int
main()
{
_Bool *c = &astruct.c;
_Bool *b = &astruct.b;
ptrdiff_t d = b - c;
printf("%d\n", d);
}
```
Produces the following gimple code:
```
c_3 = &astruct.c;
b_4 = &astruct.b;
d_5 = b_4 - c_3;
```
Running the code results in the value 2 being printed . After running
the transformation, the result should be 1.
Can anyone point me in the right direction?
So far I have tried changing the TYPE_FIELDS to drop field a, but that
doesn't work and it is not general. I also have some code which
creates a copy of RECORD_TYPE tree and modifies the tree and creates a
new identifier for this modified RECORD_TYPE tree. However, I believe
this may still not produce the intended behaviour.
Any help is appreciated. Thanks!
-Erick
Re: Question about sizeof after struct change
On December 23, 2019 6:30:31 PM GMT+01:00, Erick Ochoa
wrote:
>Hi,
>
>I am working on an LTO pass which drops unused fields on structs. On my
>tests, I found that the gimple generated for `sizeof` is a constant.
>For
>example, for the following C code:
>
>```
>struct astruct_s { _Bool c; _Bool a; _Bool b; };
>struct astruct_s astruct;
>
>int
>main()
>{
> int size = sizeof(astruct);
> return 0;
>}
>```
>
>Produces the following gimple code:
>```
>size_1 = 3;
>_2 = 0;
>:
>return _2;
>```
>
>Is there a way to determine where the value assigned to size_1 is
>obtained from? I would like to
>1. inspect sizeof statements
>2. determine whether the argument of sizeof is struct astruct_s
>3. substitute struct astruct_s with a modified version of struct
>astruct_s which has field `a` removed.
>
>Therefore, at the end of this transformation we would have size_1 = 2;
>Similary, I would like pointer arithmetic to be affected. For example:
>
>```
>struct astruct_s { _Bool c; _Bool a; _Bool b; };
>struct astruct_s astruct;
>
>int
>main()
>{
> _Bool *c = &astruct.c;
> _Bool *b = &astruct.b;
> ptrdiff_t d = b - c;
> printf("%d\n", d);
>}
>```
>
>Produces the following gimple code:
>```
>c_3 = &astruct.c;
>b_4 = &astruct.b;
>d_5 = b_4 - c_3;
>```
>
>Running the code results in the value 2 being printed . After running
>the transformation, the result should be 1.
>
>Can anyone point me in the right direction?
I believe there is no convenient point in the compilation to do all of this in
GCC.
Note that users can very well write a literal 8 (substitute correct value) for a
Sizeof expression. Likewise writing pointer subtraction in terms of integers is
possible.
>So far I have tried changing the TYPE_FIELDS to drop field a, but that
>doesn't work and it is not general. I also have some code which
>creates a copy of RECORD_TYPE tree and modifies the tree and creates a
>new identifier for this modified RECORD_TYPE tree. However, I believe
>this may still not produce the intended behaviour.
>
>Any help is appreciated. Thanks!
You need to analyze and change all actual accesses since not all of them will
necessarily use component refs refering to the FIELD_DECLs you change.
Richard.
>-Erick
