[wwwdocs] Buildstat update for 4.5
Latest results for 4.5.x -tgc Testresults for 4.5.4: powerpc-apple-darwin8.11.0 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/buildstat.html,v retrieving revision 1.18 diff -u -r1.18 buildstat.html --- buildstat.html 28 Jun 2014 11:59:44 - 1.18 +++ buildstat.html 17 Aug 2014 09:12:52 - @@ -259,6 +259,7 @@ powerpc-apple-darwin8.11.0 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01875.html";>4.5.4, https://gcc.gnu.org/ml/gcc-testresults/2011-06/msg02820.html";>4.5.3, https://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00695.html";>4.5.2, https://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00694.html";>4.5.1,
[wwwdocs] Buildstat update for 4.8
Latest results for 4.8.x -tgc Testresults for 4.8.3: x86_64-unknown-linux-gnu Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v retrieving revision 1.9 diff -u -r1.9 buildstat.html --- buildstat.html 3 Jul 2014 21:44:03 - 1.9 +++ buildstat.html 17 Aug 2014 09:14:43 - @@ -302,6 +302,7 @@ x86_64-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01786.html";>4.8.3, https://gcc.gnu.org/ml/gcc-testresults/2014-02/msg01608.html";>4.8.2, https://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00373.html";>4.8.2, https://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01854.html";>4.8.2,
[wwwdocs] Buildstat update for 4.9
Latest results for 4.9.x -tgc Testresults for 4.9.1: arm-unknown-linux-gnueabihf hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 i386-pc-solaris2.9 i686-pc-linux-gnu powerpc-apple-darwin8.11.0 sparc-sun-solaris2.9 sparc64-sun-solaris2.9 x86_64-unknown-linux-gnu x86_64-w64-mingw32 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/buildstat.html,v retrieving revision 1.4 diff -u -r1.4 buildstat.html --- buildstat.html 28 Jun 2014 11:59:44 - 1.4 +++ buildstat.html 17 Aug 2014 09:27:29 - @@ -30,6 +30,13 @@ +arm-unknown-linux-gnueabihf + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01884.html";>4.9.1 + + + hppa-unknown-linux-gnu @@ -39,9 +46,26 @@ +hppa2.0w-hp-hpux11.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01943.html";>4.9.1 + + + + +hppa64-hp-hpux11.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg00430.html";>4.9.1 + + + + i386-pc-solaris2.9 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01667.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02112.html";>4.9.0, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01785.html";>4.9.0 @@ -64,6 +88,14 @@ +i686-pc-linux-gnu + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01863.html";>4.9.1 + + + + i686-unknown-linux-gnu Test results: @@ -91,6 +123,7 @@ powerpc-apple-darwin8.11.0 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg02093.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02408.html";>4.9.0 @@ -115,6 +148,7 @@ sparc-sun-solaris2.9 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01668.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02113.html";>4.9.0, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01832.html";>4.9.0 @@ -132,6 +166,7 @@ sparc64-sun-solaris2.9 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01669.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02114.html";>4.9.0 @@ -148,12 +183,22 @@ x86_64-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg02573.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02165.html";>4.9.0, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01757.html";>4.9.0, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01741.html";>4.9.0 + +x86_64-w64-mingw32 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01531.html";>4.9.1 + + + +
Re: [PATCH] Handle -fsanitize=leak more similarly to address/thread
Jakub Jelinek writes: > Right now when -fsanitize=leak adds -llsan, it adds it late on the command > line, so e.g. -lstdc++ comes after it, which seems to be bad. > The following patch puts it early on the link command line like we do for > -lasan or -ltsan. Bootstrapped/regtested on x86_64-linux and i686-linux, > ok for trunk? > > 2014-08-14 Jakub Jelinek > > * config/gnu-user.h (LIBLSAN_EARLY_SPEC): Define. > * gcc.c (LIBLSAN_SPEC, LIBLSAN_EARLY_SPEC): Follow LIBTSAN*_SPEC. > (SANITIZER_EARLY_SPEC): Include LIBLSAN_EARLY_SPEC for -fsanitize=leak. This looks OK to me. Thanks! -- Dodji
Re: [PATCH] Fix UB in diagnostic.c
Marek Polacek a écrit: > On Wed, Aug 13, 2014 at 09:03:37PM +0200, Manuel López-Ibáñez wrote: >> I don't think this is the right fix. The problem is that we are trying >> to print the caret in a column that is larger than the line_width. We >> do this because the file given by the line directive has nothing to do >> with the actual code we are parsing. I think in that case it is ok to >> just give up and not print a caret. So something like: >> >> @@ -300,11 +299,11 @@ diagnostic_show_locus (diagnostic_contex >> return; >> >>context->last_location = diagnostic->location; >>s = expand_location_to_spelling_point (diagnostic->location); >>line = location_get_source_line (s, &line_width); >> - if (line == NULL) >> + if (line == NULL || s.column > line_width) >> return; >> >>max_width = context->caret_max_width; >>line = adjust_line (line, line_width, max_width, &(s.column)); >> >> Nonetheless, perhaps in addition adjust_line should have >> gcc_checking_assert(line_width >= column). > > Yea, I think this would be much better, thanks. Done in the > following. Yes, I agree with this as well. > Bootstrapped/regtested on x86_64-linux, ok for trunk? Yes, this is OK to me. Thank you for looking into this. Cheers. -- Dodji
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/10/2014 04:15 PM, Chen Gang wrote: > On 08/10/2014 04:03 PM, Mike Stump wrote: >> On Aug 9, 2014, at 9:55 AM, Chen Gang wrote: >>> >>> Excuse me, I can not find it with `find ./ | grep "\.sum$”` >> >> Then you didn’t do a test suite run. make check will create .sum files. >> Try cd gcc && make check. Then in testsuite/gcc/gcc.sum there will be a >> file. >> After check again, I found, I did not install runtest (but it skipped, and let "make check" OK), after install from 'dejagnu', can have real effect. At present (just running "make check"), some results are: Running /upstream/toolchain/gcc/gcc/testsuite/gcc.c-torture/compile/compile.exp ... FAIL: gcc.c-torture/compile/20001226-1.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/20001226-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-blockid.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/limits-blockid.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/limits-caselabels.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/limits-caselabels.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/limits-enumconst.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/limits-enumconst.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/limits-enumconst.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/limits-enumconst.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/limits-enumconst.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/limits-enumconst.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-enumconst.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: gcc.c-torture/compile/limits-enumconst.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) FAIL: gcc.c-torture/compile/limits-externalid.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/limits-externalid.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-externalid.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/limits-externalid.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/limits-externdecl.c -O2 (test for excess errors) ... Do these contents mean: I make any incorrect configuration, again? > > OK, thanks, I built it under individual directory "build-gcc", I guess > your meaning is "cd ./build-gcc/gcc && make check". If what I guess is > incorrect, please let me know, thanks. > >>> After comparing, should the related ".sum" files be the same (same means >>> pass checking)? >> >> No, use contrib/compare_tests before_dir after_dir :-) If you _save_off >> the .sum files, you can use the places where you same them off. If you use >> two trees, you can just use them directly (no saving off). >> >> where the two are the build directories that you did a make check in. The >> output will be in simple english and should be readily understandable. >> After try, I found your information about 2 build directories are very useful for me, which can same much time under smp machine. And sorry, I did not finish "make check" at the time point. I wasted my time resources (of my free time) on constructing PC environments and my x86_64 laptop environments. - x86_64 laptop under ubuntu: try to update 'libc6' package to install 'autogen'. At last, I succeed: overwrite libc6 package files under individual living system, and then modify dpkg config file manually. - PC environments: I failed, the reason is my PC hardware is not stable enough (low quality). After building several hours, the machine will reboot automatically (tried several times, each needs several hours). And I shall try to finish as soon as possible (may tomorrow or the day after tomorrow, under Mac book, and within a week under x86_64 laptop). > > OK, Thanks, and I shall try to finish within next week (one building is > still very long, although I have switched to mac book -- more higher > performance machine). > > > Thanks. > Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes
And sorry, I did not finish "make check" at the time point. I wasted my
time resources (of my free time) on constructing PC environments and my
x86_64 laptop environments.
- x86_64 laptop under ubuntu: try to update 'libc6' package to install
'autogen'. At last, I succeed: overwrite libc6 package files under
individual living system, and then modify dpkg config file manually.
- PC environments: I failed, the reason is my PC hardware is not stable
enough (low quality). After building several hours, the machine will
reboot automatically (tried several times, each needs several hours).
And I shall try to finish as soon as possible (may tomorrow or the day
after tomorrow, under Mac book; and within a week under x86_64 laptop).
At present, the related patch v2 is below, if possible, please check.
Thanks.
-patch begin
gcc/c/c-aux-info.c: Resize 'buff' from 10 to 23 bytes
int_size_in_bytes() returns HOST_WIDE_INT (64-bit), theoretically, the
maximized size is 23 -- it is sizeof("[-9223372036854775808]") for
0x8000LL.
It may not cause real world issue, but if another issues occur, it may
lead things worse.
2014-08-17 Chen Gang
* c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes.
---
gcc/c/c-aux-info.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/c/c-aux-info.c b/gcc/c/c-aux-info.c
index 4b6b2d0..878807b 100644
--- a/gcc/c/c-aux-info.c
+++ b/gcc/c/c-aux-info.c
@@ -310,9 +310,10 @@ gen_type (const char *ret_val, tree t, formals_style style)
TREE_TYPE (t), style);
else
{
- int size = (int_size_in_bytes (t) / int_size_in_bytes (TREE_TYPE
(t)));
- char buff[10];
- sprintf (buff, "[%d]", size);
+ char buff[23];
+ sprintf (buff, "["HOST_WIDE_INT_PRINT_DEC"]",
+ int_size_in_bytes (t)
+ / int_size_in_bytes (TREE_TYPE (t)));
ret_val = gen_type (concat (ret_val, buff, NULL),
TREE_TYPE (t), style);
}
-patch end--
On 8/12/14 11:41, Chen Gang wrote:
>
>
> On 8/12/14 7:38, Mike Stump wrote:
>> On Aug 11, 2014, at 2:27 PM, Chen Gang wrote:
>>> Welcome additional disccusions or completions, and if no any additional
>>> reply within 1 week, I shall send patch v2 for it (still use sprintf).
>>
>> So, my take is it is easier for a maintainer to re-review if you do it
>> without additional delay. I’d recommend addressing the review points and
>> posting without waiting a week in this case. Waiting is useful if a review
>> point is contentious.
>>
>
> OK, thanks. What you said sounds reasonable to me.
>
> But excuse me, I have no enough time resource on it, and also, I am
> still not quite familiar with building and checking (especially it needs
> a long time to build and check which has negative effect for analyzing).
>
> So, excuse me again, I have to need more time period on it. But I should
> try send patch v2 for it within this week (2014-08-17).
>
>
> And still welcome additional ideas, suggestions or completions.
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH, Fortran] PR fortran/60414 fix ICE was: PR 60414: Patch proposal
Hello, Le 06/08/2014 21:23, Andre Vehreschild a écrit : > Hi, > [...] > > *** gcc/fortran/Changelog *** > 2014-08-06 Andre Vehreschild > > PR fortran/60414 > * interface.c (compare_parameter): Fixing ICE when argument > of a generic is a reference into an array. > *** gcc/fortran/Changelog *** The ChangeLog format is good, but the text is not very helpful/descriptive for someone hunting a bug in compare_parameter in the future. You can say (for example): Remove class argument rank check short circuit. > > *** gcc/testsuite/Changelog *** > 2014-08-06 Andre Vehreschild > > * gfortran.dg/unlimited_polymorphism_18.f90: Check according to > PR fortran/60414 > *** gcc/testsuite/Changelog *** You should add PR fortran/60414 before like in the gcc/fortran Changelog, and then the text just need to say new/new file/new test (see what the other contributors use in the rest of the file). > > Bootstrapped and regtested on x86_64-unkown-linux-gnu. > The patch looks good to me. With the ChangeLog fixes above, OK if/when the copyright assignment is settled. Thanks Mikael
[patch, fortran] Move expressions from the mask in a forall header
Hello world,
this patch moves expressions which do not depend on the
index variable(s) from FORALL headers (which also includes
DO CONCURRENT).
For the test case in do_concurrent_4.f90,
do concurrent(i=1:n, a(i)>sum(a)/n)
a(i) = a(i) * 0.5
end do
Without the patch, this gets translated in a
straightforward manner to
DO CONCURRENT main:i 1:10:1(> main:a(main:i) (/
_gfortran_sum_r4[[((main:a(FULL)) ((arg not-present)) ((arg
not-present)))]] 1.e1))
ASSIGN main:a(main:i) (* main:a(main:i) 5.e-1) END DO
With the patch and with front-end optimization on, this becomes
ASSIGN block@7:__var_1 (/ _gfortran_sum_r4[[((main:a(FULL)) ((arg
not-present)) ((arg not-present)))]] 1.e1)
DO CONCURRENT main:i 1:10:1(> main:a(main:i) block@7:__var_1)
ASSIGN main:a(main:i) (* main:a(main:i) 5.e-1)END DO
There is one fine point regarding the part of the patch used to check
if an expression is identical to the loop variable:
+ se = (*e)->symtree;
+
+ if (se == NULL)
+return 0;
+
+ for (fa = (*current_code)->ext.forall_iterator; fa;
+ fa = fa->next)
+{
+ if (se == fa->var->symtree)
+ return 1;
+}
+ return 0;
Originally, this was
+ se = (*e)->symtree->n.sym;
+
+ for (fa = (*current_code)->ext.forall_iterator; fa; fa = fa->next)
+{
+ si = fa->var->symtree->n.sym;
+ if (si == se)
+ return 1;
+}
+
but this caused a regression in forall_5.f90 when
fa->var->symtree held the address 0x04 (which only
occurred when running the test suite). I could not
figure out where this strange value was being generated,
so I setteled for comparing the symtree address instead
(and adding a NULL check just in case :-)
Regression-tested. OK for trunk?
Regards
Thomas
2014-08-17 Thomas Koenig
PR fortran/60661
* frontend-passes.c (optimize_forall_header): Add prototype,
new function.
(optimize_code): Call optimize_forall_header.
(concurrent_iterator_check): New function.
(forall_header_varmove): New function.
2014-08-17 Thomas Koenig
PR fortran/60661
* gfortran.dg/do_concurrent_4.f90: New test.
* gfortran.dg/do_concurrent_5.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 214061)
+++ frontend-passes.c (Arbeitskopie)
@@ -33,6 +33,7 @@ along with GCC; see the file COPYING3. If not see
static void strip_function_call (gfc_expr *);
static void optimize_namespace (gfc_namespace *);
static void optimize_assignment (gfc_code *);
+static void optimize_forall_header (gfc_code *);
static bool optimize_op (gfc_expr *);
static bool optimize_comparison (gfc_expr *, gfc_intrinsic_op);
static bool optimize_trim (gfc_expr *);
@@ -145,6 +146,10 @@ optimize_code (gfc_code **c, int *walk_subtrees AT
if (op == EXEC_ASSIGN)
optimize_assignment (*c);
+
+ if (op == EXEC_DO_CONCURRENT || op == EXEC_FORALL)
+optimize_forall_header (*c);
+
return 0;
}
@@ -980,6 +985,70 @@ remove_trim (gfc_expr *rhs)
return ret;
}
+/* Callback function to check if there is a reference
+ to one of the concurrent iterators in the expression. */
+
+static int
+concurrent_iterator_check (gfc_expr **e,
+ int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data ATTRIBUTE_UNUSED)
+{
+ gfc_symtree *se;
+ gfc_forall_iterator *fa;
+
+ if ((*e)->expr_type != EXPR_VARIABLE)
+return 0;
+
+ se = (*e)->symtree;
+
+ if (se == NULL)
+return 0;
+
+ for (fa = (*current_code)->ext.forall_iterator; fa;
+ fa = fa->next)
+{
+ if (se == fa->var->symtree)
+ return 1;
+}
+ return 0;
+}
+
+/* Callback helper function for optimizing the header of
+ FORALL and DO CONCURRENT. */
+
+static int
+forall_header_varmove (gfc_expr **e,
+ int *walk_subtrees,
+ void *data ATTRIBUTE_UNUSED)
+{
+ if ((*e)->expr_type == EXPR_VARIABLE && (*e)->ref == NULL)
+return 0;
+
+ if ((*e)->expr_type == EXPR_CONSTANT)
+return 0;
+
+ if (gfc_expr_walker (e, concurrent_iterator_check, NULL) == 0)
+{
+ gfc_expr *ex;
+
+ ex = create_var (*e);
+ (*e) = ex;
+ *walk_subtrees = 1;
+}
+ return 0;
+}
+
+/* Optimization for FORALL and DO CONCURRENT masks. */
+
+static void
+optimize_forall_header (gfc_code *c)
+{
+ if (c->expr1 == NULL)
+return;
+
+ gfc_expr_walker (&(c->expr1), forall_header_varmove, NULL);
+}
+
/* Optimizations for an assignment. */
static void
! { dg-do run }
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
! Test movement of expressions not involving the index variable
program main
implicit none
integer, parameter :: n = 10
real, dimension(n) :: a,res
integer :: i
data a/0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9/
data res /0.0, 0.1, 0.2, 0.3, 0.4, 0.25, 0.3, 0.35, 0.4, 0.45/
do concurrent(i=1:n, a(i)>sum(a)/n)
a(i) = a(i) * 0.5
end do
if (any(abs(a
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
Le 07/08/2014 15:40, Andre Vehreschild a écrit : > Hi, > > in the bugtracker for PR60255 janus proposed to fix the bug by removing > the error and additionally checking if the character array length > declaration is deferred, which leaves the the charlen to be 0 > (gcc/fortran/class.c (find_intrinsic_vtab) 2418-2420). > > My contribution to that patch is the testcase and to mark the vtab-entry more > clearly to stem from a deferred array init, because I did not like the array > size being 0. This may lead to confusions with a character array of length 0. > Therefore I changed the symbol name generation to enable easier identification > of problems. > > The symbol before my change was computed to be: > > symbolname_0_kind > > I would have used the colon (:) to indicate the deferred state, but that > is not allowed in the assembler, so I spelled it out and the symbol is now > marked by: > > symbolname_DEFERRED_kind > > This way the vtab entry can not be confused with an entry for an entry for a > zero length array and the word DEFERRED has as many characters as MAXINT > printed in the decimal system, i.e., if no check is needed, if MAXINT does fit > into the space reserved for the vtab symbol, then no check is needed for the 8 > character word, too. > > Changelog and extended patch proposal attached. > > Bootstrapped and regtested on x86_64-linux-gnu > > Please comment! > Hello, the testcase should check that the code generated is actually working, not just that the ICE disappeared. Janus's comment in the PR about _size being 0 tells that probably the code generated won't work in some (corner?) cases, so I'm a bit reluctant to let it pass through (I prefer the ICE). Mikael PS: No need for two separate Changelog entries, just put the two authors in the same entry. See the other ChangeLog files for examples.
Re: [jbg...@lug-owl.de: Re: r214024 - in /trunk/gcc: ChangeLog c-family/Cha...]
On 16 August 2014 22:33, Jan-Benedict Glaw wrote: > On Sat, 2014-08-16 22:01:40 +0200, Marc Glisse wrote: >> For your tests, I thought the sequence was: >> >> checkout some revision of gcc >> build a native gcc at this revision >> use it to build a bunch of cross-compilers at the same revision > > There are actually two different build strategies implemented. > > 1. Builds using GCC's ./contrib/config-list.mk; > 2. Something homegrown (also builds binutils). > > As you can see in the timeline, the homegrown stuff isn't affected (at > least not more than usual ;-) ) > > However, the builds done with ./contrib/config-list.mk fail since > (most probably) the commit I pointed out. We can quite start a > discusion about what config-list.mk actually does and whether or not > that's universally right. But we can also recognize that as a fact, > something (which is possibly not yet fully understood) changed along > that commit. My understanding is that the build-bot is using -Werror to compile fortran/options.c with a compiler that is at least one revision older than my commit. Since my commit adds both the code to handle format codes in the Fortran FE and functions using the new format codes, you need at least that revision to not get Wformat warnings. In config-list.mk, it says "Make sure you have a recent enough gcc (with ada support) in your path so that --enable-werror-always will work" For this commit in particular, recent enough means "exactly the same revision". Otherwise, --enable-werror-always won't work. And you cannot build that compiler with --enable-werror-always. See also: https://gcc.gnu.org/ml/gcc/2014-01/msg00157.html I think that for a build-bot it would be better to bootstrap the compiler for the current target once (without --enable-werror-always), then use that compiler to build the rest minus the current target (with --enable-werror-always). This could be done within config-list.mk or from another script. Cheers, Manuel. > > From a quick view, config-list.mk tries to invoke the host compiler > ($CC/$CPP) and just builds "all-gcc" with it. There used to be some > spurious errors due to that for some targets (I can dig those out if > somebody is interested; it's usually a variable GCC thinks that's used > uninitialized, and some recently introduced fuzz with the m68k > target), but there are quite a number of functions using printf style > (with GCC extensions) format checking. That all used to work, except > for this new function introduced with the fortran change. I think that > there's something simple missing (maybe as easy as an undefined > macro), but I haven't checked that at all. > > MfG, JBG > > -- > Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 > Signature of: Wenn ich wach bin, träume ich. > the second :
Re: [PATCH, Fortran] PR fortran/60414 fix ICE was: PR 60414: Patch proposal
As Mikael said in https://gcc.gnu.org/ml/fortran/2014-08/msg00047.html
> the testcase should check that the code generated is actually working,
> not just that the ICE disappeared. ...
thus I think the test should be run, i.e., '! { dg-do compile }' should
be replaced with '! { dg-do run }' (I have checked that the test succeeds).
Dominique
Re: [PATCH] C frontend: cast-expressions sometimes retain type qualifiers
On Sat, Aug 16, 2014 at 09:54:33PM -0400, Patrick Palka wrote: > --- a/gcc/c/c-typeck.c > +++ b/gcc/c/c-typeck.c > @@ -4947,6 +4947,8 @@ build_c_cast (location_t loc, tree type, tree expr) > || TREE_CODE (type) == UNION_TYPE) > pedwarn (loc, OPT_Wpedantic, >"ISO C forbids casting nonscalar to the same type"); > + > + value = convert (type, value); Maybe a comment saying why we convert the value here anyway would be useful. Otherwise LGTM. Marek
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
> the testcase should check that the code generated is actually working, > not just that the ICE disappeared. I agree. Note that there is a test in the comment 3 of PR60255 that can be used to check the run time behavior (and possibly check the vtab issue). Dominique
Re: [PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable
Hello, Le 10/08/2014 13:55, Andre Vehreschild a écrit : > Hi, > > I am proposing another patch, this time to resolve PR60289. The issue in the > bug > reported is, that a code like: > > class(*), pointer :: P > allocate(character(20)::P) > > is rejected by trunk's gfortran compiler. ja...@gcc.gnu.org proposed a first > patch in the PR, which my patch extends. > > Motivation: Previously parsing of the type association to the unlimited > polymorphic variable P was not allowed and reported the error "Error: > Allocating p at (1) with type-spec requires the same character-length > parameter > as in the declaration", after the errorneous error report was fixed by > janus' patch, an ICE occured in trans-stmt.c's gfc_trans_allocate()-routine. > The ICE reported in PR60289 is something different and does not occur in trunk > anymore. The ICE reported now boils down to line 5056 in trans-stmt.c: > > tmp= al->expr->ts.u.cl->backend_decl; > > The dereferencing of ts.u's cl member is valid only, when ts.type is of > BT_CHARACTER. With al->expr being an unlimited polymorphic type, the > backend_decl is not available in cl. > > Although there is a backend_decl available in ts.u.derived, I was not able to > get it compatible for the fold_convert in the line following the assignment to > tmp: > > gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE(tmp), > se_sz.expr)); > > My current solution therefore is to execute those two statements only, when > ts.type is of BT_CHARACTER. My knowledge of unlimited polymorphic types is limited, but I think that this is not correct. The new length of the string has to be stored somewhere. If you don't do that, for example the intrinsic len() function won't work. > > Can someone explain what the fold_convert is doing in that specific place? I > assume that it is checking for and ensuring some type compatibility. Is there > some documentation available, explaining this? Is something similar needed for > the unlimited polymorphic variable? Well, I didn't find any documentation for fold_convert - except the code. In general, the fold_foo functions try to do foo, simplifying away useless operations. So fold_convert adds a type conversion, unless that is unnecessary (if the types are already the same for example). Mikael
Re: [Patch, Fortran] Fix DECL of namelist I/O function; fix FINALIZATION
Le 16/08/2014 00:10, Tobias Burnus a écrit : > This patch fixes two minor issues > > a) The argument issue mentioned in > https://gcc.gnu.org/ml/fortran/2014-08/msg7.html > The main issue is that the decl uses "void" as argument; the FE passes > IARG() alias gfc_array_index_type while the library expects a > GFC_INTEGER_4. As n_dim and ts->kind are small, I have chosen to keep > GFC_INTEGER_4 in the library and use int32_t for the argument and in the > decl. > As there is no testcase: did you get a confirmation that the reported issue is fixed with this? > b) resolve_finalizer calls at the end the function, which obtains the > vtab, which in turns calls the vtab function of the parent, which tries > to generate the _final entry, which requires that the finalizers are > resolved. In the test case, the parent's finalizer wasn't ready, leading > to an ICE in an assert. The patch now first resolves the parent's > finalizers before taking care of its own. > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? > The patch look good to me. Both of them. (close to obvious actually) Thanks. Mikael
Re: [PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable
> My knowledge of unlimited polymorphic types is limited, but I think that > this is not correct. My knowledge of unlimited polymorphic types is even more limited, then I cannot comment about the correctness of the patch. However > The new length of the string has to be stored somewhere. If you don't > do that, for example the intrinsic len() function won't work. if I add a line if (len(P) /= 20) call abort() in the 'type is (character(*))' block, the test still succeeds. Dominique
Re: [PATCH, Fortran] PR fortran/60414 fix ICE was: PR 60414: Patch proposal
Le 17/08/2014 14:26, Dominique Dhumieres a écrit :
> As Mikael said in https://gcc.gnu.org/ml/fortran/2014-08/msg00047.html
>
>> the testcase should check that the code generated is actually working,
>> not just that the ICE disappeared. ...
>
Well, this is for another patch where deferred character variable are
made acceptable as argument to unlimited polymorphic dummies.
Here the ICE comes (if I remember correctly) from the wrong generic
procedure being picked, so there is not really some new feature enabled
with the patch.
> thus I think the test should be run, i.e., '! { dg-do compile }' should
> be replaced with '! { dg-do run }' (I have checked that the test succeeds).
>
I don't have a strong opinion for it, but I'm OK with that change.
In fact the initial test was a run one, and it has been changed to
compile. Andre: why?
Mikael
Re: [PATCH] C frontend: cast-expressions sometimes retain type qualifiers
On Sun, Aug 17, 2014 at 8:27 AM, Marek Polacek wrote: > On Sat, Aug 16, 2014 at 09:54:33PM -0400, Patrick Palka wrote: >> --- a/gcc/c/c-typeck.c >> +++ b/gcc/c/c-typeck.c >> @@ -4947,6 +4947,8 @@ build_c_cast (location_t loc, tree type, tree expr) >> || TREE_CODE (type) == UNION_TYPE) >> pedwarn (loc, OPT_Wpedantic, >>"ISO C forbids casting nonscalar to the same type"); >> + >> + value = convert (type, value); > > Maybe a comment saying why we convert the value here anyway would be > useful. Otherwise LGTM. OK, I'll add the comment "Convert to remove any qualifiers from VALUE's type" to the patch.
Re: [PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable
Le 17/08/2014 14:46, Dominique Dhumieres a écrit : >> My knowledge of unlimited polymorphic types is limited, but I think that >> this is not correct. > > My knowledge of unlimited polymorphic types is even more limited, > then I cannot comment about the correctness of the patch. However > >> The new length of the string has to be stored somewhere. If you don't >> do that, for example the intrinsic len() function won't work. > > if I add a line > > if (len(P) /= 20) call abort() > > in the 'type is (character(*))' block, the test still succeeds. > Yeah, well. Good to know. Then I don't understand what the allocation code is doing. :-/ Sorry, I can't devote more time to that right now. Mikael
[C++] Handle && || ! for simd vectors
Hello,
as discussed in the PR, I did not add a sequence point, it can be done
later if we decide so (the other direction would be bad), but if we ever
do I believe we should add one to ?: at the same time.
For the mixed 'scalar && vector', I chose to implement it with a branch,
since we can, it made sense to me to give it semantics closer to
scalar && scalar, while 'vector && scalar' gets the same semantics as
'vector && vector' because there is no choice. So a&&b is always
equivalent to a?(b?T:F):F where T and F are vectors of the right type.
I replaced vector27, it was mostly a placeholder. I should probably remove
vector9 instead of updating it, it is pretty useless now.
I swapped save_expr and convert because gratuitously repeating the
conversion as many times as there are elements in the vector makes the
dumps quite horrible (and wastes compilation time).
Bootstrap+testsuite on x86_64-linux-gnu.
2014-08-18 Marc Glisse
PR c++/54427
PR c++/57198
PR c++/58845
gcc/c-family/
* c-common.c (warn_logical_operator): Punt for vectors.
gcc/cp/
* typeck.c (cp_build_binary_op): save_expr after convert to save
redundant operations.
[TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR]: Handle vectors.
(cp_build_unary_op) [TRUTH_NOT_EXPR]: Likewise.
gcc/
* doc/extend.texi (Vector Extensions): Document &&, ||, ! in C++.
gcc/testsuite/
* g++.dg/ext/vector9.C: Update, not an error anymore.
* g++.dg/ext/vector27.C: Replace with new test.
* g++.dg/ext/vector28.C: New file.
* g++.dg/other/error23.C: Update to a different error.
--
Marc GlisseIndex: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 214073)
+++ gcc/c-family/c-common.c (working copy)
@@ -1663,20 +1663,24 @@ warn_logical_operator (location_t locati
if (CONSTANT_CLASS_P (op_left) || CONSTANT_CLASS_P (op_right))
return;
/* This warning only makes sense with logical operands. */
if (!(truth_value_p (TREE_CODE (op_left))
|| INTEGRAL_TYPE_P (TREE_TYPE (op_left)))
|| !(truth_value_p (TREE_CODE (op_right))
|| INTEGRAL_TYPE_P (TREE_TYPE (op_right
return;
+ /* The range computations only work with scalars. */
+ if (VECTOR_TYPE_P (TREE_TYPE (op_left))
+ || VECTOR_TYPE_P (TREE_TYPE (op_right)))
+return;
/* We first test whether either side separately is trivially true
(with OR) or trivially false (with AND). If so, do not warn.
This is a common idiom for testing ranges of data types in
portable code. */
lhs = make_range (op_left, &in0_p, &low0, &high0, &strict_overflow_p);
if (!lhs)
return;
if (TREE_CODE (lhs) == C_MAYBE_CONST_EXPR)
lhs = C_MAYBE_CONST_EXPR_EXPR (lhs);
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 214073)
+++ gcc/cp/typeck.c (working copy)
@@ -4061,32 +4061,32 @@ cp_build_binary_op (location_t location,
{
enum stv_conv convert_flag = scalar_to_vector (location, code, op0, op1,
complain & tf_error);
switch (convert_flag)
{
case stv_error:
return error_mark_node;
case stv_firstarg:
{
- op0 = save_expr (op0);
op0 = convert (TREE_TYPE (type1), op0);
+ op0 = save_expr (op0);
op0 = build_vector_from_val (type1, op0);
type0 = TREE_TYPE (op0);
code0 = TREE_CODE (type0);
converted = 1;
break;
}
case stv_secondarg:
{
- op1 = save_expr (op1);
op1 = convert (TREE_TYPE (type0), op1);
+ op1 = save_expr (op1);
op1 = build_vector_from_val (type0, op1);
type1 = TREE_TYPE (op1);
code1 = TREE_CODE (type1);
converted = 1;
break;
}
default:
break;
}
}
@@ -4207,25 +4207,63 @@ cp_build_binary_op (location_t location,
|| (TREE_CODE (op1) == INTEGER_CST
&& ! integer_all_onesp (op1)));
common = 1;
}
break;
case TRUTH_ANDIF_EXPR:
case TRUTH_ORIF_EXPR:
case TRUTH_AND_EXPR:
case TRUTH_OR_EXPR:
- if (VECTOR_TYPE_P (type0) || VECTOR_TYPE_P (type1))
+ if (!VECTOR_TYPE_P (type0) && VECTOR_TYPE_P (type1))
{
- sorry ("logical operation on vector type");
- return error_mark_node;
+ if (!COMPARISON_CLASS_P (op1))
+ op1 = cp_build_binary_op (EXPR_LOCATION (op1), NE_EXPR, op1,
+ build_zero_cst (type1), complain);
+ if (code == TRUTH_ANDIF_EXPR)
+ {
+ tree z = bu
Re: [PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable
Le 17/08/2014 14:46, Dominique Dhumieres a écrit : >> My knowledge of unlimited polymorphic types is limited, but I think that >> this is not correct. > > My knowledge of unlimited polymorphic types is even more limited, > then I cannot comment about the correctness of the patch. However > >> The new length of the string has to be stored somewhere. If you don't >> do that, for example the intrinsic len() function won't work. > > if I add a line > > if (len(P) /= 20) call abort() > > in the 'type is (character(*))' block, the test still succeeds. > > Dominique > Here is a failing testcase. I must admit it wasn't easy to find, and it's probably at least as much a bug with select as with allocate. It seems that for unlimited polymorphic entities, the _size vtable field is used as character length. So there is no need to explicitly set the character length as the whole vtable is overwritten upon allocation. And the patch works. I don't know how we cope with non-default kind though (which is what the testcase is about). Mikael $ ./unlimited_polymorphic_20 here there Program aborted. Backtrace: #0 0x7FDFBA026B57 #1 0x7FDFBA028272 #2 0x7FDFBA0F3218 #3 0x400E24 in test_sub at unlimited_polymorphic_20.f90:24 (discriminator 1) #4 0x400C0D in test at unlimited_polymorphic_20.f90:6 Abandon $ program test call test_sub contains subroutine test_sub implicit none class(*), pointer :: P allocate(character(len=20, kind=4)::P) select type(P) type is (character(len=*, kind=4)) print *, "here" P ="some test string" if (P .ne. 4_"some test string") then call abort() end if print *, "there" if (len(P) /= 20) call abort print *, "not there" class default print *, "bah" call abort() end select deallocate(P) end subroutine test_sub end program test
Re: [PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable
> Here is a failing testcase. I was about to post the same test. The test fails with two counts: (1) len(P) == 80, (2) deallocate(P) fails with a.out(882,0x7fff75e1d310) malloc: *** error for object 0x7fc801c04978: incorrect checksum for freed object - object was probably modified after being freed. ... Dominique
Re: [PATCH 0/4] rs6000: Merge most logical SI and DI patterns
I wish that this patch did not need to use up another one of the primary constraint letters, but I guess there is no easy way around that. - David On Fri, Aug 15, 2014 at 8:50 PM, Segher Boessenkool wrote: > All patches were bootstrapped and regression checked separately, on > powerpc64-linux -m64,-m32,-m32/-mpowerpc64; no regressions. > > Is this okay to apply? > > > Segher > > > gcc/config/rs6000/constraints.md |3 +- > gcc/config/rs6000/htm.md |6 +- > gcc/config/rs6000/predicates.md | 23 +- > gcc/config/rs6000/rs6000-protos.h |2 +- > gcc/config/rs6000/rs6000.c| 83 +-- > gcc/config/rs6000/rs6000.md | 1319 > - > gcc/config/rs6000/vector.md | 22 +- > 7 files changed, 508 insertions(+), 950 deletions(-) > > -- > 1.8.1.4 >
Re: [PATCH,rs6000] Add pass to optimize away xxpermdi's from vector computations
On Wed, Aug 13, 2014 at 7:14 PM, Bill Schmidt wrote: > Hi, > > This patch adds a PowerPC-specific pass just prior to the first cse RTL > pass. The pass runs only when generating little-endian code for Power8 > with VSX enabled, and for -O1 and up. For this particular subtarget, > the use of the big-endian-biased vector load and store instructions > requires permutations to order vector elements for little endian. To > reduce the overhead of these permutations, this pass looks for > computations for which the exact lanes in which computations are > performed does not matter, so long as the results are returned to > storage in the proper order. For such computations we can remove the > xxpermdi's associated with the vector loads and stores. > > This patch relies on another patch posted today that converts a struct > used by the web pass into a base class that this patch can subclass. If > it's determined that the other patch isn't appropriate, then this patch > will need modifications to duplicate the union-find logic. > > A complete description of the new pass appears in rs6000.c (search for > "Analyze vector computations"). That description also identifies some > remaining opportunities we can follow up with later. > > A number of new tests are added to verify that the pass works as > expected for some vectorized code samples. > > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no > regressions. Is this ok for trunk? > > Thanks, > Bill > > > [gcc] > > 2014-08-13 Bill Schmidt > > * config/rs6000/rs6000.c (context.h): New include. > (tree-pass.h): Likewise. > (make_pass_analyze_swaps): New decl. > (rs6000_option_override): Register pass_analyze_swaps. > (swap_web_entry): New subsclass of web_entry_base (df.h). > (special_handling_values): New enum. > (union_defs): New function. > (union_uses): Likewise. > (insn_is_load_p): Likewise. > (insn_is_store_p): Likewise. > (insn_is_swap_p): Likewise. > (rtx_is_swappable_p): Likewise. > (insn_is_swappable_p): Likewise. > (chain_purpose): New enum. > (chain_contains_only_swaps): New function. > (mark_swaps_for_removal): Likewise. > (swap_const_vector_halves): Likewise. > (adjust_subreg_index): Likewise. > (permute_load): Likewise. > (permute_store): Likewise. > (handle_special_swappables): Likewise. > (replace_swap_with_copy): Likewise. > (dump_swap_insn_table): Likewise. > (rs6000_analyze_swaps): Likewise. > (pass_data_analyze_swaps): New pass_data. > (pass_analyze_swaps): New rtl_opt_pass. > (make_pass_analyze_swaps): New function. > * config/rs6000/rs6000.opt (moptimize-swaps): New option. > > [gcc/testsuite] > > 2014-08-13 Bill Schmidt > > * gcc.target/powerpc/swaps-p8-1.c: New test. > * gcc.target/powerpc/swaps-p8-2.c: New test. > * gcc.target/powerpc/swaps-p8-3.c: New test. > * gcc.target/powerpc/swaps-p8-4.c: New test. > * gcc.target/powerpc/swaps-p8-5.c: New test. > * gcc.target/powerpc/swaps-p8-6.c: New test. > * gcc.target/powerpc/swaps-p8-7.c: New test. > * gcc.target/powerpc/swaps-p8-8.c: New test. > * gcc.target/powerpc/swaps-p8-9.c: New test. > * gcc.target/powerpc/swaps-p8-10.c: New test. > * gcc.target/powerpc/swaps-p8-11.c: New test. > * gcc.target/powerpc/swaps-p8-12.c: New test. This looks okay, although I was hoping that other developers with more DF and web experience would double check. Why are you specifically gating the pass on POWER8? Thanks, David
Re: [PATCH 0/4] rs6000: Merge most logical SI and DI patterns
On Sun, Aug 17, 2014 at 02:43:09PM -0400, David Edelsohn wrote: > I wish that this patch did not need to use up another one of the > primary constraint letters, but I guess there is no easy way around > that. It doesn't use a new constraint, but I guess you mean the new output modifier (%e). We can now get rid of %b, if ever we can remove any constraint or output modifier (some asm code might use it, even if it was never documented). There are quite a few output codes and constraints we can do without. Segher
[GSoC][match-and-simplify] add more constant folding tests
We now have at-least one test-case for each of constant folding patterns
in match-constant-folding.pd
[gcc/testsuite/gcc.dg/tree-ssa]
* match-constant-folding.c: Add test-cases.
Thanks,
Prathamesh
Index: match-constant-folding.c
===
--- match-constant-folding.c (revision 214020)
+++ match-constant-folding.c (working copy)
@@ -55,4 +55,68 @@ int c6(int x)
}
/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) \\* t1_\\d\+ to x_\\d\+\\(D\\)" "ccp1" } } */
+/* x / 1 -> x */
+int c7(int x)
+{
+ int t1 = 1;
+ int c7_val = x / t1;
+ return c7_val;
+}
+/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) / t1_\\d\+ to x_\\d\+\\(D\\)" "ccp1" } } */
+
+/* x % x -> 1 */
+int c8(int x)
+{
+ int t1 = x;
+ int c8_val = x % t1;
+ return c8_val;
+}
+/* { dg-final { scan-tree-dump "gimple_simplified to c8_val_\\d\+ = 0" "forwprop1" } } */
+
+/* x | 0 -> x */
+int c9(int x)
+{
+ int t1 = 0;
+ int c9_val = x | t1;
+ return c9_val;
+}
+/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) | t1_\\d\+ to x_\\d\+\\(D\\)" "ccp1" } } */
+
+/* x | -1 -> -1 */
+int c10(int x)
+{
+ int t1 = -1;
+ int c10_val = x | t1;
+ return c10_val;
+}
+/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) | t1_\\d\+ to -1" "ccp1" } } */
+
+/* x & -1 -> x */
+int c11(int x)
+{
+ int t1 = -1;
+ int c11_val = x & t1;
+ return c11_val;
+}
+/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) & t1_\\d\+ to x_\\d\+\\(D\\)" "ccp1" } } */
+
+/* x & 0 -> 0 */
+int c12(int x)
+{
+ int t1 = 0;
+ int c12_val = x & t1;
+ return c12_val;
+}
+/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) & t1_\\d\+ to 0" "ccp1" } } */
+
+/* x ^ 0 -> x */
+int c13(int x)
+{
+ int t1 = 0;
+ int c13_val = x ^ t1;
+ return c13_val;
+}
+/* { dg-final { scan-tree-dump "Match-and-simplified x_\\d\+\\(D\\) \\^ t1_\\d\+ to x_\\d\+\\(D\\)" "ccp1" } } */
+
+
/* { dg-final { cleanup-tree-dump "forwprop2" } } */
[GSoC][match-and-simplify] simple doc-fix
[gcc/doc] * match-and-simplify.texi: Replace addres by address. Thanks, Prathamesh Index: match-and-simplify.texi === --- match-and-simplify.texi (revision 214020) +++ match-and-simplify.texi (working copy) @@ -22,7 +22,7 @@ tries to address several issues. To address these the project introduces a simple domain specific language to write expression simplifications from which code targeting GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the -fold_buildN API while for the GIMPLE variant and to addres 2) new +fold_buildN API while for the GIMPLE variant and to address 2) new APIs are introduced. @menu
Re: [wwwdocs] Re: gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(
On Fri, 15 Aug 2014, Oleg Endo wrote: > > How about the attached .html as a replacement for the current one? > > I removed the requirement of setting up a combined tree, as I believe > > it makes things much more easy. At least it's been working for me > > that way. Is this helpful / OK to commit? > > Maybe a patch is better in this case, instead of the whole .html. hm no likey, this is simply changing too much and making it SH-specific. Also, /usr/local is the default. brgds, H-P
Re: [GSoC][match-and-simplify] simple doc-fix
On Mon, Aug 18, 2014 at 2:11 AM, Prathamesh Kulkarni
wrote:
> [gcc/doc]
> * match-and-simplify.texi: Replace addres by address.
>
This version adds a small note for capturing expressions.
[gcc/doc]
* match-and-simplify.texi: Add documentation for capturing expressions.
Replace addres by address.
Thanks,
Prathamesh
> Thanks,
> Prathamesh
Index: match-and-simplify.texi
===
--- match-and-simplify.texi (revision 214020)
+++ match-and-simplify.texi (working copy)
@@ -22,7 +22,7 @@ tries to address several issues.
To address these the project introduces a simple domain specific language
to write expression simplifications from which code targeting GIMPLE
and GENERIC is auto-generated. The GENERIC variant follows the
-fold_buildN API while for the GIMPLE variant and to addres 2) new
+fold_buildN API while for the GIMPLE variant and to address 2) new
APIs are introduced.
@menu
@@ -152,6 +152,32 @@ to enable the replacement expression. T
of the @code{if} is a standard C expression which may contain references
to captures.
+Capturing Expressions:
+Captures can also be used for capturing results of sub-expressions.
+
+@smallexample
+#if GIMPLE
+(simplify
+ (pointer_plus (addr@@2 @@0) INTEGER_CST_P@@1)
+ (if (is_gimple_min_invariant (@@2)))
+ @{
+HOST_WIDE_INT off;
+tree base = get_addr_base_and_unit_offset (@@0, &off);
+off += tree_to_uhwi (@@1);
+/* Now with that we should be able to simply write
+ (addr (mem_ref (addr @@base) (plus @@off @@1))) */
+build1 (ADDR_EXPR, type,
+build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@@2)),
+build_fold_addr_expr (base),
+build_int_cst (ptr_type_node, off)));
+ @})
+#endif
+@end smallexample
+
+In the above example, @code{@@2} captures the result of the expression (addr @code{@@0}).
+For outermost expression only it's type can be captured, and the keyword
+@code{type} is reserved for this purpose.
+
@smallexample
(simplify
(bit_and:c integral_op_p@@0 (bit_ior:c (bit_not @@0) @@1))
Re: [PATCH 2/4] rs6000: Merge boolcsi3 and boolcdi3
On Fri, Aug 15, 2014 at 8:50 PM, Segher Boessenkool wrote: > 2014-08-15 Segher Boessenkool > > gcc/ > * config/rs6000/rs6000.md (*boolcsi3_internal1, *boolcsi3_internal2 > and split, *boolcsi3_internal3 and split): Delete. > (*boolcdi3_internal1, *boolcdi3_internal2 and split, > *boolcdi3_internal3 and split): Delete. > (*boolc3, *boolc3_dot, *boolc3_dot2): New. Thanks, David
Re: [PATCH 1/4] rs6000: Merge boolsi3 and booldi3
On Fri, Aug 15, 2014 at 8:50 PM, Segher Boessenkool wrote: > This adds a new output modifier "e" that prints an 's' for things like > xoris, and changes "u" to work for both xoris and xori. With that, both > SI and DI can simply use an "n" constraint, where previously they needed > "K,L" resp. "K,J" (and it used "JF" in fact, but the F doesn't do anything > there). > > > 2014-08-15 Segher Boessenkool > > gcc/ > * config/rs6000/rs6000.c (print_operand) <'e'>: New. > <'u'>: Also support printing the low-order 16 bits. > * config/rs6000/rs6000.md (iorsi3, xorsi3, *boolsi3_internal1, > *boolsi3_internal2 and split, *boolsi3_internal3 and split): Delete. > (iordi3, xordi3, *booldi3_internal1, *booldi3_internal2 and split, > *booldi3_internal3 and split): Delete. > (ior3, xor3, *bool3, *bool3_dot, > *bool3_dot2): New. > (two anonymous define_splits for non_logical_cint_operand): Merge. Okay. Thanks, Davd
Re: [PATCH 3/4] rs6000: Merge boolccsi3 and boolccdi3
On Fri, Aug 15, 2014 at 8:50 PM, Segher Boessenkool wrote: > 2014-08-15 Segher Boessenkool > > gcc/ > * config/rs6000/rs6000.md (*boolccsi3_internal1, *boolccsi3_internal2 > and split, *boolccsi3_internal3 and split): Delete. > (*boolccdi3_internal1, *boolccdi3_internal2 and split, > *boolccdi3_internal3 and split): Delete. > (*boolcc3, *boolcc3_dot, *boolcc3_dot2): New. > (*eqv3): Move. Add TODO comment. Fix attributes. Okay. Thanks, David
Re: [PATCH 4/4] rs6000: Merge andsi3 and anddi3
On Fri, Aug 15, 2014 at 8:50 PM, Segher Boessenkool
wrote:
> "AND" is more complex. It was a huge tangled mess, where very often the
> order of patterns mattered.
>
> So I made most patterns mutually exclusive (via their condition), and also
> made the "S" constraint (for mask64_operand) require TARGET_POWERPC64.
>
> There is no reason the various immediate-operand instructions should be
> the same pattern. Splitting this up is a nice cleanup, and also allows
> not using the clobber andi./andis. have for any of the other patterns.
> That in turn allows some minor cleanups elsewhere, too.
>
>
> 2014-08-15 Segher Boessenkool
>
> gcc/
> * config/rs6000/constraints.md ("S"): Require TARGET_POWERPC64.
> * config/rs6000/htm.md (ttest): Remove clobber.
> * config/rs6000/predicates.md (any_mask_operand): New predicate.
> (and_operand): Reformat.
> (and_2rld_operand): New predicate.
> * config/rs6000/rs6000-protos.h (rs6000_split_logical): Remove last
> parameter.
> * config/rs6000/rs6000.c (rs6000_split_logical_inner): Remove last
> parameter. Handle AND directly.
> (rs6000_split_logical_di): Remove last parameter.
> (rs6000_split_logical): Remove last parameter. Remove obsolete
> comment.
> * config/rs6000/rs6000.md (BOOL_REGS_AND_CR0): Delete.
> (one_cmpl2): Adjust call of rs6000_split_logical.
> (ctz2, ffs2): Delete clobber. Reformat.
> (andsi3, andsi3_mc, andsi3_nomc, *andsi3_internal2_mc,
> *andsi3_internal3_mc, *andsi3_internal4, *andsi3_internal5_mc,
> and 5 anonymous splitters): Delete.
> (and3): New expander.
> (*and3, *and3_dot, *and3_dot2): New.
> (and3_imm, *and3_imm_dot, *and3_imm_dot2): New.
> (*and3_mask, *and3_mask_dot, *and3_mask_dot2): New.
> (ior, xor3): Adjust call of rs6000_split_logical.
> (floatdisf2_internal1): Remove clobbers.
> (anddi3, anddi3_mc, anddi3_nomc, anddi3_internal2_mc,
> *anddi3_internal3_mc, and 4 anonymous splitters): Delete.
> (*anddi3_2rld, *anddi3_2rld_dot, *anddi3_2rld_dot2): New.
> (and3 for BOOL_128): Remove clobber.
> (*and3_internal for BOOL_128): Remove clobber. Adjust call of
> rs6000_split_logical.
> (*bool3_internal for BOOL_128): Adjust call of
> rs6000_split_logical.
> (*boolc3_internal1 for BOOL_128,
> *boolc3_internal2 for BOOL_128,
> *boolcc3_internal1 for BOOL_128,
> *boolcc3_internal2 for BOOL_128,
> *eqv3_internal1 for BOOL_128,
> *eqv3_internal2 for BOOL_128,
> *one_cmpl3_internal for BOOL_128): Ditto.
> * config/rs6000/vector.md (*vec_reload_and_plus_ clobber.
> (*vec_reload_and_reg_): Delete.
Okay.
Thanks, David
[PATCH] make excessive template instantiation depth a fatal error
Following a suggestion in PR16564, this patch makes excessive template instantiation depth a fatal error. In fact, this allows simplifying the code a lot, just by printing first the context (like we do for every other diagnostic) instead of printing it after (which is not possible for a fatal error). This changes the output of quite a few testcases, so before modifying those I would like to know whether the idea is OK. Examples of changed output are: [Before] g++.dg/cpp0x/decltype26.C:6:15: error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) substituting 'template decltype (f(T())) f(T) [with T = ]' g++.dg/cpp0x/decltype26.C:6:15: recursively required by substitution of 'template decltype (f(T())) f(T) [with T = A]' g++.dg/cpp0x/decltype26.C:6:15: required by substitution of 'template decltype (f(T())) f(T) [with T = A]' g++.dg/cpp0x/decltype26.C:13:8: required from here g++.dg/cpp0x/decltype26.C: In function 'int main()': g++.dg/cpp0x/decltype26.C:13:8: error: no matching function for call to 'f(A)' g++.dg/cpp0x/decltype26.C:6:18: note: candidate: template decltype (f(T())) f(T) g++.dg/cpp0x/decltype26.C:6:18: note: substitution of deduced template arguments resulted in errors seen above [After] g++.dg/cpp0x/decltype26.C: In substitution of 'template decltype (f(T())) f(T) [with T = A]': g++.dg/cpp0x/decltype26.C:6:15: recursively required by substitution of 'template decltype (f(T())) f(T) [with T = A]' g++.dg/cpp0x/decltype26.C:6:15: required by substitution of 'template decltype (f(T())) f(T) [with T = A]' g++.dg/cpp0x/decltype26.C:13:8: required from here g++.dg/cpp0x/decltype26.C:6:15: fatal error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) One interesting case is for operator->(). Here we have to adjust the location of the template instantiations so we can point the user to the point of recursion: [Before] g++.dg/template/arrow1.C:12:11: error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) instantiating 'a<(n + 1)> a::operator->() [with int n = 900]' g++.dg/template/arrow1.C:12:11: recursively required from 'a<(n + 1)> a::operator->() [with int n = 0]' g++.dg/template/arrow1.C:12:11: required from here g++.dg/template/arrow1.C:12:11: error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) instantiating 'struct a<901>' g++.dg/template/arrow1.C:12:11: recursively required from 'a<(n + 1)> a::operator->() [with int n = 0]' g++.dg/template/arrow1.C:12:11: required from here g++.dg/template/arrow1.C:12:11: error: invalid use of incomplete type 'struct a<901>' g++.dg/template/arrow1.C:5:8: note: declaration of 'struct a<901>' [After] g++.dg/template/arrow1.C: In instantiation of 'a<(n + 1)> a::operator->() [with int n = 899]': g++.dg/template/arrow1.C:7:2: recursively required from 'a<(n + 1)> a::operator->() [with int n = 1]' g++.dg/template/arrow1.C:7:2: required from 'a<(n + 1)> a::operator->() [with int n = 0]' g++.dg/template/arrow1.C:12:11: required from here g++.dg/template/arrow1.C:12:11: fatal error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) The rest of testcases follow the pattern: [Before] g++.dg/template/pr23510.C:9:1: error: expected ';' after struct definition g++.dg/template/pr23510.C:6:27: error: template instantiation depth exceeds maximum of 15 (use -ftemplate-depth= to increase the maximum) instantiating 'struct Factorial<5u>' g++.dg/template/pr23510.C:6:27: recursively required from 'struct Factorial<19u>' g++.dg/template/pr23510.C:6:27: required from 'struct Factorial<20u>' g++.dg/template/pr23510.C:21:20: required from here [After] g++.dg/template/pr23510.C:9:1: error: expected ';' after struct definition g++.dg/template/pr23510.C: In instantiation of 'struct Factorial<6u>': g++.dg/template/pr23510.C:6:27: recursively required from 'struct Factorial<19u>' g++.dg/template/pr23510.C:6:27: required from 'struct Factorial<20u>' g++.dg/template/pr23510.C:21:20: required from here g++.dg/template/pr23510.C:6:27: fatal error: template instantiation depth exceeds maximum of 15 (use -ftemplate-depth= to increase the maximum) Apart from these changes, the patch bootstraps and passes the regression suite on x86_64-linux. OK with the updated testcases? gcc/cp/ChangeLog: 2014-08-17 Manuel López-Ibáñez * error.c (print_instantiation_context): Delete. * typeck2.c (build_x_arrow): Record location when pushing template instantiation. * pt.c (push_tinst_level): Make it a wrapper around ... (push_tinst_level_loc): ... this. New function. Make excessive template instantiation depth a fatal error. Record location. Use bool as return type. (instantiate_pending_templates): Make excessive template instantiation depth a fatal error.
[PATCH] genemit: Print name of splitter to dumpfile
Currently, the splitter dumpfiles only say "scanning new insn with uid = N."
and "deleting insn with uid = N.". This makes it hard to track down which
splitter actually fired, especially so if there are many similar splitters
and one is slightly broken.
This patch makes the splitters write their name to the dumpfile when they
are called. As a side benefit it also becomes obvious in the dumpfiles
what "new insn"s belong together with what "deleting insn"s.
Bootstrapped and regression tested on powerpc64-linux, no new failures;
is this okay for mainline?
Segher
---
gcc/genemit.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/genemit.c b/gcc/genemit.c
index 16b5644..55e7372 100644
--- a/gcc/genemit.c
+++ b/gcc/genemit.c
@@ -578,6 +578,10 @@ gen_split (rtx split)
if (GET_CODE (split) == DEFINE_PEEPHOLE2)
output_peephole2_scratches (split);
+ printf (" if (dump_file)\n");
+ printf ("fprintf (dump_file, \"Splitting with gen_%s_%d\\n\");\n",
+ name, insn_code_number);
+
printf (" start_sequence ();\n");
/* The fourth operand of DEFINE_SPLIT is some code to be executed
@@ -813,6 +817,7 @@ from the machine description file `md'. */\n\n");
printf ("#include \"tm-constrs.h\"\n");
printf ("#include \"ggc.h\"\n");
printf ("#include \"basic-block.h\"\n");
+ printf ("#include \"dumpfile.h\"\n");
printf ("#include \"target.h\"\n\n");
printf ("#define FAIL return (end_sequence (), _val)\n");
printf ("#define DONE return (_val = get_insns (), end_sequence (),
_val)\n\n");
--
1.8.1.4
Re: [PATCH,rs6000] Add pass to optimize away xxpermdi's from vector computations
On Sun, 2014-08-17 at 14:52 -0400, David Edelsohn wrote: > On Wed, Aug 13, 2014 at 7:14 PM, Bill Schmidt > wrote: > > Hi, > > > > This patch adds a PowerPC-specific pass just prior to the first cse RTL > > pass. The pass runs only when generating little-endian code for Power8 > > with VSX enabled, and for -O1 and up. For this particular subtarget, > > the use of the big-endian-biased vector load and store instructions > > requires permutations to order vector elements for little endian. To > > reduce the overhead of these permutations, this pass looks for > > computations for which the exact lanes in which computations are > > performed does not matter, so long as the results are returned to > > storage in the proper order. For such computations we can remove the > > xxpermdi's associated with the vector loads and stores. > > > > This patch relies on another patch posted today that converts a struct > > used by the web pass into a base class that this patch can subclass. If > > it's determined that the other patch isn't appropriate, then this patch > > will need modifications to duplicate the union-find logic. > > > > A complete description of the new pass appears in rs6000.c (search for > > "Analyze vector computations"). That description also identifies some > > remaining opportunities we can follow up with later. > > > > A number of new tests are added to verify that the pass works as > > expected for some vectorized code samples. > > > > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no > > regressions. Is this ok for trunk? > > > > Thanks, > > Bill > > > > > > [gcc] > > > > 2014-08-13 Bill Schmidt > > > > * config/rs6000/rs6000.c (context.h): New include. > > (tree-pass.h): Likewise. > > (make_pass_analyze_swaps): New decl. > > (rs6000_option_override): Register pass_analyze_swaps. > > (swap_web_entry): New subsclass of web_entry_base (df.h). > > (special_handling_values): New enum. > > (union_defs): New function. > > (union_uses): Likewise. > > (insn_is_load_p): Likewise. > > (insn_is_store_p): Likewise. > > (insn_is_swap_p): Likewise. > > (rtx_is_swappable_p): Likewise. > > (insn_is_swappable_p): Likewise. > > (chain_purpose): New enum. > > (chain_contains_only_swaps): New function. > > (mark_swaps_for_removal): Likewise. > > (swap_const_vector_halves): Likewise. > > (adjust_subreg_index): Likewise. > > (permute_load): Likewise. > > (permute_store): Likewise. > > (handle_special_swappables): Likewise. > > (replace_swap_with_copy): Likewise. > > (dump_swap_insn_table): Likewise. > > (rs6000_analyze_swaps): Likewise. > > (pass_data_analyze_swaps): New pass_data. > > (pass_analyze_swaps): New rtl_opt_pass. > > (make_pass_analyze_swaps): New function. > > * config/rs6000/rs6000.opt (moptimize-swaps): New option. > > > > [gcc/testsuite] > > > > 2014-08-13 Bill Schmidt > > > > * gcc.target/powerpc/swaps-p8-1.c: New test. > > * gcc.target/powerpc/swaps-p8-2.c: New test. > > * gcc.target/powerpc/swaps-p8-3.c: New test. > > * gcc.target/powerpc/swaps-p8-4.c: New test. > > * gcc.target/powerpc/swaps-p8-5.c: New test. > > * gcc.target/powerpc/swaps-p8-6.c: New test. > > * gcc.target/powerpc/swaps-p8-7.c: New test. > > * gcc.target/powerpc/swaps-p8-8.c: New test. > > * gcc.target/powerpc/swaps-p8-9.c: New test. > > * gcc.target/powerpc/swaps-p8-10.c: New test. > > * gcc.target/powerpc/swaps-p8-11.c: New test. > > * gcc.target/powerpc/swaps-p8-12.c: New test. > > This looks okay, although I was hoping that other developers with more > DF and web experience would double check. Thanks for the review! > Why are you specifically gating the pass on POWER8? The problem is introduced in POWER8 (since LE isn't supported earlier), and I hope that this will no longer be necessary for -mcpu=power9. If for some reason this doesn't turn out to be the case, we'll need to make a change at that time, I suppose... Thanks, Bill > > Thanks, David >
[PATCH] Fix promotion of const local arrays to static storage
Hi,
The fix for PR38615 indirectly broke the promotion of const local arrays
to static storage in many cases. The commit in question, r143570, made
it so that only arrays that don't potentially escape from the scope in
which they're defined (i.e. arrays for which TREE_ADDRESSABLE is 0) are
candidates for the promotion to static storage.
The problem is that both the C and C++ frontends contain ancient code
(dating back to 1994) that sets the TREE_ADDRESSABLE bit on arrays
indexed by non-constant or out-of-range indices. As a result, const
arrays that are indexed by non-constant or out-of-range values are no
longer candidates for promotion to static storage following the fix to
PR38615, because their TREE_ADDRESSABLE bit will always be set.
Consequently, array promotion is essentially broken for a large class of
C and C++ code. E.g. this simple example is no longer a candidate for
promotion:
int
foo (int i)
{
const int x[] = { 1, 2, 3 };
return x[i]; /* non-constant index */
}
This patch removes the ancient code that is responsible for dubiously
setting the TREE_ADDRESSABLE bit on arrays indexed by non-constant or
out-of-range values. I don't think that this code is necessary or
useful anymore. Bootstrapped and regtested on x86_64-unknown-linux-gnu,
OK for trunk?
2014-08-18 Patrick Palka
* c-typeck.c (build_array_ref): Don't mark arrays indexed by
non-constant or out-of-range values as addressable.
2014-08-18 Patrick Palka
* typeck.c (build_array_ref): Don't mark arrays indexed by
non-constant or out-of-range values as addressable.
2014-08-18 Patrick Palka
* g++.dg/opt/static4.C: Check for static promotion.
* g++.dg/opt/static7.C: New test.
* gcc.dg/static1.c: New test.
---
gcc/c/c-typeck.c | 23 ---
gcc/cp/typeck.c| 25 -
gcc/testsuite/g++.dg/opt/static4.C | 4
gcc/testsuite/g++.dg/opt/static7.C | 12
gcc/testsuite/gcc.dg/static1.c | 12
5 files changed, 28 insertions(+), 48 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/opt/static7.C
create mode 100644 gcc/testsuite/gcc.dg/static1.c
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index e6745be..022ff8d 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -2487,29 +2487,6 @@ build_array_ref (location_t loc, tree array, tree index)
{
tree rval, type;
- /* An array that is indexed by a non-constant
-cannot be stored in a register; we must be able to do
-address arithmetic on its address.
-Likewise an array of elements of variable size. */
- if (TREE_CODE (index) != INTEGER_CST
- || (COMPLETE_TYPE_P (TREE_TYPE (TREE_TYPE (array)))
- && TREE_CODE (TYPE_SIZE (TREE_TYPE (TREE_TYPE (array !=
INTEGER_CST))
- {
- if (!c_mark_addressable (array))
- return error_mark_node;
- }
- /* An array that is indexed by a constant value which is not within
-the array bounds cannot be stored in a register either; because we
-would get a crash in store_bit_field/extract_bit_field when trying
-to access a non-existent part of the register. */
- if (TREE_CODE (index) == INTEGER_CST
- && TYPE_DOMAIN (TREE_TYPE (array))
- && !int_fits_type_p (index, TYPE_DOMAIN (TREE_TYPE (array
- {
- if (!c_mark_addressable (array))
- return error_mark_node;
- }
-
if (pedantic || warn_c90_c99_compat)
{
tree foo = array;
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index fa3283d..6dd056d 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -3112,31 +3112,6 @@ cp_build_array_ref (location_t loc, tree array, tree idx,
pointer arithmetic.) */
idx = cp_perform_integral_promotions (idx, complain);
- /* An array that is indexed by a non-constant
-cannot be stored in a register; we must be able to do
-address arithmetic on its address.
-Likewise an array of elements of variable size. */
- if (TREE_CODE (idx) != INTEGER_CST
- || (COMPLETE_TYPE_P (TREE_TYPE (TREE_TYPE (array)))
- && (TREE_CODE (TYPE_SIZE (TREE_TYPE (TREE_TYPE (array
- != INTEGER_CST)))
- {
- if (!cxx_mark_addressable (array))
- return error_mark_node;
- }
-
- /* An array that is indexed by a constant value which is not within
-the array bounds cannot be stored in a register either; because we
-would get a crash in store_bit_field/extract_bit_field when trying
-to access a non-existent part of the register. */
- if (TREE_CODE (idx) == INTEGER_CST
- && TYPE_DOMAIN (TREE_TYPE (array))
- && ! int_fits_type_p (idx, TYPE_DOMAIN (TREE_TYPE (array
- {
- if (!cxx_mark_addressable (array))
- return error_m
[C++] Remove contains_empty_class_p from class.c
It appears this is not used anywhere. Tested on i386-unknown-freebsd10.0.
Okay?
Gerald
2014-08-16 Gerald Pfeifer
* class.c (contains_empty_class_p): Remove.
Index: gcc/cp/class.c
===
--- gcc/cp/class.c (revision 214083)
+++ gcc/cp/class.c (working copy)
@@ -208,7 +208,6 @@
splay_tree_key k2);
static void warn_about_ambiguous_bases (tree);
static bool type_requires_array_cookie (tree);
-static bool contains_empty_class_p (tree);
static bool base_derived_from (tree, tree);
static int empty_base_at_nonzero_offset_p (tree, tree, splay_tree);
static tree end_of_base (tree);
@@ -7796,35 +7795,6 @@
return CLASSTYPE_EMPTY_P (type);
}
-/* Returns true if TYPE contains an empty class. */
-
-static bool
-contains_empty_class_p (tree type)
-{
- if (is_empty_class (type))
-return true;
- if (CLASS_TYPE_P (type))
-{
- tree field;
- tree binfo;
- tree base_binfo;
- int i;
-
- for (binfo = TYPE_BINFO (type), i = 0;
- BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i)
- if (contains_empty_class_p (BINFO_TYPE (base_binfo)))
- return true;
- for (field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field))
- if (TREE_CODE (field) == FIELD_DECL
- && !DECL_ARTIFICIAL (field)
- && is_empty_class (TREE_TYPE (field)))
- return true;
-}
- else if (TREE_CODE (type) == ARRAY_TYPE)
-return contains_empty_class_p (TREE_TYPE (type));
- return false;
-}
-
/* Returns true if TYPE contains no actual data, just various
possible combinations of empty classes and possibly a vptr. */
Re: [wwwdocs] Buildstat update for 4.5
On Sun, 17 Aug 2014, Tom G. Christensen wrote: > Latest results for 4.5.x > > -tgc > > Testresults for 4.5.4: > powerpc-apple-darwin8.11.0 Applied, thanks! Gerald
Re: [wwwdocs] Buildstat update for 4.8
On Sun, 17 Aug 2014, Tom G. Christensen wrote: > Testresults for 4.8.3: > x86_64-unknown-linux-gnu Applied, thanks! Gerald
