Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
Eric Botcazou wrote:
>> It's not fully fixing the issue as _all_ aggregates that may be
>> accessed beyond their declarations size are broken.
>
>Sure, but we don't need to support such nonsense in the general case.
>And not
>every language allows it, for example in Ada you cannot do that of
>course.
Well, we certainly need to support it as far as not ICEing
>> I'd say we should simply stop giving aggregates a mode besides
>BLKmode.
>> What can possibly break with that ...
>
>Nothing, but this will unnecessarily pessimize well-behaved languages,
>e.g. in
>Ada we overalign structures in some cases to give them integral modes.
What are the transformations that are enabled by making something not BLKmode?
On the gimple level I cannot think of one..
>> struct { char c[4]; }
>>
>> has SImode, we accept all trailing arrays as possibly extending
>beyond the
>> struct declaration.
>>
>> Alternatively all structs with aggregate members should not have a
>> mode != BLKmode.
>
>This could work as well, although I'd restrict this to arrays,
>recursively.
Works for me.
Thanks,
Richard.
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
Eric Botcazou wrote: >> That being said, the concern is certainly valid so we may want to go >for a >> kludge instead of the fix. The point is that the kludge should do >exactly >> what the fix would have done in the RTL expander and nothing more; >it's out >> of question to pessimize all the other languages and all the other >cases in >> the C family of languages for highly artificial testcases using >> non-portable code. > >What about: > 1. a new boolean language hook support_trailing_arrays, > 2. a new flag on RECORD_OR_UNION_TYPE_P types, >3. modifying stor-layout.c so that it sets the new flag on the >appropriate >types when support_trailing_arrays is true, >4. modifying expr.c along the lines of Bernd's latest idea to avoid >returning >anything but a MEM for objects with a type on which the flag is set? Sounds more complicated than the other two options. Fix the types mode or add the expand flag. I'm ok with either variant and I'm not worried about the ABI thing too much for the important archs. Richard.
Re: [wide-int] small cleanup in wide-int.*
Richard Sandiford wrote: >Kenneth Zadeck writes: >>#define WIDE_INT_MAX_ELTS \ >> - ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ >> - / HOST_BITS_PER_WIDE_INT) >> + (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ >> +/ HOST_BITS_PER_WIDE_INT) + 1) > I think this should be: > > (MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 1) > > We only need an extra HWI if MAX_BITSIZE_MODE_ANY_INT is an exact >multiple > of HOST_BITS_PER_WIDE_INT. we will do this later when some other issues that Eric B raised are >settled. >>> I think you're talking about defining MAX_BITSIZE_MODE_ANY_INT as >>> MAX_SIZE_MODE_ANY_INT * BITS_PER_UNIT, but that's orthogonal to the >>> change above. IMO it doesn't make sense to both round up the >division >>> and also add 1 to the result. So I think we should make this change >>> regardless of whatever follows. >>> >>> Looks good to me otherwise, thanks. >>> >>> Richard >>> >> so this one works the way you want.While it is true the the >problems >> are disjoint, the solution will likely evolving change the same lines >of >> source in two different ways. > >Well, if we're changing the definition of WIDE_INT_MAX_ELTS now (and we >are) >I think we should change it to something that makes sense. All we want >is >1 extra bit. We don't need to round up the size and then add a whole >HWI on top. Doing that will potentially pessimise targets that don't >need anything beyond SImode. I agree. Richard. >It's not like I can approve the patch anyway though, so I'll leave it >there. > >Thanks, >Richard
Remove regexp and expected output from gtest pass/fail line
I sent a patch to upstream dejagnu so that things like:
FAIL: c-c++-common/asan/global-overflow-1.c -Os output pattern test, is ==4731
==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) byte
s at address 0x02008fff7000 (12)
==4731==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes.
Perhaps you're using ulimit -v
, should match READ of size 1 at 0x[0-9a-f]+ thread T0.*(
|
)#0 0x[0-9a-f]+ (in _*main ([^
]*global-overflow-1.c:20|[^
]*:0)|[(])[^
]*(
|
).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^
]* of size 10[^
]*(
|
)
become:
FAIL: c-c++-common/asan/global-overflow-1.c -Os output pattern test
The actual and expected output are printed to the log instead:
http://lists.gnu.org/archive/html/dejagnu/2013-12/msg0.html
This patch does the same for the gtest stuff. Tested on x86_64-linux-gnu
{,-m32} with a ulimit in place. OK to install?
Thanks,
Richard
Index: gcc/testsuite/lib/asan-dg.exp
===
--- gcc/testsuite/lib/asan-dg.exp (revision 205654)
+++ gcc/testsuite/lib/asan-dg.exp (working copy)
@@ -288,9 +288,10 @@
if { "$status" == "fail" } {
pass "$testname execution test"
if { ![regexp $regexpr ${output}] } {
- fail "$testname output pattern test, should match
$regexpr"
+ fail "$testname output pattern test"
+ send_log "Output was:\n${output}\nShould
match:\n$regexpr\n"
} else {
- pass "$testname output pattern test, $regexpr"
+ pass "$testname output pattern test"
}
} elseif { "$status" == "pass" } {
fail "$testname execution test"
Re: Remove regexp and expected output from gtest pass/fail line
Richard Sandiford writes:
> I sent a patch to upstream dejagnu so that things like:
>
> FAIL: c-c++-common/asan/global-overflow-1.c -Os output pattern test, is
> ==4731
> ==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504)
> byte
> s at address 0x02008fff7000 (12)
> ==4731==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000
> bytes.
> Perhaps you're using ulimit -v
> , should match READ of size 1 at 0x[0-9a-f]+ thread T0.*(
> |
> )#0 0x[0-9a-f]+ (in _*main ([^
> ]*global-overflow-1.c:20|[^
> ]*:0)|[(])[^
> ]*(
> |
> ).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^
> ]* of size 10[^
> ]*(
> |
> )
>
> become:
>
> FAIL: c-c++-common/asan/global-overflow-1.c -Os output pattern test
>
> The actual and expected output are printed to the log instead:
>
> http://lists.gnu.org/archive/html/dejagnu/2013-12/msg0.html
>
> This patch does the same for the gtest stuff. Tested on x86_64-linux-gnu
> {,-m32} with a ulimit in place. OK to install?
Sorry, changelog is:
gcc/testsuite/
* lib/asan-dg.exp (asan-gtest): Remove actual and expected output
from the pass/fail line and add it to the log instead.
> Index: gcc/testsuite/lib/asan-dg.exp
> ===
> --- gcc/testsuite/lib/asan-dg.exp (revision 205654)
> +++ gcc/testsuite/lib/asan-dg.exp (working copy)
> @@ -288,9 +288,10 @@
> if { "$status" == "fail" } {
> pass "$testname execution test"
> if { ![regexp $regexpr ${output}] } {
> - fail "$testname output pattern test, should match
> $regexpr"
> + fail "$testname output pattern test"
> + send_log "Output was:\n${output}\nShould
> match:\n$regexpr\n"
> } else {
> - pass "$testname output pattern test, $regexpr"
> + pass "$testname output pattern test"
> }
> } elseif { "$status" == "pass" } {
> fail "$testname execution test"
[Patch, Fortran] PRs 59103/58676/41724 - honour pure-/elementalness of intrinsics, add elemental checks
This patch is about rejects-valid and accepts-invalid and does
essentially only:
a) It ensures that sym->attr.pure/elemental gets set for pure/elemental
intrinsics (isym->pure/elemental).
b) It rejects dummy procedures / procedure pointers which are ELEMENTAL.
* * *
To quote (link see PR) from interpretation request F03-0130:
Q: "When one of these procedures [i.e. the specific intrinsic procedures
listed in 13.6 and not marked with a bullet] is associated with a dummy
procedure or procedure pointer, does it still have the elemental property?"
A: "The specific intrinsic procedure itself retains the elemental
property (so a reference using its own name can be elemental), but the
dummy procedure or procedure pointer associated with it is not elemental
and so cannot be used to reference the specific intrinsic procedure
elementally."
And the Fortran standard:
C1218 (R1211) If a proc-interface describes an elemental procedure, each
procedure-entity-name shall specify an external procedure.
"12.5.2.9 Actual arguments associated with dummy procedure entities [...]
If the interface of a dummy procedure is explicit, its characteristics
as a procedure (12.3.1) shall be the same as those of its effective
argument, except that a pure effective argument may be associated with a
dummy argument that is not pure and an elemental intrinsic actual
procedure may be associated with a dummy procedure (which cannot be
elemental)."
* * *
I think the current patch handles it correctly. Last think I was
pondering on is whether "procedure(sin) :: bar" makes "bar" elemental or
not. I think it does, which makes it impossible to use, e.g.
"procedure(sin), pointer :: pp => sin". However, creating an (abstract)
interface which matches "sin" except for the elemental attribute, is
possible and permits: "procedure(sin_interf), pointer :: pp => sin".
I hope that I got everything right in the patch.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-12-04 Tobias Burnus
PR fortran/59103
PR fortran/58676
PR fortran/41724
* resolve.c (gfc_resolve_intrinsic): Set elemental/pure.
(resolve_symbol): Reject pure dummy procedures/procedure
pointers.
(gfc_explicit_interface_required): Don't require a
match of ELEMENTAL for intrinsics.
2013-12-04 Tobias Burnus
PR fortran/59103
PR fortran/58676
PR fortran/41724
* gfortran.dg/elemental_subroutine_8.f90: New.
* gfortran.dg/proc_decl_9.f90: Add ELEMENTAL to make valid.
* gfortran.dg/proc_ptr_11.f90: Ditto.
* gfortran.dg/proc_ptr_result_8.f90: Ditto.
* gfortran.dg/proc_ptr_32.f90: Update dg-error.
* gfortran.dg/proc_ptr_33.f90: Ditto.
* gfortran.dg/proc_ptr_result_1.f90: Add abstract interface
which is not elemental.
* gfortran.dg/proc_ptr_result_7.f90: Ditto.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 5ed7053..58c4d61 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1679,6 +1679,9 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc)
gfc_copy_formal_args_intr (sym, isym);
+ sym->attr.pure = isym->pure;
+ sym->attr.elemental = isym->elemental;
+
/* Check it is actually available in the standard settings. */
if (!gfc_check_intrinsic_standard (isym, &symstd, false, sym->declared_at))
{
@@ -2314,7 +2317,7 @@ gfc_explicit_interface_required (gfc_symbol *sym, char *errmsg, int err_len)
}
}
- if (sym->attr.elemental) /* (4) */
+ if (sym->attr.elemental && !sym->attr.intrinsic) /* (4) */
{
strncpy (errmsg, _("elemental procedure"), err_len);
return true;
@@ -12757,6 +12760,23 @@ resolve_symbol (gfc_symbol *sym)
&& !resolve_procedure_interface (sym))
return;
+ /* F2008, C1218. */
+ if (sym->attr.flavor == FL_PROCEDURE && sym->attr.elemental)
+{
+ if (sym->attr.proc_pointer)
+ {
+ gfc_error ("Procedure pointer '%s' at %L shall not be elemental",
+ sym->name, &sym->declared_at);
+ return;
+ }
+ if (sym->attr.dummy)
+ {
+ gfc_error ("Dummy procedure '%s' at %L shall not be elemental",
+ sym->name, &sym->declared_at);
+ return;
+ }
+}
+
if (sym->attr.is_protected && !sym->attr.proc_pointer
&& (sym->attr.procedure || sym->attr.external))
{
diff --git a/gcc/testsuite/gfortran.dg/proc_decl_9.f90 b/gcc/testsuite/gfortran.dg/proc_decl_9.f90
index 58ae321..455c27c 100644
--- a/gcc/testsuite/gfortran.dg/proc_decl_9.f90
+++ b/gcc/testsuite/gfortran.dg/proc_decl_9.f90
@@ -1,7 +1,7 @@
! { dg-do run }
! PR33162 INTRINSIC functions as ACTUAL argument
! Test case adapted from PR by Jerry DeLisle
-real function t(x)
+elemental real function t(x)
real, intent(in) ::x
t = x
end function
@@ -9,6 +9,6 @@ end function
program p
implicit none
intrinsic sin
- procedure(sin):: t
+ procedure(sin) :: t
if (t(1.0) /= 1.0) call abort
end program
diff --git a/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 b/gcc/testsuite/gfortran.dg/proc_ptr_11.f90
index bee73f4..dd3e09d 100644
Re: [PATCH] Fix PR 59390
On Fri, Dec 6, 2013 at 8:33 PM, Sriraman Tallam wrote:
> Patch updated with two more tests to check if the vfmadd insn is being
> produced when possible.
>
> Thanks
> Sri
>
> On Fri, Dec 6, 2013 at 11:12 AM, Sriraman Tallam wrote:
>> Hi,
>>
>> I have attached a patch to fix
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390. Please review.
>>
>> Here is the problem. GCC adds target-specific builtins on demand. The
>> FMA target-specific builtin __builtin_ia32_vfmaddpd gets added via
>> this declaration:
>>
>> void fun() __attribute__((target("fma")));
>>
>> Specifically, the builtin __builtin_ia32_vfmaddpd gets added when
>> ix86_add_new_builtins is called from ix86_valid_target_attribute_tree
>> when processing this target attribute.
>>
>> Now, when the vectorizer is processing the builtin "__builtin_fma" in
>> function other_fn(), it checks to see if this function is vectorizable
>> and calls ix86_builtin_vectorized_function in i386.c. That returns the
>> builtin stored here:
>>
>>
>> case BUILT_IN_FMA:
>> if (out_mode == DFmode && in_mode == DFmode)
>> {
>> if (out_n == 2 && in_n == 2)
>>return ix86_builtins[IX86_BUILTIN_VFMADDPD];
>>
>>
>> ix86_builtins[IX86_BUILTIN_VFMADDPD] would have contained NULL_TREE
>> had the builtin not been added by the previous target attribute. That
>> is why the code works if we remove the previous declaration.
>>
>> The fix is to not just return the builtin but to also check if the
>> current function's isa allows the use of the builtin. For instance,
>> this patch would solve the problem:
>>
>> @@ -33977,7 +33977,13 @@ ix86_builtin_vectorized_function (tree fndecl, tre
>>if (out_mode == DFmode && in_mode == DFmode)
>> {
>>if (out_n == 2 && in_n == 2)
>> -return ix86_builtins[IX86_BUILTIN_VFMADDPD];
>> +{
>> + if (ix86_builtins_isa[IX86_BUILTIN_VFMADDPD].isa
>> + & global_options.x_ix86_isa_flags)
>> +return ix86_builtins[IX86_BUILTIN_VFMADDPD];
>> + else
>> + return NULL_TREE;
>> +}
>>
>>
>> but there are many instances of this usage in
>> ix86_builtin_vectorized_function. This patch covers all the cases.
> PR target/59390
> * gcc.target/i386/pr59390.c: New test.
> * gcc.target/i386/pr59390_1.c: New test.
> * gcc.target/i386/pr59390_2.c: New test.
> * config/i386/i386.c (get_builtin): New function.
> (ix86_builtin_vectorized_function): Replace all instances of
> ix86_builtins[...] with get_builtin(...).
> (ix86_builtin_reciprocal): Ditto.
OK, with a couple of nits:
+static tree get_builtin (enum ix86_builtins code)
Please name this function ix86_get_builtin.
+ if (current_function_decl)
+target_tree = DECL_FUNCTION_SPECIFIC_TARGET (current_function_decl);
+ if (target_tree)
+opts = TREE_TARGET_OPTION (target_tree);
+ else
+opts = TREE_TARGET_OPTION (target_option_default_node);
+
opts = TREE_TARGET_OPTION (target_tree ? target_tree :
target_option_default_node);
Thanks,
Uros.
Re: Remove regexp and expected output from gtest pass/fail line
On Sun, Dec 08, 2013 at 10:31:56AM +, Richard Sandiford wrote:
> --- gcc/testsuite/lib/asan-dg.exp (revision 205654)
> +++ gcc/testsuite/lib/asan-dg.exp (working copy)
> @@ -288,9 +288,10 @@
> if { "$status" == "fail" } {
> pass "$testname execution test"
> if { ![regexp $regexpr ${output}] } {
> - fail "$testname output pattern test, should match
> $regexpr"
> + fail "$testname output pattern test"
> + send_log "Output was:\n${output}\nShould
> match:\n$regexpr\n"
Are you sure you need to print ${output}? At least looking at current
g++.log or gcc.log file, it looks like the program's output is already
there, so it is IMHO undesriable to print it there once again.
Jakub
Re: [Patch, Fortran] PRs 59103/58676/41724 - honour pure-/elementalness of intrinsics, add elemental checks
Hi Tobias, first off: I assume the first PR number in the subject line is wrong, since I don't see how it is related to your patch. I guess you meant 58099? > This patch is about rejects-valid and accepts-invalid and does essentially > only: > > a) It ensures that sym->attr.pure/elemental gets set for pure/elemental > intrinsics (isym->pure/elemental). this part is ok with me (since it is exactly what I posted in PR 58099 comment 18 ;) > b) It rejects dummy procedures / procedure pointers which are ELEMENTAL. This also looks good (although it should maybe go into resolve_fl_procedure?). > Build and regtested on x86-64-gnu-linux. > OK for the trunk? Ok, thanks for the patch. Cheers, Janus
Re: Remove regexp and expected output from gtest pass/fail line
Jakub Jelinek writes:
> On Sun, Dec 08, 2013 at 10:31:56AM +, Richard Sandiford wrote:
>> --- gcc/testsuite/lib/asan-dg.exp(revision 205654)
>> +++ gcc/testsuite/lib/asan-dg.exp(working copy)
>> @@ -288,9 +288,10 @@
>> if { "$status" == "fail" } {
>> pass "$testname execution test"
>> if { ![regexp $regexpr ${output}] } {
>> -fail "$testname output pattern test, should match
>> $regexpr"
>> +fail "$testname output pattern test"
>> +send_log "Output was:\n${output}\nShould
>> match:\n$regexpr\n"
>
> Are you sure you need to print ${output}? At least looking at current
> g++.log or gcc.log file, it looks like the program's output is already
> there, so it is IMHO undesriable to print it there once again.
OK, how about this version?
Thanks,
Richard
gcc/testsuite/
* lib/asan-dg.exp (asan-gtest): Remove actual and expected output
from the pass/fail line and add it to the log instead.
Index: gcc/testsuite/lib/asan-dg.exp
===
--- gcc/testsuite/lib/asan-dg.exp 2013-12-04 10:47:41.499044571 +
+++ gcc/testsuite/lib/asan-dg.exp 2013-12-08 19:18:01.840876860 +
@@ -288,9 +288,10 @@ proc asan-gtest { args } {
if { "$status" == "fail" } {
pass "$testname execution test"
if { ![regexp $regexpr ${output}] } {
- fail "$testname output pattern test, should match
$regexpr"
+ fail "$testname output pattern test"
+ send_log "Output should match: $regexpr\n"
} else {
- pass "$testname output pattern test, $regexpr"
+ pass "$testname output pattern test"
}
} elseif { "$status" == "pass" } {
fail "$testname execution test"
[wwwdocs] Re: Joseph Myers joins GCC Steering Committee
And here the web page update for Mark's departure and Joseph joining. Applied. Gerald Index: steering.html === RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v retrieving revision 1.36 diff -u -3 -p -r1.36 steering.html --- steering.html 20 Oct 2013 19:44:25 - 1.36 +++ steering.html 8 Dec 2013 21:03:14 - @@ -32,8 +32,8 @@ place to reach them is the gcc
Re: Remove regexp and expected output from gtest pass/fail line
On Sun, Dec 08, 2013 at 07:18:37PM +, Richard Sandiford wrote:
> gcc/testsuite/
> * lib/asan-dg.exp (asan-gtest): Remove actual and expected output
> from the pass/fail line and add it to the log instead.
Looks ok to me, except the ChangeLog, all I'm seeing is that you are
removing expected output from the pass/fail line, not the actual output.
> --- gcc/testsuite/lib/asan-dg.exp 2013-12-04 10:47:41.499044571 +
> +++ gcc/testsuite/lib/asan-dg.exp 2013-12-08 19:18:01.840876860 +
> @@ -288,9 +288,10 @@ proc asan-gtest { args } {
> if { "$status" == "fail" } {
> pass "$testname execution test"
> if { ![regexp $regexpr ${output}] } {
> - fail "$testname output pattern test, should match
> $regexpr"
> + fail "$testname output pattern test"
> + send_log "Output should match: $regexpr\n"
> } else {
> - pass "$testname output pattern test, $regexpr"
> + pass "$testname output pattern test"
> }
> } elseif { "$status" == "pass" } {
> fail "$testname execution test"
Jakub
Re: [Patch, Fortran] PRs 59103/58676/41724 - honour pure-/elementalness of intrinsics, add elemental checks
Hi Janus,
Janus Weil wrote:
first off: I assume the first PR number in the subject line is wrong,
since I don't see how it is related to your patch. I guess you meant
58099?
Yes. Well spotted.
a) It ensures that sym->attr.pure/elemental gets set for pure/elemental
intrinsics (isym->pure/elemental).
this part is ok with me (since it is exactly what I posted in PR 58099
comment 18 ;)
I have now added your name to the ChangeLog.
b) It rejects dummy procedures / procedure pointers which are ELEMENTAL.
This also looks good (although it should maybe go into resolve_fl_procedure?).
I had it elsewhere (I forgot where) and there I'd the problem that I got
multiple times the same error. But at least with the current patch and
looking manually at the output for elemental_subroutine_8.f90 it seems
to work. Thanks for the suggestion.
Tobias
PS: I have now committed the attached patch as Rev. 205791.
2013-12-08 Tobias Burnus
Janus Weil
PR fortran/58099
PR fortran/58676
PR fortran/41724
* resolve.c (gfc_resolve_intrinsic): Set elemental/pure.
(resolve_fl_procedure): Reject pure dummy procedures/procedure
pointers.
(gfc_explicit_interface_required): Don't require a
match of ELEMENTAL for intrinsics.
2013-12-08 Tobias Burnus
PR fortran/58099
PR fortran/58676
PR fortran/41724
* gfortran.dg/elemental_subroutine_8.f90: New.
* gfortran.dg/proc_decl_9.f90: Add ELEMENTAL to make valid.
* gfortran.dg/proc_ptr_11.f90: Ditto.
* gfortran.dg/proc_ptr_result_8.f90: Ditto.
* gfortran.dg/proc_ptr_32.f90: Update dg-error.
* gfortran.dg/proc_ptr_33.f90: Ditto.
* gfortran.dg/proc_ptr_result_1.f90: Add abstract interface
which is not elemental.
* gfortran.dg/proc_ptr_result_7.f90: Ditto.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 5ed7053..ea46324 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1679,6 +1679,9 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc)
gfc_copy_formal_args_intr (sym, isym);
+ sym->attr.pure = isym->pure;
+ sym->attr.elemental = isym->elemental;
+
/* Check it is actually available in the standard settings. */
if (!gfc_check_intrinsic_standard (isym, &symstd, false, sym->declared_at))
{
@@ -2314,7 +2317,7 @@ gfc_explicit_interface_required (gfc_symbol *sym, char *errmsg, int err_len)
}
}
- if (sym->attr.elemental) /* (4) */
+ if (sym->attr.elemental && !sym->attr.intrinsic) /* (4) */
{
strncpy (errmsg, _("elemental procedure"), err_len);
return true;
@@ -11094,6 +11097,23 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
sym->name, &sym->declared_at);
}
+ /* F2008, C1218. */
+ if (sym->attr.elemental)
+{
+ if (sym->attr.proc_pointer)
+ {
+ gfc_error ("Procedure pointer '%s' at %L shall not be elemental",
+ sym->name, &sym->declared_at);
+ return false;
+ }
+ if (sym->attr.dummy)
+ {
+ gfc_error ("Dummy procedure '%s' at %L shall not be elemental",
+ sym->name, &sym->declared_at);
+ return false;
+ }
+}
+
if (sym->attr.is_bind_c && sym->attr.is_c_interop != 1)
{
gfc_formal_arglist *curr_arg;
diff --git a/gcc/testsuite/gfortran.dg/proc_decl_9.f90 b/gcc/testsuite/gfortran.dg/proc_decl_9.f90
index 58ae321..455c27c 100644
--- a/gcc/testsuite/gfortran.dg/proc_decl_9.f90
+++ b/gcc/testsuite/gfortran.dg/proc_decl_9.f90
@@ -1,7 +1,7 @@
! { dg-do run }
! PR33162 INTRINSIC functions as ACTUAL argument
! Test case adapted from PR by Jerry DeLisle
-real function t(x)
+elemental real function t(x)
real, intent(in) ::x
t = x
end function
@@ -9,6 +9,6 @@ end function
program p
implicit none
intrinsic sin
- procedure(sin):: t
+ procedure(sin) :: t
if (t(1.0) /= 1.0) call abort
end program
diff --git a/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 b/gcc/testsuite/gfortran.dg/proc_ptr_11.f90
index bee73f4..61921e7 100644
--- a/gcc/testsuite/gfortran.dg/proc_ptr_11.f90
+++ b/gcc/testsuite/gfortran.dg/proc_ptr_11.f90
@@ -7,16 +7,23 @@
program bsp
implicit none
-
+ intrinsic :: isign, iabs
abstract interface
subroutine up()
end subroutine up
+! As intrinsics but not elemental
+pure integer function isign_interf(a, b)
+ integer, intent(in) :: a, b
+end function isign_interf
+pure integer function iabs_interf(x)
+ integer, intent(in) :: x
+end function iabs_interf
end interface
procedure( up ) , pointer :: pptr
- procedure(isign), pointer :: q
+ procedure(isign_interf), pointer :: q
- procedure(iabs),pointer :: p1
+ procedure(iabs_interf),pointer :: p1
procedure(f), pointer :: p2
pointer :: p3
@@ -48,13 +55,13 @@ program bsp
contains
-function add( a, b )
+pure function add( a, b )
integer :: add
integer, intent( in ) :: a, b
add = a + b
end function add
-integer function f(x)
+pure integer function f(x)
integer,intent(in) :: x
f = 317 + x
[PATCH, testsuite ]: Cleanup dumps
Hello!
2013-12-08 Uros Bizjak
* gcc.dg/macro-fusion-1.c: Cleanup sched2 rtl dump.
* gcc.dg/macro-fusion-2.c: Ditto.
* gcc.dg/vect/vect-simd-clone-10a.c: Cleanup vect tree dump.
* gcc.dg/vect/vect-simd-clone-12a.c: Ditto.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.dg/macro-fusion-1.c
===
--- gcc.dg/macro-fusion-1.c (revision 205790)
+++ gcc.dg/macro-fusion-1.c (working copy)
@@ -1,6 +1,5 @@
/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
/* { dg-options "-O2 -mtune=corei7 -fdump-rtl-sched2" } */
-/* { dg-final { scan-rtl-dump-not "compare.*insn.*jump_insn.*jump_insn"
"sched2" } } */
int a[100];
@@ -11,3 +10,6 @@
sum += (0.5 + (a[i%100] - 128));
return sum;
}
+
+/* { dg-final { scan-rtl-dump-not "compare.*insn.*jump_insn.*jump_insn"
"sched2" } } */
+/* { dg-final { cleanup-rtl-dump "sched2" } } */
Index: gcc.dg/macro-fusion-2.c
===
--- gcc.dg/macro-fusion-2.c (revision 205790)
+++ gcc.dg/macro-fusion-2.c (working copy)
@@ -1,6 +1,5 @@
/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
/* { dg-options "-O2 -mtune=corei7-avx -fdump-rtl-sched2" } */
-/* { dg-final { scan-rtl-dump-not "compare.*insn.*jump_insn.*jump_insn"
"sched2" } } */
int a[100];
@@ -14,3 +13,6 @@
}
return sum;
}
+
+/* { dg-final { scan-rtl-dump-not "compare.*insn.*jump_insn.*jump_insn"
"sched2" } } */
+/* { dg-final { cleanup-rtl-dump "sched2" } } */
Index: gcc.dg/vect/vect-simd-clone-10a.c
===
--- gcc.dg/vect/vect-simd-clone-10a.c (revision 205790)
+++ gcc.dg/vect/vect-simd-clone-10a.c (working copy)
@@ -15,3 +15,5 @@
{
return a + b + c;
}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
Index: gcc.dg/vect/vect-simd-clone-12a.c
===
--- gcc.dg/vect/vect-simd-clone-12a.c (revision 205790)
+++ gcc.dg/vect/vect-simd-clone-12a.c (working copy)
@@ -15,3 +15,5 @@
{
return a + b + c;
}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
fixinclude patch for fenv.h on Ubuntu
Adjusted for Richard Biener's patch
Index: fixincludes/ChangeLog
===
--- fixincludes/ChangeLog (revision 205790)
+++ fixincludes/ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2013-12-07 Bruce Korb
+
+ * inclhack.def: many of the headers found under "bits/" are
+ often stashed under architecture directories. Apply fixes
+ to those, too. Also, re-ordered misordered fixes.
+ * tests/base/linux/vt.h: 80 columns in .def file limitation
+ * tests/base/iso/math_c99.h: adjust ordering
+ * tests/base/rtldef/string.h: likewise
+ * tests/base/bits/fenv.h: likewise
+ * tests/base/pthread.h: likewise
+
2013-12-06 Richard Biener
* inclhack.def (suse_linux_vt_cxx): New fix for linux/vt.h
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x (revision 205790)
[[generated]]
Index: fixincludes/tests/base/iso/math_c99.h
===
--- fixincludes/tests/base/iso/math_c99.h (revision 205790)
+++ fixincludes/tests/base/iso/math_c99.h (working copy)
@@ -20,6 +20,13 @@
#endif /* SOLARIS_MATH_1_CHECK */
+#if defined( SOLARIS_MATH_10_CHECK )
+#pragma ident "@(#)math_c99.h 1.12 07/01/21 SMI"
+#undef isinf
+#define isinf(x) __builtin_isinf(x)
+#endif /* SOLARIS_MATH_10_CHECK */
+
+
#if defined( SOLARIS_MATH_2_CHECK )
#ident "@(#)math_c99.h 1.9 04/11/01 SMI"
#undef INFINITY
@@ -68,10 +75,3 @@
#undef isunordered
#define isunordered(x, y) __builtin_isunordered(x, y)
#endif /* SOLARIS_MATH_9_CHECK */
-
-
-#if defined( SOLARIS_MATH_10_CHECK )
-#pragma ident "@(#)math_c99.h 1.12 07/01/21 SMI"
-#undef isinf
-#define isinf(x) __builtin_isinf(x)
-#endif /* SOLARIS_MATH_10_CHECK */
Index: fixincludes/tests/base/bits/fenv.h
===
--- fixincludes/tests/base/bits/fenv.h (revision 205790)
+++ fixincludes/tests/base/bits/fenv.h (working copy)
@@ -9,6 +9,16 @@
+#if defined( FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK )
+# ifdef __SSE_MATH__
+ __asm__ __volatile__ ("divss %1, %0" : : "x" (__f), "x" (__g));
+# else
+ __asm__ __volatile__ ("fdivp %%st, %%st(1); fwait"
+ : "=t" (__f) : "0" (__f), "u" (__g) : "st(1)");
+# endif
+#endif /* FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK */
+
+
#if defined( FERAISEEXCEPT_NOSSE_INVALID_CHECK )
# ifdef __SSE_MATH__
__asm__ __volatile__ ("divss %0, %0" : : "x" (__f));
@@ -17,13 +27,3 @@
: "=t" (__f) : "0" (__f));
# endif
#endif /* FERAISEEXCEPT_NOSSE_INVALID_CHECK */
-
-
-#if defined( FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK )
-# ifdef __SSE_MATH__
- __asm__ __volatile__ ("divss %1, %0" : : "x" (__f), "x" (__g));
-# else
- __asm__ __volatile__ ("fdivp %%st, %%st(1); fwait"
- : "=t" (__f) : "0" (__f), "u" (__g) : "st(1)");
-# endif
-#endif /* FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK */
Index: fixincludes/tests/base/rtldef/string.h
===
--- fixincludes/tests/base/rtldef/string.h (revision 205790)
+++ fixincludes/tests/base/rtldef/string.h (working copy)
@@ -9,13 +9,13 @@
+#if defined( VMS_DECC_BUILTIN_CHECK )
+define FD_ZERO(__p) memset((__p), 0, sizeof(*(__p)))
+
+#endif /* VMS_DECC_BUILTIN_CHECK */
+
+
#if defined( VMS_DISABLE_DECC_STRING_BUILTINS_CHECK )
#if !defined(__VAX) && !defined(__GNUC__)
#endif /* VMS_DISABLE_DECC_STRING_BUILTINS_CHECK */
-
-
-#if defined( VMS_DECC_BUILTIN_CHECK )
-define FD_ZERO(__p) memset((__p), 0, sizeof(*(__p)))
-
-#endif /* VMS_DECC_BUILTIN_CHECK */
Index: fixincludes/tests/base/linux/vt.h
===
--- fixincludes/tests/base/linux/vt.h (revision 205790)
+++ fixincludes/tests/base/linux/vt.h (working copy)
@@ -10,5 +10,5 @@
#if defined( SUSE_LINUX_VT_CXX_CHECK )
-unsigned int newev; /* New console (if changing) */
+unsigned int newev; /* New console (if changing) */
#endif /* SUSE_LINUX_VT_CXX_CHECK */
Index: fixincludes/tests/base/pthread.h
===
--- fixincludes/tests/base/pthread.h (revision 205790)
+++ fixincludes/tests/base/pthread.h (working copy)
@@ -125,16 +125,6 @@
#endif /* SOLARIS_MUTEX_INIT_2_CHECK */
-#if defined( SOLARIS_RWLOCK_INIT_1_CHECK )
-#ident "@(#)pthread.h 1.26 98/04/12 SMI"
-#if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
-#define PTHREAD_RWLOCK_INITIALIZER {0, 0, 0, {0, 0, 0}, {0, 0}, {0, 0}}
-#else
-#define PTHREAD_RWLOCK_INITIALIZER {0, 0, 0, {{0}, {0}, {0}}, {{0}, {0}}, {{0}, {0}}}
-#endif
-#endif /* SOLARIS_RWLOCK_INIT_1_CHECK */
-
-
#if defined( SOLARIS_ONCE_INIT_1_CHECK )
#pragma ident "@(#)pthread.h 1.37 04/09/28 SMI"
#if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
@@ -156,6 +146,16 @@
#endif /* SOLARIS_ONCE_INIT_2_CHECK */
+#if defined( SOLARIS_RWLOCK_INIT_1_CHECK )
+#ident "@(#)pthread.h 1.26 98/04/12 SMI"
+#if __STDC__ - 0 == 0
Re: configure check for flex
On 12/08/13 13:06, Gerald Pfeifer wrote: Lovely. Thank you very much! $ svn diff Index: configure.ac === --- configure.ac(revision 205790) +++ configure.ac(working copy) @@ -1319,10 +1319,17 @@ # Used for setting $lt_cv_objdir _LT_CHECK_OBJDIR -# Check for GMP, MPFR and MPC +# Check for flex, GMP, MPFR and MPC +[for p in flex +do + c=`command -v $p` + test -x "$c" || \ +]AC_MSG_ERROR([the $p command is required to build GCC])[ +done + gmplibs="-lmpc -lmpfr -lgmp" gmpinc= -have_gmp=no +have_gmp=no] # Specify a location for mpc # check for this first so it ends up on the link line before mpfr.
Re: 3 libstdc++ tests fail at random
On 7 December 2013 17:28, H.J. Lu wrote:
> On Sat, Dec 7, 2013 at 9:26 AM, H.J. Lu wrote:
>> On Sat, Dec 7, 2013 at 9:09 AM, Jakub Jelinek wrote:
>FAIL: 30_threads/async/async.cc execution test
>>>
>>> async.exe:
>>> /usr/src/gcc/libstdc++-v3/testsuite/30_threads/async/async.cc:66: void
>>> test02(): Assertion `status == std::future_status::ready' failed.
>>>
>>> This one fails pretty frequently for me, 6 times out of last 12 i686-linux
>>
>> Same here.
>>
>>> bootstraps/regtests, starting with ~ Nov 21th bootstrap (but before that
>>
>> It started for me around revision 205144.
>>
>
> http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg00869.html
>
> changed 30_threads/async/async.cc.
My recent change to that test introduced a race, the main thread could
wake up and check for readiness before the shared state had been made
ready. Fixed by this patch.
Tested x86_64-linux and i686-linux, committed to trunk.
2013-12-08 Jonathan Wakely
* testsuite/30_threads/async/async.cc: Fix race condition in test.
commit 2141b30307e7802625e72eba3037c0528fcaa76d
Author: Jonathan Wakely
Date: Sun Dec 8 21:35:22 2013 +
* testsuite/30_threads/async/async.cc: Fix race condition in test.
diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc
b/libstdc++-v3/testsuite/30_threads/async/async.cc
index 1f94494..05fd23c 100644
--- a/libstdc++-v3/testsuite/30_threads/async/async.cc
+++ b/libstdc++-v3/testsuite/30_threads/async/async.cc
@@ -29,23 +29,18 @@
using namespace std;
-struct work {
- typedef void result_type;
- void operator()(mutex& m, condition_variable& cv)
- {
-unique_lock l(m);
-cv.notify_one();
- }
-};
+void work(mutex& m)
+{
+ unique_lock l(m);
+}
void test01()
{
mutex m;
- condition_variable cv;
unique_lock l(m);
- future f1 = async(launch::async, work(), ref(m), ref(cv));
- cv.wait(l);
- f1.get();
+ future f1 = async(launch::async, &work, ref(m));
+ l.unlock(); // allow async thread to proceed
+ f1.get();// wait for it to finish
}
void test02()
@@ -53,15 +48,15 @@ void test02()
bool test __attribute__((unused)) = true;
mutex m;
- condition_variable cv;
unique_lock l(m);
- future f1 = async(launch::async, work(), ref(m), ref(cv));
+ future f1 = async(launch::async, &work, ref(m));
std::future_status status;
status = f1.wait_for(std::chrono::milliseconds(1));
VERIFY( status == std::future_status::timeout );
status = f1.wait_until(std::chrono::system_clock::now());
VERIFY( status == std::future_status::timeout );
- cv.wait(l);
+ l.unlock(); // allow async thread to proceed
+ f1.wait(); // wait for it to finish
status = f1.wait_for(std::chrono::milliseconds(0));
VERIFY( status == std::future_status::ready );
status = f1.wait_until(std::chrono::system_clock::now());
[SH, committed] Deprecate mcbranchdi and mcmpeqdi options.
Hello,
The attached patch deprecates the SH options mcbranchdi and mcmpeqdi,
since they turn out to be not so useful.
For example, disabling the cbranchdi pattern results in worse code for
-Os than -O1 and enabling the cmpeqdi patterns seems to trigger
broken/incomplete code paths. Effectively this is a fix for PR 51697.
Tested with
make info dvi pdf
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
Committed as revision 205794.
Cheers,
Oleg
gcc/ChangeLog:
PR target/52898
PR target/51697
* common/config/sh/sh-common.c (sh_option_optimization_table): Remove
OPT_mcbranchdi entry.
* config/sh/sh.opt (mcbranchdi, mcmpeqdi): Mark as undocumented and
emit a warning.
* config/sh/sh.c (sh_option_override): Initialize TARGET_CBRANCHDI4
and TARGET_CMPEQDI_T variables.
* doc/invoke.texi (SH options): Undocument -mcbranchdi and -mcmpeqdi.
testsuite/ChangeLog:
PR target/52898
PR target/51697
* gcc.target/sh/pr51697.c: New.
Index: gcc/common/config/sh/sh-common.c
===
--- gcc/common/config/sh/sh-common.c (revision 205784)
+++ gcc/common/config/sh/sh-common.c (working copy)
@@ -34,7 +34,6 @@
{ OPT_LEVELS_1_PLUS_SPEED_ONLY, OPT_mdiv_, "inv:minlat", 1 },
{ OPT_LEVELS_SIZE, OPT_mdiv_, SH_DIV_STR_FOR_SIZE, 1 },
{ OPT_LEVELS_0_ONLY, OPT_mdiv_, "", 1 },
-{ OPT_LEVELS_SIZE, OPT_mcbranchdi, NULL, 0 },
/* We can't meaningfully test TARGET_SHMEDIA here, because -m
options haven't been parsed yet, hence we'd read only the
default. sh_target_reg_class will return NO_REGS if this is
Index: gcc/config/sh/sh.opt
===
--- gcc/config/sh/sh.opt (revision 205784)
+++ gcc/config/sh/sh.opt (working copy)
@@ -233,11 +233,11 @@
Assume that zero displacement conditional branches are fast
mcbranchdi
-Target Var(TARGET_CBRANCHDI4)
+Target Undocumented Var(TARGET_CBRANCHDI4) Warn(%qs is deprecated and has no effect)
Enable cbranchdi4 pattern
mcmpeqdi
-Target Var(TARGET_CMPEQDI_T)
+Target Undocumented Var(TARGET_CMPEQDI_T) Warn(%qs is deprecated and has no effect)
Emit cmpeqdi_t pattern even when -mcbranchdi is in effect.
mcut2-workaround
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 205784)
+++ gcc/config/sh/sh.c (working copy)
@@ -771,6 +771,11 @@
SUBTARGET_OVERRIDE_OPTIONS;
if (optimize > 1 && !optimize_size)
target_flags |= MASK_SAVE_ALL_TARGET_REGS;
+
+ /* Set default values of TARGET_CBRANCHDI4 and TARGET_CMPEQDI_T. */
+ TARGET_CBRANCHDI4 = 1;
+ TARGET_CMPEQDI_T = 0;
+
sh_cpu = PROCESSOR_SH1;
assembler_dialect = 0;
if (TARGET_SH2)
Index: gcc/testsuite/gcc.target/sh/pr51697.c
===
--- gcc/testsuite/gcc.target/sh/pr51697.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51697.c (revision 0)
@@ -0,0 +1,21 @@
+/* Check that DImode comparisons are optimized as expected when compiling
+ with -Os. */
+/* { dg-do compile } */
+/* { dg-options "-Os" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m5*"} { "" } } */
+/* { dg-final { scan-assembler-times "tst" 2 } } */
+/* { dg-final { scan-assembler-not "cmp" } } */
+
+int
+test_00 (long long* x)
+{
+ /* 1x tst, no cmp/* insns. */
+ return *x & 0x ? -20 : -40;
+}
+
+int
+test_01 (unsigned long long x)
+{
+ /* 1x tst, no cmp/* insns. */
+ return x >= 0x1LL ? -20 : -40;
+}
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 205784)
+++ gcc/doc/invoke.texi (working copy)
@@ -959,7 +959,7 @@
-mindexed-addressing -mgettrcost=@var{number} -mpt-fixed @gol
-maccumulate-outgoing-args -minvalid-symbols @gol
-matomic-model=@var{atomic-model} @gol
--mbranch-cost=@var{num} -mzdcbranch -mno-zdcbranch -mcbranchdi -mcmpeqdi @gol
+-mbranch-cost=@var{num} -mzdcbranch -mno-zdcbranch @gol
-mfused-madd -mno-fused-madd -mfsca -mno-fsca -mfsrra -mno-fsrra @gol
-mpretend-cmove -mtas}
@@ -20252,15 +20252,6 @@
enabled by default when generating code for SH4 and SH4A. It can be explicitly
disabled by specifying @option{-mno-zdcbranch}.
-@item -mcbranchdi
-@opindex mcbranchdi
-Enable the @code{cbranchdi4} instruction pattern.
-
-@item -mcmpeqdi
-@opindex mcmpeqdi
-Emit the @code{cmpeqdi_t} instruction pattern even when @option{-mcbranchdi}
-is in effect.
-
@item -mfused-madd
@itemx -mno-fused-madd
@opindex mfused-madd
[wwwdocs] SH 4.9 changes update
Hello, This is a summary of what has been happening on the SH side during 4.9. Applied. Cheers, Oleg ? sh_changes_49_1.patch Index: htdocs/gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.46 diff -u -r1.46 changes.html --- htdocs/gcc-4.9/changes.html 6 Dec 2013 18:27:14 - 1.46 +++ htdocs/gcc-4.9/changes.html 8 Dec 2013 22:29:41 - @@ -438,6 +438,29 @@ +SH + +Minor improvements to code generated for integer arithmetic and code +that involves the T bit. + +Added support for the SH2A clips and clipu +instructions. The compiler will now try to utilize them for min/max +expressions such as max (-128, min (127, x)). + +Added support for the cmp/str instruction through built-in +functions such as __builtin_strlen. When not optimizing for +size, the compiler will now expand calls to e.g. strlen as an +inlined sequences which utilize the cmp/str instruction. + +Improved code generated around volatile memory loads and stores. + +The option -mcbranchdi has been deprecated. Specifying it +will result in a warning and will not influence code generation. + +The option -mcmpeqdi has been deprecated. Specifying it +will result in a warning and will not influence code generation. + +
Re: [PATCH PR41488]Recognize more induction variables by simplifying PEELED chrec in scalar evolution
On 12/06/13 19:44, Bin.Cheng wrote: Right. Based on reading the archives, it looks like this stuff is/was generated by PRE. I also suspect jump threading can create them. There was talk of throttling PRE to leave things in a form that the IV analysis could more easily digest, but I'm not sure if that was ever completed. Also could just because it is coded in that way, just as the case I added in patch. I found real examples from ggc-page.c in GCC. But it's always good to cleanup input of an optimization, I presume that's why Richard tried to move IVOPT later before. Certainly. That possibility was mentioned as well in either 41488 or elsewhere in my research. I assume tree_to_aff_combination_expand is relatively expensive, thus the two approaches, one which avoids tree_to_aff_combination_expand. Considering the dump of case in the patch: [ snip ] So it's also a case using the affine stuff gets you get a simpler interface to express the value in terms you may be able match. Another question, is it acceptable to add an parameter for tree_to_aff_combination_expand to limit the number of recursive call for it? Thus we don't need to expand to leaf node every time. If there's a compelling reason to limit the recursion, then I'd think such a parameter would be reasonable. In add_old_iv_candidates, is it the case that the only time SSA_NAME_DEF_STMT (def) is another PHI node is when it's one of these affine I suppose. Actually IVOPT make an assert on IP_ORIGINAL candidates in function rewrite_use_nonlinear_expr, like: Well, the reason I ask is after your patch we'd be ignoring anything where SSA_NAME_DEF_STMT (def) is a PHI node and not a PEELED_CHREC. I want to make sure there aren't other expected cases where SSA_NAME_DEF_STMT (def) is a PHI that we'd want to call add_candidate_1 for. It sounds like there aren't other cases you'd expect to see here where SSA_NAME_DEF_STMT (defFFF) is a PHI. IVOPT adds original cand and tries to keep it the original IV is because it does have an updating statement. For IVs picked up by this patch, it doesn't have stepping statement, so no need/way to leaving it untouched. It will be represented by candidates for IVs from which it is peeled. Understood. Thanks for clarifying. The patch is fine for the trunk. jeff
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
On 12/07/13 03:44, Eric Botcazou wrote: I'd certainly be concerned. Ports have (for better or worse) keyed on BLKmode rather than looking at the underlying types. So if something which was previously SImode or DImode is now BLKmode, there's a nonzero chance we're going to change how it gets passed. Well, we have been saying that calling conventions need to be keyed on types rather than modes for more than a decade... I recall auditing and fixing the SPARC back-end circa 2003, so how long are we going to use this argument? I don't recall such a change in policy -- but that doesn't mean it didn't happen :-) If we already declared that ports should be looking at the underlying types rather than the mode and it's been in place that long, then I think any port that hasn't been audited/updated deserves its fate and we shouldn't let them stand in the way of making progress on this issue. jeff
Re: Two build != host fixes
On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote: > Alan Modra writes: > > Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch? > > > > * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for > > build != host. > > : Clear GMPINC. Don't bother > > saving CFLAGS. > > * configure: Regenerate. > > Ok for mainline, up to the 4.8 release manager if it's OK there but it > looks OK to me. http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00304.html Ping for 4.8? -- Alan Modra Australia Development Lab, IBM
Re: [PATCH PR41488]Recognize more induction variables by simplifying PEELED chrec in scalar evolution
On Mon, Dec 9, 2013 at 12:00 PM, Jeff Law wrote: > On 12/06/13 19:44, Bin.Cheng wrote: >>> >>> Right. Based on reading the archives, it looks like this stuff is/was >>> generated by PRE. I also suspect jump threading can create them. There >>> was >>> talk of throttling PRE to leave things in a form that the IV analysis >>> could >>> more easily digest, but I'm not sure if that was ever completed. >> >> >> Also could just because it is coded in that way, just as the case I >> added in patch. I found real examples from ggc-page.c in GCC. >> But it's always good to cleanup input of an optimization, I presume >> that's why Richard tried to move IVOPT later before. > > Certainly. That possibility was mentioned as well in either 41488 or > elsewhere in my research. > > >>> >>> I assume tree_to_aff_combination_expand is relatively expensive, thus the >>> two approaches, one which avoids tree_to_aff_combination_expand. >> >> Considering the dump of case in the patch: > > [ snip ] > So it's also a case using the affine stuff gets you get a simpler interface > to express the value in terms you may be able match. Yeah. > > >> >> Another question, is it acceptable to add an parameter for >> tree_to_aff_combination_expand to limit the number of recursive call >> for it? Thus we don't need to expand to leaf node every time. > > If there's a compelling reason to limit the recursion, then I'd think such a > parameter would be reasonable. Not for now. Just come up this idea given that some recent patches also use the interface to get back trace information and it's expensive. Maybe Richard have some comment here too. > > > >> >>> >>> >>> In add_old_iv_candidates, is it the case that the only time >>> SSA_NAME_DEF_STMT (def) is another PHI node is when it's one of these >>> affine >> >> >> I suppose. Actually IVOPT make an assert on IP_ORIGINAL candidates in >> function rewrite_use_nonlinear_expr, like: > > Well, the reason I ask is after your patch we'd be ignoring anything where > SSA_NAME_DEF_STMT (def) is a PHI node and not a PEELED_CHREC. I want to > make sure there aren't other expected cases where SSA_NAME_DEF_STMT (def) is > a PHI that we'd want to call add_candidate_1 for. > > It sounds like there aren't other cases you'd expect to see here where > SSA_NAME_DEF_STMT (defFFF) is a PHI. Yes. > > >> IVOPT adds original cand and tries to keep it the original IV is >> because it does have an updating statement. For IVs picked up by this >> patch, it doesn't have stepping statement, so no need/way to leaving >> it untouched. It will be represented by candidates for IVs from which >> it is peeled. > > Understood. Thanks for clarifying. The patch is fine for the trunk. Thanks very much for reviewing. Since Sebastian hasn't added any comments, I will change the patch as suggested by Richard before, then retest it, and check in the new version if it's ok. Thanks, bin > > jeff -- Best Regards.
Re: [Patch, RTL] Eliminate redundant vec_select moves.
Hello, On 05 Dec 16:40, Kirill Yukhin wrote: > On 05 Dec 05:30, H.J. Lu wrote: > > Kirill, can you take a look why it doesn't work for x86? > Okay, I'll look at this. I've looked at this. It seems that `CANNOT_CHANGE_MODE_CLASS' is too conservative for x86. In rtlanal.c we have `simplify_subreg_regno' which call target hook `REG_CANNOT_CHANGE_MODE_P'. It takes only 3 arguments: from mode, to mode and regclass. Hook in x86 called `ix86_cannot_change_mode_class' and comment says that we cannot change mode for nonzero offsets, which sounds quite reasonable. That is why this hook returns `true' for this tuple and `simplify_subreg_regno' prohibits simplification of that: (set (reg:SF 21 xmm0 [orig:86 D.1816 ] [86]) (vec_select:SF (reg:V4SF 21 xmm0 [87]) (parallel [(const_int 0 [0])]))) I think we can extend the hook and add `offset in frommode' to it. We may set it to -1 for the cases where it is unknown and work conservatively in the target hook. For most cases offset is known and we could pass it to the hook. This will require changes throughout all targets though. Alternatively, we may introduce another target hook, say `CANNOT_CHANGE_MODE_CLASS_OFFSET' with same args as `CANNOT_CHANGE_MODE_CLASS' + offset and which will be defaulted to it. For x86 (and possibly other targets) we'll implement this hook, which will checko ffset. What do you think? -- Thanks, K
Re: Two build != host fixes
On Mon, Dec 09, 2013 at 03:04:44PM +1030, Alan Modra wrote: > On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote: > > Alan Modra writes: > > > Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch? > > > > > > * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for > > > build != host. > > > : Clear GMPINC. Don't bother > > > saving CFLAGS. > > > * configure: Regenerate. > > > > Ok for mainline, up to the 4.8 release manager if it's OK there but it > > looks OK to me. > > http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00304.html > Ping for 4.8? Okay. Jakub
