[Bug tree-optimization/65494] [5 Regression] Loop is not vectorized because of operand canonicalization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65494 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Mar 23 12:47:54 2015 New Revision: 221592 URL: https://gcc.gnu.org/viewcvs?rev=221592root=gccview=rev Log: 2015-03-23 Richard Biener rguent...@suse.de PR tree-optimization/65494 * tree-vect-slp.c (vect_build_slp_tree): Do not (re-)allocate matches here. (vect_analyze_slp_instance): But do that here, always and once. * gcc.dg/vect/pr65494.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr65494.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
Re: Offloading GSOC 2015
Hi Kirill, Thread hierarchy management and creation policy is very interesting topic for me as well. I came across that paper couple weeks ago. Creating more threads in the beginning and applying suchlike busy-waiting or if-master algorithm generally works better than dynamic parallelism due to the overhead of dp. Moreover compiler might close some optimizations when dp is enable. This paper Cuda-np[1] is also interesting about managing threads. And its idea is very close that to create more thread in advance instead of using dynamic parallelism. However in the other hand, sometimes dp has better performance since it let create new thread hierarchy. In order to clarify, I prepared 2 examples while using dynamic parallelism and creating more threads in advance. *(1st example) Better result is dynamic parallelism. *(2nd example) Better result is creating more threads in advance 1st example: https://github.com/grypp/gcc-proposal-omp4/tree/master/prop0 *(prop0.c) Has 4 nested iteration *(prop0.c:10)will put small array into shared memory *Iteration size of first two loop is expressed explicitly. even if they become clear in rt, ptx/spir can be changed *Last two iteration is sizes are dynamic and dependent of first two iterations' induction variables *(prop0.c:24 - 28) there are array accessing in very inefficient way (non-coalesced) -If we put (prop0.c:21) #parallel for -*It will create another kernel (prop0_dynamic.cu:34) -*array accessing style will change (prop0_dynamic.cu:48 - 52) Basically advantages of creating dynamic parallelism in this point: 1- Accessing style to array is changed with coalasced 2- we could get rid of 3rd and 4th for loop since we could create thread as iteration size. (little advantage in terms of thread divergencency) 2nd example: https://github.com/grypp/gcc-proposal-omp4/tree/master/prop1 *Has 2 nested iteration *Innermost loop has reduction *I put 3 possible generated cuda code example *1 - prop1_baseline.cu : only cudaize prop1.c:8 and don't take account prop1.c:12 *2 - prop1_createMoreThread.cu : create more thread for innermost loop. Do reduction with extra threads. communicate by using shared memory. *3 - prop1_dynamic.cu : create child kernel. Communicate by using global memory. but allocate global memory in advance at prop1_dynamic.cu:5 Full version of prop1 calculates nbody. I benchmarked with y reserach compiler [2] and put results here https://github.com/grypp/gcc-proposal-omp4/blob/master/prop1/prop1-bench.pdf . As is seen from that figure, 2nd kernel has best performance. When we compare these 2 example, my roughly idea about this issue that, it might be good idea to implement an inspector by using compiler analyzing algorithms in order to decide whether dynamic parallelism will be used or not. Thus it also can be possible to avoid extra slowdown since compiler closes optimization when dp is enable. Besides there is some another cases exist while we can take advantage of dp such as recursive algorithms. Moreover using stream is available even if not guarantee concurrency (it also causes overhead). In addition to this, i can work on if-master or busy-waiting logic. I am really willing to work on thread hierarchy management and creation policy. if it is interesting for gcc, how can i progress on this topic? By the way, i haven't worked on #omp simd. it could be match with warps (if there is no dependency among loops). (in nvidia side) since threads in same warp can read their data with __shfl, data clauses can be used to enhance performance. (Not sure) [1] - http://people.engr.ncsu.edu/hzhou/ppopp_14_1.pdf [2] - http://link.springer.com/chapter/10.1007%2F978-3-319-11454-5_16 Güray Özen ~grypp 2015-03-20 15:47 GMT+01:00 Kirill Yukhin kirill.yuk...@gmail.com: Hello Güray, On 20 Mar 12:14, guray ozen wrote: I've started to prepare my gsoc proposal for gcc's openmp for gpus. I think that here is wide range for exploration. As you know, OpenMP 4 contains vectorization pragmas (`pragma omp simd') which not perfectly suites for GPGPU. Another problem is how to create threads dynamically on GPGPU. As far as we understand it there're two possible solutions: 1. Use dynamic parallelism available in recent API (launch new kernel from target) 2. Estimate maximum thread number on host and start them all from host, making unused threads busy-waiting There's a paper which investigates both approaches [1], [2]. However i'm little bit confused about which ideas, i mentioned last my mail, should i propose or which one of them is interesting for gcc. I'm willing to work on data clauses to enhance performance of shared memory. Or maybe it might be interesting to work on OpenMP 4.1 draft version. How do you think i should propose idea? We're going to work on OpenMP 4.1 offloading features. [1] - http://openmp.org/sc14/Booth-Sam-IBM.pdf [2] - http://dl.acm.org/citation.cfm?id=2688364 -- Thanks, K
[Bug libgcc/57221] [4.8/4.9/5 regression] libgcc symbol visibility changes break Android blobs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57221 --- Comment #9 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Hi Bero, I'm working on reproducing this. How do you build the android toolchain? Is it manual or do you have this scripted? In particular, do you use a pre-generated sysroot with Bionic or do you build the C library as part of the toolchain? Thanks.
[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65504 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org
[PATCH] Fix PR65494
This fixes PR65494 - I don't remember why I re-allocated matches
before recursing into operands. But that at least breaks backtracking.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-03-23 Richard Biener rguent...@suse.de
PR tree-optimization/65494
* tree-vect-slp.c (vect_build_slp_tree): Do not (re-)allocate
matches here.
(vect_analyze_slp_instance): But do that here, always and once.
* gcc.dg/vect/pr65494.c: New testcase.
Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 221532)
+++ gcc/tree-vect-slp.c (working copy)
@@ -926,14 +926,9 @@ vect_build_slp_tree (loop_vec_info loop_
bool *matches, unsigned *npermutes, unsigned *tree_size,
unsigned max_tree_size)
{
- unsigned nops, i, this_npermutes = 0, this_tree_size = 0;
+ unsigned nops, i, this_tree_size = 0;
gimple stmt;
- if (!matches)
-matches = XALLOCAVEC (bool, group_size);
- if (!npermutes)
-npermutes = this_npermutes;
-
matches[0] = false;
stmt = SLP_TREE_SCALAR_STMTS (*node)[0];
@@ -1012,7 +1007,6 @@ vect_build_slp_tree (loop_vec_info loop_
return false;
}
- bool *matches = XALLOCAVEC (bool, group_size);
if (vect_build_slp_tree (loop_vinfo, bb_vinfo, child,
group_size, max_nunits, loads,
vectorization_factor, matches,
@@ -1637,9 +1631,11 @@ vect_analyze_slp_instance (loop_vec_info
loads.create (group_size);
/* Build the tree for the SLP instance. */
+ bool *matches = XALLOCAVEC (bool, group_size);
+ unsigned npermutes = 0;
if (vect_build_slp_tree (loop_vinfo, bb_vinfo, node, group_size,
max_nunits, loads,
- vectorization_factor, NULL, NULL, NULL,
+ vectorization_factor, matches, npermutes, NULL,
max_tree_size))
{
/* Calculate the unrolling factor based on the smallest type. */
Index: gcc/testsuite/gcc.dg/vect/pr65494.c
===
--- gcc/testsuite/gcc.dg/vect/pr65494.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr65494.c (working copy)
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-additional-options -Ofast -funroll-loops } */
+
+typedef unsigned char uchar;
+typedef struct rgb_ {uchar r; uchar g; uchar b;} rgb;
+#define N 512
+rgb in[N], out[N];
+float c[N];
+void foo(int n)
+{
+ int i, j;
+ for (i = 0; i n; i++) //in and out are RGB byte arrays
+{
+ float r = 0, g = 0, b = 0;
+ for (j = 0; j 5; j++)
+ {
+ r += (float)in[i + j].r * c[j];
+ g += (float)in[i + j].g * c[j];
+ b += (float)in[i + j].b * c[j];
+ }
+ out[i].r = (uchar)r;
+ out[i].g = (uchar)g;
+ out[i].b = (uchar)b;
+}
+}
+
+/* { dg-final { scan-tree-dump vectorized 1 loops in function vect {
target { vect_float vect_intfloat_cvt } } } } */
+/* { dg-final { cleanup-tree-dump vect } } */
[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 Bug 24196 depends on bug 24882, which changed state. Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/16612] empty basic_strings can't live in shared memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612 Bug 16612 depends on bug 24882, which changed state. Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 Bug 21334 depends on bug 24882, which changed state. Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495 Bug 19495 depends on bug 24882, which changed state. Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Done for GCC 5
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW CC||jakub at gcc dot gnu.org
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||charlet at gcc dot gnu.org,
||ebotcazou at gcc dot gnu.org
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Ah, except ada_demangle is also exported from libgnat*.so - wonder why the RTS
is built with IN_GCC.
In that case, guess the Ada folks need to decide which one of the two to keep,
and/or if one of them (either adadecode.[ch], or {include,libiberty}/* one
shouldn't be renamed to something else.
I haven't found any uses of either of those, except the libiberty demangler
that calls ada_demangle but it could very well call a static routine instead.
[Bug c++/64931] ICE on function with deduced return type and input is instantiated template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64931
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Slightly more reduced:
templatetypename T
struct S {
T data[32];
};
auto
foo (Sint x)
{
return x;
}
The problem is that we create a RESULT_DECL with NULL DECL_SIZE, and gimplifier
ICEs on that. The RESULT_DECL is created in convert_for_initialization called
from check_return_expr I think.
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Hi Mikael, thanks for looking at the patch. Please note, that Paul has sent an addendum to the patches for 60322, which I deliberately have attached. 26/02/2015 18:17, Andre Vehreschild a écrit : This first patch is only preparatory and does not change any of the semantics of gfortran at all. Sure? With the counterexample you found below, this of course is a wrong statement. diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index ab6f7a5..d28cf77 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) lval-symtree = gfc_find_symtree (sym-ns-sym_root, sym-name); /* It will always be a full array. */ - lval-rank = sym-as ? sym-as-rank : 0; + as = sym-as; + lval-rank = as ? as-rank : 0; if (lval-rank) -gfc_add_full_array_ref (lval, sym-ts.type == BT_CLASS ? - CLASS_DATA (sym)-as : sym-as); +gfc_add_full_array_ref (lval, as); This is a change of semantics. Or do you know that sym-ts.type != BT_CLASS? You are completely right. I have made a mistake here. I have to tell the truth, I never ran a regtest with only part 1 of the patches applied. The second part of the patch will correct this, by setting the variable as depending on whether type == BT_CLASS or not. Sorry for the mistake. diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 3664824..e571a17 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, tree dummy) tree decl; tree type; gfc_array_spec *as; + symbol_attribute *array_attr; char *name; gfc_packed packed; int n; bool known_size; - if (sym-attr.pointer || sym-attr.allocatable - || (sym-as sym-as-type == AS_ASSUMED_RANK)) + /* Use the array as and attr. */ + as = sym-as; + array_attr = sym-attr; + + /* The pointer attribute is always set on a _data component, therefore check + the sym's attribute only. */ + if (sym-attr.pointer || array_attr-allocatable + || (as as-type == AS_ASSUMED_RANK)) return dummy; Any reason to sometimes use array_attr, sometimes not, like here? By the way, the comment is misleading: for classes, there is the class_pointer attribute (and it is a pain, I know). Yes, and a good one. Array_attr is sometimes sym-attr and sometimes CLASS_DATA(sym)-attr aka sym-ts.u.derived-components-attr. In the later case .pointer is always set to 1 in the _data component's attr. I.e., the above if, would always yield true for a class_array, which is not intended, but rather destructive. I know about the class_pointer attribute, but I figured, that it is not relevant here. Any idea how to formulate the comment better, to reflect what I just explained? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de ---BeginMessage--- Dear Andre and Dominique, I have found that LOC is returning the address of the class container rather than the _data component for class scalars. See the source below, which you will recognise! A fix is attached. Note that the scalar allocate fails with MOLD= and so I substituted SOURCE=. Cheers Paul class(*), allocatable :: a(:), e ! Change 'e' to an array and second memcpy works correctly ! Problem is with loc(e), which returns the address of the ! class container. allocate (e, source = 99.0) allocate (a(2), source = [1.0, 2.0]) call add_element_poly (a,e) select type (a) type is (real) print *, a end select contains subroutine add_element_poly(a,e) use iso_c_binding class(*),allocatable,intent(inout),target :: a(:) class(*),intent(in),target :: e class(*),allocatable,target :: tmp(:) type(c_ptr) :: dummy interface function memcpy(dest,src,n) bind(C,name=memcpy) result(res) import type(c_ptr) :: res integer(c_intptr_t),value :: dest integer(c_intptr_t),value :: src integer(c_size_t),value :: n end function end interface if (.not.allocated(a)) then allocate(a(1), source=e) else allocate(tmp(size(a)),source=a) deallocate(a) allocate(a(size(tmp)+1),source=e) ! mold gives a segfault dummy = memcpy(loc(a(1)),loc(tmp),sizeof(tmp)) dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e)) end if end subroutine end Index: gcc/fortran/trans-intrinsic.c === *** gcc/fortran/trans-intrinsic.c (revision 221500) --- gcc/fortran/trans-intrinsic.c (working copy) *** gfc_conv_intrinsic_loc (gfc_se * se, gfc *** 7080,7086 arg_expr = expr-value.function.actual-expr; if (arg_expr-rank == 0) !
[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65504 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35108 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35108action=edit gcc5-pr65504.patch Patch I'm going to bootstrap/regtest now.
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35109 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35109action=edit gcc5-pr65522.patch Seems the ada/adadecode.[ch] (ada_demangle) function is totally unused.
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 --- Comment #51 from Jonathan Wakely redi at gcc dot gnu.org --- This is no longer an issue when using the new non-reference-counted std::string implementation in GCC 5.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #11 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to David Edelsohn from comment #10) I believe that the choice to scalarize is based on the vector cost model. Hm, that would be interesting. The applied patch changes the cost model to favor the unaligned store on VSX. Might be a place where it should be using the cost model but perhaps isn't? I'll look into it later this week.
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Ah, except ada_demangle is also exported from libgnat*.so - wonder why the
RTS is built with IN_GCC.
This is explained in gcc-interface/Makefile.in.
In that case, guess the Ada folks need to decide which one of the two to
keep, and/or if one of them (either adadecode.[ch], or {include,libiberty}/*
one shouldn't be renamed to something else.
I think your patch is fine, but I'll let Arno approve it.
Re: ARC length attribute patch
On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Assuming you tested it, this patch is OK.
Re: ARC length attribute patch
On 23/03/15 11:22, Joern Wolfgang Rennecke wrote: On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Assuming you tested it, this patch is OK. Sorry, I replied to the wrong patch - I meant to reply to your email with the patch that only adds a COND_EXEC check for the maybe_limm case. And we've beeen discussing this on the wrong mailing list - this thread should been started gcc-patches@gcc.gnu.org; As this is not netnews where you can meaningfully set a followup-to, I changed the To: accordingly and put g...@gnu.org only in the Bcc
[Bug c++/64570] error: non-trivial conversion at assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64570 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to David Binderman from comment #4) Seems ok with trunk dated 20150322. No, it still fails. You're probably using an --enable-checking=release compiler...
Re: [Patch, Fortran, v1] Cosmetics and code simplify
Le 20/03/2015 14:51, Andre Vehreschild a écrit : Hi all, during checking that pr 61275 is really fixed, I found a indentation issue and a piece of my former code, that could be done nicer and more readable. This patch addresses both these issues. Bootstraps and regtests ok on x86_64-linux-gnu/F20. Ok for trunk? OK, thanks. Mikael
RE: [PATCH, GCC, stage1] Fallback to copy-prop if constant-prop not possible
From: Steven Bosscher [mailto:stevenb@gmail.com]
Sent: Friday, March 20, 2015 8:14 PM
I put the cprop_reg_p check there instead of !HARD_REGISTER_P
because
I like to be able to quickly find all places where a similar check is
performed. The check is whether the reg is something that copy
propagation can handle, and that is what I added cprop_reg_p for.
Makes sense indeed. I didn't think about the meaning of it.
(Note that cprop can _currently_ handle only pseudos but there is no
reason why a limited set of hard regs can't be handled also, e.g. the
flag registers like in targetm.fixed_condition_code_regs).
In this case, the result is that REG_P is checked twice.
But then again, cprop_reg_p will be inlined and the double check
optimized away.
True.
Anyway, I guess we've bikeshedded long enough over this patch as it is
:-) Let's post a final form and declare it OK for stage1.
What about the cprop_reg_p that needs to be negated? Did I miss something
that makes it ok?
As for PSEUDO_REG_P: If it were up to me, I'd like to have in rtl.h:
static bool
hard_register_p (rtx x)
{
return (REG_P (x) HARD_REGISTER_NUM_P (REGNO (x)));
}
static bool
pseudo_register_p (rtx x)
{
return (REG_P (x) !HARD_REGISTER_NUM_P (REGNO (x)));
}
and do away with all the FIRST_PSEUDO_REGISTER tests. But I've
proposed this in the past and there was opposition. Perhaps when we
introduce a rtx_reg class...
Ok I'll try to dig up what was the reasons presented. Anyway, it would
be done in a separate patch so not a problem for this one.
FYI testing your patch with the one cprop_reg_p negated as said in my
previous email shows no regression on arm-none-eabi cross-compiler
targeting Cortex-M3. Testing for x86_64 is ongoing.
Best regards,
Thomas
Re: [Patch, Fortran, pr55901, v1] [OOP] type is (character(len=*)) misinterpreted as array
Dear Andre, Yes, that's right. The first three (vtab rework 1/2 and pr64787) are combined and reformatted in the .diff file that I sent you. Please use that and then apply the pr55901 patch. This is what I am okaying. Cheers Paul On 23 March 2015 at 10:45, Andre Vehreschild ve...@gmx.de wrote: Hi Paul, thanks for the reviews. Let me ask one questions before I do something wrong. You have reviewed and approved (with changes) the patches: - vtab_access_rework1_v1.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html - vtab_access_rework2_v1.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html - pr64787_v2.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html and - pr55901_v1.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00086.html , right? I am asking so explicitly, because there are four more patches from me in the wild, that await review (not necessarily from you, Paul), namely: - pr60322_base_1.patch https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html - pr60322_3.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00032.html - crashfix2_v1.patch (small patch, ~100 loc)) https://gcc.gnu.org/ml/fortran/2015-03/msg00063.html and - cosm_simp.patch (tiny patch, ~20 loc) https://gcc.gnu.org/ml/fortran/2015-03/msg00088.html Please don't get me wrong on this. I just want to prevent misunderstandings here. The latter four patches are not yet approved, right? I will now apply the 4.9-trunk patch and wait for your answer before applying the above four on vtab_rework pr64787 and pr55901. Regards, Andre On Mon, 23 Mar 2015 08:33:51 +0100 Paul Richard Thomas paul.richard.tho...@gmail.com wrote: Dear Andre, I am persuaded by the arguments of Jerry and Dominique that this is good for trunk. Please commit as early as possible in order that any regressions can be caught, if possible, before release. Thanks Paul On 21 March 2015 at 15:11, Paul Richard Thomas paul.richard.tho...@gmail.com wrote: Dear Andre, I have applied the three preliminary patches but have not yet applied the attached one for PR55901. As advertised the composite patch bootstraps and regtests on FC21,x86_64. I went through gfc_trans_allocate and cleaned up the formatting and some of the text in the comments. You did a heroic job to tidy up this function and so I thought that I should do my bit - one of the feature, previously, was that the line length often went well in excess of the gcc style guide limit of 72 and this tended to make it somewhat unreadable. I have not been rigorous about this, especially when readability would be impaired thereby, but it does look a lot better now. The composite diff is attached. Not only does the Metcalf example run correctly but also the PGI Insider linked list example. I have attached a version of this modified to function as a gfortran.dg testcase. With the attributions in there, I do not think that there are any copyright issues. The article itself has no copyright notice. I would very much like to say that this is OK for trunk but we are hard up against the end of stage 4 and so it should really wait for backporting to 5.2. Thanks for the patches Paul On 19 March 2015 at 16:13, Andre Vehreschild ve...@gmx.de wrote: Hi all, please find attached the parts missing to stop valgrind's complaining about the use of uninitialized memory. The issue was, that when constructing a temporary class-object to call a routine with unlimited polymorphic arguments, the _len component was never set. This is fixed by this patch now. Note, the patch is based on all these preliminary patches: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html Bootstraps and regtests ok on x86_64-linux-gnu/F20. Please review! - Andre -- Andre Vehreschild * Email: vehre ad gmx dot de -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx -- Andre Vehreschild * Email: vehre ad gmx dot de -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: [PATCH, GCC, stage1] Fallback to copy-prop if constant-prop not possible
On Mon, Mar 23, 2015 at 12:01 PM, Thomas Preud'homme wrote: What about the cprop_reg_p that needs to be negated? Did I miss something that makes it ok? You didn't miss anything. I sent the wrong patch. The one I tested on ppc64 also has the condition reversed: @@ -1328,9 +1329,8 @@ implicit_set_cond_p (const_rtx cond) if (GET_CODE (cond) != EQ GET_CODE (cond) != NE) return false; - /* The first operand of COND must be a pseudo-reg. */ - if (! REG_P (XEXP (cond, 0)) - || HARD_REGISTER_P (XEXP (cond, 0))) + /* The first operand of COND must be a register we can propagate. */ + if (! cprop_reg_p (XEXP (cond, 0))) return false; /* The second operand of COND must be a suitable constant. */
[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 --- Comment #9 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Mar 23 11:58:49 2015 New Revision: 221591 URL: https://gcc.gnu.org/viewcvs?rev=221591root=gccview=rev Log: gcc/fortran/ChangeLog 2015-03-23 Andre Vehreschild ve...@gmx.de Janus Weil ja...@gcc.gnu.org Backported from mainline PR fortran/60255 Initial patch version: Janus Weil * class.c (gfc_get_len_component): New. (gfc_build_class_symbol): Add _len component to unlimited polymorphic entities. (find_intrinsic_vtab): Removed emitting of error message. * gfortran.h: Added prototype for gfc_get_len_component. * simplify.c (gfc_simplify_len): Use _len component where available. * trans-expr.c (gfc_class_len_get): New. (gfc_conv_intrinsic_to_class): Add handling for deferred character arrays. (gfc_conv_structure): Treat _len component correctly. (gfc_conv_expr): Prevent bind_c handling when not required. (gfc_trans_pointer_assignment): Propagate _len component. * trans-stmt.c (class_has_len_component): New. (trans_associate_var): _len component treatement for associate context. (gfc_trans_allocate): Same as for trans_associate_var() * trans.h: Add prototype for gfc_class_len_get. gcc/testsuite/ChangeLog 2015-03-20 Andre Vehreschild ve...@gmx.de Backport from mainline PR fortran/60255 * gfortran.dg/unlimited_polymorphic_2.f03: Removed error. Converted from dos to unix line endings. * gfortran.dg/unlimited_polymorphic_20.f03: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f03 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/class.c branches/gcc-4_9-branch/gcc/fortran/gfortran.h branches/gcc-4_9-branch/gcc/fortran/simplify.c branches/gcc-4_9-branch/gcc/fortran/trans-expr.c branches/gcc-4_9-branch/gcc/fortran/trans-stmt.c branches/gcc-4_9-branch/gcc/fortran/trans.h branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03
[Bug c++/64570] error: non-trivial conversion at assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64570 --- Comment #4 from David Binderman dcb314 at hotmail dot com --- Seems ok with trunk dated 20150322.
[Bug fortran/64952] Missing temporary in assignment from elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #6) Thanks for finishing the job. I have yet to fix 4.9 as well, as you suggested. In a week or so. Will you post a message on the clf thread, or would you like me to do it? It's better if you do it, I don't follow clf discussions.
[Bug c++/64570] error: non-trivial conversion at assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64570 --- Comment #6 from David Binderman dcb314 at hotmail dot com --- (In reply to Markus Trippelsdorf from comment #5) No, it still fails. You're probably using an --enable-checking=release compiler... Indeed I am, sorry for the false alarm.
[Bug libstdc++/65473] Including ciso646 does not define __GLIBCXX__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473 --- Comment #2 from Louis Dionne ldionne.2 at gmail dot com --- Does the standard specify which headers should define those macros? If not, then it's a QOI issue that could easily be solved. In all cases, does stdcxx document which headers must be included in order to get those definitions? I couldn't find it.
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
26/02/2015 18:17, Andre Vehreschild a écrit : This first patch is only preparatory and does not change any of the semantics of gfortran at all. Sure? diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index ab6f7a5..d28cf77 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) lval-symtree = gfc_find_symtree (sym-ns-sym_root, sym-name); /* It will always be a full array. */ - lval-rank = sym-as ? sym-as-rank : 0; + as = sym-as; + lval-rank = as ? as-rank : 0; if (lval-rank) -gfc_add_full_array_ref (lval, sym-ts.type == BT_CLASS ? - CLASS_DATA (sym)-as : sym-as); +gfc_add_full_array_ref (lval, as); This is a change of semantics. Or do you know that sym-ts.type != BT_CLASS? diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 3664824..e571a17 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, tree dummy) tree decl; tree type; gfc_array_spec *as; + symbol_attribute *array_attr; char *name; gfc_packed packed; int n; bool known_size; - if (sym-attr.pointer || sym-attr.allocatable - || (sym-as sym-as-type == AS_ASSUMED_RANK)) + /* Use the array as and attr. */ + as = sym-as; + array_attr = sym-attr; + + /* The pointer attribute is always set on a _data component, therefore check + the sym's attribute only. */ + if (sym-attr.pointer || array_attr-allocatable + || (as as-type == AS_ASSUMED_RANK)) return dummy; Any reason to sometimes use array_attr, sometimes not, like here? By the way, the comment is misleading: for classes, there is the class_pointer attribute (and it is a pain, I know). Mikael
[Bug ada/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- This boils down to: with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; with Interfaces;use Interfaces; package P is type Arr is array (Unsigned_32 range ) of Unbounded_String; end P; compiled at -O2 with SJLJ exceptions.
[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65523 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-23 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-23 CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Svn revision 221590 fails |[5 Regression] Svn revision |bootstrap - |221590 fails bootstrap - |../libiberty/libiberty.a(cp |../libiberty/libiberty.a(cp |lus-dem.o): In function |lus-dem.o): In function |`ada_demangle': |`ada_demangle': |cplus-dem.c:(.text+0xdb8): |cplus-dem.c:(.text+0xdb8): |multiple definition of |multiple definition of |`ada_demangle' |`ada_demangle' |ada/adadecode.o:adadecode.c |ada/adadecode.o:adadecode.c |:(.text+0x863): first |:(.text+0x863): first |defined here|defined here Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed by Andreas.
Re: [commited, Fortran, Backport to 4.9, pr60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
Hi all,
commited as r221591 to gcc_4.9-branch. Okayed by Paul via IRC on 2015-03-22.
Thanks, Paul.
gcc/fortran/ChangeLog
2015-03-23 Andre Vehreschild ve...@gmx.de
Janus Weil ja...@gcc.gnu.org
Backported from mainline
PR fortran/60255
Initial patch version: Janus Weil
* class.c (gfc_get_len_component): New.
(gfc_build_class_symbol): Add _len component to unlimited
polymorphic entities.
(find_intrinsic_vtab): Removed emitting of error message.
* gfortran.h: Added prototype for gfc_get_len_component.
* simplify.c (gfc_simplify_len): Use _len component where
available.
* trans-expr.c (gfc_class_len_get): New.
(gfc_conv_intrinsic_to_class): Add handling for deferred
character arrays.
(gfc_conv_structure): Treat _len component correctly.
(gfc_conv_expr): Prevent bind_c handling when not required.
(gfc_trans_pointer_assignment): Propagate _len component.
* trans-stmt.c (class_has_len_component): New.
(trans_associate_var): _len component treatement for associate
context.
(gfc_trans_allocate): Same as for trans_associate_var()
* trans.h: Add prototype for gfc_class_len_get.
gcc/testsuite/ChangeLog
2015-03-20 Andre Vehreschild ve...@gmx.de
Backport from mainline
PR fortran/60255
* gfortran.dg/unlimited_polymorphic_2.f03: Removed error.
Converted from dos to unix line endings.
* gfortran.dg/unlimited_polymorphic_20.f03: New test.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 221590)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,11 @@
+2015-03-20 Andre Vehreschild ve...@gmx.de
+
+ Backport from mainline
+ PR fortran/60255
+ * gfortran.dg/unlimited_polymorphic_2.f03: Removed error.
+ Converted from dos to unix line endings.
+ * gfortran.dg/unlimited_polymorphic_20.f03: New test.
+
2015-03-23 Yvan Roux yvan.r...@linaro.org
Backport from trunk r216841.
Index: gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03
===
--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 (Revision 221590)
+++ gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 (Arbeitskopie)
@@ -1,80 +1,80 @@
-! { dg-do compile }
-!
-! Test the most important constraints unlimited polymorphic entities
-!
-! Contributed by Paul Thomas pa...@gcc.gnu.org
-!and Tobias Burnus bur...@gcc.gnu.org
-!
- CHARACTER(:), allocatable, target :: chr ! { dg-error TODO: Deferred character length variable }
-! F2008: C5100
- integer :: i(2)
- logical :: flag
- class(*), pointer :: u1, u2(:) ! { dg-error cannot appear in COMMON }
- common u1
- u1 = chr
-! F2003: C625
- allocate (u1) ! { dg-error requires either a type-spec or SOURCE tag }
- allocate (real :: u1)
- Allocate (u1, source = 1.0)
-
-! F2008: C4106
- u2 = [u1] ! { dg-error shall not be unlimited polymorphic }
-
- i = u2 ! { dg-error Can\\'t convert CLASS\\(\\*\\) }
-
-! Repeats same_type_as_1.f03 for unlimited polymorphic u2
- flag = same_type_as (i, u2) ! { dg-error cannot be of type INTEGER }
- flag = extends_type_of (i, u2) ! { dg-error cannot be of type INTEGER }
-
-contains
-
-! C717 (R735) If data-target is unlimited polymorphic,
-! data-pointer-object shall be unlimited polymorphic, of a sequence
-! derived type, or of a type with the BIND attribute.
-!
- subroutine bar
-
-type sq
- sequence
- integer :: i
-end type sq
-
-type(sq), target :: x
-class(*), pointer :: y
-integer, pointer :: tgt
-
-x%i = 42
-y = x
-call foo (y)
-
-y = tgt ! This is OK, of course.
-tgt = y ! { dg-error must be unlimited polymorphic }
-
-select type (y) ! This is the correct way to accomplish the previous
- type is (integer)
-tgt = y
-end select
-
- end subroutine bar
-
-
- subroutine foo(tgt)
-class(*), pointer, intent(in) :: tgt
-type t
- sequence
- integer :: k
-end type t
-
-type(t), pointer :: ptr
-
-ptr = tgt ! C717 allows this.
-
-select type (tgt)
-! F03:C815 or F08:C839
- type is (t) ! { dg-error shall not specify a sequence derived type }
-ptr = tgt ! { dg-error Expected TYPE IS }
-end select
-
-print *, ptr%k
- end subroutine foo
-END
+! { dg-do compile }
+!
+! Test the most important constraints unlimited polymorphic entities
+!
+! Contributed by Paul Thomas pa...@gcc.gnu.org
+!and Tobias Burnus bur...@gcc.gnu.org
+!
+ CHARACTER(:), allocatable, target :: chr
+! F2008: C5100
+ integer :: i(2)
+ logical :: flag
+ class(*), pointer :: u1, u2(:) ! { dg-error cannot appear in COMMON }
+ common u1
+ u1 = chr
+! F2003: C625
+ allocate (u1) ! { dg-error requires either a
[Bug rtl-optimization/65504] [4.9/5 Regression] select case with strings and -fgcse -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65504
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org ---
--- gcc/config/i386/i386.c.jj2015-03-23 08:47:53.0 +0100
+++ gcc/config/i386/i386.c2015-03-23 13:11:43.416147457 +0100
@@ -23457,12 +23457,19 @@ counter_mode (rtx count_exp)
static rtx
ix86_copy_addr_to_reg (rtx addr)
{
+ rtx reg;
if (GET_MODE (addr) == Pmode || GET_MODE (addr) == VOIDmode)
-return copy_addr_to_reg (addr);
+{
+ reg = copy_addr_to_reg (addr);
+ REG_POINTER (reg) = 1;
+ return reg;
+}
else
{
gcc_assert (GET_MODE (addr) == DImode Pmode == SImode);
- return gen_rtx_SUBREG (SImode, copy_to_mode_reg (DImode, addr), 0);
+ reg = copy_to_mode_reg (DImode, addr);
+ REG_POINTER (reg) = 1;
+ return gen_rtx_SUBREG (SImode, reg, 0);
}
}
@@ -24354,6 +24361,8 @@ expand_set_or_movmem_prologue_epilogue_b
*destptr = expand_simple_binop (GET_MODE (*destptr), PLUS, *destptr,
GEN_INT (prolog_size),
NULL_RTX, 1, OPTAB_DIRECT);
+ if (REG_P (*destptr) REG_P (saveddest) REG_POINTER (*saveddest))
+REG_POINTER (*destptr) = 1;
*destptr = expand_simple_binop (GET_MODE (*destptr), AND, *destptr,
GEN_INT (-desired_align),
*destptr, 1, OPTAB_DIRECT);
@@ -24363,8 +24372,8 @@ expand_set_or_movmem_prologue_epilogue_b
saveddest, 1, OPTAB_DIRECT);
/* Adjust srcptr and count. */
if (!issetmem)
-*srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
saveddest,
-*srcptr, 1, OPTAB_DIRECT);
+*srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
+ saveddest, *srcptr, 1, OPTAB_DIRECT);
*count = expand_simple_binop (GET_MODE (*count), PLUS, *count,
saveddest, *count, 1, OPTAB_DIRECT);
/* We copied at most size + prolog_size. */
fixes this for me. Without the REG_POINTER flags, aliasing is really confused
on what is a pointer and what is not, as the prologue of the misaligned memcpy
uses
adjusteddest = dest -align;
src = src - (adjusteddest - dest)
and from these only one has REG_POINTER flag after the propagation, so aliasing
makes a wrong decision from that.
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Le 23/03/2015 13:43, Andre Vehreschild a écrit : Hi Mikael, thanks for looking at the patch. Please note, that Paul has sent an addendum to the patches for 60322, which I deliberately have attached. 26/02/2015 18:17, Andre Vehreschild a écrit : This first patch is only preparatory and does not change any of the semantics of gfortran at all. Sure? With the counterexample you found below, this of course is a wrong statement. diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index ab6f7a5..d28cf77 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) lval-symtree = gfc_find_symtree (sym-ns-sym_root, sym-name); /* It will always be a full array. */ - lval-rank = sym-as ? sym-as-rank : 0; + as = sym-as; + lval-rank = as ? as-rank : 0; if (lval-rank) -gfc_add_full_array_ref (lval, sym-ts.type == BT_CLASS ? - CLASS_DATA (sym)-as : sym-as); +gfc_add_full_array_ref (lval, as); This is a change of semantics. Or do you know that sym-ts.type != BT_CLASS? You are completely right. I have made a mistake here. I have to tell the truth, I never ran a regtest with only part 1 of the patches applied. The second part of the patch will correct this, by setting the variable as depending on whether type == BT_CLASS or not. Sorry for the mistake. diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 3664824..e571a17 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, tree dummy) tree decl; tree type; gfc_array_spec *as; + symbol_attribute *array_attr; char *name; gfc_packed packed; int n; bool known_size; - if (sym-attr.pointer || sym-attr.allocatable - || (sym-as sym-as-type == AS_ASSUMED_RANK)) + /* Use the array as and attr. */ + as = sym-as; + array_attr = sym-attr; + + /* The pointer attribute is always set on a _data component, therefore check + the sym's attribute only. */ + if (sym-attr.pointer || array_attr-allocatable + || (as as-type == AS_ASSUMED_RANK)) return dummy; Any reason to sometimes use array_attr, sometimes not, like here? By the way, the comment is misleading: for classes, there is the class_pointer attribute (and it is a pain, I know). Yes, and a good one. Array_attr is sometimes sym-attr and sometimes CLASS_DATA(sym)-attr aka sym-ts.u.derived-components-attr. In the later case .pointer is always set to 1 in the _data component's attr. I.e., the above if, would always yield true for a class_array, which is not intended, but rather destructive. I know about the class_pointer attribute, but I figured, that it is not relevant here. Any idea how to formulate the comment better, to reflect what I just explained? This pointer stuff is very difficult to swallow to me. I understand that for classes, the CLASS_DATA (sym)-pointer is always set, but almost everywhere the checks for pointerness are like (sym-ts.type != BT_CLASS sym-attr.pointer) || (sym-ts.type == BT_CLASS CLASS_DATA (sym)-attr.class_pointer) and I don't see a convincing reason to have it different here. At least gfc_is_nodesc_array should return 0 if sym-ts.type == BT_CLASS which solves the problem there; for the other cases, I think that class_pointer should be looked at. gfc_build_class_symbol clears the sym-attr.pointer flag for class containers so it doesn't make sense to test that flag. Mikael
[PATCH] Fix PR65518
This fixes PR65518 where the vectorizer builds a gigantic
load/interleaving chain for single element interleaving with
a very large distance. This situation isn't really supported
(and works by luck with generating absymal code), thus the following
simply disables support for it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-03-23 Richard Biener rguent...@suse.de
PR tree-optimization/65518
* tree-vect-stmts.c (vectorizable_load): Reject single-element
interleaving cases we generate absymal code for.
* gcc.dg/vect/pr65518.c: New testcase.
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 221532)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -5780,6 +5780,22 @@ vectorizable_load (gimple stmt, gimple_s
gcc_assert (! nested_in_vect_loop !STMT_VINFO_GATHER_P (stmt_info));
first_stmt = GROUP_FIRST_ELEMENT (stmt_info);
+
+ /* If this is single-element interleaving with an element distance
+ that leaves unused vector loads around punt - we at least create
+very sub-optimal code in that case (and blow up memory,
+see PR65518). */
+ if (first_stmt == stmt
+ !GROUP_NEXT_ELEMENT (stmt_info)
+ GROUP_SIZE (stmt_info) TYPE_VECTOR_SUBPARTS (vectype))
+ {
+ if (dump_enabled_p ())
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+single-element interleaving not supported
+for not adjacent vector loads\n);
+ return false;
+ }
+
if (!slp !PURE_SLP_STMT (stmt_info))
{
group_size = GROUP_SIZE (vinfo_for_stmt (first_stmt));
Index: gcc/testsuite/gcc.dg/vect/pr65518.c
===
--- gcc/testsuite/gcc.dg/vect/pr65518.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr65518.c (working copy)
@@ -0,0 +1,43 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+typedef struct giga
+{
+ unsigned int g[16];
+} giga;
+
+unsigned long __attribute__((noinline,noclone))
+addfst(giga const *gptr, int num)
+{
+ unsigned int retval = 0;
+ int i;
+ for (i = 0; i num; i++)
+retval += gptr[i].g[0];
+ return retval;
+}
+
+int main ()
+{
+ struct giga g[8];
+ unsigned int n = 1;
+ int i, j;
+ for (i = 0; i 8; ++i)
+for (j = 0; j 16; ++j)
+ {
+ g[i].g[j] = n++;
+ __asm__ volatile ();
+ }
+ if (addfst (g, 8) != 456)
+abort ();
+ return 0;
+}
+
+/* We don't want to vectorize the single-element interleaving in the way
+ we currently do that (without ignoring not needed vectors in the
+ gap between gptr[0].g[0] and gptr[1].g[0]), because that's very
+ sub-optimal and causes memory explosion (even though the cost model
+ should reject that in the end). */
+
+/* { dg-final { scan-tree-dump-times vectorized 0 loops in function 2 vect
} } */
+/* { dg-final { cleanup-tree-dump vect } } */
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
--- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
+++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
@@ -0,0 +1,9 @@
+/* { dg-lto-do link } */
+/* { dg-options -O2 -Wno-odr } */
Wasn't this supposed to be dg-lto-options instead?
I'm getting
WARNING: lto.exp does not support dg-options in primary source file
otherwise.
Jakub
[Bug tree-optimization/65518] gcc consumes all memory with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65518 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Mar 23 14:59:57 2015 New Revision: 221595 URL: https://gcc.gnu.org/viewcvs?rev=221595root=gccview=rev Log: 2015-03-23 Richard Biener rguent...@suse.de PR tree-optimization/65518 * tree-vect-stmts.c (vectorizable_load): Reject single-element interleaving cases we generate absymal code for. * gcc.dg/vect/pr65518.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr65518.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/65518] gcc consumes all memory with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Known to fail|5.0 |4.8.3, 4.9.2 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Mon, Mar 23, 2015 at 3:59 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
--- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
+++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
@@ -0,0 +1,9 @@
+/* { dg-lto-do link } */
+/* { dg-options -O2 -Wno-odr } */
Wasn't this supposed to be dg-lto-options instead?
I'm getting
WARNING: lto.exp does not support dg-options in primary source file
otherwise.
Yep - dg-options works in secondary files only (and applies to compile-time).
Richard.
Jakub
[PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
Hi!
As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses
src = src - (adjusted_dest - dest)
without proper REG_POINTER flags the aliasing code is very easily confused
on what is really a pointer and what is not - as REG_POINTER was used
after forwprop only on dest, but not on anything else, aliasing code thinks
that the memcpy reads dest based memory, when it really reads src based
memory (in the testcase frame pointer based in the end, but CSE did not see
it through).
Fixed by marking pseudos that must hold pointers with REG_POINTER during
the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
2015-03-23 Jakub Jelinek ja...@redhat.com
PR target/65504
* config/i386/i386.c (ix86_copy_addr_to_reg): Set REG_POINTER
on the pseudo.
(expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): Set
REG_POINTER on *destptr after adjusting it for prologue size.
* gfortran.dg/pr65504.f90: New test.
--- gcc/config/i386/i386.c.jj 2015-03-23 08:47:53.0 +0100
+++ gcc/config/i386/i386.c 2015-03-23 13:38:40.573983052 +0100
@@ -23457,12 +23457,19 @@ counter_mode (rtx count_exp)
static rtx
ix86_copy_addr_to_reg (rtx addr)
{
+ rtx reg;
if (GET_MODE (addr) == Pmode || GET_MODE (addr) == VOIDmode)
-return copy_addr_to_reg (addr);
+{
+ reg = copy_addr_to_reg (addr);
+ REG_POINTER (reg) = 1;
+ return reg;
+}
else
{
gcc_assert (GET_MODE (addr) == DImode Pmode == SImode);
- return gen_rtx_SUBREG (SImode, copy_to_mode_reg (DImode, addr), 0);
+ reg = copy_to_mode_reg (DImode, addr);
+ REG_POINTER (reg) = 1;
+ return gen_rtx_SUBREG (SImode, reg, 0);
}
}
@@ -24354,6 +24361,8 @@ expand_set_or_movmem_prologue_epilogue_b
*destptr = expand_simple_binop (GET_MODE (*destptr), PLUS, *destptr,
GEN_INT (prolog_size),
NULL_RTX, 1, OPTAB_DIRECT);
+ if (REG_P (*destptr) REG_P (saveddest) REG_POINTER (saveddest))
+ REG_POINTER (*destptr) = 1;
*destptr = expand_simple_binop (GET_MODE (*destptr), AND, *destptr,
GEN_INT (-desired_align),
*destptr, 1, OPTAB_DIRECT);
@@ -24363,8 +24372,8 @@ expand_set_or_movmem_prologue_epilogue_b
saveddest, 1, OPTAB_DIRECT);
/* Adjust srcptr and count. */
if (!issetmem)
- *srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
saveddest,
- *srcptr, 1, OPTAB_DIRECT);
+ *srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
+ saveddest, *srcptr, 1, OPTAB_DIRECT);
*count = expand_simple_binop (GET_MODE (*count), PLUS, *count,
saveddest, *count, 1, OPTAB_DIRECT);
/* We copied at most size + prolog_size. */
--- gcc/testsuite/gfortran.dg/pr65504.f90.jj2015-03-23 13:39:44.050945860
+0100
+++ gcc/testsuite/gfortran.dg/pr65504.f90 2015-03-23 13:39:57.707722713
+0100
@@ -0,0 +1,28 @@
+! PR target/65504
+! { dg-do run }
+
+program pr65504
+ implicit none
+ type :: T
+character (len=256) :: a
+character (len=256) :: b
+ end type T
+ type (T) :: c
+ type (T) :: d
+ c = foo (test)
+ d = foo (test)
+ if (trim(c%b) .ne. foo) call abort
+ contains
+ type (T) function foo (x) result (v)
+character(len=*), intent(in) :: x
+select case (x)
+case (test)
+ v%b = 'foo'
+case (bazx)
+ v%b = 'barx'
+case default
+ print *, unknown
+ stop
+end select
+ end function foo
+end program pr65504
Jakub
[Bug ipa/65521] [5 Regression] nondeterministic -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65521 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Mar 23 15:17:20 2015 New Revision: 221596 URL: https://gcc.gnu.org/viewcvs?rev=221596root=gccview=rev Log: PR ipa/65521 * ipa-icf.c (sem_item::update_hash_by_addr_refs): Hash ultimate_alias_target ()-order ints instead of ultimate_alias_target () pointers. * gcc.dg/pr65521.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr65521.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/testsuite/ChangeLog
Re: [PATCH] Fix warnings from including fdl.texi into gnat-style.texi
On Fri, 20 Mar 2015, Tom de Vries wrote: The gnat-style.texi part is OK. I cannot approve the fdl part though. Gerald, Can you approve the fdl part? Let's assume I can. Okay. Can you just describe the _why_ a bit in a @comment (in simple words beyond showing the error message), that is, what the issue is and how you avoid it? That should help someone coming in later, trying to understand. Gerald
[PATCH] Don't hash pointers for IPA ICF, instead hash -order ints (PR ipa/65521)
Hi!
The recent IPA ICF hashing changes broke -fcompare-debug, hashing in
pointers is not stable not just for -fcompare-debug, but supposedly even
just different runs with the exact same options could yield different
assembly. Hashing on DECL_UID is not good either, that is not guaranteed to
be the same for -g/-g0.
symtab_node::order is printed in the -fdump-final-insns= dumps, so I assume
it must be stable across -g/-g0.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-03-23 Jakub Jelinek ja...@redhat.com
PR ipa/65521
* ipa-icf.c (sem_item::update_hash_by_addr_refs): Hash
ultimate_alias_target ()-order ints instead of
ultimate_alias_target () pointers.
* gcc.dg/pr65521.c: New test.
--- gcc/ipa-icf.c.jj2015-03-23 08:47:53.0 +0100
+++ gcc/ipa-icf.c 2015-03-23 11:02:53.129630089 +0100
@@ -575,7 +575,7 @@ sem_item::update_hash_by_addr_refs (hash
{
ref = node-iterate_reference (i, ref);
if (ref-address_matters_p () || !m_symtab_node_map.get (ref-referred))
- hstate.add_ptr (ref-referred-ultimate_alias_target ());
+ hstate.add_int (ref-referred-ultimate_alias_target ()-order);
}
if (is_a cgraph_node * (node))
@@ -585,7 +585,7 @@ sem_item::update_hash_by_addr_refs (hash
{
sem_item **result = m_symtab_node_map.get (e-callee);
if (!result)
- hstate.add_ptr (e-callee-ultimate_alias_target ());
+ hstate.add_int (e-callee-ultimate_alias_target ()-order);
}
}
--- gcc/testsuite/gcc.dg/pr65521.c.jj 2015-03-23 11:03:16.190252436 +0100
+++ gcc/testsuite/gcc.dg/pr65521.c 2015-03-23 11:02:07.0 +0100
@@ -0,0 +1,39 @@
+/* PR ipa/65521 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fcompare-debug } */
+
+struct S { int s; };
+int f6 (void *, unsigned long);
+int f7 (int, int *, unsigned long);
+int f8 (void);
+int f9 (void (*) (void));
+
+int
+f1 (void *p)
+{
+ return f6 (p, 256UL);
+}
+
+int
+f2 (void *p)
+{
+ return f6 (p, 256UL);
+}
+
+int
+f3 (struct S *x)
+{
+ return f7 (f8 (), x-s, 16UL);
+}
+
+int
+f4 (struct S *x)
+{
+ return f7 (f8 (), x-s, 16UL);
+}
+
+void
+f5 (void)
+{
+ f9 (f5);
+}
Jakub
Re: [PATCH] Don't hash pointers for IPA ICF, instead hash -order ints (PR ipa/65521)
On Mon, 23 Mar 2015, Jakub Jelinek wrote:
Hi!
The recent IPA ICF hashing changes broke -fcompare-debug, hashing in
pointers is not stable not just for -fcompare-debug, but supposedly even
just different runs with the exact same options could yield different
assembly. Hashing on DECL_UID is not good either, that is not guaranteed to
be the same for -g/-g0.
symtab_node::order is printed in the -fdump-final-insns= dumps, so I assume
it must be stable across -g/-g0.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2014-03-23 Jakub Jelinek ja...@redhat.com
PR ipa/65521
* ipa-icf.c (sem_item::update_hash_by_addr_refs): Hash
ultimate_alias_target ()-order ints instead of
ultimate_alias_target () pointers.
* gcc.dg/pr65521.c: New test.
--- gcc/ipa-icf.c.jj 2015-03-23 08:47:53.0 +0100
+++ gcc/ipa-icf.c 2015-03-23 11:02:53.129630089 +0100
@@ -575,7 +575,7 @@ sem_item::update_hash_by_addr_refs (hash
{
ref = node-iterate_reference (i, ref);
if (ref-address_matters_p () || !m_symtab_node_map.get
(ref-referred))
- hstate.add_ptr (ref-referred-ultimate_alias_target ());
+ hstate.add_int (ref-referred-ultimate_alias_target ()-order);
}
if (is_a cgraph_node * (node))
@@ -585,7 +585,7 @@ sem_item::update_hash_by_addr_refs (hash
{
sem_item **result = m_symtab_node_map.get (e-callee);
if (!result)
- hstate.add_ptr (e-callee-ultimate_alias_target ());
+ hstate.add_int (e-callee-ultimate_alias_target ()-order);
}
}
--- gcc/testsuite/gcc.dg/pr65521.c.jj 2015-03-23 11:03:16.190252436 +0100
+++ gcc/testsuite/gcc.dg/pr65521.c2015-03-23 11:02:07.0 +0100
@@ -0,0 +1,39 @@
+/* PR ipa/65521 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fcompare-debug } */
+
+struct S { int s; };
+int f6 (void *, unsigned long);
+int f7 (int, int *, unsigned long);
+int f8 (void);
+int f9 (void (*) (void));
+
+int
+f1 (void *p)
+{
+ return f6 (p, 256UL);
+}
+
+int
+f2 (void *p)
+{
+ return f6 (p, 256UL);
+}
+
+int
+f3 (struct S *x)
+{
+ return f7 (f8 (), x-s, 16UL);
+}
+
+int
+f4 (struct S *x)
+{
+ return f7 (f8 (), x-s, 16UL);
+}
+
+void
+f5 (void)
+{
+ f9 (f5);
+}
Jakub
--
Richard Biener rguent...@suse.de
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
[PATCH] Fix Ada bootstrap (PR bootstrap/65522)
Hi!
Honza's recent change to use the libiberty demangler inside of gcc
broke Ada bootstrap. The issue is that there is a symbol clash,
libiberty contains ada_demangle symbol (with one API), and ada/adadecode.c
(since around 3.3 time, claimed for compatibility) contains another one,
with incompatible API, guarded with IN_GCC. IN_GCC for some strange reason
in Ada means that it is linked both into gnat1 and libgnat*.{a,so}.
This means that current trunk fails to bootstrap, because there are
two ada_demangle definitions being linked in.
gnat1 doesn't use ada_demangle for anything, libgnat*.{a,so} only exports it
but there are no direct users, and ada_demangle in libiberty is used froim
the same file, but not elsewhere from what I could find.
In any case, for compatibility, this patch just changes the guard so that
adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
into gnat1, which can then successfully link against libiberty cplus-dem.o.
The ipa-devirt.c change is obvious IMHO, the same header is included a few
lines above this.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-03-23 Jakub Jelinek ja...@redhat.com
PR bootstrap/65522
* ipa-devirt.c: Remove duplicate demangle.h include.
* adadecode.c (ada_demangle): Guard with IN_RTS instead of IN_GCC.
--- gcc/ipa-devirt.c.jj 2015-03-23 08:47:53.0 +0100
+++ gcc/ipa-devirt.c2015-03-23 13:52:49.937174740 +0100
@@ -166,7 +166,6 @@ along with GCC; see the file COPYING3.
#include gimple-pretty-print.h
#include stor-layout.h
#include intl.h
-#include demangle.h
/* Hash based set of pairs of types. */
typedef struct
--- gcc/ada/adadecode.c.jj 2012-01-23 18:23:54.0 +0100
+++ gcc/ada/adadecode.c 2015-03-23 13:53:35.869429888 +0100
@@ -6,7 +6,7 @@
* *
* C Implementation File *
* *
- * Copyright (C) 2001-2012, Free Software Foundation, Inc.*
+ * Copyright (C) 2001-2015, Free Software Foundation, Inc.*
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@ -368,7 +368,7 @@ __gnat_decode (const char *coded_name, c
extern C {
#endif
-#ifdef IN_GCC
+#ifdef IN_RTS
char *
ada_demangle (const char *coded_name)
{
Jakub
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
On Mon, Mar 23, 2015 at 4:07 PM, Jakub Jelinek ja...@redhat.com wrote: As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses src = src - (adjusted_dest - dest) without proper REG_POINTER flags the aliasing code is very easily confused on what is really a pointer and what is not - as REG_POINTER was used after forwprop only on dest, but not on anything else, aliasing code thinks that the memcpy reads dest based memory, when it really reads src based memory (in the testcase frame pointer based in the end, but CSE did not see it through). Fixed by marking pseudos that must hold pointers with REG_POINTER during the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2015-03-23 Jakub Jelinek ja...@redhat.com PR target/65504 * config/i386/i386.c (ix86_copy_addr_to_reg): Set REG_POINTER on the pseudo. (expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): Set REG_POINTER on *destptr after adjusting it for prologue size. * gfortran.dg/pr65504.f90: New test. OK. Thanks, Uros.
[Bug ipa/65521] [5 Regression] nondeterministic -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65521 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thanks!
Unnamed Struct / Union
Hi All ,
GCC 4.8.3 ,pop up with below error
/home/i16382/an.c:13:18: error: duplicate member 'bOriginator'
unsigned bOriginator;
^
for the case
union
{
struct
{
unsigned bStatusType;
unsigned bOriginator;
};
struct
{
unsigned originator;
unsigned memoryContentsChanged;
unsigned interruptPending;
unsigned bOriginator;
};
} USB_WORD;
is that expected behaviour ?
Thank you
~Umesh
[Bug ipa/65521] [5 Regression] nondeterministic -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65521 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- But even hashing DECL_UIDs rather than hashing pointers is a no-go here, pointers can be arbitrary, for DECL_UIDs we at least have the guarantee that -g and -g0 DECL_UIDs compare the same, but there can be bigger gaps in between them for -g. Dunno if symtab_node's order field can be used reliably for this or not (or it could hash -name () string).
[Bug ipa/65521] [5 Regression] nondeterministic -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65521 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35105 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35105action=edit gcc5-pr65521.patch This fixes this for me. But I haven't done any in-depth analysis whether the symtab order fields are always identical between -g and -g0.
[Bug ipa/65502] pure-const should play well with clobbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65502 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|6.0 |--- --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I think we can safely ignore clobbers when scanning functions for pure/constness.
[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65506 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Looks good to me.
[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65506 --- Comment #4 from dave.anglin at bell dot net --- On 2015-03-23 10:05 AM, jakub at gcc dot gnu.org wrote: Indeed, have verified this with the cross-compiler and the attached patch should cure this. I have applied the patch for testing but hit pr65522 regression. Restarted build without ada. Will take about a day to confirm fix. Dave
[Bug ada/65524] gnatbind generates decrementing the unexisting elab-counter into finalize_library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65524 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-23 CC||charlet at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Arnaud Charlet charlet at gcc dot gnu.org --- Sounds interesting/puzzling. But we really need a reproducer/test case to work from.
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #35109|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35112 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35112action=edit gcc5-pr65522.patch I'm actually testing a slightly adjusted variant that keeps the compatibility ada_demangle in libgnat* for ABI reasons, but not in gnat1 which doesn't use it and thus can link against libiberty.
[Bug c++/59254] confusing diagnostic for undefined template shadowed by declaration in inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59254
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-23
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Confirmed on trunk.
The difference between 'struct' and 'class' in my original example is not
relevant:
namespace outer {
inline namespace inner {
templatetypename T struct A;
}
templatetypename T struct A;
template struct Aint;
}
[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65500 --- Comment #3 from dave.anglin at bell dot net --- On 2015-03-23 10:02 AM, redi at gcc dot gnu.org wrote: 3) Use fixincludes to change either the definition of __LWP_RWLOCK_VALID to (short)0x8c91 or change the definition of PTHREAD_RWLOCK_INITIALIZER to use (short)__LWP_RWLOCK_VALID Instead of (short)0x8c91, I am testing patch with value changed to -29551. The libstdc++ testsuite was clean with hppa64. However, I hit a new issue in 32-bit build this morning. Dave
[Bug tree-optimization/65494] [5 Regression] Loop is not vectorized because of operand canonicalization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65494 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65523 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35110 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35110action=edit gcc5-pr65523.patch Untested fix.
[Bug c++/65047] [c++17] Add support for nested namespace defintions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65047 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||bkoz at gcc dot gnu.org --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 21494 has been marked as a duplicate of this bug. ***
[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Uh, just rediscovered this and recreated exactly the same reduced testcase!
Also, this variation which should not compile (because lookup should fail for
N::f):
namespace N
{
namespace detail
{
inline namespace ver
{
templatetypename T
void f();
}
}
templatetypename T
void
detail::f() { }
}
int main()
{
N::fint();
}
Somehow the fact N::detail::ver is an inline namespace causes N::detail::f to
also be declared in N.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #56 from clyon at gcc dot gnu.org --- Author: clyon Date: Mon Mar 23 13:43:22 2015 New Revision: 221593 URL: https://gcc.gnu.org/viewcvs?rev=221593root=gccview=rev Log: 2015-03-23 Christophe Lyon christophe.l...@linaro.org PR sanitizer/59009 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry pick upstream r230324. * sanitizer_common/sanitizer_platform.h: Likewise. * sanitizer_common/sanitizer_common_syscalls.inc: Likewise. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc trunk/libsanitizer/sanitizer_common/sanitizer_platform.h trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65506 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35111 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35111action=edit gcc5-pr65506.patch Indeed, have verified this with the cross-compiler and the attached patch should cure this.
[Bug ada/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- It's forwprop4 propagating an abnormal SSA name: bb 5: [...] I.3_30(ab) = I.3_1 + 1; _31 = (interfaces__unsigned_32) I.3_30(ab); [...] bb 13: _43 = v.P_ARRAY; _45 = (sizetype) _31; is changed into: bb 13: _43 = v.P_ARRAY; _71 = I.3_30(ab) 4294967295; but I.3_87(ab) is live in BB 13.
[Bug c++/21494] condensed nested namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Something like this is in the C++17 WP *** This bug has been marked as a duplicate of bug 65047 ***
[Bug c++/65047] [c++17] Add support for nested namespace defintions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65047 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-23 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- There's a much older patch referred to in PR 21494
[Bug ada/65524] New: gnatbind generates decrementing the unexisting elab-counter into finalize_library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65524 Bug ID: 65524 Summary: gnatbind generates decrementing the unexisting elab-counter into finalize_library Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: demoonlit at panathenaia dot halfmoon.jp I found some cases that gnatbind generates decrementing the unexisting elaboration counter of each package Exxx. E142 : Short_Integer; pragma Import (Ada, E142, system__exn_lli_E); ... some Exxx are declared ... procedure finalize_library is begin ... E132 := E132 - 1; -- * E132 is not declared in above * ... end finalize_library; A cause is a package having _finalize_spec/_finalize_body without _elabs/_elabb. I still have not been able to make the minimal example, but have made a patch. In bindgen.adb, Gen_Elab_Externals refers U.Set_Elab_Entity to generate Exxx. However, Gen_Finalize_Library does not refer it. --- a/gcc/ada/bindgen.adb +++ b/gcc/ada/bindgen.adb @@ -1434,7 +1434,9 @@ package body Bindgen is -- has a finalizer. In that case, this is where we decrement -- the elaboration entity. -if U.Utype = Is_Body and then Uspec.Has_Finalizer then +if U.Utype = Is_Body and then Uspec.Has_Finalizer + and then Uspec.Set_Elab_Entity +then if not Lib_Final_Built then Gen_Header; Lib_Final_Built := True; @@ -1548,7 +1550,9 @@ package body Bindgen is WBI ( begin); -if U.Utype /= Is_Spec then +if U.Utype /= Is_Spec + and then Uspec.Set_Elab_Entity +then Set_String ( E); Set_Unit_Number (Unum); Set_String ( := E);
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #57 from clyon at gcc dot gnu.org --- Cherry-picked r230324 and committed in GCC as r221593, to fix aarch64 problems. I'm not sure whether the old arm and hppa problems have been fixed?
[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65504 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65500 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to dave.anglin from comment #1) At one time, GCC was permissive about system header issues, particularly when they aren't really a problem. Is this still the case? It is, yes, but this specific diagnostic is an error not just a warning and it doesn't get disabled in system headers. It looks like an include hack would fix but there's probably more issues like this. I think this isn't a widespread problem. We only use these PTHREAD_XXX_INITIALIZER macros in a handful of places, and the other ones have been there for some time without problems. The choices seem to be: 1) Add an autoconf check to see if we can use the PTHREAD_RWLOCK_INITIALIZER macro in this way, so that it falls back to the constructor+destructor if the INITIALIZER macro can't be used. 2) Change the front-end to suppress narrowing errors in system headers. 3) Use fixincludes to change either the definition of __LWP_RWLOCK_VALID to (short)0x8c91 or change the definition of PTHREAD_RWLOCK_INITIALIZER to use (short)__LWP_RWLOCK_VALID I don't like (1) because it would be a bit fragile and could introduce silent ABI issues. If a later release of HPUX changes the INITIALIZER macro to avoid the narrowing conversion, or if a later release of G++ does (2), then the result of the autoconf check would change and would silently change whether a std::shared_timed_mutex uses a constructor/destructor or not. Different translation units built by different versions of GCC would disagree on how to construct the objects. Neither (1) nor (2) helps user code that wants to do: pthread_rwlock_t lock = PTHREAD_RWLOCK_INITIALIZER; which presumably fails with the same error when using g++ -std=c++11. So I think a fixincludes to cast the constant to (short) is the best option. If __LWP_RWLOCK_T is only used in the definition of PTHREAD_RWLOCK_INITIALIZER then changing its definition is probably the simplest: #define __LWP_RWLOCK_VALID (short)0x8c91 I don't have any HPUX machines to try that with, would you be able to?
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Mon, Mar 23, 2015 at 04:07:10PM +0100, Richard Biener wrote:
On Mon, Mar 23, 2015 at 3:59 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
--- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
+++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
@@ -0,0 +1,9 @@
+/* { dg-lto-do link } */
+/* { dg-options -O2 -Wno-odr } */
Wasn't this supposed to be dg-lto-options instead?
I'm getting
WARNING: lto.exp does not support dg-options in primary source file
otherwise.
Yep - dg-options works in secondary files only (and applies to compile-time).
Here is a fix then. Both
WARNING: lto.exp does not support dg-options in primary source file
messages go away with it. Ok for trunk?
2015-03-23 Jakub Jelinek ja...@redhat.com
PR ipa/65475
* g++.dg/lto/pr65475_0.C: Use dg-lto-options instead of
dg-options.
* g++.dg/lto/pr65475b_0.C: Likewise.
--- gcc/testsuite/g++.dg/lto/pr65475_0.C.jj 2015-03-23 08:47:52.0
+0100
+++ gcc/testsuite/g++.dg/lto/pr65475_0.C2015-03-23 16:24:36.024316627
+0100
@@ -1,5 +1,5 @@
/* { dg-lto-do link } */
-/* { dg-options -O2 -Wno-odr } */
+/* { dg-lto-options -O2 -Wno-odr } */
/* { dg-extra-ld-options { -O2 -Wno-odr -r -nostdlib } } */
namespace std {
class ios_base {
@@ -7,4 +7,3 @@ class ios_base {
class __attribute((__abi_tag__(cxx11))) failure : A {};
} a;
}
-
--- gcc/testsuite/g++.dg/lto/pr65475b_0.C.jj2015-03-23 08:47:52.432180556
+0100
+++ gcc/testsuite/g++.dg/lto/pr65475b_0.C 2015-03-23 16:21:44.524084847
+0100
@@ -1,5 +1,5 @@
/* { dg-lto-do link } */
-/* { dg-options -O2 -Wno-odr } */
+/* { dg-lto-options -O2 -Wno-odr } */
/* { dg-extra-ld-options { -O2 -Wno-odr -r -nostdlib } } */
namespace std {
class exception {};
Jakub
[Bug target/65504] [4.9 Regression] select case with strings and -fgcse -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65504 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9/5 Regression] select |[4.9 Regression] select |case with strings and |case with strings and |-fgcse -O |-fgcse -O --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug tree-optimization/65518] [4.8/4.9 Regression] gcc consumes all memory with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65518 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.5 Summary|gcc consumes all memory |[4.8/4.9 Regression] gcc |with -O3|consumes all memory with ||-O3 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Must be a regression, at least from the times when we didn't have any vectorizer.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) Richard, any thoughts what to do about this? Avoid scheduling frame related instructions across conditional jumps? Something else? Yes, for the short term that will have to be a requirement in order to keep the unwind info happy. Something for the next stage1 is (1) Avoiding the use of bare /f, and thus also REG_FRAME_RELATED_EXPR, using instead always REG_CFA_*. I suspect that this insn 620 shouldn't actually be frame related at all, but is a part of a larger dwarf expression we're intending to construct. (2) Once we have an unambiguous note for everything, we can allow these insns to be scheduled across a conditional jump if we strip and collect those notes and place them after the conditional jump, probably on a fake insn like (insn/f (use (const_int 0)) (expr-list:REG_CFA_... (expr-list:REG_CFA_... (expr-list:REG_CFA_...
Re: [PATCH] Fix Ada bootstrap (PR bootstrap/65522)
In any case, for compatibility, this patch just changes the guard so that
adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
into gnat1, which can then successfully link against libiberty
cplus-dem.o.
The ipa-devirt.c change is obvious IMHO, the same header is included a few
lines above this.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
The Ada part looks OK to me.
Arno
[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64967 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Looks reasonable.
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Mar 23 15:49:02 2015 New Revision: 221599 URL: https://gcc.gnu.org/viewcvs?rev=221599root=gccview=rev Log: PR bootstrap/65522 * ipa-devirt.c: Remove duplicate demangle.h include. * adadecode.c (ada_demangle): Guard with IN_RTS instead of IN_GCC. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/adadecode.c trunk/gcc/ipa-devirt.c
[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65522 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Hi Mikael, This pointer stuff is very difficult to swallow to me. I totally understand. When doing the patch I had to restart twice, because I mixed up the development on the class arrays so completely, that I couldn't get it right again. I understand that for classes, the CLASS_DATA (sym)-pointer is always set, but almost everywhere the checks for pointerness are like (sym-ts.type != BT_CLASS sym-attr.pointer) || (sym-ts.type == BT_CLASS CLASS_DATA (sym)-attr.class_pointer) and I don't see a convincing reason to have it different here. I see your point. Currently I am bootstraping and regtesting some patches for commit. While this is running, my machine is nearly unusable. I will look into this as soon, as my machine allows, but probably not before tomorrow. At least gfc_is_nodesc_array should return 0 if sym-ts.type == BT_CLASS which solves the problem there; for the other cases, I think that class_pointer should be looked at. gfc_build_class_symbol clears the sym-attr.pointer flag for class containers so it doesn't make sense to test that flag. Completely right again. But I figured, that because sym-attr.pointer is never set for BT_CLASS there is no harm to check it and furthermore no need to guard it by checking whether ts.type == BT_CLASS. Fortunately not checking for class_pointer in _data's attr, didn't throw any regressions. Thinking about it now, I also think that it is probably safer to add the check for the class_pointer attribute were attr.pointer is checked on the sym, having the expression like you pointed out: (sym-ts.type != BT_CLASS sym-attr.pointer) || (sym-ts.type == BT_CLASS CLASS_DATA (sym)-attr.class_pointer) Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
[Bug ada/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
The problematic statement is created by the gimple-match stuff:
Applying pattern match.pd:761, gimple-match.c:1727
Applying pattern match.pd:625, gimple-match.c:1525
gimple_simplified to _71 = I.3_30(ab) 4294967295;
_45 = _71;
and falls through the cracks of replace_stmt_with_simplification:
/* Play safe and do not allow abnormals to be mentioned in
newly created statements. See also maybe_push_res_to_seq. */
if ((TREE_CODE (ops[0]) == SSA_NAME
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[0]))
|| (ops[1]
TREE_CODE (ops[1]) == SSA_NAME
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[1]))
|| (ops[2]
TREE_CODE (ops[2]) == SSA_NAME
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[2])))
return false;
because ops[0] is already the new SSA_NAME (_71), which was created by:
tree
gimple_build (gimple_seq *seq, location_t loc,
enum tree_code code, tree type, tree op0, tree op1,
tree (*valueize)(tree))
{
tree res = gimple_simplify (code, type, op0, op1, seq, valueize);
if (!res)
{
if (gimple_in_ssa_p (cfun))
res = make_ssa_name (type);
else
res = create_tmp_reg (type);
gimple stmt = gimple_build_assign (res, code, op0, op1);
gimple_set_location (stmt, loc);
gimple_seq_add_stmt_without_update (seq, stmt);
}
return res;
}
I don't think that gimple_build can fail, so maybe the way out is to test
stmt_references_abnormal_ssa_name (SSA_NAME_DEF_STMT (ops[x]))
instead of just
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops [x]))
in replace_stmt_with_simplification.
[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65504 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Mar 23 15:31:59 2015 New Revision: 221597 URL: https://gcc.gnu.org/viewcvs?rev=221597root=gccview=rev Log: PR target/65504 * config/i386/i386.c (ix86_copy_addr_to_reg): Set REG_POINTER on the pseudo. (expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): Set REG_POINTER on *destptr after adjusting it for prologue size. * gfortran.dg/pr65504.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr65504.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 CC||jakub at gcc dot gnu.org
[Bug rtl-optimization/60851] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 --- Comment #14 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #13) In 4.9 branch, the check is located in three different places throughout constrain_operands. There was a big cleanup by Richard Sandiford in this area [1]. Looks good.
[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64967 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) Or drop the gnu-versioned-namespace support altogether. I'd like to do that ... maybe for GCC 6 though. It seems a bit late now to remove it without deprecation. Anyway, if you don't, bumping it to _8 and always using the new ABI sounds like a good plan to me. That proved quite difficult. My plan for now is to simply force --disable-libstdcxx-dual-abi when gnu-versioned-namespace is in use, so it bootstraps and can be used, just without the new GCC 5 hotness.
[Bug target/65523] New: ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65523 Bug ID: 65523 Summary: ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 35107 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35107action=edit reduced testcase (gcc.dg/torture/pr55890-3.c) Compiler output: $ gcc -fcheck-pointer-bounds -mmpx testcase.c testcase.c: In function 'bar.chkp': testcase.c:7:1: internal compiler error: in gimple_op, at gimple.h:2270 } ^ 0x59ec53 gimple_op /mnt/svn/gcc-trunk/gcc/gimple.h:2270 0xcfb51f gimple_op /mnt/svn/gcc-trunk/gcc/gimple.h:2257 0xcfb51f gimple_call_arg /mnt/svn/gcc-trunk/gcc/gimple.h:2855 0xd012cf chkp_build_returned_bound /mnt/svn/gcc-trunk/gcc/tree-chkp.c:2195 0xd012cf chkp_get_bounds_by_definition /mnt/svn/gcc-trunk/gcc/tree-chkp.c:2728 0xd012cf chkp_find_bounds_1 /mnt/svn/gcc-trunk/gcc/tree-chkp.c:3475 0xd04862 chkp_find_bounds /mnt/svn/gcc-trunk/gcc/tree-chkp.c:3555 0xd04862 chkp_add_bounds_to_ret_stmt /mnt/svn/gcc-trunk/gcc/tree-chkp.c:1232 0xd04862 chkp_instrument_function /mnt/svn/gcc-trunk/gcc/tree-chkp.c:4133 0xd04862 chkp_execute /mnt/svn/gcc-trunk/gcc/tree-chkp.c:4323 0xd04862 execute /mnt/svn/gcc-trunk/gcc/tree-chkp.c:4380 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 5.0.0 20150320 (experimental) (GCC) Tested revisions: r221539 - ICE
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote: PR ipa/65475 * ipa-devirt.c: Include demangle.h === --- ipa-devirt.c (revision 221572) +++ ipa-devirt.c (working copy) @@ -166,6 +166,7 @@ along with GCC; see the file COPYING3. #include gimple-pretty-print.h #include stor-layout.h #include intl.h +#include demangle.h Why? demangle.h has been already included a few lines above this: #include tree-dfa.h #include demangle.h #include dbgcnt.h #include gimple-pretty-print.h #include stor-layout.h #include intl.h #include demangle.h Jakub
RE: ARC length attribute patch
I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Assuming you tested it, this patch is OK. Sorry, I replied to the wrong patch - I meant to reply to your email with the patch that only adds a COND_EXEC check for the maybe_limm case. The patch is tested with the latest gcc-head (dg.exp). It also has been in place for at least the past year in the Synopsys' git gcc-4.8 branch. Thank you, Claudiu
Re: [patch c++]: Fix for PR/65390
On 03/20/2015 10:53 AM, Kai Tietz wrote: * tree.c (strip_typedefs): Ignore alignment difference during processing template. + || (processing_template_decl + TYPE_ALIGN (t) != TYPE_ALIGN (result))) Your change is actually ignoring alignment differences when *not* processing a template, which isn't what we want. The problem is that the type is considered dependent in a template but is not actually dependent, so we can see the exact same type outside a template and it's not dependent. So, this code is creating the difference: /* We can only call value_dependent_expression_p on integral constant expressions; treat non-constant expressions as dependent, too. */ if (processing_template_decl (type_dependent_expression_p (size) || !TREE_CONSTANT (size) || value_dependent_expression_p (size))) Now that we have instantiation_dependent_expression_p, we should be able to use that instead of checking type/value dependency separately. Jason
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
On 03/23/2015 03:33 PM, Eric Botcazou wrote: FWIW, you have to be very careful depending on REG_POINTER. I believe Ada can still set REG_POINTER on things that are not pointers (via virtual origins) and cross jumping can cause problems too where one arm has x + y with X as the pointer and the other arm has x + y with Y as the pointer. Can you elaborate a bit about Ada here? Front-ends don't fiddle directly with RTL for years so I'm a little at a loss here. It's been years since I looked at this, but my recollection was that the Ada front end could set REG_POINTER for virtual origins. From a correctness standpoint it only matters on a few obscure targets and only causes a failure when the flag is set on a pseudo with a value on a different, unmapped, page than the full effective address. Jeff
[Bug target/65531] New: ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531 Bug ID: 65531 Summary: ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 35118 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35118action=edit reduced testcase Compiler output: $ gcc -fcheck-pointer-bounds -mmpx testcase.C testcase.C:10:4: error: Two symbols with same comdat_group are not linked by the same_comdat_group list. S s; ^ _ZN1SD1Ev.chkp/11 (S::~S(#'pointer_bounds_type' not supported by dump_type#type error, void, ...)) @0x7f52d8b0f310 Type: function definition analyzed alias cpp_implicit_alias Visibility: external public weak comdat comdat_group:_ZN1SD5Ev one_only Same comdat group as: _ZN1SD1Ev/2 Address is taken. References: _ZN1SD2Ev.chkp/10 (alias) Referring: _ZN1SD1Ev/2 (chkp) Availability: available First run: 0 Function flags: Called by: Calls: Is instrumented version. _ZN1SD2Ev.chkp/10 (S::~S(#'pointer_bounds_type' not supported by dump_type#type error, void, ...)) @0x7f52d8b0f188 Type: function definition analyzed Visibility: external public weak comdat comdat_group:_ZN1SD5Ev one_only artificial Same comdat group as: _ZN1SD2Ev/1 Address is taken. References: Referring: _ZN1SD1Ev.chkp/11 (alias)_ZN1SD2Ev/1 (chkp) Availability: available First run: 0 Function flags: body Called by: _ZN1SD2Ev/1 (1.00 per call) Calls: Is instrumented version. testcase.C:10:4: internal compiler error: symtab_node::verify failed 0x9dc3c4 symtab_node::verify_symtab_nodes() /mnt/svn/gcc-trunk/gcc/symtab.c:1140 0xc28668 symbol_table::remove_unreachable_nodes(_IO_FILE*) /mnt/svn/gcc-trunk/gcc/ipa.c:686 0xd0d4bd execute_todo /mnt/svn/gcc-trunk/gcc/passes.c:2023 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 5.0.0 20150320 (experimental) (GCC) Tested revisions: r221530 - ICE
[Bug fortran/65532] New: [5 Regression] Unexpected error with legacy code (D1MACH)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65532 Bug ID: 65532 Summary: [5 Regression] Unexpected error with legacy code (D1MACH) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gmx dot de Created attachment 35119 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35119action=edit Bug demo. Dear all, after updating to trunk rev. 221607, I found a problem which I reduced to the attached example. Commenting out the call to d1mach or commenting out in d1mach the data statements in lines 21-25 makes the error messages disappear. Here's the error messages I get: % gfc-trunk -c gfcbug131.f90 gfcbug131.f90:10:23: INTEGER :: diver(4) 1 Error: Different shape for array assignment at (1) on dimension 1 (4 and 2) gfcbug131.f90:8:23: INTEGER :: large(4) 1 Error: Different shape for array assignment at (1) on dimension 1 (4 and 2) gfcbug131.f90:11:23: INTEGER :: LOG10(4) 1 Error: Different shape for array assignment at (1) on dimension 1 (4 and 2) gfcbug131.f90:9:23: INTEGER :: right(4) 1 Error: Different shape for array assignment at (1) on dimension 1 (4 and 2) gfcbug131.f90:7:23: INTEGER :: small(4) 1 Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 Joel Matz joel.matz at horizonbtc dot com changed: What|Removed |Added CC||joel.matz at horizonbtc dot com --- Comment #8 from Joel Matz joel.matz at horizonbtc dot com --- Any word on this? I would certainly be willing to help test.
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
On 03/23/2015 09:07 AM, Jakub Jelinek wrote: Hi! As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses src = src - (adjusted_dest - dest) without proper REG_POINTER flags the aliasing code is very easily confused on what is really a pointer and what is not - as REG_POINTER was used after forwprop only on dest, but not on anything else, aliasing code thinks that the memcpy reads dest based memory, when it really reads src based memory (in the testcase frame pointer based in the end, but CSE did not see it through). Fixed by marking pseudos that must hold pointers with REG_POINTER during the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? FWIW, you have to be very careful depending on REG_POINTER. I believe Ada can still set REG_POINTER on things that are not pointers (via virtual origins) and cross jumping can cause problems too where one arm has x + y with X as the pointer and the other arm has x + y with Y as the pointer. But yes, in general, if we're marking things that must be pointers with REG_POINTER, that is a good thing. jeff
Re: [PATCH, ARM, PR64208] LRA ICE Fix
On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux yvan.r...@linaro.org wrote: Hi, This is a fix for PR64208 where LRA loops when dealing with iwmmxt_arm_movdi insn. As explain in the PR, the issue was introduced on trunk and 4.9 branch by fix of PR rtl-optimization/60969 and then workaround by r211798 (-fuse-caller-save enable for ARM). The changes in IRA cost made by PR60969, changed the register class of this insn output from GENERAL_REGS to IWMMXT_REGS, and the redundancies in the insn pattern alternatives description force LRA to reload the pseudo, which generates the same iwmmxt_arm_movdi insn, which can't be resolved, and so on ... Removing the redundancies fixes the issue, as LRA find that alternative 8 (Uy = y) matches. This issue is present in 4.9 branch, but latent on trunk (the clobbering of IP and CC information added during -fuse-caller-save patch changed the register allocation). Cross compiled and regression tested on ARM targets (but not on an IWMMXT one), is it ok for trunk and 4.9 branch ? This looks sane. It doesn't look reasonable for alternatives to be duplicating each other. Given I have neither the time nor the hardware to test this patch on, I'd rather someone with an interest in iwMMX possibly folks from Marvell can pick up testing for this patch. regards Ramana Rq: I think that adding IP and CC clobbers to CALL_INSN_FUNCTION_USAGE, as specified by AAPCS, in 4.9 branch is something we need too, I've a patch for that if you agree on that. Thanks, Yvan 2105-03-17 Yvan Roux yvan.r...@linaro.org PR target/64208 * config/arm/iwmmxt.md (*iwmmxt_arm_movdi): Cleanup redundant alternatives.
Re: [PATCH ARM]Fix memset-inline-* failures on cortex-a9 tune by checking tune information.
On Tue, Mar 17, 2015 at 3:34 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Fri, Mar 13, 2015 at 7:56 PM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Mar 6, 2015 at 7:46 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
This patch is the second part fixing memset-inline-{4,5,6,8,9}.c failures on
cortex-a9. It adds a function checking CPU tuning information in dejagnu,
it also uses that function to skip related testcase when we are compiling
for cortex-a9 tune.
Skips the related testcase for all tests where the tuning information
doesn't use neon. I think this technique can be used to clean up a
number of multilib related failures in the gcc.target/arm testsuite.
Actually these are all related cases. Cases {1,2,3} are intended for
non-neon target inlining test, case 7 is an executable test which
should be run what ever the target supports.
Build and test on arm-none-eabi. Is it OK?
gcc/testsuite/ChangeLog
2015-03-06 Bin Cheng bin.ch...@arm.com
* lib/target-supports.exp (arm_tune_string_ops_prefer_neon): New.
* gcc.target/arm/memset-inline-4.c: Skip for
arm_tune_string_ops_prefer_neon.
* gcc.target/arm/memset-inline-5.c: Ditto.
* gcc.target/arm/memset-inline-6.c: Ditto.
* gcc.target/arm/memset-inline-8.c: Ditto.
* gcc.target/arm/memset-inline-9.c: Ditto.
Ok, please document the new dejagnu helper routine in sourcebuild.texi
Done. Patch updated, I will push both patches in if you are ok with it.
Thanks,
bin
2015-03-17 Bin Cheng bin.ch...@arm.com
* doc/sourcebuild.texi (arm_tune_string_ops_prefer_neon): New.
gcc/testsuite/ChangeLog
2015-03-17 Bin Cheng bin.ch...@arm.com
* lib/target-supports.exp (arm_tune_string_ops_prefer_neon): New.
* gcc.target/arm/memset-inline-4.c: Skip for
arm_tune_string_ops_prefer_neon.
* gcc.target/arm/memset-inline-5.c: Ditto.
* gcc.target/arm/memset-inline-6.c: Ditto.
* gcc.target/arm/memset-inline-8.c: Ditto.
* gcc.target/arm/memset-inline-9.c: Ditto.
OK.
Ramana
[PATCH][ARM] PR 65489: Accept VSTRUCT constants in arm_legitimate_constant_p
Hi all, The ICE in the PR happens on arm during the hoist pass when the code generates a SET rtx of the form: (set (reg:OI) (const_int 0)). It checks whether const_int 0 is a general_operand for OImode which involves asking the backend whether it's a legitimate constant. arm_legitimate_constant_p_1 explicitly rejects OImode constants as a result of the fix for PR 46329 https://gcc.gnu.org/ml/gcc-patches/2011-04/msg00200.html This results in gcse using an emit_insn of the SET rtx rather than trying to do an emit_move_insn which would have worked in this case. From reading the thread I get the impression that the ICE there was caused by reload and coproc_secondary_reload_class behaving weirdly. We're now using LRA and SECONDARY_INPUT_RELOAD_CLASS and SECONDARY_OUTPUT_RELOAD_CLASS which are the only users of coproc_secondary_reload_class are no longer used. I removed the restriction on constants for these large modes in arm_legitimate_constant_p_1 and the testcases in PR 46329 all work fine. Bootstrap, testing and building various vector workloads also didn't show any problems. Is this the right way to go for this? If so, ok for trunk? The ICE in this PR happens on a recently added testcase to gcc.c-torture/execute/ and this patch fixes that, so no new testcase is added. Jakub mentioned that maybe the testcase can be modified to manually perform the lowering done in his patch to potentially trigger this on older gcc versions, but I'm not sure how that would be done. The problem is that something is generating OImode moves that I think can only be done in the vector form of the testcase, so I'm not entirely convinced that it's reproducible on 4.9 and 4.8. Thanks, Kyrill Thanks, Kyrill 2015-03-23 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/65489 * config/arm/arm.c (arm_legitimate_constant_p_1): Remove restriction on constants for NEON VSTRUCT modes. arm-vstruct-const.patch Description: Binary data
