Re: [PATCH] Fix PR60505
On Thu, 13 Mar 2014, Cong Hou wrote:
> On Thu, Mar 13, 2014 at 2:27 AM, Richard Biener wrote:
> > On Wed, 12 Mar 2014, Cong Hou wrote:
> >
> >> Thank you for pointing it out. I didn't realized that alias analysis
> >> has influences on this issue.
> >>
> >> The current problem is that the epilogue may be unnecessary if the
> >> loop bound cannot be larger than the number of iterations of the
> >> vectorized loop multiplied by VF when the vectorized loop is supposed
> >> to be executed. My method is incorrect because I assume the vectorized
> >> loop will be executed which is actually guaranteed by loop bound check
> >> (and also alias checks). So if the alias checks exist, my method is
> >> fine as both conditions are met.
> >
> > But there is still the loop bound check which, if it fails, uses
> > the epilogue loop as fallback, not the scalar versioned loop.
>
> The loop bound check is already performed together with alias checks
> (assume we need alias checks). Actually, I did observe that the loop
> bound check in the true body of alias checks may be unnecessary. For
> example, for the following loop
>
> for(i=0; i < num ; ++i)
> out[i] = (ovec[i] = in[i]);
>
> GCC now generates the following GIMPLE code after vectorization:
>
>
>
> : // loop bound check (with cost model) and alias checks
> _29 = (unsigned int) num_5(D);
> _28 = _29 > 15;
> _24 = in_9(D) + 16;
> _23 = out_7(D) >= _24;
> _2 = out_7(D) + 16;
> _1 = _2 <= in_9(D);
> _32 = _1 | _23;
> _31 = _28 & _32;
> if (_31 != 0)
> goto ;
> else
> goto ;
>
> :
> niters.3_44 = (unsigned int) num_5(D);
> _46 = niters.3_44 + 4294967280;
> _47 = _46 >> 4;
> bnd.4_45 = _47 + 1;
> ratio_mult_vf.5_48 = bnd.4_45 << 4;
> _59 = (unsigned int) num_5(D);
> _60 = _59 + 4294967295;
> if (_60 <= 14) < is this necessary?
> goto ;
> else
> goto ;
>
>
> The check _60<=14 should be unnecessary because it is implied by the
> fact _29 > 15 in bb3.
I agree that the code the vectorizer generates is less than optimal
in some cases (I filed a PR about this some time ago and fixed some
cases).
> Consider this fact and if there are alias checks, we can safely remove
> the epilogue if the maximum trip count of the loop is less than or
> equal to the calculated threshold.
You have to consider n % vf != 0, so an argument on only maximum
trip count or threshold cannot work.
Richard.
>
> Cong
>
>
>
> >
> >> If there is no alias checks, I must
> >> consider the possibility that the vectorized loop may not be executed
> >> at runtime and then the epilogue should not be eliminated. The warning
> >> appears on epilogue, and with loop bound checks (and without alias
> >> checks) the warning will be gone. So I think the key is alias checks:
> >> my method only works if there is no alias checks.
> >>
> >> How about adding one more condition that checks if alias checks are
> >> needed, as the code shown below?
> >>
> >> else if (LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo)
> >> || (tree_ctz (LOOP_VINFO_NITERS (loop_vinfo))
> >> < (unsigned)exact_log2 (LOOP_VINFO_VECT_FACTOR (loop_vinfo))
> >> && (!LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo)
> >>|| (unsigned HOST_WIDE_INT)max_stmt_executions_int
> >>(LOOP_VINFO_LOOP (loop_vinfo)) > (unsigned)th)))
> >> LOOP_VINFO_PEELING_FOR_NITER (loop_vinfo) = true;
> >>
> >>
> >> thanks,
> >> Cong
> >>
> >>
> >> On Wed, Mar 12, 2014 at 1:24 AM, Jakub Jelinek wrote:
> >> > On Tue, Mar 11, 2014 at 04:16:13PM -0700, Cong Hou wrote:
> >> >> This patch is fixing PR60505 in which the vectorizer may produce
> >> >> unnecessary epilogues.
> >> >>
> >> >> Bootstrapped and tested on a x86_64 machine.
> >> >>
> >> >> OK for trunk?
> >> >
> >> > That looks wrong. Consider the case where the loop isn't versioned,
> >> > if you disable generation of the epilogue loop, you end up only with
> >> > a vector loop.
> >> >
> >> > Say:
> >> > unsigned char ovec[16] __attribute__((aligned (16))) = { 0 };
> >> > void
> >> > foo (char *__restrict in, char *__restrict out, int num)
> >> > {
> >> > int i;
> >> >
> >> > in = __builtin_assume_aligned (in, 16);
> >> > out = __builtin_assume_aligned (out, 16);
> >> > for (i = 0; i < num; ++i)
> >> > out[i] = (ovec[i] = in[i]);
> >> > out[num] = ovec[num / 2];
> >> > }
> >> > -O2 -ftree-vectorize. Now, consider if this function is called
> >> > with num != 16 (num > 16 is of course invalid, but num 0 to 15 is
> >> > valid and your patch will cause a wrong-code in this case).
> >> >
> >> > Jakub
> >>
> >>
> >
> > --
> > Richard Biener
> > SUSE / SUSE Labs
> > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
> > GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH] Fix PR60505
On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote: > > Consider this fact and if there are alias checks, we can safely remove > > the epilogue if the maximum trip count of the loop is less than or > > equal to the calculated threshold. > > You have to consider n % vf != 0, so an argument on only maximum > trip count or threshold cannot work. Well, if you only check if maximum trip count is <= vf and you know that for n < vf the vectorized loop + it's epilogue path will not be taken, then perhaps you could, but it is a very special case. Now, the question is when we are guaranteed we enter the scalar versioned loop instead for n < vf, is that in case of versioning for alias or versioning for alignment? Jakub
Re: [PATCH] Fix PR60505
On Fri, 14 Mar 2014, Jakub Jelinek wrote: > On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote: > > > Consider this fact and if there are alias checks, we can safely remove > > > the epilogue if the maximum trip count of the loop is less than or > > > equal to the calculated threshold. > > > > You have to consider n % vf != 0, so an argument on only maximum > > trip count or threshold cannot work. > > Well, if you only check if maximum trip count is <= vf and you know > that for n < vf the vectorized loop + it's epilogue path will not be taken, > then perhaps you could, but it is a very special case. > Now, the question is when we are guaranteed we enter the scalar versioned > loop instead for n < vf, is that in case of versioning for alias or > versioning for alignment? I think neither - I have plans to do the cost model check together with the versioning condition but didn't get around to implement that. That would allow stronger max bounds for the epilogue loop. Richard.
[PATCH] Fix PR60518, split_block not updating loops properly
The following fixes PR60518 where split_block does not fixup
all loops that the block was a latch of (without simple latches
a latch need not belong to its loop but can be an exit block
of a nested loop).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-03-14 Richard Biener
PR middle-end/60518
* cfghooks.c (split_block): Properly adjust all loops the
block was a latch of.
* g++.dg/pr60518.C: New testcase.
Index: gcc/cfghooks.c
===
*** gcc/cfghooks.c (revision 208536)
--- gcc/cfghooks.c (working copy)
*** split_block (basic_block bb, void *i)
*** 510,518
if (current_loops != NULL)
{
add_bb_to_loop (new_bb, bb->loop_father);
! if (bb->loop_father->latch == bb)
! bb->loop_father->latch = new_bb;
}
res = make_single_succ_edge (bb, new_bb, EDGE_FALLTHRU);
--- 510,522
if (current_loops != NULL)
{
+ edge_iterator ei;
+ edge e;
add_bb_to_loop (new_bb, bb->loop_father);
! /* Identify all loops bb may have been the latch of and adjust them. */
! FOR_EACH_EDGE (e, ei, new_bb->succs)
! if (e->dest->loop_father->latch == bb)
! e->dest->loop_father->latch = new_bb;
}
res = make_single_succ_edge (bb, new_bb, EDGE_FALLTHRU);
Index: gcc/testsuite/g++.dg/pr60518.C
===
*** gcc/testsuite/g++.dg/pr60518.C (revision 0)
--- gcc/testsuite/g++.dg/pr60518.C (working copy)
***
*** 0
--- 1,13
+ // { dg-do compile }
+ // { dg-options "-Os -fprofile-use" }
+
+ int a;
+ int fn1 () { return a == ',' || a == ';'; }
+
+ void fn2 ()
+ {
+ do
+ while (fn1 ())
+ ;
+ while (1);
+ }
Re: [patch] make -flto -save-temps less verbose
On Thu, 13 Mar 2014, Cesar Philippidis wrote:
> On 3/13/14, 2:52 AM, Richard Biener wrote:
> > On Thu, Mar 13, 2014 at 10:31 AM, Richard Biener
> > wrote:
> >> On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis
> >> wrote:
> >>> I noticed that the lto-wrapper is a little noisy without the -v option
> >>> when -save-temps is used. E.g.,
> >>>
> >>> $ gcc main.c -flto -save-temps
> >>> [Leaving LTRANS /tmp/ccSEvaB7.args]
> >>> [Leaving LTRANS /tmp/ccQomDzb.ltrans.out]
> >>> [Leaving LTRANS /tmp/ccVzWdGZ.args]
> >>> [Leaving LTRANS /tmp/ccQomDzb.ltrans0.o]
> >>>
> >>> Those messages probably should be suppressed unless the user wants
> >>> verbose diagnostics. They also show up as errors in the testsuite
> >>> (although none currently use -save-temps with -flto, yet). The attached
> >>> patch addresses this issue by disabling those messages unless the user
> >>> passes -v to the driver. I've also included a simple test case which
> >>> would fail without the change.
> >>>
> >>> Is this OK for stage-4? If so, please check it in since I don't have an
> >>> SVN account.
> >>
> >> Ok (I'll check it in).
> >
> > I have not committed the testcase as it leaves the saved-temps files
> > behind and
> >
> > /* { dg-final { cleanup-saved-temps } } */
> >
> > doesn't work. May I ask you to see why and eventually fix it?
> > Supposedly some weird TCL "upvar" stuff ... I get (after my lto.exp fix)
> >
> > Running /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/lto/lto.exp ...
> > ERROR:
> > /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/lto/save-temps_0.c:
> > error executing dg-final: bad level "5"
> >
> > not sure how to set verboseness or debug that stuff (and no time to
> > do that right now).
>
> That error was caused by cleanup-saved-temps because it wants to use
> testname_with_flags to get the names of the files to remove. Usually
> dg-test would set testname_with_flags, but since the LTO tests usually
> links multiple object files, lto.exp handles the building and execution
> of the testcases directly and that variable doesn't get set.
>
> My fix to have lto-execute cleanup the files generated by -save-temps
> instead of calling cleanup-saved-temps in the testcase. That's necessary
> because the name of the final LTO executable is different from name of
> the testcase file. I've also extended cleanup-saved-temps to make it
> aware of the LTO temporaries. Calling cleanup-saved-temps from dg-final
> will still work if the test uses dg-test to run, just not for the tests
> in gcc.dg/lto/.
>
> Is this OK?
Yes, that works for me. I have committed it.
Thanks,
Richard.
Re: [PATCH] BZ60501: Add addptr optab
> This would suggest that you can use the pattern also for performing a normal > add in case the condition code is not needed afterwards but this isn't > correct for s390 31 bit where an address calculation is actually something > different. Then you should document that by stating that the pattern is guaranteed to be invoked only for addresses (and may not clobber the condition code). > addptr is better I think because it is a pattern which is > supposed to be implemented with a load address instruction and the > middle-end guarantees to use it only on addresses. (I hope LRA is actually > behaving that way). Hoping isn't sufficient IMO here, you need to rename/rework emit_add3_insn and possibly stop the compiler if the value it is invoked on is not an address. -- Eric Botcazou
Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
Hi! Ping. On Fri, 07 Mar 2014 21:21:48 +0100, I wrote: > On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote: > > I fixed a few nits Jason pointed out off-line, and both him and Jakub > > have approved the patch for trunk. > > > > In running the final round of tests I noticed a few problems with my > > choice of bit numbers for the GF_OMP_* masks. I fixed them, and re-ran > > tests on x86-64 Linux. > > > > Attached is the final version of the patch I have committed to trunk. > > > Date: Mon Oct 14 18:32:13 2013 -0500 > > > --- a/gcc/omp-low.c > > +++ b/gcc/omp-low.c > > > @@ -3587,7 +3619,7 @@ lower_rec_input_clauses (tree clauses, gimple_seq > > *ilist, gimple_seq *dlist, > >/* Don't add any barrier for #pragma omp simd or > > #pragma omp distribute. */ > >if (gimple_code (ctx->stmt) != GIMPLE_OMP_FOR > > - || gimple_omp_for_kind (ctx->stmt) == GF_OMP_FOR_KIND_FOR) > > + || gimple_omp_for_kind (ctx->stmt) & GF_OMP_FOR_KIND_FOR) > > gimple_seq_add_stmt (ilist, build_omp_barrier (NULL_TREE)); > > } > > Maybe it's just too late on a Friday evening, but I don't understand this > change, part of r204863. GF_OMP_FOR_KIND_FOR has the value zero; > shouldn't this comparison have remained unchanged? Is the following > (untested) patch OK for trunk? Does this need a test case? > > commit f3c7834ecbedc50e04223d24b1b671fc8a62c169 > Author: Thomas Schwinge > Date: Fri Mar 7 21:11:43 2014 +0100 > > Restore check for OpenMP for construct. > > gcc/ > * omp-low.c (lower_rec_input_clauses) : Restore > check for GF_OMP_FOR_KIND_FOR. > > diff --git gcc/omp-low.c gcc/omp-low.c > index 4dc3956..713a4ae 100644 > --- gcc/omp-low.c > +++ gcc/omp-low.c > @@ -3915,7 +3915,7 @@ lower_rec_input_clauses (tree clauses, gimple_seq > *ilist, gimple_seq *dlist, >/* Don't add any barrier for #pragma omp simd or >#pragma omp distribute. */ >if (gimple_code (ctx->stmt) != GIMPLE_OMP_FOR > - || gimple_omp_for_kind (ctx->stmt) & GF_OMP_FOR_KIND_FOR) > + || gimple_omp_for_kind (ctx->stmt) == GF_OMP_FOR_KIND_FOR) > gimple_seq_add_stmt (ilist, build_omp_barrier (NULL_TREE)); > } > Grüße, Thomas pgpT85V3oWwkX.pgp Description: PGP signature
config-ml.in: Robustify ac_configure_args parsing.
Hi!
$ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'
[...]
$ make configure-zlib
config.status: creating Makefile
config.status: executing default-1 commands
../../zlib/../config-ml.in: eval: line 142: unexpected EOF while looking
for matching `''
../../zlib/../config-ml.in: eval: line 143: syntax error: unexpected end of
file
make: *** [configure-zlib] Error 1
140 case $enableopt in
141 enable_shared | enable_static) ;;
142 *) eval $enableopt="$optarg" ;;
143 esac
144 ;;
$ grep ac_configure_args < zlib/config.status
ac_configure_args=" '--cache-file=./config.cache'
'--enable-foo=--enable-a=1 --enable-b=2 --enable-c=3'
'--enable-languages=c,c++,fortran,java,lto,objc'
'--program-transform-name=s,y,y,' '--disable-option-checking'
'--build=x86_64-unknown-linux-gnu' '--host=x86_64-unknown-linux-gnu'
'--target=x86_64-unknown-linux-gnu' '--srcdir=../../zlib'
'build_alias=x86_64-unknown-linux-gnu' 'host_alias=x86_64-unknown-linux-gnu'
'target_alias=x86_64-unknown-linux-gnu'"
These are quoted correctly; the error happens because the
ac_configure_args parsing logic in config-ml.in will parse this as:
1. '--enable-foo=--enable-a=1
2. --enable-b=2
3. --enable-c=3'
Below I'm proposing a patch using a shell function and eval to properly
handle such configure arguments. Instead of a shell function, we could
also use:
eval set x "${ac_configure_args}" && shift
for option
do
[...]
done
..., as done in top-level configure.ac for baseargs etc., but as the
config-ml.in script is sourced in different contexts, it is not obvious
to me that we're permitted to overwrite the shell's positional parameters
here.
OK for trunk? (Will properly indent scan_arguments before commit.)
commit bc6f99e9840994309eaf4e88679c3ba50d5e4918
Author: Thomas Schwinge
Date: Thu Mar 13 19:54:58 2014 +0100
* config-ml.in: Robustify ac_configure_args parsing.
diff --git config-ml.in config-ml.in
index 1198346..0cd7db3 100644
--- config-ml.in
+++ config-ml.in
@@ -105,10 +105,13 @@ ml_realsrcdir=${srcdir}
# Scan all the arguments and set all the ones we need.
+scan_arguments ()
+{
ml_verbose=--verbose
-for option in ${ac_configure_args}
+for option
do
- # strip single quotes surrounding individual options
+ # Strip single quotes surrounding individual options, that is, remove one
+ # level of shell quoting for these.
case $option in
\'*\') eval option=$option ;;
esac
@@ -139,7 +142,7 @@ do
# Don't undo its work.
case $enableopt in
enable_shared | enable_static) ;;
- *) eval $enableopt="$optarg" ;;
+ *) eval $enableopt='$optarg' ;;
esac
;;
--norecursion | --no-recursion)
@@ -157,7 +160,7 @@ do
*) optarg=yes ;;
esac
withopt=`echo ${option} | sed 's:^--::;s:=.*$::;s:-:_:g'`
- eval $withopt="$optarg"
+ eval $withopt='$optarg'
;;
--without-*)
withopt=`echo ${option} | sed 's:^--::;s:out::;s:-:_:g'`
@@ -165,6 +168,11 @@ do
;;
esac
done
+}
+# Use eval to properly handle configure arguments such as
+# --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'.
+eval scan_arguments "${ac_configure_args}"
+unset scan_arguments
# Only do this if --enable-multilib.
if [ "${enable_multilib}" = yes ]; then
@@ -860,7 +868,7 @@ if [ -n "${multidirs}" ] && [ -z "${ml_norecursion}" ]; then
if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
--with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
- ${ac_configure_args} ${ml_config_env} ${ml_srcdiroption} ; then
+ "${ac_configure_args}" ${ml_config_env} ${ml_srcdiroption} ; then
true
else
exit 1
Grüße,
Thomas
pgpHe1tqkFZ5h.pgp
Description: PGP signature
Re: [PATCH] BZ60501: Add addptr optab
On 14/03/14 11:02, Eric Botcazou wrote: >> This would suggest that you can use the pattern also for performing a normal >> add in case the condition code is not needed afterwards but this isn't >> correct for s390 31 bit where an address calculation is actually something >> different. > > Then you should document that by stating that the pattern is guaranteed to be > invoked only for addresses (and may not clobber the condition code). Ok, will do. >> addptr is better I think because it is a pattern which is >> supposed to be implemented with a load address instruction and the >> middle-end guarantees to use it only on addresses. (I hope LRA is actually >> behaving that way). > > Hoping isn't sufficient IMO here, you need to rename/rework emit_add3_insn > and > possibly stop the compiler if the value it is invoked on is not an address. Agreed. Any idea how to check for this? Bye, -Andreas-
Re: Enale -fno-fat-lto-objects by default
On Fri, Mar 14, 2014 at 6:36 AM, Ryan Hill wrote: > On Mon, 18 Nov 2013 19:04:59 +0100 > Jan Hubicka wrote: > >> Hi, >> this patch switches the default for fat-lto-objects as was documented for a >> while. -ffat-lto-objects doubles compilation time and often makes users to >> not notice that LTO was not used at all (because they forgot to use >> gcc-ar/gcc-nm plugins). >> >> Sadly I had to add -ffat-lto-objects to bootstrap. This is because I do not >> know how to convince our build machinery to use gcc-ar/gcc-nm during the >> stage2+ >> >> ltobootstrapped/regtested ppc64-linux, OK? >> >> Honza >> >> * config/bootstrap-lto.mk: Use -ffat-lto-objects. >> * common.opt (ffat-lto-objects): Disable by default. >> * doc/invoke.texi (fat-lto-objects): Update documentation. >> * opts.c: Enable fat-lto-objects on lto plugin disable setups. > > Hi. You seem to have included some unrelated -fipa-sem-equality stuff in > common.opt and opts.c with this commit. I have reverted those changes. Richard. > > -- > Ryan Hillpsn: dirtyepic_sk >gcc-porting/toolchain/wxwidgets @ gentoo.org > > 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
Re: [RFC] [PATCH, AARCH64] : Using standard patterns for stack protection.
On Fri, Mar 14, 2014 at 4:05 AM, Andrew Pinski wrote:
> On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
> wrote:
>> Hi Marcus,
>>
>>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>>> + [(set_attr "length" "12")])
>>>
>>> This pattern emits an opaque sequence of instructions that cannot be
>>> scheduled, is that necessary? Can we not expand individual
>>> instructions or at least split ?
>>
>> Almost all the ports emits a template of assembly instructions.
>> I m not sure why they have to be generated this way.
>> But usage of these pattern is to clear the register that holds canary
>> value immediately after its usage.
>
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01981.html answer the
> original question of why. It was a reply to the exact same question
> being asked here but about the rs6000 (PowerPC) patch.
>
To be precise, you probably want this one (
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01968.html
) which gives the reason rather than the other bits about xor. on PowerPC.
It looks like the fundamental reason is to keep this in registers for
as little time as possible and not allow this to get spilled to the
stack where it may be picked up for an exploit. That may make more
sense from a security point of view.
regards
Ramana
> Thanks,
> Andrew Pinski
>
>>
>>> -/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
>>> +/* { dg-do compile { target stack_protection } } */
>>> /* { dg-options "-O2 -fstack-protector-strong" } */
>>>
>>> Do we need a new effective target test, why is the existing
>>> "fstack_protector" not appropriate?
>>
>> "stack_protector" does a run time test. It failed in cross compilation
>> environment and these are compile only tests.
>> Also I thought richard suggested me to add a new option for this.
>> ref: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03358.html
>>
>> regards,
>> Venkat.
>>
>> On 4 February 2014 21:39, Marcus Shawcroft
>> wrote:
>>> Hi Venkat,
>>>
>>> On 22 January 2014 16:57, Venkataramanan Kumar
>>> wrote:
Hi Marcus,
After we changed the frame growing direction (downwards) in Aarch64,
the back-end now generates stack smashing set and test based on
generic code available in GCC.
But most of the ports (i386, spu, rs6000, s390, sh, sparc, tilepro and
tilegx) define machine descriptions using standard pattern names
'stack_protect_set' and 'stack_protect_test'. This is done for both
TLS model as well as global variable based stack guard model.
>>>
>>> + ""
>>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>>> + [(set_attr "length" "12")])
>>>
>>> This pattern emits an opaque sequence of instructions that cannot be
>>> scheduled, is that necessary? Can we not expand individual
>>> instructions or at least split ?
>>>
>>> + "ldr\t%x3, %x1\;ldr\t%x0, %x2\;eor\t%x0, %x3, %x0"
>>> + [(set_attr "length" "12")])
>>>
>>> Likewise.
>>>
>>> -/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
>>> +/* { dg-do compile { target stack_protection } } */
>>> /* { dg-options "-O2 -fstack-protector-strong" } */
>>>
>>> Do we need a new effective target test, why is the existing
>>> "fstack_protector" not appropriate?
>>>
>>> Cheers
>>> /Marcus
Re: [RFC] [PATCH, AARCH64] : Using standard patterns for stack protection.
Hi Venkat
On 5 February 2014 10:29, Venkataramanan Kumar
wrote:
> Hi Marcus,
>
>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>> + [(set_attr "length" "12")])
>>
>> This pattern emits an opaque sequence of instructions that cannot be
>> scheduled, is that necessary? Can we not expand individual
>> instructions or at least split ?
>
> Almost all the ports emits a template of assembly instructions.
> I m not sure why they have to be generated this way.
> But usage of these pattern is to clear the register that holds canary
> value immediately after its usage.
I've just read the thread Andrew pointed out, thanks, I'm happy that
there is a good reason to do it this way. Andrew, thanks for
providing the background.
+ [(set_attr "length" "12")])
+
These patterns should also set the "type" attribute, a reasonable
value would be "multiple".
>> -/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
>> +/* { dg-do compile { target stack_protection } } */
>> /* { dg-options "-O2 -fstack-protector-strong" } */
>>
>> Do we need a new effective target test, why is the existing
>> "fstack_protector" not appropriate?
>
> "stack_protector" does a run time test. It failed in cross compilation
> environment and these are compile only tests.
This works fine in my cross environment, how does yours fail?
> Also I thought richard suggested me to add a new option for this.
> ref: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03358.html
I read that comment to mean use an effective target test instead of
matching triples. I don't see that re-using an existing effective
target test contradicts that suggestion.
Looking through the test suite I see that there are:
6 tests that use dg-do compile with dg-require-effective-target fstack_protector
4 tests that use dg-do run with dg-require-effective-target fstack_protector
2 tests that use dg-do run {target native} dg-require-effective-target
fstack_protector
and finally the 2 tests we are discussing that use dg-compile with a
triple test.
so there are already tests in the testsuite that use dg-do compile
with the existing effective target test.
I see no immediately obvious reason why the two tests that require
target native require the native constraint... but I guess that is a
different issue.
The proposed patch moves the triple matching from the test case into
the .exp file, iff the existing run time test is inappropriate, would
it not be better to write a new effective target test that performs a
compile/link test rather resorting to a triple match?
This patch as presented would also result in two effective target
tests with names that are easily confused and provide no hint as to
their different purposes:
fstack_protector
fstack_protection
... if we are going to have two similar effective target tests then
they ought to be named in a fashion that doesn;t lead to confusion in
the future.
Can you respin and split the patch into two please one with the
aarch64 target change the other with the testsuite effective target
change?
Cheers
/Marcus
[wwwdocs] Add Ian and Ramana to steering committee list
Index: steering.html === RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v retrieving revision 1.37 diff -c -p -r1.37 steering.html *** steering.html 8 Dec 2013 21:04:17 - 1.37 --- steering.html 14 Mar 2014 14:33:57 - *** place to reach them is the gcc
Re: [wwwdocs] Add Ian and Ramana to steering committee list
On Fri, Mar 14, 2014 at 10:40:22AM -0400, David Edelsohn wrote: > ! Joseph Myers (CodeSourcery / Mentor Graphics) [co-Release Maanger] s/Maanger/Manager/ Marek
Re: [PATCH] Add test for PR c++/53711
Applied, thanks. Jason
Re: [PATCH] Use the LTO linker plugin by default
Rainer Orth writes: >>> > For this particular case at least. >>> > >>> > Note that I'm not against linking against static libgcc_s for >>> > lto-plugin. The -static-libstdc++ we use is just because during >>> > bootstrap picking up the correct libstdc++ was deemed too hard >>> > to implement and thus the easy way out was -static-libstdc++. >>> >>> So how should we go forward with this issue? This bootstrap failure is >>> a regression from all previous releases. As I said, I'd rather not >>> duplicate the -static-libgcc test from the toplevel, but would do so if >>> all else fails. Perhaps Paolo could weigh in as the build maintainer? >> >> Yeah, I'd like a build maintainer to look over your first proposed patch >> (workaround libtools nicyness). > > Just one additional data point: I've checked mainline libtool, and it > still doesn't handle (meaning: still drops) > -static-libgcc/-static-libstdc++. At least they have some hints in > their documentation on what testing etc. it takes to get additional > options passed through to the compiler/linker. I'm now testing this alternative. So far, I've just manually configured lto-plugin with CC=cc (Solaris Studio cc, no -static-libgcc) and CC=gcc and found that -static-libgcc is only used with gcc, as expected. I've checked that -static-libgcc is supported as far back as 3.4.6 (probably even far older), so the $GCC check should be enough. I'm including it in this weekend's bootstraps on Solaris and Linux. Rainer 2014-03-14 Rainer Orth * configure.ac (ac_lto_plugin_ldflags): Set to -Wc,-static-libgcc for gcc. * configure: Regenerate. * Makefile.am (AM_LDFLAGS): New variable. (liblto_plugin_la_LDFLAGS): Add it. * Makefile.in: Regenerate. # HG changeset patch # Parent baa4e95100d168dd4133db86c265fd35739647aa Fix Solaris bootstrap with GNU ld/LTO diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am --- a/lto-plugin/Makefile.am +++ b/lto-plugin/Makefile.am @@ -9,6 +9,7 @@ libexecsubdir := $(libexecdir)/gcc/$(tar AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS) AM_CFLAGS = @ac_lto_plugin_warn_cflags@ +AM_LDFLAGS = @ac_lto_plugin_ldflags@ AM_LIBTOOLFLAGS = --tag=disable-static libexecsub_LTLIBRARIES = liblto_plugin.la @@ -22,7 +23,8 @@ liblto_plugin_la_SOURCES = lto-plugin.c liblto_plugin_la_LIBADD = \ $(if $(wildcard ../libiberty/pic/libiberty.a),$(Wc)../libiberty/pic/libiberty.a,) # Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS -liblto_plugin_la_LDFLAGS = $(lt_host_flags) -module -bindir $(libexecsubdir) \ +liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) \ + $(lt_host_flags) -module -bindir $(libexecsubdir) \ $(if $(wildcard ../libiberty/pic/libiberty.a),,-Wc,../libiberty/libiberty.a) liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \ ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,) diff --git a/lto-plugin/configure.ac b/lto-plugin/configure.ac --- a/lto-plugin/configure.ac +++ b/lto-plugin/configure.ac @@ -7,6 +7,9 @@ AM_MAINTAINER_MODE AC_PROG_CC AC_SYS_LARGEFILE ACX_PROG_CC_WARNING_OPTS([-Wall], [ac_lto_plugin_warn_cflags]) +# Need -Wc to get it through libtool. +if test "x$GCC" = xyes; then ac_lto_plugin_ldflags="-Wc,-static-libgcc"; fi +AC_SUBST(ac_lto_plugin_ldflags) AM_PROG_LIBTOOL ACX_LT_HOST_FLAGS AC_SUBST(target_noncanonical) -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[AArch64] VDUP Testcases
Hi,
This patch adds vdup intrinsic testcases for AArch64. those testcases
are nice to have, as it allows to reason about vdup consistency for
both LE and BE compiler flavors.
This patch covers following intrinsics:
vdup_lane_f32
vdup_lane_s[8,16]
vdup_lane_s[32,64]
vdup_n_[p,s,u][8,16]
vdup_n_[s,u][32,64]
vdupb_lane_[s,u]8
vduph_lane_[s,u]16
vdupd_lane_[f,s,u]64
vdups_lane_[f,s,u]32
vdupq_lane_[f,s][32,64]
vdupq_lane_s[8,16]
vdup[q]_n_f32
vdupq_n_f64
vdupq_n_[s,p,u][8,16]
vdupq_n_[s,u][32,64]
Is it OK for trunk?
Kind regards,
Alex
gcc/testsuite/
2014-03-14 Alex Velenko
* gcc.target/aarch64/vdup_lane_1.c: New testcase.
* gcc.target/aarch64/vdup_lane_2.c: New testcase.
* gcc.target/aarch64/vdup_n_1.c: New testcase.
diff --git a/gcc/testsuite/gcc.target/aarch64/vdup_lane_1.c b/gcc/testsuite/gcc.target/aarch64/vdup_lane_1.c
new file mode 100644
index ..4582471c8aad3d855eb33494ac01a62c87978ca9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/vdup_lane_1.c
@@ -0,0 +1,430 @@
+/* Test vdup_lane intrinsics work correctly. */
+/* { dg-do run } */
+/* { dg-options "--save-temps -O1" } */
+
+#include
+
+extern void abort (void);
+
+float32x2_t __attribute__ ((noinline))
+wrap_vdup_lane_f32_0 (float32x2_t a)
+{
+ return vdup_lane_f32 (a, 0);
+}
+
+float32x2_t __attribute__ ((noinline))
+wrap_vdup_lane_f32_1 (float32x2_t a)
+{
+ return vdup_lane_f32 (a, 1);
+}
+
+int __attribute__ ((noinline))
+test_vdup_lane_f32 ()
+{
+ float32x2_t a;
+ float32x2_t b;
+ int i;
+ float32_t c[2] = { 0.0 , 3.14 };
+ float32_t d[2];
+
+ a = vld1_f32 (c);
+ b = wrap_vdup_lane_f32_0 (a);
+ vst1_f32 (d, b);
+ for (i = 0; i < 2; i++)
+if (c[0] != d[i])
+ return 1;
+
+ b = wrap_vdup_lane_f32_1 (a);
+ vst1_f32 (d, b);
+ for (i = 0; i < 2; i++)
+if (c[1] != d[i])
+ return 1;
+ return 0;
+}
+
+float32x4_t __attribute__ ((noinline))
+wrap_vdupq_lane_f32_0 (float32x2_t a)
+{
+ return vdupq_lane_f32 (a, 0);
+}
+
+float32x4_t __attribute__ ((noinline))
+wrap_vdupq_lane_f32_1 (float32x2_t a)
+{
+ return vdupq_lane_f32 (a, 1);
+}
+
+int __attribute__ ((noinline))
+test_vdupq_lane_f32 ()
+{
+ float32x2_t a;
+ float32x4_t b;
+ int i;
+ float32_t c[2] = { 0.0 , 3.14 };
+ float32_t d[4];
+
+ a = vld1_f32 (c);
+ b = wrap_vdupq_lane_f32_0 (a);
+ vst1q_f32 (d, b);
+ for (i = 0; i < 4; i++)
+if (c[0] != d[i])
+ return 1;
+
+ b = wrap_vdupq_lane_f32_1 (a);
+ vst1q_f32 (d, b);
+ for (i = 0; i < 4; i++)
+if (c[1] != d[i])
+ return 1;
+ return 0;
+}
+
+int8x8_t __attribute__ ((noinline))
+wrap_vdup_lane_s8_0 (int8x8_t a)
+{
+ return vdup_lane_s8 (a, 0);
+}
+
+int8x8_t __attribute__ ((noinline))
+wrap_vdup_lane_s8_1 (int8x8_t a)
+{
+ return vdup_lane_s8 (a, 1);
+}
+
+int __attribute__ ((noinline))
+test_vdup_lane_s8 ()
+{
+ int8x8_t a;
+ int8x8_t b;
+ int i;
+ /* Only two first cases are interesting. */
+ int8_t c[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
+ int8_t d[8];
+
+ a = vld1_s8 (c);
+ b = wrap_vdup_lane_s8_0 (a);
+ vst1_s8 (d, b);
+ for (i = 0; i < 8; i++)
+if (c[0] != d[i])
+ return 1;
+
+ b = wrap_vdup_lane_s8_1 (a);
+ vst1_s8 (d, b);
+ for (i = 0; i < 8; i++)
+if (c[1] != d[i])
+ return 1;
+ return 0;
+}
+
+int8x16_t __attribute__ ((noinline))
+wrap_vdupq_lane_s8_0 (int8x8_t a)
+{
+ return vdupq_lane_s8 (a, 0);
+}
+
+int8x16_t __attribute__ ((noinline))
+wrap_vdupq_lane_s8_1 (int8x8_t a)
+{
+ return vdupq_lane_s8 (a, 1);
+}
+
+int __attribute__ ((noinline))
+test_vdupq_lane_s8 ()
+{
+ int8x8_t a;
+ int8x16_t b;
+ int i;
+ /* Only two first cases are interesting. */
+ int8_t c[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
+ int8_t d[16];
+
+ a = vld1_s8 (c);
+ b = wrap_vdupq_lane_s8_0 (a);
+ vst1q_s8 (d, b);
+ for (i = 0; i < 16; i++)
+if (c[0] != d[i])
+ return 1;
+
+ b = wrap_vdupq_lane_s8_1 (a);
+ vst1q_s8 (d, b);
+ for (i = 0; i < 16; i++)
+if (c[1] != d[i])
+ return 1;
+ return 0;
+}
+
+int16x4_t __attribute__ ((noinline))
+wrap_vdup_lane_s16_0 (int16x4_t a)
+{
+ return vdup_lane_s16 (a, 0);
+}
+
+int16x4_t __attribute__ ((noinline))
+wrap_vdup_lane_s16_1 (int16x4_t a)
+{
+ return vdup_lane_s16 (a, 1);
+}
+
+int __attribute__ ((noinline))
+test_vdup_lane_s16 ()
+{
+ int16x4_t a;
+ int16x4_t b;
+ int i;
+ /* Only two first cases are interesting. */
+ int16_t c[4] = { 0, 1, 2, 3 };
+ int16_t d[4];
+
+ a = vld1_s16 (c);
+ b = wrap_vdup_lane_s16_0 (a);
+ vst1_s16 (d, b);
+ for (i = 0; i < 4; i++)
+if (c[0] != d[i])
+ return 1;
+
+ b = wrap_vdup_lane_s16_1 (a);
+ vst1_s16 (d, b);
+ for (i = 0; i < 4; i++)
+if (c[1] != d[i])
+ return 1;
+ return 0;
+}
+
+int16x8_t __attribute__ ((noinline))
+wrap_vdupq_lane_s16_0 (int16x4_t a)
+{
+ return vdupq_lane_s16 (a, 0);
+}
+
+int16x8_t __attribute__ ((noinline))
+wrap_vdupq_lane_s16_1 (int16x4_t a)
+{
+ return vdupq_lane_s16 (a, 1);
+}
+
+int __attribute__ ((noinline))
+test_vdupq_lane_
patch to fix PR60508
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 208570.
2014-03-14 Vladimir Makarov
PR rtl-optimization/60508
* lra-constraints.c (get_reload_reg): Add new parameter
in_subreg_p.
(process_addr_reg, simplify_operand_subreg, curr_insn_transform):
Pass the new parameter values.
2014-03-14 Vladimir Makarov
PR rtl-optimization/60508
* gcc.target/i386/pr60508.c: New.
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 288e24b..ba4d489 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -439,14 +439,16 @@ init_curr_insn_input_reloads (void)
}
/* Create a new pseudo using MODE, RCLASS, ORIGINAL or reuse already
- created input reload pseudo (only if TYPE is not OP_OUT). The
- result pseudo is returned through RESULT_REG. Return TRUE if we
- created a new pseudo, FALSE if we reused the already created input
- reload pseudo. Use TITLE to describe new registers for debug
- purposes. */
+ created input reload pseudo (only if TYPE is not OP_OUT). Don't
+ reuse pseudo if IN_SUBREG_P is true and the reused pseudo should be
+ wrapped up in SUBREG. The result pseudo is returned through
+ RESULT_REG. Return TRUE if we created a new pseudo, FALSE if we
+ reused the already created input reload pseudo. Use TITLE to
+ describe new registers for debug purposes. */
static bool
get_reload_reg (enum op_type type, enum machine_mode mode, rtx original,
- enum reg_class rclass, const char *title, rtx *result_reg)
+ enum reg_class rclass, bool in_subreg_p,
+ const char *title, rtx *result_reg)
{
int i, regno;
enum reg_class new_class;
@@ -471,6 +473,8 @@ get_reload_reg (enum op_type type, enum machine_mode mode,
rtx original,
Ensure we don't return *result_reg with wrong mode. */
if (GET_MODE (reg) != mode)
{
+ if (in_subreg_p)
+ continue;
if (GET_MODE_SIZE (GET_MODE (reg)) < GET_MODE_SIZE (mode))
continue;
reg = lowpart_subreg (mode, reg, GET_MODE (reg));
@@ -1139,9 +1143,11 @@ process_addr_reg (rtx *loc, rtx *before, rtx *after,
enum reg_class cl)
rtx reg;
rtx new_reg;
enum machine_mode mode;
- bool before_p = false;
+ bool subreg_p, before_p = false;
- loc = strip_subreg (loc);
+ subreg_p = GET_CODE (*loc) == SUBREG;
+ if (subreg_p)
+loc = &SUBREG_REG (*loc);
reg = *loc;
mode = GET_MODE (reg);
if (! REG_P (reg))
@@ -1171,7 +1177,7 @@ process_addr_reg (rtx *loc, rtx *before, rtx *after, enum
reg_class cl)
{
reg = *loc;
if (get_reload_reg (after == NULL ? OP_IN : OP_INOUT,
- mode, reg, cl, "address", &new_reg))
+ mode, reg, cl, subreg_p, "address", &new_reg))
before_p = true;
}
else if (new_class != NO_REGS && rclass != new_class)
@@ -1304,7 +1310,7 @@ simplify_operand_subreg (int nop, enum machine_mode
reg_mode)
= (enum reg_class) targetm.preferred_reload_class (reg, ALL_REGS);
if (get_reload_reg (curr_static_id->operand[nop].type, reg_mode, reg,
- rclass, "subreg reg", &new_reg))
+ rclass, TRUE, "subreg reg", &new_reg))
{
bool insert_before, insert_after;
bitmap_set_bit (&lra_subreg_reload_pseudos, REGNO (new_reg));
@@ -1365,7 +1371,7 @@ simplify_operand_subreg (int nop, enum machine_mode
reg_mode)
= (enum reg_class) targetm.preferred_reload_class (reg, ALL_REGS);
if (get_reload_reg (curr_static_id->operand[nop].type, mode, reg,
- rclass, "paradoxical subreg", &new_reg))
+ rclass, TRUE, "paradoxical subreg", &new_reg))
{
rtx subreg;
bool insert_before, insert_after;
@@ -3573,7 +3579,7 @@ curr_insn_transform (void)
new_reg = emit_inc (rclass, *loc, *loc,
/* This value does not matter for MODIFY. */
GET_MODE_SIZE (GET_MODE (op)));
- else if (get_reload_reg (OP_IN, Pmode, *loc, rclass,
+ else if (get_reload_reg (OP_IN, Pmode, *loc, rclass, FALSE,
"offsetable address", &new_reg))
lra_emit_move (new_reg, *loc);
before = get_insns ();
@@ -3615,7 +3621,8 @@ curr_insn_transform (void)
}
}
old = *loc;
- if (get_reload_reg (type, mode, old, goal_alt[i], "", &new_reg)
+ if (get_reload_reg (type, mode, old, goal_alt[i],
+ loc != curr_id->operand_loc[i], "", &new_reg)
&& type != OP_OUT)
{
push_to_sequence (before);
diff --git a/gcc/testsuite/gcc.target/i
Re: [PATCH] Use the LTO linker plugin by default
On Fri, 14 Mar 2014, Rainer Orth wrote: > Rainer Orth writes: > > >>> > For this particular case at least. > >>> > > >>> > Note that I'm not against linking against static libgcc_s for > >>> > lto-plugin. The -static-libstdc++ we use is just because during > >>> > bootstrap picking up the correct libstdc++ was deemed too hard > >>> > to implement and thus the easy way out was -static-libstdc++. > >>> > >>> So how should we go forward with this issue? This bootstrap failure is > >>> a regression from all previous releases. As I said, I'd rather not > >>> duplicate the -static-libgcc test from the toplevel, but would do so if > >>> all else fails. Perhaps Paolo could weigh in as the build maintainer? > >> > >> Yeah, I'd like a build maintainer to look over your first proposed patch > >> (workaround libtools nicyness). > > > > Just one additional data point: I've checked mainline libtool, and it > > still doesn't handle (meaning: still drops) > > -static-libgcc/-static-libstdc++. At least they have some hints in > > their documentation on what testing etc. it takes to get additional > > options passed through to the compiler/linker. > > I'm now testing this alternative. So far, I've just manually configured > lto-plugin with CC=cc (Solaris Studio cc, no -static-libgcc) and CC=gcc > and found that -static-libgcc is only used with gcc, as expected. I've > checked that -static-libgcc is supported as far back as 3.4.6 (probably > even far older), so the $GCC check should be enough. Yeah, only -static-libstdc++ is relatively new. And we require at least GCC 3.4.x for bootstrapping anyway. > I'm including it in this weekend's bootstraps on Solaris and Linux. Looks good to me, thus ok if the bootstraps work. Thanks, Richard.
[PATCH] Don't set dir prefix twice (PR middle-end/60484)
This patch makes sure that we set the directory prefix of
dump_base_name only once, otherwise we'd end up with invalid path,
resulting in error: could not open dump file ...
This happened because finish_options is called for every optimize
attribute and once more for command line options and every time it
added the directory prefix.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-03-14 Jakub Jelinek
Marek Polacek
PR middle-end/60484
* common.opt (dump_base_name_prefixed): New Variable.
* opts.c (finish_options): Don't prepend directory to x_dump_base_name
if x_dump_base_name_prefixed is already set, set it at the end.
diff --git gcc/common.opt gcc/common.opt
index 661516d..d8918d1 100644
--- gcc/common.opt
+++ gcc/common.opt
@@ -211,6 +211,10 @@ bool flag_opts_finished
Variable
unsigned int flag_sanitize
+; Flag whether a prefix has been added to dump_base_name
+Variable
+bool dump_base_name_prefixed = false
+
###
Driver
diff --git gcc/opts.c gcc/opts.c
index 5dd442f..41c1a73 100644
--- gcc/opts.c
+++ gcc/opts.c
@@ -645,7 +645,9 @@ finish_options (struct gcc_options *opts, struct
gcc_options *opts_set,
{
enum unwind_info_type ui_except;
- if (opts->x_dump_base_name && ! IS_ABSOLUTE_PATH (opts->x_dump_base_name))
+ if (opts->x_dump_base_name
+ && ! IS_ABSOLUTE_PATH (opts->x_dump_base_name)
+ && ! opts->x_dump_base_name_prefixed)
{
/* First try to make OPTS->X_DUMP_BASE_NAME relative to the
OPTS->X_DUMP_DIR_NAME directory. Then try to make
@@ -675,6 +677,7 @@ finish_options (struct gcc_options *opts, struct
gcc_options *opts_set,
opts->x_dump_base_name = new_dump_base_name;
}
}
+ opts->x_dump_base_name_prefixed = true;
}
/* Handle related options for unit-at-a-time, toplevel-reorder, and
Marek
[jit] Support array to pointer conversions
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.c (is_valid_cast): Permit casts between pointer types.
* internal-api.c (convert): Report more information if this ever
occurs, and make the error occur on the playback context, so that
it makes the gcc_jit_result be NULL.
(gcc::jit::playback::context::build_cast): Handle pointers. Report
more information if an unhandlable cast reaches here.
gcc/testsuite/
* jit.dg/test-expressions.c (called_pointer_checking_function): New.
(make_tests_of_casts): Add test of casting from array to pointer.
(verify_casts): Likewise.
---
gcc/jit/ChangeLog.jit | 10
gcc/jit/internal-api.c | 21 +--
gcc/jit/libgccjit.c | 6 ++
gcc/testsuite/ChangeLog.jit | 6 ++
gcc/testsuite/jit.dg/test-expressions.c | 98 +
5 files changed, 137 insertions(+), 4 deletions(-)
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 260273c..8244eba 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,13 @@
+2014-03-14 David Malcolm
+
+ * libgccjit.c (is_valid_cast): Permit casts between pointer types.
+
+ * internal-api.c (convert): Report more information if this ever
+ occurs, and make the error occur on the playback context, so that
+ it makes the gcc_jit_result be NULL.
+ (gcc::jit::playback::context::build_cast): Handle pointers. Report
+ more information if an unhandlable cast reaches here.
+
2014-03-13 David Malcolm
* libgccjit.c (is_valid_cast): New.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 062095e..8e0395d 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -33,9 +33,14 @@
extern tree convert (tree type, tree expr);
tree
-convert (tree /*type*/, tree /*expr*/)
-{
- error ("unhandled conversion");
+convert (tree dst_type, tree expr)
+{
+ gcc_assert (gcc::jit::active_playback_ctxt);
+ gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
+ fprintf (stderr, "input expression:\n");
+ debug_tree (expr);
+ fprintf (stderr, "requested type:\n");
+ debug_tree (dst_type);
return error_mark_node;
}
@@ -3095,8 +3100,16 @@ playback::context::build_cast (playback::location *loc,
t_ret = convert_to_real (t_dst_type, t_expr);
goto maybe_fold;
+case POINTER_TYPE:
+ t_ret = build1 (NOP_EXPR, t_dst_type, t_expr);
+ goto maybe_fold;
+
default:
- add_error (loc, "can't handle cast");
+ add_error (loc, "couldn't handle cast during playback");
+ fprintf (stderr, "input expression:\n");
+ debug_tree (t_expr);
+ fprintf (stderr, "requested type:\n");
+ debug_tree (t_dst_type);
return error_mark_node;
maybe_fold:
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index baab60d..5acb1bc 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -905,6 +905,12 @@ is_valid_cast (gcc::jit::recording::type *src_type,
if (dst_is_int || dst_is_bool)
return true;
+ /* Permit casts between pointer types. */
+ gcc::jit::recording::type *deref_src_type = src_type->dereference ();
+ gcc::jit::recording::type *deref_dst_type = dst_type->dereference ();
+ if (deref_src_type && deref_dst_type)
+return true;
+
return false;
}
diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index b8f1fa8..1d8c11c 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,3 +1,9 @@
+2014-03-14 David Malcolm
+
+ * jit.dg/test-expressions.c (called_pointer_checking_function): New.
+ (make_tests_of_casts): Add test of casting from array to pointer.
+ (verify_casts): Likewise.
+
2014-03-13 David Malcolm
* jit.dg/test-error-bad-cast.c: New test case.
diff --git a/gcc/testsuite/jit.dg/test-expressions.c
b/gcc/testsuite/jit.dg/test-expressions.c
index 07fe9d6..4873098 100644
--- a/gcc/testsuite/jit.dg/test-expressions.c
+++ b/gcc/testsuite/jit.dg/test-expressions.c
@@ -492,6 +492,14 @@ make_test_of_cast (gcc_jit_context *ctxt,
gcc_jit_rvalue_as_object (cast));
}
+/* For use by test_cast_from_array_of_ints_to_int_ptr. */
+extern int called_pointer_checking_function (int *ints)
+{
+ CHECK_VALUE (ints[0], 10);
+ CHECK_VALUE (ints[1], 4);
+ return ints[0] * ints[1];
+}
+
static void
make_tests_of_casts (gcc_jit_context *ctxt)
{
@@ -501,6 +509,12 @@ make_tests_of_casts (gcc_jit_context *ctxt)
gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT);
gcc_jit_type *bool_type =
gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_BOOL);
+ gcc_jit_type *array_int_type =
+gcc_jit_context_new_array_type (ctxt, NULL,
+ int_type,
+ 2);
+ gcc_jit_type *int_ptr_type =
+gcc_jit_type_get_pointer (int_type);
/* float/int conversions
Re: [PATCH] Don't set dir prefix twice (PR middle-end/60484)
On Fri, 14 Mar 2014, Marek Polacek wrote: > This patch makes sure that we set the directory prefix of > dump_base_name only once, otherwise we'd end up with invalid path, > resulting in error: could not open dump file ... > This happened because finish_options is called for every optimize > attribute and once more for command line options and every time it > added the directory prefix. > > Regtested/bootstrapped on x86_64-linux, ok for trunk? OK, though I think it might be better to use separate fields of gcc_options for the originally specified name and the prefixed version. -- Joseph S. Myers jos...@codesourcery.com
[patch] Remove unused pattern from GLIBCXX_3.4.11 version
This removes the _ZNSt12system_errorC* pattern from the GLIBCXX_3.4.11
version, because it doesn't seem to be used at the moment, but inlining
changes being tested for PR ipa/58721 cause some new symbols to be
added to the library and exported with version GLIBCXX_3.4.11, which
obviously shouldn't be getting new symbols now.
This happened for Solaris previously, and Rainer disabled the pattern
for Solaris: http://gcc.gnu.org/ml/libstdc++/2012-10/msg00070.html
This patch does the same for all targets.
Tested x86_64-linux, committed to trunk.
commit ee702751f19b333766011c6cd16156ce6c76bb69
Author: Jonathan Wakely
Date: Fri Mar 14 17:26:26 2014 +
PR ipa/58721
* config/abi/pre/gnu.ver (GLIBCXX_3.4.11): Remove unused pattern for
_ZNSt12system_errorC* symbols which are not exported on any target.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
b/libstdc++-v3/config/abi/pre/gnu.ver
index 2010bd3..f3afb94 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1056,12 +1056,6 @@ GLIBCXX_3.4.11 {
_ZTISt12system_error;
_ZTVSt12system_error;
_ZNSt12system_errorD*Ev;
-# Those template instantiations weren't exported on Solaris in GCC 4.6
-# and aren't necessary for correct operation, so don't emit them now
-# (PR libstdc++/54872).
-#if !defined(__sun__) && !defined(__svr4__)
-_ZNSt12system_errorC*;
-#endif
_ZNKSt4hashISt10error_codeEclES0_;
[Patch] Add/modify regex comments
Fix some inaccurate comments, especially the asymptotic complexity
mark: o() => \Omega().
Thanks!
--
Regards,
Tim Shen
commit 7db473c494866d071087f3e7465e36cc96a918b1
Author: tim
Date: Fri Mar 14 14:50:12 2014 -0400
2014-03-14 Tim Shen
* include/bits/regex_compiler.h: Add/modify comments.
* include/bits/regex_executor.h: Likewise.
* include/bits/regex_executor.tcc: Likewise.
* include/bits/regex_scanner.h: Likewise.
diff --git a/libstdc++-v3/include/bits/regex_compiler.h
b/libstdc++-v3/include/bits/regex_compiler.h
index fe2e5f1..6d25b39 100644
--- a/libstdc++-v3/include/bits/regex_compiler.h
+++ b/libstdc++-v3/include/bits/regex_compiler.h
@@ -42,7 +42,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
struct _BracketMatcher;
- /// Builds an NFA from an input iterator interval.
+ /**
+ * @brief class _Compiler. Builds an NFA from an input iterator interval.
+ *
+ * The %_TraitsT type should fulfill requirements [28.3].
+ */
template
class _Compiler
{
diff --git a/libstdc++-v3/include/bits/regex_executor.h
b/libstdc++-v3/include/bits/regex_executor.h
index 0885716..4e0e0fb 100644
--- a/libstdc++-v3/include/bits/regex_executor.h
+++ b/libstdc++-v3/include/bits/regex_executor.h
@@ -41,6 +41,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @{
*/
+ /**
+ * @brief class _Executor. Takes a regex and an input string in and
+ * do the matching.
+ *
+ * The %_Executor class has two modes: DFS mode and BFS mode, controlled
+ * by the template parameter %__dfs_mode.
+ */
template
class _Executor
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc
b/libstdc++-v3/include/bits/regex_executor.tcc
index e1cfcb0..68a5e04 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -72,7 +72,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// TODO: This approach is exponentially slow for certain input.
// Try to compile the NFA to a DFA.
//
- // Time complexity: o(match_length), O(2^(_M_nfa.size()))
+ // Time complexity: \Omega(match_length), O(2^(_M_nfa.size()))
// Space complexity: \theta(match_results.size() + match_length)
//
//
@@ -82,8 +82,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Russ Cox's article (http://swtch.com/~rsc/regexp/regexp1.html)
// explained this algorithm clearly.
//
- // It first computes epsilon closure for every state that's still matching,
- // using the same DFS algorithm, but doesn't reenter states (set true in
+ // It first computes epsilon closure (states that can be achieved without
+ // consuming characters) for every state that's still matching,
+ // using the same DFS algorithm, but doesn't re-enter states (find a true in
// _M_visited), nor follows _S_opcode_match.
//
// Then apply DFS using every _S_opcode_match (in _M_match_queue) as the
start
@@ -92,9 +93,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// It significantly reduces potential duplicate states, so has a better
// upper bound; but it requires more overhead.
//
- // Time complexity: o(match_length * match_results.size())
+ // Time complexity: \Omega(match_length * match_results.size())
// O(match_length * _M_nfa.size() * match_results.size())
- // Space complexity: o(_M_nfa.size() + match_results.size())
+ // Space complexity: \Omega(_M_nfa.size() + match_results.size())
// O(_M_nfa.size() * match_results.size())
template
diff --git a/libstdc++-v3/include/bits/regex_scanner.h
b/libstdc++-v3/include/bits/regex_scanner.h
index 6dc2b4e..1becb61 100644
--- a/libstdc++-v3/include/bits/regex_scanner.h
+++ b/libstdc++-v3/include/bits/regex_scanner.h
@@ -188,7 +188,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
/**
- * @brief struct _Scanner. Scans an input range for regex tokens.
+ * @brief class _Scanner. Scans an input range for regex tokens.
*
* The %_Scanner class interprets the regular expression pattern in
* the input range passed to its constructor as a sequence of parse
C++ PATCH for c++/58678 (devirt vs. KDE)
Honza suggested that if the destructor for an abstract class can't ever
be called through the vtable, the front end could avoid referring to it
from the vtable. This patch replaces such a destructor with
__cxa_pure_virtual in the vtable.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 32cc4489140da9dd154f8ba5ad3fc904efb23d55
Author: Jason Merrill
Date: Fri Mar 14 14:10:03 2014 -0400
PR c++/58678
* search.c (dfs_get_pure_virtuals): Treat the destructor of an
abstract class as pure.
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index c3eed90..66c6df5 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -2096,6 +2096,22 @@ dfs_get_pure_virtuals (tree binfo, void *data)
if (DECL_PURE_VIRTUAL_P (BV_FN (virtuals)))
vec_safe_push (CLASSTYPE_PURE_VIRTUALS (type), BV_FN (virtuals));
}
+ /* Treat a virtual destructor in an abstract class as pure even if it
+ isn't declared as pure; there is no way it would be called through the
+ vtable except during construction, which causes undefined behavior. */
+ if (binfo == TYPE_BINFO (type)
+ && CLASSTYPE_PURE_VIRTUALS (type)
+ && TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type))
+{
+ tree dtor = CLASSTYPE_DESTRUCTORS (type);
+ if (DECL_VIRTUAL_P (dtor) && !DECL_PURE_VIRTUAL_P (dtor))
+ {
+ tree clone;
+ DECL_PURE_VIRTUAL_P (dtor) = true;
+ FOR_EACH_CLONE (clone, dtor)
+ DECL_PURE_VIRTUAL_P (clone) = true;
+ }
+}
return NULL_TREE;
}
diff --git a/gcc/testsuite/g++.dg/ipa/devirt-30.C b/gcc/testsuite/g++.dg/ipa/devirt-30.C
new file mode 100644
index 000..c4ac694
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/devirt-30.C
@@ -0,0 +1,25 @@
+// PR c++/58678
+// { dg-options "-O3 -fdump-ipa-devirt" }
+
+// We shouldn't speculatively devirtualize to ~B because B is an abstract
+// class; any actual object passed to f will be of some derived class which
+// has its own destructor.
+
+struct A
+{
+ virtual void f() = 0;
+ virtual ~A();
+};
+
+struct B : A
+{
+ virtual ~B() {}
+};
+
+void f(B* b)
+{
+ delete b;
+}
+
+// { dg-final { scan-ipa-dump-not "Speculatively devirtualizing" "devirt" } }
+// { dg-final { cleanup-ipa-dump "devirt" } }
Re: [Patch] Add/modify regex comments
On 14/03/14 14:55 -0400, Tim Shen wrote: Fix some inaccurate comments, especially the asymptotic complexity mark: o() => \Omega(). If all the tests pass this is OK for trunk, thanks. N.B. the patch is fine but I don't think we usually say @brief Class FooBar. Does some Foo and some Bar. just @brief Does some Foo and some Bar. Because Doxygen always outputs the class details anyway.
[Patch, Fortran, F08] PR 55207: Variables declared in the main program should implicitly get the SAVE attribute
Hi all,
attached is a patch which implicitly sets the SAVE attribute for all
variables in the main program, as demanded by the Fortran 2008
standard. This fixes an ICE with pointer initialization (see
pointer_init_9.f90). Also a few exisiting test cases had to be changed
to accomodate for the modified behavior.
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Cheers,
Janus
2014-03-14 Janus Weil
PR fortran/55207
* decl.c (match_attr_spec): Variables in the main program implicitly
get the SAVE attribute in Fortran 2008.
2014-03-14 Janus Weil
PR fortran/55207
* gfortran.dg/assumed_rank_7.f90: Explicitly deallocate variables.
* gfortran.dg/c_ptr_tests_16.f90: Put into subroutine.
* gfortran.dg/inline_sum_bounds_check_1.f90: Add
-Wno-aggressive-loop-optimizations and remove an unused variable.
* gfortran.dg/intent_optimize_1.f90: Put into subroutine.
* gfortran.dg/pointer_init_9.f90: New.
* gfortran.dg/volatile4.f90: Put into subroutine.
* gfortran.dg/volatile6.f90: New.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 208566)
+++ gcc/fortran/decl.c (working copy)
@@ -3827,9 +3827,11 @@ match_attr_spec (void)
}
}
- /* Since Fortran 2008 module variables implicitly have the SAVE attribute.
*/
- if (gfc_current_state () == COMP_MODULE && !current_attr.save
- && (gfc_option.allow_std & GFC_STD_F2008) != 0)
+ /* Since Fortran 2008, variables declared in a MODULE or PROGRAM
+ implicitly have the SAVE attribute. */
+ if ((gfc_current_state () == COMP_MODULE
+ || gfc_current_state () == COMP_PROGRAM)
+ && !current_attr.save && (gfc_option.allow_std & GFC_STD_F2008) != 0)
current_attr.save = SAVE_IMPLICIT;
colon_seen = 1;
Index: gcc/testsuite/gfortran.dg/assumed_rank_7.f90
===
--- gcc/testsuite/gfortran.dg/assumed_rank_7.f90(revision 208566)
+++ gcc/testsuite/gfortran.dg/assumed_rank_7.f90(working copy)
@@ -24,6 +24,8 @@ call bar(ac)
call bar(at)
if (i /= 12) call abort()
+deallocate(ac,at)
+
contains
subroutine bar(x)
type(t) :: x(..)
Index: gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90
===
--- gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90(revision 208566)
+++ gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90(working copy)
@@ -3,7 +3,7 @@
!
! PR fortran/46974
-program test
+subroutine test
use ISO_C_BINDING
implicit none
type(c_ptr) :: m
@@ -15,7 +15,7 @@
.and. int(z'41424345') /= a &
.and. int(z'41424345',kind=8) /= a) &
call i_do_not_exist()
-end program test
+end subroutine
! Examples contributed by Steve Kargl and James Van Buskirk
Index: gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90
===
--- gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90 (revision
208566)
+++ gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90 (working copy)
@@ -1,9 +1,9 @@
! { dg-do run }
-! { dg-options "-fbounds-check" }
+! { dg-options "-fbounds-check -Wno-aggressive-loop-optimizations" }
integer, parameter :: nx = 3, ny = 4
- integer :: i, j, too_big
+ integer :: i, too_big
integer, parameter, dimension(nx,ny) :: p = &
reshape((/ (i*i, i=1,size(p)) /), shape(p))
Index: gcc/testsuite/gfortran.dg/intent_optimize_1.f90
===
--- gcc/testsuite/gfortran.dg/intent_optimize_1.f90 (revision 208566)
+++ gcc/testsuite/gfortran.dg/intent_optimize_1.f90 (working copy)
@@ -6,7 +6,10 @@
! honoured.
!
! PR fortran/43665
-!
+
+
+subroutine test
+
interface
subroutine foo(x)
integer, intent(in) :: x
Index: gcc/testsuite/gfortran.dg/volatile4.f90
===
--- gcc/testsuite/gfortran.dg/volatile4.f90 (revision 208566)
+++ gcc/testsuite/gfortran.dg/volatile4.f90 (working copy)
@@ -2,6 +2,8 @@
! { dg-options "-O2 -fdump-tree-optimized" }
! Tests whether volatile really works
! PR fortran/29601
+
+subroutine sub
logical, volatile :: t1
logical :: t2
integer :: i
Index: gcc/testsuite/gfortran.dg/volatile6.f90
===
--- gcc/testsuite/gfortran.dg/volatile6.f90 (revision 208566)
+++ gcc/testsuite/gfortran.dg/volatile6.f90 (working copy)
@@ -2,6 +2,8 @@
! { dg-options "-O2 -fdump-tree-optimized" }
! Tests whether volatile really works for arrays
! PR fortran/29601
+
+subroutine sub
logical, allocatable, volatile :: t1(:)
logical, allocatable :: t2(:)
integer :: i
! { dg-do run }
!
! PR 55207: [F08] Variables declared in the main program should implicitly get the SAVE attribute
Re: [Patch, Fortran, F08] PR 55207: Variables declared in the main program should implicitly get the SAVE attribute
Janus Weil wrote: Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for next stage1? Looks good to me - and simple enough for the 4.9 trunk. Tobias
[Fortran-CAF, Patch, committed] Cleanup in libcaf.h; declare caf_send
Hi all, I have committed the attached patch to the Fortran-CAF branch. It paves the road to CAF sending support by declaring caf_send - and implementing it in libcaf_single.c (as memmove). Additionally, I cleaned up the library by handling the token in a better way (more readable - and permitting a cleaner implementation in the implementation part). Additionally, it includes some fixes to my recent branch patch. The next step will be to add real sending support in the *compiler*, for which I have a draft patch. Adding send support to the library is a separate task and will be done by someone else. Committed after building and regtesting on x86-64-gnu-linux as Rev. 208580. Tobias
Re: [Fortran-CAF, Patch, committed] Cleanup in libcaf.h; declare caf_send
I forgot to attach the patch.
Tobias Burnus wrote:
Hi all,
I have committed the attached patch to the Fortran-CAF branch. It
paves the road to CAF sending support by declaring caf_send - and
implementing it in libcaf_single.c (as memmove). Additionally, I
cleaned up the library by handling the token in a better way (more
readable - and permitting a cleaner implementation in the
implementation part). Additionally, it includes some fixes to my
recent branch patch.
The next step will be to add real sending support in the *compiler*,
for which I have a draft patch. Adding send support to the library is
a separate task and will be done by someone else.
Committed after building and regtesting on x86-64-gnu-linux as Rev.
208580.
Tobias
Index: libgfortran/ChangeLog.fortran-caf
===
--- libgfortran/ChangeLog.fortran-caf (Revision 208554)
+++ libgfortran/ChangeLog.fortran-caf (Arbeitskopie)
@@ -1,3 +1,17 @@
+2014-03-14 Tobias Burnus
+
+ * caf/libcaf.h (caf_token_t): New typedef.
+ (caf_static_t, _gfortran_caf_register, _gfortran_caf_deregister):
+ Use it.
+ (_gfortran_send): New.
+ * caf/mpi.c (mpi_token_t, TOKEN): New.
+ (_gfortran_caf_register, _gfortran_caf_deregister): Update.
+ (_gfortran_caf_init): Fix prototype.
+ (_gfortran_caf_send): New stub implementation.
+ * caf/single.c (single_token_t, TOKEN): New.
+ (_gfortran_caf_register, _gfortran_caf_deregister): Update.
+ (_gfortran_caf_send): New; implement it.
+
2014-03-08 Tobias Burnus
* caf/libcaf.h (_gfortran_caf_this_image, _gfortran_caf_num_images):
Index: libgfortran/caf/libcaf.h
===
--- libgfortran/caf/libcaf.h (Revision 208554)
+++ libgfortran/caf/libcaf.h (Arbeitskopie)
@@ -28,6 +28,7 @@
#include /* For int32_t. */
#include /* For size_t. */
+#include
#ifndef __GNUC__
#define __attribute__(x)
@@ -55,9 +56,11 @@
}
caf_register_t;
+typedef void* caf_token_t;
+
/* Linked list of static coarrays registered. */
typedef struct caf_static_t {
- void **token;
+ caf_token_t token;
struct caf_static_t *prev;
}
caf_static_t;
@@ -69,10 +72,11 @@
int _gfortran_caf_this_image (int);
int _gfortran_caf_num_images (int, int);
-void * _gfortran_caf_register (size_t, caf_register_t, void ***, int *,
- char *, int);
-void _gfortran_caf_deregister (void ***, int *, char *, int);
+void *_gfortran_caf_register (size_t, caf_register_t, caf_token_t *, int *,
+ char *, int);
+void _gfortran_caf_deregister (caf_token_t *, int *, char *, int);
+void _gfortran_send (caf_token_t, size_t, int, void *, size_t, bool);
void _gfortran_caf_sync_all (int *, char *, int);
void _gfortran_caf_sync_images (int, int[], int *, char *, int);
Index: libgfortran/caf/mpi.c
===
--- libgfortran/caf/mpi.c (Revision 208554)
+++ libgfortran/caf/mpi.c (Arbeitskopie)
@@ -34,6 +34,8 @@
/* Define GFC_CAF_CHECK to enable run-time checking. */
/* #define GFC_CAF_CHECK 1 */
+typedef void ** mpi_token_t;
+#define TOKEN(X) ((mpi_token_t) (X))
static void error_stop (int error) __attribute__ ((noreturn));
@@ -73,7 +75,7 @@
libaray is initialized. */
void
-_gfortran_caf_init (int *argc, char ***argv, int *this_image, int *num_images)
+_gfortran_caf_init (int *argc, char ***argv)
{
if (caf_num_images == 0)
{
@@ -99,8 +101,8 @@
{
caf_static_t *tmp = caf_static_list->prev;
- free (caf_static_list->token[caf_this_image-1]);
- free (caf_static_list->token);
+ free (TOKEN(caf_static_list->token)[caf_this_image-1]);
+ free (TOKEN(caf_static_list->token));
free (caf_static_list);
caf_static_list = tmp;
}
@@ -128,7 +130,7 @@
void *
-_gfortran_caf_register (size_t size, caf_register_t type, void ***token,
+_gfortran_caf_register (size_t size, caf_register_t type, caf_token_t *token,
int *stat, char *errmsg, int errmsg_len)
{
void *local;
@@ -139,17 +141,17 @@
/* Start MPI if not already started. */
if (caf_num_images == 0)
-_gfortran_caf_init (NULL, NULL, NULL, NULL);
+_gfortran_caf_init (NULL, NULL);
/* Token contains only a list of pointers. */
local = malloc (size);
- *token = malloc (sizeof (void*) * caf_num_images);
+ *token = malloc (sizeof (mpi_token_t) * caf_num_images);
if (unlikely (local == NULL || *token == NULL))
goto error;
/* token[img-1] is the address of the token in image "img". */
- err = MPI_Allgather (&local, sizeof (void*), MPI_BYTE, *token,
+ err = MPI_Allgather (&local, sizeof (void*), MPI_BYTE, TOKEN(*token),
sizeof (void*), MPI_BYTE, MPI_COMM_WORLD);
if (unlikely (err))
@@ -202,7 +204,7 @@
void
-_gfortran_caf_deregister (void ***token, int *stat, char *errmsg, int errmsg_len)
+_gfortran_caf_deregister (caf_token_t *token, int *stat, char *errmsg, int errmsg_len)
{
Missing experimental patch bit
Hi
I just realized that when I committed this:
2014-01-20 François Dumont
* scripts/create_testsuite_files: Add testsuite/experimental in
the list of folders to search for tests.
* include/experimental/string_view
(basic_string_view<>::operator[]): Comment _GLIBCXX_DEBUG_ASSERT,
incompatible with constexpr qualifier.
(basic_string_view<>::front()): Likewise.
(basic_string_view<>::back()): Likewise.
* testsuite/experimental/string_view/element_access/wchar_t/2.cc:
Merge dg-options directives into one.
* testsuite/experimental/string_view/element_access/char/2.cc:
Likewise. Remove invalid experimental namespace scope on
string_view_type.
I forgot to commit the create_testsuite_files script. Is it still ok to
do so now ?
By the way is there an info about when stage 1 is going to restart ?
François
Index: scripts/create_testsuite_files
===
--- scripts/create_testsuite_files (revision 208578)
+++ scripts/create_testsuite_files (working copy)
@@ -32,7 +32,7 @@
# This is the ugly version of "everything but the current directory". It's
# what has to happen when find(1) doesn't support -mindepth, or -xtype.
dlist=`echo [0-9][0-9]*`
-dlist="$dlist abi backward ext performance tr1 tr2 decimal"
+dlist="$dlist abi backward ext performance tr1 tr2 decimal experimental"
find $dlist "(" -type f -o -type l ")" -name "*.cc" -print > $tmp.01
find $dlist "(" -type f -o -type l ")" -name "*.c" -print > $tmp.02
cat $tmp.01 $tmp.02 | sort > $tmp.1
Re: Missing experimental patch bit
On 14/03/14 22:26 +0100, François Dumont wrote: I forgot to commit the create_testsuite_files script. Is it still ok to do so now ? Yes, since this was meant to be commited earlier it's OK to commit now (assuming it doesn't introduce any new failures) - thanks. By the way is there an info about when stage 1 is going to restart ? After the 4.9 branch is created, which will be when it's ready :-)
Re: [PATCH] Fix PR60505
On Fri, Mar 14, 2014 at 12:58 AM, Richard Biener wrote: > On Fri, 14 Mar 2014, Jakub Jelinek wrote: > >> On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote: >> > > Consider this fact and if there are alias checks, we can safely remove >> > > the epilogue if the maximum trip count of the loop is less than or >> > > equal to the calculated threshold. >> > >> > You have to consider n % vf != 0, so an argument on only maximum >> > trip count or threshold cannot work. >> >> Well, if you only check if maximum trip count is <= vf and you know >> that for n < vf the vectorized loop + it's epilogue path will not be taken, >> then perhaps you could, but it is a very special case. >> Now, the question is when we are guaranteed we enter the scalar versioned >> loop instead for n < vf, is that in case of versioning for alias or >> versioning for alignment? > > I think neither - I have plans to do the cost model check together > with the versioning condition but didn't get around to implement that. > That would allow stronger max bounds for the epilogue loop. In vect_transform_loop(), check_profitability will be set to true if th >= VF-1 and the number of iteration is unknown (we only consider unknown trip count here), where th is calculated based on the parameter PARAM_MIN_VECT_LOOP_BOUND and cost model, with the minimum value VF-1. If the loop needs to be versioned, then check_profitability with true value will be passed to vect_loop_versioning(), in which an enhanced loop bound check (considering cost) will be built. So I think if the loop is versioned and n < VF, then we must enter the scalar version, and in this case removing epilogue should be safe when the maximum trip count <= th+1. thanks, Cong > > Richard.
Re: C++ PATCH for c++/58678 (devirt vs. KDE)
Oops, need to make sure dtor is non-null before looking at it...
We also might as well handle this after the dfs is done.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 142f595d2474a05c59991e8ea7a5f6712d9982ff
Author: Jason Merrill
Date: Fri Mar 14 20:38:10 2014 -0400
PR c++/60532
PR c++/58678
* search.c (get_pure_virtuals): Handle abstract dtor here.
(dfs_get_pure_virtuals): Not here.
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index 66c6df5..d99e182 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -2096,22 +2096,6 @@ dfs_get_pure_virtuals (tree binfo, void *data)
if (DECL_PURE_VIRTUAL_P (BV_FN (virtuals)))
vec_safe_push (CLASSTYPE_PURE_VIRTUALS (type), BV_FN (virtuals));
}
- /* Treat a virtual destructor in an abstract class as pure even if it
- isn't declared as pure; there is no way it would be called through the
- vtable except during construction, which causes undefined behavior. */
- if (binfo == TYPE_BINFO (type)
- && CLASSTYPE_PURE_VIRTUALS (type)
- && TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type))
-{
- tree dtor = CLASSTYPE_DESTRUCTORS (type);
- if (DECL_VIRTUAL_P (dtor) && !DECL_PURE_VIRTUAL_P (dtor))
- {
- tree clone;
- DECL_PURE_VIRTUAL_P (dtor) = true;
- FOR_EACH_CLONE (clone, dtor)
- DECL_PURE_VIRTUAL_P (clone) = true;
- }
-}
return NULL_TREE;
}
@@ -2131,6 +2115,22 @@ get_pure_virtuals (tree type)
which it is a primary base will contain vtable entries for the
pure virtuals in the base class. */
dfs_walk_once (TYPE_BINFO (type), NULL, dfs_get_pure_virtuals, type);
+
+ /* Treat a virtual destructor in an abstract class as pure even if it
+ isn't declared as pure; there is no way it would be called through the
+ vtable except during construction, which causes undefined behavior. */
+ if (CLASSTYPE_PURE_VIRTUALS (type)
+ && TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type))
+{
+ tree dtor = CLASSTYPE_DESTRUCTORS (type);
+ if (dtor && DECL_VIRTUAL_P (dtor) && !DECL_PURE_VIRTUAL_P (dtor))
+ {
+ tree clone;
+ DECL_PURE_VIRTUAL_P (dtor) = true;
+ FOR_EACH_CLONE (clone, dtor)
+ DECL_PURE_VIRTUAL_P (clone) = true;
+ }
+}
}
/* Debug info for C++ classes can get very large; try to avoid
diff --git a/gcc/testsuite/g++.dg/other/abstract6.C b/gcc/testsuite/g++.dg/other/abstract6.C
new file mode 100644
index 000..ceba1a6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/abstract6.C
@@ -0,0 +1,10 @@
+// PR c++/60532
+
+class A
+{
+ ~A ();
+};
+class B : A
+{
+ virtual void m () = 0;
+};
[patch, libgfortran] PR58324 Bogus END-of-line error with list-directed I/O
The attached patch fixes this problem by first reading the next available char
to see if EOF is encountered. If so, issue the EOF error. If not use eat_line
to find the end of the line. If the end of the line is at the end of the file,
it will be caught on any subsequent attempt to read.
The problem particularly manifests for empty reads that do no other actual file
reading except in (finish_list_read).
Regression tested on x86-64-linux-gnu. NIST tested. test case provided.
Ok for trunk?
Regards,
Jerry
2014-03-14 Jerry DeLisle
PR libfortran/58324
* io/list_read.c (finish_list_read): Read one character to check
for the end of the file. If it is the end, then issue the file
end error message. If not, use eat_line to reach the end
without giving error. The next attempt to read will then
issue the error as described above.
Index: list_read.c
===
--- list_read.c (revision 208561)
+++ list_read.c (working copy)
@@ -2092,8 +2092,6 @@ list_formatted_read (st_parameter_dt *dtp, bt type
void
finish_list_read (st_parameter_dt *dtp)
{
- int err;
-
free_saved (dtp);
fbuf_flush (dtp->u.p.current_unit, dtp->u.p.mode);
@@ -2106,13 +2104,20 @@ finish_list_read (st_parameter_dt *dtp)
if (!is_internal_unit (dtp))
{
- err = eat_line (dtp);
- if (err == LIBERROR_END)
+ int c;
+ c = next_char (dtp);
+ if (c == EOF)
{
free_line (dtp);
hit_eof (dtp);
+ return;
}
+ if (c != '\n')
+ eat_line (dtp);
}
+
+ free_line (dtp);
+
}
/* NAMELIST INPUT
! { dg-do run }
! PR58324 Bogus end of file condition
integer :: i, ios
open(99, access='stream', form='unformatted')
write(99) "5 a"
close(99)
open(99, access='sequential', form='formatted')
read(99, *, iostat=ios) i
if (ios /= 0) call abort
end
[PR58479] introduce a param to limit debug stmts count
This bug report had various testcases that had to do with full loop
unrolling with non-automatic iterators and fixed boundaries, which
resulted in duplicating debug stmts in the loop for each iteration. In
some cases, the resulting executable code is none, but the debug stmts
add up to millions. Just dropping them on the floor is somewhat
undesirable, even though they're not usable for much with today's
compiler and debugger infrastructure. I decided to introduce a param to
limit debug stmts, so that this sort of testcase doesn't run nearly
forever, eating up all memory while at that. This is what this patchset
does.
The first patch introduces the parameter (defaulting to no limit) and
the infrastructure around it. I decided to only detect that the limit
was exceeded and clean up existing debug stmts at pass boundaries, so
that no pass would be surprised by a failure to create a debug stmt
where it used to be possible to do so.
The second patch addresses the actual problem in some passes,
particularly in the code that copies basic blocks, used by the loop
unroller, by testing regularly whether building more debug stmts is
desirable. They will still collect debug stmts only at the end of the
pass, since there's not much reason to rush to do that.
The third patch enables the limit by default. I played a bit with lower
values, and on i686 and x86_64, I could build all of stage3, with all
languages enabled, without any debug info degradation, with the limit
set as low as 25000, so 1 million is a very conservative limit.
fold-const, the largest debug stmt builder, builds a total of 24382
debug stmts, and with the limit at 1, fold_binary_loc is still the
only function that VTA disabled because the limit is reached. At 4000,
there are only some 20 functions in the entire stage3 (host and target
libs) that get degradation. fold-const.c:fold_comparison and
tree-browser.c:browse_tree got my attention because they built a few
hundred debug stmts more than the limit set, indicating there are other
passes that may still benefit from BUILD_DEBUG_STMTS_P testing, but I
haven't investigated any further.
Regstrapped incrementally (first patch alone, first and second, and all
3) on i686- and x86_64-linux-gnu. Ok to install?
Introduce --param max-vartrack-debug-stmts
From: Alexandre Oliva
for gcc/ChangeLog
PR debug/58479
* cfgexpand.c (expand_gimple_basic_block): Check that
MAY_HAVE_DEBUG_STMTS remains true when expanding debug stmts.
* doc/invoke.texi (max-vartrack-debug-stmts): New param.
* function.c (allocate_struct_function): Initialize
debug_stmts enabler and counter based on
flag_var_tracking_assignments.
* function.h (struct function): Add debug_stmts counter.
* gimple.c (gimple_alloc_stat): Check enablement and increment
counter when code is GIMPLE_DEBUG.
(gimple_collect_debug_stmts): New function.
* gimple.h (gimple_collect_debug_stmts): Declare.
* lto-streamer-in.c (input_function): Enable debug stmts while
reading stmts. Simplify their removal.
* params.def (PARAM_MAX_DEBUG_STMTS): New.
* passes.c (execute_one_pass): Collect debug stmts after
gimple passes if we reached the limit.
* rtl.h (MAY_HAVE_DEBUG_INSNS): Base on debug_stmts counter.
* tree.h (MAY_HAVE_DEBUG_STMTS): Likewise.
(BUILD_DEBUG_STMTS_P, SET_BUILD_DEBUG_STMTS): New macros.
---
gcc/cfgexpand.c |4
gcc/doc/invoke.texi |8
gcc/function.c|2 ++
gcc/function.h|7 +++
gcc/gimple.c | 40 +++-
gcc/gimple.h |1 +
gcc/lto-streamer-in.c | 18 --
gcc/params.def|8
gcc/passes.c |4
gcc/rtl.h |2 +-
gcc/tree.h| 21 +++--
11 files changed, 105 insertions(+), 10 deletions(-)
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index dd163a5..783b928 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -5024,6 +5024,8 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
}
else if (gimple_debug_bind_p (stmt))
{
+ gcc_checking_assert (MAY_HAVE_DEBUG_STMTS);
+
location_t sloc = curr_insn_location ();
gimple_stmt_iterator nsi = gsi;
@@ -5088,6 +5090,8 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
}
else if (gimple_debug_source_bind_p (stmt))
{
+ gcc_checking_assert (MAY_HAVE_DEBUG_STMTS);
+
location_t sloc = curr_insn_location ();
tree var = gimple_debug_source_bind_get_var (stmt);
tree value = gimple_debug_source_bind_get_value (stmt);
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 24bd76e..3e26fc3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9950,6 +9950,14 @@ debug information may end up not being used; setting this higher may
enable the compiler to find more complex debug expressions, but compile
time and memory use may grow. The default is 12.
+@item max-vartrack-debug-stmts
+Se
[COMMITTED] Fix target/60525 -- i386 float ICEs
This PR is fallout from my patch from yesterday, which adjusted some of the
i386 float->int conversion patterns. In the gcc-patches message for that
change, I opined that in stage1 we should clean up all of these patterns.
Except that the existing state of affairs appears to have been too complex for
me to make small changes and get all of the fiddly bits right. Cleaning all of
this up now turns out to be the best way for me to ensure that all of the
patterns are in sync.
The diffstat of the two patches is impressive:
> i386-protos.h |4
> i386.c| 105
> i386.md | 761
> +-
> 3 files changed, 133 insertions(+), 737 deletions(-)
over 600 lines removed from these conversion patterns.
Anyway, tested by me with -march=generic, and by the reporter with
-march=amdfam10.
r~
PR target/60525
* config/i386/i386.md (floathi2): Delete expander; rename
define_insn from *floathi2_i387; allow nonimmediate_operand.
(*floathi2_i387_with_temp): Remove.
(floathi splitters): Remove.
(floatxf2): New pattern.
(float2): Rename from float2. Drop
code that tried to handle DImode for 32-bit, but which was excluded
by the pattern's condition. Drop allocation of stack temporary.
(*floatsi2_vector_mixed_with_temp): Remove.
(*float2_mixed_with_temp): Remove.
(*float2_mixed_interunit): Remove.
(*float2_mixed_nointerunit): Remove.
(*floatsi2_vector_sse_with_temp): Remove.
(*float2_sse_with_temp): Remove.
(*float2_sse_interunit): Remove.
(*float2_sse_nointerunit): Remove.
(*float2_i387_with_temp): Remove.
(*float2_i387): Remove.
(all float _with_temp splitters): Remove.
(*float2_i387): New pattern.
(*float2_sse): New pattern.
(float TARGET_USE_VECTOR_CONVERTS splitters): Merge them.
(float TARGET_SSE_PARTIAL_REG_DEPENDENCY splitters): Merge them.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 03939fd..a824e78 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -4653,36 +4653,12 @@
;; Conversion between fixed point and floating point.
;; Even though we only accept memory inputs, the backend _really_
-;; wants to be able to do this between registers.
+;; wants to be able to do this between registers. Thankfully, LRA
+;; will fix this up for us during register allocation.
-(define_expand "floathi2"
- [(parallel [(set (match_operand:X87MODEF 0 "register_operand")
- (float:X87MODEF
-(match_operand:HI 1 "nonimmediate_operand")))
- (clobber (match_dup 2))])]
- "TARGET_80387
- && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
- || TARGET_MIX_SSE_I387)"
-{
- operands[2] = assign_386_stack_local (HImode, SLOT_TEMP);
-})
-
-(define_insn "*floathi2_i387_with_temp"
- [(set (match_operand:X87MODEF 0 "register_operand" "=f,f")
- (float:X87MODEF (match_operand:HI 1 "nonimmediate_operand" "m,?r")))
- (clobber (match_operand:HI 2 "memory_operand" "=X,m"))]
- "TARGET_80387
- && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
- || TARGET_MIX_SSE_I387)"
- "#"
- [(set_attr "type" "fmov,multi")
- (set_attr "mode" "")
- (set_attr "unit" "*,i387")
- (set_attr "fp_int_src" "true")])
-
-(define_insn "*floathi2_i387"
+(define_insn "floathi2"
[(set (match_operand:X87MODEF 0 "register_operand" "=f")
- (float:X87MODEF (match_operand:HI 1 "memory_operand" "m")))]
+ (float:X87MODEF (match_operand:HI 1 "nonimmediate_operand" "m")))]
"TARGET_80387
&& (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
|| TARGET_MIX_SSE_I387)"
@@ -4691,50 +4667,31 @@
(set_attr "mode" "")
(set_attr "fp_int_src" "true")])
-(define_split
- [(set (match_operand:X87MODEF 0 "register_operand")
- (float:X87MODEF (match_operand:HI 1 "register_operand")))
- (clobber (match_operand:HI 2 "memory_operand"))]
- "TARGET_80387
- && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
- || TARGET_MIX_SSE_I387)
- && reload_completed"
- [(set (match_dup 2) (match_dup 1))
- (set (match_dup 0) (float:X87MODEF (match_dup 2)))])
-
-(define_split
- [(set (match_operand:X87MODEF 0 "register_operand")
- (float:X87MODEF (match_operand:HI 1 "memory_operand")))
- (clobber (match_operand:HI 2 "memory_operand"))]
- "TARGET_80387
-&& (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
-|| TARGET_MIX_SSE_I387)
-&& reload_completed"
- [(set (match_dup 0) (float:X87MODEF (match_dup 1)))])
+(define_insn "floatxf2"
+ [(set (match_operand:XF 0 "register_operand" "=f")
+ (float:XF (match_operand:SWI48x 1 "nonimmediate_operand" "m")))]
+ "TARGET_80387"
+ "fild%Z1\t%1"
+ [(set_attr "type" "fmov")
+ (set_attr "mode" "XF")
+ (set_attr "fp_int_src" "true")])
-(define_expand "float2"
- [(parallel [(set (match_operand:X87MODEF
Re: [PR58479] introduce a param to limit debug stmts count
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva wrote: > In some cases, the resulting executable code is none, but the debug stmts > add up to millions. I’d like to think there is a better theoretic answer to the specific problem… trimming random debug info I think just invites a bad experience where people want to know what is going on and to them it just feels like a bad compiler that just randomly messed up debug info. A user that wants faster compilation can refrain from using -g, or use -g1? For example, if there truly is no code, removing all scopes that have no instruction between the start and the end along with all the debug info that goes with those scopes. If there is one instruction, seems tome that it should be hard to have more than a few debug statements per instruction. If there are more than 5, it would be curious to review each one and ask the question, is this useful and interesting? I’d like to think there are entire classes of useless things that can be removed with no loss to the debug experience.
Register at the GSoC website to rate projects
Hi,
You are receiving this message because you are in top 50 contributors to GCC
[1]. Congratulations!
Since you are a top contributor to GCC project it is important for you to rate
the incoming student GSOC applications. Go and register at
https://www.google-melange.com/gsoc/homepage/google/gsoc2014 and connect with
"GCC - GNU Compiler Collection" organization. Pretty. Please. It will take
3-5 minutes of your time.
Furthermore, if you work at a college or university (or otherwise interact with
talented computer science students), encourage them to look at GCC's ideas page
[2] and run with it for a summer project (or, indeed, propose their own idea).
They should hurry, only one week is left!
So far we've got several good proposals from students, but we want to see more.
Thank you,
[1] As determined by number of checked in patches over the last 2 years (and,
"yes", I know this is not the fairest metric). Script used:
$ git log "--pretty=format:%an" | head -n 12000 | awk '{ a[$1]++; } END { for
(i in a) print a[i] " " i; }' | sort -g | tail -n 50
[2] http://gcc.gnu.org/wiki/SummerOfCode
--
Maxim Kuvyrkov
www.linaro.org
