[wwwdocs] Push DOCTYPEs into individual pages and switch to HTML 5
This simplifies our web infrastructure by pushing DOCTYPEs into the individual pages, thus (a) reducing the preprocessing of our pages on the server end, (b) hence reducing the dependency on MetaHTML which makes that tool it easier to replace, and last but not least (c) makes it easier to edit pages locally now that they carry both CSS and DOCTYPE information. In the course of this I went ahead and, after all the preliminary changes in that direction that I made in the past weeks, flagged all pages except for our main page as HTML 5 and removed XML markers. Some of the pages still are not fully HTML 5, and I am going to address that in the coming days and weeks, though this should not cause any practical issues for browsers or users. Fully converting our main page and those others may take a little, but I figured progressing faster for the majority of pages and then taking it from there was the better approach. Progress trumps perfection. I already adjusted my validator that provides feedback to the committer of any web page change, and am running a full validation of our site to flag and address any outstanding issues. David, let's give this a few days to settle; it should then allow simplifying your nice script to replace MetaHTML altogether a little (and there is room for a bit more). Gerald Push DOCTYPEs into the individual web pages, reducing the preprocessing of our pages on the server end and simplifying our MetaHTML style sheet accordingly. In the course of that flag all pages as HTML 5, except for the main page which remains XHTML for the time being. Index: style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.147 diff -u -r1.147 style.mhtml --- style.mhtml 26 Aug 2018 18:54:40 - 1.147 +++ style.mhtml 1 Sep 2018 23:11:48 - @@ -10,17 +10,10 @@ > -;;; Note that the line really needs to start in the first column. - - http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > > > Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1095 diff -u -r1.1095 index.html --- index.html 26 Aug 2018 18:40:30 - 1.1095 +++ index.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,8 @@ + +http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> + Index: about.html === RCS file: /cvs/gcc/wwwdocs/htdocs/about.html,v retrieving revision 1.30 diff -u -r1.30 about.html --- about.html 2 Jun 2018 21:16:09 - 1.30 +++ about.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: backends.html === RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.79 diff -u -r1.79 backends.html --- backends.html 17 Aug 2018 19:22:22 - 1.79 +++ backends.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: badspammer.html === RCS file: /cvs/gcc/wwwdocs/htdocs/badspammer.html,v retrieving revision 1.8 diff -u -r1.8 badspammer.html --- badspammer.html 2 Jun 2018 21:16:09 - 1.8 +++ badspammer.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: branch-closing.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branch-closing.html,v retrieving revision 1.2 diff -u -r1.2 branch-closing.html --- branch-closing.html 2 Jun 2018 21:16:09 - 1.2 +++ branch-closing.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: branching.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v retrieving revision 1.35 diff -u -r1.35 branching.html --- branching.html 2 Jun 2018 21:16:09 - 1.35 +++ branching.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/buildstat.html,v retrieving revision 1.28 diff -u -r1.28 buildstat.html --- buildstat.html 2 Jun 2018 21:16:09 - 1.28 +++ buildstat.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v retrieving revision 1.65 diff -u -r1.65 c99status.html --- c99status.html 2 Jun 2018 21:16:09 - 1.65 +++ c99status.html 1 Sep 2018 23:11:49 - @@ -1,3 +1,4 @@ + Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.82 diff -u -r1.82 codingconventions.html --- codingconventions.html
[wwwdocs] Fix up gcc-6/changes.html wrt. HTML 5
As simple as using instead of in one place. Committed. Gerald Index: gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.106 diff -u -r1.106 changes.html --- gcc-6/changes.html 1 Sep 2018 23:42:06 - 1.106 +++ gcc-6/changes.html 2 Sep 2018 08:12:47 - @@ -314,7 +314,7 @@ new features: std::uncaught_exceptions function (this is also -available for -std=gnu++NN modes); +available for -std=gnu++NN modes); new member functions try_emplace and insert_or_assign for unique_key maps; non-member functions std::size,
[wwwdocs] news/gcse.html goes HTML 5
Only a little change, simply omitting align="middle" which did not actually make a practical difference, since "middle" was about vertical alignment. On the way strip a little disclaimer above (since, really, the graphics isn't bad ;-). Committed. Gerald Index: news/gcse.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news/gcse.html,v retrieving revision 1.6 diff -u -r1.6 gcse.html --- news/gcse.html 1 Sep 2018 23:42:07 - 1.6 +++ news/gcse.html 2 Sep 2018 08:19:09 - @@ -48,10 +48,10 @@ Fred Chow's thesis. The difference between GCSE and PRE is best illustrated with an example -flow graph (please forgive the poor graphics, I'm no HTML or graphics guru). +flow graph: - +
[wwwdocs] releases.html -- use CSS
Due to security settings on gcc.gnu.org and the switch to HTML 5 we
need to define a style in our global CSS file instead of hardcoding
things or keeping it local to that file.
Committed.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.54
diff -u -r1.54 gcc.css
--- gcc.css 26 Aug 2018 18:54:40 - 1.54
+++ gcc.css 2 Sep 2018 08:38:32 -
@@ -91,6 +91,9 @@
table.cxxstatus td:nth-child(3) { text-align:center; }
table.cxxstatus tr.separator { background: #f2f2f9; }
+/* Padded tables. */
+table.padding5 th, td { border: 1px solid gray; padding:5px; }
+
.supported { background-color: lightgreen; }
.unsupported { background-color: lightsalmon; }
Index: releases.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/releases.html,v
retrieving revision 1.136
diff -u -r1.136 releases.html
--- releases.html 1 Sep 2018 23:42:00 - 1.136
+++ releases.html 2 Sep 2018 08:38:32 -
@@ -35,7 +35,7 @@
Please refer to our development plan
for future releases, and an alternative view of the release history.
-
+
ReleaseRelease date
GCC 8.2 July 26, 2018
GCC 8.1 May 2, 2018
[wwwdocs] news/egcs-vcg.html goes HTML 5 (and looks better)
Use CSS (aligned with our regular documentation) to highlight code
snippets as opposed to direct encoding; don't some blocks.
This makes this page HTML 5 and actually also looks better.
(We probably could simply remove those tables; not sure why Jeff
added them back then, probably for the sake of coloring?)
Committed.
Gerald
Index: news/egcs-vcg.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news/egcs-vcg.html,v
retrieving revision 1.14
diff -u -r1.14 egcs-vcg.html
--- news/egcs-vcg.html 1 Sep 2018 23:42:07 - 1.14
+++ news/egcs-vcg.html 2 Sep 2018 09:03:35 -
@@ -35,10 +35,10 @@
First you should get an impression on what the program and the
gcc changes do. Take the following small program.
-
+
- int
+ int
gcd (int v1, int v2)
{
int l = v1 < v2 ? v1 : v2;
@@ -74,10 +74,10 @@
should dump. E.g., giving GCC the option -da dumps
the files:
-
+
- # ../cc1 -O2 -o test.o test.c -da
+ # ../cc1 -O2 -o test.o test.c -da
gcd main
time in parse: 0.01
[... some lines removed ...]
@@ -93,10 +93,10 @@
These files are kind of hard to read if you are not used to
RTL. Example? This is a part of test.c.lreg:
-
+
- [... some lines removed ...]
+ [... some lines removed ...]
Basic block 5: first insn 25, last 27.
Registers live at start: 6 7 24 25
@@ -133,7 +133,6 @@
-
All the information about the basic blocks and the instructions
and so on is available but not the the most human friendly
@@ -143,10 +142,10 @@
If you add the option -dv to your
commandline you get a handful of extra files:
-
+
- # ../cc1 -O2 -o test.o test.c -da -dv
+ # ../cc1 -O2 -o test.o test.c -da -dv
gcd main
time in parse: 0.01
[... some lines removed ...]
@@ -162,7 +161,7 @@
If you view these files using a suitable program, you'll get output
similar to the following:
-
+
These are nodes representing all the functions in the file. If
you expand the nodes you can get a picture like
[wwwdocs] Improve formatting for blocks
is used by our online documentation, and with a change I just applied also by news/egcs-vcg.html and later possibly further pages. This change limits coloring of the background of those pre blocks to the actual width, not the entire page width. Validated by reviewing some pages under /onlinedocs and news/egcs-vcg.html. Committed. Gerald Index: gcc.css === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v retrieving revision 1.55 diff -u -r1.55 gcc.css --- gcc.css 2 Sep 2018 09:02:29 - 1.55 +++ gcc.css 2 Sep 2018 09:46:01 - @@ -103,6 +103,7 @@ font-size: medium; background: #f2f2f9; padding: 4px; + display: inline-block; } /* Classpath versus libgcj merge status page. */
Re: [wwwdocs] news/egcs-vcg.html goes HTML 5 (and looks better)
On Sun, 2 Sep 2018, Gerald Pfeifer wrote:
> (We probably could simply remove those tables; not sure why Jeff
> added them back then, probably for the sake of coloring?)
Done thusly.
And, yes, without the tables or the patch I just committed to our CSS
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00031.html
(a concept which did not exist back then, but really helps with such
matters), the background of the examples would go across the while
width, which doesn't look that great.
Gerald
Index: news/egcs-vcg.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news/egcs-vcg.html,v
retrieving revision 1.15
diff -u -r1.15 egcs-vcg.html
--- news/egcs-vcg.html 2 Sep 2018 09:05:50 - 1.15
+++ news/egcs-vcg.html 2 Sep 2018 09:09:45 -
@@ -35,10 +35,7 @@
First you should get an impression on what the program and the
gcc changes do. Take the following small program.
-
-
-
- int
+int
gcd (int v1, int v2)
{
int l = v1 < v2 ? v1 : v2;
@@ -64,20 +61,14 @@
printf ("gcd(%d, %d) = %d\n", v1, v2, gcd (v1, v2));
return 0;
}
-
-
-
-
+
If you want to understand how GCC translates this
programs you use the -d option to select what GCC
should dump. E.g., giving GCC the option -da dumps
the files:
-
-
-
- # ../cc1 -O2 -o test.o test.c -da
+# ../cc1 -O2 -o test.o test.c -da
gcd main
time in parse: 0.01
[... some lines removed ...]
@@ -85,18 +76,13 @@
test.c.addressof test.c.cse2 test.c.jump test.c.regmove test.c.stack
test.c.bp test.c.flow test.c.jump2 test.c.rtl
test.c.combinetest.c.gcse test.c.loop test.c.sched
-test.c.csetest.c.greg test.c.lreg test.c.sched2
-
-
-
+test.c.csetest.c.greg test.c.lreg test.c.sched2
+
These files are kind of hard to read if you are not used to
RTL. Example? This is a part of test.c.lreg:
-
-
-
- [... some lines removed ...]
+[... some lines removed ...]
Basic block 5: first insn 25, last 27.
Registers live at start: 6 7 24 25
@@ -129,10 +115,8 @@
(insn 12 10 13 (set (reg/v:SI 23)
(reg/v:SI 24)) 54 {movsi+2} (insn_list 6 (nil))
(nil))
-[... more lines removed ...]
-
-
-
+[... more lines removed ...]
+
All the information about the basic blocks and the instructions
and so on is available but not the the most human friendly
@@ -142,10 +126,7 @@
If you add the option -dv to your
commandline you get a handful of extra files:
-
-
-
- # ../cc1 -O2 -o test.o test.c -da -dv
+# ../cc1 -O2 -o test.o test.c -da -dv
gcd main
time in parse: 0.01
[... some lines removed ...]
@@ -153,10 +134,8 @@
test.c.addressof.vcg test.c.cse2.vcg test.c.jump.vcg test.c.regmove.vcg
test.c.bp.vcg test.c.flow.vcg test.c.jump2.vcg test.c.sched.vcg
test.c.combine.vcgtest.c.gcse.vcg test.c.loop.vcg test.c.sched2.vcg
-test.c.cse.vcgtest.c.greg.vcg test.c.lreg.vcg test.c.stack.vcg
-
-
-
+test.c.cse.vcgtest.c.greg.vcg test.c.lreg.vcg test.c.stack.vcg
+
If you view these files using a suitable program, you'll get output
similar to the following:
Re: [patch] [match.pd]: missing optimization on comparison
On 30 August 2018 22:20:06 CEST, Marc Glisse wrote: >Hello, > >INTEGRALS_SIGN_PREC_MATCH: the name doesn't really match the semantics. +#define INTEGRALS_SIGN_PREC_MATCH(A, B) \ + TYPE_PRECISION (TREE_TYPE (A)) == TYPE_PRECISION (TREE_TYPE (B)) \ + (TYPE_PRECISION (TREE_TYPE (A)) > TYPE_PRECISION (TREE_TYPE (B)) \ + && !TYPE_UNSIGNED (TREE_TYPE (B))) + Unless my mailer somehow mangled it, isn't there some operator ( maybe || ?) missing between the eq clause and the second one? How comes that it even compiles, presumably without a warning? thanks,
[wwwdocs] testing/index.html - simplification, HTML 5
Left-align table with tests, removing align="center". Committed. Gerald Index: testing/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/testing/index.html,v retrieving revision 1.40 diff -u -r1.40 index.html --- testing/index.html 1 Sep 2018 23:42:10 - 1.40 +++ testing/index.html 2 Sep 2018 11:16:45 - @@ -73,7 +73,7 @@ list (accompanied with build and test guides) are welcome. - + Name Language Build and test guide
[wwwdocs] about.html - transform into a "real" page
While having just a line with a tag that redirects works in practice, that doesn't make a valid HTML document, so let's fix this by building out an HTML structure skeleton (incl. DOCTYPE). Committed. Gerald Index: gcc.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.html,v retrieving revision 1.1 retrieving revision 1.3 diff -u -r1.1 -r1.3 --- gcc.html7 Jan 2013 22:43:06 - 1.1 +++ gcc.html2 Sep 2018 11:25:31 - 1.3 @@ -1 +1,7 @@ + + + +GCC, the GNU Compiler Collection + +
[wwwdocs] simtest-howto.html - convert to HTML 5, using CSS
The new CSS class should prove useful also in other cases.
Committed.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.56
diff -u -r1.56 gcc.css
--- gcc.css 2 Sep 2018 09:47:10 - 1.56
+++ gcc.css 2 Sep 2018 11:39:01 -
@@ -15,6 +15,8 @@
.highlight{ color: darkslategray; font-weight:bold; }
.smaller { font-size: 80%; }
+.left { text-align:left; }
+
.no-margin-top { margin-top:0; }
.twocolumns { column-counts:2; -moz-column-count:2; }
.imgleft { margin: 5px 20px; float: left; }
Index: simtest-howto.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/simtest-howto.html,v
retrieving revision 1.34
diff -u -r1.34 simtest-howto.html
--- simtest-howto.html 1 Sep 2018 23:42:01 - 1.34
+++ simtest-howto.html 2 Sep 2018 11:39:40 -
@@ -172,8 +172,8 @@
significantly different code to be generated and can matter more
than word size and endianness in terms of detecting new breakage.
-
-
+
+
TargetSimulatorCommentsTest Results
[wwwdocs] Use standard DOCTYPE and header for projects/tree-ssa/vectorization.html
I'm not sure why this page did not fall in line with our standard headers, but since it did not, it at first escape the conversions I conducted the last while. Fixed thusly. Gerald Index: projects/tree-ssa/vectorization.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v retrieving revision 1.38 diff -u -r1.38 vectorization.html --- projects/tree-ssa/vectorization.html26 Aug 2018 11:13:56 - 1.38 +++ projects/tree-ssa/vectorization.html2 Sep 2018 11:41:19 - @@ -1,4 +1,6 @@ -http://www.w3.org/1999/xhtml";> + + + Auto-vectorization in GCC https://gcc.gnu.org/gcc.css"; />
Re: [patch, libgfortran] Fix warning about mismatched type declarations.
Hi Jerry, The subject patch fixes the declaration for the vlist argument of the formatted_dtio function pointer definition which currently gives a warnings during compilation for mismatched types. Regression tested on x86_64-pc-linux. OK for trunk? OK. Thanks! Regards Thomas
[wwwdocs] projects/tree-ssa/tree-browser.html - use more regular markup, existing CSS, move to HTML 5
This page did a lot of manual formatting (via tables) which was not
consistent with other spots on our site. This address that by using
CSS instead of manually constructing tables, and adds environments
where suitable, overall making this simpler/shorter, more consistent,
and HTML 5 in the end.
Committed.
Gerald
Index: projects/tree-ssa/tree-browser.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/tree-browser.html,v
retrieving revision 1.5
diff -u -r1.5 tree-browser.html
--- projects/tree-ssa/tree-browser.html 1 Sep 2018 23:42:10 - 1.5
+++ projects/tree-ssa/tree-browser.html 2 Sep 2018 11:57:14 -
@@ -8,41 +8,29 @@
Tree Browser
-Until recently the only way to debug trees from gdb was to call debug_tree
as follows:
+Until recently the only way to debug trees from gdb was to call
+debug_tree as follows:
-
-
-
-
+
(gdb) p debug_tree (current_function_decl)
-
-
-
-
-
-An alternative for interactively scan tree structures is to use the Tree
Browser.
-You can access Tree Browser from anywhere during a debugging session as
follows:
-
-
-
-
-
+
+
+An alternative for interactively scan tree structures is to use the
+Tree Browser. You can access Tree Browser from anywhere during a debugging
+session as follows:
+
+
(gdb) p browse_tree (current_function_decl)
Tree Browser
foo
Up/prev expressions updated.
TB>
-
-
-
-
-
-For listing available commands, you could try:
-
-
-
-
+
+
+For listing available commands, you could try:
+
+
TB> h
Possible commands are:
@@ -102,19 +90,15 @@
pp - Pretty print current node.
p - Prints the current node.
TB>
-
-
-
-
-Note that this list of commands is susceptible to change, since this is a
pretty new tool
-and is still in development.
+
+
+Note that this list of commands is susceptible to change, since this
+is a pretty new tool and is still in development.
-Now let's try some of these commands: we're on the declaration of the
current function,
-we can have a look at its body.
-
-
-
-
+Now let's try some of these commands: we're on the declaration of the
+current function, we can have a look at its body.
+
+
TB> decl_saved_tree
{
int T.1;
@@ -134,18 +118,13 @@
}, return i;
}
TB>
-
-
-
-
-
-The above output is a pretty-print of the body of the current function.
-A call to debug_tree would have printed more things about the structure of
-the Abstract Syntax Trees (AST), as follows:
-
-
-
-
+
+
+The above output is a pretty-print of the body of the current function.
+A call to debug_tree would have printed more things about the structure of
+the Abstract Syntax Trees (AST), as follows:
+
+
TB> p
one.c:3:0>
TB>
-
-
-
-
-
-An interesting thing to remark in this dumping is that a node is
represented as
-a well parenthesized expression. Each tree node contains several fields
that are in
-general aligned at the same indentation level.
-For example BIND_EXPR has a child called vars (a set of variable
definitions), a body,
-and a block. All these fields are accessible from Tree Browser.
-
-Thus if we continue our exploration of the current tree structure,
-
-
-
-
+
+
+An interesting thing to remark in this dumping is that a node is
+represented as a well parenthesized expression. Each tree node contains
+several fields that are in general aligned at the same indentation level.
+For example BIND_EXPR has a child called vars (a set of variabl
+definitions), a body, and a block. All these fields are accessible from
+Tree Browser.
+
+Thus if we continue our exploration of the current tree structure,
+
+
TB> arg0
{
int T.1;
@@ -241,21 +216,18 @@
T.1 = i * 3, T.2 = i + T.1, toons (T.2)
}, return i;
TB>
-
-
-
-
-Here I have to write some notes on the current chaining of expressions
procedure.
-A compound_expr contains two operands: arg0 the child that contains the
expression
-and arg1 the child that contains the rest of the list of expressions. In
arg0
-GCC stores an expr_with_file_location node that contains the expression
and an
-information about the position of this expression in the original source
code.
-
-For accessing the next expression you can use the next command:
-
-
-
-
+
+
+Here I have to write some notes on the current chaining of
Re: [patch] [match.pd]: missing optimization on comparison
On Sun, 2 Sep 2018, Bernhard Reutner-Fischer wrote: On 30 August 2018 22:20:06 CEST, Marc Glisse wrote: Hello, INTEGRALS_SIGN_PREC_MATCH: the name doesn't really match the semantics. +#define INTEGRALS_SIGN_PREC_MATCH(A, B) \ + TYPE_PRECISION (TREE_TYPE (A)) == TYPE_PRECISION (TREE_TYPE (B)) \ + (TYPE_PRECISION (TREE_TYPE (A)) > TYPE_PRECISION (TREE_TYPE (B)) \ + && !TYPE_UNSIGNED (TREE_TYPE (B))) + Unless my mailer somehow mangled it, isn't there some operator ( maybe || ?) missing between the eq clause and the second one? Kai sent a second email immediately afterwards that fixes this. -- Marc Glisse
[wwwdocs] Add missing (empty) table cells to gcc-2.95/regress.html
Committed. Gerald Index: gcc-2.95/regress.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/regress.html,v retrieving revision 1.111 retrieving revision 1.113 diff -u -r1.111 -r1.113 --- gcc-2.95/regress.html 1 Sep 2018 23:42:02 - 1.111 +++ gcc-2.95/regress.html 2 Sep 2018 12:13:26 - 1.113 @@ -398,6 +398,8 @@ + + @@ -465,6 +467,8 @@ + +
[wwwdocs] gcc-2.95/branch.html -- use instead of
...making this page HTML 5. Committed. Gerald Index: gcc-2.95/branch.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/branch.html,v retrieving revision 1.11 diff -u -r1.11 branch.html --- gcc-2.95/branch.html1 Sep 2018 23:42:02 - 1.11 +++ gcc-2.95/branch.html2 Sep 2018 12:15:51 - @@ -17,12 +17,12 @@ Track just the GCC 2.95 release. You can convert your existing CVS tree to track the GCC 2.95 release with the command: - cvs update -rgcc-2_95-branch + cvs update -rgcc-2_95-branch Track both the GCC 2.95 release and the development sources. You will need to check out the GCC 2.95 release in a separate directory using the command: - cvs co -rgcc-2_95-branch egcs + cvs co -rgcc-2_95-branch egcs Considering that the primary focus of the developers is on the GCC 2.95
[wwwdocs] gcc-7/changes.html -- use instead of
Surprising to see such a new page use old markup. I recall having fixed this back then, reviewing the change, but probably missed that one instance? Anyway, fixed thusly. Gerald Index: gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.109 diff -u -r1.109 changes.html --- gcc-7/changes.html 1 Sep 2018 23:42:06 - 1.109 +++ gcc-7/changes.html 2 Sep 2018 12:46:21 - @@ -604,7 +604,7 @@ The C++ front end has experimental support for all of the current C++17 draft with the -std=c++1z or -std=gnu++1z flags, -including if constexpr, class template argument +including if constexpr, class template argument deduction, auto template parameters, and structured bindings. For a full list of new features, see https://gcc.gnu.org/projects/cxx-status.html#cxx1z";>the C++
[wwwdocs] projects/strees/index.html -- convert to HTML 5
Committed. Gerald Convert to HTML 5: Use instead of , omit align="center", use CSS. Index: projects/strees/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/strees/index.html,v retrieving revision 1.4 diff -u -r1.4 index.html --- projects/strees/index.html 1 Sep 2018 23:42:10 - 1.4 +++ projects/strees/index.html 2 Sep 2018 13:01:25 - @@ -4,23 +4,23 @@ https://gcc.gnu.org/gcc.css"; /> -Stree design notes - +Stree design notes + Matt Austern, Robert Bowdidge, Geoff Keating - + The stree project is based on three fundamental premises. First: for an important class of development tasks (roughly: GUI programs -written in a relatively simple subset of C++, compiled at -O0 --g), compilation time is dominated by the C++ front end. Second: +written in a relatively simple subset of C++, compiled at -O0 +-g), compilation time is dominated by the C++ front end. Second: the performance of the C++ front end is dominated by memory allocation and management. This includes memory allocation, initializing newly allocated objects, and bookkeeping for garbage collection. Reducing front end memory usage should thus improve front end performance. Third: many programs consist of small source files that include truly enormous header files. Such header files -include(25,000 lines), -Apple's (91,000 lines), and the X11 +include (25,000 lines), +Apple's (91,000 lines), and the X11 headers. Any given translation unit only uses a tiny fraction of the declarations in one of these headers. @@ -47,23 +47,23 @@ generate strees. Usually we generate strees only for declarations that are not also definitions. So, for example, we would generate an stree - for void do_nothing(); (which the middle end and back + for void do_nothing(); (which the middle end and back end don't necessarily have to know about), but we would generate - a full tree for void >do_nothing() { } (which the + a full tree for void >do_nothing() { } (which the middle end has to expand to RTL). For a declaration that is not a definition, there is a simple way to characterize whether or not the definition is "needed": some other declaration refers to it by name. For example: if a - function xyzzy is declared but nobody ever defines it, + function xyzzy is declared but nobody ever defines it, takes its address, or calls a function with that name, then that declaration isn't needed, and generating a decl tree for it is wasted time and space. This definition of "needed" immediately leads to an implementation technique. References to a decl by name always - go through a cxx_binding - object. (See name_lookup.h). So we just need to - make cxx_binding a little bit more complicated: when - we ask a cxx_binding for the value of the binding, we + go through a cxx_binding + object. (See name_lookup.h). So we just need to + make cxx_binding a little bit more complicated: when + we ask a cxx_binding for the value of the binding, we check to see whether we have a tree or an stree. If the latter, we expand it into a tree and cache the expanded version. @@ -78,7 +78,8 @@ implementation reason why we don't want to defer emission of diagnostics. Early diagnostics reduce the need for global state to be remembered for each stree: source code - position, current_binding_level, current_class_ptr, + position, current_binding_level, + current_class_ptr, etc.) @@ -86,41 +87,42 @@ An example: enumerators Consider the front end data structure for a simple enumeration -declaration, enum foo { a, b };. We have two enumerators. For -each one we need to know its name, its type, the underlying integer +declaration, enum foo { a, b };. We have two enumerators. +For each one we need to know its name, its type, the underlying integer type used to represent it, and its value. At present we represent -enumerators with CONST_DECL nodes, so each enumerator takes -128 bytes for the tree_decl node, plus additional memory -for cp-tree.h's version of lang_decl. +enumerators with CONST_DECL nodes, so each enumerator takes +128 bytes for the tree_decl node, plus additional memory +for cp-tree.h's version of lang_decl. Each enumerator has an entry in the hash table, an identifier. Each -identifier has a pointer to a binding of type cxx_binding -(this is the bindings field in lang_identifier, defined in -name_lookup.h). The binding for foo itself points to -a tree_type, and the bindings for a and b -point to CONST_DECL nodes. Each CONST_DECL node has -pointers to the name and to the ENUMERAL_TYPE node, and +identifier has a pointer to a binding of type cxx_binding +(this is the bindings field in lang_identifier, defined in +name_lookup.h). The binding for foo itself
[wwwdocs] egcs-1.1/egcs-1.1-branch.html -- use instead of
It appears we copied from ourselves, so what I fixed for GCC 2.95 already was, pretty much identically, there for egcs 1.1. Fixued thusly, making also this page HTML 5. Gerald Index: egcs-1.1/egcs-1.1-branch.html === RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/egcs-1.1-branch.html,v retrieving revision 1.9 diff -u -r1.9 egcs-1.1-branch.html --- egcs-1.1/egcs-1.1-branch.html 1 Sep 2018 23:42:02 - 1.9 +++ egcs-1.1/egcs-1.1-branch.html 2 Sep 2018 12:27:45 - @@ -15,11 +15,11 @@ EGCS sources. Track just the EGCS 1.1 release. You can convert your existing CVS tree to track the EGCS 1.1 release with the command: - cvs update -regcs_1_1_branch + cvs update -regcs_1_1_branch Track both the EGCS 1.1 release and the development sources. You will need to check out the EGCS 1.1 release in a separate directory using the command: - cvs co -regcs_1_1_branch egcs + cvs co -regcs_1_1_branch egcs Considering that the primary focus of the project is on the egc-1.1 release,
[wwwdocs] projects/x86.html -- convert to HTML 5
This was an easy one, we just have to remove align=right from one of the table headers, and one where it did not make a difference actually. Committed. Gerald Index: projects/x86.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/x86.html,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- projects/x86.html 1 Sep 2018 23:42:10 - 1.5 +++ projects/x86.html 2 Sep 2018 13:20:18 - 1.6 @@ -465,7 +465,7 @@ Routine Compiler -fomit-fp? Cycles -(× 107) % of slowest +(× 107) % of slowest fcpy2.95 no 3.855 97.56 yes3.850 97.42 3.0 no 3.952 100.00
[wwwdocs] projects/cfo.html -- simplify
This uses a new CSS class *once* instead of attributing most elements
in the table with align="right" and also brings us closer to HTML 5
compliance.
Committed.
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.57
diff -u -r1.57 gcc.css
--- gcc.css 2 Sep 2018 11:39:30 - 1.57
+++ gcc.css 2 Sep 2018 13:19:37 -
@@ -16,6 +16,7 @@
.smaller { font-size: 80%; }
.left { text-align:left; }
+.right{ text-align:right; }
.no-margin-top { margin-top:0; }
.twocolumns { column-counts:2; -moz-column-count:2; }
Index: projects/cfo.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfo.html,v
retrieving revision 1.14
diff -u -r1.14 cfo.html
--- projects/cfo.html 1 Sep 2018 23:42:09 - 1.14
+++ projects/cfo.html 2 Sep 2018 13:25:52 -
@@ -164,7 +164,7 @@
http://szeged.github.io/csibe/";>CSiBE benchmark with respect
to the mainline at the last merge (2005-07-11).
-
+
Code size save
@@ -179,43 +179,43 @@
Sequence abstraction on RTL
- 1.07%
- 1.43%
+ 1.07%
+ 1.43%
- 1.94
- 1.26
+ 1.94
+ 1.26
Sequence abstraction on Tree
- 0.34%
- 0.18%
+ 0.34%
+ 0.18%
- 1.25
- 1.25
+ 1.25
+ 1.25
Local factoring on RTL
- 0.11%
- 0.19%
+ 0.11%
+ 0.19%
- 1.01
- 0.99
+ 1.01
+ 0.99
Local factoring on Tree-SSA
- 0.31%
- 0.24%
+ 0.31%
+ 0.24%
- 1.02
- 1.01
+ 1.02
+ 1.01
Overall
- 1.96%
- 1.94%
+ 1.96%
+ 1.94%
- 2.08
- 1.49
+ 2.08
+ 1.49
[C++, wwwdocs] bugs/index.html - complete C++ non-bug entry
Jason and Nathan, while I completed one C+ non-bug entry with the patch below, I am not sure the items as such is really still relevant? In fact, if you could have a look at https://gcc.gnu.org/bugs/#nonbugs_cxx and advise which entries perhaps should be removed (or updated or added), I'll take care. Thanks, Gerald Add a missing element to the C++ Non-bugs section. Index: bugs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v retrieving revision 1.126 diff -u -r1.126 index.html --- bugs/index.html 1 Sep 2018 23:42:01 - 1.126 +++ bugs/index.html 2 Sep 2018 13:30:52 - @@ -538,6 +538,7 @@ C++ +export Most C++ compilers (G++ included) do not yet implement export, which is necessary for separate compilation of template declarations and definitions. Without export, a
[PATCH] x86: Replace hard frame pointer with stack pointer - UNITS_PER_WORD
On Sat, Sep 01, 2018 at 06:38:35AM -0500, Segher Boessenkool wrote:
> >
> > With -fno-omit-frame-pointer, arg pointer is eliminated with hard frame
> > pointer. But
> >
> > commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
> > Author: hjl
> > Date: Thu Aug 10 15:29:05 2017 +
> >
> > i386: Don't use frame pointer without stack access
> >
> > When there is no stack access, there is no need to use frame pointer
> > even if -fno-omit-frame-pointer is used and caller's frame pointer is
> > unchanged.
> >
> > changed it in the last minute. It is too late to go back. When it is done,
> > hard frame pointer must be replaced by stack pointer - UNITS_PER_WORD
> > if it is ever used.
>
> So after that patch something uses the hard frame pointer, while it also
> claims nothing uses the hard frame pointer? Sounds to me you should fix
> the uses, and all will be fine.
>
>
Here is the patch to replace hard frame pointer with stack pointer
- UNITS_PER_WORD in x86 backend.
OK for trunk?
H.J.
---
With
commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
Author: hjl
Date: Thu Aug 10 15:29:05 2017 +
i386: Don't use frame pointer without stack access
When there is no stack access, there is no need to use frame pointer
even if -fno-omit-frame-pointer is used and caller's frame pointer is
unchanged.
frame pointer may not be available even if -fno-omit-frame-pointer is
used. When this happened, arg pointer in debug info may be eliminated
by hard frame pointer. In this case, hard frame pointer should be
replaced by stack pointer - UNITS_PER_WORD.
This patch adds replace_fp_with_sp_in_debug_info to x86 machine_function,
replaces arg pointer in debug info with stack pointer - UNITS_PER_WORD
if it is eliminated by hard frame pointer and disallows hard frame pointer
in debug info when frame pointer isn't available.
gcc/
PR debug/86593
* dwarf2out.c (based_loc_descr): Disallow hard frame pointer when
frame pointer isn't available.
(compute_frame_pointer_to_fb_displacement): Likewise.
* config/i386/i386.c (ix86_finalize_stack_frame_flags): Set
replace_fp_with_sp_in_debug_info to true if frame pointer isn't
used.
(ix86_replace_fp_with_sp_1): New function.
(ix86_replace_fp_with_sp): Likewise.
(ix86_reorg): Call ix86_replace_fp_with_sp if needed.
* config/i386/i386.h (machine_function): Add
replace_fp_with_sp_in_debug_info.
gcc/testsuite/
PR debug/86593
* g++.dg/pr86593-1.C: New test.
* g++.dg/pr86593-2.C: Likewise.
---
gcc/config/i386/i386.c | 103 +++
gcc/config/i386/i386.h | 4 ++
gcc/dwarf2out.c | 6 +-
gcc/testsuite/g++.dg/pr86593-1.C | 11
gcc/testsuite/g++.dg/pr86593-2.C | 11
5 files changed, 131 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/pr86593-1.C
create mode 100644 gcc/testsuite/g++.dg/pr86593-2.C
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8672a666024..8166ea06d42 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13161,6 +13161,11 @@ ix86_finalize_stack_frame_flags (void)
df_compute_regs_ever_live (true);
df_analyze ();
+ /* Replace hard frame pointer with stack pointer in debug
+info. */
+ cfun->machine->replace_fp_with_sp_in_debug_info
+ = debug_info_level > DINFO_LEVEL_NONE;
+
if (flag_var_tracking)
{
/* Since frame pointer is no longer available, replace it with
@@ -41944,6 +41949,99 @@ ix86_seh_fixup_eh_fallthru (void)
}
}
+/* Help function for ix86_replace_fp_with_sp. */
+
+static rtx
+ix86_replace_fp_with_sp_1 (rtx x)
+{
+ if (!x)
+return x;
+
+ if (x == hard_frame_pointer_rtx)
+return plus_constant (Pmode, stack_pointer_rtx, -UNITS_PER_WORD);
+
+ const char *fmt = GET_RTX_FORMAT (GET_CODE (x));
+ int i, j;
+ for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)
+{
+ if (fmt[i] == 'e')
+ XEXP (x, i) = ix86_replace_fp_with_sp_1 (XEXP (x, i));
+ else if (fmt[i] == 'E')
+ for (j = XVECLEN (x, i) - 1; j >= 0; j--)
+ XVECEXP (x, i, j) = ix86_replace_fp_with_sp_1 (XVECEXP (x, i, j));
+}
+
+ return x;
+}
+
+/* Replace hard frame pointer in debug info with stack pointer
+ - UNITS_PER_WORD. */
+
+static void
+ix86_replace_fp_with_sp (void)
+{
+ if (flag_var_tracking)
+{
+ rtx_insn *insn, *next;
+ rtx replace, note;
+ for (insn = get_insns (); insn; insn = next)
+ {
+ next = NEXT_INSN (insn);
+ if (NOTE_P (insn))
+ {
+ if (NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION)
+ {
+ replace = PATTERN (insn);
+ if (reg_mentioned_p (arg_pointer_rtx, replace))
+ {
+ replace = eliminate_regs (replace, VOID
Re: [patch,nvptx] Basic -misa support for nvptx
On 09/01/2018 12:04 PM, Tom de Vries wrote:
> On 08/31/2018 04:14 PM, Cesar Philippidis wrote:
>> Is this patch OK for trunk?
>>
>
> Well, how did you test this (
> https://gcc.gnu.org/contribute.html#patches : "Bootstrapping and
> testing. State the host and target combinations you used to do proper
> testing as described above, and the results of your testing.") ?
I tested the standalone nvptx compiler. I'll retest with libgomp with
-misa=sm_35. Bootstrapping won't help much here, unfortunately.
>> +++ b/gcc/testsuite/gcc.target/nvptx/atomic_fetch-1.c
>> @@ -0,0 +1,24 @@
>> +/* Test the nvptx atomic instructions for __atomic_fetch_OP for SM_35
>> + targets. */
>> +
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -misa=sm_35" } */
>> +
>> +int
>> +main()
>> +{
>> + unsigned long long a = ~0;
>> + unsigned b = 0xa;
>> +
>> + __atomic_fetch_add (&a, b, 0);
>> + __atomic_fetch_and (&a, b, 0);
>> + __atomic_fetch_or (&a, b, 0);
>> + __atomic_fetch_xor (&a, b, 0);
>> +
>> + return a;
>> +}
>> +
>> +/* { dg-final { scan-assembler "atom.add.u64" } } */
>> +/* { dg-final { scan-assembler "atom.b64.and" } } */
>> +/* { dg-final { scan-assembler "atom.b64.or" } } */
>> +/* { dg-final { scan-assembler "atom.b64.xor" } } */
>> -- 2.17.1
>>
>
> Hmm, the add.u64 vs b64.and looks odd (and the scan-assembler-not
> testcase does not use this difference, so that needs to be fixed, or for
> bonus points, changed into a scan-assembler testcase).
>
> The documentation uses "op.type", we should fix the compiler to emit
> that consistently. Separate patch that fixes that pre-approved.
ACK. I think there are a lot of other cases like that in the BE.
> This is ok (with, as I mentioned above, the SI part split off into a
> separate patch), on the condition that you test libgomp with
> -foffload=-misa=sm_35.
Thanks,
Cesar
[wwwdocs] projects/prefetch.html -- replace direct formatting of tables with CSS
Committed. Gerald Index: projects/prefetch.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/prefetch.html,v retrieving revision 1.36 diff -u -r1.36 prefetch.html --- projects/prefetch.html 1 Sep 2018 23:42:10 - 1.36 +++ projects/prefetch.html 2 Sep 2018 15:11:11 - @@ -208,7 +208,7 @@ Summary - + Target Prefetch amount @@ -333,7 +333,7 @@ Instruction LDS with a destination of register F31 prefetches for a store. - + LDBU, LDF, LDG, LDL, LDT, LDWU @@ -358,7 +358,7 @@ The Alpha architecture also defines the following instructions [2]: - + FETCH Prefetch Data @@ -380,7 +380,7 @@ data stream made up of the following elements [4].: - + EA the effective address of the first unit in the sequence; @@ -405,7 +405,7 @@ The instructions that operate on these data streams are: - + dst (Data Stream Touch); data marked as most recently used @@ -474,7 +474,7 @@ The SSE prefetch instruction has the following variants: - + prefetcht0 Temporal data; prefetch data into all cache levels. @@ -508,7 +508,7 @@ The possible values for the locality hint are: - + none Temporal locality for cache level 1 and higher (all levels). @@ -545,7 +545,7 @@ [9] and MIPS64 [10], takes a hint with one of the following values: - + load data is expected to be read, not modified @@ -598,7 +598,7 @@ MMIX has the following data prefetch instructions [11][12]: - + PRELD preload a specified number of bytes of data @@ -625,7 +625,8 @@ A normal load to register GR0 prefetches data. The data prefetch instructions are [13]: - + + LDWPrefetch cache line for read. LDDPrefetch cache line for write. @@ -651,7 +652,7 @@ The PowerPC provides the following data prefetch instructions [14]: - + dcbt Data Cache Block Touch @@ -684,7 +685,7 @@ [15] instructions, whose variants are specified by the fcn field: - + 0 prefetch for several reads
Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement
On Wed, 22 Aug 2018 at 21:37, Janus Weil wrote:
>
> Am Mi., 22. Aug. 2018 um 17:46 Uhr schrieb Thomas Koenig
> :
> >
> > Hi Janus,
> >
> > >> Janus,
> > >>
> > >> On 13 August 2018 21:44:47 CEST, Janus Weil wrote:
> > >>> Hi all,
> > >>>
> > >>> this simple patch improves some of the diagnostics for invalid
> > >>> ASSOCIATE statements:
> > >>>
> > >>> https://github.com/janusw/gcc/commit/2f484479c741abddc8ac473cb0c1b9010397e006
> > >>
> > >> Please do not send external references but the patch itself for
> > >> posterity.
> > >
> > > "git diff pr86935~1 pr86935 > pr86935.diff"
> > > See attachment.
> >
> > The patch is OK; you might want to take Bernhard's remark about
> > the trailing space after "%e" into account.
>
> I have incorporated Bernhard's remark and committed as r263787.
While rebasing my fortran-fe-stringpool branch i spotted one
(pre-existing) possible inconsistency that i did overlook back then:
gfc_match_associate () reads
...
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
/* Have another go, allowing for procedure pointer selectors. */
gfc_matching_procptr_assignment = 1;
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
gfc_error ("Invalid association target at %C");
goto assocListError;
}
gfc_matching_procptr_assignment = 0;
}
i.e. we retry a match, but in the second attempt we turn on procptr
assignment matching and if that works, we turn procptr assignment
matching off again.
But if we fail that retry, we forget to turn it off again.
I suppose we should:
$ svn diff -x -p gcc/fortran/match.c
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 264040)
+++ gcc/fortran/match.c (working copy)
@@ -1898,13 +1898,16 @@ gfc_match_associate (void)
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
/* Have another go, allowing for procedure pointer selectors. */
+ match m;
+
gfc_matching_procptr_assignment = 1;
- if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
+ m = gfc_match (" %e", &newAssoc->target);
+ gfc_matching_procptr_assignment = 0;
+ if (m != MATCH_YES)
{
gfc_error ("Invalid association target at %C");
goto assocListError;
}
- gfc_matching_procptr_assignment = 0;
}
newAssoc->where = gfc_current_locus;
Untested. Maybe someone wants to give it a whirl...
If it wrecks havoc then leaving it set deliberately deserves at least a comment.
PS: It would be nice to get rid of gfc_matching_procptr_assignment,
gfc_matching_ptr_assignment, gfc_matching_prefix, FWIW.
cheers,
>
> Thanks everyone!
>
> Cheers,
> Janus
Re: [PATCHv2] Call braced_list_to_string after array size is fixed
On 08/31/2018 12:47 AM, Bernd Edlinger wrote: > On 08/30/18 09:07, Bernd Edlinger wrote: >> On 08/30/18 06:34, Jason Merrill wrote: >>> On 08/24/2018 03:52 PM, Bernd Edlinger wrote: this updated patch fixes one regression with current trunk due to a new test case. Sorry for the confusion. The change to the previous version is: 1) the check to avoid folding on empty char arrays is restored. 2) A null-termination character is added except when the string is full length. - && TYPE_STRING_FLAG (TREE_TYPE (valtype))) + tree typ1 = TYPE_MAIN_VARIANT (TREE_TYPE (type)); + if (typ1 == char_type_node + || typ1 == signed_char_type_node + || typ1 == unsigned_char_type_node) >>> >>> Why stop using TYPE_STRING_FLAG? >>> >> No longer sure, I will try it with TYPE_STRING_FLAG. >> > This is an update that uses TYPE_STRING_FLAG. > It does not seem to make any difference, though. > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > > > Is it OK for trunk? > > > Thanks > Bernd. > > > patch-bracedstr-v2.diff > > > c-family: > 2018-08-24 Bernd Edlinger > > * c-common.c (braced_list_to_string): Remove eval parameter. > Add some more checks. Always create zero-terminated STRING_CST. > * c-common.h (braced_list_to_string): Adjust prototype. > > c: > 2018-08-24 Bernd Edlinger > > * c-decl.c (finish_decl): Call braced_list_to_string here ... > * c-parser.c (c_parser_declaration_or_fndef): ... instead of here. > > > cp: > 2018-08-24 Bernd Edlinger > > * decl.c (eval_check_narrowing): Remove. > (check_initializer): Move call to braced_list_to_string from here ... > * typeck2.c (store_init_value): ... to here. > (digest_init_r): Remove handing of signed/unsigned char strings. > > testsuite: > 2018-08-24 Bernd Edlinger > > * c-c++-common/array-init.c: New test. > * g++.dg/init/string2.C: Remove xfail. Thanks. Committed. Jeff
Re: [patch, libgfortran] Fix warning about mismatched type declarations.
On 09/02/2018 04:49 AM, Thomas Koenig wrote: Hi Jerry, The subject patch fixes the declaration for the vlist argument of the formatted_dtio function pointer definition which currently gives a warnings during compilation for mismatched types. Regression tested on x86_64-pc-linux. OK for trunk? OK. Thanks! Regards Thomas Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ... M libgfortran/ChangeLog M libgfortran/io/format.c M libgfortran/io/format.h M libgfortran/io/io.h Committed r264043
[wwwdocs] gcc-3.0/criteria.html -- fix up to HTML 5
...by stripping use of some obsolete features and adding missing table cells (). Committed. Gerald Index: gcc-3.0/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/criteria.html,v retrieving revision 1.34 diff -u -r1.34 criteria.html --- gcc-3.0/criteria.html 1 Sep 2018 23:42:02 - 1.34 +++ gcc-3.0/criteria.html 2 Sep 2018 16:55:04 - @@ -8,8 +8,8 @@ -This document is obsolete and kept for historical reference -only. +This document is obsolete and kept for historical reference +only. GCC 3.0 Release Criteria @@ -113,7 +113,7 @@ systems and the most popular microprocessors. Of course, where possible, the release will support other targets as well. - + Primary Evaluation Platforms Chip OS Triplet AlphaRed Hat Linux 6.2 @@ -150,18 +150,22 @@ team, will make reasonable efforts to assist these volunteers by answering questions and reviewing patches as time permits. - + Secondary Evaluation Platforms Chip OS Triplet Tester Intel x86FreeBSD 4.2 i386-unknown-freebsd4.2 mailto:obr...@freebsd.org";>David O'Brien -PowerPC GNU/Linux -SPARCSunOS 4.1.4 sparc-sun-sunos4.1.4 +PowerPC GNU/Linux + +SPARCSunOS 4.1.4 sparc-sun-sunos4.1.4 + SPARCDebian GNU/Linux 2.2sparc-linux mailto:bcoll...@debian.org";>Ben Collins -ARM GNU/Linux armv4l-unknown-linux-gnu -Intel x86Cygwin i686-pc-cygwin +ARM GNU/Linux armv4l-unknown-linux-gnu + +Intel x86Cygwin i686-pc-cygwin + Language Support @@ -214,7 +218,7 @@ and high-level code, of numerical and logical programs, and of different programming languages. - + Integration Tests Name Language @@ -292,18 +296,22 @@ previous releases. Therefore, we will use the following benchmarks for measuring code quality: - + Name Language Source URL -gzip 1.2.4aC +gzip 1.2.4a +C + -StepanovC++ +Stepanov +C++ ftp://ftp.kai.com/pub/benchmarks/stepanov_v1p2.C";> stepanov_v1p2.C -LAPACKFortran +LAPACK +Fortran http://www.netlib.org/lapack/lapack.tgz";> LAPACK 3.0 (timing programs) @@ -351,9 +359,9 @@ statement; it is a reasonable benchmark for testing flow optimizations and for handling large functions. -C++ +C++ -Fortran +Fortran
[wwwdocs] projects/h8300-abi.html -- replace by
...hence converting to proper HTML 5.
Committed.
Gerald
Index: projects/h8300-abi.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/h8300-abi.html,v
retrieving revision 1.9
diff -u -r1.9 h8300-abi.html
--- projects/h8300-abi.html 1 Sep 2018 23:42:09 - 1.9
+++ projects/h8300-abi.html 2 Sep 2018 16:59:17 -
@@ -30,12 +30,12 @@
Argument Passing
-With -mno-quickcall
+With -mno-quickcall
-With -mno-quickcall, every argument is pushed onto the
+With -mno-quickcall, every argument is pushed onto the
stack.
-Without -mno-quickcall
+Without -mno-quickcall
Functions with Fixed-Length Arguments
@@ -126,15 +126,15 @@
Frame Pointer
On H8/300, R6 is used as the frame pointer. On H8/300H and H8S,
-ER6 is used as the frame pointer. -fomit-frame-pointer can
-be used to eliminate the use of the frame pointer in favor of the
+ER6 is used as the frame pointer. -fomit-frame-pointer
+can be used to eliminate the use of the frame pointer in favor of the
stack pointer.
Bit-Field
The memory location containing a bit-field is filled from MSB to
-LSB. In the following example, a will take bit 7, MSB.
-b will take bit 6 and bit 5.
+LSB. In the following example, a will take bit 7, MSB.
+b will take bit 6 and bit 5.
struct s {
@@ -145,7 +145,7 @@
Structure Alignment
-Unless __attribute__ ((packed)) is attached to the
+Unless __attribute__ ((packed)) is attached to the
declaration of a struct, each structure member is aligned to a
multiple of 2 bytes on H8/300 and of 4 bytes on H8/300H and H8S.
[wwwdocs] projects/bp/main.html -- remove obsolete
Committed. Gerald Index: projects/bp/main.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/bp/main.html,v retrieving revision 1.22 diff -u -r1.22 main.html --- projects/bp/main.html 1 Sep 2018 23:42:10 - 1.22 +++ projects/bp/main.html 2 Sep 2018 17:02:43 - @@ -4,7 +4,6 @@ Bounds Checking in C & C++ using Bounded Pointers https://gcc.gnu.org/gcc.css"; /> -mailto:g...@mcgary.org"; />
[wwwdocs] Revamp formatting markup of bugs/management.html
...making this page HTML 5 compliant.
Committed.
Gerald
Use new CSS clases center and top instead of direct markup. Improve
alignment of the "Severity" table and adjust that of the "Priority" table.
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.58
diff -u -r1.58 gcc.css
--- gcc.css 2 Sep 2018 13:20:18 - 1.58
+++ gcc.css 2 Sep 2018 17:23:57 -
@@ -17,6 +17,8 @@
.left { text-align:left; }
.right{ text-align:right; }
+.center { text-align:center; }
+.top { vertical-align:top; }
.no-margin-top { margin-top:0; }
.twocolumns { column-counts:2; -moz-column-count:2; }
Index: bugs/management.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v
retrieving revision 1.38
diff -u -r1.38 management.html
--- bugs/management.html1 Sep 2018 23:42:01 - 1.38
+++ bugs/management.html2 Sep 2018 17:28:56 -
@@ -86,57 +86,65 @@
The following two fields describe how serious a bug is from a user's
perspective (Severity) and what Priority we assign to it in fixing it:
-
-
+
+
-Severity
+Severity
This field describes the impact of a bug.
+
-Criticalcrashes, memory leaks and similar problems on code
-that is written in a common enough style to affect a significant fraction of
-users
-Normalmajor loss of functionality
-Minorminor loss of functionality, misspelled word, or other
-problem where an easy workaround exists
-EnhancementRequest for enhancement
+Critical
+crashes, memory leaks and similar problems on code that is written
+in a common enough style to affect a significant fraction of users
+
+Normal
+major loss of functionality
+
+Minor
+minor loss of functionality, misspelled word, or other
+problem where an easy workaround exists
+
+Enhancement
+Request for enhancement
+
-
+
-Priority
+Priority
For regressions this field describes the importance
and order in which a bug should be fixed. Priorities are set by
the release management team only. If you think a priority is wrong,
set it to P3 and add a note.
The available priorities are:
-
+
- P1
+ P1
Most important. This generally labels a regression which the
release manager feels should be addressed for the next release
including wrong-code regressions.
A P1 regression blocks the release.
- P2
+ P2
This generally indicates a regression users will notice on a
major platform, which is not severe enough to block a release though.
This includes bugs that were already present in a previous release.
- P3
+ P3
The default priority for new PRs which have not been prioritized
yet. Priorities below P3 are not on the radar of release management.
- P4
+ P4
An important regression on a platform that is not in the list of
primary or secondary targets or a regression that users
will not see for release builds.
This includes bugs with error-recovery or ice-checking keywords.
- P5
+ P5
A less important regression on a platform that is not in the list of
primary or secondary targets.
[wwwdocs] gcc-3.3/gcj-status.html - streamline formatting
...making things HTML 5 compliant on the way (without a real loss). Committed. Gerald Index: gcc-3.3/gcj-status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/gcj-status.html,v retrieving revision 1.10 diff -u -r1.10 gcj-status.html --- gcc-3.3/gcj-status.html 1 Sep 2018 23:42:03 - 1.10 +++ gcc-3.3/gcj-status.html 2 Sep 2018 19:09:41 - @@ -19,7 +19,7 @@ Packages - + Package Status Who @@ -28,7 +28,7 @@ - rhug + rhug ok on x86 @@ -38,7 +38,7 @@ Mark Wielaard - http://www-124.ibm.com/developerworks/oss/cvs/jikes/~checkout~/jacks/jacks.html";>Jacks + http://www-124.ibm.com/developerworks/oss/cvs/jikes/~checkout~/jacks/jacks.html";>Jacks As good as we're going to be
Re: [wwwdocs] gcc-3.3/gcj-status.html - streamline formatting
On Sun, 2 Sep 2018, Gerald Pfeifer wrote: > ...making things HTML 5 compliant on the way (without a real loss). And pretty much the same patch for gcc-3.1/gcj-status.html, which initially escaped my attention. Committed as well. Gerald Index: gcc-3.1/gcj-status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/gcj-status.html,v retrieving revision 1.5 diff -u -r1.5 gcj-status.html --- gcc-3.1/gcj-status.html 1 Sep 2018 23:42:03 - 1.5 +++ gcc-3.1/gcj-status.html 2 Sep 2018 19:14:53 - @@ -17,7 +17,7 @@ Platforms - + Platform Status Who @@ -84,7 +84,7 @@ Adam - PPC Darwin + PPC Darwin stddef.h tweak, std_cctype.h tweak, use "ar qc" Andreas, Alexandre, others @@ -108,7 +108,7 @@ Packages - + Package Status Who
[PATCH] Skip check for dlopen() when compiling libstdcxx with avrlibc
Hello,
II tried compiling avr-gcc (AVR 8-bit target) with libstdcxx support,
and even if I set the configure parameters to be "disable-shared" and
"enable-static", the "configure" step fails because it checks for
dlopen() support in avrlibc (which doesn't exist).
I see that in the newlib case, the failing step is skipped, so I've
just added branch to the condition, to skip the same check for
avrlibc.
Please double-check this patch, as it's my first commit to the GCC
project, and I had to manually adjust a couple of things for the
regeneration step to work out.
Thank you,
Adrian Stratulat
Index: libstdc++-v3/ChangeLog
===
--- libstdc++-v3/ChangeLog (revision 264043)
+++ libstdc++-v3/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2018-09-02 Adrian Stratulat
+
+ * configure.ac: Skip dlopen check for avrlibc builds.
+ * configure: Regenerate
+
2018-09-02 François Dumont
* include/debug/safe_iterator.h
Index: libstdc++-v3/configure
===
--- libstdc++-v3/configure (revision 264043)
+++ libstdc++-v3/configure (working copy)
@@ -5376,7 +5376,9 @@ $as_echo "$as_me: OS config directory is
# Libtool setup.
-if test "x${with_newlib}" != "xyes"; then
+if test "x${with_newlib}" != "xyes" &&
+ test "x${with_avrlibc}" != "xyes";
+then
enable_dlopen=yes
Index: libstdc++-v3/configure.ac
===
--- libstdc++-v3/configure.ac (revision 264043)
+++ libstdc++-v3/configure.ac (working copy)
@@ -89,7 +89,9 @@ CXXFLAGS="$save_CXXFLAGS"
GLIBCXX_CONFIGURE
# Libtool setup.
-if test "x${with_newlib}" != "xyes"; then
+if test "x${with_newlib}" != "xyes" &&
+ test "x${with_avrlibc}" != "xyes";
+then
AC_LIBTOOL_DLOPEN
fi
AM_PROG_LIBTOOL
Re: [wwwdocs] projects/cfo.html -- simplify
On Sun, 2 Sep 2018, Gerald Pfeifer wrote: > This uses a new CSS class *once* instead of attributing most elements > in the table with align="right" and also brings us closer to HTML 5 > compliance. And this also takes care of align="center" by using the CSS of the same name I introduced earlier today. Gerald Index: projects/cfo.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfo.html,v retrieving revision 1.16 diff -u -r1.16 cfo.html --- projects/cfo.html 2 Sep 2018 13:26:43 - 1.16 +++ projects/cfo.html 2 Sep 2018 19:19:17 - @@ -167,15 +167,15 @@ - Code size save - Compilation time multiplier + Code size save + Compilation time multiplier Target - arm-elf - i686-linux - arm-elf - i686-linux + arm-elf + i686-linux + arm-elf + i686-linux Sequence abstraction on RTL
Re: [PATCH] Skip check for dlopen() when compiling libstdcxx with avrlibc
On 02/09/18 22:18 +0300, Adrian Stratulat wrote: Hello, II tried compiling avr-gcc (AVR 8-bit target) with libstdcxx support, and even if I set the configure parameters to be "disable-shared" and "enable-static", the "configure" step fails because it checks for dlopen() support in avrlibc (which doesn't exist). Why has nobody noticed this problem before? You're not the first person to build avr-gcc. Does nobody else build libstdc++ for AVR? I see that in the newlib case, the failing step is skipped, so I've just added branch to the condition, to skip the same check for avrlibc. That seems reasonable. Please double-check this patch, as it's my first commit to the GCC project, and I had to manually adjust a couple of things for the regeneration step to work out. Has it been tested? Does it work?
Re: Relocation (= move+destroy)
On 01/09/18 21:56 +0200, Marc Glisse wrote: On Sat, 1 Sep 2018, Marc Glisse wrote: this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu. I realized afterwards that for a C++17-only feature, that's not testing much... So I changed it to apply in C++14 and fixed a minor issue. There is now a single regression: 23_containers/vector/modifiers/push_back/49836.cc The PR was about not using assignment for an operation that should only use construction, and that's fine. But we ended up with a stricter testcase using CopyConsOnlyType, where the type has a deleted move constructor which, as far as I understand the standard, makes it an invalid type for use in vector::push_back. Is that something we want to keep supporting, or may I break it? What is happening is that I think you can break it. I'll look back over the history of the test case, but I don't think supporting deleted moves is intended. the definition of __use_relocate asks if some expression involving a move of _Tp is noexcept, which causes a hard error. It would certainly be possible to work around that, but it would complicate the code and seems quite pointless to me. Agreed.
Re: Relocation (= move+destroy)
On 2 September 2018 at 23:03, Jonathan Wakely wrote: > On 01/09/18 21:56 +0200, Marc Glisse wrote: >> >> On Sat, 1 Sep 2018, Marc Glisse wrote: >> >>> this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu. >> >> >> I realized afterwards that for a C++17-only feature, that's not testing >> much... So I changed it to apply in C++14 and fixed a minor issue. There is >> now a single regression: >> >> 23_containers/vector/modifiers/push_back/49836.cc >> >> The PR was about not using assignment for an operation that should only >> use construction, and that's fine. But we ended up with a stricter testcase >> using CopyConsOnlyType, where the type has a deleted move constructor which, >> as far as I understand the standard, makes it an invalid type for use in >> vector::push_back. Is that something we want to keep supporting, or may I >> break it? What is happening is that > > > I think you can break it. I'll look back over the history of the test > case, but I don't think supporting deleted moves is intended. We have supported those occasionally; I did so in std::any, but the standard has explicitly been moving towards a direction where deleted moves (if corresponding copies are not deleted) are not a supported thing, so I concur with the suggestion of breaking such tests being okay.
[wwwdocs] codingconventions.html -- convert to HTML 5
Convert to HTML by using CSS instead of cellpadding= and align=. On the way ensure that all table rows have the appropriate number of cells. Committed. Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.83 diff -u -r1.83 codingconventions.html --- codingconventions.html 1 Sep 2018 23:42:00 - 1.83 +++ codingconventions.html 2 Sep 2018 20:24:28 - @@ -298,7 +298,7 @@ documentation and diagnostics is more important than that in comments and code. The following table lists some simple cases: - + Use..instead ofRationale @@ -393,6 +393,7 @@ "free software" or just "free" "Open Source" or "OpenSource" + "front end" (noun) @@ -448,6 +449,7 @@ "Objective-C" "Objective C" + "prologue" @@ -457,6 +459,7 @@ "PowerPC" "powerpc", "powerPC" or "PowerPc" + "Red Hat" @@ -483,10 +486,12 @@ "SPARC" "Sparc" or "sparc" + "testcase", "testsuite" "test-case" or "test case", "test-suite" or "test suite" + "uppercase" @@ -496,6 +501,7 @@ "VAX", "VAXen", "MicroVAX" "vax" or "Vax", "vaxen" or "vaxes", "microvax" or "microVAX" + @@ -778,26 +784,30 @@ Code in GCC should use the following formatting conventions: - + - For - Use..instead of + For + Use... + ...instead of - logical not - !x! x + logical not + !x + ! x - bitwise complement - ~x~ x + bitwise complement + ~x + ~ x - unary minus - -x- x + unary minus + -x + - x - cast - (foo) x + cast + (foo) x (foo)x - pointer dereference - *x + pointer dereference + *x * x
[wwwdocs] news.html - omit use of
...thus making this page proper HTML 5. Committed. Gerald Index: news.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v retrieving revision 1.163 diff -u -r1.163 news.html --- news.html 1 Sep 2018 23:42:00 - 1.163 +++ news.html 2 Sep 2018 20:27:37 - @@ -1754,7 +1754,7 @@ November 23, 1998 -egcs now can dump flow graph information usable for +egcs now can dump flow graph information usable for graphical representation. Contributed by Ulrich Drepper.
Re: [PATCH] Skip check for dlopen() when compiling libstdcxx with avrlibc
On Sun, Sep 2, 2018 at 11:00 PM Jonathan Wakely wrote: > > On 02/09/18 22:18 +0300, Adrian Stratulat wrote: > >Hello, > > > >II tried compiling avr-gcc (AVR 8-bit target) with libstdcxx support, > >and even if I set the configure parameters to be "disable-shared" and > >"enable-static", the "configure" step fails because it checks for > >dlopen() support in avrlibc (which doesn't exist). > > Why has nobody noticed this problem before? You're not the first > person to build avr-gcc. Does nobody else build libstdc++ for AVR? Libstdc++ support for avr-gcc was added in 2016 [1] and wasn't used widely, as the avr-libc project considers libstdc++ to be unsupported [2]. When the initial developer tried to get the library added to the ArchLinux package system, the package maintainer hit the same error I was seeing [3]. Also, it seems that this corner-case of the config causes problems from time to time, on embedded/non-mainstream platforms ([4], [5]). > >I see that in the newlib case, the failing step is skipped, so I've > >just added branch to the condition, to skip the same check for > >avrlibc. > > That seems reasonable. > > >Please double-check this patch, as it's my first commit to the GCC > >project, and I had to manually adjust a couple of things for the > >regeneration step to work out. > > Has it been tested? Does it work? For the AVR platform? Yes, I did test it and it works: compiled an avr-g++ instance with libstdc++ and then used a couple of features from C++17 (std::optional<> templates). [1] https://patchwork.ozlabs.org/patch/670656/ [2] https://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus [3] https://bugs.archlinux.org/task/56293 [4] https://gcc.gnu.org/ml/gcc/2008-03/msg00515.html [5] https://forum.osdev.org/viewtopic.php?f=13&t=29983
[wwwdocs] projects/tree-ssa/vectorization.html - complete conversion to CSS and HTML 5
Committed.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.60
diff -u -r1.60 gcc.css
--- gcc.css 2 Sep 2018 17:24:50 - 1.60
+++ gcc.css 2 Sep 2018 20:36:32 -
@@ -20,6 +20,8 @@
.center { text-align:center; }
.top { vertical-align:top; }
+.width33 { width:33%; }
+
.no-margin-top { margin-top:0; }
.twocolumns { column-counts:2; -moz-column-count:2; }
.imgleft { margin: 5px 20px; float: left; }
Index: projects/tree-ssa/vectorization.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v
retrieving revision 1.39
diff -u -r1.39 vectorization.html
--- projects/tree-ssa/vectorization.html2 Sep 2018 12:05:16 -
1.39
+++ projects/tree-ssa/vectorization.html2 Sep 2018 20:36:33 -
@@ -1638,17 +1638,17 @@
-
+
-
-vectorization driver
+
+vectorization driver
-basic vectorizer
+basic vectorizer
-enhancements
+enhancements
-
+
analyze_loop_CFG(loop)
@@ -1698,7 +1698,7 @@
-
+
analyze_loop_index_and_bound(loop)
@@ -1736,7 +1736,7 @@
-
+
analyze_loop_stmts(loop-stmts)
@@ -1781,7 +1781,7 @@
-
+
analyze_access_pattern(loop-mem-refs)
@@ -1818,7 +1818,7 @@
-
+
analyze_alignment(loop-mem-refs)
@@ -1847,7 +1847,7 @@
-
+
analyze_loop_carried_dependences(loop)
@@ -1894,7 +1894,7 @@
-
+
estimate_vectorization_profitability(loop)
@@ -1920,7 +1920,7 @@
-
+
vectorize_loop(loop)
[wwwdocs] gcc-3.4/sparc-abi.html -- convert to HTML 5
...replacing cellpading=, omitting valign="top" whichactually made
things look worse, and using class="right" instead of manual alignment.
Committed.
Gerald
Index: gcc-3.4/sparc-abi.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/sparc-abi.html,v
retrieving revision 1.6
diff -u -r1.6 sparc-abi.html
--- gcc-3.4/sparc-abi.html 1 Sep 2018 23:42:03 - 1.6
+++ gcc-3.4/sparc-abi.html 2 Sep 2018 19:49:03 -
@@ -20,32 +20,32 @@
A. Small structure arguments and return values (1)
-
-
-Affected ABI
+
+
+Affected ABI
64-bit
-
-Conditions
+
+Conditions
A small structure is passed or returned in a register; and
it contains a unique field of type float .
-
-Old behavior
+
+Old behavior
The register was odd-numbered.
-
-New behavior
+
+New behavior
The register is even-numbered.
-
-Example
+
+Example
struct s { float f; };
void g (struct s x);
@@ -56,14 +56,14 @@
B. Small structure arguments and return values (2)
-
-
-Affected ABI
+
+
+Affected ABI
64-bit
-
-Conditions
+
+Conditions
A small structure is passed or returned in registers;
its size in bytes is not a multiple of 8 and is greater than
8;
@@ -72,39 +72,39 @@
-
-Old behavior
+
+Old behavior
The last used register was padded at the most significant end.
-
-New behavior
+
+New behavior
The last used register is padded at the least significant end.
-
-Example
+
+Example
struct s { float f; int i; int j; };
void g (struct s x);
x is passed in several registers, which are laid
out as follows:
-
-
+
+
%f0 %o0 (high) %o0 (low)
%o1 (high) %o1 (low)
-
- Old behavior
+
+ Old behavior
f padding i
padding j
-
- New behavior
+
+ New behavior
f padding i
j padding
@@ -114,51 +114,51 @@
C. Small unions arguments and return values
-
-
-Affected ABI
+
+
+Affected ABI
64-bit
-
-Conditions
+
+Conditions
A small union is passed or returned in a register; and
its size in bytes is less than 8.
-
-Old behavior
+
+Old behavior
The register was padded at the most significant end.
-
-New behavior
+
+New behavior
The register is padded at the least significant end.
-
-Example
+
+Example
union u { int i; float f; };
void g (union u x);
x is passed in register %o0, which is
laid out as follows:
-
-
+
+
%o0 (high) %o0 (low)
-
- Old behavior
+
+ Old behavior
padding i/f
-
- New behavior
+
+ New behavior
i/f padding
@@ -167,14 +167,14 @@
D. Small structure arguments (1)
-
-
-Affected ABI
+
+
+Affected ABI
64-bit
-
-Conditions
+
+Conditions
A small structure is passed past the 6th argument slot and
prior to the last one; and
@@ -182,18 +182,18 @@
-
-Old behavior
+
+Old behavior
The complex floating-point field was passed on the stack.
-
-New behavior
+
+New behavior
The complex floating-point field is passed in registers.
-
-Example
+
+Example
struct s { _Complex float cf; };
void g (struct s x1, struct s x2, struct s x3, struct s x4, struct s x5,
struct s x6, struct s x7);
@@ -204,14 +204,14 @@
E. Small structure arguments (2)
-
-
-Affected ABI
+
+
+Affected ABI
64-bit
-
-Conditions
+
+Conditions
A small structure is passed past the 6th argument slot and
prior to the last one;
@@ -220,18 +220,18 @@
-
-Old behavior
+
+Old behavior
The floating-point field was passed on the stack.
-
-New behavior
+
+New behavior
The floating-point field is passed in registers.
-
-Example
+
+Example
struct s { struct { double d; } ns; };
void g (struct s x1, struct s x2, struct s x3, struct s x4, struct s x5,
struct s x6, struct s x7);
@@ -242,76 +242,76 @@
F. Complex floating-point arguments and return values
-
-
-Affected ABI
+
+
+Affected ABI
32-bit
-
-Conditions
+
+Conditions
A complex floating-point value is passed to or returned from a
function.
-
-Old behavior
+
+Old behavior
The
[wwwdocs] Partially convert search.html to CSS
Committed. Gerald Index: search.html === RCS file: /cvs/gcc/wwwdocs/htdocs/search.html,v retrieving revision 1.195 diff -u -r1.195 search.html --- search.html 1 Sep 2018 23:42:00 - 1.195 +++ search.html 2 Sep 2018 20:42:19 - @@ -90,7 +90,7 @@ Mailing lists, including those for the old egcs project. Ticking a box is like marking all dates for that list: - + gcc @@ -118,7 +118,7 @@ ...-testresults - + Mar 2013 @@ -1206,7 +1206,7 @@ - + ...-regression @@ -1228,7 +1228,7 @@ fortran - + Mar 2013 @@ -1603,7 +1603,7 @@ - + libstdc++ @@ -1617,7 +1617,7 @@ ...-prs - + Mar 2013 @@ -1898,7 +1898,7 @@ - + java @@ -1916,7 +1916,7 @@ ...-announce - + Mar 2013
[wwwdocs] gcc-4.9/changes.html - replace use of
...with , which should render this page HTML 5 compliant.
Committed.
Gerald
Index: gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.94
diff -u -r1.94 changes.html
--- gcc-4.9/changes.html1 Sep 2018 23:42:05 - 1.94
+++ gcc-4.9/changes.html2 Sep 2018 20:46:25 -
@@ -222,8 +222,10 @@
The G++ implementation of C++1y
return type deduction for normal
functions has been updated to conform to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html";>N3638,
-the proposal accepted into the working paper. Most notably, it adds
decltype(auto) for
-getting decltype semantics rather than the template argument
deduction semantics of plain auto:
+the proposal accepted into the working paper. Most notably, it adds
+decltype(auto) for getting decltype semantics
+rather than the template argument deduction semantics of plain
+auto:
int& f();
auto i1 = f(); // int
@@ -236,8 +238,8 @@
[x = 42]{ ... };
Actually, they have been accepted since GCC 4.5, but now the compiler doesn't
-warn about them with -std=c++1y, and supports parenthesized and
-brace-enclosed initializers as well.
+warn about them with -std=c++1y, and supports parenthesized
+and brace-enclosed initializers as well.
G++ supports C++1y variable length
@@ -245,7 +247,7 @@
additionally supports initializers and lambda capture by reference. In
C++1y mode G++ will complain about VLA uses that are not permitted by
the draft standard, such as forming a pointer to VLA type or
-applying sizeof to a VLA variable. Note that it now appears
+applying sizeof to a VLA variable. Note that it now appears
that VLAs will not be part of C++14, but will be part of a separate
document and then perhaps C++17.
[wwwdocs] gcc-3.4/criteria.html - simplify
Remove align="center" attributes from tables. Committed. Gerald Index: gcc-3.4/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/criteria.html,v retrieving revision 1.8 diff -u -r1.8 criteria.html --- gcc-3.4/criteria.html 1 Sep 2018 23:42:03 - 1.8 +++ gcc-3.4/criteria.html 2 Sep 2018 21:29:39 - @@ -64,7 +64,7 @@ systems and the most popular microprocessors. Of course, where possible, the release will support other targets as well. - + Primary Evaluation Platforms Chip OS Triplet @@ -123,7 +123,7 @@ team, will make reasonable efforts to assist these volunteers by answering questions and reviewing patches as time permits. - + Secondary Evaluation Platforms Chip OS Triplet @@ -200,7 +200,7 @@ to general information about a package and a source URL. Versions shown here are used for GCC 3.4 integration testing. - + Integration Tests Name Language @@ -313,7 +313,7 @@ Therefore, we will use the following benchmarks for measuring code quality: - + Name Language Source URL @@ -356,7 +356,8 @@ In order to measure compile-time performance, we will use the following unit tests: - + + Name Language Source
[wwwdocs] faq.html -- replace
...by , rendering this page HTML 5 compliant. Committed. Gerald Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v retrieving revision 1.229 diff -u -r1.229 faq.html --- faq.html1 Sep 2018 23:42:00 - 1.229 +++ faq.html2 Sep 2018 21:34:39 - @@ -217,23 +217,24 @@ building GCC. Another alternative is to create links to GNU as and ld in any of -the directories printed by the command `gcc -print-search-dirs | -grep '^programs:''. The link to `ld' should be named -`real-ld' if `ld' already exists. If such links do -not exist while you're compiling GCC, you may have to create them in -the build directories too, within the gcc directory -and in all the gcc/stage* subdirectories. +the directories printed by the command `gcc -print-search-dirs | +grep '^programs:''. The link to `ld' should be named +`real-ld' if `ld' already exists. If such links +do not exist while you're compiling GCC, you may have to create them in +the build directories too, within the gcc directory +and in all the gcc/stage* subdirectories. GCC 2.95 allows you to specify the full pathname of the assembler and the linker to use. The configure flags are -`--with-as=/path/to/as' and `--with-ld=/path/to/ld'. -GCC will try to use these pathnames before looking for `as' -or `(real-)ld' in the standard search dirs. If, at +`--with-as=/path/to/as' and +`--with-ld=/path/to/ld'. +GCC will try to use these pathnames before looking for `as' +or `(real-)ld' in the standard search dirs. If, at configure-time, the specified programs are found to be GNU utilities, -`--with-gnu-as' and `--with-gnu-ld' need not be +`--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will be auto-detected. One drawback of this option is that it won't allow you to override the search path for assembler -and linker with command-line options -B/path/ if the +and linker with command-line options -B/path/ if the specified filenames exist. @@ -444,7 +445,8 @@ compile additional code to be included in the library. That additional code must also be compiled with the proper PIC option. -Adding the proper PIC option (-fpic or -fPIC) to the link +Adding the proper PIC option (-fpic or -fPIC) +to the link line which creates the shared library will fix this problem on targets that support PIC in this manner. For example:
[wwwdocs] gcc-3.3/criteria.html - simplify
Similar changes as for gcc-3.4/criteria.html, now HTML 5. Committed. Gerald Index: gcc-3.3/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/criteria.html,v retrieving revision 1.15 diff -u -r1.15 criteria.html --- gcc-3.3/criteria.html 1 Sep 2018 23:42:03 - 1.15 +++ gcc-3.3/criteria.html 2 Sep 2018 21:39:48 - @@ -64,7 +64,7 @@ systems and the most popular microprocessors. Of course, where possible, the release will support other targets as well. - + Primary Evaluation Platforms Chip OS Triplet @@ -123,7 +123,7 @@ team, will make reasonable efforts to assist these volunteers by answering questions and reviewing patches as time permits. - + Secondary Evaluation Platforms Chip OS Triplet @@ -200,7 +200,7 @@ to general information about a package and a source URL. Versions shown here are used for GCC 3.3 integration testing. - + Integration Tests Name Language @@ -313,7 +313,7 @@ Therefore, we will use the following benchmarks for measuring code quality: - + Name Language Source URL @@ -356,7 +356,7 @@ In order to measure compile-time performance, we will use the following unit tests: - + Name Language Source
Re: [patch, fortran] Asynchronous I/O, take 3
On Sun, 15 Jul 2018 at 13:20, Thomas Koenig wrote:
> So, here is the final version. I would really like to get this
> into trunk, and out of the way, so Nicolas and I can focus on
> other things.
>
> So, OK?
[I know i'm late as it was already applied]
For me it would be easier to read the locking if struct async_unit had
it's queue_lock named q_lock/qlock instead of plain lock.
The io_lock is named nicely already.
Furthermore there is a mixture of (correctly wrapped) __gthread_ in
struct adv_cond versus unwrapped pthread_mutex_t in struct async_unit
where i'd have expected the latter to also use the __gthread wrappers.
struct adv_cond member pending should not be an int but an unsigned
int or, even better, a bool, i'd say.
transfer_array_inner () is named unintuitively IMHO. Maybe
transfer_array_now, transfer_array_scalar or transfer_array_1.
Index: libgfortran/io/async.c
===
--- libgfortran/io/async.c (nicht existent)
+++ libgfortran/io/async.c (Arbeitskopie)
[]
+static void
+update_pdt (st_parameter_dt **old, st_parameter_dt *new) {
+ st_parameter_dt *temp;
+ NOTE ("Changing pdts, current_unit = %p", (void *) (new->u.p.current_unit));
+ temp = *old;
+ *old = new;
+ if (temp)
+free (temp);
+}
free (NULL) is perfectly valid, please remove the if.
+static void *
+async_io (void *arg)
+{
[]
+ while (true)
+{
+ /* Main loop. At this point, au->lock is always held. */
dot space space at the end of a sentence please.
[]
+ while (ctq)
+ {
+ if (prev)
+ free (prev);
Likewise, drop if.
+ prev = ctq;
+ if (!au->error.has_error)
I'd flag that as likely.
Likewise, i'd flag finish_thread as unlikely; Being a label you can
hint the predictor that it's rather unlikely jumped to by flagging it
cold:
finish_thread: __attribute__((cold));
+/* Initialize an asyncronous unit, returning zero on success,
+ nonzero on failure. It also sets u->au. */
+
+void
+init_async_unit (gfc_unit *u)
s/asyncronous/asynchronous/
+{
+ async_unit *au;
+ if (!__gthread_active_p ())
+{
+ u->au = NULL;
+ return;
+}
+
Excess horizontal space on the empty line above.
+ au = (async_unit *) xmalloc (sizeof (async_unit));
I'd XCNEW (async_unit) and omit all those NULL and 0 stores.
You should use the scalar allocators provided in include/libiberty.h
throughout, so s/xmalloc/XNEW/ and s/free/XDELETE/ and so on.
+/* Enqueue a transfer statement. */
+
+void
+enqueue_transfer (async_unit *au, transfer_args *arg, enum aio_do type)
+{
+ transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
+ tq->arg = *arg;
boom on OOM. XCNEW (transfer_queue), please.
+ tq->arg = *arg;
+ tq->type = type;
+ tq->has_id = 0;
redundant store to has_id.
+ LOCK (&au->lock);
+ if (!au->tail)
+au->head = tq;
+ else
+au->tail->next = tq;
+ au->tail = tq;
+ REVOKE_SIGNAL (&(au->emptysignal));
+ au->empty = false;
+ UNLOCK (&au->lock);
+ SIGNAL (&au->work);
+}
+/* Enqueue an st_write_done or st_read_done which contains an ID. */
+
+int
+enqueue_done_id (async_unit *au, enum aio_do type)
+{
+ int ret;
+ transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
XCNEW.
+/* Enqueue an st_write_done or st_read_done without an ID. */
+
+void
+enqueue_done (async_unit *au, enum aio_do type)
+{
+ transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
XCNEW.
+ tq->type = type;
+ tq->has_id = 0;
Redundant store to has_id. Maybe just comment it out if you do want to
emphasis this side-effect of zeroing.
/* tq->has_id = 0; already done by XCNEW */
or the like.
+/* Enqueue a CLOSE statement. */
+
+void
+enqueue_close (async_unit *au)
+{
+ transfer_queue *tq = calloc (sizeof (transfer_queue), 1);
XCNEW.
And i think enqueue_close does not need internal_proto but could be
and should be static.
Or, even better, remove it completely and call
enqueue_done (au, AIO_CLOSE)
in async_close directly.
+/* The asynchronous unit keeps the currently active PDT around.
+ This function changes that to the current one. */
+
+void
+enqueue_data_transfer_init (async_unit *au, st_parameter_dt *dt, int read_flag)
+{
+ st_parameter_dt *new = xmalloc (sizeof (st_parameter_dt));
XNEW (st_parameter_dt);
+ transfer_queue *tq = xmalloc (sizeof (transfer_queue));
XNEW (transfer_queue);
+
+ memcpy ((void *) new, (void *) dt, sizeof (st_parameter_dt));
+
+ NOTE ("dt->internal_unit_desc = %p", dt->internal_unit_desc);
+ NOTE ("common.flags & mask = %d", dt->common.flags & IOPARM_LIBRETURN_MASK);
+ tq->next = NULL;
+ tq->type = AIO_DATA_TRANSFER_INIT;
+ tq->read_flag = read_flag;
+ tq->has_id = 0;
ah, that should be bool, not _Bool and hence s/0/false/ and s/1/true/
here and elsewhere when storing to has_id.
since read_flag seems to be a boolean too, i'd
unsigned has_id : 1;
unsiged read_flag : 1;
fwiw.
+ tq->new_pdt = new;
+ LOCK (&au->lock);
+
+ if (!au->tail)
+a
Cleanup tree merging
Hi,
while dropping streaming of now unnecesary fields I forgot to update lto.c
side. This patch removes few checks form tree merging that will hopefully
make it bit faster. While doing that I also turned DECL_ASSEMBLER_NAME
check to use DECL_ASSEMBLER_NAME_RAW.
lto-bootstraped/regtested x86_64-linux.
OK?
Honza
* lto.c (mentions_vars_p_function): Do not check DECL_ARGUMENTS and
VINDEX.
(mentions_vars_p_field_decl): Do not check DECL_FCONTEXT.
(mentions_vars_p_binfo): Do not check BASE_ACCESSES, VIRTUALS and
VPTR_FIELD.
(compare_tree_sccs_1): Do no check BLOCKs; do not check
BINFO_BASE_ACCESSES; function arguments and results, ORIGINAL_TYPE;
use DECL_ASSEMBLER_NAME_RAW when comparing assembler names;
do not check DECL_FCONTEXT; do not check DECL_VINDEX; do not check
TYPE_STUB_DECL.
(compare_tree_sccs_1): Do not check BINFO_BASE_ACCESS;
BINFO_VPTR_FIELD, DECL_ARGUMENTS, DECL_VINDEX, DECL_FCONTEXT.
Index: lto/lto.c
===
--- lto/lto.c (revision 263989)
+++ lto/lto.c (working copy)
@@ -614,8 +614,8 @@ mentions_vars_p_function (tree t)
{
if (mentions_vars_p_decl_non_common (t))
return true;
- CHECK_NO_VAR (DECL_ARGUMENTS (t));
- CHECK_NO_VAR (DECL_VINDEX (t));
+ gcc_checking_assert (!DECL_ARGUMENTS (t));
+ gcc_checking_assert (!DECL_VINDEX (t));
CHECK_VAR (DECL_FUNCTION_PERSONALITY (t));
return false;
}
@@ -631,7 +630,7 @@ mentions_vars_p_field_decl (tree t)
CHECK_NO_VAR (DECL_BIT_FIELD_TYPE (t));
CHECK_NO_VAR (DECL_QUALIFIER (t));
CHECK_NO_VAR (DECL_FIELD_BIT_OFFSET (t));
- CHECK_NO_VAR (DECL_FCONTEXT (t));
+ gcc_checking_assert (!DECL_FCONTEXT (t));
return false;
}
@@ -672,11 +671,8 @@ mentions_vars_p_binfo (tree t)
return true;
CHECK_VAR (BINFO_VTABLE (t));
CHECK_NO_VAR (BINFO_OFFSET (t));
- CHECK_NO_VAR (BINFO_VIRTUALS (t));
- CHECK_NO_VAR (BINFO_VPTR_FIELD (t));
- n = vec_safe_length (BINFO_BASE_ACCESSES (t));
- for (i = 0; i < n; i++)
-CHECK_NO_VAR (BINFO_BASE_ACCESS (t, i));
+ gcc_checking_assert (!BINFO_VIRTUALS (t));
+ gcc_checking_assert (!BINFO_VPTR_FIELD (t));
/* Do not walk BINFO_INHERITANCE_CHAIN, BINFO_SUBVTT_INDEX
and BINFO_VPTR_INDEX; these are used by C++ FE only. */
n = BINFO_N_BASE_BINFOS (t);
@@ -1210,7 +1206,7 @@ compare_tree_sccs_1 (tree t1, tree t2, t
/* BLOCKs are function local and we don't merge anything there, so
simply refuse to merge. */
if (CODE_CONTAINS_STRUCT (code, TS_BLOCK))
-return false;
+gcc_unreachable ();
if (CODE_CONTAINS_STRUCT (code, TS_TRANSLATION_UNIT_DECL))
if (strcmp (TRANSLATION_UNIT_LANGUAGE (t1),
@@ -1227,9 +1223,8 @@ compare_tree_sccs_1 (tree t1, tree t2, t
return false;
if (CODE_CONTAINS_STRUCT (code, TS_BINFO))
-if (vec_safe_length (BINFO_BASE_ACCESSES (t1))
- != vec_safe_length (BINFO_BASE_ACCESSES (t2)))
- return false;
+gcc_assert (!vec_safe_length (BINFO_BASE_ACCESSES (t1))
+ && !vec_safe_length (BINFO_BASE_ACCESSES (t2)));
if (CODE_CONTAINS_STRUCT (code, TS_CONSTRUCTOR))
compare_values (CONSTRUCTOR_NELTS);
@@ -1362,23 +1357,17 @@ compare_tree_sccs_1 (tree t1, tree t2, t
{
if (code == FUNCTION_DECL)
{
- tree a1, a2;
- for (a1 = DECL_ARGUMENTS (t1), a2 = DECL_ARGUMENTS (t2);
- a1 || a2;
- a1 = TREE_CHAIN (a1), a2 = TREE_CHAIN (a2))
- compare_tree_edges (a1, a2);
- compare_tree_edges (DECL_RESULT (t1), DECL_RESULT (t2));
+ gcc_checking_assert (!DECL_ARGUMENTS (t1));
+ gcc_checking_assert (!DECL_RESULT (t1));
}
else if (code == TYPE_DECL)
- compare_tree_edges (DECL_ORIGINAL_TYPE (t1), DECL_ORIGINAL_TYPE (t2));
+ gcc_checking_assert (!DECL_ORIGINAL_TYPE (t1));
}
if (CODE_CONTAINS_STRUCT (code, TS_DECL_WITH_VIS))
{
- /* Make sure we don't inadvertently set the assembler name. */
- if (DECL_ASSEMBLER_NAME_SET_P (t1))
- compare_tree_edges (DECL_ASSEMBLER_NAME (t1),
- DECL_ASSEMBLER_NAME (t2));
+ compare_tree_edges (DECL_ASSEMBLER_NAME_RAW (t1),
+ DECL_ASSEMBLER_NAME_RAW (t2));
}
if (CODE_CONTAINS_STRUCT (code, TS_FIELD_DECL))
@@ -1389,14 +1378,14 @@ compare_tree_sccs_1 (tree t1, tree t2, t
DECL_BIT_FIELD_REPRESENTATIVE (t2));
compare_tree_edges (DECL_FIELD_BIT_OFFSET (t1),
DECL_FIELD_BIT_OFFSET (t2));
- compare_tree_edges (DECL_FCONTEXT (t1), DECL_FCONTEXT (t2));
+ gcc_checking_assert (!DECL_FCONTEXT (t1));
}
if (CODE_CONTAINS_STRUCT (code, TS_FUNCTION_DECL))
{
compare_tree_edges (DECL_FUNCTION_PERSONALITY (t1),
DECL_FUNCTION_PERSONALITY (t2));
- compare_tree_edges (DECL_VINDEX (t1), DECL_VINDEX (t2));
Re: [PATCH] Use complete_array_type on flexible array member initializers
On 08/26/2018 02:52 AM, Bernd Edlinger wrote:
> On 08/26/18 07:36, Jeff Law wrote:
>> On 08/24/2018 07:13 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>>
>>> This patch prevents init values of STRING_CST and braced
>>> array initializers to reach the middle-end with incomplete
>>> type.
>>>
>>> This will allow further simplifications in the middle-end,
>>> and address existing issues with STRING_CST in a correct
>>> way.
>>>
>>>
>>>
>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>> Is it OK for trunk?
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>>>
>>> patch-flexarray.diff
>>>
>>>
>>> gcc:
>>> 2018-08-24 Bernd Edlinger
>>>
>>> * varasm.c (output_constructor_regular_field): Check TYPE_SIZE_UNIT of
>>> the init value.
>>>
>>> c-family:
>>> 2018-08-24 Bernd Edlinger
>>>
>>> * c-common.c (complete_flexible_array_elts): New helper function.
>>> * c-common.h (complete_flexible_array_elts): Declare.
>>>
>>> c:
>>> 2018-08-24 Bernd Edlinger
>>>
>>> * c-decl.c (finish_decl): Call complete_flexible_array_elts.
>>>
>>> cp:
>>> 2018-08-24 Bernd Edlinger
>>>
>>> * decl.c (check_initializer): Call complete_flexible_array_elts.
>>>
>>>
>>> diff -Npur gcc/c/c-decl.c gcc/c/c-decl.c
>>> --- gcc/c/c-decl.c 2018-08-21 08:17:41.0 +0200
>>> +++ gcc/c/c-decl.c 2018-08-24 12:06:21.374892294 +0200
>>> @@ -5035,6 +5035,8 @@ finish_decl (tree decl, location_t init_
>>> if (init && TREE_CODE (init) == CONSTRUCTOR)
>>> add_flexible_array_elts_to_size (decl, init);
>>>
>>> + complete_flexible_array_elts (DECL_INITIAL (decl));
>>> +
>>> if (DECL_SIZE (decl) == NULL_TREE && TREE_TYPE (decl) !=
>>> error_mark_node
>>> && COMPLETE_TYPE_P (TREE_TYPE (decl)))
>>> layout_decl (decl, 0);
>>> diff -Npur gcc/c-family/c-common.c gcc/c-family/c-common.c
>>> --- gcc/c-family/c-common.c 2018-08-17 05:02:11.0 +0200
>>> +++ gcc/c-family/c-common.c 2018-08-24 12:45:56.559011703 +0200
>>> @@ -6427,6 +6427,28 @@ complete_array_type (tree *ptype, tree i
>>> return failure;
>>> }
>>>
>>> +/* INIT is an constructor of a structure with a flexible array member.
>>> + Complete the flexible array member with a domain based on it's value.
>>> */
>>> +void
>>> +complete_flexible_array_elts (tree init)
>>> +{
>>> + tree elt, type;
>>> +
>>> + if (init == NULL_TREE || TREE_CODE (init) != CONSTRUCTOR)
>>> +return;
>>> +
>>> + if (vec_safe_is_empty (CONSTRUCTOR_ELTS (init)))
>>> +return;
>>> +
>>> + elt = CONSTRUCTOR_ELTS (init)->last ().value;
>>> + type = TREE_TYPE (elt);
>>> + if (TREE_CODE (type) == ARRAY_TYPE
>>> + && TYPE_SIZE (type) == NULL_TREE)
>>> +complete_array_type (&TREE_TYPE (elt), elt, false);
>>> + else
>>> +complete_flexible_array_elts (elt);
>>> +}
>> Shouldn't this be handled in c-decl.c by the call to
>> add_flexible_array_elts_to_size?Why the recursion when the
>> CONSTRUCTOR_ELT isn't an array type?
>>
>
> There are tests in the test suite that use something like that:
> struct {
>union {
> struct {
> int a;
> char b[];
> };
> struct {
> char x[32];
> };
>};
> } u = { { { 1, "test" } } };
>
> So it fails to go through add_flexible_array_elts_to_size.
Huh? We get into add_flexible_array_elts_to_size just fine. Using your
testcase above:
Breakpoint 3, add_flexible_array_elts_to_size (decl=0x77ff6ab0,
init=0x7fffe9f3edc8) at /home/gcc/GIT-3/gcc/gcc/c/c-decl.c:4617
4617 if (vec_safe_is_empty (CONSTRUCTOR_ELTS (init)))
(gdb) p debug_tree (decl)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7fffe9f35498
fields
BLK j.c:10:4 size unit-size
align:32 warn_if_not_align:0 offset_align 128
offset
bit-offset context
>
chain >
public static BLK j.c:11:3 size
unit-size
align:32 warn_if_not_align:0 initial >
So I'm a bit confused. It seems to go through
add_flexible_array_elts_to_size in my limited testing.
Given how closely complete_flexible_array_elts is to
add_flexible_array_elts_to_size I can't help but continue to wonder if
we're really papering over a problem in add_flexible_array_elts_to_size.
But it may also be the case that the recursive needs to handle the
CONSTRUCTORS embedded within other CONSTRUCTORS mean we want two routines.
Basically I want to see a rationale why we want/need two routines here.
> I am not sure what happens if the string is larger than 32 byte.
> The test suite does not do that.
> Well I just tried, while writing those lines:
>
> struct {
> union {
>struct {
> int a;
> char b[];
>};
>struct {
> char x[4];
>};
> };
> } u = { { { 1, "test" } } };
>
> =>
>
> .file "t.c"
> .text
> .globl u
> .data
> .align 4
> .type u, @object
> .size u, 4
> u:
> .long 1
> .string "test"
> .ident "GCC: (GNU) 9.0.0 2
PING: Re: lightweight class to wide int ranges in VRP and friends
Forwarded Message
Subject: Re: lightweight class to wide int ranges in VRP and friends
Date: Fri, 24 Aug 2018 13:40:29 -0400
From: Aldy Hernandez
To: Richard Biener
CC: GCC Patches
On 08/24/2018 06:32 AM, Richard Biener wrote:
On Wed, Aug 15, 2018 at 7:31 PM Aldy Hernandez wrote:
I kept seeing the same patterns over and over in all this re-factoring:
1. extract value_range constants into pairs of wide ints
2. mimic symbolics as [-MIN, +MAX] (most of the time :))
3. perform some wide int operation on the wide int range
4. convert back to a value range
So I've decided to clean this up even more. Instead of passing a pair
of wide ints plus sign, precision, and god knows what to every
wide_int_range_* function, I've implemented a lighweight class
(wi_range) for a pair of wide ints. It is not meant for long term
storage, but even so its footprint is minimal.
The only extra bits are another 64-bit word per pair for keeping
attributes such as precision, sign, overflow_wraps, and a few other
things we'll need shortly. In reality we only need one set of
attributes for both sets of pairs, so we waste one 64-bit word. I don't
care. They're short lived, and the resulting code looks an awful lot
nicer. For example, the shift code gets rewritten from this:
if (range_int_cst_p (&vr1)
&& !vrp_shift_undefined_p (vr1, prec))
{
if (code == RSHIFT_EXPR)
{
if (vr0.type != VR_RANGE || symbolic_range_p (&vr0))
{
vr0.type = type = VR_RANGE;
vr0.min = vrp_val_min (expr_type);
vr0.max = vrp_val_max (expr_type);
}
extract_range_from_multiplicative_op (vr, code, &vr0, &vr1);
return;
}
else if (code == LSHIFT_EXPR
&& range_int_cst_p (&vr0))
{
wide_int res_lb, res_ub;
if (wide_int_range_lshift (res_lb, res_ub, sign, prec,
wi::to_wide (vr0.min),
wi::to_wide (vr0.max),
wi::to_wide (vr1.min),
wi::to_wide (vr1.max),
TYPE_OVERFLOW_UNDEFINED (expr_type),
TYPE_OVERFLOW_WRAPS (expr_type)))
{
min = wide_int_to_tree (expr_type, res_lb);
max = wide_int_to_tree (expr_type, res_ub);
set_and_canonicalize_value_range (vr, VR_RANGE,
min, max, NULL);
return;
}
}
}
set_value_range_to_varying (vr);
into this:
wi_range w0 (&vr0, expr_type);
wi_range w1 (&vr1, expr_type);
if (!range_int_cst_p (&vr1)
|| wi_range_shift_undefined_p (w1)
|| (code == LSHIFT_EXPR
&& !range_int_cst_p (&vr0)))
{
vr->set_varying ();
return;
}
bool success;
if (code == RSHIFT_EXPR)
success = wi_range_multiplicative_op (res, code, w0, w1);
else
success = wi_range_lshift (res, w0, w1);
if (success)
vr->set_and_canonicalize (res, expr_type);
else
vr->set_varying ();
return;
not sure whether I like the munging of lshift and right shift (what exactly gets
done is less clear in your version ...). Having a light-weigth class for
the wi_range_ parameters is nice though.
No worries. I'm not emotionally attached to munging them :).
I also munged together the maybe/mustbe nonzero_bits into one structure.
Finally, I've pontificated that wide_int_range_blah is too much typing.
Everyone's RSI will thank me for rewriting the methods as wi_range_blah.
I've tried to keep the functionality changes to a minimum. However,
there are some slight changes where I treat symbolics and VR_VARYING as
[MIN, MAX] and let the constant code do its thing. It is considerably
easier to read.
I am finally happy with the overall direction of this. If this and the
last one are acceptable, I think I only need to clean MIN/MAX_EXPR and
ABS_EXPR and I'm basically done with what I need going forward.
Phew...
How does this look?
+struct wi_range
+{
+ wide_int min;
+ wide_int max;
+ /* This structure takes one additional 64-bit word apart from the
+ min/max bounds above. It is laid out so that PRECISION and SIGN
+ can be accessed without any bit twiddling, since they're the most
+ commonly accessed fields. */
+ unsigned short precision;
+ bool empty_p:1;
+ bool pointer_type_p:1;
+ bool overflow_wraps:1;
+ bool overflow_undefined:1;
+ signop sign;
isn't precision already available in min.get_precision () which is
required to be equal to max.get_preci
