[PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
Hi, the test case g++.dg/tsan/aligned_vs_unaligned_race.C still fails sporadically (around 1 out of 100 times). That is apparently a race condition in the tsan runtime itself. To make the test reproducible pass, I need to add a sleep(1) in one of the two threads. Tested really often with: make check-gcc-c++ RUNTESTFLAGS="tsan.exp=*" OK for trunk? Thanks Bernd. patch-tsan-race.diff Description: Binary data
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 3, 2015, at 1:01 AM, Bernd Edlinger wrote: > the test case g++.dg/tsan/aligned_vs_unaligned_race.C > still fails sporadically (around 1 out of 100 times). > That is apparently a race condition in the tsan runtime itself. > To make the test reproducible pass, I need to add a sleep(1) > in one of the two threads. > > > Tested really often with: > make check-gcc-c++ RUNTESTFLAGS="tsan.exp=*" > > OK for trunk? No. sleep can never fix race conditions. The only time sleep can fix a race condition would be in a hard real time system, and, that in general doesn’t apply to anything in the gcc test suite.
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
Hello Maintainers: It is finished with qemu today, it spends 13 days, the result is below, please help check. With qemu: === gcc Summary === # of expected passes83439 # of unexpected failures175 # of unexpected successes 1 # of expected failures 100 # of unresolved testcases 349 # of unsupported tests 1954 /upstream/build-gcc-microblaze/gcc/xgcc version 5.0.0 20141220 (experimental) (GCC) No qemu (originally): === gcc Summary === # of expected passes65987 # of unexpected failures82 # of unexpected successes 1 # of expected failures 97 # of unresolved testcases 16378 # of unsupported tests 1810 If the result is OK, I shall start tile environments construction ( although, I guess, there is no qemu or sim for tile). And also excuse me, during these days, gmail is broken in China, I have to use my another mail address to send/receive emails. Thanks. On 12/21/14 05:45, Chen Gang wrote: > On 12/21/2014 12:31 AM, Michael Eager wrote: >> On 12/20/14 02:09, Chen Gang wrote: >>> By the way, if this thread really has negative effect with other members, >>> please warn me, I should not notify it to mailing list again, and try my >>> best to finish it within myself. >> >> I appreciate your enthusiasm and perseverance in pursuing this bug. >> >> If the problem you are working on has changed from the mb-gcc issue, >> change the subject. Otherwise, keep up the good work. >> > > Thank you for your encouragement, and I should continue. At present, I > guess my own main issues are: > > - Have no enough time resources on open source: > > sometimes need work overtime. > > need 4 hours per work day on subway between home and work office > (come 2 hours, go 2 hours, so total is 4 hours). > > need spend time for my child: check his homework, play with him. > (especially in weekend). > > - Really not familiar with gcc: > > Sometimes can find real world issues, but can not fix them in time. > > Sometimes can find coding issues, but do not know whether it can > cause real world issues or not (may also waste other members time > resources, but get no positive result). > > - Not familiar with related environments for each architectures. > > So next, I should change myself for solving the issues above, firstly: > > - I shall try to spend 1-1.5 hours for reading gcc related documents ( >e.g. "gcc info") in work day when I on subway (another time on subway >is for listening Holy Bible, reading news, or sleeping for a while). > > - I shall mainly forcus on finding real world issues and try to fix in >time. And stop finding coding issues (which may get negative effect >with others -- at least may waste other members time resources). > > - Still contiue for constructing all related enviroments (it is always >necessary) for architectures. > > Welcome any ideas, suggestions or completions by any members. > > Thanks. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
Happy New Year to all. The test gfortran.dg/coarray/codimension_2.f90 fails on x86_64-apple-darwin14 with -m32 (see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00185.html). The error is gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/codimension_2.f90 /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/codimension_2a.f90 -fcoarray=lib -O2 -lcaf_single -m32 /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccPcznrm.s:18:non-relocatable subtraction expression, "__F.caf_token__global_coarrays_MOD_b" minus "L1$pb" /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccPcznrm.s:18:symbol: "__F.caf_token__global_coarrays_MOD_b" can't be undefined in a subtraction expression Dominique
RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Sat, 3 Jan 2015 01:51:34, Mike Strump wrote: > > On Jan 3, 2015, at 1:01 AM, Bernd Edlinger wrote: >> the test case g++.dg/tsan/aligned_vs_unaligned_race.C >> still fails sporadically (around 1 out of 100 times). >> That is apparently a race condition in the tsan runtime itself. >> To make the test reproducible pass, I need to add a sleep(1) >> in one of the two threads. >> >> >> Tested really often with: >> make check-gcc-c++ RUNTESTFLAGS="tsan.exp=*" >> >> OK for trunk? > > No. sleep can never fix race conditions. The only time sleep can fix a race > condition would be in a hard real time system, and, that in general doesn’t > apply to anything in the gcc test suite. Yes, but all other tsan test cases call sleep(1) too. The sleep does not really "fix" the race condition but it changes the likelihood from 1 / 100 to 1 / 10^20. That is just to avoid noise from sporadic test failures. Bernd.
[Patch, Fortran, OOP] PR 63552: Type-bound procedures rejected as actual argument to dummy procedure
Hi all,
the attached patch allows type-bound procedures to be passed actual
arguments to dummy procedures. When doing this, on has to transform
the expression such that the corresponding procedure pointer from the
vtab is used.
The patch is regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-03 Janus Weil
PR fortran/63552
* primary.c (gfc_match_varspec): Handle type-bound procedures as actual
argument to dummy procedure.
2015-01-03 Janus Weil
PR fortran/63552
* gfortran.dg/typebound_proc_34.f90: New.
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (Revision 219159)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -1826,6 +1826,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
gfc_ref *substring, *tail;
gfc_component *component;
gfc_symbol *sym = primary->symtree->n.sym;
+ gfc_symbol *dt = NULL;
match m;
bool unknown;
@@ -1929,7 +1930,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
|| gfc_match_char ('%') != MATCH_YES)
goto check_substring;
- sym = sym->ts.u.derived;
+ dt = sym->ts.u.derived;
for (;;)
{
@@ -1942,8 +1943,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
if (m != MATCH_YES)
return MATCH_ERROR;
- if (sym->f2k_derived)
- tbp = gfc_find_typebound_proc (sym, &t, name, false,
&gfc_current_locus);
+ if (dt->f2k_derived)
+ tbp = gfc_find_typebound_proc (dt, &t, name, false, &gfc_current_locus);
else
tbp = NULL;
@@ -1950,6 +1951,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
if (tbp)
{
gfc_symbol* tbp_sym;
+ gfc_actual_arglist *actual = NULL;
if (!t)
return MATCH_ERROR;
@@ -1967,37 +1969,48 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
else
tbp_sym = tbp->n.tb->u.specific->n.sym;
- primary->expr_type = EXPR_COMPCALL;
- primary->value.compcall.tbp = tbp->n.tb;
- primary->value.compcall.name = tbp->name;
- primary->value.compcall.ignore_pass = 0;
- primary->value.compcall.assign = 0;
- primary->value.compcall.base_object = NULL;
- gcc_assert (primary->symtree->n.sym->attr.referenced);
if (tbp_sym)
primary->ts = tbp_sym->ts;
else
gfc_clear_ts (&primary->ts);
- m = gfc_match_actual_arglist (tbp->n.tb->subroutine,
- &primary->value.compcall.actual);
+ m = gfc_match_actual_arglist (tbp->n.tb->subroutine, &actual);
if (m == MATCH_ERROR)
return MATCH_ERROR;
- if (m == MATCH_NO)
+ if (m == MATCH_YES || sub_flag)
{
- if (sub_flag)
- primary->value.compcall.actual = NULL;
- else
- {
- gfc_error ("Expected argument list at %C");
- return MATCH_ERROR;
- }
+ primary->expr_type = EXPR_COMPCALL;
+ primary->value.compcall.tbp = tbp->n.tb;
+ primary->value.compcall.name = tbp->name;
+ primary->value.compcall.ignore_pass = 0;
+ primary->value.compcall.assign = 0;
+ primary->value.compcall.base_object = NULL;
+ primary->value.compcall.actual = actual;
+ gcc_assert (primary->symtree->n.sym->attr.referenced);
}
+ else if (!matching_actual_arglist)
+ {
+ gfc_error ("Expected argument list at %C");
+ return MATCH_ERROR;
+ }
+ else if (sym->ts.type == BT_CLASS)
+ {
+ gfc_add_vptr_component (primary);
+ gfc_add_component_ref (primary, name);
+ }
+ else if (sym->ts.type == BT_DERIVED)
+ {
+ gfc_symtree *symtree;
+ gfc_symbol *vtab = gfc_find_derived_vtab (dt);
+ gfc_find_sym_tree (vtab->name, NULL, 1, &symtree);
+ primary->symtree = symtree;
+ gfc_add_component_ref (primary, name);
+ }
break;
}
- component = gfc_find_component (sym, name, false, false);
+ component = gfc_find_component (dt, name, false, false);
if (component == NULL)
return MATCH_ERROR;
@@ -2005,7 +2018,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
tail->type = REF_COMPONENT;
tail->u.c.component = component;
- tail->u.c.sym = sym;
+ tail->u.c.sym = dt;
primary->ts = component->ts;
@@ -2058,12 +2071,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
|| gfc_match_char ('%') != MATCH_YES)
break;
- sym = component->ts.u.derived;
+ dt = component->ts.u.derived;
}
check_substring:
unknown = false;
- if (primary->ts.type == BT_UNKNOWN && sym->attr.flavor != FL_DERIVED)
+ if (primar
Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length
Hi Andre, >> 1) There are still two TODO markers in the patch. It might be a good >> idea to take care of them before committing the patch. In particular >> for the first one (adding the initializer in gfc_build_class_symbol) >> it would be good to understand where those problems come from. > > I started with the initializer for the _len component and ran into "Pointer > assignment target is neither TARGET nor POINTER at %L" errors (expr.c:3714). I > tracked this back to the constructor resolve of the class type. Resolving the > constructor somehow concludes, that something needs to be done for the > constant > initializer although it is marked artificial. I could not track down the > location that is causing this behavior, or if I need to set a flag in the > class > itself to get through with it. I am hoping, that either some fortran guru says > "You just need to do xyz to get it running." or that we conclude to remove the > TODO and the commented instructions (setting a zero value for _len is done > where > needed (gfc_conv_structure trans-expr.c:6540)). I can reproduce the "pointer assignment ..." error, but I'm not sure if there is any good way to get rid of it. I'm not even sure if it is a good idea to add an initializer for the _len component at all, since neither _data nor _vptr have one. So, I'm fine with just removing the commented code and the TODO marker, as long as everything works and you make sure the _len component is properly initialized before it is accessed. >> For the >> second one (in gfc_conv_expr), I don't directly see how it's related >> to deferred char-len. Why is this change needed? > > That change is needed, because in some rare case where an associated variable > in a "select type ()" is used, then the type and f90_type match the condition > while them not really being in a bind_c context. Therefore I have added > the check for bind_c. Btw, I now have removed the TODO, because that case is > covered by the regression tests. I don't understand how f90_type can be BT_VOID without being in a BIND_C context, but I'm not really a ISO_C_BINDING expert. Which test case is the one that triggered this? >> 2) You're making a lot of changes to 'trans_associate_var', but I >> don't see any ASSOCIATE statements covered in your test case. Can you >> add more test cases which cover this code? > > Select type (assoc => upoly) uses these where an explicit assoc is supplied. Ah, right. Forgot about that. >> 3) The function 'gfc_get_len_component' that you're introducing is >> only called in a single place. Do you expect this to be useful in >> other places in the future, or could one remove the function and >> insert the code inline? > > In one of the first versions it was uses from two locations. But I had to > remove one call site again. I am currently not sure, if I will be using it in > the patch for allocatable components when deferred char arrays are handled. So > what I do I do now? Inline it and when needed make it explicit again in a > future patch? I leave that up to you. In principle I'm fine with keeping it as it is. The only problem I see is that the function name sounds rather general, but it apparently expects the expression to be an ASSOCIATE symbol. If you want to keep the function, I would either: a) document it more properly, or b) even better: make it more general by calling it like return gfc_get_len_component (e->symtree->n.sym->assoc->target); and inside use gfc_expr *len_comp = gfc_copy_expr (e); Maybe it can be more useful also in other places like this? Cheers, Janus
[PING] Add refers_to_regno_p overload to simplify callers
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01730.html On Sun, 2014-12-21 at 23:02 +0100, Oleg Endo wrote: > Hi, > > It seems that quite some callers of refers_to_regno_p are interested in > testing a single register number only. The caller code can be > simplified by adding an overload for refers_to_regno_p. This is what > the patch does. No functional changes. Tested with 'make all-gcc' on > sh-elf cross config and bootstrapped on i686-pc-linux-gnu. > OK for trunk? > > Cheers, > Oleg > > gcc/ChangeLog: > * rtlanal.c (refers_to_regno_p): Change return value from int to > bool. > * rtl.h (refers_to_regno_p): Add overload. > * cse.c: Use it. > * bt-load.c: Likewise. > * combine.c: Likewise. > * df-scan.c: Likewise. > * sched-deps.c: Likewise. > * config/s390/s390.c: Likewise. > * config/m32r/m32r.c: Likewise. > * config/rs6000/spe.md: Likewise. > * config/rs6000/rs6000.c: Likewise. > * config/pa/pa.c: Likewise. > * config/stormy16/stormy16.c: Likewise. > * config/cris/cris.c: Likewise. > * config/arc/arc.md: Likewise. > * config/arc/arc.c: Likewise. > * config/sh/sh.md: Likewise. > * config/sh/sh.c: Likewise. > * config/frv/frv.c: Likewise.
[PATCH] Enable experimental TSAN support for Ada
Hi, I was experimenting with enabling TSAN for Ada recently. I think this gives rather interesting results. The Instrumentation worked almost out of the box, we just have the problem that it is not gimple-OK to fold something like "& VIEW_CONVERT_EXPR(x)", and this happens in Ada all the time. Boot-Strapped and regression-tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. gcc/ChangeLog: 2015-01-03 Bernd Edlinger Enable experimental TSAN support for Ada. * tsan.c (instrument_expr): Handle VIEW_CONVERT_EXPR. patch-tsan-ada.diff Description: Binary data
Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length
Hi Janus, thanks for the quick response. Please see my answers inline. On Sat, 3 Jan 2015 13:12:28 +0100 Janus Weil wrote: > > I started with the initializer for the _len component and ran into "Pointer > > assignment target is neither TARGET nor POINTER at %L" errors > > (expr.c:3714). I tracked this back to the constructor resolve of the class > > type. Resolving the constructor somehow concludes, that something needs to > > be done for the constant initializer although it is marked artificial. I > > could not track down the location that is causing this behavior, or if I > > need to set a flag in the class itself to get through with it. I am hoping, > > that either some fortran guru says "You just need to do xyz to get it > > running." or that we conclude to remove the TODO and the commented > > instructions (setting a zero value for _len is done where needed > > (gfc_conv_structure trans-expr.c:6540)). > > I can reproduce the "pointer assignment ..." error, but I'm not sure > if there is any good way to get rid of it. > I'm not even sure if it is a good idea to add an initializer for the > _len component at all, since neither _data nor _vptr have one. > So, I'm fine with just removing the commented code and the TODO > marker, as long as everything works and you make sure the _len > component is properly initialized before it is accessed. Removed it. > >> For the > >> second one (in gfc_conv_expr), I don't directly see how it's related > >> to deferred char-len. Why is this change needed? > > > > That change is needed, because in some rare case where an associated > > variable in a "select type ()" is used, then the type and f90_type match > > the condition while them not really being in a bind_c context. Therefore I > > have added the check for bind_c. Btw, I now have removed the TODO, because > > that case is covered by the regression tests. > > I don't understand how f90_type can be BT_VOID without being in a > BIND_C context, but I'm not really a ISO_C_BINDING expert. Which test > case is the one that triggered this? This case is triggered by the test-case in the patch, where in the select type (w => arg) in module m routine bar the w meets the criteria to make the condition become true. The type of w is then "fixed" and gfortran would terminate, because the type of w would be set be and BT_INTEGER. I tried to backtrace where this is coming from, but to no success. In the resolve () of the select type it looks all quite ok, but in the trans stage the criteria are met. Most intriguing to me is, that in the condition we are talking about the type of w and f90_type of the derived class' ts (expr->ts.u.derived->ts.f90_type) of w is examined. But expr->ts.u.derived->ts does not describe the type of w, but of the class w is associate with __STAR... So I am not quite sure how to fix this, if this really needs fixing. When I understand you right, then f90_type should only be set in a bind_c context, so adding that check wouldn't hurt, right? > >> 3) The function 'gfc_get_len_component' that you're introducing is > >> only called in a single place. Do you expect this to be useful in > >> other places in the future, or could one remove the function and > >> insert the code inline? > > > > In one of the first versions it was uses from two locations. But I had to > > remove one call site again. I am currently not sure, if I will be using it > > in the patch for allocatable components when deferred char arrays are > > handled. So what I do I do now? Inline it and when needed make it explicit > > again in a future patch? > > I leave that up to you. In principle I'm fine with keeping it as it > is. The only problem I see is that the function name sounds rather > general, but it apparently expects the expression to be an ASSOCIATE > symbol. I am nearly finished with the patch on allocatable scalar components and I don't need the code there. Therefore I have inlined the routine. So, what do we do about the bind_c issue above? Is some bind_c guru available to have a look at this? It would be very much appreciated. Regards, Andre -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 241 9291018 * Email: ve...@gmx.de
Re: [PATCH 3/4] Add Visium support to gcc
> I don't see anything particularly offensive. Actually it looks like a > reasonably clean RISC port. Thanks for the review. > I'm a little concerned about the MODES_TIEABLE_P definition, but if it's > working, I wouldn't mess with it. Could you elaborate? Do you find it too restrictive? > Any thoughts on using LRA for this port? Ideally we want to be moving > away from reload as much as we can. I can only promise to start experimenting with it and report issues, if any. The port is quite mature and the performances are closely monitored so bold changes need to be made with extra caution. > I didn't look closely, do you need blockage insns in your epilogue/prologue? No, I don't think so. > For the prologue, if you store callee saved registers using the frame > pointer, then you need a blockage to ensure those stores don't bubble up > before the local stack gets allocated. And you need something analogous > in the epilogue. I didn't check your port carefully for this, but I'd > advise doing so. The register saves in the prologue are based on the stack pointer because the frame pointer is established only at the very end and its value comprises the allocation. The restores in the epilogue are also based on the stack pointer and the stack_restore and stack_pop patterns which do the deallocation have an explicit memory barrier. > Presumably you're going to be the maintainer for this port? Yes, I'm going to be the maintainer for now. > I think this is good to go into the trunk. The blockage issue (if it's > an issue) can be resolved as a follow-up. OK, thanks again. -- Eric Botcazou
Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length
Hi Andre, >> >> For the >> >> second one (in gfc_conv_expr), I don't directly see how it's related >> >> to deferred char-len. Why is this change needed? >> > >> > That change is needed, because in some rare case where an associated >> > variable in a "select type ()" is used, then the type and f90_type match >> > the condition while them not really being in a bind_c context. Therefore I >> > have added the check for bind_c. Btw, I now have removed the TODO, because >> > that case is covered by the regression tests. >> >> I don't understand how f90_type can be BT_VOID without being in a >> BIND_C context, but I'm not really a ISO_C_BINDING expert. Which test >> case is the one that triggered this? > > This case is triggered by the test-case in the patch, where in the select type > (w => arg) in module m routine bar the w meets the criteria to make the > condition become true. The type of w is then "fixed" and gfortran would > terminate, because the type of w would be set be and BT_INTEGER. I tried to > backtrace where this is coming from, but to no success. In the resolve () of > the select type it looks all quite ok, but in the trans stage the criteria are > met. Most intriguing to me is, that in the condition we are talking about the > type of w and f90_type of the derived class' ts > (expr->ts.u.derived->ts.f90_type) of w is examined. But expr->ts.u.derived->ts > does not describe the type of w, but of the class w is associate with > __STAR... > > So I am not quite sure how to fix this, if this really needs fixing. When I > understand you right, then f90_type should only be set in a bind_c context, so > adding that check wouldn't hurt, right? Yes, in principle adding the check for attr.bind_c looks ok to me (alternatively one could also check for attr.unlimited_polymorphic). I think originally BT_VOID was indeed only used in a bind_c context, but recently it has also been 'hijacked' for unlimited polymorphism, e.g. for the STAR symbol and some of the components of the intrinsic vtabs. What I don't really understand is why these problems are triggered by your patch now and have not crept up earlier in other use-cases of CLASS(*). >> >> 3) The function 'gfc_get_len_component' that you're introducing is >> >> only called in a single place. Do you expect this to be useful in >> >> other places in the future, or could one remove the function and >> >> insert the code inline? >> > >> > In one of the first versions it was uses from two locations. But I had to >> > remove one call site again. I am currently not sure, if I will be using it >> > in the patch for allocatable components when deferred char arrays are >> > handled. So what I do I do now? Inline it and when needed make it explicit >> > again in a future patch? >> >> I leave that up to you. In principle I'm fine with keeping it as it >> is. The only problem I see is that the function name sounds rather >> general, but it apparently expects the expression to be an ASSOCIATE >> symbol. > > I am nearly finished with the patch on allocatable scalar components and I > don't > need the code there. Therefore I have inlined the routine. Ok, good. Could you please post an updated patch? > So, what do we do about the bind_c issue above? Is some bind_c guru available > to have a look at this? It would be very much appreciated. >From my non-guru POV, it can stay as is. It would be helpful if someone like Paul or Tobias could have a look at the patch before it goes to trunk. I think it's pretty close to being ready for prime-time. Thanks for your work! Cheers, Janus
Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
On Wed, 31 Dec 2014, H.J. Lu wrote:
> - /* Arguments for a sibling call that are pushed to memory are passed
> - using the incoming argument pointer of the current function. These
> - may or may not be frame related depending on the target. Since
> - argument pointer related stores are not currently tracked, we treat
> - a sibling call as though it does a wild read. */
> - if (SIBLING_CALL_P (insn))
> + if (targetm.sibcall_wild_read_p (insn))
> {
> add_wild_read (bb_info);
> return;
Instead of falling through to code designed to handle normal calls, it
would be better to treat them separately. Potentially, there are other
optimizations that may be applicable. If a sibcall doesn't read from
the frame, add_non_frame_wild_read() can be called. This would restore
the x86 optimization.
Dave
--
J. David Anglin dave.ang...@bell.net
[committed] gcc.dg/pr57233.c: Add -fno-common option on hppa*-*-hpux*
The attached change fixes failure of gcc.dg/pr57233.c: on hppa-hpux due to
limited common alignment.
Dave
--
John David Anglin dave.ang...@bell.net
2015-01-03 John David Anglin
* gcc.dg/pr63914.c: Add -fno-common option on hppa*-*-hpux*.
Index: gcc.dg/pr63914.c
===
--- gcc.dg/pr63914.c(revision 219148)
+++ gcc.dg/pr63914.c(working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-O2 -ffast-math" } */
/* { dg-prune-output "non-standard ABI extension" } */
+/* { dg-additional-options "-fno-common" { target hppa*-*-hpux* } } */
typedef float __m128 __attribute__ ((__vector_size__ (16)));
__m128 a, d, e;
Re: [Ada] implement C99 fmax semantics for floating-point 'Min/Max
> NaNs are invalid values in Ada so the language doesn't specify how they
> should be handled but GNAT nevertheless attempts to implement sensible
> semantics for them. This patch extends this to the Min and Max attributes.
>
> Tested on x86_64-suse-linux, applied on the mainline.
>
>
> 2014-12-22 Eric Botcazou
>
> * gcc-interface/trans.c (Attribute_to_gnu) : If the
> type is a floating-point type, implement the semantics of the C99
> f{min,max} routines with regard to NaNs.
> (gnat_to_gnu): Call builtin_decl_implicit.
> * gcc-interface/utils2.c (compare_arrays): Adjust comments.
>
>
> 2014-12-22 Eric Botcazou
>
> * gnat.dg/nan_max.adb: New test.
ENOPATCH: https://gcc.gnu.org/ml/gcc-cvs/2014-12/msg00823.html
--
Eric Botcazou
[committed] Fix memory constraint issue on PA
The attached change fixes a memory constraint issue found building the asterisk
package on hppa-linux:
http://buildd.debian-ports.org/status/fetch.php?pkg=asterisk&arch=hppa&ver=1%3A13.1.0%7Edfsg-1&stamp=1420088700
The problem was the `m' constraint allowed reload to substitute a register
indexed memory form which is
invalid for store instructions. This wasn't detected by the predicate but it
was detected by the assembler.
The patch changes to using the `Q' constraint which doesn't allow the register
indexed memory form. The
predicate was also tightened to reject the register indexed memory and LO_SUM
DLT memory address
forms that are unsuitable for stores on hppa.
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11
with no objserved
regressions. Committed to trunk and 4.9 branch.
Dave
--
John David Anglin dave.ang...@bell.net
2015-01-03 John David Anglin
* config/pa/pa.md (decrement_and_branch_until_zero): Use `Q' constraint
instead of `m' constraint. Likewise for unnamed movb comparison
patterns using reg_before_reload_operand predicate.
* config/pa/predicates.md (reg_before_reload_operand): Tighten
predicate to reject register index and LO_SUM DLT memory forms
after reload.
Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 219114)
+++ config/pa/pa.md (working copy)
@@ -8922,7 +8922,7 @@
;; strength reduction is used. It is actually created when the instruction
;; combination phase combines the special loop test. Since this insn
;; is both a jump insn and has an output, it must deal with its own
-;; reloads, hence the `m' constraints. The `!' constraints direct reload
+;; reloads, hence the `Q' constraints. The `!' constraints direct reload
;; to not choose the register alternatives in the event a reload is needed.
(define_insn "decrement_and_branch_until_zero"
[(set (pc)
@@ -8929,7 +8929,7 @@
(if_then_else
(match_operator 2 "comparison_operator"
[(plus:SI
- (match_operand:SI 0 "reg_before_reload_operand" "+!r,!*f,*m")
+ (match_operand:SI 0 "reg_before_reload_operand" "+!r,!*f,*Q")
(match_operand:SI 1 "int5_operand" "L,L,L"))
(const_int 0)])
(label_ref (match_operand 3 "" ""))
@@ -9018,7 +9018,7 @@
[(match_operand:SI 1 "register_operand" "r,r,r,r") (const_int 0)])
(label_ref (match_operand 3 "" ""))
(pc)))
- (set (match_operand:SI 0 "reg_before_reload_operand" "=!r,!*f,*m,!*q")
+ (set (match_operand:SI 0 "reg_before_reload_operand" "=!r,!*f,*Q,!*q")
(match_dup 1))]
""
"* return pa_output_movb (operands, insn, which_alternative, 0); "
@@ -9090,7 +9090,7 @@
[(match_operand:SI 1 "register_operand" "r,r,r,r") (const_int 0)])
(pc)
(label_ref (match_operand 3 "" ""
- (set (match_operand:SI 0 "reg_before_reload_operand" "=!r,!*f,*m,!*q")
+ (set (match_operand:SI 0 "reg_before_reload_operand" "=!r,!*f,*Q,!*q")
(match_dup 1))]
""
"* return pa_output_movb (operands, insn, which_alternative, 1); "
Index: config/pa/predicates.md
===
--- config/pa/predicates.md (revision 219114)
+++ config/pa/predicates.md (working copy)
@@ -528,20 +528,29 @@
;; This predicate is used for branch patterns that internally handle
;; register reloading. We need to accept non-symbolic memory operands
;; after reload to ensure that the pattern is still valid if reload
-;; didn't find a hard register for the operand.
+;; didn't find a hard register for the operand. We also reject index
+;; and lo_sum DLT address as these are invalid for move destinations.
(define_predicate "reg_before_reload_operand"
(match_code "reg,mem")
{
+ rtx op0;
+
if (register_operand (op, mode))
return true;
- if (reload_completed
- && memory_operand (op, mode)
- && !symbolic_memory_operand (op, mode))
-return true;
+ if (!reload_in_progress && !reload_completed)
+return false;
- return false;
+ if (! MEM_P (op))
+return false;
+
+ op0 = XEXP (op, 0);
+
+ return (memory_address_p (mode, op0)
+ && !IS_INDEX_ADDR_P (op0)
+ && !IS_LO_SUM_DLT_ADDR_P (op0)
+ && !symbolic_memory_operand (op, mode));
})
;; True iff OP is a register or const_0 operand for MODE.
Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
wrote:
> On Wed, 31 Dec 2014, H.J. Lu wrote:
>
>> - /* Arguments for a sibling call that are pushed to memory are passed
>> - using the incoming argument pointer of the current function. These
>> - may or may not be frame related depending on the target. Since
>> - argument pointer related stores are not currently tracked, we treat
>> - a sibling call as though it does a wild read. */
>> - if (SIBLING_CALL_P (insn))
>> + if (targetm.sibcall_wild_read_p (insn))
>> {
>> add_wild_read (bb_info);
>> return;
>
> Instead of falling through to code designed to handle normal calls, it
> would be better to treat them separately. Potentially, there are other
> optimizations that may be applicable. If a sibcall doesn't read from
> the frame, add_non_frame_wild_read() can be called. This would restore
> the x86 optimization.
>
That will a new optimization. I am trying to restore the old behavior on
x86 with minimum impact in stage 3.
--
H.J.
Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
> wrote:
>> On Wed, 31 Dec 2014, H.J. Lu wrote:
>>
>>> - /* Arguments for a sibling call that are pushed to memory are passed
>>> - using the incoming argument pointer of the current function. These
>>> - may or may not be frame related depending on the target. Since
>>> - argument pointer related stores are not currently tracked, we treat
>>> - a sibling call as though it does a wild read. */
>>> - if (SIBLING_CALL_P (insn))
>>> + if (targetm.sibcall_wild_read_p (insn))
>>> {
>>>add_wild_read (bb_info);
>>>return;
>>
>> Instead of falling through to code designed to handle normal calls, it
>> would be better to treat them separately. Potentially, there are other
>> optimizations that may be applicable. If a sibcall doesn't read from
>> the frame, add_non_frame_wild_read() can be called. This would restore
>> the x86 optimization.
>>
>
> That will a new optimization. I am trying to restore the old behavior on
> x86 with minimum impact in stage 3.
Not really. In gcc.dg/pr44194-1.c, the sibcall was not a const function and
this case
was covered by this hunk of code:
else
/* Every other call, including pure functions, may read any memory
that is not relative to the frame. */
add_non_frame_wild_read (bb_info);
Dave
--
John David Anglin dave.ang...@bell.net
Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin wrote:
> On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
>
>> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
>> wrote:
>>> On Wed, 31 Dec 2014, H.J. Lu wrote:
>>>
- /* Arguments for a sibling call that are pushed to memory are passed
- using the incoming argument pointer of the current function. These
- may or may not be frame related depending on the target. Since
- argument pointer related stores are not currently tracked, we treat
- a sibling call as though it does a wild read. */
- if (SIBLING_CALL_P (insn))
+ if (targetm.sibcall_wild_read_p (insn))
{
add_wild_read (bb_info);
return;
>>>
>>> Instead of falling through to code designed to handle normal calls, it
>>> would be better to treat them separately. Potentially, there are other
>>> optimizations that may be applicable. If a sibcall doesn't read from
>>> the frame, add_non_frame_wild_read() can be called. This would restore
>>> the x86 optimization.
>>>
>>
>> That will a new optimization. I am trying to restore the old behavior on
>> x86 with minimum impact in stage 3.
>
>
> Not really. In gcc.dg/pr44194-1.c, the sibcall was not a const function and
> this case
> was covered by this hunk of code:
>
> else
> /* Every other call, including pure functions, may read any memory
>that is not relative to the frame. */
> add_non_frame_wild_read (bb_info);
>
Revision 219037 has
diff --git a/gcc/dse.c b/gcc/dse.c
index 2555bd1..3a7f31c 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -2483,6 +2483,17 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn)
insn_info->cannot_delete = true;
+ /* Arguments for a sibling call that are pushed to memory are passed
+ using the incoming argument pointer of the current function. These
+ may or may not be frame related depending on the target. Since
+ argument pointer related stores are not currently tracked, we treat
+ a sibling call as though it does a wild read. */
+ if (SIBLING_CALL_P (insn))
+ {
+add_wild_read (bb_info);
+return;
+ }
+
/* Const functions cannot do anything bad i.e. read memory,
however, they can read their parameters which may have
been pushed onto the stack.
My patch changes it to
diff --git a/gcc/dse.c b/gcc/dse.c
index 2555bd1..c0e1a0c 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -2483,6 +2483,12 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn)
insn_info->cannot_delete = true;
+ if (targetm.sibcall_wild_read_p (insn))
+ {
+add_wild_read (bb_info);
+return;
+ }
+
/* Const functions cannot do anything bad i.e. read memory,
however, they can read their parameters which may have
been pushed onto the stack.
On x86, it is the same as before revision 219037 since
targetm.sibcall_wild_read_p always returns false on x86.
--
H.J.
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
Dominique Dhumieres wrote:
The test gfortran.dg/coarray/codimension_2.f90 fails on x86_64-apple-darwin14
with -m32
(see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00185.html). The error is
[...]
Yes, there seems to be something wrong. The module has:
U _F.caf_token__global_coarrays_MOD_b
B __global_coarrays_MOD_b
where the token should not be "U"ndefined but "B". On the other hand,
the USEr of the module has:
B _F.caf_token__global_coarrays_MOD_b
U __global_coarrays_MOD_b
but it should have a "U" – with two users one even would get: "multiple
definition of `_F.caf_token__global_coarrays_MOD_b'".
Untested patch attached.
Tobias
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 9ef6bfc..84a8a6e 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -830,14 +830,23 @@ gfc_build_qualified_array (tree decl, gfc_symbol * sym)
IDENTIFIER_POINTER (gfc_sym_mangled_identifier (sym;
token = build_decl (DECL_SOURCE_LOCATION (decl), VAR_DECL, token_name,
token_type);
- TREE_PUBLIC (token) = 1;
+ if (sym->attr.use_assoc)
+ DECL_EXTERNAL (token) = 1;
+ else
+ TREE_STATIC (token) = 1;
+
+ if (sym->attr.use_assoc || sym->attr.access != ACCESS_PRIVATE ||
+ sym->attr.public_used)
+ TREE_PUBLIC (token) = 1;
}
else
- token = gfc_create_var_np (token_type, "caf_token");
+ {
+ token = gfc_create_var_np (token_type, "caf_token");
+ TREE_STATIC (token) = 1;
+ }
GFC_TYPE_ARRAY_CAF_TOKEN (type) = token;
DECL_ARTIFICIAL (token) = 1;
- TREE_STATIC (token) = 1;
gfc_add_decl_to_function (token);
}
Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
> On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
> wrote:
>> On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
>>
>>> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
>>> wrote:
On Wed, 31 Dec 2014, H.J. Lu wrote:
> - /* Arguments for a sibling call that are pushed to memory are
> passed
> - using the incoming argument pointer of the current function. These
> - may or may not be frame related depending on the target. Since
> - argument pointer related stores are not currently tracked, we treat
> - a sibling call as though it does a wild read. */
> - if (SIBLING_CALL_P (insn))
> + if (targetm.sibcall_wild_read_p (insn))
> {
> add_wild_read (bb_info);
> return;
Instead of falling through to code designed to handle normal calls, it
would be better to treat them separately. Potentially, there are other
optimizations that may be applicable. If a sibcall doesn't read from
the frame, add_non_frame_wild_read() can be called. This would restore
the x86 optimization.
>>>
>>> That will a new optimization. I am trying to restore the old behavior on
>>> x86 with minimum impact in stage 3.
>>
>>
>> Not really. In gcc.dg/pr44194-1.c, the sibcall was not a const function and
>> this case
>> was covered by this hunk of code:
>>
>> else
>>/* Every other call, including pure functions, may read any memory
>> that is not relative to the frame. */
>>add_non_frame_wild_read (bb_info);
>>
>
> Revision 219037 has
>
> diff --git a/gcc/dse.c b/gcc/dse.c
> index 2555bd1..3a7f31c 100644
> --- a/gcc/dse.c
> +++ b/gcc/dse.c
> @@ -2483,6 +2483,17 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn)
>
> insn_info->cannot_delete = true;
>
> + /* Arguments for a sibling call that are pushed to memory are passed
> + using the incoming argument pointer of the current function. These
> + may or may not be frame related depending on the target. Since
> + argument pointer related stores are not currently tracked, we treat
> + a sibling call as though it does a wild read. */
> + if (SIBLING_CALL_P (insn))
> + {
> +add_wild_read (bb_info);
> +return;
> + }
> +
> /* Const functions cannot do anything bad i.e. read memory,
>however, they can read their parameters which may have
>been pushed onto the stack.
>
> My patch changes it to
>
> diff --git a/gcc/dse.c b/gcc/dse.c
> index 2555bd1..c0e1a0c 100644
> --- a/gcc/dse.c
> +++ b/gcc/dse.c
> @@ -2483,6 +2483,12 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn)
>
> insn_info->cannot_delete = true;
>
> + if (targetm.sibcall_wild_read_p (insn))
> + {
> +add_wild_read (bb_info);
> +return;
> + }
> +
> /* Const functions cannot do anything bad i.e. read memory,
>however, they can read their parameters which may have
>been pushed onto the stack.
>
> On x86, it is the same as before revision 219037 since
> targetm.sibcall_wild_read_p always returns false on x86.
Understood. The point is the subsequent code for const functions is based on
assumptions that
are not generally true for sibcalls:
/* This field is only used for the processing of const functions.
These functions cannot read memory, but they can read the stack
because that is where they may get their parms. We need to be
this conservative because, like the store motion pass, we don't
consider CALL_INSN_FUNCTION_USAGE when processing call insns.
Moreover, we need to distinguish two cases:
1. Before reload (register elimination), the stores related to
outgoing arguments are stack pointer based and thus deemed
of non-constant base in this pass. This requires special
handling but also means that the frame pointer based stores
need not be killed upon encountering a const function call.
2. After reload, the stores related to outgoing arguments can be
either stack pointer or hard frame pointer based. This means
that we have no other choice than also killing all the frame
pointer based stores upon encountering a const function call.
This field is set after reload for const function calls. Having
this set is less severe than a wild read, it just means that all
the frame related stores are killed rather than all the stores. */
bool frame_read;
For example, the stores related to sibcall arguments are not in general stack
pointer based. This
suggests to me that we don't have to always kill stack pointer based stores in
the const sibcall case
and they can be optimized.
For me, keeping the sibcall handling separate from normal calls is easier to
understand and
potentially provides a means to optimize stack pointer based stores. Are you
sure that the prior
behaviour was always correct on x86 (e.g., more than 6 arguments)
[doc, committed] add/fix @opindex entries
This is another in my series of cleanups to the GCC user documentation.
I noticed that some recently-added options documented in invoke.texi
were missing @opindex entries, or had incorrect ones. I made a pass
through the whole file to try to fix all the mistakes of this sort that
I spotted -- I probably missed some, but at least this is an incremental
improvement.
The manual isn't consistent about whether the no-* forms of options are
explicitly listed and/or given entries in the index. (In some cases
there are index entries without specific listing of the no-* option in
the documentation, too.) In general I did not mess with that, except
for the very long group of i386 -mmmx, -msse, etc options. Some of
these had negative forms listed and others didn't, and because the list
was so long (spanning multiple pages) already, I thought it better to
remove the existing entries for the -mno-* guys rather than make the
list even bigger by adding the missing ones. While I was at it, I
diddled with the formatting a bit to allow page breaks to be inserted
anywhere in this long @itemx sequence.
Since this is all boring tech writer stuff rather than substantive
changes, I've checked it in under the obvious fix rule.
-Sandra
2015-01-03 Sandra Loosemore
gcc/
* doc/invoke.texi ([-fplan9-extensions]): Add/fix @opindex.
([-fvtv-debug]): Likewise.
([-Wc++-compat]): Likewise.
([-Wc++11-compat]): Likewise.
([-Wc++14-compat]): Likewise.
([-Wno-sized-deallocation]): Likewise.
([-femit-class-debug-always]): Likewise.
([-femit-struct-debug-detailed]): Likewise.
([-fno-keep-inline-dllexport]): Likewise.
([-fira-algorithm]): Likewise.
([-fira-region]): Likewise.
([-flra-remat]): Likewise.
([-fipa-ra]): Likewise.
([-fhoist-adjacent-loads]): Likewise.
([-fisolate-erroneous-paths-dereference]): Likewise.
([-fisolate-erroneous-paths-attribute]): Likewise.
([-ftree-switch-conversion]): Likewise.
([-ftree-tail-merge]): Likewise.
([-ftree-loop-if-convert]): Likewise.
([-ftree-loop-if-convert-stores]): Likewise.
([-ftree-loop-distribution]): Likewise.
([-ftree-loop-distribute-patterns]): Likewise.
([-flto-compression-level]): Likewise.
([-flto-report]): Likewise.
([-flto-report-wpa]): Likewise.
([-fuse-linker-plugin]): Likewise.
([-mfix-cortex-a53-835769]): Likewise.
([-mno-fix-cortex-a53-835769]): Likewise.
([-mmmx]...[-mno-3dnow]): Remove the -mno- forms from the
explicit listing; add a note to the discussion indicating they
exist. Reorder table to group similar options. Add missing
@opindex entries. Add @need commands throughout the table to
allow it to be split across multiple pages.
([-m8bit-idiv]): Fix @opindex.
([-mavx256-split-unaligned-load]): Likewise.
([-mavx256-split-unaligned-store]): Likewise.
([-mstack-protector-guard]): Likewise.
([-mcpu=]): Likewise.
([-mcpu]): Likewise.
([-mpointer-size=]): Likewise.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219158)
+++ gcc/doc/invoke.texi (working copy)
@@ -1942,7 +1942,9 @@ fields within structs/unions}, for detai
Note that this option is off for all targets but i?86 and x86_64
targets using ms-abi.
+
@item -fplan9-extensions
+@opindex fplan9-extensions
Accept some non-standard constructs used in Plan 9 code.
This enables @option{-fms-extensions}, permits passing pointers to
@@ -2453,7 +2455,7 @@ values specified, 'none' will take highe
'preinit'; 'preinit' will take priority over 'std'.
@item -fvtv-debug
-@opindex (fvtv-debug)
+@opindex fvtv-debug
Causes debug versions of the runtime functions for the vtable verification
feature to be called. This assumes the @option{-fvtable-verify=std} or
@option{-fvtable-verify=preinit} has been used. This flag will also cause the
@@ -4622,17 +4624,20 @@ and so on. This option is independent o
disabled in the expression that follows @code{__extension__}.
@item -Wc++-compat @r{(C and Objective-C only)}
+@opindex Wc++-compat
Warn about ISO C constructs that are outside of the common subset of
ISO C and ISO C++, e.g.@: request for implicit conversion from
@code{void *} to a pointer to non-@code{void} type.
@item -Wc++11-compat @r{(C++ and Objective-C++ only)}
+@opindex Wc++11-compat
Warn about C++ constructs whose meaning differs between ISO C++ 1998
and ISO C++ 2011, e.g., identifiers in ISO C++ 1998 that are keywords
in ISO C++ 2011. This warning turns on @option{-Wnarrowing} and is
enabled by @option{-Wall}.
@item -Wc++14-compat @r{(C++ and Objective-C++ only)}
+@opindex Wc++14-compat
Warn about C++ constructs whose meaning differs between ISO C++ 2011
and ISO C++ 201
Re: [PATCH, ada]: Use xasprintf instead of unchecked asprintf
> 2014-12-31 Uros Bizjak > > * gcc-interface/misc.c (internal_error_function): Use xasprintf instead > of unchecked asprintf. > > Although almost trivial, this patch is *not* tested, so I'd kindly ask > someone to bootstrap and regresion test this patch. Sanity checked only, but that's good enough so you can apply it, thanks. -- Eric Botcazou
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
From a quick test, with the patch I still see the error with -m32 /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cc8Yz3Jr.s:18:non-relocatable subtraction expression, "__F.caf_token__global_coarrays_MOD_b" minus "L1$pb" /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cc8Yz3Jr.s:18:symbol: "__F.caf_token__global_coarrays_MOD_b" can't be undefined in a subtraction expression but also the test fails at link time with -m64 [Book15] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/codimension_2.f90 /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/codimension_2a.f90 -fcoarray=lib -O2 -lcaf_single Undefined symbols for architecture x86_64: "__F.caf_token__global_coarrays_MOD_b", referenced from: __caf_init.0 in ccljvUii.o _MAIN__ in ccmqTPwK.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status Dominique > Le 3 janv. 2015 à 21:50, Tobias Burnus a écrit : > > Dominique Dhumieres wrote: >> The test gfortran.dg/coarray/codimension_2.f90 fails on >> x86_64-apple-darwin14 with -m32 >> (see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00185.html). The >> error is >> [...] > > Yes, there seems to be something wrong. The module has: > > U _F.caf_token__global_coarrays_MOD_b > B __global_coarrays_MOD_b > > where the token should not be "U"ndefined but "B". On the other hand, the > USEr of the module has: > > B _F.caf_token__global_coarrays_MOD_b > U __global_coarrays_MOD_b > > but it should have a "U" – with two users one even would get: "multiple > definition of `_F.caf_token__global_coarrays_MOD_b'". > > > Untested patch attached. > > Tobias >
Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin wrote:
> On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
>
>> On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
>> wrote:
>>> On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
>>>
On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
wrote:
> On Wed, 31 Dec 2014, H.J. Lu wrote:
>
>> - /* Arguments for a sibling call that are pushed to memory are
>> passed
>> - using the incoming argument pointer of the current function.
>> These
>> - may or may not be frame related depending on the target. Since
>> - argument pointer related stores are not currently tracked, we
>> treat
>> - a sibling call as though it does a wild read. */
>> - if (SIBLING_CALL_P (insn))
>> + if (targetm.sibcall_wild_read_p (insn))
>> {
>> add_wild_read (bb_info);
>> return;
>
> Instead of falling through to code designed to handle normal calls, it
> would be better to treat them separately. Potentially, there are other
> optimizations that may be applicable. If a sibcall doesn't read from
> the frame, add_non_frame_wild_read() can be called. This would restore
> the x86 optimization.
>
That will a new optimization. I am trying to restore the old behavior on
x86 with minimum impact in stage 3.
>>>
>>>
>>> Not really. In gcc.dg/pr44194-1.c, the sibcall was not a const function
>>> and this case
>>> was covered by this hunk of code:
>>>
>>> else
>>>/* Every other call, including pure functions, may read any memory
>>> that is not relative to the frame. */
>>>add_non_frame_wild_read (bb_info);
>>>
>>
>> Revision 219037 has
>>
>> diff --git a/gcc/dse.c b/gcc/dse.c
>> index 2555bd1..3a7f31c 100644
>> --- a/gcc/dse.c
>> +++ b/gcc/dse.c
>> @@ -2483,6 +2483,17 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn)
>>
>> insn_info->cannot_delete = true;
>>
>> + /* Arguments for a sibling call that are pushed to memory are passed
>> + using the incoming argument pointer of the current function. These
>> + may or may not be frame related depending on the target. Since
>> + argument pointer related stores are not currently tracked, we treat
>> + a sibling call as though it does a wild read. */
>> + if (SIBLING_CALL_P (insn))
>> + {
>> +add_wild_read (bb_info);
>> +return;
>> + }
>> +
>> /* Const functions cannot do anything bad i.e. read memory,
>>however, they can read their parameters which may have
>>been pushed onto the stack.
>>
>> My patch changes it to
>>
>> diff --git a/gcc/dse.c b/gcc/dse.c
>> index 2555bd1..c0e1a0c 100644
>> --- a/gcc/dse.c
>> +++ b/gcc/dse.c
>> @@ -2483,6 +2483,12 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn)
>>
>> insn_info->cannot_delete = true;
>>
>> + if (targetm.sibcall_wild_read_p (insn))
>> + {
>> +add_wild_read (bb_info);
>> +return;
>> + }
>> +
>> /* Const functions cannot do anything bad i.e. read memory,
>>however, they can read their parameters which may have
>>been pushed onto the stack.
>>
>> On x86, it is the same as before revision 219037 since
>> targetm.sibcall_wild_read_p always returns false on x86.
>
>
> Understood. The point is the subsequent code for const functions is based on
> assumptions that
> are not generally true for sibcalls:
>
> /* This field is only used for the processing of const functions.
> These functions cannot read memory, but they can read the stack
> because that is where they may get their parms. We need to be
> this conservative because, like the store motion pass, we don't
> consider CALL_INSN_FUNCTION_USAGE when processing call insns.
> Moreover, we need to distinguish two cases:
> 1. Before reload (register elimination), the stores related to
> outgoing arguments are stack pointer based and thus deemed
> of non-constant base in this pass. This requires special
> handling but also means that the frame pointer based stores
> need not be killed upon encountering a const function call.
> 2. After reload, the stores related to outgoing arguments can be
> either stack pointer or hard frame pointer based. This means
> that we have no other choice than also killing all the frame
> pointer based stores upon encountering a const function call.
> This field is set after reload for const function calls. Having
> this set is less severe than a wild read, it just means that all
> the frame related stores are killed rather than all the stores. */
> bool frame_read;
>
> For example, the stores related to sibcall arguments are not in general stack
> pointer based. This
> suggests to me that we don't have to always kill stack pointer based stores
> in the const sibcall case
> and they can be optimized.
>
> For me, keeping the sibcall handling separate fr
Re: [Patch, Fortran, OOP] PR 63552: Type-bound procedures rejected as actual argument to dummy procedure
Hi Janus,
Janus Weil wrote:
the attached patch allows type-bound procedures to be passed actual
arguments to dummy procedures. When doing this, on has to transform
the expression such that the corresponding procedure pointer from the
vtab is used.
...
+ else if (sym->ts.type == BT_CLASS)
+ {
+ gfc_add_vptr_component (primary);
+ gfc_add_component_ref (primary, name);
+ }
+ else if (sym->ts.type == BT_DERIVED)
+ {
If the procedure is NON_OVERRIDABLE, it should be directly called
without the detour through the vptr.
Tobias
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
Dominique d'Humières wrote:
From a quick test, with the patch I still see the error with -m32
It helps if one actually adds the decl. The following (still untested)
should help. I also marked the token as nonaliasing (it really should!)
and added for proc pointers the tree-public optimization.
Tobias
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 9ef6bfc..976db2b 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -830,15 +830,32 @@ gfc_build_qualified_array (tree decl, gfc_symbol * sym)
IDENTIFIER_POINTER (gfc_sym_mangled_identifier (sym;
token = build_decl (DECL_SOURCE_LOCATION (decl), VAR_DECL, token_name,
token_type);
- TREE_PUBLIC (token) = 1;
+ if (sym->attr.use_assoc)
+ DECL_EXTERNAL (token) = 1;
+ else
+ TREE_STATIC (token) = 1;
+
+ if (sym->attr.use_assoc || sym->attr.access != ACCESS_PRIVATE ||
+ sym->attr.public_used)
+ TREE_PUBLIC (token) = 1;
}
else
- token = gfc_create_var_np (token_type, "caf_token");
+ {
+ token = gfc_create_var_np (token_type, "caf_token");
+ TREE_STATIC (token) = 1;
+ }
GFC_TYPE_ARRAY_CAF_TOKEN (type) = token;
DECL_ARTIFICIAL (token) = 1;
- TREE_STATIC (token) = 1;
- gfc_add_decl_to_function (token);
+ DECL_NONALIASED (token) = 1;
+
+ if (sym->module && !sym->attr.use_assoc)
+ {
+ DECL_CONTEXT (token) = sym->ns->proc_name->backend_decl;
+ gfc_module_add_decl (cur_module, token);
+ }
+ else
+ gfc_add_decl_to_function (token);
}
for (dim = 0; dim < GFC_TYPE_ARRAY_RANK (type); dim++)
@@ -1664,7 +1681,9 @@ get_proc_pointer_decl (gfc_symbol *sym)
else if (sym->module && sym->ns->proc_name->attr.flavor == FL_MODULE)
{
/* This is the declaration of a module variable. */
- TREE_PUBLIC (decl) = 1;
+ if (sym->ns->proc_name->attr.flavor == FL_MODULE
+ && (sym->attr.access != ACCESS_PRIVATE || sym->attr.public_used))
+ TREE_PUBLIC (decl) = 1;
TREE_STATIC (decl) = 1;
}
Re: [PATCH/TopLevel] Fix compiling libgo with a combined sources
On Mon, Nov 24, 2014 at 1:32 PM, Jeff Law wrote: > On 11/22/14 21:20, Andrew Pinski wrote: >> >> Hi, >>The problem here is here is that OBJCOPY is not being set to the >> newly built objcopy when compiling libgo. This patch adds >> OBJCOPY_FOR_TARGET to the toplevel configure/Makefile so that when >> libgo is compiled OBJCOPY is set to OBJCOPY_FOR_TARGET. >> >> I noticed this issue when building an aarch64 cross compile on an >> older system where objcopy did not understand aarch64. >> >> OK? Bootstrapped and tested on x86_64 with no regressions. Also >> tested with a combined build for a cross compiler to >> aarch64-linux-gnu. >> >> Thanks, >> Andrew Pinski >> >> >> * Makefile.def (flags_to_pass): Pass OBJCOPY_FOR_TARGET also. >> * Makefile.tpl (HOST_EXPORTS): Add OBJCOPY_FOR_TARGET. >> (BASE_TARGET_EXPORTS): Add OBJCOPY. >> (OBJCOPY_FOR_TARGET): New variable. >> (EXTRA_TARGET_FLAGS): Add OBJCOPY. >> * Makefile.in: Regenerate. >> * configure.ac: Check for already installed target objcopy. >> Also GCC_TARGET_TOOL on objcopy. >> * configure: Regenerate. > > OK Committed to GCC and gdb/binutils repos now. Thanks, Andrew > Jeff > >
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
Compilation with the new patch fails with ../../work/gcc/fortran/trans-decl.c: In function 'void gfc_build_qualified_array(tree, gfc_symbol*)': ../../work/gcc/fortran/trans-decl.c:855:25: error: 'cur_module' was not declared in this scope gfc_module_add_decl (cur_module, token); Dominique > Le 3 janv. 2015 à 23:30, Tobias Burnus a écrit : > > Dominique d'Humières wrote: >> From a quick test, with the patch I still see the error with -m32 > > It helps if one actually adds the decl. The following (still untested) should > help. I also marked the token as nonaliasing (it really should!) and added > for proc pointers the tree-public optimization. > > Tobias >
[doc, committed] copy-edit -fsemantic-interposition documentation
I spotted some typos in the description of -fsemantic-interposition.
This patch fixes them and also cleans up some awkward grammar.
Committed under the obvious fix rule.
-Sandra
2015-01-03 Sandra Loosemore
gcc/
* doc/invoke.texi ([-fsemantic-interposition]): Fix typos and
tidy grammar.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219164)
+++ gcc/doc/invoke.texi (working copy)
@@ -8070,19 +8070,21 @@ This option has no effect unless @option
@item -fsemantic-interposition
@opindex fsemantic-interposition
-Some object formats, like ELF, allow interposing of symbols by dynamic linker.
-This means that for symbols exported from the DSO compiler can not perform
-inter-procedural propagation, inlining and other optimizations in anticipation
+Some object formats, like ELF, allow interposing of symbols by the
+dynamic linker.
+This means that for symbols exported from the DSO, the compiler cannot perform
+interprocedural propagation, inlining and other optimizations in anticipation
that the function or variable in question may change. While this feature is
useful, for example, to rewrite memory allocation functions by a debugging
implementation, it is expensive in the terms of code quality.
-With @option{-fno-semantic-inteposition} compiler assumest that if interposition
-happens for functions the overwritting function will have
-precisely same semantics (and side effects). Similarly if interposition happens
+With @option{-fno-semantic-interposition} the compiler assumes that
+if interposition happens for functions the overwriting function will have
+precisely the same semantics (and side effects).
+Similarly if interposition happens
for variables, the constructor of the variable will be the same. The flag
-has no effect for functions explicitly declared inline, where
-interposition changing semantic is never allowed and for symbols explicitly
-declared weak.
+has no effect for functions explicitly declared inline
+(where it is never allowed for interposition to change semantics)
+and for symbols explicitly declared weak.
@item -fshrink-wrap
@opindex fshrink-wrap
[doc, committed] copy-edit documentation for -fisolate-erroneous-paths-*
This patch fixes a bunch of small problems in the descriptions of
-fisolate-erroneous-paths-dereference and
-fisolate-erroneous-paths-attribute:
* "which"/"that" confusion
* use American spelling of "behavior" vs British "behaviour"
* most places in the manual use "null" or more rarely "@code{NULL}"
rather than "NULL"
* wrong markup on option
I also added a note that -fisolate-erroneous-paths-dereference is
enabled by default at -O2 since it seemed odd to mention only that the
other option is *not* enabled.
Committed under the obvious fix rule, since this is more boring
tech-writer stuff.
-Sandra
2015-01-03 Sandra Loosemore
gcc/
* doc/invoke.texi ([-fisolate-erroneous-paths-dereference]):
Copy-edit description.
([-fisolate-erroneous-paths-attribute]): Likewise.
* common.opt (fisolate-erroneous-paths-dereference):
Copy-edit description.
(fisolate-erroneous-paths-attribute): Likewise.
Index: gcc/common.opt
===
--- gcc/common.opt (revision 219165)
+++ gcc/common.opt (working copy)
@@ -2241,16 +2241,16 @@ Enable string length optimizations on tr
fisolate-erroneous-paths-dereference
Common Report Var(flag_isolate_erroneous_paths_dereference) Optimization
-Detect paths which trigger erroneous or undefined behaviour due to
-dereferencing a NULL pointer. Isolate those paths from the main control
-flow and turn the statement with erroneous or undefined behaviour into a trap.
+Detect paths that trigger erroneous or undefined behavior due to
+dereferencing a null pointer. Isolate those paths from the main control
+flow and turn the statement with erroneous or undefined behavior into a trap.
fisolate-erroneous-paths-attribute
Common Report Var(flag_isolate_erroneous_paths_attribute) Optimization
-Detect paths which trigger erroneous or undefined behaviour due a NULL value
-being used in a way which is forbidden by a returns_nonnull or nonnull
+Detect paths that trigger erroneous or undefined behavior due a null value
+being used in a way forbidden by a returns_nonnull or nonnull
attribute. Isolate those paths from the main control flow and turn the
-statement with erroneous or undefined behaviour into a trap.
+statement with erroneous or undefined behavior into a trap.
ftree-loop-distribution
Common Report Var(flag_tree_loop_distribution) Optimization
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219166)
+++ gcc/doc/invoke.texi (working copy)
@@ -8234,17 +8234,18 @@ This flag is enabled by default at @opti
@item -fisolate-erroneous-paths-dereference
@opindex fisolate-erroneous-paths-dereference
-Detect paths which trigger erroneous or undefined behaviour due to
-dereferencing a NULL pointer. Isolate those paths from the main control
-flow and turn the statement with erroneous or undefined behaviour into a trap.
+Detect paths that trigger erroneous or undefined behavior due to
+dereferencing a null pointer. Isolate those paths from the main control
+flow and turn the statement with erroneous or undefined behavior into a trap.
+This flag is enabled by default at @option{-O2} and higher.
@item -fisolate-erroneous-paths-attribute
@opindex fisolate-erroneous-paths-attribute
-Detect paths which trigger erroneous or undefined behaviour due a NULL value
-being used in a way which is forbidden by a @code{returns_nonnull} or @code{nonnull}
+Detect paths that trigger erroneous or undefined behavior due a null value
+being used in a way forbidden by a @code{returns_nonnull} or @code{nonnull}
attribute. Isolate those paths from the main control flow and turn the
-statement with erroneous or undefined behaviour into a trap. This is not
-currently enabled, but may be enabled by @code{-O2} in the future.
+statement with erroneous or undefined behavior into a trap. This is not
+currently enabled, but may be enabled by @option{-O2} in the future.
@item -ftree-sink
@opindex ftree-sink
[doc, committed] clean up -fauto-profile documentation
I saw that the documentation for the new -fauto-profile option needed a
lot of work -- it had formatting and markup problems, terminology
problems (e.g., "linux" is not a proper name by GNU documentation
standards), and content problems like failure to document the filename
default. I removed the previously documented optional requirement (?)
for "An Intel processor with last branch record (LBR) support" as IIUC
that is a property of perf and/or create_gcov and not of GCC's support
for this option, which seems to have no target-specific component.
I also did minor cleanup on the -fprofile-generate and -fprofile-use
options, which also had some of the same markup problems.
I've committed this under the "obvious fix" rule.
-Sandra
2015-01-03 Sandra Loosemore
gcc/
* doc/invoke.texi ([-fprofile-generate], [-fprofile-use]):
Fix markup, light copy-editing.
([-fauto-profile]): Rewrite to fix formatting and content
problems.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219170)
+++ gcc/doc/invoke.texi (working copy)
@@ -9325,7 +9325,7 @@ profile useful for later recompilation w
optimization. You must use @option{-fprofile-generate} both when
compiling and when linking your program.
-The following options are enabled: @code{-fprofile-arcs}, @code{-fprofile-values}, @code{-fvpt}.
+The following options are enabled: @option{-fprofile-arcs}, @option{-fprofile-values}, @option{-fvpt}.
If @var{path} is specified, GCC looks at the @var{path} to find
the profile feedback data files. See @option{-fprofile-dir}.
@@ -9333,12 +9333,12 @@ the profile feedback data files. See @op
@item -fprofile-use
@itemx -fprofile-use=@var{path}
@opindex fprofile-use
-Enable profile feedback directed optimizations, and optimizations
-generally profitable only with profile feedback available.
-
-The following options are enabled: @code{-fbranch-probabilities}, @code{-fvpt},
-@code{-funroll-loops}, @code{-fpeel-loops}, @code{-ftracer}, @code{-ftree-vectorize},
-@code{ftree-loop-distribute-patterns}
+Enable profile feedback-directed optimizations,
+and the following optimizations
+which are generally profitable only with profile feedback available:
+@option{-fbranch-probabilities}, @option{-fvpt},
+@option{-funroll-loops}, @option{-fpeel-loops}, @option{-ftracer},
+@option{-ftree-vectorize}, and @option{ftree-loop-distribute-patterns}.
By default, GCC emits an error message if the feedback profiles do not
match the source code. This error can be turned into a warning by using
@@ -9351,37 +9351,39 @@ the profile feedback data files. See @op
@item -fauto-profile
@itemx -fauto-profile=@var{path}
@opindex fauto-profile
-Enable sampling based feedback directed optimizations, and optimizations
-generally profitable only with profile feedback available.
-
-The following options are enabled: @code{-fbranch-probabilities}, @code{-fvpt},
-@code{-funroll-loops}, @code{-fpeel-loops}, @code{-ftracer}, @code{-ftree-vectorize},
-@code{-finline-functions}, @code{-fipa-cp}, @code{-fipa-cp-clone},
-@code{-fpredictive-commoning}, @code{-funswitch-loops},
-@code{-fgcse-after-reload}, @code{-ftree-loop-distribute-patterns},
-
-If @var{path} is specified, GCC looks at the @var{path} to find
-the profile feedback data files.
-
-In order to collect AutoFDO profile, you need to have:
-
-1. A linux system with linux perf support
-2. (optional) An Intel processor with last branch record (LBR) support. This is
- to guarantee accurate instruction level profile, which is important for
- AutoFDO performance.
-
-To collect the profile, first use linux perf to collect raw profile
-(see @uref{https://perf.wiki.kernel.org/}).
+Enable sampling-based feedback-directed optimizations,
+and the following optimizations
+which are generally profitable only with profile feedback available:
+@option{-fbranch-probabilities}, @option{-fvpt},
+@option{-funroll-loops}, @option{-fpeel-loops}, @option{-ftracer},
+@option{-ftree-vectorize},
+@option{-finline-functions}, @option{-fipa-cp}, @option{-fipa-cp-clone},
+@option{-fpredictive-commoning}, @option{-funswitch-loops},
+@option{-fgcse-after-reload}, and @option{-ftree-loop-distribute-patterns}.
+
+@var{path} is the name of a file containing AutoFDO profile information.
+If omitted, it defaults to @file{fbdata.afdo} in the current directory.
+
+Producing an AutoFDO profile data file requires running your program
+with the @command{perf} utility on a supported GNU/Linux target system.
+For more information, see @uref{https://perf.wiki.kernel.org/}.
E.g.
-@code{perf record -e br_inst_retired:near_taken -b -o perf.data -- your_program}
+@smallexample
+perf record -e br_inst_retired:near_taken -b -o perf.data \
+-- your_program
+@end smallexample
-Then use create_gcov tool, which takes raw profile and unstripped binary to
-generate AutoFDO profile that can be used by GC
