Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64
On Thu, Jul 3, 2014 at 3:02 PM, Uros Bizjak wrote:
> On Thu, Jul 3, 2014 at 2:43 PM, FX wrote:
>> Here’s an updated patch, providing support for underflow control in the
>> IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc.
>>
>> Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha.
>
> The testcase still needs:
>
> ! { dg-do run }
> ! { dg-require-effective-target sse2_runtime { target { i?86-*-*
> x86_64-*-* } } }
> ! { dg-additional-options "-msse2 -mfpmath=sse" { target { i?86-*-*
> x86_64-*-* } } }
I think that:
+x = x / 2000._kx
+if (x <= 0) call abort
+call ieee_get_underflow_mode(l)
+if (.not. l) call abort
+
+x = tiny(x)
+call ieee_set_underflow_mode(.false.)
+x = x / 2000._kx
+if (x > 0) call abort
you want to test for == 0 above and != 0 below, and in the same way for DFmode.
The x86 part of the patch is OK.
Uros.
[wwwdocs,Fortran] Announce IEEE intrinsic modules support for Fortran
Hi there, I am thinking to provide the update below on our main page. Let me know if there are any changes you'd like to see. Also, for that page having 2-3(-4) words as a short title are necessary. What would be appropriate here? "Fortran IEEE intrinsic modules"? Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.926 diff -u -r1.926 index.html --- index.html 30 Jun 2014 16:49:33 - 1.926 +++ index.html 4 Jul 2014 08:08:29 - @@ -52,6 +52,12 @@ +[2014-07-04] +The Fortran compiler (gfortran) has gained support for the IEEE +intrinsic modules specified by the Fortran 2003 and Fortran 2008 +standards. The code was contributed by François-Xavier Coudert of +CNRS. + OpenMP v4.0 [2014-06-30] An implementation of the
Re: [PATCH] Don't run guality.exp tests with LTO_TORTURE_OPTIONS.
On July 3, 2014 10:47:52 PM CEST, Mark Wielaard wrote: >On Thu, 2014-07-03 at 22:14 +0200, Jakub Jelinek wrote: >> On Thu, Jul 03, 2014 at 10:04:35PM +0200, Mark Wielaard wrote: >> > On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote: >> > > On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek >wrote: >> > > >On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote: >> > > >> Well, simply removing the regression testing for LTO is a >> > > >maintainance nightmare as well. >> > > >> >> > > >> The guality testsuite is very noisy anyway with all the xfail >and >> > > >xpass. >> > > > >> > > >Let's keep it as is then? >> > > >> > > That works for me. >> > >> > I don't find that very satisfactory. I want to add more guality >tests, >> > but the fact that they are unreliable and by default introduce even >more >> > FAILs when lto is enabled makes that not very attractive. I do like >> > Jakub's suggestion to disable the guality tests be run with lto by >> > default, but provide an environment variable to enable them for >those >> > that want to try them anyway. Shall I implement that? >> >> They aren't that unrealiable (at least, if people committing patches >don't >> ignore regressions in there). Just one should diff >contrib/test_summary >> output from earlier builds to the latest, that way it is clear what >is a >> regression and what is not. > >The are much more unreliable than any other test. With guality.exp >disabled one can just eyeball the results and investigate new FAILS. >There are only a handful. When you include guality.exp you can easily >get the impression the gcc testsuite is really bad (and it isn't!) And >the problem is that it makes adding new tests a pain. See my new tests, >they introduce new FAILs because LTO is enabled by default for >guality.exp at the moment. It just results in a slow increase of FAILs >that people have to ignore. And I am afraid that will just result in >people missing real regressions. > >I don't mind if there is active work to fix LTO DWARF debuginfo >generation issues and the guality.exp LTO failures will soon disappear, >but if there is no active work on reducing the amount of failures and >introducing new guality.exp testcases will keep adding more FAILs I >think we are much better off disabling them for now. Can't you simply add proper xfails for lto when you add new tests that fail with lto? (Please quickly check why - usually the tests are just optimized in an unexpected way - compare with -fwhole-program behavior for example). BTW, reducing the number of lto variants checked to -O2 -flto would be fine with me. Richard. >Thanks, > >Mark
Re: [wwwdocs,Fortran] Announce IEEE intrinsic modules support for Fortran
> Also, for that page having 2-3(-4) words as a short title are necessary. > What would be appropriate here? "Fortran IEEE intrinsic modules”? Sounds good to me. FX
Re: [PATCH] Fix ICE with thunks (PR middle-end/61654)
On July 3, 2014 8:47:36 PM CEST, Jakub Jelinek wrote:
>Hi!
>
>update_ssa that expand_thunk calls, if it needs to change anything,
>computes CDI_DOMINATORS, but we assert that dominators are not computed
>when we release e.g. an unused thunk.
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
>for trunk/4.9?
OK.
Thanks,
Richard.
>2014-07-03 Jakub Jelinek
>
> PR middle-end/61654
> * cgraphunit.c (expand_thunk): Call free_dominance_info.
>
> * g++.dg/opt/pr61654.C: New test.
>
>--- gcc/cgraphunit.c.jj2014-07-01 19:38:24.0 +0200
>+++ gcc/cgraphunit.c 2014-07-03 15:51:44.329423346 +0200
>@@ -1693,6 +1693,7 @@ expand_thunk (struct cgraph_node *node,
> #ifdef ENABLE_CHECKING
> verify_flow_info ();
> #endif
>+ free_dominance_info (CDI_DOMINATORS);
>
> /* Since we want to emit the thunk, we explicitly mark its name as
>referenced. */
>--- gcc/testsuite/g++.dg/opt/pr61654.C.jj 2014-07-03 15:55:42.413163208
>+0200
>+++ gcc/testsuite/g++.dg/opt/pr61654.C 2014-07-03 15:55:16.0
>+0200
>@@ -0,0 +1,27 @@
>+// PR middle-end/61654
>+// { dg-do compile }
>+
>+class A
>+{
>+ virtual int a (int, int = 0) = 0;
>+ int b (const int &);
>+ int c;
>+};
>+
>+class B : virtual A
>+{
>+ int d;
>+ int a (int, int);
>+};
>+
>+int
>+A::b (const int &)
>+{
>+ return a ('\0');
>+}
>+
>+int
>+B::a (int, int)
>+{
>+ return 0 ? 0 : d;
>+}
>
> Jakub
Re: [PATCH] Fix recognize_single_bit_test (PR tree-optimization/61684)
On July 3, 2014 8:44:28 PM CEST, Jakub Jelinek wrote:
>Hi!
>
>The rhs1 of CONVERT_EXPR_CODE_P doesn't have to be a SSA_NAME, can be
>e.g.
>invariant like ADDR_EXPR of a var, but ifcombine didn't think about
>that
>possibility.
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
>for
>trunk/4.9/4.8?
Ok.
Thanks
Richard.
>2014-07-03 Jakub Jelinek
>
> PR tree-optimization/61684
> * tree-ssa-ifcombine.c (recognize_single_bit_test): Make sure
> rhs1 of conversion is a SSA_NAME before using SSA_NAME_DEF_STMT on it.
>
> * gcc.c-torture/compile/pr61684.c: New test.
>
>--- gcc/tree-ssa-ifcombine.c.jj2014-06-06 09:19:22.0 +0200
>+++ gcc/tree-ssa-ifcombine.c 2014-07-03 11:46:25.868335148 +0200
>@@ -233,7 +233,8 @@ recognize_single_bit_test (gimple cond,
> while (is_gimple_assign (stmt)
>&& ((CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))
> && (TYPE_PRECISION (TREE_TYPE (gimple_assign_lhs (stmt)))
>-<= TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1
>(stmt)
>+<= TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1 (stmt
>+&& TREE_CODE (gimple_assign_rhs1 (stmt)) == SSA_NAME)
>|| gimple_assign_ssa_name_copy_p (stmt)))
> stmt = SSA_NAME_DEF_STMT (gimple_assign_rhs1 (stmt));
>
>--- gcc/testsuite/gcc.c-torture/compile/pr61684.c.jj 2014-07-03
>12:06:46.654858358 +0200
>+++ gcc/testsuite/gcc.c-torture/compile/pr61684.c 2014-07-03
>12:09:05.016123771 +0200
>@@ -0,0 +1,15 @@
>+/* PR tree-optimization/61684 */
>+
>+int a, c;
>+static int *b = 0;
>+short d;
>+static short **e = 0;
>+
>+void
>+foo ()
>+{
>+ for (; c < 1; c++)
>+;
>+ *e = &d;
>+ a = d && (c && 1) & *b;
>+}
>
> Jakub
Fix BLOCK_SUPERCONTEXT for cilk produced functions
Hi, BLOCK_SUPERCONTEXT for normal blocks leads all the way to FUNCTOIN_DECL. This is not the case of some automatically generated functions, like one for cilk. I think it is bug. This patch fixes cilk, I will look for other cases if that looks OK. Bootstrapped/regtested x86_64-linux Honza * cilk.c (create_cilk_helper_decl): Create toplevel block correctly. Index: cilk.c === --- cilk.c (revision 212278) +++ cilk.c (working copy) @@ -314,6 +314,7 @@ create_cilk_helper_decl (struct wrapper_ tree block = make_node (BLOCK); DECL_INITIAL (fndecl) = block; TREE_USED (block) = 1; + BLOCK_SUPERCONTEXT (block) = fndecl; gcc_assert (!DECL_SAVED_TREE (fndecl)); /* Inlining would defeat the purpose of this wrapper.
Re: [PATCH v2] typeof: Remove type qualifiers for atomic types
On 2014-06-30 15:03, Marek Polacek wrote: On Fri, Jun 27, 2014 at 08:49:24AM +0200, Marek Polacek wrote: On Fri, Jun 27, 2014 at 08:36:38AM +0200, Sebastian Huber wrote: Thanks for your patience. It would be nice if this can be applied to GCC 4.9 as well. Can someone please commit this for me, since I don't have write access. I will commit it for you. Now applied to 4.9 as well. Marek Should this __typeof and __auto_type behaviour for atomic types show up in the documentation? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo wrote: > > >> -Original Message- >> From: Richard Earnshaw >> Sent: Wednesday, June 18, 2014 4:31 PM >> To: Terry Guo >> Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan >> Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function >> thumb1_reorg >> >> On 10/06/14 12:42, Terry Guo wrote: >> > Hi There, >> > >> > The thumb1_reorg function use macro INSN_CODE to find expected >> instructions. >> > But the macro INSN_CODE doesn't work for label type instruction. The >> > INSN_CODE(label_insn) will return the label number. When we have a lot >> of >> > labels and current label_insn is the first insn of basic block, the >> > INSN_CODE(label_insn) could accidentally equal to >> CODE_FOR_cbranchsi4_insn >> > in this case. This leads to ICE due to SET_SRC(label_insn) in subsequent >> > code. In general we should skip all such improper insns. This is the >> > purpose >> > of attached small patch. >> > >> > Some failures in recent gcc regression test on thumb1 target are caused by >> > this reason. So with this patch, all of them passed and no new failures. Is >> > it ok to trunk? >> > >> > BR, >> > Terry >> > >> > 2014-06-10 Terry Guo >> > >> > * config/arm/arm.c (thumb1_reorg): Move to next basic block if the >> head >> > of current basic block isn't a proper insn. >> > >> >> I think you should just test that "insn != BB_HEAD (bb)". The loop >> immediately above this deals with the !NON-DEBUG insns, so the logic is >> confusing the way you've written it. >> >> R. >> > > Thanks for comments. The patch is updated and tested. No more ICE. Is this > one OK? > > BR, > Terry Hi, The bug is also reported for 4.9 branch at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712 As far as I checked, the ICE is also caused by label instruction as in this message thread. Since the fix is on trunk more than two weeks, could we back port it to 4.9 branch? Thanks, bin
Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg
On 04/07/14 10:36, Bin.Cheng wrote: > On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo wrote: >> >> >>> -Original Message- >>> From: Richard Earnshaw >>> Sent: Wednesday, June 18, 2014 4:31 PM >>> To: Terry Guo >>> Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan >>> Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function >>> thumb1_reorg >>> >>> On 10/06/14 12:42, Terry Guo wrote: Hi There, The thumb1_reorg function use macro INSN_CODE to find expected >>> instructions. But the macro INSN_CODE doesn't work for label type instruction. The INSN_CODE(label_insn) will return the label number. When we have a lot >>> of labels and current label_insn is the first insn of basic block, the INSN_CODE(label_insn) could accidentally equal to >>> CODE_FOR_cbranchsi4_insn in this case. This leads to ICE due to SET_SRC(label_insn) in subsequent code. In general we should skip all such improper insns. This is the purpose of attached small patch. Some failures in recent gcc regression test on thumb1 target are caused by this reason. So with this patch, all of them passed and no new failures. Is it ok to trunk? BR, Terry 2014-06-10 Terry Guo * config/arm/arm.c (thumb1_reorg): Move to next basic block if the >>> head of current basic block isn't a proper insn. >>> >>> I think you should just test that "insn != BB_HEAD (bb)". The loop >>> immediately above this deals with the !NON-DEBUG insns, so the logic is >>> confusing the way you've written it. >>> >>> R. >>> >> >> Thanks for comments. The patch is updated and tested. No more ICE. Is this >> one OK? >> >> BR, >> Terry > > Hi, > The bug is also reported for 4.9 branch at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712 > As far as I checked, the ICE is also caused by label instruction as in > this message thread. > Since the fix is on trunk more than two weeks, could we back port it > to 4.9 branch? > > Thanks, > bin > Yes, unless an RM objects within 24 hours. R.
Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg
On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng wrote: > On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo wrote: >> >> >>> -Original Message- >>> From: Richard Earnshaw >>> Sent: Wednesday, June 18, 2014 4:31 PM >>> To: Terry Guo >>> Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan >>> Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function >>> thumb1_reorg >>> >>> On 10/06/14 12:42, Terry Guo wrote: >>> > Hi There, >>> > >>> > The thumb1_reorg function use macro INSN_CODE to find expected >>> instructions. >>> > But the macro INSN_CODE doesn't work for label type instruction. The >>> > INSN_CODE(label_insn) will return the label number. When we have a lot >>> of >>> > labels and current label_insn is the first insn of basic block, the >>> > INSN_CODE(label_insn) could accidentally equal to >>> CODE_FOR_cbranchsi4_insn >>> > in this case. This leads to ICE due to SET_SRC(label_insn) in subsequent >>> > code. In general we should skip all such improper insns. This is the >>> > purpose >>> > of attached small patch. >>> > >>> > Some failures in recent gcc regression test on thumb1 target are caused by >>> > this reason. So with this patch, all of them passed and no new failures. >>> > Is >>> > it ok to trunk? >>> > >>> > BR, >>> > Terry >>> > >>> > 2014-06-10 Terry Guo >>> > >>> > * config/arm/arm.c (thumb1_reorg): Move to next basic block if the >>> head >>> > of current basic block isn't a proper insn. >>> > >>> >>> I think you should just test that "insn != BB_HEAD (bb)". The loop >>> immediately above this deals with the !NON-DEBUG insns, so the logic is >>> confusing the way you've written it. >>> >>> R. >>> >> >> Thanks for comments. The patch is updated and tested. No more ICE. Is this >> one OK? >> >> BR, >> Terry > > Hi, > The bug is also reported for 4.9 branch at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712 > As far as I checked, the ICE is also caused by label instruction as in > this message thread. > Since the fix is on trunk more than two weeks, could we back port it > to 4.9 branch? Yes, since there have been no other issues reported. Can either of you also update PR61544 with the fields for Known to Work and Known to fail setting a target milestone of GCC 4.9.1 rather than leaving these fields empty. Ramana > > Thanks, > bin
Re: [patch 1/4] change specific int128 -> generic intN
> Setting TYPE_PRECISION is mostly useless, because most of gcc assumes > it's the same as TYPE_SIZE and ignores it. Then you need to change that and not TYPE_SIZE. > It seems to work just fine in testing, and I'm trying to make it > non-fundamental. I'm very skeptical... In any case, having a type whose TYPE_SIZE is smaller than the size of its MODE is a lie which will bite you back at some point. -- Eric Botcazou
Re: [PATCH] PR rtl-optimization/61712
On 04/07/14 05:59, lin zuojian wrote: > Hi, > This crash is due to fail to consider the exception situation that > the insn variable may not be a insn at all. > > arm.c (thumb1_reorg): if the > selected insn is not a insn, continue to next bb. > > --- > gcc/config/arm/arm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c > index 89684bb..50ae64b 100644 > --- a/gcc/config/arm/arm.c > +++ b/gcc/config/arm/arm.c > @@ -16720,7 +16720,7 @@ thumb1_reorg (void) > insn = PREV_INSN (insn); > >/* Find the last cbranchsi4_insn in basic block BB. */ > - if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn) > + if (!INSN_P (insn) || (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)) > continue; > >/* Get the register with which we are comparing. */ > This should be fixed the same way as it was on trunk. Bin's taking care of that. R.
Re: [patch 1/4] change specific int128 -> generic intN
> I don't doubt it, because I've been fighting these assumptions for years. The fight needs to be resumed/sped up, that's clearly the right thing to do. > Then please provide a "very good idea" for how to teach gcc about true > 20-bit types in a system with 8-bit memory and 16-bit words. TYPE_PRECISION was designed precisely for this purpose. -- Eric Botcazou
Re: [PATCH] PR rtl-optimization/61712
Thanks Richard, I didn't aware that patch. -- Lin Zuojian
[PATCH 01/09, nds32] Committed: Add several new files for preparation of providing modules that are going to be separated from nds32.c source.
Hi, This patch is the preparation for subsquent patches of modules implementation. In addition to create several empty source files, we also need to modify config.gcc and provide t-nds32 makefile fragment. Committed as Rev.212280. https://gcc.gnu.org/r212280 Best regards, jasonwucj
[PATCH 02/09, nds32] Committed: Move ISR impelentation to nds32-isr.c module.
Hi, There are many helper functions implemented in nds32.c to deal with interrupt service routine code generation. We move all of them into nds32-isr.c module. Committed as Rev.212281. https://gcc.gnu.org/r212281 Best regards, jasonwucj
[PATCH 03/09, nds32] Committed: Move builtin functions implementation to nds32-intrinsic.c module.
Hi, For supporting target specific builtin functions, we use an individual nds32-intrinsic.c module to implement essential and helpler functions. Committed as Rev.212282. https://gcc.gnu.org/r212282 Best regards, jasonwucj
[PATCH, aarch64] Correctly wire up --with-cpu and --with-arch (PR61714)
I noticed that although configure on aarch64 handles --with-arch and
--with-cpu, they aren't passed on to the compilation -- instead you just
get whatever the internal default is in the compiler back-end. This
patch fixes that by wiring up the missing logic.
2014-07-04 Richard Earnshaw
PR target/61714
* aarch64.h (OPTION_DEFAULT_SPECS): Define.
Applied to trunk. It's trivial enough that I'll probably back-port it
to 4.9 as well.
R.diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index b95365a..080b23f 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -879,6 +879,13 @@ extern enum aarch64_code_model aarch64_cmodel;
#define ENDIAN_LANE_N(mode, n) \
(BYTES_BIG_ENDIAN ? GET_MODE_NUNITS (mode) - 1 - n : n)
+/* Support for a configure-time default CPU, etc. We currently support
+ --with-arch and --with-cpu. Both are ignored if either is specified
+ explicitly on the command line at run time. */
+#define OPTION_DEFAULT_SPECS \
+ {"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" }, \
+ {"cpu", "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" },
+
#define BIG_LITTLE_SPEC \
" %{mcpu=*:-mcpu=%:rewrite_mcpu(%{mcpu=*:%*})}"
Re: [PATCH 01/09, nds32] Committed: Add several new files for preparation of providing modules that are going to be separated from nds32.c source.
2014-07-04 18:47 GMT+08:00 Chung-Ju Wu : > Hi, > > This patch is the preparation for subsquent patches of modules > implementation. In addition to create several empty source files, > we also need to modify config.gcc and provide t-nds32 makefile fragment. > > Committed as Rev.212280. > https://gcc.gnu.org/r212280 > Sorry I forgot to attach patch in the previous mail. Best regards, jasonwucj 0001-PATCH-01-Add-several-new-files-for-preparation-of-pr.patch Description: Binary data
Re: [PATCH 02/09, nds32] Committed: Move ISR impelentation to nds32-isr.c module.
2014-07-04 18:48 GMT+08:00 Chung-Ju Wu : > Hi, > > There are many helper functions implemented in nds32.c to > deal with interrupt service routine code generation. > We move all of them into nds32-isr.c module. > > Committed as Rev.212281. > https://gcc.gnu.org/r212281 > Sorry I forgot to attach patch in the previous mail. Best regards, jasonwucj 0002-PATCH-02-Move-ISR-impelentation-to-nds32-isr.c-modul.patch Description: Binary data
Re: [PATCH 03/09, nds32] Committed: Move builtin functions implementation to nds32-intrinsic.c module.
2014-07-04 18:50 GMT+08:00 Chung-Ju Wu : > Hi, > > For supporting target specific builtin functions, > we use an individual nds32-intrinsic.c module to implement > essential and helpler functions. > > Committed as Rev.212282. > https://gcc.gnu.org/r212282 > Sorry I forgot to attach patch in the previous mail. Best regards, jasonwucj 0003-PATCH-03-Move-builtin-functions-implementation-to-nd.patch Description: Binary data
[PATCH, aarch64] Add prefetch support
Hi, Attached is a patch that implements * Prefetch with immediate offset in the range 0 to 32760 (multiple of 8). Added a predicate for this. * Prefetch with immediate offset - in the range -256 to 255 (Gets generated only when we have a negative offset. Generates prfum instruction). Added a predicate for this. * Prefetch with register offset. (modified for printing the locality) This patch has been already discussed on https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01644.html "make -k check" passes. Ok for trunk? Changelog 2014-07-04 Ganesh Gopalasubramanian * config/aarch64/aarch64.md (define_insn "*prefetch") (define_insn "prefetch"): New * config/aarch64/predicates.md (aarch64_prefetch_pimm) (aarch64_prefetch_unscaled): New. * config/arm/types.md (define_attr "type"): Add prefetch. Regards Ganesh prefetch.diff Description: prefetch.diff
[PATCH 04/09, nds32] Committed: Move some helper functions of predicates and constraints to nds32-predicates.c module.
Hi, Many external functions are used in predicates and constraints checking. We move all of them into nds32-predicates.c module so that we can easily maintain those implementation in the future. Committed as Rev.212283. https://gcc.gnu.org/r212283 Best regards, jasonwucj 0004-PATCH-04-Move-some-helper-functions-of-predicates-an.patch Description: Binary data
[PATCH 05/09, nds32] Committed: Move cost calculation to nds32-cost.c module.
Hi, We provide a nds32-cost.c module to maintain some cost implementation required by target hooks and macros. Currently we only migrate nds32_rtx_costs() and nds32_address_cost() into the module. Committed as Rev.212284. https://gcc.gnu.org/r212284 Best regards, jasonwucj 0005-PATCH-05-Move-cost-calculation-to-nds32-cost.c-modul.patch Description: Binary data
[PATCH 06/09, nds32] Committed: Preparation of nds32-pipelines-auxiliary.c module for future implementation.
Hi, The module is prepared for future implementation of pipeline models. In this patch we only add a few comment to describe its purpose. Committed as Rev.212285. https://gcc.gnu.org/r212285 Best regards, jasonwucj 0006-PATCH-06-Preparation-of-nds32-pipelines-auxiliary.c-.patch Description: Binary data
[PATCH 08/09, nds32] Committed: Move memory related implementation to nds32-memory-manipulation.c module.
Hi, The multiple load/store instructions are provided by nds32 target and some memory access behaviors are able to utilize such instuctions. We use nds32-memory-manipulation.c module to hold those memory related implementation. Committed as Rev.212287. https://gcc.gnu.org/r212287 Best regards, jasonwucj 0008-PATCH-08-Move-memory-related-implementation-to-nds32.patch Description: Binary data
[PATCH 09/09, nds32] Committed: Move fp-as-gp optimization to nds32-fp-as-gp.c module.
Hi, There is a target specific optimization, called fp-as-gp optimization, in the nds32 port. We are planning to make it as an individual pass. By now we just move related implementation into nds32-fp-as-gp.c module. Committed as Rev.212288. https://gcc.gnu.org/r212288 Best regards, jasonwucj 0009-PATCH-09-Move-fp-as-gp-optimization-to-nds32-fp-as-g.patch Description: Binary data
[PATCH 00/09, nds32] Provide individual modules as assistance to nds32.c implementation.
Hi, all, In the nds32 port, we are expecting the implementation in nds32.c is going to gradually grow up. For the sake of future maintenance, we decide to provide individual modules and then migrate some implementation from nds32.c into the modules. The following is a series of patches: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00293.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00295.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00296.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00298.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00299.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00300.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00301.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00302.html https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00303.html I would like to thank Kito, Monk, and Ling-Hua, to help me separate the nds32.c content. So I also list them as contributors in the ChangeLog. Thank you all, and we are looking forward to have more patches to make nds32 port better. Best regards, jasonwucj
Re: [PATCH, x86] Improves x86 permutation expand
On Thu, Jul 3, 2014 at 10:57 AM, Evgeny Stupachenko wrote: > The following patch should fix 61618 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 8046c67..2cffcef 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -43211,12 +43211,10 @@ expand_vec_perm_pblendv (struct expand_vec_perm_d > *d) >bool ok; > >/* Use the same checks as in expand_vec_perm_blend, but skipping > - AVX2 as it requires more than 2 instructions for general case. */ > + AVX float case and AVX2 as they require more than 2 instructions. */ >if (d->one_operand_p) > return false; > - if (TARGET_AVX && (vmode == V4DFmode || vmode == V8SFmode)) > -; > - else if (TARGET_SSE4_1 && GET_MODE_SIZE (vmode) == 16) > + if (TARGET_SSE4_1 && GET_MODE_SIZE (vmode) == 16) > ; >else > return false; ChangeLog entry is missing. Uros.
Re: [PATCH 1/2, x86] Add palignr support for AVX2.
On Thu, Jul 3, 2014 at 11:53 AM, Evgeny Stupachenko wrote: > The "expand_vec_perm_palignr" is similar for SSSE3 and AVX2 cases, > but AVX2 requires more instructions to complete the scheme. > > The patch below adds AVX2 support for six instructions, leaving SSSE3 for two. > Is it ok? ChangeLog entry is missing. Uros.
Re: Porting libsanitizer to Solaris (Was: Re: [PATCH][Revised] Enable libsanitizer on darwin)
Hi Rainer, All contributions to libsanitizer should go via LLVM repository. See https://code.google.com/p/address-sanitizer/wiki/HowToContribute The smaller the patches the faster they will come through. If you can set up a public build bot it will *immensely* simplify many things. (see more below) On Fri, Jul 4, 2014 at 3:47 PM, Rainer Orth wrote: > Hi Alex, > >> The quick answer is no, although the expansion into GCC world may >> require such a guideline. >> We've initially implemented ASan on Linux and then ported it to >> Android (which is very similar to Linux) and Mac (which is very >> different), so we have little experience with porting yet. >> I've summarized the differences between Linux and Mac here: >> https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails >> >> The core things to pay attention at are function wrapping (e.g. dlsym >> on Linux, mach_override on Mac), hooking the allocations/deallocations >> in the program, stack unwinding (already done for x86 and ARM), thread >> creation, early initialization, debug info and symbolization. Maybe >> something else. In fact if any of these points work on your platform >> differently than they do on Linux/Mac, you'll have to re-implement >> those. >> >> Regarding mach_override, it's a Mac OS-specific thing that we use >> because dlsym doesn't reliably override functions (keywords: two-level >> namespace) >> This only works on x86/x86_64 and is just a bunch of ad-hoc hacks to >> hot-patch the library code. >> Extending the instruction table in mach_override.c is irrelevant to >> porting, it's just a mean of making it work with some newer libraries >> provided by Apple. >> It won't work on any other OS (well, without some refactoring; in fact >> it's possible to use it on Linux) or any other arch (one could rewrite >> mach_override.c for ARM, but iOS doesn't allow code patching). >> >> I'm working on a replacement for mach_override, which will compile >> libasan as a dynamic library on Mac OS and preload it before running >> the program. >> It's not ready yet, so the easiest thing for GCC will be to add some >> more instructions to mach_override and stick to it for now. > > Thanks for those hints. After a first start at a Solaris port of > libsanitizer when it was first integrated into the GCC tree, I've now > made very good progress. > > I'm now down to just a few testsuite failures on Solaris 11.2 Beta: > > * g++, 32-bit: > > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/swapcontext-test-1.c > g++.dg/asan/deep-tail-call-1.C > > * g++, 64-bit: > > c-c++-common/asan/global-overflow-1.c > c-c++-common/asan/heap-overflow-1.c > c-c++-common/asan/memcmp-1.c > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/pr61530.c > c-c++-common/asan/rlimit-mmap-test-1.c > c-c++-common/asan/sanity-check-pure-c-1.c > c-c++-common/asan/sleep-before-dying-1.c > c-c++-common/asan/stack-overflow-1.c > c-c++-common/asan/strip-path-prefix-1.c > c-c++-common/asan/strlen-overflow-1.c > c-c++-common/asan/strncpy-overflow-1.c > c-c++-common/asan/swapcontext-test-1.c > c-c++-common/asan/use-after-free-1.c > c-c++-common/asan/use-after-return-1.c > g++.dg/asan/deep-stack-uaf-1.C > g++.dg/asan/deep-tail-call-1.C > g++.dg/asan/deep-thread-stack-1.C > g++.dg/asan/default-options-1.C > g++.dg/asan/interception-failure-test-1.C > g++.dg/asan/interception-test-1.C > g++.dg/asan/large-func-test-1.C > g++.dg/asan/pr55617.C > c-c++-common/ubsan/float-cast-overflow-2.c > c-c++-common/ubsan/float-cast-overflow-4.c > > * gcc, 32-bit: > > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/swapcontext-test-1.c > > * gcc, 64-bit: > > c-c++-common/asan/global-overflow-1.c > c-c++-common/asan/heap-overflow-1.c > c-c++-common/asan/memcmp-1.c > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/pr61530.c > c-c++-common/asan/rlimit-mmap-test-1.c > c-c++-common/asan/sanity-check-pure-c-1.c > c-c++-common/asan/sleep-before-dying-1.c > c-c++-common/asan/stack-overflow-1.c > c-c++-common/asan/strip-path-prefix-1.c > c-c++-common/asan/strlen-overflow-1.c > c-c++-common/asan/strncpy-overflow-1.c > c-c++-common/asan/swapcontext-test-1.c > c-c++-common/asan/use-after-free-1.c > c-c++-common/asan/use-after-return-1.c > gcc.dg/asan/nosanitize-and-inline.c > c-c++-common/ubsan/float-cast-overflow-2.c > c-c++-common/ubsan/float-cast-overflow-4.c > > That's not too bad, I believe, and the 64-bit failures seem to be mostly > due to a single error. > > The question is how best to proceed from here. I'm attaching the > current patch for reference, though it's far from ready for submission
Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro
Hello Nicholas, Nicholas Ormrod writes: > I found time this morning to run your changes through our system. I > patched our gcc-4.8.1 with your latest change, and ran it through our > folly testsuite. Thanks! > One thing that I immediately noticed was that this increased the preprocessed > size substantially. > When preprocessing my favorite .cpp file, its .ii grew from 137k lines > to 145k, a 5% increase. Yeah, the growth is expected. It's interesting to have actual numbers, thank you for that. > All the folly code compiled and ran successfully under the changes. > > I looked at some of the preprocessed output. I was pleased to see that > consecutive macros that expanded entirely to system tokens did not > insert unnecessary line directives between them. Cool! > I did, however, notice that __LINE__ was treated as belonging to the > calling file, even when its token appears in the system file. That is > to say: > > CODE: > > // system macro > #define FOO() sys_token __LINE__ sys_token > > // non-system callsite > FOO() > > // preprocessed output > # 3 "test.cpp" 3 4 > sys_token > # 3 "test.cpp" > 3 > # 3 "test.cpp" 3 4 > sys_token > > :CODE Yeah. For Built-in tokens that are expanded like that we only do track their the location of their expansion, not their spelling location. So this behaviour is expected as well. > This seems to generalize to other builtin macros, like __FILE__. Indeed. > > Otherwise, the code looks fine. There is only one thing I noticed: > >> + if (do_line_adjustments >> + && !in_pragma >> + && !line_marker_emitted >> + && print.prev_was_system_token != !!in_system_header_at(loc)) >> + /* The system-ness of this token is different from the one >> + of the previous token. Let's emit a line change to >> + mark the new system-ness before we emit the token. */ >> + line_marker_emitted = do_line_change (pfile, token, loc, false); > > This line_marker_emitted assignment is immediately overwritten, two lines > below. However, from a > maintainability perspective, this is probably a good assignment to > keep. Yeah, maintainability is why I kept it. But if the maintainers feel strongly about it I can, certainly just remove that assignment. Thank you for your time on this! Cheers. -- Dodji
RE: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly
> -Original Message-
> From: Bin.Cheng [mailto:amker.ch...@gmail.com]
> Sent: Wednesday, July 02, 2014 1:46 PM
> To: Ramana Radhakrishnan
> Cc: Bin Cheng; Richard Earnshaw; gcc-patches
> Subject: Re: [PATCH ARM]Handle REG addressing mode in
> output_move_neon explicitly
>
> On Wed, Jul 2, 2014 at 7:48 AM, Ramana Radhakrishnan
> wrote:
> > On Mon, May 5, 2014 at 8:21 AM, bin.cheng wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Richard Earnshaw
> >>> Sent: Thursday, May 01, 2014 10:03 PM
> >>> To: Bin Cheng
> >>> Cc: gcc-patches@gcc.gnu.org
> >>> Subject: Re: [PATCH ARM]Handle REG addressing mode in
> >>> output_move_neon explicitly
> >>>
> >>> On 29/04/14 04:02, bin.cheng wrote:
> >>> > Hi,
> >>> > Function output_move_neon now generates vld1.64 for memory ref
> >>> > like "dx <- [r1:SI]", this is bogus because it requires at least
> >>> > 64-bit alignment for 32-bit aligned memory ref. It works now
> >>> > because GCC doesn't generate such insns in the first place, but
> >>> > things are going to change if memset/memcpy calls are inlined by
using
> neon instructions.
> >>> >
> >>>
> >>> V[LD/ST]1.64 only need to be 64-bit aligned if strict alignment is
> >> enabled. We
> >>> normally assume that not to be the case. The exception to this is
> >>> when an
> >> theoretically, this doesn't make the problem go away, right?
> >>
> >>> explicit alignment check is used in the address expression (the :64
> >> suffix),
> >>> which causes the address to be checked for strict alignment at all
times.
> >>>
> >>> Do you have a testcase?
> >> I can't provide a test case without the memset inlining patch.
> >>
> > Are the tests in the memset inlining patch now sufficient to expose
> > the problem or do we need another test ?
>
> Yes, it's covered by the 4th/7th test cases in memset inlining patch.
>
This is the rebased patch, though the original one doesn't conflict with
latest trunk. Is it OK?
Thanks,
binIndex: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 212295)
+++ gcc/config/arm/arm.c(working copy)
@@ -18454,6 +18498,20 @@ output_move_neon (rtx *operands)
/* FIXME: Not currently enabled in neon_vector_mem_operand. */
gcc_unreachable ();
+case REG:
+ /* We have to use vldm / vstm for too-large modes. */
+ if (nregs > 1)
+ {
+ if (nregs > 4)
+ templ = "v%smia%%?\t%%m0, %%h1";
+ else
+ templ = "v%s1.64\t%%h1, %%A0";
+
+ ops[0] = mem;
+ ops[1] = reg;
+ break;
+ }
+ /* Fall through. */
case LABEL_REF:
case PLUS:
{
@@ -18487,14 +18545,7 @@ output_move_neon (rtx *operands)
}
default:
- /* We have to use vldm / vstm for too-large modes. */
- if (nregs > 4)
- templ = "v%smia%%?\t%%m0, %%h1";
- else
- templ = "v%s1.64\t%%h1, %%A0";
-
- ops[0] = mem;
- ops[1] = reg;
+ gcc_unreachable ();
}
sprintf (buff, templ, load ? "ld" : "st");
Re: Porting libsanitizer to Solaris
Hi Konstantin, > All contributions to libsanitizer should go via LLVM repository. > See https://code.google.com/p/address-sanitizer/wiki/HowToContribute > The smaller the patches the faster they will come through. ok. I'll see how to split up the patches. Some parts are completely trivial in that they treat Solaris exactly like Linux and FreeBSD. I believe they could go in incrementally since they won't hurt other ports, even if they don't enable the Solaris port yet until the last step. > If you can set up a public build bot it will *immensely* simplify many things. > (see more below) I fear this is going to be difficult: I don't have such a thing even for GCC, and fighting with the buildbot software itself, another unfamiliar build system (cmake has been my nemesis in the past) and a compiler that doesn't even support Solaris (LLVM/Clang) is way more than I can spend on this. That's why I asked in the past why the libsanitizer maintainers cannot act as liaisons between GCC (OS port maintainers primarily) and LLVM/Compiler-RT, like Ian does for Go, to relieve the burden of working in yet another `world'. I do regular (once a week usually) GCC bootstraps on Solaris, so I will notice libsanitizer breakage relatively quickly. >> A few random observations about the port: >> >> * From a porting point, I find it nightmarish that libsanitizer is >> completely platform-based (SANITIZER_ all over the place) >> rather than feature-based (HAVE_, irrespective of how the >> features are detected). > > I don't enjoy the current situation. > Any help here is welcome, but testing any such change might be complicated, > especially for platforms which don't have public buildbots :( Agreed, but even in the GCC world, due diligence is considered enough: test on a couple of common platforms and let the port maintainers deal with the breakage if any. Not ideal but certainly better than delaying cleanup work forever. Maybe I can come up with some suggestions when the Solaris port finishes. >> * Even this is not consistent: many places use SANITIZER_, >> others still __linux__/__FreeBSD__/... > > Again, patches are more than welcome to get rid of __linux__/__FreeBSD__/... Good. I may well do this as preparatory patches for the Solaris port proper to make several parts cleaner (SANITIZER_SOLARIS is at least a bit more readable than (defined(__sun__) && defined(__svr4__)) ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 1/2, x86] Add palignr support for AVX2.
2014-07-04 Evgeny Stupachenko * config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2 PALINGR instruction. * config/i386/i386.c (ix86_expand_vec_perm_const_1): Add palignr try for AVX2. On Fri, Jul 4, 2014 at 3:22 PM, Uros Bizjak wrote: > On Thu, Jul 3, 2014 at 11:53 AM, Evgeny Stupachenko > wrote: >> The "expand_vec_perm_palignr" is similar for SSSE3 and AVX2 cases, >> but AVX2 requires more instructions to complete the scheme. >> >> The patch below adds AVX2 support for six instructions, leaving SSSE3 for >> two. >> Is it ok? > > ChangeLog entry is missing. > > Uros.
Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg
On Fri, Jul 4, 2014 at 10:44 AM, Ramana Radhakrishnan wrote: > On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng wrote: >> On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo wrote: >>> >>> -Original Message- From: Richard Earnshaw Sent: Wednesday, June 18, 2014 4:31 PM To: Terry Guo Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg On 10/06/14 12:42, Terry Guo wrote: > Hi There, > > The thumb1_reorg function use macro INSN_CODE to find expected instructions. > But the macro INSN_CODE doesn't work for label type instruction. The > INSN_CODE(label_insn) will return the label number. When we have a lot of > labels and current label_insn is the first insn of basic block, the > INSN_CODE(label_insn) could accidentally equal to CODE_FOR_cbranchsi4_insn > in this case. This leads to ICE due to SET_SRC(label_insn) in subsequent > code. In general we should skip all such improper insns. This is the > purpose > of attached small patch. > > Some failures in recent gcc regression test on thumb1 target are caused > by > this reason. So with this patch, all of them passed and no new failures. > Is > it ok to trunk? > > BR, > Terry > > 2014-06-10 Terry Guo > > * config/arm/arm.c (thumb1_reorg): Move to next basic block if the head > of current basic block isn't a proper insn. > I think you should just test that "insn != BB_HEAD (bb)". The loop immediately above this deals with the !NON-DEBUG insns, so the logic is confusing the way you've written it. R. >>> >>> Thanks for comments. The patch is updated and tested. No more ICE. Is this >>> one OK? >>> >>> BR, >>> Terry >> >> Hi, >> The bug is also reported for 4.9 branch at >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712 >> As far as I checked, the ICE is also caused by label instruction as in >> this message thread. >> Since the fix is on trunk more than two weeks, could we back port it >> to 4.9 branch? > > Yes, since there have been no other issues reported. Can either of you > also update PR61544 with the fields for Known to Work and Known to > fail setting a target milestone of GCC 4.9.1 rather than leaving these > fields empty. Done, I will back port it to 4.9 branch after 24 hours window. Hopefully we can catch with 4.9.1 release. Thanks, bin
Re: [PATCH, x86] Improves x86 permutation expand
2014-07-04 Evgeny Stupachenko * config/i386/i386.c (expand_vec_perm_pblendv): Disable for AVX. On Fri, Jul 4, 2014 at 3:20 PM, Uros Bizjak wrote: > On Thu, Jul 3, 2014 at 10:57 AM, Evgeny Stupachenko > wrote: >> The following patch should fix 61618 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c >> index 8046c67..2cffcef 100644 >> --- a/gcc/config/i386/i386.c >> +++ b/gcc/config/i386/i386.c >> @@ -43211,12 +43211,10 @@ expand_vec_perm_pblendv (struct expand_vec_perm_d >> *d) >>bool ok; >> >>/* Use the same checks as in expand_vec_perm_blend, but skipping >> - AVX2 as it requires more than 2 instructions for general case. */ >> + AVX float case and AVX2 as they require more than 2 instructions. */ >>if (d->one_operand_p) >> return false; >> - if (TARGET_AVX && (vmode == V4DFmode || vmode == V8SFmode)) >> -; >> - else if (TARGET_SSE4_1 && GET_MODE_SIZE (vmode) == 16) >> + if (TARGET_SSE4_1 && GET_MODE_SIZE (vmode) == 16) >> ; >>else >> return false; > > ChangeLog entry is missing. > > Uros.
Re: Porting libsanitizer to Solaris
On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth wrote: > Hi Konstantin, > >> All contributions to libsanitizer should go via LLVM repository. >> See https://code.google.com/p/address-sanitizer/wiki/HowToContribute >> The smaller the patches the faster they will come through. > > ok. I'll see how to split up the patches. Some parts are completely > trivial in that they treat Solaris exactly like Linux and FreeBSD. I > believe they could go in incrementally since they won't hurt other > ports, even if they don't enable the Solaris port yet until the last > step. > >> If you can set up a public build bot it will *immensely* simplify many >> things. >> (see more below) > > I fear this is going to be difficult: I don't have such a thing even for > GCC, and fighting with the buildbot software itself, another unfamiliar > build system (cmake has been my nemesis in the past) and a compiler that > doesn't even support Solaris (LLVM/Clang) is way more than I can spend > on this. You don't have to fight with Clang on Solaris, and maybe not even with cmake. Recently we tried hard to make tests in compiler-rt become compiler-independent -- you can now run most of the asan tests in compiler-rt with any compiler that supports -fsanitize=address. https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerTestSuite So you'll need to checkout only the compiler-rt svn and test it against a compiler of your choice (e.g. gcc trunk) BTW, I really want to change our current scheme of merging sanitizer sources to gcc -- to use 'svn external' or some such instead of maintaining a copy. cmake support should be trivial and we will be able to help. > That's why I asked in the past why the libsanitizer > maintainers cannot act as liaisons between GCC (OS port maintainers > primarily) and LLVM/Compiler-RT, like Ian does for Go, to relieve the We do it to some extent. But we are not Ian and sanitizers are *much* more platform-dependent than Go. --kcc > burden of working in yet another `world'. I do regular (once a week > usually) GCC bootstraps on Solaris, so I will notice libsanitizer > breakage relatively quickly. > >>> A few random observations about the port: >>> >>> * From a porting point, I find it nightmarish that libsanitizer is >>> completely platform-based (SANITIZER_ all over the place) >>> rather than feature-based (HAVE_, irrespective of how the >>> features are detected). >> >> I don't enjoy the current situation. >> Any help here is welcome, but testing any such change might be complicated, >> especially for platforms which don't have public buildbots :( > > Agreed, but even in the GCC world, due diligence is considered enough: > test on a couple of common platforms and let the port maintainers deal > with the breakage if any. Not ideal but certainly better than delaying > cleanup work forever. > > Maybe I can come up with some suggestions when the Solaris port > finishes. > >>> * Even this is not consistent: many places use SANITIZER_, >>> others still __linux__/__FreeBSD__/... >> >> Again, patches are more than welcome to get rid of __linux__/__FreeBSD__/... > > Good. I may well do this as preparatory patches for the Solaris port > proper to make several parts cleaner (SANITIZER_SOLARIS is at least a > bit more readable than (defined(__sun__) && defined(__svr4__)) ;-) > > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [GSoC] Addition of ISL AST generation to Graphite
Roman Gareev writes: >> It seems the patch1/patch2 files you attach have the Content-Type: >> application/octet-stream. This makes it impossible to view them inline. >> Could you send them as text files? Just calling them patch1.patch or >> patch1.txt should make this work. > > Yes, sure. This patch broke bootstrap with --enable-cloog-backend=isl when using isl 0.10: /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:27:27: fatal error: isl/ast_build.h: No such file or directory compilation terminated. make[3]: *** [graphite-isl-ast-to-gimple.o] Error 1 is missing in in isl 0.10. Seems it was introduced in 0.11, but no idea if that works. Toplevel configure.ac accepts 0.10, while install.texi states 0.12.2 is required. Configuration and/or docs should be changed to match reality. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, x86] Improves x86 permutation expand
On Fri, Jul 4, 2014 at 2:49 PM, Evgeny Stupachenko wrote: > 2014-07-04 Evgeny Stupachenko > > * config/i386/i386.c (expand_vec_perm_pblendv): Disable for AVX. Please mention PR target/61618 above. >>> The following patch should fix 61618 >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 >>> >>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c >>> index 8046c67..2cffcef 100644 >>> --- a/gcc/config/i386/i386.c >>> +++ b/gcc/config/i386/i386.c >>> @@ -43211,12 +43211,10 @@ expand_vec_perm_pblendv (struct expand_vec_perm_d >>> *d) >>>bool ok; >>> >>>/* Use the same checks as in expand_vec_perm_blend, but skipping >>> - AVX2 as it requires more than 2 instructions for general case. */ >>> + AVX float case and AVX2 as they require more than 2 instructions. */ Just say: AVX and AVX2, as they require ... OK with these changes. Uros.
Re: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly
>> > This is the rebased patch, though the original one doesn't conflict with > latest trunk. Is it OK? Ok. Ramana > > Thanks, > bin
[PATCH, COMMITTED] Update earlyclobber documentation
[ was: Re: combination of read/write and earlyclobber constraint modifier on
gcc@ ]
On 03-07-14 00:42, Jeff Law wrote:
Based on various followups (public & private), let's go with the clarification
above. Richard E. explicitly added support for this in the mid/late 90s as an
optimization for the ARM.
Jeff,
Committed as attached.
Thanks to all for the helpful comments.
- Tom
2014-07-04 Tom de Vries
* doc/md.texi (@subsection Constraint Modifier Characters): Clarify
combination of earlyclobber and read/write modifiers.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 539865e..fde67d7 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1582,7 +1582,10 @@ alternatives of this form often allows GCC to produce better code
when only some of the inputs can be affected by the earlyclobber.
See, for example, the @samp{mulsi3} insn of the ARM@.
-@samp{&} does not obviate the need to write @samp{=}.
+Furthermore, if the @dfn{earlyclobber} operand is also read/write operand, then
+that operand is modified only after it's used.
+
+@samp{&} does not obviate the need to write @samp{=} or @samp{+}.
@cindex @samp{%} in constraint
@item %
--
1.9.1
[PATCH 4.9][AArch64][testsuite] Backport r211502: PR/59843 Fix ICE on singleton vector of float on AArch64
No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf, arm-none-eabi, x86_64-unknown-linux-gnu: NA->PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20) NA->PASS gcc.dg/vect/vect-singleton_1.c (test for excess errors) gcc/ChangeLog: * config/aarch64/aarch64-modes.def: Add V1DFmode. * config/aarch64/aarch64.c (aarch64_vector_mode_supported_p): Support V1DFmode. gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-singleton_1.c: New file.
[wwwdocs] Make git/gitweb_config.perl use https
Applied. Gerald Index: git/gitweb_config.perl === RCS file: /cvs/gcc/wwwdocs/htdocs/git/gitweb_config.perl,v retrieving revision 1.1 diff -u -r1.1 gitweb_config.perl --- git/gitweb_config.perl 18 Mar 2008 02:07:15 - 1.1 +++ git/gitweb_config.perl 4 Jul 2014 14:10:54 - @@ -7,6 +7,6 @@ @git_base_url_list = (qw(git://gcc.gnu.org/git ssh://gcc.gnu.org/git - http://gcc.gnu.org/git)); + https://gcc.gnu.org/git)); $projects_list = "$projectroot/gitweb-project-list";
Re: [PATCH 4.9][AArch64][testsuite] Backport r211502: PR/59843 Fix ICE on singleton vector of float on AArch64
Patch here.
Alan Lawrence wrote:
No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf,
arm-none-eabi, x86_64-unknown-linux-gnu:
NA->PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20)
NA->PASS gcc.dg/vect/vect-singleton_1.c (test for excess errors)
gcc/ChangeLog:
* config/aarch64/aarch64-modes.def: Add V1DFmode.
* config/aarch64/aarch64.c (aarch64_vector_mode_supported_p):
Support V1DFmode.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-singleton_1.c: New file.
diff --git a/gcc/config/aarch64/aarch64-modes.def b/gcc/config/aarch64/aarch64-modes.def
index 1d2cc76..f9c4369 100644
--- a/gcc/config/aarch64/aarch64-modes.def
+++ b/gcc/config/aarch64/aarch64-modes.def
@@ -31,6 +31,7 @@ VECTOR_MODES (INT, 8);/* V8QI V4HI V2SI. */
VECTOR_MODES (INT, 16); /* V16QI V8HI V4SI V2DI. */
VECTOR_MODES (FLOAT, 8); /* V2SF. */
VECTOR_MODES (FLOAT, 16); /*V4SF V2DF. */
+VECTOR_MODE (FLOAT, DF, 1); /* V1DF. */
/* Oct Int: 256-bit integer mode needed for 32-byte vector arguments. */
INT_MODE (OI, 32);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4838498..bf35031 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6307,7 +6307,8 @@ aarch64_vector_mode_supported_p (enum machine_mode mode)
|| mode == V16QImode || mode == V2DImode
|| mode == V2SImode || mode == V4HImode
|| mode == V8QImode || mode == V2SFmode
- || mode == V4SFmode || mode == V2DFmode))
+ || mode == V4SFmode || mode == V2DFmode
+ || mode == V1DFmode))
return true;
return false;
diff --git a/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c b/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c
new file mode 100644
index 000..6c2ff49
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c
@@ -0,0 +1,38 @@
+/* PR target/59843 ICE on function taking/returning vector of one float64_t. */
+
+/* { dg-do compile } */
+/* { dg-options "-Warray-bounds -O2 -fno-inline -std=c99" } */
+
+#define TEST(BASETYPE, VECTYPE, SUFFIX) \
+ typedef BASETYPE VECTYPE \
+ __attribute__ ((__vector_size__ (sizeof (BASETYPE; \
+ VECTYPE \
+ test_vadd_##SUFFIX (VECTYPE a, VECTYPE b) \
+ { \
+return a + b; \
+ } \
+ \
+ void \
+ test_##SUFFIX (BASETYPE val) \
+ { \
+VECTYPE var = { val }; \
+BASETYPE v0 = var[0]; \
+BASETYPE v1 = var[1]; /* { dg-warning "index value is out of bound" } */ \
+ }
+
+TEST (double, float64x1_t, f64)
+
+/* Original bug was for above type;
+ in a nod to completeness, test other types too. */
+
+TEST (long long, int64x1_t, s64)
+
+TEST (float, float32x1_t, f32)
+
+TEST (long, longx1_t, l)
+
+TEST (int, intx1_t, i)
+
+TEST (short, int16x1_t, s16)
+
+TEST (char, int8x1_t, s8)
Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.
On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:
> +/* Internal scalar builtin types. These types are used to support
> + neon intrinsic builtins. They are _not_ user-visible types. Therefore
> + the mangling for these types are implementation defined. */
> +const char *aarch64_scalar_builtin_types[] = {
> + "__builtin_aarch64_simd_qi",
> + "__builtin_aarch64_simd_hi",
> + "__builtin_aarch64_simd_si",
> + "__builtin_aarch64_simd_sf",
> + "__builtin_aarch64_simd_di",
> + "__builtin_aarch64_simd_df",
> + "__builtin_aarch64_simd_poly8",
> + "__builtin_aarch64_simd_poly16",
> + "__builtin_aarch64_simd_poly64",
> + "__builtin_aarch64_simd_poly128",
> + "__builtin_aarch64_simd_ti",
> + "__builtin_aarch64_simd_uqi",
> + "__builtin_aarch64_simd_uhi",
> + "__builtin_aarch64_simd_usi",
> + "__builtin_aarch64_simd_udi",
> + "__builtin_aarch64_simd_ei",
> + "__builtin_aarch64_simd_oi",
> + "__builtin_aarch64_simd_ci",
> + "__builtin_aarch64_simd_xi",
> + NULL
> +};
> +static const char *
> +aarch64_mangle_builtin_scalar_type (const_tree type)
> +{
> + int i = 0;
> +
> + while (aarch64_scalar_builtin_types[i] != NULL)
> {
> - default:
> - eltype = aarch64_build_scalar_type (GET_MODE_INNER (mode),
> - unsigned_p, poly_p);
> - return build_vector_type_for_mode (eltype, mode);
> - break;
> - VECTOR_TYPES
> - }
> + const char *name = aarch64_scalar_builtin_types[i];
> +
> + if (TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
> + && DECL_NAME (TYPE_NAME (type))
> + && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), name))
> + return aarch64_scalar_builtin_types[i];
> + i++;
> +}
> + return NULL;
> }
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 3ed8a98..50d294e 100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -32,66 +32,45 @@
> +typedef __Poly8_t poly8_t;
> +typedef __Poly16_t poly16_t;
> +typedef __Poly64_t poly64_t;
> +typedef __Poly128_t poly128_t;
This looks wrong to me. The type which eventually becomes poly8_t in
arm_neon.h has "__Poly8_t" as its internal type name.
When you go through the loop in aarch64_mangle_builtin_scalar_type you'll
be checking in aarch64_scalar_builtin_types for a string matching
"__Poly8_t" and won't find it, so we'll end up with default mangling for this
type.
One question I have is, if for all the backend types we define we want the
mangled name to be:
then why do we not just return that and save the string comparisons?
I can see some argument for future flexibility, but in that case we will need
to rewrite this code anyway. Is there some other hole in my reasoning?
Thanks,
James
[PATCH][Ping v3] Add patch for debugging compiler ICEs
Ping.
Original Message
Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs
Date: Thu, 26 Jun 2014 19:46:08 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, Maxim Ostapenko
Ping.
Original Message
Subject:[PATCH][Ping] Add patch for debugging compiler ICEs
Date: Wed, 11 Jun 2014 18:15:27 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com
Ping.
Original Message
Subject:[PATCH] Add patch for debugging compiler ICEs
Date: Mon, 02 Jun 2014 19:21:14 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Yury Gribov , Slava Garbuzov
, Jakub Jelinek ,
tsaund...@mozilla.com, chefm...@gmail.com
Hi,
A years ago there was a discussion
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch wasn't
applied to trunk.
This is the resurrected patch with added GCC version information into generated
repro file.
-Maxim
2014-06-02 Jakub Jelinek
Max Ostapenko
* diagnostic.c (diagnostic_action_after_output): Exit with
ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
* gcc.c (execute): Don't free first string early, but at the end
of the function. Call retry_ice if compiler exited with
ICE_EXIT_CODE.
(main): Factor out common code.
(print_configuration): New function.
(try_fork): Likewise.
(redirect_stdout_stderr): Likewise.
(files_equal_p): Likewise.
(check_repro): Likewise.
(run_attempt): Likewise.
(generate_preprocessed_code): Likewise.
(append_text): Likewise.
(try_generate_repro): Likewise.
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 0cc7593..67b8c5b 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
real_abort ();
diagnostic_finish (context);
fnotice (stderr, "compilation terminated.\n");
- exit (FATAL_EXIT_CODE);
+ exit (ICE_EXIT_CODE);
default:
gcc_unreachable ();
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 9ac18e6..86dce03 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec". */
#include "params.h"
#include "vec.h"
#include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
/* By default there is no special suffix for target executables. */
/* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
static const char *convert_filename (const char *, int, int);
#endif
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
static const char *getenv_spec_function (int, const char **);
static const char *if_exists_spec_function (int, const char **);
static const char *if_exists_else_spec_function (int, const char **);
@@ -2797,7 +2807,7 @@ execute (void)
}
}
- if (string != commands[i].prog)
+ if (i && string != commands[i].prog)
free (CONST_CAST (char *, string));
}
@@ -2850,6 +2860,16 @@ execute (void)
else if (WIFEXITED (status)
&& WEXITSTATUS (status) >= MIN_FATAL_STATUS)
{
+#ifdef RETRY_ICE_SUPPORTED
+ /* For ICEs in cc1, cc1obj, cc1plus see if it is
+ reproducible or not. */
+ const char *p;
+ if (WEXITSTATUS (status) == ICE_EXIT_CODE
+ && i == 0
+ && (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+ && ! strncmp (p + 1, "cc1", 3))
+ try_generate_repro (commands[0].prog, commands[0].argv);
+#endif
if (WEXITSTATUS (status) > greatest_status)
greatest_status = WEXITSTATUS (status);
ret_code = -1;
@@ -2907,6 +2927,9 @@ execute (void)
}
}
+ if (commands[0].argv[0] != commands[0].prog)
+ free (CONST_CAST (char *, commands[0].argv[0]));
+
return ret_code;
}
}
@@ -6098,6 +6121,342 @@ give_switch (int switchnum, int omit_first_word)
switches[switchnum].validated = true;
}
+static void
+print_configuration (void)
+{
+ int n;
+ const char *thrmod;
+
+ fnotice (stderr, "Target: %s\n", spec_machine);
+ fnotice (stderr, "Configured with: %s\n", configuration_arguments);
+
+#ifdef THREAD_MODEL_SPEC
+ /* We could have defined THREAD_MODEL_SPEC to "%*" by default,
+ but there's no point in doing all this processing just to get
+ thread_model back. */
+ obstack_init (&obstack);
+ do_spec_1 (THREAD_MODEL_SPEC, 0, thread_model);
+ obstack_1grow (&obstack, '\0');
+ thrmod = XOBFINISH (&obstack, const char *);
+#else
+ thrmod = thread_model;
+#endif
+
+ fnotice (stderr, "Threa
Re: [Patch AArch64_be] Fix some vec_concat big-endian confusions
On 24 June 2014 09:45, James Greenhalgh wrote: > 2014-06-20 James Greenhalgh > > * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): New. > (move_lo_quad_internal_be_): Likewise. > (move_lo_quad_): Convert to define_expand. > (aarch64_simd_move_hi_quad_): Gate on BYTES_BIG_ENDIAN. > (aarch64_simd_move_hi_quad_be_): New. > (move_hi_quad_): Use appropriate insn for BYTES_BIG_ENDIAN. > (aarch64_combinez): Gate on BYTES_BIG_ENDIAN. > (aarch64_combinez_be): New. > (aarch64_combine): Convert to define_expand. > (aarch64_combine_internal): New. > (aarch64_simd_combine): Remove bogus RTL description. OK... and back port to 4.9 please? /Marcus
Re: [PATCH 4.9][AArch64][testsuite] Backport r211502: PR/59843 Fix ICE on singleton vector of float on AArch64
On 4 July 2014 14:58, Alan Lawrence wrote: > No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf, > arm-none-eabi, x86_64-unknown-linux-gnu: > > NA->PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20) > NA->PASS gcc.dg/vect/vect-singleton_1.c (test for excess errors) > > > gcc/ChangeLog: > > * config/aarch64/aarch64-modes.def: Add V1DFmode. > * config/aarch64/aarch64.c (aarch64_vector_mode_supported_p): > Support V1DFmode. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/vect-singleton_1.c: New file. > PR should be referenced in the ChangeLog entry, otherwise O. /Marcus
Re: [PATCH] Add patch for debugging compiler ICEs
On Mon, Jun 02, 2014 at 04:21:14PM +0100, Maxim Ostapenko wrote: > Hi, > > A years ago there was a discussion > (https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging > compiler ICEs that resulted in a patch from Jakub, which dumps > useful information into temporary file, but for some reasons this patch > wasn't applied to trunk. > > This is the resurrected patch with added GCC version information into > generated repro file. > How can I test this patch? I tried applying it and injecting a segmentation fault in to the AArch64 CPU option parsing code, but I didn't see anything new when the ICE was triggered. What am I doing wrong? Thanks, James
Re: [PATCH] Add patch for debugging compiler ICEs
On Fri, Jul 04, 2014 at 04:13:31PM +0100, James Greenhalgh wrote: > On Mon, Jun 02, 2014 at 04:21:14PM +0100, Maxim Ostapenko wrote: > > Hi, > > > > A years ago there was a discussion > > (https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging > > compiler ICEs that resulted in a patch from Jakub, which dumps > > useful information into temporary file, but for some reasons this patch > > wasn't applied to trunk. > > > > This is the resurrected patch with added GCC version information into > > generated repro file. > > > > How can I test this patch? > > I tried applying it and injecting a segmentation fault in to the AArch64 CPU > option parsing code, but I didn't see anything new when the ICE was triggered. > > What am I doing wrong? It is a driver patch, so you get something only when you invoke the driver, not when compiling with cc1 or cc1plus etc. directly. Just pick up any known ICE from bugzilla and try it... Jakub
Re: [Patch] Not very subtle fix for pr61510
On Mon, Jun 23, 2014 at 06:43:20PM +0100, Jan Hubicka wrote: > > On Mon, 23 Jun 2014, James Greenhalgh wrote: > > > > > > > > Hi, > > > > > > pr61510 is a case where cgraphunit.c::analyze_functions can end up > > > dereferencing a NULL pointer. This is, to me, the obvious way to avoid > > > dereferencing NULL. > > > > > > However, I'm not very confident that this isn't just masking some > > > horrible and subtle bug, so I'd like some review feedback on the patch. > > > > > > Tested on aarch64-none-elf, where I was seeing the issue. > > > > > > OK? > > > > Obvious in some sense to me, too, but I wonder why we don't have a cgraph > > node > > for it and what happens if it is created later (and then doesn't > > have the flag set)? > > In that case we won't get the used_as_abstract_origin flag. that will make us > to throw away the debug info if we remove it. I guess we simply want > graph_get_create_node here. I can prepare patch tonight (after teaching) Did you get round to testing this? Thanks, James
[PATCH][ARM] Remove deprecated mwords-little-endian
Hi all,
-mwords-little-endian was deprecated in GCC 4.7. This patch removes the
option and associated machinery and documentation.
Tested armeb-none-eabi and saw no regressions.
Ok for trunk?
Thanks,
Kyrill
2014-07-04 Kyrylo Tkachov
* config/arm/arm.opt (mwords-little-endian): Delete.
* config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Remove handling
of TARGET_LITTLE_WORDS.
(WORDS_BIG_ENDIAN): Define to BYTES_BIG_ENDIAN.
* config/arm/arm.c (arm_option_override): Remove TARGET_LITTLE_WORDS
warning.
* doc/invoke.texi: Remove references to -mwords-little-endian.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 773e001..00b3ca2 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2644,10 +2644,6 @@ arm_option_override (void)
if (TARGET_APCS_FLOAT)
warning (0, "passing floating point arguments in fp regs not yet supported");
- if (TARGET_LITTLE_WORDS)
-warning (OPT_Wdeprecated, "% is deprecated and "
- "will be removed in a future release");
-
/* Initialize boolean versions of the flags, for use in the arm.md file. */
arm_arch3m = (insn_flags & FL_ARCH3M) != 0;
arm_arch4 = (insn_flags & FL_ARCH4) != 0;
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index c325026..047df97 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -104,8 +104,6 @@ extern char arm_arch_name[];
builtin_define ("__ARM_BIG_ENDIAN"); \
if (TARGET_THUMB)\
builtin_define ("__THUMBEB__"); \
- if (TARGET_LITTLE_WORDS) \
- builtin_define ("__ARMWEL__"); \
} \
else \
{ \
@@ -643,9 +641,8 @@ extern int arm_arch_crc;
#define BYTES_BIG_ENDIAN (TARGET_BIG_END != 0)
/* Define this if most significant word of a multiword number is the lowest
- numbered.
- This is always false, even when in big-endian mode. */
-#define WORDS_BIG_ENDIAN (BYTES_BIG_ENDIAN && ! TARGET_LITTLE_WORDS)
+ numbered. */
+#define WORDS_BIG_ENDIAN (BYTES_BIG_ENDIAN)
#define UNITS_PER_WORD 4
diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index d80f1f1..0a80513 100644
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -231,10 +231,6 @@ Tune code for the given processor
EnumValue
Enum(processor_type) String(native) Value(-1) DriverOnly
-mwords-little-endian
-Target Report RejectNegative Mask(LITTLE_WORDS)
-Assume big endian bytes, little endian words. This option is deprecated.
-
mvectorize-with-neon-quad
Target Report RejectNegative InverseMask(NEON_VECTORIZE_DOUBLE)
Use Neon quad-word (rather than double-word) registers for vectorization
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3a02125d..62b7a69 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -517,7 +517,7 @@ Objective-C and Objective-C++ Dialects}.
-mapcs-float -mno-apcs-float @gol
-mapcs-reentrant -mno-apcs-reentrant @gol
-msched-prolog -mno-sched-prolog @gol
--mlittle-endian -mbig-endian -mwords-little-endian @gol
+-mlittle-endian -mbig-endian @gol
-mfloat-abi=@var{name} @gol
-mfp16-format=@var{name}
-mthumb-interwork -mno-thumb-interwork @gol
@@ -12374,15 +12374,6 @@ the default for all standard configurations.
Generate code for a processor running in big-endian mode; the default is
to compile code for a little-endian processor.
-@item -mwords-little-endian
-@opindex mwords-little-endian
-This option only applies when generating code for big-endian processors.
-Generate code for a little-endian word order but a big-endian byte
-order. That is, a byte order of the form @samp{32107654}. Note: this
-option should only be used if you require compatibility with code for
-big-endian ARM processors generated by versions of the compiler prior to
-2.8. This option is now deprecated.
-
@item -march=@var{name}
@opindex march
This specifies the name of the target ARM architecture. GCC uses this
Re: *ping* - [Patch, Fortran] Coarray fixes for select type/associate and type of derived components
Dear Tobias, This looks absolutely fine to me - good for trunk. Thanks for the patch and for the overall co-array effort. Paul On 4 July 2014 08:02, Tobias Burnus wrote: > Another somewhat early PING**2 > > >> On June 29, 2014, Tobias Burnus wrote: >>> >>> This patch fixes some issues with polymorphic coarrays. I still have to >>> fix at least one issue. >>> >>> Fixed by the patch: >>> >>> a) The temporary pointer generated with SELECT TYPE has to be a coarray. >>> That's fixed with the resolve.c patch. The comment is also bogus: The >>> comment is correct – and gfortran correctly detects coindexed variables as >>> selector. However, in the code in question, the selector is not coindexed >>> but the variable in the coindexed section is. >>> >>> b) It doesn't make sense to try to initialize the temporary pointer of >>> SELECT TYPE (or ASSOCIATE), thus we have to exclude it also in trans-decl.c >>> >>> c) As the temporary variable is internally a pointer, the assert in >>> trans-array.c also has to accept a pointer – even though coarrays with token >>> in the descriptor can only be allocatable. But for code like "a(1)[1])", >>> "a(1)" is not longer a pointer – and one ends up having an akind of unknown. >>> Instead of adding all kind of values, I simply removed the assert. >>> >>> d) In trans-intrinsic.c, one has a similar issue. We now avoid an ICE by >>> checking whether the variable is set before accessing it. >>> >>> e) For caf(:)[i]%a, we had the dtype of the descriptor of "caf" instead >>> of "...%a". That's now fixed. >>> >>> Build and regtested on x86-64-gnu-linux. >>> OK for the trunk? >>> >>> Tobias >>> >>> PS: Still to be done for coarrays: Nonallocatable polymorphic coarray >>> dummies. For those, the offset and the token is passed as additional >>> argument – but that's not yet correctly handled with ASSOCIATE/SELECT TYPE. >>> Also to be done are more type-conversion checks (beyond those which are >>> implicitly checked by this patch) – and the handling of vector subscripts. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [i386] Replace builtins with vector extensions
On Thu, 3 Jul 2014, Kirill Yukhin wrote: Hello Marc, On 28 Jun 12:42, Marc Glisse wrote: It would enable a number of optimizations, like constant propagation, FMA contraction, etc. It would also allow us to remove several builtins. This should be main motivation for replacing built-ins. But this approach IMHO should only be used for `obvious' cases only. I mean: + - / * and friends. Think that this shouldn't apply for shuffles, broadcasts. But we have to define border between `obvious' and rest intrinsics. We don't have a syntax in the front-end for broadcasts anyway, but are you sure about shuffles? __builtin_shuffle directly translates to VEC_PERM_EXPR, on which we are careful to avoid optimizations like combining 2 shuffles unless the result is the identity. And expanding shuffles that can be done in a single instruction works well. But I am happy not doing them yet. To be very specific, could you list which intrinsics you would like to remove from the posted patch? On the over hand, updated in such a way intrinsic may actually generate different instruction then intended (e.g. FMA case). It is the same with scalars, we have -ffp-contract for that. For ICC this is generally OK to generate different instructions, only semantics should be obeyed. -- Marc Glisse
[PATCH] -fsanitize=alignment support
Hi!
This patch adds -fsanitize=alignment support, part of -fsanitize=undefined,
which will complain about misaligned accesses (those where the compiler
isn't told it is less than naturally aligned access, such as with packed
struct accesses).
In addition to that it adds instrumentation of reference initialization
for C++ (in that case it checks for -fsanitize=null whether a reference
doesn't bind to what a NULL pointer points to and for -fsanitize=alignment
whether it is sufficiently aligned).
And also instruments method calls and constructor calls, the former for
both null and alignment, the latter only for alignment, as for placement
new we don't construct anything at NULL address.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-07-04 Jakub Jelinek
* opts.c (common_handle_option): Handle -fsanitize=alignment.
* ubsan.h (enum ubsan_null_ckind): Add UBSAN_CTOR_CALL.
(ubsan_expand_bounds_ifn, ubsan_expand_null_ifn): Change return
type to bool.
* stor-layout.h (min_align_of_type): New prototype.
* asan.c (pass_sanopt::execute): Don't perform gsi_next if
ubsan_expand* told us not to do it. Remove the extra gsi_end_p
check.
* ubsan.c: Include builtins.h.
(ubsan_expand_bounds_ifn): Change return type to bool,
always return true.
(ubsan_expand_null_ifn): Change return type to bool, change
argument to gimple_stmt_iterator *. Handle both null and alignment
sanitization, take type from ckind argument's type rather than
first argument.
(instrument_member_call): Removed.
(instrument_mem_ref): Remove t argument, add mem and base arguments.
Handle both null and alignment sanitization, don't say whole
struct access is member access. Build 3 argument IFN_UBSAN_NULL
call instead of 2 argument.
(instrument_null): Adjust instrument_mem_ref caller. Don't
instrument calls here.
(pass_ubsan::gate, pass_ubsan::execute): Handle SANITIZE_ALIGNMENT
like SANITIZE_NULL.
* stor-layout.c (min_align_of_type): New function.
* flag-types.h (enum sanitize_code): Add SANITIZE_ALIGNMENT.
Or it into SANITIZE_UNDEFINED.
* doc/invoke.texi (-fsanitize=alignment): Document.
cp/
* cp-gimplify.c (cp_genericize_r): For -fsanitize=null and/or
-fsanitize=alignment call ubsan_maybe_instrument_reference
for casts to REFERENCE_TYPE and ubsan_maybe_instrument_member_call
for calls to member functions.
c-family/
* c-common.h (min_align_of_type): Removed prototype.
* c-common.c (min_align_of_type): Removed.
* c-ubsan.h (ubsan_maybe_instrument_reference,
ubsan_maybe_instrument_member_call): New prototypes.
* c-ubsan.c: Include stor-layout.h and builtins.h.
(ubsan_maybe_instrument_reference_or_call,
ubsan_maybe_instrument_reference, ubsan_maybe_instrument_call): New
functions.
testsuite/
* c-c++-common/ubsan/align-1.c: New test.
* c-c++-common/ubsan/align-2.c: New test.
* c-c++-common/ubsan/align-3.c: New test.
* c-c++-common/ubsan/align-4.c: New test.
* c-c++-common/ubsan/align-5.c: New test.
* c-c++-common/ubsan/attrib-4.c: New test.
* g++.dg/ubsan/align-1.C: New test.
* g++.dg/ubsan/align-2.C: New test.
* g++.dg/ubsan/align-3.C: New test.
* g++.dg/ubsan/attrib-1.C: New test.
* g++.dg/ubsan/null-1.C: New test.
* g++.dg/ubsan/null-2.C: New test.
--- gcc/opts.c.jj 2014-07-03 16:35:57.364165700 +0200
+++ gcc/opts.c 2014-07-04 10:58:10.844536974 +0200
@@ -1475,6 +1475,7 @@ common_handle_option (struct gcc_options
{ "float-cast-overflow", SANITIZE_FLOAT_CAST,
sizeof "float-cast-overflow" - 1 },
{ "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
+ { "alignment", SANITIZE_ALIGNMENT, sizeof "alignment" - 1 },
{ NULL, 0, 0 }
};
const char *comma;
--- gcc/ubsan.h.jj 2014-07-03 16:35:57.012167511 +0200
+++ gcc/ubsan.h 2014-07-04 14:49:24.125733716 +0200
@@ -27,7 +27,8 @@ enum ubsan_null_ckind {
UBSAN_STORE_OF,
UBSAN_REF_BINDING,
UBSAN_MEMBER_ACCESS,
- UBSAN_MEMBER_CALL
+ UBSAN_MEMBER_CALL,
+ UBSAN_CTOR_CALL
};
/* This controls how ubsan prints types. Used in ubsan_type_descriptor. */
@@ -43,8 +44,8 @@ struct ubsan_mismatch_data {
tree ckind;
};
-extern void ubsan_expand_bounds_ifn (gimple_stmt_iterator *);
-extern void ubsan_expand_null_ifn (gimple_stmt_iterator);
+extern bool ubsan_expand_bounds_ifn (gimple_stmt_iterator *);
+extern bool ubsan_expand_null_ifn (gimple_stmt_iterator *);
extern tree ubsan_instrument_unreachable (location_t);
extern tree ubsan_create_data (const char *, const location_t *,
const struct ubsan_mismatch_data *, ...);
--- gcc/stor-lay
Re: [PATCH] Fix arrays in rtx.u + add minor rtx verification
On Mon, Jun 23, 2014 at 04:40:43PM +0200, Richard Biener wrote:
> Can we instead refactor expmed.c to avoid allocating rtx_def directly?
> Like by using rtx in init_expmed_rtl and allocating from an obstack
> (or not care and GC-allocate anyway).
So like this? Bootstrapped/regtested on x86_64-linux and i686-linux,
haven't seen any measurable difference in 1000x invocations of null .c file
compilations. It is just 18 GC allocations + I ggc_free all of them.
2014-07-04 Jakub Jelinek
* expmed.c (struct init_expmed_rtl): Change all fields but
pow2 and cint from struct rtx_def to rtx.
(init_expmed_one_conv, init_expmed_one_mode): Adjust for that change.
(init_expmed): Likewise. Allocate all the 18 rtxes and ggc_free them
at the end again.
--- gcc/expmed.c.jj 2014-07-03 16:37:50.0 +0200
+++ gcc/expmed.c2014-07-04 17:23:54.229174101 +0200
@@ -88,24 +88,24 @@ mask_rtx (enum machine_mode mode, int bi
struct init_expmed_rtl
{
- struct rtx_def reg;
- struct rtx_def plus;
- struct rtx_def neg;
- struct rtx_def mult;
- struct rtx_def sdiv;
- struct rtx_def udiv;
- struct rtx_def sdiv_32;
- struct rtx_def smod_32;
- struct rtx_def wide_mult;
- struct rtx_def wide_lshr;
- struct rtx_def wide_trunc;
- struct rtx_def shift;
- struct rtx_def shift_mult;
- struct rtx_def shift_add;
- struct rtx_def shift_sub0;
- struct rtx_def shift_sub1;
- struct rtx_def zext;
- struct rtx_def trunc;
+ rtx reg;
+ rtx plus;
+ rtx neg;
+ rtx mult;
+ rtx sdiv;
+ rtx udiv;
+ rtx sdiv_32;
+ rtx smod_32;
+ rtx wide_mult;
+ rtx wide_lshr;
+ rtx wide_trunc;
+ rtx shift;
+ rtx shift_mult;
+ rtx shift_add;
+ rtx shift_sub0;
+ rtx shift_sub1;
+ rtx zext;
+ rtx trunc;
rtx pow2[MAX_BITS_PER_WORD];
rtx cint[MAX_BITS_PER_WORD];
@@ -127,9 +127,9 @@ init_expmed_one_conv (struct init_expmed
- (GET_MODE_CLASS (from_mode) == MODE_PARTIAL_INT));
/* Assume cost of zero-extend and sign-extend is the same. */
- which = (to_size < from_size ? &all->trunc : &all->zext);
+ which = (to_size < from_size ? all->trunc : all->zext);
- PUT_MODE (&all->reg, from_mode);
+ PUT_MODE (all->reg, from_mode);
set_convert_cost (to_mode, from_mode, speed, set_src_cost (which, speed));
}
@@ -142,32 +142,32 @@ init_expmed_one_mode (struct init_expmed
mode_bitsize = GET_MODE_UNIT_BITSIZE (mode);
- PUT_MODE (&all->reg, mode);
- PUT_MODE (&all->plus, mode);
- PUT_MODE (&all->neg, mode);
- PUT_MODE (&all->mult, mode);
- PUT_MODE (&all->sdiv, mode);
- PUT_MODE (&all->udiv, mode);
- PUT_MODE (&all->sdiv_32, mode);
- PUT_MODE (&all->smod_32, mode);
- PUT_MODE (&all->wide_trunc, mode);
- PUT_MODE (&all->shift, mode);
- PUT_MODE (&all->shift_mult, mode);
- PUT_MODE (&all->shift_add, mode);
- PUT_MODE (&all->shift_sub0, mode);
- PUT_MODE (&all->shift_sub1, mode);
- PUT_MODE (&all->zext, mode);
- PUT_MODE (&all->trunc, mode);
-
- set_add_cost (speed, mode, set_src_cost (&all->plus, speed));
- set_neg_cost (speed, mode, set_src_cost (&all->neg, speed));
- set_mul_cost (speed, mode, set_src_cost (&all->mult, speed));
- set_sdiv_cost (speed, mode, set_src_cost (&all->sdiv, speed));
- set_udiv_cost (speed, mode, set_src_cost (&all->udiv, speed));
+ PUT_MODE (all->reg, mode);
+ PUT_MODE (all->plus, mode);
+ PUT_MODE (all->neg, mode);
+ PUT_MODE (all->mult, mode);
+ PUT_MODE (all->sdiv, mode);
+ PUT_MODE (all->udiv, mode);
+ PUT_MODE (all->sdiv_32, mode);
+ PUT_MODE (all->smod_32, mode);
+ PUT_MODE (all->wide_trunc, mode);
+ PUT_MODE (all->shift, mode);
+ PUT_MODE (all->shift_mult, mode);
+ PUT_MODE (all->shift_add, mode);
+ PUT_MODE (all->shift_sub0, mode);
+ PUT_MODE (all->shift_sub1, mode);
+ PUT_MODE (all->zext, mode);
+ PUT_MODE (all->trunc, mode);
+
+ set_add_cost (speed, mode, set_src_cost (all->plus, speed));
+ set_neg_cost (speed, mode, set_src_cost (all->neg, speed));
+ set_mul_cost (speed, mode, set_src_cost (all->mult, speed));
+ set_sdiv_cost (speed, mode, set_src_cost (all->sdiv, speed));
+ set_udiv_cost (speed, mode, set_src_cost (all->udiv, speed));
- set_sdiv_pow2_cheap (speed, mode, (set_src_cost (&all->sdiv_32, speed)
+ set_sdiv_pow2_cheap (speed, mode, (set_src_cost (all->sdiv_32, speed)
<= 2 * add_cost (speed, mode)));
- set_smod_pow2_cheap (speed, mode, (set_src_cost (&all->smod_32, speed)
+ set_smod_pow2_cheap (speed, mode, (set_src_cost (all->smod_32, speed)
<= 4 * add_cost (speed, mode)));
set_shift_cost (speed, mode, 0, 0);
@@ -181,13 +181,13 @@ init_expmed_one_mode (struct init_expmed
n = MIN (MAX_BITS_PER_WORD, mode_bitsize);
for (m = 1; m < n; m++)
{
- XEXP (&all->shift, 1) = all->cint[m];
- XEXP (&all->shift_mult, 1) = all->pow2[m];
+ XEXP (all->shift, 1) = all->cint[m];
+ XEXP (all->shift_mult, 1) = all->pow2[m];
- set_shift_cost (speed, mode, m, set_s
Re: [BUILDROBOT] xtensa fallout (was: Turn DECL_SECTION_NAME into string)
On Wed, 2014-06-25 08:55:57 -0700, augustine.sterl...@gmail.com wrote: > On Tue, Jun 24, 2014 at 10:20 PM, Jan Hubicka wrote: > > > This is the xtensa fallout, see > > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=272418 > > > > > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > > > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > > > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > > > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros > > > -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. > > > -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. > > > -I/home/jbglaw/repos/gcc/gcc/../include > > > -I/home/jbglaw/repos/gcc/gcc/../libcpp/include > > > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber > > > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber > > > -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o insn-preds.o -MT > > > insn-preds.o -MMD -MP -MF ./.deps/insn-preds.TPo insn-preds.c > > > /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md: In function ‘int > > > call_insn_operand_1(rtx, machine_mode)’: > > > /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md:113:57: error: > > > cannot convert ‘const char*’ to ‘tree’ in assignment > > > /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md:119:46: error: > > > cannot convert ‘const char*’ to ‘tree’ in assignment > > > make[1]: *** [insn-preds.o] Error 1 > > Should be fixed by this (and I see in my prevoius mail I wanted > > TREE_STRING_POINTER) > > [resend due to gmail's stupid html-by-default] > > This patch looks correct to me, but I haven't watched quite enough of > the underlying change to know that replacing the strcmp with pointer > equality is really the right thing. > > If it is, approved for Xtensa. *ping* As Jan wrote it, I *guess* it probably is (haven't checked.) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://www.eyrie.org/~eagle/faqs/questions.html the second : signature.asc Description: Digital signature
Re: Strenghten assumption about dynamic type changes (placement new)
> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> >We propagate types from places we know instances are created across pointers
> >passed to functions. Once non-POD type is created at a given memory
> >location,
> >one can not change its type by placement_new into something else.
>
> Hmm. If the memory location is untyped (i.e. from malloc) or a
> character array, or a union, you can indeed destroy an object of one
> type and create an object of a different type in that location.
>
> >Jason, this assumes that one can not destroy the type and re-construct same
> >type at the same spot.
>
> That is an invalid assumption; you can destroy one object and
> construct a new one in the same location. Doing it within a method
> would be unusual, but I don't think there's a rule against it.
Hi,
this is updated patch that does the legwork needed to prove we are not
re-constructing an object in the same location as we created previous one.
Currenlty we track only objects places in declarations, but I would really
like to understand how precisely the rules of the game differs when the
object lives in dynamically allocated memory - i.e. I work out the dynamic
type by spotting either virtual table store or constructor call.
Bootstrapped/regtested x86_64-linux, will commit it after bit more
testing.
* cgraph.c (cgraph_create_indirect_edge): Update call of
get_polymorphic_call_info.
* ipa-utils.h (get_polymorphic_call_info): Add parameter CALL.
(possible_polymorphic_call_targets): Add parameter call.
(decl_maybe_in_construction_p): New predicate.
(get_polymorphic_call_info): Add parameter call;
use decl_maybe_in_construction_p.
* gimple-fold.c (fold_gimple_assign): Update use of
possible_polymorphic_call_targets.
(gimple_fold_call): Likewise.
* ipa-prop.c: Inlcude calls.h
(ipa_binfo_from_known_type_jfunc): Check that known type is record.
(param_type_may_change_p): New predicate.
(detect_type_change_from_memory_writes): Break out from ...
(detect_type_change): ... this one; use
param_type_may_change_p.
(detect_type_change_ssa): Use param_type_may_change_p.
(compute_known_type_jump_func): Use decl_maybe_in_construction_p.
* g++.dg/ipa/devirt-26.C: Update testcase.
* g++.dg/ipa/imm-devirt-1.C: Update testcase.
* g++.dg/ipa/imm-devirt-2.C: Update testcase.
Index: cgraph.c
===
--- cgraph.c(revision 212278)
+++ cgraph.c(working copy)
@@ -967,7 +967,7 @@ cgraph_create_indirect_edge (struct cgra
get_polymorphic_call_info (caller->decl,
target,
&otr_type, &otr_token,
-&context);
+&context, call_stmt);
/* Only record types can have virtual calls. */
gcc_assert (TREE_CODE (otr_type) == RECORD_TYPE);
Index: testsuite/g++.dg/ipa/devirt-26.C
===
--- testsuite/g++.dg/ipa/devirt-26.C(revision 212278)
+++ testsuite/g++.dg/ipa/devirt-26.C(working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O3 -fdump-ipa-devirt-details" } */
+/* { dg-options "-O3 -fdump-tree-ccp1" } */
struct A
{
int a;
@@ -23,7 +23,6 @@ int test(void)
return d->foo()+b->foo();
}
/* The call to b->foo() is perfectly devirtualizable because C can not be in
construction
- when &c was used, but we can not analyze that so far. Test that we at
least speculate
- that type is in the construction. */
-/* { dg-final { scan-ipa-dump "speculatively devirtualizing" "devirt" } } */
-/* { dg-final { cleanup-ipa-dump "devirt" } } */
+ when &c was used. */
+/* { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "ccp1" } } */
+/* { dg-final { cleanup-tree-dump "ccp1" } } */
Index: testsuite/g++.dg/ipa/imm-devirt-1.C
===
--- testsuite/g++.dg/ipa/imm-devirt-1.C (revision 212278)
+++ testsuite/g++.dg/ipa/imm-devirt-1.C (working copy)
@@ -1,7 +1,7 @@
/* Verify that virtual calls are folded even early inlining puts them into one
function with the definition. */
/* { dg-do run } */
-/* { dg-options "-O2 -fdump-tree-fre1-details" } */
+/* { dg-options "-O2 -fdump-tree-einline" } */
extern "C" void abort (void);
@@ -58,5 +58,10 @@ int main (int argc, char *argv[])
return 0;
}
-/* { dg-final { scan-tree-dump "converting indirect call to function virtual
int B::foo" "fre1" } } */
-/* { dg-final { cleanup-tree-dump "fre1" } } */
+/* middleman_2 gets early inlined and the virtual call should get turned to
+ a direct call. */
+/* { dg-final { scan-tree-dump "Inlining int middleman_1" "einline" } } */
+/* { dg-final { scan-tree-dump "Inlining int middleman_2" "einline" } } */
+/* { dg-final { scan-tree-dump
[GSoC] Addition of __isl_give to declarations
This patch adds __isl_give to declarations of the following funcions: generate_isl_context, generate_isl_schedule, scop_to_isl_ast Is it fine for trunk? -- Cheers, Roman Gareev ChangeLog_entry Description: Binary data patch Description: Binary data
