Re: Automatically generated ChangeLog files - script
On 7/7/20 4:14 AM, Alexandre Oliva wrote:
Sorry it took me so long to get back to this.
Don't worry!
On Jun 24, 2020, Martin Liška wrote:
Please escape the '[':
+end_of_location_regex = re.compile(r'[\[<(:]')
check
and please a test-case for it.
check
Thanks, I've made the changes; sorry it took me so long.
I couldn't figure out how to run the internal gcc-changelog test.
I've just installed your patch and added the test, please see the change
in test_email.py in:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a759bfc7cf238b9fc5bf97884297fc69d8cdf2b5
Thank you for the patch,
Martin
accept and [cond] in ChangeLog
From: Alexandre Oliva
Only '(' and ':' currently terminate file lists in ChangeLog entries
in the ChangeLog parser. This rules out such legitimate entries as:
* filename :
* filename [COND]:
This patch extends the ChangeLog parser to recognize these forms.
for contrib/ChangeLog
* gcc-changelog/git_commit.py: Support CASE and COND.
* gcc-changelog/test_patches.txt: Add test.
---
contrib/gcc-changelog/git_commit.py| 16 +++
contrib/gcc-changelog/test_patches.txt | 35
2 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 4a78793..900a294 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -154,6 +154,7 @@ changelog_regex = re.compile(r'^(?:[fF]or
+)?([a-z0-9+-/]*)ChangeLog:?')
pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
dr_regex = re.compile(r'\tDR ([0-9]+)$')
star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
+end_of_location_regex = re.compile(r'[\[<(:]')
LINE_LIMIT = 100
TAB_WIDTH = 8
@@ -203,14 +204,13 @@ class ChangeLogEntry:
line = m.group('content')
if in_location:
-# Strip everything that is not a filename in "line": entities
-# "(NAME)", entry text (the colon, if present, and anything
-# that follows it).
-if '(' in line:
-line = line[:line.index('(')]
-in_location = False
-if ':' in line:
-line = line[:line.index(':')]
+# Strip everything that is not a filename in "line":
+# entities "(NAME)", cases "", conditions
+# "[COND]", entry text (the colon, if present, and
+# anything that follows it).
+m = end_of_location_regex.search(line)
+if m:
+line = line[:m.start()]
in_location = False
# At this point, all that's left is a list of filenames
diff --git a/contrib/gcc-changelog/test_patches.txt
b/contrib/gcc-changelog/test_patches.txt
index 1463fb9..2bf5d1a 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -3160,3 +3160,38 @@ index 823eb539993..4ec22162c12 100644
--
2.27.0
+=== 0001-Check-for-more-missing-math-decls-on-vxworks.patch ===
+From 0edfc1fd22405ee8e946101e44cd8edc0ee12047 Mon Sep 17 00:00:00 2001
+From: Douglas B Rupp
+Date: Sun, 31 May 2020 13:25:28 -0700
+Subject: [PATCH] Check for more missing math decls on vxworks.
+
+Use the GLIBCXX_CHECK_MATH_DECL macro to check for the full list of
+vxworks math decls.
+
+for libstdc++-v3/ChangeLog:
+
+ * crossconfig.m4 <*-vxworks>: Check for more math decls.
+ * configure [FAKEPATCH]: Rebuild.
+---
+ libstdc++-v3/configure | 255
+ libstdc++-v3/crossconfig.m4 | 3 +-
+ 2 files changed, 257 insertions(+), 1 deletion(-)
+
+diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
+index b5beb45..4ef678e 100755
+--- a/libstdc++-v3/configure
b/libstdc++-v3/configure
+@@ -1 +1,2 @@
+
++
+diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
+index fe18288..313f84d 100644
+--- a/libstdc++-v3/crossconfig.m4
b/libstdc++-v3/crossconfig.m4
+@@ -1 +1,2 @@
+
++
+--
+2.7.4
+
RE: DW_OP_implict_value usage and motivation
Hi Jakub,
Thanks for clarifying this. I went through literature and other stuff
available, it describes operation and semantics. Unfortunately I wasn't able to
get to the actual DWARF Issue/proposal when it was proposed.
One small doubt still remains. It seems(to me) that DW_OP_stack_value and
DW_OP_implicit_value both can be used to describe most optimized location/value
of a variable. Then representing/choosing appropriate operation involves matter
like space/compactness(just like GCC does) or maybe other factors too ?
I'm unable to come-up with an motivating example where DW_OP_implicit_value is
indispensable. Would you please, if possible, share an example(test case or
any specific situation) covering this.
Thanks a lot again!
Sourabh.
-Original Message-
From: Jakub Jelinek
Sent: Saturday, July 4, 2020 10:33 PM
To: Tomar, Sourabh Singh
Cc: gcc@gcc.gnu.org
Subject: Re: DW_OP_implict_value usage and motivation
[CAUTION: External Email]
On Sat, Jul 04, 2020 at 04:23:58PM +, Tomar, Sourabh Singh wrote:
> Consider the following test case:
> [..]
> int main () {
> __int128 newVar = 8;
> newVar = ~newVar;
> return 0;
> }
DW_OP_implicit_value as well as DW_OP_stack_value is described in DWARF4/5,
just read the description in there.
And as you found, in some cases it is possible to represent the value by either
of those, in which case GCC tries to use the shorter one.
For __int128, to use DW_OP_stack_value one would need to use the typed DWARF
stack DWARF5 features (so e.g. inappropriate in DWARF4 mode when it can be
represented by DWARF4 features already).
Jakub
Re: DW_OP_implict_value usage and motivation
On Tue, Jul 07, 2020 at 09:26:58AM +, Tomar, Sourabh Singh wrote: > Thanks for clarifying this. I went through literature and other stuff > available, it describes operation and semantics. Unfortunately I wasn't > able to get to the actual DWARF Issue/proposal when it was proposed. > > One small doubt still remains. It seems(to me) that DW_OP_stack_value and > DW_OP_implicit_value both can be used to describe most optimized > location/value of a variable. Then representing/choosing appropriate > operation involves matter like space/compactness(just like GCC does) or > maybe other factors too ? > > I'm unable to come-up with an motivating example where > DW_OP_implicit_value is indispensable. Would you please, if possible, > share an example(test case or any specific situation) covering this. I wasn't involved in DWARF standard when DW_OP_implicit_value has been added, but it was added in DWARF4, where the DWARF stack could only hold integers (and only up to the size of address). So, DW_OP_implicit_value was the only way to hold floating point constants, or integers larger than address, or other non-integral values. It is like using DW_AT_const_value, except DW_AT_const_value, except that DW_AT_const_value is for the case when a variable etc. has the same value at all spots, while DW_OP_implicit_value can be used in .debug_loc, you can say the object has this constant value at certain locations, and another one at others. DW_OP_stack_value is for the cases where the value is computable using the DWARF stack operations. Jakub
GCC usage script
Hey. Some of you may know Honza's images about CPU utilization and memory usage when using LTO [1]. Last week I played with Chromium and Firefox and I wanted to visualize their utilization. That's why I came up with a new script [2]. You can easily wrap a command and the script generates graphs for you:. The script uses modern psutil library and plots through a great matplotlib: $ usage-wrapper.py -v -t postgresql 'make -j16' ... $ eog usage.svg There's a gallery of the collected reports for Firefox and Chromium: https://gist.github.com/marxin/223890df4d8d8e490b6b2918b77dacad and yes, we have a LTO regression since GCC 9 that I'm going to take closer to. Martin [1] https://4.bp.blogspot.com/-fvrkYSMBqug/XMsTqg4HEkI/Gl8/8sp1GWv6Oe8tfBfL6aO8Nbq5j3hExurpwCEwYBhgL/s1600/llvm.png [2] https://github.com/marxin/script-misc/blob/master/usage-wrapper.py
Re: GCC usage script
> Hey. > > Some of you may know Honza's images about CPU utilization and memory usage > when using LTO [1]. Last week I played with Chromium and Firefox and I wanted > to visualize their utilization. That's why I came up with a new script [2]. > > You can easily wrap a command and the script generates graphs for you:. > The script uses modern psutil library and plots through a great matplotlib: > $ usage-wrapper.py -v -t postgresql 'make -j16' > ... > $ eog usage.svg > > There's a gallery of the collected reports for Firefox and Chromium: > https://gist.github.com/marxin/223890df4d8d8e490b6b2918b77dacad Thanks, it looks nice. I am not sure what the blue line means - if it is overall usage of vmstat then I guess you do not calculate COW of the stream out processes correctly and that is why you get so high peak on them. > > and yes, we have a LTO regression since GCC 9 that I'm going to take closer > to. Where do you see the regression? (just trying to make sense of the numbers). For Firefox I see you get around 16GB streaming memory peak and 32GB for ltranses which seems kind of acceptable for such a large parallelism. Do you have time report for Cromium WPA? It seems to be stuck on something for quite a while. I would say that simple time report + ideally perf profile should make it possible to track this down. Honza > > Martin > > [1] > https://4.bp.blogspot.com/-fvrkYSMBqug/XMsTqg4HEkI/Gl8/8sp1GWv6Oe8tfBfL6aO8Nbq5j3hExurpwCEwYBhgL/s1600/llvm.png > [2] https://github.com/marxin/script-misc/blob/master/usage-wrapper.py
Re: GCC usage script
On 7/7/20 12:27 PM, Jan Hubicka wrote: Hey. Some of you may know Honza's images about CPU utilization and memory usage when using LTO [1]. Last week I played with Chromium and Firefox and I wanted to visualize their utilization. That's why I came up with a new script [2]. You can easily wrap a command and the script generates graphs for you:. The script uses modern psutil library and plots through a great matplotlib: $ usage-wrapper.py -v -t postgresql 'make -j16' ... $ eog usage.svg There's a gallery of the collected reports for Firefox and Chromium: https://gist.github.com/marxin/223890df4d8d8e490b6b2918b77dacad Thanks, it looks nice. Thanks. I am not sure what the blue line means - if it is overall usage of vmstat then I guess you do not calculate COW of the stream out processes correctly and that is why you get so high peak on them. I use: rss: aka “Resident Set Size”, this is the non-swapped physical memory a process has used. On UNIX it matches “top“‘s RES column). So I guess it's not computed correctly, but it's likely hard to identify memory that is actually shared in between processes (and doesn't need copying). and yes, we have a LTO regression since GCC 9 that I'm going to take closer to. I basically speak about Firefox WPA (which is about 2-3x slower with GCC 9). For chromium, the situation is even worse (WPA is 7x slower). Where do you see the regression? (just trying to make sense of the numbers). For Firefox I see you get around 16GB streaming memory peak and 32GB for ltranses which seems kind of acceptable for such a large parallelism. Do you have time report for Cromium WPA? No. It seems to be stuck on something for quite a while. Yep. Martin I would say that simple time report + ideally perf profile should make it possible to track this down. Honza Martin [1] https://4.bp.blogspot.com/-fvrkYSMBqug/XMsTqg4HEkI/Gl8/8sp1GWv6Oe8tfBfL6aO8Nbq5j3hExurpwCEwYBhgL/s1600/llvm.png [2] https://github.com/marxin/script-misc/blob/master/usage-wrapper.py
a small typo in the documentation, FYI
The top line in https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html says " The syntax is: `prefix quote digits quote', were the prefix is either b, o or z," Here, 'were' must be 'where' HTH, Nino
Re: a small typo in the documentation, FYI
On Tue, 7 Jul 2020 at 15:41, Nino Pereira via Gcc wrote: > > The top line in > https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html > > says " The syntax is: `prefix quote digits quote', were the prefix is > either b, o or z," > > Here, 'were' must be 'where' Thanks. That page is the documentation from the GCC 4.6.3 release, which is old, and has already been released, so its documentation can't be changed now. But the typo is still present in the currently supported branches. I've CC'd the fortran mailing list, so our Fortran devs can fix it.
