Re: [patch, fortran] Function call optimization
On Mar 18 2011, Tobias Burnus wrote: Thomas Koenig wrote: + if (!(*e)->value.function.esym->attr.pure + && !(*e)->value.function.esym->attr.implicit_pure + && !(*e)->value.function.esym->attr.elemental) + return 0; I have not followed the discussion nor have I fully read the patch, but what's the reason for allowing ELEMENTAL functions? I understand the PURE and the implicitly pure part. But without looking at the scalarizer, I would assume that the same reasons which speak against non-elemental impure functions should also speak against IMPURE ELEMENTAL functions, don't they? Impure elemental procedures came in only in Fortran 2008, if I understand it. I don't know for certain, but my guess is that they are there primarily to allow diagnostics in elemental procedures. What that means about their required semantics is a bit unclear Regards, Nick Maclaren.
Re: [PATCH] prune warn_compact_unwind warnings on darwin
On 19 Mar 2011, at 06:22, Mike Stump wrote: On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote: Xcode 4.0's linker now defaults on... -warn_compact_unwind So, if this is a flag, and we can turn the warning off, and we truly don't care about the warnings, why not just use - no_warn_compact_unwind? That would be preferable, I think. 1/ Hm. AFAIK we set "-no_compact_unwind", when the target is 10.6 #define LINK_GCC_C_SEQUENCE_SPEC \ "%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \ - it would seem to be a tool bug to flag a warning for something specifically excluded. 2/ unless "-no_compact_unwind" is now ignored? 3/ maybe we are going to have to follow clang et. al in having a tools version runtime flag (this would especially ease the issues in making canadians to early Darwin versions). OSX ld and cctools version are detectable at runtime for native builds - say: -mmacosx-ld-version= - mmacosx-cctools-version= ... so we don't ask people to put this for the native case (we can also pick sensible defaults for other systems).[trunk clang uses -target-linker-version xx.yy.zz - but that's not consistent with our general scheme]. (I know Mike hates additional flags - and tool capabilities can, of course, be detected at runtime for native builds - but we also cater - by design - for cross-builds to earlier versions of the OS) cheers Iain
[PATCH] libstdc++ ABI issues with __int128
On Wed, Mar 16, 2011 at 10:05:41AM -0700, Benjamin Kosnik wrote:
>
> Here's the 4_6-branch version, approved by Jakub.
Comparing the additions in x86_64-linux libstdc++, I still see a couple of
wrong exports, in particular since gcc 4.5 the following symbols
_ZTIn@@CXXABI_1.3 OBJECT WEAK DEFAULT 16
_ZTIo@@CXXABI_1.3 OBJECT WEAK DEFAULT 16
_ZTIPKn@@CXXABI_1.3 OBJECT WEAK DEFAULT 32
_ZTIPKo@@CXXABI_1.3 OBJECT WEAK DEFAULT 32
_ZTIPn@@CXXABI_1.3 OBJECT WEAK DEFAULT 32
_ZTIPo@@CXXABI_1.3 OBJECT WEAK DEFAULT 32
_ZTSn@@CXXABI_1.3 OBJECT WEAK DEFAULT 2
_ZTSo@@CXXABI_1.3 OBJECT WEAK DEFAULT 2
_ZTSPKn@@CXXABI_1.3 OBJECT WEAK DEFAULT 4
_ZTSPKo@@CXXABI_1.3 OBJECT WEAK DEFAULT 4
_ZTSPn@@CXXABI_1.3 OBJECT WEAK DEFAULT 3
_ZTSPo@@CXXABI_1.3 OBJECT WEAK DEFAULT 3
were added. Those surely need to go into CXXABI_1.3.5, not CXXABI_1.3,
as they weren't exported in gcc 3.4 (nor 4.5).
Plus, I believe we aren't exporting new _ZTS* symbols for some time, only
_ZTI*, right?
I'll try to post updated abilist files for
i686/x86_64/powerpc{,64}/s390{,x}-linux once this is resolved.
So here is a patch to fix that up. Ok for trunk/4.6?
2011-03-19 Jakub Jelinek
* config/abi/pre/gnu.ver (CXXABI_1.3): Don't export _ZT[IS][PK]*[no].
(CXXABI_1.3.5): Export _ZTI[PK]*[no].
--- libstdc++-v3/config/abi/pre/gnu.ver.jj 2011-03-16 17:28:54.0
+0100
+++ libstdc++-v3/config/abi/pre/gnu.ver 2011-03-19 10:07:48.978884614 +0100
@@ -1337,9 +1337,9 @@ CXXABI_1.3 {
_ZTVN10__cxxabiv121__vmi_class_type_infoE;
# typeinfo structure (and some names)
-_ZTI[a-fh-z];
-_ZTIP[a-fh-z];
-_ZTIPK[a-fh-z];
+_ZTI[a-fh-mp-z];
+_ZTIP[a-fh-mp-z];
+_ZTIPK[a-fh-mp-z];
_ZTIN10__cxxabiv117__array_type_infoE;
_ZTIN10__cxxabiv117__class_type_infoE;
_ZTIN10__cxxabiv116__enum_type_infoE;
@@ -1352,9 +1352,9 @@ CXXABI_1.3 {
_ZTIN10__cxxabiv121__vmi_class_type_infoE;
# typeinfo name
-_ZTS[a-fh-z];
-_ZTSP[a-fh-z];
-_ZTSPK[a-fh-z];
+_ZTS[a-fh-mp-z];
+_ZTSP[a-fh-mp-z];
+_ZTSPK[a-fh-mp-z];
_ZTSN10__cxxabiv117__array_type_infoE;
_ZTSN10__cxxabiv117__class_type_infoE;
_ZTSN10__cxxabiv116__enum_type_infoE;
@@ -1435,6 +1435,11 @@ CXXABI_1.3.5 {
_ZTIPDn;
_ZTIPKDn;
+# typeinfo for __int128 and unsigned __int128
+_ZTI[no];
+_ZTIP[no];
+_ZTIPK[no];
+
# Default function.
_ZSt11_Hash_bytesPKv*;
Jakub
Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)
On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck wrote: > yes, but i think that the reason this is a pr is that it seems to be needed > for correctness. Note that df_get_bb_dirty is defaulting to "return false", not "abort". This is what tricked crossjumping and caused the bug. If I can get hold of my old SPEC2000 copy, I'd like to remove LIVE completely from most -O2 passes (certainly those running after initialization of uninitialized regs!) in 4.7. Paolo
Re: [PATCH] libstdc++ ABI issues with __int128
On Sat, Mar 19, 2011 at 10:19:04AM +0100, Jakub Jelinek wrote: > On Wed, Mar 16, 2011 at 10:05:41AM -0700, Benjamin Kosnik wrote: > > > > Here's the 4_6-branch version, approved by Jakub. > > Comparing the additions in x86_64-linux libstdc++, I still see a couple of > wrong exports, in particular since gcc 4.5 the following symbols > > _ZTIn@@CXXABI_1.3 OBJECT WEAK DEFAULT 16 > _ZTIo@@CXXABI_1.3 OBJECT WEAK DEFAULT 16 > _ZTIPKn@@CXXABI_1.3 OBJECT WEAK DEFAULT 32 > _ZTIPKo@@CXXABI_1.3 OBJECT WEAK DEFAULT 32 > _ZTIPn@@CXXABI_1.3 OBJECT WEAK DEFAULT 32 > _ZTIPo@@CXXABI_1.3 OBJECT WEAK DEFAULT 32 > _ZTSn@@CXXABI_1.3 OBJECT WEAK DEFAULT 2 > _ZTSo@@CXXABI_1.3 OBJECT WEAK DEFAULT 2 > _ZTSPKn@@CXXABI_1.3 OBJECT WEAK DEFAULT 4 > _ZTSPKo@@CXXABI_1.3 OBJECT WEAK DEFAULT 4 > _ZTSPn@@CXXABI_1.3 OBJECT WEAK DEFAULT 3 > _ZTSPo@@CXXABI_1.3 OBJECT WEAK DEFAULT 3 > > were added. Those surely need to go into CXXABI_1.3.5, not CXXABI_1.3, > as they weren't exported in gcc 3.4 (nor 4.5). > Plus, I believe we aren't exporting new _ZTS* symbols for some time, only > _ZTI*, right? And another question is, we still export a bunch of new _ZTS* symbols, isn't that now pointless when we always do strcmp anyway? I'm talking about _ZTSSt16nested_exception@@CXXABI_1.3.5 OBJECT WEAK DEFAULT 21 _ZTSNSt13__future_base11_State_baseE@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 33 _ZTSNSt13__future_base12_Result_baseE@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 34 _ZTSSt11regex_error@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 16 _ZTSSt12bad_weak_ptr@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 17 _ZTSSt17bad_function_call@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 22 here. Jakub
Re: [PATCH] prune warn_compact_unwind warnings on darwin
On Fri, Mar 18, 2011 at 11:22:11PM -0700, Mike Stump wrote: > On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote: > > Xcode 4.0's linker now defaults on... > > > > -warn_compact_unwind > > So, if this is a flag, and we can turn the warning off, and we truly don't > care about the warnings, why not just use -no_warn_compact_unwind? That > would be preferable, I think. Mike, Unfortunately, there is no such -no_warn_compact_unwind flag in the Xcode 3.2.6/4.0 linkers. Since the -warn_compact_unwind option in the past was set as a default-in option, Apple never bothered to add a flag to turn it off and forgot to do so (or even to document the fact that the flag was defaulted on now for the new Xcode releases). Jack
Re: [PATCH] prune warn_compact_unwind warnings on darwin
On Sat, Mar 19, 2011 at 08:52:32AM +, IainS wrote: > > On 19 Mar 2011, at 06:22, Mike Stump wrote: > >> On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote: >>> Xcode 4.0's linker now defaults on... >>> >>>-warn_compact_unwind >> >> So, if this is a flag, and we can turn the warning off, and we truly >> don't care about the warnings, why not just use - >> no_warn_compact_unwind? That would be preferable, I think. > > > 1/ > Hm. AFAIK we set "-no_compact_unwind", when the target is 10.6 > > #define LINK_GCC_C_SEQUENCE_SPEC \ > "%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \ > > - it would seem to be a tool bug to flag a warning for something > specifically excluded. Yes it could be considered a tool bug but we are stuck with it. We might be able to get that fixed in Xcode 4.1 but I have doubts about 3.2.6 or even 4.0 getting such a fix. Unfortunately it generates a lot of noise on the testsuite results with bogus excessive error failures. Note that Nick said... Yes. -warn_compact_unwind is on by default in the Xcode4 linker. And there is no option to turn of the warnings (other than -Wl,-w which suppresses all linker warnings). > > 2/ > unless "-no_compact_unwind" is now ignored? > > 3/ > maybe we are going to have to follow clang et. al in having a tools > version runtime flag (this would especially ease the issues in making > canadians to early Darwin versions). OSX ld and cctools version are > detectable at runtime for native builds - say: -mmacosx-ld-version= - > mmacosx-cctools-version= ... so we don't ask people to put this for the > native case (we can also pick sensible defaults for other systems). > [trunk clang uses -target-linker-version xx.yy.zz - but that's not > consistent with our general scheme]. > > (I know Mike hates additional flags - and tool capabilities can, of > course, be detected at runtime for native builds - but we also cater - > by design - for cross-builds to earlier versions of the OS) > > cheers > Iain
Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)
On 03/19/2011 05:19 AM, Paolo Bonzini wrote: On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck wrote: yes, but i think that the reason this is a pr is that it seems to be needed for correctness. Note that df_get_bb_dirty is defaulting to "return false", not "abort". This is what tricked crossjumping and caused the bug. where does the compiler fail if you change it to abort, (after doing the check from jakub's patch)? If I can get hold of my old SPEC2000 copy, I'd like to remove LIVE completely from most -O2 passes (certainly those running after initialization of uninitialized regs!) in 4.7. i had thought that there were other reasons for doing live throughout -O2 and higher, but i have forgotten. it has been a long time. Paolo
Re: [testsuite] Properly XFAIL gcc.dg/vect/slp-multitypes-2.c on Solaris 2/SPARC
On Fri, Mar 18, 2011 at 5:09 PM, Rainer Orth
wrote:
> I noticed that gcc.dg/vect/slp-multitypes-2.c is failing on Solaris
> 8/x86 with Sun as:
>
> FAIL: gcc.dg/vect/slp-multitypes-2.c (test for excess errors)
> WARNING: gcc.dg/vect/slp-multitypes-2.c compilation failed to produce
> executable
>
> Excess errors:
> Assembler: slp-multitypes-2.c
> "/var/tmp//ccmA7WBi.s", line 16 : Illegal mnemonic
> "/var/tmp//ccmA7WBi.s", line 16 : Syntax error
>
> unpcklpd %xmm0,%xmm2
>
> This should be dealt with by the explicit
> check_vect_support_and_set_flags in vect.exp, which does
>
> } elseif { [istarget "i?86-*-*"] || [istarget "x86_64-*-*"] } {
> lappend DEFAULT_VECTCFLAGS "-msse2"
> if { [check_effective_target_sse2_runtime] } {
> set dg-do-what-default run
> } else {
> set dg-do-what-default compile
> }
>
> Unfortunately, this gets overridden by the explicit
>
> /* { dg-do run { xfail { sparc*-*-* && ilp32 } } } PR rtl-opt /46603 */
>
> To fix this, I've changed the testcase to use dg-xfail-run-if instead.
> Besides, I see the failure only with gas, not Sun as.
>
> The following patch has been tested with the appropriate runtest
> invocations on both i386-pc-solaris2.8 and sparc-sun-solaris2.10 (both
> as and gas).
>
> I'm about to commit this to mainline. The 4.5 branch is unaffected, but
> 4.6 is. Ok there, too, after testing?
Ok.
Thanks,
Richard.
> Thanks.
>
> Rainer
>
>
> 2011-03-18 Rainer Orth
>
> * gcc.dg/vect/slp-multitypes-2.c: Replace dg-do run with
> dg-xfail-run-if.
> Only xfail with gas.
>
> diff -r eebced2eebe8 gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c
> --- a/gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c Fri Mar 18 10:52:22
> 2011 +0100
> +++ b/gcc/testsuite/gcc.dg/vect/slp-multitypes-2.c Fri Mar 18 16:58:49
> 2011 +0100
> @@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
> -/* { dg-do run { xfail { sparc*-*-* && ilp32 } } } PR rtl-opt/46603 */
> +/* { dg-xfail-run-if "PR rtl-optimization/46603" { sparc*-*-* && { ilp32 &&
> gas } } } */
>
> #include
> #include "tree-vect.h"
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
Re: [v3] Start random dists values testing
Paolo, The test 26_numerics/random/binomial_distribution/operators/values.cc fails on *-apple-darwin* (see http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01893.html) with [macbook] f90/bug% g++47 /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc -std=gnu++0x -I/opt/gcc/work/libstdc++-v3/testsuite/util/opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc: In lambda function: /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:36:67: error: 'binomial_pdf' was not declared in this scope /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:36:70: error: return-statement with a value, in function returning 'void' [-fpermissive] /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc: In lambda function: /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:40:68: error: 'binomial_pdf' was not declared in this scope /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:40:71: error: return-statement with a value, in function returning 'void' [-fpermissive] /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc: In lambda function: /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:45:69: error: 'binomial_pdf' was not declared in this scope /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:45:72: error: return-statement with a value, in function returning 'void' [-fpermissive] In file included from /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:26:0: /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_random.h: In function 'void __gnu_test::testDiscreteDist(Distribution&, Pdf) [with long unsigned int BINS = 100ul, long unsigned int N = 10ul, Distribution = std::_Bind(std::mersenne_twister_engine)>, Pdf = test01()::]': /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:36:72: instantiated from here /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_random.h:55:2: error: void value not ignored as it ought to be /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_random.h: In function 'void __gnu_test::testDiscreteDist(Distribution&, Pdf) [with long unsigned int BINS = 100ul, long unsigned int N = 10ul, Distribution = std::_Bind(std::mersenne_twister_engine)>, Pdf = test01()::]': /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:40:73: instantiated from here /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_random.h:55:2: error: void value not ignored as it ought to be /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_random.h: In function 'void __gnu_test::testDiscreteDist(Distribution&, Pdf) [with long unsigned int BINS = 100ul, long unsigned int N = 10ul, Distribution = std::_Bind(std::mersenne_twister_engine)>, Pdf = test01()::]': /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc:45:74: instantiated from here /opt/gcc/work/libstdc++-v3/testsuite/util/testsuite_random.h:55:2: error: void value not ignored as it ought to be The test compiles and runs if I add -D_GLIBCXX_USE_C99_MATH_TR1: [macbook] f90/bug% g++47 /opt/gcc/work/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc -std=gnu++0x -I/opt/gcc/work/libstdc++-v3/testsuite/util -D_GLIBCXX_USE_C99_MATH_TR1 [macbook] f90/bug% a.out[macbook] f90/bug% TIA Dominique
Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)
On Sat, Mar 19, 2011 at 08:08:48AM -0400, Kenneth Zadeck wrote: > > On 03/19/2011 05:19 AM, Paolo Bonzini wrote: > >On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck > >wrote: > >>yes, but i think that the reason this is a pr is that it seems to be needed > >>for correctness. > >Note that df_get_bb_dirty is defaulting to "return false", not > >"abort". This is what tricked crossjumping and caused the bug. > > > where does the compiler fail if you change it to abort, (after doing > the check from jakub's patch)? With neither of the patches of mine for this issue, df_get_bb_dirty would ICE with added gcc_assert (df && df_live); The point is that df_get_bb_dirty was silently returning false even for blocks which had lr not recumputed when live wasn't computed at all. So live isn't needed for crossjumping correctness, assuming df_get_bb_dirty is compatible with what df_get_live_out does (the first patch). Jakub
Re: [v3] Start random dists values testing
Hi, > The test compiles and runs if I add -D_GLIBCXX_USE_C99_MATH_TR1: Unfortunately I cannot debug the issue over the next few hours. If you are willing to further help I suggest checking why the dg-require I addes and used exactly because of that doesn't automatically skip the testcase on targets not defining the macro, probanly it's something trivial like a typo (in that case a fix is preapproved) > Paolo
Re: Disallow redefinition of variably modified typedefs
On Sat, Mar 19, 2011 at 12:29 AM, Joseph S. Myers
wrote:
> This week's London WG14 meeting decided that typedef redefinition
> should not be allowed in the case of variably modified types. This
> patch implements this, giving an error for such redefinitions.
>
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu. Applied
> to mainline. Any comments from other RMs about whether this should go
> in 4.6 as well, to avoid 4.6.0 being more lenient in this area than
> both 4.5 and 4.7? This is much the same issue as for anonymous
> structs and unions, but for a much more obscure case.
>
> (These two patches cover the only two cases of C1X features that were
> fully implemented for 4.6 according to the pre-London draft, and then
> changed in London. The post-London document will be going to
> enquiry-stage ITTF/JTC1 ballot so if that passes there should be no
> more technical changes before publication.)
I think it should go into 4.6.0 as well.
Thanks,
Richard.
> 2011-03-18 Joseph Myers
>
> * c-decl.c (diagnose_mismatched_decls): Give an error for
> redefining a typedef with variably modified type.
>
> testsuite:
> 2011-03-18 Joseph Myers
>
> * gcc.dg/c1x-typedef-1.c: Expect errors for redefinitions of
> variably modified typedefs.
> * gcc.dg/c1x-typedef-2.c: Remove.
>
> Index: testsuite/gcc.dg/c1x-typedef-1.c
> ===
> --- testsuite/gcc.dg/c1x-typedef-1.c (revision 171110)
> +++ testsuite/gcc.dg/c1x-typedef-1.c (working copy)
> @@ -3,7 +3,8 @@
> /* { dg-options "-std=c1x -pedantic-errors" } */
>
> /* C1X permits typedefs to be redeclared to the same type, but not to
> - different-but-compatible types. */
> + different-but-compatible types, and not when the type is variably
> + modified. */
>
> #include
>
> @@ -60,9 +61,10 @@ f (void)
> typedef void FN2(int (*p)[*]); /* { dg-message "previous declaration" } */
> typedef void FN2(int (*p)[]); /* { dg-error "with different type" } */
> typedef int AV[a]; /* { dg-message "previous declaration" } */
> - typedef int AV[b-1]; /* { dg-warning "may be a constraint violation at
> runtime" } */
> - typedef int AAa[a];
> + typedef int AV[b-1]; /* { dg-error "redefinition" } */
> + typedef int AAa[a]; /* { dg-message "previous declaration" } */
> typedef int AAb[b-1];
> typedef AAa *VF(void); /* { dg-message "previous declaration" } */
> - typedef AAb *VF(void); /* { dg-warning "may be a constraint violation at
> runtime" } */
> + typedef AAb *VF(void); /* { dg-error "redefinition" } */
> + typedef AAa AAa; /* { dg-error "redefinition" } */
> }
> Index: testsuite/gcc.dg/c1x-typedef-2.c
> ===
> --- testsuite/gcc.dg/c1x-typedef-2.c (revision 171110)
> +++ testsuite/gcc.dg/c1x-typedef-2.c (working copy)
> @@ -1,18 +0,0 @@
> -/* Test typedef redeclaration in C1X. Side effects from duplicate
> - declarations still apply. */
> -/* { dg-do run } */
> -/* { dg-options "-std=c1x -pedantic-errors" } */
> -
> -extern void exit (int);
> -extern void abort (void);
> -
> -int
> -main (void)
> -{
> - int a = 1, b = 1;
> - typedef int T[++a]; /* { dg-message "previous declaration" } */
> - typedef int T[++b]; /* { dg-warning "may be a constraint violation at
> runtime" } */
> - if (a != 2 || b != 2)
> - abort ();
> - exit (0);
> -}
> Index: c-decl.c
> ===
> --- c-decl.c (revision 171110)
> +++ c-decl.c (working copy)
> @@ -1813,20 +1813,16 @@ diagnose_mismatched_decls (tree newdecl,
> || TREE_NO_WARNING (olddecl))
> return true; /* Allow OLDDECL to continue in use. */
>
> - if (pedantic && !flag_isoc1x)
> + if (variably_modified_type_p (newtype, NULL))
> {
> - pedwarn (input_location, OPT_pedantic,
> - "redefinition of typedef %q+D", newdecl);
> + error ("redefinition of typedef %q+D with variably modified type",
> + newdecl);
> locate_old_decl (olddecl);
> }
> - else if (variably_modified_type_p (newtype, NULL))
> + else if (pedantic && !flag_isoc1x)
> {
> - /* Whether there is a constraint violation for the types not
> - being the same cannot be determined at compile time; a
> - warning that there may be one at runtime is considered
> - appropriate (WG14 reflector message 11743, 8 May 2009). */
> - warning (0, "redefinition of typedef %q+D may be a constraint "
> - "violation at runtime", newdecl);
> + pedwarn (input_location, OPT_pedantic,
> + "redefinition of typedef %q+D", newdecl);
> locate_old_decl (olddecl);
> }
>
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: Disallow redefinition of variably modified typedefs
On Sat, Mar 19, 2011 at 01:20:41PM +0100, Richard Guenther wrote: > On Sat, Mar 19, 2011 at 12:29 AM, Joseph S. Myers > wrote: > > This week's London WG14 meeting decided that typedef redefinition > > should not be allowed in the case of variably modified types. This > > patch implements this, giving an error for such redefinitions. > > > > Bootstrapped with no regressions on x86_64-unknown-linux-gnu. Applied > > to mainline. Any comments from other RMs about whether this should go > > in 4.6 as well, to avoid 4.6.0 being more lenient in this area than > > both 4.5 and 4.7? This is much the same issue as for anonymous > > structs and unions, but for a much more obscure case. > > > > (These two patches cover the only two cases of C1X features that were > > fully implemented for 4.6 according to the pre-London draft, and then > > changed in London. The post-London document will be going to > > enquiry-stage ITTF/JTC1 ballot so if that passes there should be no > > more technical changes before publication.) > > I think it should go into 4.6.0 as well. Seconded. Jakub
Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)
On 03/19/2011 08:15 AM, Jakub Jelinek wrote: On Sat, Mar 19, 2011 at 08:08:48AM -0400, Kenneth Zadeck wrote: On 03/19/2011 05:19 AM, Paolo Bonzini wrote: On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck wrote: yes, but i think that the reason this is a pr is that it seems to be needed for correctness. Note that df_get_bb_dirty is defaulting to "return false", not "abort". This is what tricked crossjumping and caused the bug. where does the compiler fail if you change it to abort, (after doing the check from jakub's patch)? With neither of the patches of mine for this issue, df_get_bb_dirty would ICE with added gcc_assert (df&& df_live); The point is that df_get_bb_dirty was silently returning false even for blocks which had lr not recumputed when live wasn't computed at all. So live isn't needed for crossjumping correctness, assuming df_get_bb_dirty is compatible with what df_get_live_out does (the first patch). Jakub i think that there are two separate questions here: 1) should your original patch go in as you did it, or should it go in with the last "return false" be an abort? 2) which dataflow problems should be used at what points during optimization at any level. There is, and will always be, a question of precision vs cost. Live is both more expensive and more precise. The questions about the second patch with respect to crossjumping is: does the extra precision either make any difference? and is required for correctness?My guess is that it most likely is not required for correctness and may not even make any difference. However, I never looked closely at what cross jumping did - i get the feeling that Paolo has more experience here so I defer to him on this. I do believe in the principal that if someone specifies something like cross jumping explicitly, that they get substantially the same optimization at whatever -O level they run it. So if live does make any difference in the quality of the optimization, then we should turn on live to run it. However, if it does not, then some form of your first patch is all that is necessary. kenny
Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)
On Sat, Mar 19, 2011 at 08:48:55AM -0400, Kenneth Zadeck wrote:
> i think that there are two separate questions here:
>
> 1) should your original patch go in as you did it, or should it go
> in with the last "return false" be an abort?
bool
df_get_bb_dirty (basic_block bb)
{
return bitmap_bit_p ((df_live
? df_live : df_lr)->out_of_date_transfer_functions,
bb->index);
}
would IMHO work equally well (no need to assert IMHO, it isn't much
different from just segfaulting). From what I can see, df_get_bb_dirty
is called from ifcvt (both passes, but both are guarded with optimize > 0
and happen while df is computed) and crossjumping (run with -fcrossjumping
even at -O0, but after pass_df_initialize_no_opt, so df_lr is computed too
at least, if not even df_live).
I'd need to bootstrap/regtest it of course, but I don't expect any failures.
> 2) which dataflow problems should be used at what points during
...
> However, if it does not, then some form of your first patch is all
> that is necessary.
I believe it doesn't make any difference, but I'll let Paolo comment on it.
I could try to write a patch that would check for any differences
(basically compute for -O2 -fcrossjumping live_union from both DF_LR_OUT (bb)
and df_get_live_out (bb) and if it is different, run can_move_*across twice
and see whether it makes any difference).
Jakub
Re: Can't use SImode as Pmode for x32
On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek wrote:
> On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
>> On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson wrote:
>> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> >> X86 backend uses Pmode for hardware pointer size. Changes
>> >> it to 32bit for x32, which is really 64bit process, breaks many
>> >> assumptions of x86 backend. push/pop/call is just the tip of
>> >> the iceberg.
>> >
>> > Please enumerate "many assumptions". I can't think of any off
>> > the top of my head.
>> >
>>
>> I don't have a complete list. gen_push is one of them:
>>
>> static rtx
>> gen_push (rtx arg)
>> {
>> struct machine_function *m = cfun->machine;
>>
>> if (m->fs.cfa_reg == stack_pointer_rtx)
>> m->fs.cfa_offset += UNITS_PER_WORD;
>> m->fs.sp_offset += UNITS_PER_WORD;
>>
>> return gen_rtx_SET (VOIDmode,
>> gen_rtx_MEM (Pmode,
>> gen_rtx_PRE_DEC (Pmode,
>> stack_pointer_rtx)),
>> arg);
>> }
>>
>> You can only push/pup 64bit in hardware 64bit mode.
>
> That's still push/pop/call. And you can certainly use a Pmode (== SImode)
> stack_pointer_rtx to describe it too, push/pop reference %rsp just
> implicitly. For the MEM you would just use DImode for x32 in that case,
> or for <= 32 bit pushes you could describe it as a SImode MEM with
> PRE_MODIFY inside of it.
Because TARGET_MEM_REF only works on ptr_mode:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00655.html
x32 accepts (%eax,%ebx,4).
> For addresses, you could use 32-bit regs (i.e. addr32 prefix) by default,
> perhaps with machine reorg optimizing away some of the addr32 prefixes when
> it can prove the base register is already zero extended, and if there is no
> added or very small one.
You can change 32bit registers in memory address to 64bit only if there is
no index register.
I will try ptr_mode == SImode and report any new problems.
Thanks.
--
H.J.
Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)
On 03/19/2011 09:01 AM, Jakub Jelinek wrote:
On Sat, Mar 19, 2011 at 08:48:55AM -0400, Kenneth Zadeck wrote:
i think that there are two separate questions here:
1) should your original patch go in as you did it, or should it go
in with the last "return false" be an abort?
bool
df_get_bb_dirty (basic_block bb)
{
return bitmap_bit_p ((df_live
? df_live : df_lr)->out_of_date_transfer_functions,
bb->index);
}
would IMHO work equally well (no need to assert IMHO, it isn't much
different from just segfaulting). From what I can see, df_get_bb_dirty
is called from ifcvt (both passes, but both are guarded with optimize> 0
and happen while df is computed) and crossjumping (run with -fcrossjumping
even at -O0, but after pass_df_initialize_no_opt, so df_lr is computed too
at least, if not even df_live).
I'd need to bootstrap/regtest it of course, but I don't expect any failures.
i think that this is the right way to go.my view is not just what
the code currently does, but also from the perspective of the way i want
this to work as the back ends evolve.
2) which dataflow problems should be used at what points during
...
However, if it does not, then some form of your first patch is all
that is necessary.
I believe it doesn't make any difference, but I'll let Paolo comment on it.
I could try to write a patch that would check for any differences
(basically compute for -O2 -fcrossjumping live_union from both DF_LR_OUT (bb)
and df_get_live_out (bb) and if it is different, run can_move_*across twice
and see whether it makes any difference).
yes, see if paolo wants to add anything here.
Jakub
Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()
On Thu, Mar 17, 2011 at 5:21 AM, FX wrote: > Thanks for the review! > >> - Use the type size_t for tempdirlen as that is the return type of >> strlen() and argument type for get_mem(). >> >> - You can use a const size_t variable for the length of the string >> "slash" rather than calling strlen() in the do-while loop. > > Both OK. > >> - Don't set errno as we anyway loop until we successfully open a file >> with O_CREAT|O_EXCL. > > No, if I don't set errno, the continue statement will not iteration the loop, > as the condition (fd == -1 && errno == EEXIST) is false. Unless I don't > understand what you mean. > The new test failed on Linux/x86. -- H.J.
Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()
> The new test failed on Linux/x86. Yes, it might if you have a low limit on the number of concurrently open files. I've lowered the number to 30 (revision 171180). FX
Re: PATCH: PR rtl-optimization/47502: Never combine asm statement
On Fri, Mar 18, 2011 at 3:39 PM, Richard Henderson wrote:
> On 03/18/2011 02:51 PM, H.J. Lu wrote:
>> See analysis in:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47502
>
> You're patching the wrong place. See can_combine_p,
> which can test for specific sources, rather than
> cant_combine_insn_p which has no access to sources.
>
I can no longer trigger the failure. But I'd like to add those
2 testcases. OK for trunk?
Thanks.
--
H.J.
---
2011-03-19 H.J. Lu
PR rtl-optimization/47502
* gcc.target/i386/pr47502-1.c: New.
* gcc.target/i386/pr47502-2.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/i386/pr47502-1.c
b/gcc/testsuite/gcc.target/i386/pr47502-1.c
new file mode 100644
index 000..727afe9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr47502-1.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+void
+foo (const void *x, void *y, long y)
+{
+ asm volatile ("" :: "c" ((x)), "d" ((y)), "S" (y));
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr47502-2.c
b/gcc/testsuite/gcc.target/i386/pr47502-2.c
new file mode 100644
index 000..1f57ea0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr47502-2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int
+foo (int how, const void *set, void *oset)
+{
+ int resultvar;
+ asm volatile (""
+: "=a" (resultvar)
+: "0" (14) , "b" (how), "c" ((set)), "d" ((oset)),
"S" (65 / 8) : "memory", "cc");
+ return resultvar;
+}
Re: Can't use SImode as Pmode for x32
On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek wrote:
> On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
>> On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson wrote:
>> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> >> X86 backend uses Pmode for hardware pointer size. Changes
>> >> it to 32bit for x32, which is really 64bit process, breaks many
>> >> assumptions of x86 backend. push/pop/call is just the tip of
>> >> the iceberg.
>> >
>> > Please enumerate "many assumptions". I can't think of any off
>> > the top of my head.
>> >
>>
>> I don't have a complete list. gen_push is one of them:
>>
>> static rtx
>> gen_push (rtx arg)
>> {
>> struct machine_function *m = cfun->machine;
>>
>> if (m->fs.cfa_reg == stack_pointer_rtx)
>> m->fs.cfa_offset += UNITS_PER_WORD;
>> m->fs.sp_offset += UNITS_PER_WORD;
>>
>> return gen_rtx_SET (VOIDmode,
>> gen_rtx_MEM (Pmode,
>> gen_rtx_PRE_DEC (Pmode,
>> stack_pointer_rtx)),
>> arg);
>> }
>>
>> You can only push/pup 64bit in hardware 64bit mode.
>
> That's still push/pop/call. And you can certainly use a Pmode (== SImode)
> stack_pointer_rtx to describe it too, push/pop reference %rsp just
> implicitly. For the MEM you would just use DImode for x32 in that case,
> or for <= 32 bit pushes you could describe it as a SImode MEM with
> PRE_MODIFY inside of it.
>
Operations on stack and frame pointers, like push/pop, require stack
and frame pointers in DImode. Even if I use word_mode in gen_push
and gen_pop, I got
[hjl@gnu-6 pmode-1]$ cat x.i
extern void abort (void) __attribute__ ((__nothrow__)) __attribute__
((__noreturn__));
typedef int DItype __attribute__ ((mode (DI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
void
foo (DItype a, DItype b)
{
const DItype w = (UDItype) a + (UDItype) b;
if (w < a)
abort ();
}
[hjl@gnu-6 pmode-1]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32
x.i
x.i: In function \u2018foo\u2019:
x.i:10:1: error: unrecognizable insn:
(insn/f 22 5 23 2 (set (mem:SI (pre_dec:DI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp)) x.i:6 -1
(nil))
x.i:10:1: internal compiler error: in insn_default_length, at
config/i386/i386.md:600
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 pmode-1]$
--
H.J.
[Patch, Fortran, 4.7] PR 18918 - Add initial support for a coarray communication library
This patch adds a first support for a coarray communication library.
Note: The patch does not yet allow communication (i.e. access to remote
coarrays); thus it is only of limited practical use. (If you restrict
yourself to barriers and this_image/num_images, you can already
parallelize.)
This patch contains two parts: (a) The front end part, which mainly adds
some library calls. (b) Two communication library implementations.
(Single-image library and a very initial MPI version.)
To (a): The patch adds library calls for
- Initialization and finalization
- STOP/ERROR STOP
- SYNC ALL/SYNC IMAGES
- CRITICAL block
- num_images() and this_image()*
- Additionally, SYNC MEMORY is handled (via BUILT_IN_SYNCHRONIZE)
(* only no-argument version)
To (b): The MPI library currently requires MPI 2.x, does not work for
SYNC IMAGE(), and is very rough.
The single-image library version is the library equivalent to
-fcoarray=single, but less efficient. Its purpose is for testing - and
to avoid recompilation (e.g. if you do not have the source code).
My idea is to place those library into libgfortran/caf. The user has to
compile them themselves and link it then to their "gfortran
-fcoarray=lib" compiled program. (Cf.
http://gcc.gnu.org/ml/fortran/2011-03/msg3.html).
Build and regtested on x86-64-linux.
(a) Is the patch OK for the 4.7 trunk?
(b) Are the libgfortrancaf.h, libgfortrancaf_mpi.c and
libgfortrancaf_single.c OK for inclusion at libgfortran/caf?
* * *
TODO:
- Documentation about the usage of coarrays - and in particular calling
the library for programs with a non-gfortran main program
- Add test-suite support, where the user specifies (e.g. via environment
variables?) the to-be-linked coarray communication library (e.g.
"-lgfortrancaf_mpi") and the command to run it (e.g. "mpiexec -n 3")
- autoconf work: Allow to automatically build the communication library
(statically), in particular the single-image version.
And the obvious extensions:
- Implement ATOMIC, LOCK, coarray registration/communication, and other
left overs
- Properly implement an MPI version.
(I plan to concentrate on the front-end (FE) version - and will only do
a minimal version for the single/MPI library. I hope that someone else
will take over that part. If not, I might do it after the FE part is
implemented. Maybe, one also finds a student, who wants to work on it
via Google's Summer of Code program.)
Tobias
2011-03-19 Tobias Burnus
PR fortran/18918
* gfortran.h (gfc_isym_id): Rename GFC_ISYM_NUMIMAGES to
GFC_ISYM_NUM_IMAGES.
(gfc_fcoarray): Add GFC_FCOARRAY_LIB.
* intrinsic.c (add_functions): Update due to GFC_ISYM_NUM_IMAGES
rename.
* invoke.texi (-fcoarray=): Document "lib" argument.
* iresolve.c (gfc_resolve_this_image): Fix THIS IMAGE().
* libgfortran.h (libgfortran_stat_codes): Add comments.
* options.c (gfc_handle_coarray_option): Add -fcoarray=lib.
* simplify.c (gfc_simplify_num_images, gfc_simplify_this_image):
Handle GFC_FCOARRAY_LIB.
* trans.h (gfc_init_coarray_decl): New prototype.
(gfor_fndecl_caf_init, gfor_fndecl_caf_finalize,
gfor_fndecl_caf_critical, gfor_fndecl_caf_end_critical,
gfor_fndecl_caf_sync_all, gfor_fndecl_caf_sync_images,
gfor_fndecl_caf_error_stop, gfor_fndecl_caf_error_stop_str,
gfort_gvar_caf_num_images, gfort_gvar_caf_this_image):
New global variables.
* trans-decl.c: Declare several CAF functions (cf. above).
(gfc_build_builtin_function_decls): Initialize those.
(gfc_init_coarray_decl): New function.
(create_main_function): Call CAF init/finalize functions.
* trans-intrinsic.c (trans_this_image, trans_num_images): New.
(gfc_conv_intrinsic_function): Call those.
* trans-stmt.c (gfc_trans_stop, gfc_trans_sync, gfc_trans_critical):
Add code for GFC_FCOARRAY_LIB.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index b64fa20..9a6907e 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -458,7 +458,7 @@ enum gfc_isym_id
GFC_ISYM_NORM2,
GFC_ISYM_NOT,
GFC_ISYM_NULL,
- GFC_ISYM_NUMIMAGES,
+ GFC_ISYM_NUM_IMAGES,
GFC_ISYM_OR,
GFC_ISYM_PACK,
GFC_ISYM_PARITY,
@@ -572,7 +572,8 @@ init_local_integer;
typedef enum
{
GFC_FCOARRAY_NONE = 0,
- GFC_FCOARRAY_SINGLE
+ GFC_FCOARRAY_SINGLE,
+ GFC_FCOARRAY_LIB
}
gfc_fcoarray;
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index 80dbaa8..0fea078 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -2358,7 +2358,8 @@ add_functions (void)
make_generic ("null", GFC_ISYM_NULL, GFC_STD_F95);
- add_sym_0 ("num_images", GFC_ISYM_NUMIMAGES, CLASS_INQUIRY, ACTUAL_NO, BT_INTEGER, di, GFC_STD_F2008,
+ add_sym_0 ("num_images", GFC_ISYM_NUM_IMAGES, CLASS_INQUIRY, ACTUAL_NO,
+ BT_INTEGER, di, GFC_STD_F2008,
NULL, gfc_simplify_num_images, NULL);
add_sym_3 ("pack", GFC_ISYM_PACK, CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_REAL, dr, GFC_STD_F95,
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 2
Re: [Patch, Fortran, 4.7] PR 18918 - Add initial support for a coarray communication library
On Sat, Mar 19, 2011 at 05:23:17PM +0100, Tobias Burnus wrote:
>
> My idea is to place those library into libgfortran/caf. The user has to
> compile them themselves and link it then to their "gfortran
> -fcoarray=lib" compiled program. (Cf.
> http://gcc.gnu.org/ml/fortran/2011-03/msg3.html).
See below at [1].
> Build and regtested on x86-64-linux.
> (a) Is the patch OK for the 4.7 trunk?
> (b) Are the libgfortrancaf.h, libgfortrancaf_mpi.c and
> libgfortrancaf_single.c OK for inclusion at libgfortran/caf?
>
Just a comment on names. Since you are planning to install
these in libgfortran/caf, please shorten the file names to
caf.h, caf_mpi.c, and caf_single.c. Consider this a friendly
RSI prevention measure.
[1] I don't understand what you mean by the above. Are you saying that
gcc would install caf.h, caf_mpi.c, etc in say
lib/gcc/i386-unknown-freebsd9.0/4.7.0/libgfortran
and a user would need to do
gfortran -fcoarray=mpi file.f90
${PATH}/lib/gcc/i386-unknown-freebsd9.0/4.7.0/libgfortran/caf_mpi.c
to compile her code to use coarrays?
--
Steve
Re: [PATCH, i386]: Use indirect functions some more
On Fri, Mar 18, 2011 at 10:08 PM, Richard Henderson wrote:
> On 03/18/2011 01:40 PM, Uros Bizjak wrote:
>> if (mode == SFmode)
>> - insn = gen_truncxfsf2 (operands[0], reg);
>> + insn = gen_truncxfsf2;
>> else if (mode == DFmode)
>> - insn = gen_truncxfdf2 (operands[0], reg);
>> + insn = gen_truncxfdf2;
>> else
>> gcc_unreachable ();
>
> Why is this a good thing? Surely the direct calls are much
> better predicted by the CPU...
I was hoping that cmove will be generated in this particular case for
64bit targets. I'm not aware of any other differences between direct
and indirect calls...
OTOH, call arguments do not need to be set-up twice when indirect call
is used. Please note that these are not CSE'd as shown by comparing
two examples below on 32bit i386:
--cut here--
#include
#include
int foo (int, int);
int bar (int, int);
void test (int a, int b, int c)
{
int x;
if (c == 1)
x = foo (a, b);
else if (c == 2)
x = bar (a, b);
else
abort ();
printf ("%i\n", x);
}
void test_ (int a, int b, int c)
{
int (*x)(int, int);
if (c == 1)
x = foo;
else if (c == 2)
x = bar;
else
abort ();
printf ("%i\n", x (a, b));
}
--cut here--
test:
subl$28, %esp
movl40(%esp), %eax
movl32(%esp), %edx
movl36(%esp), %ecx
cmpl$1, %eax
je .L6
cmpl$2, %eax
jne .L4
movl%ecx, 4(%esp)
movl%edx, (%esp)
callbar
.L3:
movl%eax, 36(%esp)
movl$.LC0, 32(%esp)
addl$28, %esp
jmp printf
.p2align 4,,7
.p2align 3
.L6:
movl%ecx, 4(%esp)
movl%edx, (%esp)
callfoo
jmp .L3
.L4:
callabort
test_:
subl$28, %esp
movl40(%esp), %eax
movl32(%esp), %edx
movl36(%esp), %ecx
cmpl$1, %eax
je .L9
cmpl$2, %eax
jne .L11
movl$bar, %eax
.L8:
movl%ecx, 4(%esp)
movl%edx, (%esp)
call*%eax
movl$.LC0, 32(%esp)
movl%eax, 36(%esp)
addl$28, %esp
jmp printf
.p2align 4,,7
.p2align 3
.L9:
.cfi_restore_state
movl$foo, %eax
jmp .L8
.L11:
callabort
> I can certainly understand sinking the call to emit_insn, as
> in the second hunk; that ought to save code size. Though the
> compiler really ought to be able to figure that out itself.
Currently, it does not.
Uros.
Re: [Patch, Fortran, 4.7] PR 18918 - Add initial support for a coarray communication library
Steve Kargl wrote:
On Sat, Mar 19, 2011 at 05:23:17PM +0100, Tobias Burnus wrote:
My idea is to place those library into libgfortran/caf. The user has to
compile them themselves and link it then to their "gfortran
-fcoarray=lib" compiled program. (Cf.
http://gcc.gnu.org/ml/fortran/2011-03/msg3.html).
[1] I don't understand what you mean by the above. Are you saying that
gcc would install caf.h, caf_mpi.c, etc in say
lib/gcc/i386-unknown-freebsd9.0/4.7.0/libgfortran
and a user would need to do
gfortran -fcoarray=mpi file.f90
${PATH}/lib/gcc/i386-unknown-freebsd9.0/4.7.0/libgfortran/caf_mpi.c
to compile her code to use coarrays?
Well, the code is only in the GCC source code and not in the installed
directory (as in your example); and the -fcoarray= argument is "lib" and
not "mpi".
But the answer is: Essentially, yes. One has the same issue as with
gfortran's -fexternal-blas and with GCC's -mveclibabi=.
Namely, there is a lot of system dependency. For BLAS there exists
Netlib's and several vendor versions and also for ACML/SVML on might
have different file names and library paths.
While the single-image library version could be directly compiled and
linked, that's not possible with MPI. There exist too many MPI
implementations and too much system dependence to do this automatically.
Thus, the procedure is usually the following; one compiles the file once
- for real deployment, one would do something like the following (e.g.
as HPC administrator or as Linux distributor):
mpicc -O2 -flto -c $GCC_SOURCE/libgfortran/caf/libgfortrancaf_mpi.c
ar rcs libgfortrancaf_mpi.a libgfortrancaf_mpi.o
cp libgfortrancaf_mpi.a /usr/lib64/mpi/gcc/openmpi/lib64
(As a user with self-compiled gfortran, one would copy it, e.g., to
$HOME/gcc-trunk/lib{,64}.)
And when compiling a coarray program, one simply specifies the library as in
mpif90 -fcoarray=lib *.f90 -lgfortrancaf_mpi
In the future, one could automatically generate the single-image library
and - when passing some MPI-settings to ./configure - also a version for
MPI, which would then be installed in, e.g.,
$prefix/lib64/gcc/x86_64-gnu-linux/4.7/. [1]
(For the shared-memory version [-fcoarray=shared] one will automatically
link the library, but first the library implementation has to work,
before one starts another construction site. The advantage for the
shared-library version is that one has a known ABI for libpthread - and
might be able to share some of the existing libgomp functions.)
If you have a better idea how one should handle the MPI-wrapper library,
I would be interested. (Besides, I am looking for a full review of
either the library or of the front-end patch ;-)
* * *
> (b) Are the libgfortrancaf.h, libgfortrancaf_mpi.c and
> libgfortrancaf_single.c OK for inclusion at libgfortran/caf?
Just a comment on names. Since you are planning to install
these in libgfortran/caf, please shorten the file names to
caf.h, caf_mpi.c, and caf_single.c. Consider this a friendly
RSI prevention measure.
I was thinking of using the lib- prefix for linking as one should at the
end generate a lib*.a file (cf. libgfortran.h). And I feared that
libcaf.* might be ambiguous, if one places into $prefix/lib/. But I am
fine with libcaf.h or with caf.h if you think that it is preferable.
Tobias
[1] Cf. Ralf's comments at
http://gcc.gnu.org/ml/fortran/2011-03/msg4.html
Re: [PATCH] Document --with-plugin-ld
On Fri, 18 Mar 2011, Richard Guenther wrote:
> ! @item --with-plugin-ld=@var{pathname}
> ! Enable an alternate linker to be used at link-time optimization (LTO)
> ! link time when @option{-fuse-linker-plugin} is enabled.
I will admit that "link-time optimization link time" may be a bit
confusing. ;-) Might
Enable an alternate linker to be used at link time when link-time
optimization (LTO) is enabled and @option{-fuse-linker-plugin} has
been specified.
be a suitable alternative wording, or would that change what you had
in mind?
Happy to apply that change if you agree.
Gerald
Re: [patch, fortran] Function call optimization
Am 19.03.2011 00:23, schrieb Tobias Burnus:
I have not followed the discussion nor have I fully read the patch, but
what's the reason for allowing ELEMENTAL functions?
Here's an updated version of the patch, which removes the elemental
functions as well. I have also added an option which allows full access
to all function call eliminations, so if any user wants it, it is there.
(I know I will use it :-) This option is not enabled by any
optimization option.
Regression-tested. Before committing, I'll check on the status of the
gfc_free removal patch, and re-test. Also tested with "make dvi" and
"make info".
OK for trunk?
Thomas
2010-03-14 Thomas Koenig
PR fortran/22572
* gfortran.h (gfc_option_t) : Add
flag_aggressive_function_elimination.
* lang.opt: Add faggressive-function-elimination.
* invoke.texi: Document -faggressive-function-elimination.
* frontend_passes (expr_array): New static variable.
(expr_size): Likewise.
(expr_count): Likewise.
(current_code): Likewise.
(current_ns): Likewise.
(gfc_run_passes): Allocate and free space for expressions.
(compare_functions): New function.
(cfe_expr): New function.
(create_var): New function.
(cfc_expr_0): New function.
(cfe_code): New function.
(optimize_namespace): Invoke gfc_code_walker with cfe_code
and cfe_expr_0.
* options.c (gfc_init_options): Handle
flag_aggressive_function_elimination.
(gfc_handle_option): Likewise.
2010-03-14 Thomas Koenig
PR fortran/22572
* gfortran.dg/function_optimize_1.f90: New test.
* gfortran.dg/function_optimize_2.f90: New test.
Index: gfortran.h
===
--- gfortran.h (Revision 170960)
+++ gfortran.h (Arbeitskopie)
@@ -2232,6 +2232,7 @@ typedef struct
int flag_whole_file;
int flag_protect_parens;
int flag_realloc_lhs;
+ int flag_aggressive_function_elimination;
int fpe;
int rtcheck;
Index: lang.opt
===
--- lang.opt (Revision 170960)
+++ lang.opt (Arbeitskopie)
@@ -278,6 +278,10 @@ d
Fortran Joined
; Documented in common.opt
+faggressive-function-elimination
+Fortran
+Eliminate multiple function invokations also for impure functions
+
falign-commons
Fortran
Enable alignment of COMMON blocks
Index: invoke.texi
===
--- invoke.texi (Revision 170960)
+++ invoke.texi (Arbeitskopie)
@@ -1468,6 +1468,18 @@ need to be in effect.
An allocatable left-hand side of an intrinsic assignment is automatically
(re)allocated if it is either unallocated or has a different shape. The
option is enabled by default except when @option{-std=f95} is given.
+
+@item -faggressive-function-elimination
+@opindex @code{faggressive-function-elimination}
+@cindex Elimination of functions with identical argument lists
+Functions with identical argument lists are eliminated within
+statements, regardless of whether these functions are marked
+@code{PURE} or not. For example, in
+@smallexample
+ a = f(b,c) + f(b,c)
+@end smallexample
+there will only be a single call to @code{f}.
+
@end table
@xref{Code Gen Options,,Options for Code Generation Conventions,
@@ -1475,7 +1487,6 @@ gcc,Using the GNU Compiler Collection (GCC)}, for
offered by the GBE
shared by @command{gfortran}, @command{gcc}, and other GNU compilers.
-
@c man end
@node Environment Variables
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 170960)
+++ frontend-passes.c (Arbeitskopie)
@@ -40,6 +40,21 @@ static bool optimize_trim (gfc_expr *);
static int count_arglist;
+/* Pointer to an array of gfc_expr ** we operate on, plus its size
+ and counter. */
+
+static gfc_expr ***expr_array;
+static int expr_size, expr_count;
+
+/* Pointer to the gfc_code we currently work on - to be able to insert
+ a statement before. */
+
+static gfc_code **current_code;
+
+/* The namespace we are currently dealing with. */
+
+gfc_namespace *current_ns;
+
/* Entry point - run all passes for a namespace. So far, only an
optimization pass is run. */
@@ -48,9 +63,16 @@ gfc_run_passes (gfc_namespace *ns)
{
if (optimize)
{
+ expr_size = 20;
+ expr_array = XNEWVEC(gfc_expr **, expr_size);
+
optimize_namespace (ns);
if (gfc_option.dump_fortran_optimized)
gfc_dump_parse_tree (ns, stdout);
+
+ /* FIXME: The following should be XDELETEVEC(expr_array);
+ but we cannot do that because it depends on free. */
+ gfc_free (expr_array);
}
}
@@ -106,11 +128,237 @@ optimize_expr (gfc_expr **e, int *walk_subtrees AT
return 0;
}
+/* Compare two functions for equality. We could use gfc_dep_compare_expr
+ except that
Re: [Patch, Fortran, 4.7] PR 18918 - Add initial support for a coarray communication library
Hi Tobias,
> void
> _gfortran_caf_init (int *argc, char ***argv, int *this_image, int *num_images)
> {
> int flag;
>
> /* The following is only the case if one does not have a Fortran
> main program. */
> MPI_Initialized (&flag);
> if (!flag)
> MPI_Init (argc, argv);
[...]
> }
>
>
> /* Finalize coarray program. Note: This is only called before the
>program ends; thus the MPI_Initialized status of _gfortran_caf_init
>does not play a role. */
>
> void
> _gfortran_caf_finalize (void)
> {
> MPI_Win_free (&caf_world_window);
> MPI_Finalize ();
> }
Some MPI implementations require that the thread that called MPI_Init
also calls MPI_Finalize. How can this be ensured in this case?
(Sure is something that can be fixed later, but maybe it is not relevant
for this?)
Thanks,
Ralf
[PATCH 0/4] Remove (lots of) lazy call graph node construction
Hi, I believe the general consensus is that lazy call graph node creation is no longer a good idea and a few of us have seen bugs caused by a creation of a node when we did not expect it. Therefore I embarked on getting rid of it. In the process I quickly realized it would be difficult to do that completely but it is certainly possible to weed it out of most places where it is not necessary. We can then tackle the remaining places separately. These patches are meant to be applied on top of http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01170.html The first patch in the series removes the cgraph_node function. Most of its callers should use already existing cgraph_get_node instead, for the others there are new functions: - craph_create_node will create a node but fail on assert if there already is a node for the declaration - cgraph_get_create_node is the new lazy node creation. I did not want to continue using cgraph_node name because I really thought the it was unfortunate and the new name will also help us to discourage potential new uses and isolate those that we might want to convert to a non-lazy way of creating nodes later. - cgraph_do_get_node is a simple wrapper around cgraph_get_node which checking_asserts that the return value is not NULL. I found it very useful while developing the patch and think it can be sometimes useful even in the longer term, for example when the result is stored in some data structure which is to be used later. If the general consensus is that we don't want it, it is easy to remove it from the patch. When I was processing calls to cgraph_node I first tried to determine if it is possible for cgraph_get_node to return NULL. If it was, I either lazily-created the node or assumed the default node properties depending on the nature of the call. If I thought NULL should not be returned, I used cgraph_do_get_node if the code would not immediately segfault. The places which still need lazy node construction can be roughly divided into the following categories: - Stuff called from the front ends. Most noticeably, nested functions are organized in a tree of call graph nodes for some time, the leaves are entered first and the cgraph_(create_)node creates the encapsulation one for DECL_CONTEXT. And then there are aliases. And perhaps more stuff I already forgot about. In most cases, keeping it is not harmful and even sensible. - Almost all of cgraphbuild.c. But that basically makes sense. - Sometimes the decl of call statement is a builtin that is newly created by folding. If it does not have a node at that point, we might trigger an assert. I have tried to verify diligently that NULL cannot be returned at places where I don't handle it and of course I tested the changes thoroughly. Nevertheless, there are few places where I'd appreciate if someone confirmed my conclusions. These are: - lower_emutls_function_body honk and - hunks in ipa-struct-reorg.c and ipa-type-escape.c ...just in case anyone really cared ;-) The patch is not very complex but I understand the scope it changes is vast. In order to ease its assessment, all changes in front-ends change calls to cgraph_node to calls to cgraph_get_create_node (except an obvious assert in java). I hope that this will mean the big first patch will eventually not require approval of individual front-end maintainers. There are three simple subsequent patches which change the calls in front-end specific code but those are much smaller and not that crucial to the whole effort. I have successfully bootstrapped and tested "all,ada" on x86_64-linux and "c,c++,fortran" on i686. I have successfully checked "c,c++,fortran" on ia64 and (an almost identical patch) on sparc64. Sorry for the long email and long patch to review. I understand there will be comments and suggestions and I thank in advance for them. At the same time I think it is really a good idea to commit something like this early in stage 1. Tomorrow I'm leaving for a four day vacation (I'll be back on Thursday) so please be patient when waiting for my reply. Thanks! Martin
[PATCH 3/4] A tweak to fortran -> call graph interface
Hi, it seems to me that fortran can call cgraph_create_node directly without checking for its existence first. Thanks, Martin 2011-03-18 Martin Jambor * trans-decl.c (gfc_generate_function_code): Call cgraph_create_node instead of cgraph_get_create_node. Index: src/gcc/fortran/trans-decl.c === --- src.orig/gcc/fortran/trans-decl.c 2011-03-18 19:45:10.0 +0100 +++ src/gcc/fortran/trans-decl.c2011-03-18 19:45:12.0 +0100 @@ -4924,7 +4924,7 @@ gfc_generate_function_code (gfc_namespac if (decl_function_context (fndecl)) /* Register this function with cgraph just far enough to get it added to our parent's nested function list. */ -(void) cgraph_get_create_node (fndecl); +(void) cgraph_create_node (fndecl); else cgraph_finalize_function (fndecl, true);
[PATCH 2/4] Tweaks to C++ -> call graph interface
I concede that my understanding of the C++ front-end inner workings
are quite narrow and so the folling is basically a suggestion. But it
seems to me that at a few places where C++ queries the call graph for
a node, the lazy node creation is not necessary. If a maintainer can
verify and approve (parts of) this after the big patch is committed,
it would be a nice cleanup too.
Thanks,
Martin
2011-03-18 Martin Jambor
cp/
* class.c (cp_fold_obj_type_ref): Call cgraph_get_node instead of
cgraph_get_create_node.
* decl2.c (cxx_callgraph_analyze_expr): Call cgraph_do_get_node
instead of cgraph_get_create_node.
(cp_write_global_declarations): Call cgraph_get_node instead of
cgraph_get_create_node.
* method.c (make_alias_for_thunk): Call cgraph_do_get_node instead
of cgraph_get_create_node.
(use_thunk): Likewise.
* optimize.c (maybe_clone_body): Call cgraph_same_body_alias only
when flag_syntax_only is not set. Call cgraph_do_get_node instead of
cgraph_get_create_node.
(maybe_clone_body): Call cgraph_get_node instead of
cgraph_get_create_node.
Index: src/gcc/cp/class.c
===
--- src.orig/gcc/cp/class.c 2011-03-18 19:34:07.0 +0100
+++ src/gcc/cp/class.c 2011-03-18 19:34:38.0 +0100
@@ -8405,7 +8405,7 @@ cp_fold_obj_type_ref (tree ref, tree kno
DECL_VINDEX (fndecl)));
#endif
- cgraph_get_create_node (fndecl)->local.vtable_method = true;
+ cgraph_get_node (fndecl)->local.vtable_method = true;
return build_address (fndecl);
}
Index: src/gcc/cp/decl2.c
===
--- src.orig/gcc/cp/decl2.c 2011-03-18 19:34:07.0 +0100
+++ src/gcc/cp/decl2.c 2011-03-18 19:34:39.0 +0100
@@ -3375,12 +3375,12 @@ cxx_callgraph_analyze_expr (tree *tp, in
case PTRMEM_CST:
if (TYPE_PTRMEMFUNC_P (TREE_TYPE (t)))
cgraph_mark_address_taken_node (
- cgraph_get_create_node (PTRMEM_CST_MEMBER (t)));
+ cgraph_do_get_node (PTRMEM_CST_MEMBER (t)));
break;
case BASELINK:
if (TREE_CODE (BASELINK_FUNCTIONS (t)) == FUNCTION_DECL)
cgraph_mark_address_taken_node (
- cgraph_get_create_node (BASELINK_FUNCTIONS (t)));
+ cgraph_do_get_node (BASELINK_FUNCTIONS (t)));
break;
case VAR_DECL:
if (DECL_CONTEXT (t)
@@ -3893,7 +3893,7 @@ cp_write_global_declarations (void)
if (!DECL_EXTERNAL (decl)
&& decl_needed_p (decl)
&& !TREE_ASM_WRITTEN (decl)
- && !cgraph_get_create_node (decl)->local.finalized)
+ && !cgraph_get_node (decl)->local.finalized)
{
/* We will output the function; no longer consider it in this
loop. */
Index: src/gcc/cp/method.c
===
--- src.orig/gcc/cp/method.c2011-03-18 19:34:07.0 +0100
+++ src/gcc/cp/method.c 2011-03-18 19:34:40.0 +0100
@@ -260,7 +260,7 @@ make_alias_for_thunk (tree function)
if (!flag_syntax_only)
{
struct cgraph_node *aliasn;
- aliasn = cgraph_same_body_alias (cgraph_get_create_node (function),
+ aliasn = cgraph_same_body_alias (cgraph_do_get_node (function),
alias, function);
DECL_ASSEMBLER_NAME (function);
gcc_assert (aliasn != NULL);
@@ -379,7 +379,7 @@ use_thunk (tree thunk_fndecl, bool emit_
a = nreverse (t);
DECL_ARGUMENTS (thunk_fndecl) = a;
TREE_ASM_WRITTEN (thunk_fndecl) = 1;
- cgraph_add_thunk (cgraph_get_create_node (function), thunk_fndecl, function,
+ cgraph_add_thunk (cgraph_do_get_node (function), thunk_fndecl, function,
this_adjusting, fixed_offset, virtual_value,
virtual_offset, alias);
Index: src/gcc/cp/optimize.c
===
--- src.orig/gcc/cp/optimize.c 2011-03-18 19:34:07.0 +0100
+++ src/gcc/cp/optimize.c 2011-03-18 19:34:40.0 +0100
@@ -309,8 +309,9 @@ maybe_clone_body (tree fn)
&& (!DECL_ONE_ONLY (fns[0])
|| (HAVE_COMDAT_GROUP
&& DECL_WEAK (fns[0])))
- && cgraph_same_body_alias (cgraph_get_create_node (fns[0]), clone,
-fns[0]))
+ && (flag_syntax_only
+ || cgraph_same_body_alias (cgraph_do_get_node (fns[0]), clone,
+fns[0])))
{
alias = true;
if (DECL_ONE_ONLY (fns[0]))
@@ -424,8 +425,8 @@ maybe_clone_body (tree fn)
/* If *[CD][12]* dtors go into the *[CD]5* comdat group and dtor is
virtual, it goes into the same comdat g
[PATCH 4/4] Tweaks to objc -> call graph interface
Hi,
thi is really only based on successful testing and not much analyzis
of the context but it seems that we don't need lazy node construction
here. It would be nice not to have it after the big patch gets in.
Thanks,
Martin
2011-03-18 Martin Jambor
* objc-act.c (mark_referenced_methods): Call cgraph_do_get_node
instead of cgraph_get_create_node.
Index: src/gcc/objc/objc-act.c
===
--- src.orig/gcc/objc/objc-act.c2011-03-18 20:21:00.0 +0100
+++ src/gcc/objc/objc-act.c 2011-03-18 20:21:05.0 +0100
@@ -4520,7 +4520,7 @@ mark_referenced_methods (void)
while (chain)
{
cgraph_mark_needed_node (
- cgraph_get_create_node (METHOD_DEFINITION (chain)));
+ cgraph_do_get_node (METHOD_DEFINITION (chain)));
chain = DECL_CHAIN (chain);
}
@@ -4528,7 +4528,7 @@ mark_referenced_methods (void)
while (chain)
{
cgraph_mark_needed_node (
- cgraph_get_create_node (METHOD_DEFINITION (chain)));
+ cgraph_do_get_node (METHOD_DEFINITION (chain)));
chain = DECL_CHAIN (chain);
}
}
[PATCH 1/4] Remove cgraph_node function and fixup all callers
Hi, I hope I explained everything in the introductory email. This patch is the core, the subsequent ones are only small tweaks in the front ends. Let me remind you this is to be applied on top of http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01170.html. (I have tested the patch on top revision 171141.) Thanks, Martin 2011-03-18 Martin Jambor * cgraph.h (cgraph_node): Remove function declaration. (cgraph_create_node): Declare. (cgraph_get_create_node): Likewise. (cgraph_do_get_node): New function. * cgraph.c (cgraph_create_node): Renamed to cgraph_create_node_1. Updated all callers. (cgraph_node): Renamed to cgraph_create_node, assert that a node for the decl does not already exist. Call cgraph_get_create_node instead of cgraph_node. (cgraph_get_create_node): New function. (cgraph_same_body_alias): Update comment. (cgraph_set_call_stmt): Call cgraph_do_get_node instead of cgraph_node. (cgraph_update_edges_for_call_stmt): Likewise. (cgraph_clone_edge): Likewise. (cgraph_create_virtual_clone): Likewise. (cgraph_set_call_stmt): Call cgraph_get_create_node instead of cgraph_node. (cgraph_local_info): Call cgraph_get_node instead of cgraph_node, handle NULL return value. (cgraph_global_info): Likewise. (cgraph_rtl_info): Likewise. (cgraph_add_new_function): Call cgraph_create_node or cgraph_get_create_node instead of cgraph_node. * cgraphbuild.c (record_reference): Call cgraph_get_create_node instead of cgraph_node. (record_eh_tables): Likewise. (mark_address): Likewise. (mark_load): Likewise. (build_cgraph_edges): Call cgraph_get_node and cgraph_get_create_node instead of cgraph_node. (rebuild_cgraph_edges): Likewise. (cgraph_rebuild_references): Call cgraph_get_node instead of cgraph_node. (remove_cgraph_callee_edges): Likewise. * cgraphunit.c (cgraph_finalize_function): Call cgraph_get_create_node instead of cgraph_node. (cgraph_mark_if_needed): Call cgraph_get_node instead of cgraph_node. (verify_cgraph_node): Likewise. (cgraph_analyze_functions): Likewise. (cgraph_preserve_function_body_p): Likewise. (save_inline_function_body): Likewise. (save_inline_function_body): Likewise. (cgraph_copy_node_for_versioning): Call cgraph_create_node instead of cgraph_node. * tree-inline.c (copy_bb): Call cgraph_get_node instead of cgraph_node. (estimate_num_insns): Likewise and handle returned NULL. (optimize_inline_calls): Call cgraph_get_node instead of cgraph_node. (tree_function_versioning): Call cgraph_do_get_node instead of cgraph_node. * lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Call cgraph_create_node instead of cgraph_node. * c-decl.c (finish_function): Call cgraph_get_create_node instead of cgraph_node. * c-family/c-gimplify.c (c_genericize): Likewise. * lto-cgraph.c (input_node): Likewise. * lto-streamer-in.c (input_function): Likewise. * except.c (set_nothrow_function_flags): Call cgraph_get_node instead of cgraph_node. * final.c (rest_of_clean_state): Likewise. * gimple-iterator.c (update_call_edge_frequencies): Likewise. * passes.c (pass_init_dump_file): Likewise. (execute_all_ipa_transforms): Likewise. (function_called_by_processed_nodes_p): Likewise. * predict.c (maybe_hot_frequency_p): Likewise. (probably_never_executed_bb_p): Likewise. (compute_function_frequency): Likewise. * tree-nested.c (check_for_nested_with_variably_modified): Likewise. (unnest_nesting_tree_1): Likewise. (lower_nested_functions): Likewise. * tree-optimize.c (execute_fixup_cfg): Likewise. (tree_rest_of_compilation): Likewise. * tree-optimize.c (execute_fixup_cfg): Likewise. (tree_rest_of_compilation): Likewise. * tree-profile.c (gimple_gen_ic_func_profiler): Likewise. * tree-sra.c (ipa_early_sra): Likewise. * tree-ssa-loop-ivopts.c (computation_cost): Likewise. * config/i386/i386.c (ix86_compute_frame_layout): Likewise. * ipa.c (record_cdtor_fn): Likewise. * ipa-inline.c (cgraph_early_inlining): Likewise. (compute_inline_parameters_for_current): Likewise. * ipa-prop.c (ipa_make_edge_direct_to_target): Likewise. * ipa-pure-const.c (local_pure_const): Likewise. * ipa-split.c (split_function): Likewise. (split_function): Likewise. (execute_split_functions): Likewise. * lto-streamer-in.c (lto_read_body): Call cgraph_do_get_node instead of cgraph_node. * omp-low.c (new_omp_context): Likewise. (create_task_copyfn)
[wwwdocs] addition to gcc-4.6/changes.html
I've committed this patch to note a change in G++, as requested in the
comments of PR c++/44499
Index: htdocs/gcc-4.6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v
retrieving revision 1.114
diff -u -r1.114 changes.html
--- htdocs/gcc-4.6/changes.html 10 Feb 2011 01:01:42 - 1.114
+++ htdocs/gcc-4.6/changes.html 19 Mar 2011 19:36:00 -
@@ -388,6 +388,17 @@
Use -fpermissive to allow the old, non-conforming behaviour.
+G++ no longer allows objects of const-qualified type to be default
+initialized unless the type has a user-declared default constructor.
+Code that fails to compile can be fixed by providing an initializer e.g.
+
+struct A { A(); };
+struct B : A { };
+const B b = B();
+
+Use -fpermissive to allow the old, non-conforming behaviour.
+
+
Runtime Library (libstdc++)
Re: [v3] Start random dists values testing
... turns out, something insane is going on with name: if I use
*c99_math anywhere the dg-require is totally ignored. For the time being
I'm simply renaming everything per the below.
Paolo.
//
2011-03-19 Paolo Carlini
* testsuite/lib/libstdc++.exp (check_v3_target_c99_math): Rename
to check_v3_target_cmath.
* testsuite/lib/dg-options.exp (dg-require-c99_math): Rename
to dg-require-cmath.
* testsuite/26_numerics/random/binomial_distribution/
operators/values.cc: Adjust.
Index: testsuite/26_numerics/random/binomial_distribution/operators/values.cc
===
--- testsuite/26_numerics/random/binomial_distribution/operators/values.cc
(revision 171183)
+++ testsuite/26_numerics/random/binomial_distribution/operators/values.cc
(working copy)
@@ -1,6 +1,6 @@
// { dg-options "-std=gnu++0x" }
// { dg-require-cstdint "" }
-// { dg-require-c99_math "" }
+// { dg-require-cmath "" }
//
// Copyright (C) 2011 Free Software Foundation, Inc.
//
Index: testsuite/lib/libstdc++.exp
===
--- testsuite/lib/libstdc++.exp (revision 171183)
+++ testsuite/lib/libstdc++.exp (working copy)
@@ -1146,7 +1146,7 @@
return $et_cstdint
}
-proc check_v3_target_c99_math { } {
+proc check_v3_target_cmath { } {
global cxxflags
global DEFAULT_CXXFLAGS
global et_c99_math
Index: testsuite/lib/dg-options.exp
===
--- testsuite/lib/dg-options.exp(revision 171183)
+++ testsuite/lib/dg-options.exp(working copy)
@@ -107,8 +107,8 @@
return
}
-proc dg-require-c99_math { args } {
-if { ![ check_v3_target_c99_math ] } {
+proc dg-require-cmath { args } {
+if { ![ check_v3_target_cmath ] } {
upvar dg-do-what dg-do-what
set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
return
Re: A problem of our Gcc mirror
On Tue, 15 Feb 2011, Mingjie Xing wrote: > The mirror site in China is unavailable for a long time. I believe it > is helpful if we can have one, though I don't know the requirements of > being a mirror. Indeed; for the time being I am removing this mirror per the patch below. David, if you can restore the server, please advise and we can include it again. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.205 diff -u -r1.205 mirrors.html --- mirrors.html31 Dec 2010 12:10:01 - 1.205 +++ mirrors.html19 Mar 2011 20:15:48 - @@ -36,7 +36,6 @@ Bulgaria: http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks to igor at onlinedirect dot bg Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, thanks to James Miller (jmiller at parentingamerica dot com). Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at skazkaforyou dot com) -China: ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/, thanks to David Deng (david99deng at yahoo dot com) France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 dot fr France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks to ftpmaint at irisa dot fr France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, thanks to ftpmaint at uvsq dot fr
Re: [patch, fortran] Function call optimization
On Saturday 19 March 2011 19:59:56 Thomas Koenig wrote:
> Am 19.03.2011 00:23, schrieb Tobias Burnus:
> > I have not followed the discussion nor have I fully read the patch, but
> > what's the reason for allowing ELEMENTAL functions?
>
> Here's an updated version of the patch, which removes the elemental
> functions as well. I have also added an option which allows full access
> to all function call eliminations, so if any user wants it, it is there.
> (I know I will use it :-) This option is not enabled by any
> optimization option.
>
> Regression-tested. Before committing, I'll check on the status of the
> gfc_free removal patch, and re-test. Also tested with "make dvi" and
> "make info".
>
> OK for trunk?
Not yet, comment here, nits below.
I'm a bit worried about the patch possibly conflicting with other
optimizations at code generation time. I'm thinking especially about cases
where we manage not to create a temporary without the patch:
- Inline intrinsics have only been for scalar cases so far, so it should not
matter for now.
- Array elementals: here it's hard to tell which one is faster; save function
calls to a temporary and use the temporary or do multiple function calls every
time (but without temporary).
- Transpose optimization: here the transpose call is changed into a direct
array access, so your patch will definitely make things worse. Even if
transpose calls are used multiple times as actual argument for example, better
create multiple descriptors than copy the whole lot to a temp. The common
function elimination should be disabled (IMO) in this case.
Mikael.
> Index: frontend-passes.c
> ===
> --- frontend-passes.c (Revision 170960)
> +++ frontend-passes.c (Arbeitskopie)
> @@ -106,11 +128,237 @@ optimize_expr (gfc_expr **e, int *walk_subtrees AT
>return 0;
> }
>
> +/* Compare two functions for equality. We could use gfc_dep_compare_expr
> + except that we also consider impure functions equal, because anybody
> + changing the return value of the function within an expression would
> + violate the Fortran standard. */
Given how much the codes match, it looks like one can move the relevant
gfc_dep_compare_expr code to a function, use that function, driving the small
differences with a flag, no?
> +
> +static bool
> +compare_functions (gfc_expr **ep1, gfc_expr **ep2)
> +{
> + gfc_expr *e1, *e2;
> +
> + e1 = *ep1;
> + e2 = *ep2;
> +
> + if (e1->expr_type != EXPR_FUNCTION || e2->expr_type != EXPR_FUNCTION)
> +return false;
> +
> + if ((e1->value.function.esym && e2->value.function.esym
> + && e1->value.function.esym == e2->value.function.esym)
> + || (e1->value.function.isym && e2->value.function.isym
> + && e1->value.function.isym == e2->value.function.isym))
> +{
> + gfc_actual_arglist *args1, *args2;
> +
> + args1 = e1->value.function.actual;
> + args2 = e2->value.function.actual;
> +
> + /* Compare the argument lists for equality. */
> + while (args1 && args2)
> + {
> + /* Bitwise xor, since C has no non-bitwise xor operator. */
> + if ((args1->expr == NULL) ^ (args2->expr == NULL))
> + return false;
> +
> + if (args1->expr != NULL && args2->expr != NULL
> + && gfc_dep_compare_expr (args1->expr, args2->expr) != 0)
> + return false;
> +
> + args1 = args1->next;
> + args2 = args2->next;
> + }
> + return args1 == NULL && args2 == NULL;
> +}
> + else
> +return false;
> +
> +}
> +
> +/* Callback function for gfc_expr_walker, called from cfe_expr_0. Put all
> + eligible function expressions into expr_array. We can't do allocatable
> + functions. */
> +
> +static int
> +cfe_expr (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
> + void *data ATTRIBUTE_UNUSED)
Please use more descriptive names.
There are 3 cfe* functions and only one has a comment explaining what cfe
means.
Something like "register_function_expr" seems to match what this function
does, but you may propose something better ;-)
> +{
> + if ((*e)->expr_type != EXPR_FUNCTION)
> +return 0;
> +
> + /* We don't do character functions (yet). */
> + if ((*e)->ts.type == BT_CHARACTER)
> +return 0;
> +
> + /* If we don't know the shape at compile time, we do not create a
temporary
> + variable to hold the intermediate result. FIXME: Change this later
when
> + allocation on assignment works for intrinsics. */
> +
> + if ((*e)->rank > 0 && (*e)->shape == NULL)
> +return 0;
> +
> + /* Skip the test for pure functions if -faggressive-function-elimination
> + is specified. */
> + if (!gfc_option.flag_aggressive_function_elimination)
> +{
> + if ((*e)->value.function.esym)
> + {
> + if ((*e)->value.function.esym->attr.allocatable)
> + return 0;
Is it expected that you allow allocatables
Re: [Patch, Fortran, 4.7] PR 18918 - Add initial support for a coarray communication library
Hi Ralf, Ralf Wildenhues wrote: Some MPI implementations require that the thread that called MPI_Init also calls MPI_Finalize. How can this be ensured in this case? Well, the front-end only calls (via the wrapper) MPI_Finalize for STOP and at the end of the main program. However, the end of the main program cannot be present if the main program is not in Fortran - and if the main program is written in Fortran, it will be MPI_Init. And in case of STOP, if the program exits, there is no chance to leave invoke MPI_Finalize of the original thread. (STOP is the normal termination, ERROR STOP is the error termination.) Thus, I think the code is OK. Thanks for scrutinizing at the code. Tobias
[PATCH Committed] [SH] Don't emit a constant pool between call and call_arg_location note
Hi,
The attached patch is to work around PR debug/48178 on SH
which causes ~2000 failures in the test for sh4-unknown-linux-gnu.
s390 has avoided the same issue with the target specific patch
and the patch below is quite similar with it.
Tested with "make -k check" on sh4-unknown-linux-gnu and applied
on trunk.
Regards,
kaz
--
2011-03-19 Kaz Kojima
PR debug/48178
* config/sh/sh.c (find_barrier): Don't emit a constant pool
between a call and its corresponding CALL_ARG_LOCATION note.
--- ORIG/trunk/gcc/config/sh/sh.c 2011-03-19 09:34:38.0 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.c 2011-03-19 15:06:13.0 +0900
@@ -4876,6 +4876,16 @@ find_barrier (int num_mova, rtx mova, rt
|| LABEL_P (from))
from = PREV_INSN (from);
+ /* Make sure we do not split between a call and its corresponding
+CALL_ARG_LOCATION note. */
+ if (CALL_P (from))
+ {
+ rtx next = NEXT_INSN (from);
+ if (next && NOTE_P (next)
+ && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
+ from = next;
+ }
+
from = emit_jump_insn_after (gen_jump (label), from);
JUMP_LABEL (from) = label;
LABEL_NUSES (label) = 1;
Re: [PATCH] libstdc++ ABI issues with __int128
2011-03-19 Jakub Jelinek * config/abi/pre/gnu.ver (CXXABI_1.3): Don't export _ZT[IS][PK]*[no]. (CXXABI_1.3.5): Export _ZTI[PK]*[no]. This looks good to me, nice catch. I'll figure out what happened with check_abi when I'm back, conductivity-wise. And: > And another question is, we still export a bunch of new _ZTS* symbols, isn't > that now pointless when we always do strcmp anyway? Yes, indeed it is as long as !__GXX_TYPEINFO_EQUALITY_INLINE && !__GXX_MERGED_TYPEINFO_NAMES for all targets that have baseline symbols. I think that is correct, since they are all linux targets. But arm-linux too? > I'm talking about > _ZTSSt16nested_exception@@CXXABI_1.3.5 OBJECT WEAK DEFAULT 21 > _ZTSNSt13__future_base11_State_baseE@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 33 > _ZTSNSt13__future_base12_Result_baseE@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 34 > _ZTSSt11regex_error@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 16 > _ZTSSt12bad_weak_ptr@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 17 > _ZTSSt17bad_function_call@@GLIBCXX_3.4.15 OBJECT WEAK DEFAULT 22 > here. Yeah, basically all _ZTS* from GLIBCXX_3.4.15 and CXXABI_1.3.5 . -benjamin
Re: Disallow redefinition of variably modified typedefs
On Sat, 19 Mar 2011, Jakub Jelinek wrote: > > I think it should go into 4.6.0 as well. > > Seconded. I have now committed both patches to 4.6 branch after bootstrap there with no regressions on x86_64-unknown-linux-gnu, and applied this release notes patch to note that these changes to semantics are included. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v retrieving revision 1.122 diff -u -r1.122 changes.html --- changes.html19 Mar 2011 19:48:34 - 1.122 +++ changes.html20 Mar 2011 01:57:31 - @@ -320,9 +320,10 @@ experimental and may change incompatibly in future releases for consistency with changes to the C1X standard draft. The following features are newly supported as described in the N1539 draft of -C1X; some other features were already supported with no compiler +C1X (with changes agreed at the March 2011 WG14 meeting); some +other features were already supported with no compiler changes being needed, or have some support but not in full accord -with N1539. +with N1539 (as amended). Static assertions (_Static_assert keyword) Typedef redefinition -- Joseph S. Myers jos...@codesourcery.com
Re: A problem of our Gcc mirror
On Sun, Mar 20, 2011 at 10:58:23AM +0800, harryxiyou wrote: > On Sun, Mar 20, 2011 at 4:18 AM, Gerald Pfeifer wrote: > > > On Tue, 15 Feb 2011, Mingjie Xing wrote: > > > The mirror site in China is unavailable for a long time. I believe it > > > is helpful if we can have one, though I don't know the requirements of > > > being a mirror. > > > > Indeed; for the time being I am removing this mirror per the patch > > below. David, if you can restore the server, please advise and we > > can include it again. > > Hi Gerald, What about others? If i can? I want to restore our China's. Could you give some advice? Thanks. Best Regards. Harry Wei. > > > > > Gerald > > > > Index: mirrors.html > > === > > RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v > > retrieving revision 1.205 > > diff -u -r1.205 mirrors.html > > --- mirrors.html31 Dec 2010 12:10:01 - 1.205 > > +++ mirrors.html19 Mar 2011 20:15:48 - > > @@ -36,7 +36,6 @@ > > Bulgaria: http://gcc.igor.onlinedirect.bg/";> > > gcc.igor.onlinedirect.bg, thanks to igor at onlinedirect dot bg > > Canada: http://gcc.parentingamerica.com";> > > http://gcc.parentingamerica.com, thanks to James Miller (jmiller at > > parentingamerica dot com). > > Canada: http://gcc.skazkaforyou.com";> > > http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at > > skazkaforyou dot com) > > -China: ftp://linuxforum.net/ftp.gcc.gnu.org/";> > > ftp://linuxforum.net/ftp.gcc.gnu.org/, thanks to David Deng > > (david99deng at yahoo dot com) > > France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";> > > ftp.lip6.fr, thanks to ftpmaint at lip6 dot fr > > France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks > > to ftpmaint at irisa dot fr > > France, Versailles: > href="ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, > > thanks to ftpmaint at uvsq dot fr > >
[patch, libgfortran] Bug 48030 - Implement read_x using fbuf_getc
Hi,
The attached patch re-implements read_x using fbuf_getc. Self explanatory.
Regression tested on x86-64 linux. No new test case needed.
Ok for trunk?
Regards,
Jerry
2011-03-19 Jerry DeLisle
PR libgfortran/48030
* io/read.c (read_x): Re-implement using fbuf_getc.
Index: read.c
===
--- read.c (revision 171191)
+++ read.c (working copy)
@@ -1186,8 +1186,8 @@
void
read_x (st_parameter_dt *dtp, int n)
{
- int length;
- char *p, q;
+ int length, q, q2;
+ char *p;
if ((dtp->u.p.current_unit->pad_status == PAD_NO || is_internal_unit (dtp))
&& dtp->u.p.current_unit->bytes_left < n)
@@ -1230,34 +1230,34 @@
n = 0;
while (n < length)
{
- q = *p;
- if (q == '\n' || q == '\r')
+ q = fbuf_getc (dtp->u.p.current_unit);
+ if (q == EOF)
+ break;
+ else if (q == '\n' || q == '\r')
{
/* Unexpected end of line. Set the position. */
- fbuf_seek (dtp->u.p.current_unit, n + 1 ,SEEK_CUR);
dtp->u.p.sf_seen_eor = 1;
+ /* If we see an EOR during non-advancing I/O, we need to skip
+ the rest of the I/O statement. Set the corresponding flag. */
+ if (dtp->u.p.advance_status == ADVANCE_NO || dtp->u.p.seen_dollar)
+ dtp->u.p.eor_condition = 1;
+
/* If we encounter a CR, it might be a CRLF. */
if (q == '\r') /* Probably a CRLF */
{
- /* See if there is an LF. Use fbuf_read rather then fbuf_getc so
- the position is not advanced unless it really is an LF. */
- int readlen = 1;
- p = fbuf_read (dtp->u.p.current_unit, &readlen);
- if (*p == '\n' && readlen == 1)
- {
- dtp->u.p.sf_seen_eor = 2;
- fbuf_seek (dtp->u.p.current_unit, 1 ,SEEK_CUR);
- }
+ /* See if there is an LF. */
+ q2 = fbuf_getc (dtp->u.p.current_unit);
+ if (q2 == '\n')
+ dtp->u.p.sf_seen_eor = 2;
+ else if (q2 != EOF) /* Oops, seek back. */
+ fbuf_seek (dtp->u.p.current_unit, -1, SEEK_CUR);
}
goto done;
}
n++;
- p++;
}
- fbuf_seek (dtp->u.p.current_unit, n, SEEK_CUR);
-
done:
if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
dtp->u.p.size_used += (GFC_IO_INT) n;
