RE: [PATCH v3] doc: change 'make check-g++' to 'make check-c++' in install.texi
Hi, Jason > On 9/9/20 6:25 AM, Hu Jiangping wrote: > > This patch check the command 'make check-g++' to 'make check-c++' in > > install.texi since there is no 'make check-g++' target in the object > > directory. > > make check-g++ works fine for me in the object directory. And > gcc/cp/Make-lang.in includes Oh, there might be something wrong with my execute flow or configuration. I run 'make check-g++' as the following flow: 1) move to object directory & run configure script 2) run make -j8 3) run make check-g++ It give the following output: # make check-g++ make: *** No rule to make target 'check-g++'. Stop. If the flow is OK, the reason must be in configuration, then it will become a little difficult to determine. However I'm not in a hurry to solve this problem, I can move to the gcc subdirectory to run the tests that I want to. > > > # 'make check' in gcc/ looks for check-c++, as do all toplevel C++- > related > > # check targets. However, our DejaGNU framework requires 'check-g++' as > its > > # entry point. We feed the former to the latter here. > > check-c++ : check-g++ > > So this change doesn't seem like an improvement. OK. Thanks anyway. Regards! Hujp > > Jason > >
[PATCH v3] doc: change 'make check-g++' to 'make check-c++' in install.texi
This patch check the command 'make check-g++' to 'make check-c++' in
install.texi since there is no 'make check-g++' target in the object
directory. It also adds some description in the above text, to clarity
and emphasis the difference of the 'make check-' targets in
between object directory and the gcc subdirectory.
The earlier patch discussion is as follows:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552761.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553307.html
Ok for master?
Regards!
Hujp
---
gcc/doc/install.texi | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5330bf3bb29..0a6a3271757 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2964,10 +2964,13 @@ on a simulator as described at
@uref{http://gcc.gnu.org/simtest-howto.html}.
In order to run sets of tests selectively, there are targets
@samp{make check-gcc} and language specific @samp{make check-c},
-@samp{make check-c++}, @samp{make check-d} @samp{make check-fortran},
+@samp{make check-c++}, @samp{make check-d}, @samp{make check-fortran},
@samp{make check-ada}, @samp{make check-objc}, @samp{make check-obj-c++},
@samp{make check-lto}
-in the @file{gcc} subdirectory of the object directory. You can also
+in both the object directory and the @file{gcc} subdirectory of the
+object directory. Note these targets in the object directory will do
+both the language tests and the related library tests while in the @file{gcc}
+subdirectory of the object directory will do only language tests. You can also
just run @samp{make check} in a subdirectory of the object directory.
@@ -2978,11 +2981,11 @@ testsuite is to use
make check-gcc RUNTESTFLAGS="execute.exp @var{other-options}"
@end smallexample
-Likewise, in order to run only the @command{g++} ``old-deja'' tests in
+Likewise, in order to run only the @command{c++} ``old-deja'' tests in
the testsuite with filenames matching @samp{9805*}, you would use
@smallexample
-make check-g++ RUNTESTFLAGS="old-deja.exp=9805* @var{other-options}"
+make check-c++ RUNTESTFLAGS="old-deja.exp=9805* @var{other-options}"
@end smallexample
The file-matching expression following @var{filename}@command{.exp=} is treated
@@ -2991,8 +2994,8 @@ may be passed, although any whitespace must either be
escaped or surrounded by
single quotes if multiple expressions are desired. For example,
@smallexample
-make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c
@var{other-options}"
-make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c'
@var{other-options}"
+@dots{}"old-deja.exp=9805*\ virtual2.c @var{other-options}"
+@dots{}"'old-deja.exp=9805* virtual2.c' @var{other-options}"
@end smallexample
The @file{*.exp} files are located in the testsuite directories of the GCC
@@ -3010,10 +3013,10 @@ You can pass multiple options to the testsuite using the
work outside the makefiles. For example,
@smallexample
-make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
+@dots{}"--target_board=unix/-O3/-fmerge-constants"
@end smallexample
-will run the standard @command{g++} testsuites (``unix'' is the target name
+will run the standard @command{c++} testsuites (``unix'' is the target name
for a standard native testsuite situation), passing
@samp{-O3 -fmerge-constants} to the compiler on every test, i.e.,
slashes separate options.
--
2.17.1
RE: [PATCH] Makefile.tpl: Add check-g++
Hi, Richard > On Tue, Sep 8, 2020 at 11:35 AM Hu Jiangping > wrote: > > > > This patch add a new check-g++ target to the Makefile under toplevel, > > as synonym of the check-c++ target. > > > > It is to be consistent with the check-g++ target under the gcc > > subdirectory. And because check-gcc can be performed under toplevel, > > it is very possible that check-g++ may be performed under toplevel, > > but now it gives 'No rule to make target.' error. > > I don't think this is correct. The toplevel check-gcc is not a simple > alias for gcc/ check-gcc, instead it is for the whole gcc/ subdirectory > checks. Thanks for reply. Yes, I know what toplevel check-gcc do, and the difference with gcc / check-gcc. IIUC you mean if we add toplevel check-g++, it will make the toplevel check-gcc and check-g++ a little strange, because toplevel check-gcc is not only for c, while toplevel check-g++ is only for c++. I agree with you on this point. And I thought about that before. I just thought that toplevel check-g++ is easy to be executed incorrectly, so can we make it do some right things as misunderstood. As for whether the meanings of check-gcc and check-g++ are inconsistent, it may not be that important, or we could modify the document https://gcc.gnu.org/install/test.html to describe what they actually do. Thanks again. I agree with you more now. Regards! Hujp > > Richard. > > > > > ChangeLog: > > 2020-09-08 Hu Jiangping > > > > Makefile.tpl (check-g++): New target. As synonym of check-c++. > > Makefile.in: Regenerated. > > > > Bootstraped on aarch64. Ok for master? > > > > Regards! > > Hujp > > > > --- > > Makefile.in | 3 +++ > > Makefile.tpl | 3 +++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/Makefile.in b/Makefile.in > > index 36e369df6e7..35b57d5af21 100644 > > --- a/Makefile.in > > +++ b/Makefile.in > > @@ -4,6 +4,9 @@ check-gcc-d: > > check-d: check-gcc-d check-target-libphobos > > > > > > +.PHONY: check-g++ > > +check-g++: check-c++ > > + > > # The gcc part of install-no-fixedincludes, which relies on an intimate > > # knowledge of how a number of gcc internal targets (inter)operate. > Delegate. > > .PHONY: gcc-install-no-fixedincludes > > diff --git a/Makefile.tpl b/Makefile.tpl > > index efed1511750..6dfe3c9caca 100644 > > --- a/Makefile.tpl > > +++ b/Makefile.tpl > > @@ -1542,6 +1542,9 @@ check-gcc-[+language+]: > > check-[+language+]: check-gcc-[+language+][+ FOR lib-check-target +] [+ > lib-check-target +][+ ENDFOR lib-check-target +] > > [+ ENDFOR languages +] > > > > +.PHONY: check-g++ > > +check-g++: check-c++ > > + > > # The gcc part of install-no-fixedincludes, which relies on an intimate > > # knowledge of how a number of gcc internal targets (inter)operate. > Delegate. > > .PHONY: gcc-install-no-fixedincludes > > -- > > 2.17.1 > > > > > > >
RE: [PATCH v2] doc: add 'cd' command before 'make check-gcc' command in install.texi
Hi, H-P
> > > On Sat, 29 Aug 2020, Hu Jiangping wrote:
> > >
> > > > This patch add 'cd' command before 'make check-gcc' command
> > > > when run the testsuite on selected tests.
> > >
> > > No, don't do that; those targets work fine from the toplevel
> > > too, and then include the language libs.
> > Yes, I know that 'make check-gcc' work well from the toplevel,
> > but 'make check-g++' does not. Is there anything wrong with
> > the Makefile?
>
> IIUC check-g++ is somewhat a historic artefact, but for
> consistency it should be added to the toplevel Makefile too as
> a synonym for check-c++.
Thanks for your suggestion. I'm submitting a patch for that.
Any advice will be appreciated.
>
> > i.e.:
> > Note that if run 'make check-testsuite' from the object directory,
> > not only the tests under gcc subdirectory but also the tests under
> > the target libriaries will be performed.
>
> (There's no "make check-testsuite".)
Oh, I mean 'check-@var{testsuite}'.
If the patch for Makefile is ok, then the patch here will be modified
accordingly.
For example, it is no need to add cd objdir/gcc before the ‘make
check-’
commands, but in the text above the commands we need to describe the difference
between the targets in the gcc subdirectory and the object directory.
Regards!
Hujp
>
> > What do you think?
>
> I think that after re-reading the patch, I retract my objection,
> thanks.
>
> FWIW, note also "check-gcc-" where LANGUAGE="c, c++,
> fortran, ada" which do consider the library testsuite.
>
> brgds, H-P
>
[PATCH] Makefile.tpl: Add check-g++
This patch add a new check-g++ target to the Makefile under toplevel, as synonym of the check-c++ target. It is to be consistent with the check-g++ target under the gcc subdirectory. And because check-gcc can be performed under toplevel, it is very possible that check-g++ may be performed under toplevel, but now it gives 'No rule to make target.' error. ChangeLog: 2020-09-08 Hu Jiangping Makefile.tpl (check-g++): New target. As synonym of check-c++. Makefile.in: Regenerated. Bootstraped on aarch64. Ok for master? Regards! Hujp --- Makefile.in | 3 +++ Makefile.tpl | 3 +++ 2 files changed, 6 insertions(+) diff --git a/Makefile.in b/Makefile.in index 36e369df6e7..35b57d5af21 100644 --- a/Makefile.in +++ b/Makefile.in @@ -4,6 +4,9 @@ check-gcc-d: check-d: check-gcc-d check-target-libphobos +.PHONY: check-g++ +check-g++: check-c++ + # The gcc part of install-no-fixedincludes, which relies on an intimate # knowledge of how a number of gcc internal targets (inter)operate. Delegate. .PHONY: gcc-install-no-fixedincludes diff --git a/Makefile.tpl b/Makefile.tpl index efed1511750..6dfe3c9caca 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -1542,6 +1542,9 @@ check-gcc-[+language+]: check-[+language+]: check-gcc-[+language+][+ FOR lib-check-target +] [+ lib-check-target +][+ ENDFOR lib-check-target +] [+ ENDFOR languages +] +.PHONY: check-g++ +check-g++: check-c++ + # The gcc part of install-no-fixedincludes, which relies on an intimate # knowledge of how a number of gcc internal targets (inter)operate. Delegate. .PHONY: gcc-install-no-fixedincludes -- 2.17.1
RE: [PATCH v2] doc: add 'cd' command before 'make check-gcc' command in install.texi
Hi, H-P
Thanks for comment.
> On Sat, 29 Aug 2020, Hu Jiangping wrote:
>
> > This patch add 'cd' command before 'make check-gcc' command
> > when run the testsuite on selected tests.
>
> No, don't do that; those targets work fine from the toplevel
> too, and then include the language libs.
Yes, I know that 'make check-gcc' work well from the toplevel,
but 'make check-g++' does not. Is there anything wrong with
the Makefile?
I pasted the original error in the v1 submitting text.
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552761.html
>
> > Richard and I agree it would be good for clarity and
> > emphasis to have the cd in the example as well, although
> > the text above the example was trying to restrict that to
> > objdir/gcc.
>
> Aha, I guess you misinterpreted the existing "cd @var{objdir};
> make -k check", because I see no /gcc there.
Does the "cd @var{objdir}; make -k check" mean to execute command
from the toplevel.
I understand the context like this:
1. We can execute 'make -k check' from the toplevel to run all testsuites
2. And also, We can execute 'make check-gcc' from gcc subdirectory
to run selected targets
3. And 'A more selective way', We can execute command with 'RUNTESTFLAGS'
option to run selected test(s).
"In order to run sets of tests selectively, there are targets
@samp{make check-gcc}, @samp{make check-g++} and language specific
@samp{make check-c},
@samp{make check-c++}, @samp{make check-d}, @samp{make check-fortran},
@samp{make check-ada}, @samp{make check-objc}, @samp{make
check-obj-c++},
@samp{make check-lto}
in the @file{gcc} subdirectory of the object directory. You can also
just run @samp{make check} in a subdirectory of the object directory."
I think the text above the 'make check-gcc' command implies point 2.
So, if the following commands which are examples of point 3 are also
executed from gcc subdirectory, it will make the context more logical
(The tests to be performed are more specific than point 2).
But it does not mean the commands must be executed from gcc subdirectory.
If anyone wants to execute the testsuites including the target libraries,
he should refer to other documents, or directly the Makefile under toplevel.
Or we can make a note here to illustrate that.
i.e.:
Note that if run 'make check-testsuite' from the object directory,
not only the tests under gcc subdirectory but also the tests under
the target libriaries will be performed.
What do you think?
Regards!
Hujp
>
> Please remove the /gcc from the patch.
>
> Some .exp just exist in the gcc dir, but that's not
> the point of these examples and the extra iteration from the
> toplevel doesn't take more than a second or two. The bigger
> risk is missing testing in the target libraries.
>
> (Incidentally, while GNU make is required such that "-C objdir"
> would be equivalent, for newcomers I agree the "cd" is
> clearer in examples.)
>
> brgds, H-P
>
RE: [wwwdocs PATCH] projects/tree-ssa: add note for deprecated flag -ftree-vectorizer-verbose in vectorization.html
> I think the pages under gcc.gnu.org/projects/ are all hopelessly > out-of-date and more recent (but still usually out-of-date) info > is found on the wiki. > > So I'm not sure these kind of changes make sense. > > Eventually we should remove those pages? Or do we want > to keep them for historical purposes (and edit them to reflect > that purpose)? > Thanks for reply! Yes. This is indeed a question. We cannot ensure that anyone who modifies the code can fully update the relevant documentation. After a long time, the documentation may contain errors. It is also not realistic to confirm those outdated documents in detail and correct all the errors. On the other hand, for me, sometimes even if I know that a document is out of date, I still read it because I think there may be some useful information in it. In this case, if I am troubled by an error in the document, I will want to modify it to prevent others who have the same idea as me from being troubled. In addition to deleting outdated documents, I don't know if there is any other better way. Or, everyone should reach a consensus not to read outdated documents. Regards! Hujp > > Regards! > > Hujp > > > > --- > > htdocs/projects/tree-ssa/vectorization.html | 8 +++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/htdocs/projects/tree-ssa/vectorization.html > b/htdocs/projects/tree-ssa/vectorization.html > > index 22d136c0..ab07eb28 100644 > > --- a/htdocs/projects/tree-ssa/vectorization.html > > +++ b/htdocs/projects/tree-ssa/vectorization.html > > @@ -13,7 +13,13 @@ > > The goal of this project was to develop a loop and basic block > > vectorizer in GCC, based on the tree-ssa framework. > > It has been completed and the functionality has been part of GCC > > -for years. > > +for years. > > + > > +(Note: The -ftree-vectorizer-verbose flag below is now > > +deprecated. New flag -fopt-info see > +"https://gcc.gnu.org/onlinedocs/gcc/Developer- > Options.html#index-fopt-info"> > > + https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index- > fopt-info) > > + > > > > Table of Contents > > > > -- > > 2.17.1 > > > > > > >
[wwwdocs PATCH] projects/tree-ssa: add note for deprecated flag -ftree-vectorizer-verbose in vectorization.html
Although vectorization.html is not up-to-date, it is still easy to be searched, and the deprecated flag in it may confuse users. This patch simply adds a note to the head of the page, hoping to help users who read it. OK for master? Regards! Hujp --- htdocs/projects/tree-ssa/vectorization.html | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/htdocs/projects/tree-ssa/vectorization.html b/htdocs/projects/tree-ssa/vectorization.html index 22d136c0..ab07eb28 100644 --- a/htdocs/projects/tree-ssa/vectorization.html +++ b/htdocs/projects/tree-ssa/vectorization.html @@ -13,7 +13,13 @@ The goal of this project was to develop a loop and basic block vectorizer in GCC, based on the tree-ssa framework. It has been completed and the functionality has been part of GCC -for years. +for years. + +(Note: The -ftree-vectorizer-verbose flag below is now +deprecated. New flag -fopt-info see https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-fopt-info;> + https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-fopt-info) + Table of Contents -- 2.17.1
RE: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
Hi, Jakub Thank you for your detailed explanation. I will try to compare the results of rtl expand as Richard have suggested, to see if I can find anything. May be I can make another patch. Thanks again. Regards! Hujp > On Thu, Aug 27, 2020 at 11:13:50AM +0000, Hu, Jiangping wrote: > > I'm not sure about if the case should fail. > > So, I add Jakub who committed this testcase. > > > > I thought the case should success, but for changes of gcc of > > years, now it failed. So I think that may be some optimization > > are unnecessary for this testcase, and I found the FRE. > > The intent of the guality testsuite is to track regressions in debug info > quality. Because the testing matrix is huge > (different targets x different -O* options x different gdb versions), > it isn't really feasible to keep xfails for them accurately, so all we > care > about is whether we don't regress compared to older gcc releases for the > same target, same -O* options and same gdb version. > If we do regress e.g. because of some added optimization, the intent is > that it is analyzed why it regressed and if possible some improvements > in the debug info generation are added to deal with the optimization if > possible. > So adding -fno-tree-* is not the right solution, the majority of people > will > not use such options in their codes and so they will observe the debug > info > quality degradation there. > > Jakub > >
[PATCH v2] doc: add 'cd' command before 'make check-gcc' command in install.texi
This patch add 'cd' command before 'make check-gcc' command
when run the testsuite on selected tests.
Richard and I agree it would be good for clarity and
emphasis to have the cd in the example as well, although
the text above the example was trying to restrict that to
objdir/gcc.
Tested on x86_64. OK for master?
Regards!
Hujp
---
gcc/doc/install.texi | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5330bf3bb29..1560615bf3c 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2963,8 +2963,9 @@ on a simulator as described at
@uref{http://gcc.gnu.org/simtest-howto.html}.
@section How can you run the testsuite on selected tests?
In order to run sets of tests selectively, there are targets
-@samp{make check-gcc} and language specific @samp{make check-c},
-@samp{make check-c++}, @samp{make check-d} @samp{make check-fortran},
+@samp{make check-gcc}, @samp{make check-g++} and language specific
+@samp{make check-c},
+@samp{make check-c++}, @samp{make check-d}, @samp{make check-fortran},
@samp{make check-ada}, @samp{make check-objc}, @samp{make check-obj-c++},
@samp{make check-lto}
in the @file{gcc} subdirectory of the object directory. You can also
@@ -2975,14 +2976,14 @@ A more selective way to just run all @command{gcc}
execute tests in the
testsuite is to use
@smallexample
-make check-gcc RUNTESTFLAGS="execute.exp @var{other-options}"
+cd @var{objdir}/gcc; make check-gcc RUNTESTFLAGS="execute.exp
@var{other-options}"
@end smallexample
Likewise, in order to run only the @command{g++} ``old-deja'' tests in
the testsuite with filenames matching @samp{9805*}, you would use
@smallexample
-make check-g++ RUNTESTFLAGS="old-deja.exp=9805* @var{other-options}"
+cd @var{objdir}/gcc; make check-g++ RUNTESTFLAGS="old-deja.exp=9805*
@var{other-options}"
@end smallexample
The file-matching expression following @var{filename}@command{.exp=} is treated
@@ -2991,8 +2992,8 @@ may be passed, although any whitespace must either be
escaped or surrounded by
single quotes if multiple expressions are desired. For example,
@smallexample
-make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c
@var{other-options}"
-make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c'
@var{other-options}"
+@dots{}"old-deja.exp=9805*\ virtual2.c @var{other-options}"
+@dots{}"'old-deja.exp=9805* virtual2.c' @var{other-options}"
@end smallexample
The @file{*.exp} files are located in the testsuite directories of the GCC
@@ -3010,7 +3011,7 @@ You can pass multiple options to the testsuite using the
work outside the makefiles. For example,
@smallexample
-make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
+cd @var{objdir}/gcc; make check-g++
RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
@end smallexample
will run the standard @command{g++} testsuites (``unix'' is the target name
@@ -3063,7 +3064,7 @@ make -j@var{N}
check-@var{testsuite}//@var{test-target}/@var{option1}/@var{optio
For example,
@smallexample
-make -j3 check-gcc//sh-hms-sim/@{-m1,-m2,-m3,-m3e,-m4@}/@{,-nofpu@}
+cd @var{objdir}/gcc; make -j3
check-gcc//sh-hms-sim/@{-m1,-m2,-m3,-m3e,-m4@}/@{,-nofpu@}
@end smallexample
will run three concurrent ``make-gcc'' testsuites, eventually testing all
--
2.17.1
RE: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
Hi, Richard, Jakub
Thanks for reply.
I'm not sure about if the case should fail.
So, I add Jakub who committed this testcase.
I thought the case should success, but for changes of gcc of
years, now it failed. So I think that may be some optimization
are unnecessary for this testcase, and I found the FRE.
> Huh well - I guess it should be XFAILed instead? But then we see
> XPASSes. Disabling
> FRE doesn't look correct - we _do_ want the test to succeed here. Did
> you analyze
> why it fails?
Do you mean the reason may be in gcc, not in this testcase?
If so, I'll do more debug.
>
> It looks like we assign 'a' a register at RTL expansion time for -Og
> but do not perform any
> fancy tracking of components of it then. On GIMPLE we assume it's
> eventually
> memory and thus wouldn't bother with any debug stmts.
>
> So it's a genuine FAIL for -Og at least. That said, the logic is simple -
> both
> a.i and a.j need to be available for a.i + a.j to be evaluated. For
> some reasons
> we fail to record where their value resides. For -Og they are in
> %rbp, resp. %rbx.
> But obviously some elaborate DWARF is necessary to convey that info.
I tried -gdwarf options, but it makes no difference.
Jakub, what do you think?
Regards!
Hujp
>
> Richard.
>
> > Regards!
> > hujp
> >
> > ---
> > gcc/testsuite/gcc.dg/guality/sra-1.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/testsuite/gcc.dg/guality/sra-1.c
> b/gcc/testsuite/gcc.dg/guality/sra-1.c
> > index 8ad57cf3f8e..94ea29dd727 100644
> > --- a/gcc/testsuite/gcc.dg/guality/sra-1.c
> > +++ b/gcc/testsuite/gcc.dg/guality/sra-1.c
> > @@ -1,6 +1,6 @@
> > /* PR debug/43983 */
> > /* { dg-do run } */
> > -/* { dg-options "-g -fno-ipa-icf" } */
> > +/* { dg-options "-g -fno-tree-fre -fno-ipa-icf" } */
> >
> > struct A { int i; int j; };
> > struct B { int : 4; int i : 12; int j : 12; int : 4; };
> > --
> > 2.17.1
> >
> >
> >
>
[PATCH] doc: add 'cd' command before 'make check-gcc' command in install.texi
Hi,
This patch add 'cd' command before 'make check-gcc' command
when run the testsuite on selected tests.
I think the implicit meaning of the original text is to
execute the cd command to move to the gcc subdirectory of
the object directory before executing the make command.
However, due to the following reasons, it may cause
confusion if it is not clearly written.
* make check-gcc command also can be executed in
object directory which will run more testcases
than be executed in gcc subdirectory.
* the make check-g++ command below will report
'No rule to make target' error if be executed in
object directory.
Tested on x86_64. OK for master?
Regards!
hujp
---
gcc/doc/install.texi | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5330bf3bb29..fd4409921ee 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2975,6 +2975,7 @@ A more selective way to just run all @command{gcc}
execute tests in the
testsuite is to use
@smallexample
+cd @var{objdir}/gcc
make check-gcc RUNTESTFLAGS="execute.exp @var{other-options}"
@end smallexample
--
2.17.1
[PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
This patch add -fno-tree-fre to dg-options in gcc.dg/guality/sra-1.c,
to make the following testcases passed.
FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 32 a[1] == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 43 a.j == 14
The detail error logs like this:
> Spawning: gdb -nx -nw -quiet -batch -x sra-1.gdb ./sra-1.exe
>
> spawn gdb -nx -nw -quiet -batch -x sra-1.gdb ./sra-1.exe
>
> Breakpoint 1 at 0x40074c: file
> /home/build_gcc/gcc-a64fx-1-a/gcc/testsuite/gcc.dg/guality/sra-1.c, line 43.
>
> Breakpoint 1, f3 (k=k@entry=7) at
> /home/build_gcc/gcc-a64fx-1-a/gcc/testsuite/gcc.dg/guality/sra-1.c:43
> 43bar (a.j);/* { dg-final { gdb-test . "a.j" "14" } } */
> $1 =
> $2 = 4
> != 4
Tested on aarch64.
Regards!
hujp
---
gcc/testsuite/gcc.dg/guality/sra-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/guality/sra-1.c
b/gcc/testsuite/gcc.dg/guality/sra-1.c
index 8ad57cf3f8e..94ea29dd727 100644
--- a/gcc/testsuite/gcc.dg/guality/sra-1.c
+++ b/gcc/testsuite/gcc.dg/guality/sra-1.c
@@ -1,6 +1,6 @@
/* PR debug/43983 */
/* { dg-do run } */
-/* { dg-options "-g -fno-ipa-icf" } */
+/* { dg-options "-g -fno-tree-fre -fno-ipa-icf" } */
struct A { int i; int j; };
struct B { int : 4; int i : 12; int j : 12; int : 4; };
--
2.17.1
[PATCH] doc: add return type for functions in gimple.texi
This patch add the return type for some functions in gimple.texi,
to make the context unified. OK for trunk?
Tested on x86_64.
Regards!
Hujp
---
gcc/doc/gimple.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/gimple.texi b/gcc/doc/gimple.texi
index 5e0fc2e0dc5..f01c3083835 100644
--- a/gcc/doc/gimple.texi
+++ b/gcc/doc/gimple.texi
@@ -831,17 +831,17 @@ expression to a variable.
Return true if g is any of the OpenMP codes.
@end deftypefn
-@deftypefn {GIMPLE function} gimple_debug_begin_stmt_p (gimple g)
+@deftypefn {GIMPLE function} bool gimple_debug_begin_stmt_p (gimple g)
Return true if g is a @code{GIMPLE_DEBUG} that marks the beginning of
a source statement.
@end deftypefn
-@deftypefn {GIMPLE function} gimple_debug_inline_entry_p (gimple g)
+@deftypefn {GIMPLE function} bool gimple_debug_inline_entry_p (gimple g)
Return true if g is a @code{GIMPLE_DEBUG} that marks the entry
point of an inlined function.
@end deftypefn
-@deftypefn {GIMPLE function} gimple_debug_nonbind_marker_p (gimple g)
+@deftypefn {GIMPLE function} bool gimple_debug_nonbind_marker_p (gimple g)
Return true if g is a @code{GIMPLE_DEBUG} that marks a program location,
without any variable binding.
@end deftypefn
--
2.17.1
[PATCH] target: delete unnecessary codes in aarch64.c
Hi,
This patch deletes 2 unnecessary codes in function
aarch64_if_then_else_costs, which were duplicated
where the function starts.
Tested on aarch64. OK for trunk?
Regards!
Hujp
---
gcc/config/aarch64/aarch64.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 7c3ab3eeb1f..a70b2287b2c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11774,8 +11774,6 @@ aarch64_if_then_else_costs (rtx op0, rtx op1, rtx op2,
int *cost, bool speed)
if (speed)
{
machine_mode mode = GET_MODE (XEXP (op1, 0));
- const struct cpu_cost_table *extra_cost
- = aarch64_tune_params.insn_extra_cost;
if (GET_MODE_CLASS (mode) == MODE_INT)
*cost += extra_cost->alu.arith;
--
2.17.1
[PATCH v4] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
Hi!
This patch makes the -falign-foo=0 work as described in the
documentation. Thanks for all the suggestions.
v4: do changes for coding conventions
v3: make change more readable and self-consistent
Changelog:
2020-07-27 Hu Jiangping
PR driver/96247
* opts.c (check_alignment_argument): Set the -falign-Name
on/off flag on and set the -falign-Name string value null,
when the command-line specified argument is zero.
Tested on x86_64.
Regards!
Hujp
---
gcc/opts.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/gcc/opts.c b/gcc/opts.c
index 499eb900643..574b28416fb 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2004,13 +2004,21 @@ parse_and_check_align_values (const char *flag,
}
/* Check that alignment value FLAG for -falign-NAME is valid at a given
- location LOC. */
+ location LOC. OPT_STR points to the stored -falign-NAME=argument and
+ OPT_FLAG points to the associated -falign-NAME on/off flag. */
static void
-check_alignment_argument (location_t loc, const char *flag, const char *name)
+check_alignment_argument (location_t loc, const char *flag, const char *name,
+int *opt_flag, const char **opt_str)
{
auto_vec align_result;
parse_and_check_align_values (flag, name, align_result, true, loc);
+
+ if (align_result.length() >= 1 && align_result[0] == 0)
+{
+ *opt_flag = 1;
+ *opt_str = NULL;
+}
}
/* Print help when OPT__help_ is set. */
@@ -2785,19 +2793,27 @@ common_handle_option (struct gcc_options *opts,
break;
case OPT_falign_loops_:
- check_alignment_argument (loc, arg, "loops");
+ check_alignment_argument (loc, arg, "loops",
+>x_flag_align_loops,
+>x_str_align_loops);
break;
case OPT_falign_jumps_:
- check_alignment_argument (loc, arg, "jumps");
+ check_alignment_argument (loc, arg, "jumps",
+>x_flag_align_jumps,
+>x_str_align_jumps);
break;
case OPT_falign_labels_:
- check_alignment_argument (loc, arg, "labels");
+ check_alignment_argument (loc, arg, "labels",
+>x_flag_align_labels,
+>x_str_align_labels);
break;
case OPT_falign_functions_:
- check_alignment_argument (loc, arg, "functions");
+ check_alignment_argument (loc, arg, "functions",
+>x_flag_align_functions,
+>x_str_align_functions);
break;
case OPT_ftabstop_:
--
2.17.1
RE: [PATCH v3] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
> > This patch makes the -falign-foo=0 work as described in the
> > documentation. Thanks for all the suggestions, Richard and Segher!
>
> Hello.
>
> I'm the author of the original code.
>
> >
> > v3: make change more readable and self-consistent
> > v2: at a high level handles -falign-foo=0 like -falign-foo
> >
> > Regards!
> > Hujp
> >
> > ---
> > gcc/opts.c | 24 +++-
> > 1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/gcc/opts.c b/gcc/opts.c
> > index 499eb900643..dec5ba6d2be 100644
> > --- a/gcc/opts.c
> > +++ b/gcc/opts.c
> > @@ -2007,10 +2007,20 @@ parse_and_check_align_values (const char
> *flag,
> > location LOC. */
> >
> > static void
> > -check_alignment_argument (location_t loc, const char *flag, const char
> *name)
> > +check_alignment_argument (location_t loc,
> > +const char *flag,
> > +const char *name,
> > +int *opt_flag,
> > +const char **opt_str)
> > {
> > auto_vec align_result;
> > parse_and_check_align_values (flag, name, align_result, true, loc);
> > +
> > + if (align_result.length() >= 1 && align_result[0] == 0)
> > + {
> > +*opt_flag = 1;
> > +*opt_str = NULL;
> > + }
>
> Hm, shouldn't the code be placed in parse_and_check_align_values? Note that
> there's
> one another call gcc/toplev.c (parse_N_M).
>
> I bet you likely want to modify result_values in case -falign-foo=0.
> About the -falign-foo=0:m:n2:m3, you can report an error in
> parse_and_check_align_values?
>
Thanks Martin!
Reporting errors may break exist Makefiles and is not as good as handling
-falign-foo=0 like -falign-foo. We have discussed earlier.
And when parse_N_M is called, the values may have been overided by
target code, I think it is inappropriate to report errors at that time.
> Thanks for working on that?
> Btw. what's your use-case that you use the extended syntax of -falign-foo?
> Martin
>
In fact, I was understanding the cpu tuning structure of gcc, and then
when I read the documentation of -falign-foo, I found this problem.
Thanks,
Hujp
> > }
> >
> > /* Print help when OPT__help_ is set. */
> > @@ -2785,19 +2795,23 @@ common_handle_option (struct gcc_options
> *opts,
> > break;
> >
> > case OPT_falign_loops_:
> > - check_alignment_argument (loc, arg, "loops");
> > + check_alignment_argument (loc, arg, "loops",
> > + >x_flag_align_loops, >x_str_align_loops);
> > break;
> >
> > case OPT_falign_jumps_:
> > - check_alignment_argument (loc, arg, "jumps");
> > + check_alignment_argument (loc, arg, "jumps",
> > + >x_flag_align_jumps, >x_str_align_jumps);
> > break;
> >
> > case OPT_falign_labels_:
> > - check_alignment_argument (loc, arg, "labels");
> > + check_alignment_argument (loc, arg, "labels",
> > + >x_flag_align_labels, >x_str_align_labels);
> > break;
> >
> > case OPT_falign_functions_:
> > - check_alignment_argument (loc, arg, "functions");
> > + check_alignment_argument (loc, arg, "functions",
> > + >x_flag_align_functions, >x_str_align_functions);
> > break;
> >
> > case OPT_ftabstop_:
> >
>
>
RE: [PATCH v3] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
Tested on x86_64.
> -Original Message-
> From: Gcc-patches On Behalf Of Hu
> Jiangping
> Sent: Monday, July 27, 2020 3:46 PM
> To: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com;
> seg...@kernel.crashing.org
> Subject: [PATCH v3] driver: fix a problem with implementation of -falign-foo=0
> [PR96247]
>
> Hi!
>
> This patch makes the -falign-foo=0 work as described in the
> documentation. Thanks for all the suggestions, Richard and Segher!
>
> v3: make change more readable and self-consistent
> v2: at a high level handles -falign-foo=0 like -falign-foo
>
> Regards!
> Hujp
>
> ---
> gcc/opts.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/opts.c b/gcc/opts.c
> index 499eb900643..dec5ba6d2be 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -2007,10 +2007,20 @@ parse_and_check_align_values (const char *flag,
> location LOC. */
>
> static void
> -check_alignment_argument (location_t loc, const char *flag, const char
> *name)
> +check_alignment_argument (location_t loc,
> +const char *flag,
> +const char *name,
> +int *opt_flag,
> +const char **opt_str)
> {
>auto_vec align_result;
>parse_and_check_align_values (flag, name, align_result, true, loc);
> +
> + if (align_result.length() >= 1 && align_result[0] == 0)
> + {
> +*opt_flag = 1;
> +*opt_str = NULL;
> + }
> }
>
> /* Print help when OPT__help_ is set. */
> @@ -2785,19 +2795,23 @@ common_handle_option (struct gcc_options
> *opts,
>break;
>
> case OPT_falign_loops_:
> - check_alignment_argument (loc, arg, "loops");
> + check_alignment_argument (loc, arg, "loops",
> + >x_flag_align_loops, >x_str_align_loops);
>break;
>
> case OPT_falign_jumps_:
> - check_alignment_argument (loc, arg, "jumps");
> + check_alignment_argument (loc, arg, "jumps",
> + >x_flag_align_jumps, >x_str_align_jumps);
>break;
>
> case OPT_falign_labels_:
> - check_alignment_argument (loc, arg, "labels");
> + check_alignment_argument (loc, arg, "labels",
> + >x_flag_align_labels, >x_str_align_labels);
>break;
>
> case OPT_falign_functions_:
> - check_alignment_argument (loc, arg, "functions");
> + check_alignment_argument (loc, arg, "functions",
> + >x_flag_align_functions, >x_str_align_functions);
>break;
>
> case OPT_ftabstop_:
> --
> 2.17.1
>
>
[PATCH v3] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
Hi!
This patch makes the -falign-foo=0 work as described in the
documentation. Thanks for all the suggestions, Richard and Segher!
v3: make change more readable and self-consistent
v2: at a high level handles -falign-foo=0 like -falign-foo
Regards!
Hujp
---
gcc/opts.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/gcc/opts.c b/gcc/opts.c
index 499eb900643..dec5ba6d2be 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2007,10 +2007,20 @@ parse_and_check_align_values (const char *flag,
location LOC. */
static void
-check_alignment_argument (location_t loc, const char *flag, const char *name)
+check_alignment_argument (location_t loc,
+const char *flag,
+const char *name,
+int *opt_flag,
+const char **opt_str)
{
auto_vec align_result;
parse_and_check_align_values (flag, name, align_result, true, loc);
+
+ if (align_result.length() >= 1 && align_result[0] == 0)
+ {
+*opt_flag = 1;
+*opt_str = NULL;
+ }
}
/* Print help when OPT__help_ is set. */
@@ -2785,19 +2795,23 @@ common_handle_option (struct gcc_options *opts,
break;
case OPT_falign_loops_:
- check_alignment_argument (loc, arg, "loops");
+ check_alignment_argument (loc, arg, "loops",
+ >x_flag_align_loops, >x_str_align_loops);
break;
case OPT_falign_jumps_:
- check_alignment_argument (loc, arg, "jumps");
+ check_alignment_argument (loc, arg, "jumps",
+ >x_flag_align_jumps, >x_str_align_jumps);
break;
case OPT_falign_labels_:
- check_alignment_argument (loc, arg, "labels");
+ check_alignment_argument (loc, arg, "labels",
+ >x_flag_align_labels, >x_str_align_labels);
break;
case OPT_falign_functions_:
- check_alignment_argument (loc, arg, "functions");
+ check_alignment_argument (loc, arg, "functions",
+ >x_flag_align_functions, >x_str_align_functions);
break;
case OPT_ftabstop_:
--
2.17.1
RE: [PATCH v2] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
> In addition to Segher's comments, I wonder if it would be better > to pass >x_flag_align_foo and >x_str_align_jumps to > check_alignment_argument and do the check there instead. > The condition for whether to do this would then be: > > align_result.length () == 1 && align_result[0] == 0 > > The reason for suggesting that is that it makes the parsing code > more self-consistent, rather than using atoi for this case only. > Thanks, Segher and Richard! I'll make a new patch to do the check in check_alignment_argument, and change the condition of the if statement as follows: align_result.length () >= 1 && align_result[0] == 0 for the input -falign-foo=n:m:n2:m2, according to documentation, if n is zero, use the machine-dependent value. I think the implict meaning is that even if m or n2 or m2 is specified, it should be ignored. Any comments are appreciated! > Looks good otherwise, thanks. > > Richard >
RE: [PATCH v2] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
Add CC to Richard.
> Thanks, Richard!
>
> I think your suggestion is very good, so I made a new patch.
>
> v2: at a high level handles -falign-foo=0 like -falign-foo
> v1: at the target level overides the -falign-foo=0 option values
>
> Obviously, v2 is better than v1. In addition, anthor option
> to reject 0 that discussed in the email and PR96247
> is not as good as the current patch either, I think.
>
> I tested this patch on x86_64, it works well. OK for trunk?
>
> Regards!
> Hujp
>
> ---
> gcc/opts.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/gcc/opts.c b/gcc/opts.c
> index 499eb900643..ed6102cd606 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -2786,18 +2786,38 @@ common_handle_option (struct gcc_options
> *opts,
>
> case OPT_falign_loops_:
>check_alignment_argument (loc, arg, "loops");
> + // fix PR96247
> + if (0 == atoi(arg)) {
> +opts->x_flag_align_loops = true;
> +opts->x_str_align_loops = NULL;
> + }
>break;
>
> case OPT_falign_jumps_:
>check_alignment_argument (loc, arg, "jumps");
> + // fix PR96247
> + if (0 == atoi(arg)) {
> +opts->x_flag_align_jumps = true;
> +opts->x_str_align_jumps = NULL;
> + }
>break;
>
> case OPT_falign_labels_:
>check_alignment_argument (loc, arg, "labels");
> + // fix PR96247
> + if (0 == atoi(arg)) {
> +opts->x_flag_align_labels = true;
> +opts->x_str_align_labels = NULL;
> + }
>break;
>
> case OPT_falign_functions_:
>check_alignment_argument (loc, arg, "functions");
> + // fix PR96247
> + if (0 == atoi(arg)) {
> +opts->x_flag_align_functions = true;
> +opts->x_str_align_functions = NULL;
> + }
>break;
>
> case OPT_ftabstop_:
> --
> 2.17.1
>
>
[PATCH v2] driver: fix a problem with implementation of -falign-foo=0 [PR96247]
Thanks, Richard!
I think your suggestion is very good, so I made a new patch.
v2: at a high level handles -falign-foo=0 like -falign-foo
v1: at the target level overides the -falign-foo=0 option values
Obviously, v2 is better than v1. In addition, anthor option
to reject 0 that discussed in the email and PR96247
is not as good as the current patch either, I think.
I tested this patch on x86_64, it works well. OK for trunk?
Regards!
Hujp
---
gcc/opts.c | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/opts.c b/gcc/opts.c
index 499eb900643..ed6102cd606 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2786,18 +2786,38 @@ common_handle_option (struct gcc_options *opts,
case OPT_falign_loops_:
check_alignment_argument (loc, arg, "loops");
+ // fix PR96247
+ if (0 == atoi(arg)) {
+opts->x_flag_align_loops = true;
+opts->x_str_align_loops = NULL;
+ }
break;
case OPT_falign_jumps_:
check_alignment_argument (loc, arg, "jumps");
+ // fix PR96247
+ if (0 == atoi(arg)) {
+opts->x_flag_align_jumps = true;
+opts->x_str_align_jumps = NULL;
+ }
break;
case OPT_falign_labels_:
check_alignment_argument (loc, arg, "labels");
+ // fix PR96247
+ if (0 == atoi(arg)) {
+opts->x_flag_align_labels = true;
+opts->x_str_align_labels = NULL;
+ }
break;
case OPT_falign_functions_:
check_alignment_argument (loc, arg, "functions");
+ // fix PR96247
+ if (0 == atoi(arg)) {
+opts->x_flag_align_functions = true;
+opts->x_str_align_functions = NULL;
+ }
break;
case OPT_ftabstop_:
--
2.17.1
RE: [PATCH] target: fix default value checking of x_str_align_functions in aarch64.c
> Sorry for the slow response on this. Like you say, it seems to be a pretty
> pervasive problem. In fact I couldn't see anywhere that actually treated -
> falign-foo=0 as anything other than -falign-foo=1.
>
> Technically using an alignment of one for zero is within what the
> documentation allows, but not in a useful way. The documentation also isn't
> clear about whether:
>
> -falign-loops=0:8
>
> (“align to whatever you think is best, but don't skip more than 8 bytes”) is
> supposed to be valid. The implication is that it's OK, but in practice it
> doesn't
> work.
>
Thanks, Richard!
> If there isn't anywhere that handles zero in the way that the documentation
> implies (i.e. with -falign-loops=0 being equivalent to -falign-loops) then
> maybe
> we should instead change the documentation to match the actual behaviour.
>
Yes, I confirmed in source level that there is no target that handles zero in
the way that the documentation implies.
But, I think just adjusting the documentation to reflect the implementation
behavior will cause -falign-functions=0 and -falign-functions=1 to have the
same meaning which is a bit confusing from the user's perspective.
In fact, I have issued a pr to Bugzilla, and got a comment from Richard Biener.
We are considering whether to reject 0, which means both the source and the
documentation should be modified a bit.
I found that function parse_and_check_align_values in gcc/opts.c maybe the
point we want to modify, values less than 0 are currently rejected here. Maybe
we can change the '<’ to '<=' in the if statement. But I need test, to make
sure there are no regression issues.
What do you think?
Regards!
Hujp
> If instead this is a regression from previous compilers, then I guess we
> should
> fix it. But I think it would be good to have a helper function that tests
> whether
> the default should be used for a given x_flag_align_foo and x_str_align_foo
> pair. That we we could reuse it in other targets and would have only one
> place
> to update. (For example, we might decide to use
> parse_and_check_align_values rather than strcmp.)
>
> Don't know whether anyone else has any thoughts about the best fix.
>
> Thanks, and sorry again for the slow reply.
>
> Richard
>
> >
> > Regards!
> > Hujp
> >
> > ---
> > gcc/config/aarch64/aarch64.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/gcc/config/aarch64/aarch64.c
> > b/gcc/config/aarch64/aarch64.c index 17dbe673978..697ac676f4d
> 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -14221,11 +14221,14 @@ aarch64_override_options_after_change_1
> (struct gcc_options *opts)
> > alignment to what the target wants. */
> >if (!opts->x_optimize_size)
> > {
> > - if (opts->x_flag_align_loops && !opts->x_str_align_loops)
> > + if ((opts->x_flag_align_loops && !opts->x_str_align_loops)
> > +|| (opts->x_str_align_loops &&
> > + strcmp(opts->x_str_align_loops, "0") == 0))
> > opts->x_str_align_loops = aarch64_tune_params.loop_align;
> > - if (opts->x_flag_align_jumps && !opts->x_str_align_jumps)
> > + if ((opts->x_flag_align_jumps && !opts->x_str_align_jumps)
> > +|| (opts->x_str_align_jumps &&
> > + strcmp(opts->x_str_align_jumps, "0") == 0))
> > opts->x_str_align_jumps = aarch64_tune_params.jump_align;
> > - if (opts->x_flag_align_functions && !opts->x_str_align_functions)
> > + if ((opts->x_flag_align_functions && !opts->x_str_align_functions)
> > +|| (opts->x_str_align_functions &&
> > + strcmp(opts->x_str_align_functions, "0") == 0))
> > opts->x_str_align_functions = aarch64_tune_params.function_align;
> > }
>
RE: [PATCH] target: fix default value checking of x_str_align_functions in aarch64.c
PING.
> -Original Message-
> From: Gcc-patches On Behalf Of Hu
> Jiangping
> Sent: Tuesday, July 14, 2020 3:55 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] target: fix default value checking of x_str_align_functions
> in
> aarch64.c
>
> Hi,
>
> This patch deal with the -falign-X=0 options. According to man pages,
> if zero is specified, a machine-dependent default value should be used.
> But in fact, zero was used in internal process, it is inconsistent.
>
> Tested on aarch64-linux cross compiler, Is that OK?
>
> BTW, the similar problems exists in other target sources.
> I can submit them all in another patch if needed,
> but I can test on i386 target only.
>
> Regards!
> Hujp
>
> ---
> gcc/config/aarch64/aarch64.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 17dbe673978..697ac676f4d 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -14221,11 +14221,14 @@ aarch64_override_options_after_change_1
> (struct gcc_options *opts)
> alignment to what the target wants. */
>if (!opts->x_optimize_size)
> {
> - if (opts->x_flag_align_loops && !opts->x_str_align_loops)
> + if ((opts->x_flag_align_loops && !opts->x_str_align_loops)
> +|| (opts->x_str_align_loops && strcmp(opts->x_str_align_loops, "0")
> ==
> 0))
> opts->x_str_align_loops = aarch64_tune_params.loop_align;
> - if (opts->x_flag_align_jumps && !opts->x_str_align_jumps)
> + if ((opts->x_flag_align_jumps && !opts->x_str_align_jumps)
> +|| (opts->x_str_align_jumps && strcmp(opts->x_str_align_jumps, "0")
> == 0))
> opts->x_str_align_jumps = aarch64_tune_params.jump_align;
> - if (opts->x_flag_align_functions && !opts->x_str_align_functions)
> + if ((opts->x_flag_align_functions && !opts->x_str_align_functions)
> +|| (opts->x_str_align_functions &&
> strcmp(opts->x_str_align_functions,
> "0") == 0))
> opts->x_str_align_functions = aarch64_tune_params.function_align;
> }
>
> --
> 2.17.1
>
>
[wwwdocs PATCH v2] projects/tree-ssa: add a big banner to tree-browser.html
Hi, Different from Patch v1 which removed the page, I add a big banner to say that the page is no longer up-to-date, just as Richard and Gerald recommended. OK for push? Regards! Hujp --- htdocs/projects/tree-ssa/tree-browser.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/projects/tree-ssa/tree-browser.html b/htdocs/projects/tree-ssa/tree-browser.html index ce95a103..fe292b49 100644 --- a/htdocs/projects/tree-ssa/tree-browser.html +++ b/htdocs/projects/tree-ssa/tree-browser.html @@ -8,6 +8,11 @@ + + +Tree Browser has been removed from gcc, +and this page is no longer up-to-date. + Tree Browser Until recently the only way to debug trees from gdb was to call -- 2.17.1
[PATCH] target: fix default value checking of x_str_align_functions in aarch64.c
Hi,
This patch deal with the -falign-X=0 options. According to man pages,
if zero is specified, a machine-dependent default value should be used.
But in fact, zero was used in internal process, it is inconsistent.
Tested on aarch64-linux cross compiler, Is that OK?
BTW, the similar problems exists in other target sources.
I can submit them all in another patch if needed,
but I can test on i386 target only.
Regards!
Hujp
---
gcc/config/aarch64/aarch64.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 17dbe673978..697ac676f4d 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -14221,11 +14221,14 @@ aarch64_override_options_after_change_1 (struct
gcc_options *opts)
alignment to what the target wants. */
if (!opts->x_optimize_size)
{
- if (opts->x_flag_align_loops && !opts->x_str_align_loops)
+ if ((opts->x_flag_align_loops && !opts->x_str_align_loops)
+|| (opts->x_str_align_loops && strcmp(opts->x_str_align_loops, "0") ==
0))
opts->x_str_align_loops = aarch64_tune_params.loop_align;
- if (opts->x_flag_align_jumps && !opts->x_str_align_jumps)
+ if ((opts->x_flag_align_jumps && !opts->x_str_align_jumps)
+|| (opts->x_str_align_jumps && strcmp(opts->x_str_align_jumps, "0") ==
0))
opts->x_str_align_jumps = aarch64_tune_params.jump_align;
- if (opts->x_flag_align_functions && !opts->x_str_align_functions)
+ if ((opts->x_flag_align_functions && !opts->x_str_align_functions)
+|| (opts->x_str_align_functions && strcmp(opts->x_str_align_functions,
"0") == 0))
opts->x_str_align_functions = aarch64_tune_params.function_align;
}
--
2.17.1
RE: [wwwdocs PATCH] remove tree-browser page and links
> On Thu, 9 Jul 2020, Richard Sandiford wrote: > >> I'm trying Tree Browser during debugging, but failed. > >> I found that tree-browser.c and tree-browser.def have been removed at > >> 2015-07-25. So, to avoid misunderstanding, can we remove this > >> tree-browser page too? > > Thanks for the patch. Seems like a good idea to me. I guess the only > > question is whether we should keep it around for historical purposes, > > but with a big banner to say that it's no longer up-to-date. I also > > don't know whether we try to avoid 404s on old pages. > > Thank you, Hujp and Richard! > > We generally try to avoid 404s. So in case we remove a page put in a > redirect. > You can do so via a new entry in wwwdocs/htdocs/.htaccess (which I believe is > self explanatory, and I'm happy to help, too). > Thank you, Richard and Gerald! Since the tree-ssa/index.html and tree-ssa/tree_browser.html are no longer up-to-date, I think it may be better to add a redirect than to update. Is there a page means the page which was redirected is no longer up-to-date? Or just redirect to index.html itself as the following, it's OK? Regards. Hujp --- diff --git a/htdocs/.htaccess b/htdocs/.htaccess index 18997d63..67ee474f 100644 --- a/htdocs/.htaccess +++ b/htdocs/.htaccess @@ -67,6 +67,7 @@ Redirect permanent /proj-optimize.html https://gcc.gnu.org/projects/optimize.ht Redirect permanent /projects.html https://gcc.gnu.org/projects/ Redirect permanent /projects/cxx1z.html https://gcc.gnu.org/projects/cxx-status.html#cxx1z Redirect permanent /projects/web.html https://gcc.gnu.org/about.html +Redirect permanent /projects/tree-ssa/tree-browser.html https://gcc.gnu.org/projects/tree-ssa/ Redirect permanent /reghunt-howto.html https://gcc.gnu.org/bugs/reghunt.html Redirect permanent /svn.html https://gcc.gnu.org/git.html Redirect permanent /svnwrite.html https://gcc.gnu.org/gitwrite.html -- > My recommendation in a case like this is to follow the approach of adding a > big > banner at the top as you suggest, Richard. That said, if the consensus by > you/those working in this area is to completely remove the page, that is > perfectly fine, too. > > Gerald >
[wwwdocs PATCH] remove tree-browser page and links
Hi, I'm trying Tree Browser during debugging, but failed. I found that tree-browser.c and tree-browser.def have been removed at 2015-07-25. So, to avoid misunderstanding, can we remove this tree-browser page too? Regards. hujp --- htdocs/projects/tree-ssa/index.html| 6 - htdocs/projects/tree-ssa/tree-browser.html | 306 - 2 files changed, 312 deletions(-) delete mode 100644 htdocs/projects/tree-ssa/tree-browser.html diff --git a/htdocs/projects/tree-ssa/index.html b/htdocs/projects/tree-ssa/index.html index a15d0f32..930df390 100644 --- a/htdocs/projects/tree-ssa/index.html +++ b/htdocs/projects/tree-ssa/index.html @@ -21,7 +21,6 @@ GENERIC and GIMPLE SSA implementation Unparsing GENERIC trees -Tree Browser Implementation Status (last updated: 2003-11-22) TODO list (last updated: 2003-12-27) @@ -221,11 +220,6 @@ functions that given a GENERIC tree node, they print a C representation of the tree. The output is not meant to be compilable, but it is of great help when debugging transformations done by the transformation passes. - -Tree Browser -For debugging, browsing, discovering, and playing with trees you can -use the Tree Browser directly from gdb. - Implementation Status diff --git a/htdocs/projects/tree-ssa/tree-browser.html b/htdocs/projects/tree-ssa/tree-browser.html deleted file mode 100644 index ce95a103.. --- a/htdocs/projects/tree-ssa/tree-browser.html +++ /dev/null @@ -1,306 +0,0 @@ - - - - - -Tree Browser -https://gcc.gnu.org/gcc.css; /> - - - -Tree Browser - -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: - - -(gdb) p browse_tree (current_function_decl) - -Tree Browser -foo -Up/prev expressions updated. -TB - - -For listing available commands, you could try: - - -TB h -Possible commands are: - - x - Exits tree-browser. - q - Exits tree-browser. - h - Prints this help message. - update - Update information about parent expressions. - verbose - Sets/unsets verbose mode (default is on). - fun - Go to the current function declaration. - nx - Go to the next expression in a BIND_EXPR. - pr - Go to the previous expression in a BIND_EXPR. - up - Go to the parent tree node. -last - Go to the last expression in a BIND_EXPR. - first - Go to the first expression in a BIND_EXPR. - hpr - Go to the previous visited node (history previous). -arg0 - Child 0. -arg1 - Child 1. -arg2 - Child 2. -arg3 - Child 3. - decl_saved_tree - Body of a function. -type - Field accessor. -size - Field accessor. - unit_size - Field accessor. - offset - Field accessor. - bit_offset - Field accessor. - context - Field accessor. - attributes - Field accessor. - abstract_origin - Field accessor. - arguments - Field accessor. - result - Field accessor. - initial - Field accessor. -arg-type - Field accessor. - arg-type-as-written - Field accessor. - chain - Field accessor. - values - Field accessor. - domain - Field accessor. - method_basetype - Field accessor. - fields - Field accessor. - arg-types - Field accessor. -basetype - Field accessor. - pointer_to_this - Field accessor. - reference_to_this - Field accessor. -vars - Field accessor. -supercontext - Field accessor. -body - Field accessor. - subblocks - Field accessor. - block - Field accessor. -real - Field accessor. -imag - Field accessor. - purpose - Field accessor. - value - Field accessor. - elt - Field accessor. - min - Field accessor. - max - Field accessor. - sc - Search a node having a TREE_CODE given as a parameter. - sn - Search an identifier having a name given as a parameter. - 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. - -Now let's try some of these commands: we're on the declaration of the -current
[wwwdocs PATCH] Fix typo
Hi, this patch fix a typo in contribute.html. Best Regards. Hujp --- htdocs/contribute.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index 80a4470e..a913565b 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -133,7 +133,7 @@ other changes applied. Documentation changes do not require a new bootstrap (a working bootstrap is necessary to get the build environment correct), but you must perform make info and make dvi and correct -and errors. You should investigate complaints about overfull or +any errors. You should investigate complaints about overfull or underfull hboxes from make dvi, as these can be the only indication of serious markup problems, but do not feel obliged to eliminate them all. -- 2.17.1
