Re: Symbol + Constant output.
Hi, Hongyu Wang via Gcc wrote: I've adjust the testcase and now it only contains constant offset, since with -fPIC the mov target address does not contain any symbol in the assembler. Could you help to check the attached changes on darwin and see if they all get passed? LGTM. OK from a Darwin PoV, thanks Iain make check-gcc-c RUNTESTFLAGS=i386.exp=keylocker* === gcc Summary for unix/-m64 === # of expected passes120 === gcc Summary for unix/-m32 === # of expected passes120 === gcc Summary === # of expected passes240
Re: Dead Field Elimination and Field Reordering
Hi Richard, just some top-level comments before I write about anything specific: * I have removed all non-essential flags I introduced * I have placed the standard headers before config * I have squashed some changes that I sent to the patches mailing list and make sure that the transformation bootstraps on every commit * I will be sending another set of patches to the patch mailing list soon that have the changes mentioned above. Things I will be working on the next couple of days: * Removing std datastructures and using GCC specific ones. * Adding support for ipa-sra. * Flattening the visitors. On 05/11/2020 14:10, Richard Biener wrote: On Tue, Nov 3, 2020 at 5:21 PM Erick Ochoa wrote: Thanks for the review Richard I'll address what I can. I also provide maybe some hindsight into some of the design decisions here. I'm not trying to be defensive just hoping to illuminate why some decisions were made and how some criticisms may fail to really address the reason why these designs were made. On 03/11/2020 15:58, Richard Biener wrote: On Fri, Oct 30, 2020 at 6:44 PM Erick Ochoa wrote: Hello again, I've been working on several implementations of data layout optimizations for GCC, and I am again kindly requesting for a review of the type escape based dead field elimination and field reorg. Thanks to everyone that has helped me. The main differences between the previous commits have been fixing the style, adding comments explaining classes and families of functions, exit gracefully if we handle unknown gimple syntax, and added a heuristic to handle void* casts. This patchset is organized in the following way: * Adds a link-time warning if dead fields are detected * Allows for the dead-field elimination transformation to be applied * Reorganizes fields in structures. * Adds some documentation * Gracefully does not apply transformation if unknown syntax is detected. * Adds a heuristic to handle void* casts I have tested this transformations as extensively as I can. The way to trigger these transformations are: -fipa-field-reorder and -fipa-type-escape-analysis Having said that, I welcome all criticisms and will try to address those criticisms which I can. Please let me know if you have any questions or comments, I will try to answer in a timely manner. The code is in: refs/vendors/ARM/heads/arm-struct-reorg-wip Future work includes extending the current heuristic with ipa-modref extending the analysis to use IPA-PTA as discussed previously. Few notes: * Currently it is not safe to use -fipa-sra. * I added some tests which are now failing by default. This is because there is no way to safely determine within the test case that a layout has been transformed. I used to determine that a field was eliminated doing pointer arithmetic on the fields. And since that is not safe, the analysis decides not to apply the transformation. There is a way to deal with this (add a flag to allow the address of a field to be taken) but I wanted to hear other possibilities to see if there is a better option. * At this point we’d like to thank the again GCC community for their patient help so far on the mailing list and in other channels. And we ask for your support in terms of feedback, comments and testing. I've only had a brief look at the branch - if you want to even have a remote chance of making this stage1 you should break the branch up into a proper patch series and post it with appropriate ChangeLogs and descriptions. First, standard includes may _not_ be included after including system.h, in fact, they _need_ to be included from system.h - that includes things like or . There are "convenient" defines you can use like #define INCLUDE_SET #include "system.h" and system.h will do what you want. Not to say that you should use GCCs containers and not the standard library ones. Thanks I didn't know this! You expose way too many user-visible command-line options. Yes, I can certainly remove some debugging flags. All the stmt / tree walking "meta" code should be avoided - it would need to be touched each time we change GIMPLE or GENERIC. Instead use available walkers if you really need it in such DFS-ish way. There are two points being made here: 1. Use the available walkers 2. Changing gimple would imply changes to your code First: I did tried using the available walkers in the past, and the walk_tree function does not contain a post-order callback. We really need to propagate information from the gimple leaf nodes back to the root, and as a way to achieve this (and probably other things like maintaining a stack of the nodes visited to reach the current node) we really need a post-order callback. We did have a conversation about this where you pointed out this pattern: *walk_subtrees = 0; walk_tree (.. interesting subexpressions ... ); do post-order work In the preorder hook, but this only works with simple expressions and we need more complicated machinery. Furth
Re: gcc/DATESTAMP not updated any longer
On Tue, Nov 03, 2020 at 06:26:58PM +, Joseph Myers wrote:
> On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote:
>
> > It isn't that easy (because update_version_git checks the gcc trunk and
> > so I had to insert a sh invocation in which I've tweaked it), but it worked,
> > thanks. But something is really wrong with the hooks, as the gcc-cvs mail
> > for the trunk daily bump wasn't sent again (r10, r9 and r8 changes did).
>
> I think any issue with an email not sent to gcc-cvs should be raised with
> overseers or postmaster; they'll need to check logs at the exact time to
> see if the email was ever submitted by the hooks to the MTA (and at least
> part of the mail sending from the hooks is I think asynchronous so any
> issues might not be reported back to the git commit command). If it was
> submitted to the MTA, the problem is with the MTA or mailman. If it was
> not submitted to the MTA, Joel might be able to advise on how to
> instrument the process of email sending from the hooks to see where it
> went wrong.
As I didn't hear from overseers yet and we've seen again multiple missing
mails, after discussion with Martin Liska we've applied following hack
to log the mail addresses and mail subjects that are being passed to
sendmail.postfix, and a short while ago we got another case of missing mail.
And it didn't show up in the log file either:
gcc-...@gcc.gnu.org [gcc r11-4793] core: Rename DECL_IS_BUILTIN ->
DECL_IS_UNDECLARED_BUILTIN
gcc-...@gcc.gnu.org [gcc r11-4794] Add PC as control register
gcc-...@gcc.gnu.org [gcc r11-4795] Combine new calculated ranges with existing
range.
gcc-...@gcc.gnu.org [gcc r11-4796] rework PRE PHI translation cache
gcc-...@gcc.gnu.org [gcc r11-4798] c++: Propagate attributes to clones in
duplicate_decls [PR67453]
As you can see, the r11-4797 commit is missing from that list and didn't
make gcc-cvs either.
But git log certainly shows that commit in between:
commit 556ab5125912fa2233986eb19d6cd995cf7de1d2
Author: Iain Sandoe
Date: Fri Jul 31 21:05:28 2020 +0100
Darwin: Darwin 20 is to be macOS 11 (Big Sur).
So, I'm afraid it must fail or bypass this code path somewhere earlier
in the hooks.
diff --git a/hooks/post_receive.py b/hooks/post_receive.py
index 3761c00..f368559 100644
--- a/hooks/post_receive.py
+++ b/hooks/post_receive.py
@@ -16,7 +16,7 @@ from init import init_all_globals
from updates.emails import EmailQueue
from updates.factory import new_update
from utils import debug, warn
-
+import traceback
def post_receive_one(ref_name, old_rev, new_rev, refs, submitter_email):
"""post-receive treatment for one reference.
@@ -44,8 +44,12 @@ def post_receive_one(ref_name, old_rev, new_rev, refs,
submitter_email):
" old_rev = %s" % old_rev,
" new_rev = %s" % new_rev)
return
-update.send_email_notifications()
-
+try:
+update.send_email_notifications()
+except Exception as e:
+with open("/tmp/gcc-git-mail.log", "a") as f:
+f.write(str(e) + '\n')
+f.write(traceback.format_exc() + '\n')
def post_receive(updated_refs, submitter_email):
"""Implement the post-receive hook for all given updated_refs.
diff --git a/hooks/updates/emails.py b/hooks/updates/emails.py
index 706124c..81f4beb 100644
--- a/hooks/updates/emails.py
+++ b/hooks/updates/emails.py
@@ -272,6 +272,9 @@ class Email(object):
else: # pragma: no cover (do not want real emails during testing)
sendmail(self.email_info.email_from, email_recipients,
e_msg.as_string(), 'localhost')
+with open("/tmp/gcc-git-mail.log", "a") as f:
+f.write(e_msg['To'] + ' ' + e_msg['Subject'] + '\n')
+f.close()
if self.filer_cmd is not None:
self.__call_filer_cmd()
Jakub
Re: gcc/DATESTAMP not updated any longer
On November 6, 2020 8:45:55 PM GMT+01:00, Jakub Jelinek via Gcc
wrote:
>On Tue, Nov 03, 2020 at 06:26:58PM +, Joseph Myers wrote:
>> On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote:
>>
>> > It isn't that easy (because update_version_git checks the gcc trunk
>and
>> > so I had to insert a sh invocation in which I've tweaked it), but
>it worked,
>> > thanks. But something is really wrong with the hooks, as the
>gcc-cvs mail
>> > for the trunk daily bump wasn't sent again (r10, r9 and r8 changes
>did).
>>
>> I think any issue with an email not sent to gcc-cvs should be raised
>with
>> overseers or postmaster; they'll need to check logs at the exact time
>to
>> see if the email was ever submitted by the hooks to the MTA (and at
>least
>> part of the mail sending from the hooks is I think asynchronous so
>any
>> issues might not be reported back to the git commit command). If it
>was
>> submitted to the MTA, the problem is with the MTA or mailman. If it
>was
>> not submitted to the MTA, Joel might be able to advise on how to
>> instrument the process of email sending from the hooks to see where
>it
>> went wrong.
>
>As I didn't hear from overseers yet and we've seen again multiple
>missing
>mails, after discussion with Martin Liska we've applied following hack
>to log the mail addresses and mail subjects that are being passed to
>sendmail.postfix, and a short while ago we got another case of missing
>mail.
>And it didn't show up in the log file either:
>gcc-...@gcc.gnu.org [gcc r11-4793] core: Rename DECL_IS_BUILTIN ->
>DECL_IS_UNDECLARED_BUILTIN
>gcc-...@gcc.gnu.org [gcc r11-4794] Add PC as control register
>gcc-...@gcc.gnu.org [gcc r11-4795] Combine new calculated ranges with
>existing range.
>gcc-...@gcc.gnu.org [gcc r11-4796] rework PRE PHI translation cache
>gcc-...@gcc.gnu.org [gcc r11-4798] c++: Propagate attributes to clones
>in duplicate_decls [PR67453]
>As you can see, the r11-4797 commit is missing from that list and
>didn't
>make gcc-cvs either.
>But git log certainly shows that commit in between:
>commit 556ab5125912fa2233986eb19d6cd995cf7de1d2
>Author: Iain Sandoe
>Date: Fri Jul 31 21:05:28 2020 +0100
>
>Darwin: Darwin 20 is to be macOS 11 (Big Sur).
>So, I'm afraid it must fail or bypass this code path somewhere earlier
>in the hooks.
Is that maybe already known to the repo when it is on some rebased user branch?
Richard.
>diff --git a/hooks/post_receive.py b/hooks/post_receive.py
>index 3761c00..f368559 100644
>--- a/hooks/post_receive.py
>+++ b/hooks/post_receive.py
>@@ -16,7 +16,7 @@ from init import init_all_globals
> from updates.emails import EmailQueue
> from updates.factory import new_update
> from utils import debug, warn
>-
>+import traceback
>
>def post_receive_one(ref_name, old_rev, new_rev, refs,
>submitter_email):
> """post-receive treatment for one reference.
>@@ -44,8 +44,12 @@ def post_receive_one(ref_name, old_rev, new_rev,
>refs, submitter_email):
> " old_rev = %s" % old_rev,
> " new_rev = %s" % new_rev)
> return
>-update.send_email_notifications()
>-
>+try:
>+update.send_email_notifications()
>+except Exception as e:
>+with open("/tmp/gcc-git-mail.log", "a") as f:
>+f.write(str(e) + '\n')
>+f.write(traceback.format_exc() + '\n')
>
> def post_receive(updated_refs, submitter_email):
> """Implement the post-receive hook for all given updated_refs.
>diff --git a/hooks/updates/emails.py b/hooks/updates/emails.py
>index 706124c..81f4beb 100644
>--- a/hooks/updates/emails.py
>+++ b/hooks/updates/emails.py
>@@ -272,6 +272,9 @@ class Email(object):
> else: # pragma: no cover (do not want real emails during testing)
> sendmail(self.email_info.email_from, email_recipients,
> e_msg.as_string(), 'localhost')
>+with open("/tmp/gcc-git-mail.log", "a") as f:
>+f.write(e_msg['To'] + ' ' + e_msg['Subject'] + '\n')
>+f.close()
>
> if self.filer_cmd is not None:
> self.__call_filer_cmd()
>
> Jakub
Re: gcc/DATESTAMP not updated any longer
On Fri, Nov 06, 2020 at 08:56:25PM +0100, Richard Biener wrote: > >Darwin: Darwin 20 is to be macOS 11 (Big Sur). > >So, I'm afraid it must fail or bypass this code path somewhere earlier > >in the hooks. > > Is that maybe already known to the repo when it is on some rebased user > branch? I don't think so. I think I'll work with Martin early next week to think about further spots to add logging, so we narrow down where it is still called and where it isn't. But we really don't have a reliable reproducer, commit this and it won't show up. Jakub
Re: gcc/DATESTAMP not updated any longer
Jakub Jelinek via Gcc wrote: On Fri, Nov 06, 2020 at 08:56:25PM +0100, Richard Biener wrote: Darwin: Darwin 20 is to be macOS 11 (Big Sur). So, I'm afraid it must fail or bypass this code path somewhere earlier in the hooks. Is that maybe already known to the repo when it is on some rebased user branch? I don't think so. That commit was only present on a local branch, so not “known” to the repo, for sure. Iain I think I'll work with Martin early next week to think about further spots to add logging, so we narrow down where it is still called and where it isn't. But we really don't have a reliable reproducer, commit this and it won't show up. Jakub
gcc-9-20201106 is now available
Snapshot gcc-9-20201106 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201106/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 542b564343fdb896ede9c9d5e32d45dcd96b2a00 You'll find: gcc-9-20201106.tar.xzComplete GCC SHA256=080d2840c16be0d6ca6a21da9908b7e1840700b9a23d16b9aa491e6b5a85d93d SHA1=4710f613194317f62613ca8fbffc85e855477301 Diffs from 9-20201030 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
