Re: [Fortran, Patch] Implement IMPLICIT NONE
>> Build and regtested on x86-64-gnu-linux. >> OK for the trunk? Looks mostly OK, but I have one question: I don’t understand what the wording "Type IMPLICIT NONE statement” is supposed to mean. Why “type”? FX
Re: [Fortran, Patch] Implement IMPLICIT NONE
FX wrote: Build and regtested on x86-64-gnu-linux. OK for the trunk? Looks mostly OK, but I have one question: I don’t understand what the wording "Type IMPLICIT NONE statement” is supposed to mean. Why “type”? Well, I want to distinguish "IMPLICIT NONE (external)" which only applies to procedures from "IMPLICIT NONE" alias "IMPLICIT NONE (type)" which applies only to variables and function (return value) types. Thus, IMPLICIT NONE (external) IMPLICIT integer(a-z) is valid while IMPLICIT NONE IMPLICIT integer(a-z) is not. If you have a better suggestion for the wording … Tobias
Re: [Fortran, Patch] Implement IMPLICIT NONE
> If you have a better suggestion for the wording … I’d suggest “IMPLICIT NONE (TYPE) statement at %C following an IMPLICIT statement” (and the other way around). OK, with or without the wording change, I let you decide
Re: [fortran,patch] Emit code for some IEEE functions in the front-end
ping > Hi all, > > The attached patch improves our code generation for some of the > IEEE_ARITHMETIC functions: some testing functions (is*) and some arithmetic > (logb, rint, scalb, …). The interfaces are still present in the module file > generated as part of the library (which allows, in particular, for accurate > testing of the extent of support we have), but we catch them before emitting > the actual function call and emit front-end-generated code instead. This code > uses some intrinsics that we didn’t use in the front-end so far (some type > generic, some not), so I have added them (logb, remainder, rint, signbit). > > The patch is nice because it improves the quality of the code generated, > eliminating in many cases the need for a function call. It is also a > prerequisite to extend our IEEE support to more floating-point types > (extended precision and binary128, on some targets including i386/x86_64). > Without it, we would have a combinatorial explosion of the number of “helper” > functions in the library. > > Also, I’m removing symbols from gfortran.map, but no branching/release has > occurred since I added them in the first place: it should be all good. > > Regtested on x86_64-apple-darwin14. This regresses ieee_2.f90, at -m32 > -fno-float-store only, where we seem to trigger a missimplification of > __builtin_rint(). I’ll send, just after this one, a mail to gcc to get some > help on that, and track the issue separately. > > OK to commit? > FX ieee.ChangeLog Description: Binary data ieee.diff Description: Binary data
Re: [fortran,patch] Forbid assignment of different character kinds
> In the test case, could you also add a "PR fortran/36534" to the > as comment? Sure. > Additionally, I wonder whether instead of the name-based checking > + && (sym->name[0] != '_' || sym->name[1] != '_')) > it wouldn't be cleaner to check > && sym->attr.intrinsic > (If you change it to attr.intrinsic, you need to set > the attribute also in intrinsic.c's gfc_convert_type_warn.) > > I know that using __... names it not really possible in Fortran (except as C > binding name), but - still - I think it is cleaner. But I am fine with > either version. OK, it sounds logical, so I tried that… it gets caught later in resolve.c, saying “… declared INTRINSIC at %L does not exist”, because it’s not actually a proper intrinsic, it’s just a function call manually constructed. In the interest of minimal modification of this code, I have committed the original approach as rev. 215887. Thanks for the review. FX
Re: parallel check output changes?
Jakub Jelinek writes:
>> make the result of combining separate .sum files the same as the .sum
>> file you'd get for -j1. As Jakub said upthread, that's a lost cause
>> with the new approach to parallel testing, but I think the comment was
>> valid while matching -j1 was still a goal.
>
> I'm sorry for invalidating those assumptions. Indeed, before my recent
> changes, all tests for the same testcase name were run serially by the same
> job. If we wanted to preserve that property, we could e.g. store the
> results of gcc_parallel_test_run_p in some tcl array with testcase as the
> key, and after the
> if { $gcc_runtest_parallelize_enable == 0 } {
> return 1
> }
> test add a test if we've been asked about a particular testcase already,
> just return what we've returned before. Perhaps accompany that with
> lowering the granularity (e.g. from 10 to 5).
That sounds like it'd help if we have any lingering cases where the
text after the PASS: etc. isn't unique, since otherwise it's probably
unpredictable which one comes first in the combined summary (as it was
when the test order was still keyed only off filename). OTOH I suppose
we should just fix those tests so that the name is unique.
Also, now that even partial RUNTESTFLAGS-based testuite runs can be
fully parallelised (very nice, thanks), what -j1 did is probably
no longer relevant anyway.
Thanks,
Richard
Re: RFA: one more version of the patch for PR61360
Uros Bizjak writes: > On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov wrote: > > I guess we achieved the consensus about the following patch to fix > PR61360 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 > > The patch was successfully bootstrapped and tested (w/wo > -march=amdfam10) on x86/x86-64. > > Is it ok to commit to trunk? I've tested your patch and unfortunately it doesn't work: In file included from /var/tmp/moz-build-dir/js/src/shell/Unified_cpp_js_src_shell0.cpp:15:0: /var/tmp/mozilla-central/js/src/shell/js.cpp: In function ‘void Process(JSContext*, JSObject*, const char*, bool)’: /var/tmp/mozilla-central/js/src/shell/js.cpp:592:1: internal compiler error: in lra_update_insn_recog_data, at lra.c:1221 } ^ 0xa9d9ec lra_update_insn_recog_data(rtx_insn*) ../../gcc/gcc/lra.c:1220 0xab450f eliminate_regs_in_insn ../../gcc/gcc/lra-eliminations.c:1077 0xab450f process_insn_for_elimination ../../gcc/gcc/lra-eliminations.c:1344 0xab450f lra_eliminate(bool, bool) ../../gcc/gcc/lra-eliminations.c:1408 0xa9f2da lra(_IO_FILE*) ../../gcc/gcc/lra.c:2270 0xa5d659 do_reload ../../gcc/gcc/ira.c:5311 0xa5d659 execute ../../gcc/gcc/ira.c:5470 >>> >>> >>> Testcase is attached: >>> >>> % g++ -c -march=amdfam10 -w -O2 js.ii >>> js.ii: In function ‘void RunFile(C)’: >>> js.ii:64:1: internal compiler error: in lra_update_insn_recog_data, at >>> lra.c:1221 >>> >> >> Thanks for reporting this, Marcus. The problem now is in >> optimize_function_for_size_p. It is false, when we define and cache enable >> attributes at early stages (instantation of virtual regs) and true later. >> >> It is returning us to the same problem. I believe that we should not have >> enable attributes depending on optimization options or on the current >> running pass if we don't want the current solution in the trunk (with >> recog_init). Setting right value for optimize_function_for_size_p does not >> solve the problem as we can have different options for different functions >> in the same compilation file. >> >> So minimal solution would be removing optimize_function_for_size_p from the >> attribute definition. But I guess we could remove all condition. >> Unfortunately, Ganesh did not post is it really beneficial to switch off >> this alternative for AMD CPUs even if AMD optimization guide recommends it. > > I propose to split the pattern into size-optimized and normal pattern. > The patch implements this proposal. An alternative would be to add two new enabled-like attributes, "good_for_size" and "good_for_speed", that say whether it is efficient to use a particular alternative. These attributes wouldn't ever stop an existing instruction from being recognised; they would just say whether the RA and optimisers should consider the alternative when optimising for size or speed respectively. The attributes would have the same restrictions as the enabled attribute and could be cached in the same way. The "enabled" attribute would then be purely about whether an instruction is available, not whether it's efficient in a particular situation. The main advantage is that it would be possible to make the size/speed choice at a basic block level rather than a function level. In the worst case we might move an instruction from a hot block to a cold block or vice versa, but with intelligent spilling that shouldn't happen too often and at least it wouldn't trigger an ICE. If that sounds OK, I'll try to get something together next week. I think Ramana said he had a use for this on ARM too. Thanks, Richard
Re: RFA: one more version of the patch for PR61360
On Sat, Oct 4, 2014 at 12:49 PM, Richard Sandiford wrote: > Uros Bizjak writes: >> On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov >> wrote: >> >> I guess we achieved the consensus about the following patch to fix >> PR61360 >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 >> >> The patch was successfully bootstrapped and tested (w/wo >> -march=amdfam10) on x86/x86-64. >> >> Is it ok to commit to trunk? > > > I've tested your patch and unfortunately it doesn't work: > > In file included from > /var/tmp/moz-build-dir/js/src/shell/Unified_cpp_js_src_shell0.cpp:15:0: > /var/tmp/mozilla-central/js/src/shell/js.cpp: In function ‘void > Process(JSContext*, JSObject*, const char*, bool)’: > /var/tmp/mozilla-central/js/src/shell/js.cpp:592:1: internal compiler > error: in lra_update_insn_recog_data, at lra.c:1221 > } > ^ > 0xa9d9ec lra_update_insn_recog_data(rtx_insn*) > ../../gcc/gcc/lra.c:1220 > 0xab450f eliminate_regs_in_insn > ../../gcc/gcc/lra-eliminations.c:1077 > 0xab450f process_insn_for_elimination > ../../gcc/gcc/lra-eliminations.c:1344 > 0xab450f lra_eliminate(bool, bool) > ../../gcc/gcc/lra-eliminations.c:1408 > 0xa9f2da lra(_IO_FILE*) > ../../gcc/gcc/lra.c:2270 > 0xa5d659 do_reload > ../../gcc/gcc/ira.c:5311 > 0xa5d659 execute > ../../gcc/gcc/ira.c:5470 Testcase is attached: % g++ -c -march=amdfam10 -w -O2 js.ii js.ii: In function ‘void RunFile(C)’: js.ii:64:1: internal compiler error: in lra_update_insn_recog_data, at lra.c:1221 >>> >>> Thanks for reporting this, Marcus. The problem now is in >>> optimize_function_for_size_p. It is false, when we define and cache enable >>> attributes at early stages (instantation of virtual regs) and true later. >>> >>> It is returning us to the same problem. I believe that we should not have >>> enable attributes depending on optimization options or on the current >>> running pass if we don't want the current solution in the trunk (with >>> recog_init). Setting right value for optimize_function_for_size_p does not >>> solve the problem as we can have different options for different functions >>> in the same compilation file. >>> >>> So minimal solution would be removing optimize_function_for_size_p from the >>> attribute definition. But I guess we could remove all condition. >>> Unfortunately, Ganesh did not post is it really beneficial to switch off >>> this alternative for AMD CPUs even if AMD optimization guide recommends it. >> >> I propose to split the pattern into size-optimized and normal pattern. >> The patch implements this proposal. > > An alternative would be to add two new enabled-like attributes, > "good_for_size" and "good_for_speed", that say whether it is efficient > to use a particular alternative. These attributes wouldn't ever stop > an existing instruction from being recognised; they would just say > whether the RA and optimisers should consider the alternative when > optimising for size or speed respectively. The attributes would have > the same restrictions as the enabled attribute and could be cached in > the same way. > > The "enabled" attribute would then be purely about whether an > instruction is available, not whether it's efficient in a particular > situation. > > The main advantage is that it would be possible to make the size/speed > choice at a basic block level rather than a function level. In the worst > case we might move an instruction from a hot block to a cold block or > vice versa, but with intelligent spilling that shouldn't happen too > often and at least it wouldn't trigger an ICE. > > If that sounds OK, I'll try to get something together next week. > I think Ramana said he had a use for this on ARM too. I think that this would be way better than duplication of patterns. Perhaps we can name these attributes "enable_for_size" and "enable_for_speed", and have them in addition to "enable" attribute. The final enable condition would be an union of "enable", "enable_for_speed" and "enable_for_size" attributes. Uros.
[PATCH, PR63307] Fix generation of new declarations in random order
Hi!
The following patch does fix random order for new decls generation during
Cilk_spawn generation.
As Jakub suggested in the PR first we deal with vectors, then sort them and
only then perform necessary generation of new decls.
Bootstrapped and regtested on trunk/4.9.
For trunk I couldn't check with COMPARE_DEBUG since building fails somewhere
else.
For 4.9 COMPARE_DEBUG building is ok.
Is it ok for trunk and backport into 4.9?
c-family/Changelog:
2014-10-03 Igor Zamyatin
PR c/63307
* cilk.c: Include vec.h.
(struct cilk_decls): New structure.
(wrapper_parm_cb): Split this function to...
(fill_decls_vec): ...this...
(create_parm_list): ...and this.
(compare_decls): New function.
(for_local_cb): Remove.
(wrapper_local_cb): Ditto.
(build_wrapper_type): For now first traverse and fill vector of
declarations then sort it and then deal with sorted vector.
(cilk_outline): Ditto.
(declare_one_free_variable): Ditto.
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index 20b3432..e7a1c6a 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3. If not see
#include "toplev.h"
#include "cgraph.h"
#include "diagnostic.h"
+#include "vec.h"
#include "cilk.h"
enum add_variable_type {
@@ -332,17 +333,36 @@ create_cilk_helper_decl (struct wrapper_data *wd)
return fndecl;
}
-/* A function used by walk tree to find wrapper parms. */
+struct cilk_decls
+{
+ tree key;
+ tree *val;
+};
+
+/* A function used by traversal to fill vector of decls for further work. */
bool
-wrapper_parm_cb (tree const &key0, tree *val0, wrapper_data *wd)
+fill_decls_vec (tree const &key0, tree *val0, auto_vec *v)
+{
+ tree t1 = key0;
+ struct cilk_decls dp;
+
+ dp.key = t1;
+ dp.val = val0;
+ v->safe_push (dp);
+ return true;
+}
+
+/* Function that actually creates necessary parm lists. */
+
+static void
+create_parm_list (struct wrapper_data *wd, tree *val0, tree arg)
{
- tree arg = key0;
tree val = *val0;
tree parm;
if (val == error_mark_node || val == arg)
-return true;
+return;
if (TREE_CODE (val) == PAREN_EXPR)
{
@@ -360,7 +380,7 @@ wrapper_parm_cb (tree const &key0, tree *val0, wrapper_data
*wd)
}
else
arg = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (arg)), arg);
-
+
val = TREE_OPERAND (val, 0);
*val0 = val;
gcc_assert (TREE_CODE (val) == INDIRECT_REF);
@@ -371,9 +391,19 @@ wrapper_parm_cb (tree const &key0, tree *val0,
wrapper_data *wd)
parm = val;
TREE_CHAIN (parm) = wd->parms;
wd->parms = parm;
- wd->argtypes = tree_cons (NULL_TREE, TREE_TYPE (parm), wd->argtypes);
- wd->arglist = tree_cons (NULL_TREE, arg, wd->arglist);
- return true;
+ wd->argtypes = tree_cons (NULL_TREE, TREE_TYPE (parm), wd->argtypes);
+ wd->arglist = tree_cons (NULL_TREE, arg, wd->arglist);
+}
+
+/* Sorting decls in a vector. */
+
+static int
+compare_decls (const void *a, const void *b)
+{
+ const struct cilk_decls* t1 = (const struct cilk_decls*) a;
+ const struct cilk_decls* t2 = (const struct cilk_decls*) b;
+
+ return DECL_UID (t1->key) > DECL_UID (t2->key);
}
/* This function is used to build a wrapper of a certain type. */
@@ -381,13 +411,21 @@ wrapper_parm_cb (tree const &key0, tree *val0,
wrapper_data *wd)
static void
build_wrapper_type (struct wrapper_data *wd)
{
+ unsigned int j;
+ struct cilk_decls * c;
+ auto_vec vd;
wd->arglist = NULL_TREE;
wd->parms = NULL_TREE;
wd->argtypes = void_list_node;
- wd->decl_map->traverse (wd);
+ wd->decl_map->traverse *, fill_decls_vec> (&vd);
gcc_assert (wd->type != CILK_BLOCK_FOR);
+ vd.qsort (compare_decls);
+
+ FOR_EACH_VEC_ELT (vd, j, c)
+ create_parm_list (wd, c->val, c->key);
+
/* Now build a function.
Its return type is void (all side effects are via explicit parameters).
Its parameters are WRAPPER_PARMS with type WRAPPER_TYPES.
@@ -448,41 +486,19 @@ copy_decl_for_cilk (tree decl, copy_body_data *id)
}
}
-/* Copy all local variables. */
-
-bool
-for_local_cb (tree const &k, tree *vp, copy_body_data *id)
-{
- tree v = *vp;
-
- if (v == error_mark_node)
-*vp = copy_decl_no_change (k, id);
- return true;
-}
-
-/* Copy all local declarations from a _Cilk_spawned function's body. */
-
-bool
-wrapper_local_cb (tree const &key, tree *vp, copy_body_data *id)
-{
- tree val = *vp;
-
- if (val == error_mark_node)
-*vp = copy_decl_for_cilk (key, id);
-
- return true;
-}
-
/* Alter a tree STMT from OUTER_FN to form the body of INNER_FN. */
void
cilk_outline (tree inner_fn, tree *stmt_p, void *w)
{
struct wrapper_data *wd = (struct wrapper_data *) w;
- const tree outer_fn = wd->context;
+ const tree outer_fn = wd->context;
const bool nested = (wd->type == CILK_BLOCK_FOR);
copy_body_data id;
bool throws;
+ auto_v
Re: RFA: one more version of the patch for PR61360
Uros Bizjak writes: > On Sat, Oct 4, 2014 at 12:49 PM, Richard Sandiford > wrote: >> Uros Bizjak writes: >>> On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov >>> wrote: >>> >>> I guess we achieved the consensus about the following patch to fix >>> PR61360 >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 >>> >>> The patch was successfully bootstrapped and tested (w/wo >>> -march=amdfam10) on x86/x86-64. >>> >>> Is it ok to commit to trunk? >> >> >> I've tested your patch and unfortunately it doesn't work: >> >> In file included from >> /var/tmp/moz-build-dir/js/src/shell/Unified_cpp_js_src_shell0.cpp:15:0: >> /var/tmp/mozilla-central/js/src/shell/js.cpp: In function ‘void >> Process(JSContext*, JSObject*, const char*, bool)’: >> /var/tmp/mozilla-central/js/src/shell/js.cpp:592:1: internal compiler >> error: in lra_update_insn_recog_data, at lra.c:1221 >> } >> ^ >> 0xa9d9ec lra_update_insn_recog_data(rtx_insn*) >> ../../gcc/gcc/lra.c:1220 >> 0xab450f eliminate_regs_in_insn >> ../../gcc/gcc/lra-eliminations.c:1077 >> 0xab450f process_insn_for_elimination >> ../../gcc/gcc/lra-eliminations.c:1344 >> 0xab450f lra_eliminate(bool, bool) >> ../../gcc/gcc/lra-eliminations.c:1408 >> 0xa9f2da lra(_IO_FILE*) >> ../../gcc/gcc/lra.c:2270 >> 0xa5d659 do_reload >> ../../gcc/gcc/ira.c:5311 >> 0xa5d659 execute >> ../../gcc/gcc/ira.c:5470 > > > Testcase is attached: > > % g++ -c -march=amdfam10 -w -O2 js.ii > js.ii: In function ‘void RunFile(C)’: > js.ii:64:1: internal compiler error: in lra_update_insn_recog_data, at > lra.c:1221 > Thanks for reporting this, Marcus. The problem now is in optimize_function_for_size_p. It is false, when we define and cache enable attributes at early stages (instantation of virtual regs) and true later. It is returning us to the same problem. I believe that we should not have enable attributes depending on optimization options or on the current running pass if we don't want the current solution in the trunk (with recog_init). Setting right value for optimize_function_for_size_p does not solve the problem as we can have different options for different functions in the same compilation file. So minimal solution would be removing optimize_function_for_size_p from the attribute definition. But I guess we could remove all condition. Unfortunately, Ganesh did not post is it really beneficial to switch off this alternative for AMD CPUs even if AMD optimization guide recommends it. >>> >>> I propose to split the pattern into size-optimized and normal pattern. >>> The patch implements this proposal. >> >> An alternative would be to add two new enabled-like attributes, >> "good_for_size" and "good_for_speed", that say whether it is efficient >> to use a particular alternative. These attributes wouldn't ever stop >> an existing instruction from being recognised; they would just say >> whether the RA and optimisers should consider the alternative when >> optimising for size or speed respectively. The attributes would have >> the same restrictions as the enabled attribute and could be cached in >> the same way. >> >> The "enabled" attribute would then be purely about whether an >> instruction is available, not whether it's efficient in a particular >> situation. >> >> The main advantage is that it would be possible to make the size/speed >> choice at a basic block level rather than a function level. In the worst >> case we might move an instruction from a hot block to a cold block or >> vice versa, but with intelligent spilling that shouldn't happen too >> often and at least it wouldn't trigger an ICE. >> >> If that sounds OK, I'll try to get something together next week. >> I think Ramana said he had a use for this on ARM too. > > I think that this would be way better than duplication of patterns. > Perhaps we can name these attributes "enable_for_size" and > "enable_for_speed", and have them in addition to "enable" attribute. > The final enable condition would be an union of "enable", > "enable_for_speed" and "enable_for_size" attributes. I was trying to avoid having "enable" in the names because the new attributes would only be strong optimisation hints whereas "enabled" is a correctness thing. We'd need to ignore the new attributes when constraining an existing instruction (which might have been optimised the opposite way and then moved) but we can never ignore "enabled". E.g. to take two examples, when constrain_operands is used like this: if (! constrain_operands (1)) fatal_insn_not_found (insn); then only the enabled attribute matters, whereas for validate_change I think we'd want to take the new attributes into account as well. "good_
[patch] Add -static-libquadmath option
We have a -static-libgfortran option, but on targets where we support quad-prec math through libquadmath, we didn’t have an equivalent -static-libquadmath so far. This patch adds it, in what I think is a rather straightforward manner. The only minor complication comes from the fact that previously, linking libquadmath was conditionally through libgfortran.spec. So the spec was modified: when we use -static-libquadmath, the driver itself includes the -lquadmath (surrounded by the necessary static linking directives), so that libgfortran.spec shouldn’t do it again. Bootstrapped and regtested on x86_64 linux. OK to commit? FX static_quadmath.ChangeLog Description: Binary data static_quadmath.diff Description: Binary data
Re: [PATCH Fortran] move more diagnostics to the common machinery
On 3 October 2014 23:29, Manuel López-Ibáñez wrote: > The following patch adds two new functions. One of them is an overload > of gfc_warning_cmdline() that takes an option. Thus now we get: Don't review this one just yet. I must have messed up testing or new testcases appeared because after doing 'svn up' some testcases started failing. I am testing a new patch. Cheers, Manuel.
[PATCH Fortran] move more diagnostics to the common machinery (try 2)
The following patch adds two new functions. One of them is an overload
of gfc_warning_cmdline() that takes an option. Thus now we get:
f951: Warning: Nonexistent include directory
'C:\msys\1.0.10\home\FX\ibin\i586-pc-mingw32\libgfortran/../../../trunk/libgfortran/generated'
[-Wmissing-include-dirs]
plus colors!
and of course, with -Werror=missing-include-dirs you get:
f951: Error: Nonexistent include directory
'C:\msys\1.0.10\home\FX\ibin\i586-pc-mingw32\libgfortran/../../../trunk/libgfortran/generated'
[-Werror=missing-include-dirs]
f951: some warnings being treated as errors
plus colors!
The other new function is for errors instead of warnings. Perhaps
there are more places where these functions can be used.
Surprisingly, options that are not Common and not handled explicitly
in gfc_handle_option were rejected. This is fixed by this patch since
such options are handled automatically by the common options
machinery.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/fortran/ChangeLog:
2014-10-04 Manuel López-Ibáñez
* gfortran.h (gfc_warning_cmdline): Add overload that takes an
option.
(gfc_error_cmdline): Declare.
* error.c (gfc_warning_cmdline): New overload that takes an option.
(gfc_error_cmdline): New.
* lang.opt (Wmissing-include-dirs): New.
* scanner.c (add_path_to_list): Use the new functions.
(load_file): Likewise.
* options.c (gfc_init_options): Wmissing-include-dirs is enabled
by default in Fortran.
(gfc_handle_option): Accept automatically handled options.
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h (revision 215880)
+++ gcc/fortran/gfortran.h (working copy)
@@ -2693,17 +2693,19 @@ void gfc_buffer_error (int);
const char *gfc_print_wide_char (gfc_char_t);
void gfc_warning (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
void gfc_warning_now (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
-void gfc_warning_cmdline (const char *gmsgid, ...) ATTRIBUTE_GCC_GFC(1,2);
+bool gfc_warning_cmdline (const char *gmsgid, ...) ATTRIBUTE_GCC_GFC(1,2);
+bool gfc_warning_cmdline (int opt, const char *gmsgid, ...)
ATTRIBUTE_GCC_GFC(2,3);
void gfc_clear_warning (void);
void gfc_warning_check (void);
void gfc_error (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
+void gfc_error_cmdline (const char *gmsgid, ...) ATTRIBUTE_GCC_GFC(1,2);
void gfc_error_now (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
void gfc_fatal_error (const char *, ...) ATTRIBUTE_NORETURN
ATTRIBUTE_GCC_GFC(1,2);
void gfc_internal_error (const char *, ...) ATTRIBUTE_NORETURN
ATTRIBUTE_GCC_GFC(1,2);
void gfc_clear_error (void);
int gfc_error_check (void);
int gfc_error_flag_test (void);
Index: gcc/fortran/error.c
===
--- gcc/fortran/error.c (revision 215880)
+++ gcc/fortran/error.c (working copy)
@@ -1050,25 +1109,61 @@ gfc_diagnostic_finalizer (diagnostic_con
{
pp_destroy_prefix (context->printer);
pp_newline_and_flush (context->printer);
}
/* Give a warning about the command-line. */
-void
+bool
+gfc_warning_cmdline (int opt, const char *gmsgid, ...)
+{
+ va_list argp;
+ diagnostic_info diagnostic;
+ bool ret;
+
+ va_start (argp, gmsgid);
+ diagnostic_set_info (&diagnostic, gmsgid, &argp, UNKNOWN_LOCATION,
+ DK_WARNING);
+ diagnostic.option_index = opt;
+ ret = report_diagnostic (&diagnostic);
+ va_end (argp);
+ return ret;
+}
+
+
+/* Give a warning about the command-line. */
+
+bool
gfc_warning_cmdline (const char *gmsgid, ...)
{
va_list argp;
diagnostic_info diagnostic;
+ bool ret;
va_start (argp, gmsgid);
diagnostic_set_info (&diagnostic, gmsgid, &argp, UNKNOWN_LOCATION,
DK_WARNING);
+ ret = report_diagnostic (&diagnostic);
+ va_end (argp);
+ return ret;
+}
+
+
+/* Give an error about the command-line. */
+
+void
+gfc_error_cmdline (const char *gmsgid, ...)
+{
+ va_list argp;
+ diagnostic_info diagnostic;
+
+ va_start (argp, gmsgid);
+ diagnostic_set_info (&diagnostic, gmsgid, &argp, UNKNOWN_LOCATION, DK_ERROR);
report_diagnostic (&diagnostic);
va_end (argp);
}
/* Clear the warning flag. */
void
gfc_clear_warning (void)
{
Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt(revision 215880)
+++ gcc/fortran/lang.opt(working copy)
@@ -255,10 +255,14 @@ Warn about truncated source lines
Wintrinsics-std
Fortran Warning
Warn on intrinsics not part of the selected standard
+Wmissing-include-dirs
+Fortran
+; Documented in C/C++
+
Wuse-without-only
Fortran Warning
Warn about USE statements that have no ONLY qualifier
Wopenmp-simd
Index: gcc/fortran/scanner.c
===
--- gcc/fortran/scanner.c (revision 215880)
+++ gcc/fortran/scanner.c (working cop
Re: __intN patch 3/5: main __int128 -> __intN conversion.
On 10/03/2014 04:11 PM, DJ Delorie wrote: Note that there is a separate __int128_t type that isn't part of the "standard" extension. Maybe it's there for that type? Otherwise, I don't see what moving the test would accomplish. If "long" is never 128 bits, it doesn't matter if the int128 test is before or after it, and the other intN are never the same size as standard types, I don't see how you can assert that these will never happen. Why not make the code more correct, while we're touching it? and we already have code to prefer unsigned for intN types. What I don't see is the intN parallel to this: if (same_type_p (TYPE_MAIN_VARIANT (t1), long_long_unsigned_type_node) || same_type_p (TYPE_MAIN_VARIANT (t2), long_long_unsigned_type_node)) return build_type_attribute_variant (long_long_unsigned_type_node, attributes); Your patch only compares t1/t2 to int_n_trees[i].signed_type. Jason
Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.
On 10/03/2014 05:31 PM, Siva Chandra wrote: * decl2.c (grokfield): Mark special methods declared as default to be artificial. No, defaulted methods are still user-declared, not artificial. Jason
Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.
On 10/03/2014 05:41 PM, Siva Chandra wrote: I understand that knowing whether a copy-ctor or a d-tor has been explicitly defaulted is not sufficient to determine the parameter passing ABI. However, why is it not necessary? I could be wrong, but doesn't the example I have given show that it is necessary? An implicitly declared 'tor can also be trivial. Jason
Re: __intN patch 3/5: main __int128 -> __intN conversion.
> > Otherwise, I don't see what moving the test would accomplish. If
> > "long" is never 128 bits, it doesn't matter if the int128 test is
> > before or after it, and the other intN are never the same size as
> > standard types,
>
> I don't see how you can assert that these will never happen.
It's checked specifically in toplev.c - if the backend *does* request
a type that matches a standard size, they won't get it:
+static bool
+standard_type_bitsize (int bitsize)
+{
+ /* As a special exception, we always want __int128 enabled if possible. */
+ if (bitsize == 128)
+return false;
+ if (bitsize == CHAR_TYPE_SIZE
+ || bitsize == SHORT_TYPE_SIZE
+ || bitsize == INT_TYPE_SIZE
+ || bitsize == LONG_TYPE_SIZE
+ || (bitsize == LONG_LONG_TYPE_SIZE && LONG_LONG_TYPE_SIZE <
GET_MODE_BITSIZE (TImode)))
+return true;
+ return false;
+}
+ /* This must happen after the backend has a chance to process
+command line options, but before the parsers are
+initialized. */
+ for (i = 0; i < NUM_INT_N_ENTS; i ++)
+ if (targetm.scalar_mode_supported_p (int_n_data[i].m)
+ && ! standard_type_bitsize (int_n_data[i].bitsize)
+ && int_n_data[i].bitsize <= HOST_BITS_PER_WIDE_INT * 2)
+ int_n_enabled_p[i] = true;
+ else
+ int_n_enabled_p[i] = false;
+
Re: Profile mode maintenance patch
On 23/09/2014 13:27, Jonathan Wakely wrote:
Yes, OK for trunk - thanks very much.
Hi
There was in fact one last test failing, ext/profile/mh.cc, a
profile mode specific test. It must have been failing for quite a while
since malloc hooks has been deprecated. It is normally testing the
profile mode protection against recursion if memory allocation functions
are redefined. It was based on malloc but we use in fact new operator.
So I rewrite the test using new/delete operators.
This new test version is attached, I removed those 2 lines at the
beginning:
// { dg-do compile { target *-*-linux* *-*-gnu* } }
// { dg-xfail-if "" { uclibc } { "*" } { "" } }
I think that this test can now be executed and see no reason why it
should fail with uclibc. Do you confirm ?
I attached the full patch again. I also remove useless virtual
destructor or methods, no need for polymorphism.
François
profile.patch.bz2
Description: application/bzip
// -*- C++ -*-
// Copyright (C) 2006-2014 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING3. If not see
//
Re: [gomp4] OpenACC wait directive
On 10/03/2014 07:34 AM, Cesar Philippidis wrote: > On 09/24/2014 12:18 AM, Ilmir Usmanov wrote: >> Hi Cesar! >> >> Thank you for the patch! >> >> On 24.09.2014 02:29, Cesar Philippidis wrote: >>> This patch adds support for the async clause in the wait directive in >>> fortran. It should be pretty straight forward. The fortran FE already >>> supports the wait directive, but the async clause was introduced to the >>> wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch. >> Yes, I've mostly focused on spec. ver. 1.0. >> >>> Is this OK for gomp-4_0-branch? >> No, it isn't. According to the spec and this presentation: >> http://www.pgroup.com/lit/presentations/cea-3.pdf (See slide 1-35) >> it is possible to write construction like: >> !$acc wait(1) async(2) >> However, your patch doesn't support this. Also, don't forget to check >> whether a queue waits itself (for example, wait(1) async(1)). >> In addition, it breaks current support of the directive (for example, >> wait(1)). > > Sorry for the delay. I encountered some problems with the runtime in our > internal branch, and that slowed things down a bit. > > Anyway, you are correct, I broke the optional argument to wait in the > previous patch. This new patch addresses that and it also make the wait > construct conform with OpenACC 2.0. Specifically, > > !$acc wait (1, 2) async (3) > > should behave as ex[ected. > > If you look at gfc_trans_oacc_wait_directive, you'll note that a call to > GOACC_wait is emitted for the wait directive. Since I had to add a > runtime library stub for that builtin function, I decided to go ahead an > include the c front end bits. > > Is this patch OK for gomp-4_0-branch? Julian is working on working on a > more complete implementation of the runtime. The runtime stub that I > included is only temporary. I noticed that I forgot to include the changes to gimplify.c in that patch. This new patch includes those changes. Cesar 2014-10-04 Cesar Philippidis James Norris Thomas Schwinge gcc/ * builtin-types.def (BT_FN_VOID_INT_PTR_INT): Define. * oacc-builtins.def (DEF_GOACC_BUILTIN): Define. * omp-low.c (scan_sharing_clauses): Update handling of OMP_CLAUSE_ASYNC and OMP_CLAUSE_WAIT. (expand_oacc_offload): Likewise. (expand_omp_target): Likewise. * gimplify.c (gimplify_scan_omp_clauses): Call gimplify_expr for OMP_CLAUSE_ASYNC and OMP_CLAUSE_WAIT. (gimplify_adjust_omp_clauses): Don't treat OMP_CLAUSE_ASYNC and OMP_CLAUSE_WAIT as unreachable. gcc/c-family/ * c-common.h (c_finish_oacc_wait): Declare. * c-omp.c (c_finish_oacc_wait): New function. * c-pragma.c (oacc_pragmas): Add an entry for "wait". * c-pragma.h (enum pragma_kind): Add PRAGMA_OACC_WAIT. (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_ASYNC and PRAGMA_OMP_CLAUSE_WAIT. gcc/c/ * c-parser.c (c_parser_omp_clause_name): Handle async and wait. (c_parser_oacc_integer_list): New function. (c_parser_oacc_int_list_parens): New function. (c_parser_oacc_clause_async): New function. (c_parser_oacc_clause_wait): New function. (c_parser_oacc_all_clauses): Handle PRAGMA_OMP_CLAUSE_ASYNC and PRAGMA_OMP_CLAUSE_WAIT. (OACC_KERNELS_CLAUSE_MASK): Add async and wait clauses. (OACC_PARALLEL_CLAUSE_MASK): Likewise. (OACC_UPDATE_CLAUSE_MASK): Likewise. (OACC_WAIT_CLAUSE_MASK): New define. (c_parser_oacc_wait): New function. (c_parser_omp_construct): Handle PRAGMA_OACC_WAIT. * c-typeck.c (c_finish_omp_clauses): Handle OMP_CLAUSE_ASYNC and OMP_CLAUSE_WAIT. gcc/fortran/ * gfortran.h (struct gfc_omp_clauses): Remove non_clause_wait_expr. * dump-parse-tree.c (show_omp_clauses): Likewise. * openmp.c (gfc_free_omp_clauses): Likewise. (gfc_match_omp_clauses): Update handling of async. (OACC_WAIT_CLAUSE_MASK): New define. (gfc_match_oacc_wait): Make the wait directive comply with OpenACC 2.0. (resolve_omp_clauses): Use resolve_oacc_scalar_in_expr inspect arguments to the wait clause. (resolve_oacc_wait): Remove. (gfc_resolve_oacc_directive): Handle EXEC_OACC_WAIT with resolve_omp_clauses. * trans-openmp.c (gfc_trans_omp_clauses): Update handling of OpenACC wait arguments. (gfc_trans_oacc_wait_directive): New function. (gfc_trans_oacc_directive): Use it. * types.def (BT_FN_VOID_INT_PTR_INT): Define. gcc/testsuite/ * c-c++-common/goacc/asyncwait-1.c: New test. * gfortran.dg/goacc/asyncwait-1.f95: New test. * gfortran.dg/goacc/asyncwait-2.f95: New test. * gfortran.dg/goacc/asyncwait-3.f95: New test. * gfortran.dg/goacc/asyncwait-4.f95: New test. libgomp/ * libgomp.map (GOACC_2.0): Add GOACC_wait. * libgomp_g.h (GOACC_wait): Declare. * oacc-parallel.c (GOACC_wait): Define. diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def index 7c294af..094b3a8 100644 --- a/gcc/builtin-types.def +++ b/gcc/builtin-types.def @@ -358,6 +358,8 @@ DEF_FUNCTION_TYPE_3 (BT_FN_VOID_PTR_INT_SIZE, BT_VOID, BT_PTR, BT_INT, BT_SIZE) DEF_FUNCTION_TYPE_3 (BT_FN_VOID_PTR_INT_INT, BT_VOID, BT_PTR, BT_INT, BT
SD-6 C++ feature-testing macros for 4.9
On 10/02/2014 11:42 AM, Jonathan Wakely wrote: The library macros are safe and can't cause any issues, so I'm happy for them to go on the branch. I can think of at least two that aren't implemented on the branch: and the std::is_final trait (although I'd be OK with the trait going on the branch too). - Original Message - From: "Jason Merrill" To: "Ed Smith-Rowland" <3dw...@verizon.net>, "Jonathan Wakely" Cc: gcc-patches@gcc.gnu.org, "thiago macieira" Sent: Thursday, 2 October, 2014 4:40:03 PM Subject: Re: feature-testing macros for 4.9 On 10/02/2014 10:58 AM, Ed Smith-Rowland wrote: We've had a request from someone that we include SD-6 feature testing for gcc-4.9. It seems rather heavy for a backport but it might make maintainers of large C++ libraries happy ;-) and it might make sense as people migrate from 4.9 to 5.0 to see what we've added. I'm open to that. Jason OK, This really does build clean and test clean on x86_64-linux. It's basically the same as for 5.0 except experimental/any isn't in and variable templates aren't in. I put std::is_final into 4.9 earlier - this patch adds the macro for that too. I made this into a single grand unified patch this time. i didn't think splitting it lat time bought me much. Ed libcpp/ 2014-10-05 Edward Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * internal.h (lexer_state, spec_nodes): Add in__has_include__. * directives.c: Support __has_include__ builtin. * expr.c (parse_has_include): New function to parse __has_include__ builtin; (eval_token()): Use it. * files.c (_cpp_has_header()): New funtion to look for header; (open_file_failed()): Not an error to not find a header file for __has_include__. * identifiers.c (_cpp_init_hashtable()): Add entry for __has_include__. * pch.c (cpp_read_state): Lookup __has_include__. * traditional.c (enum ls, _cpp_scan_out_logical_line()): Walk through __has_include__ statements. gcc/c-family/ 2014-10-05 Edward Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * c-cppbuiltin.c (c_cpp_builtins()): Define language feature macros and the __has_header macro. libstdc++-v3/ 2014-10-05 Edward Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * include/bits/basic_string.h: Add __cpp_lib feature test macro. * include/bits/stl_algobase.h: Ditto. * include/bits/stl_function.h: Ditto. * include/bits/unique_ptr.h: Ditto. * include/std/chrono: Ditto. * include/std/complex: Ditto. * include/std/iomanip: Ditto. * include/std/shared_mutex: Ditto. * include/std/tuple: Ditto. * include/std/type_traits: Ditto. * include/std/utility: Ditto. * testsuite/experimental/feat-cxx14.cc: New. * testsuite/experimental/feat-lib-fund.cc: New. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust. * testsuite/20_util/duration/literals/range.cc: Adjust. * testsuite/20_util/duration/requirements/typedefs_neg1.cc: Adjust. * testsuite/20_util/duration/requirements/typedefs_neg2.cc: Adjust. * testsuite/20_util/duration/requirements/typedefs_neg3.cc: Adjust. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Adjust. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: Adjust. gcc/testsuite/ 2014-10-05 Edward Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * g++.dg/cpp1y/feat-cxx11-neg.C: New. * g++.dg/cpp1y/feat-cxx11.C: New. * g++.dg/cpp1y/feat-cxx14.C: New. * g++.dg/cpp1y/feat-cxx98.C: New. * g++.dg/cpp1y/feat-cxx98-neg.C: New. * g++.dg/cpp1y/phoobhar.h: New. * g++.dg/cpp1y/testinc/phoobhar.h: New. Index: libcpp/internal.h === --- libcpp/internal.h (revision 215826) +++ libcpp/internal.h (working copy) @@ -258,6 +258,9 @@ /* Nonzero when parsing arguments to a function-like macro. */ unsigned char parsing_args; + /* Nonzero if in a __has_include__ or __has_include_next__ statement. */ + unsigned char in__has_include__; + /* Nonzero if prevent_expansion is true only because output is being discarded. */ unsigned char discarding_output; @@ -279,6 +282,8 @@ cpp_hashnode *n_true;/* C++ keyword true */ cpp_hashnode *n_false; /* C++ keyword false */ cpp_hashnode *n__VA_ARGS__; /* C99 vararg macros */ + cpp_hashnode *n__has_include__; /* __has_include__ operator */ + cpp_has
PR 62026 (4.9-branch version)
Hi,
the ICE is caused by duplicate_thunk_for_node not copying DECL_ARGUMENTS in LTO
mode because they are not streamed in. This is gcc-4.9 branch version of the
fix,
I will prepare mainline version shortly.
Bootstrapped/regtested x86_64-linux, comitted.
PR lto/62026
* g++.dg/lto/pr62026.C: New testcase.
* lto-streamer-out.c (lto_output): Handle thunks correctly.
* cgraphclones.c (duplicate_thunk_for_node): Get thunk's arguments.
Index: testsuite/g++.dg/lto/pr62026.C
===
--- testsuite/g++.dg/lto/pr62026.C (revision 0)
+++ testsuite/g++.dg/lto/pr62026.C (revision 0)
@@ -0,0 +1,22 @@
+// { dg-lto-do link }
+// { dg-lto-options {{-flto -O3 -r -nostdlib}} }
+class C;
+class F {
+ virtual C m_fn1();
+};
+class C {
+ public:
+ virtual int *m_fn3(int);
+};
+class G : F, C {
+ int offsets;
+ int *m_fn3(int);
+};
+C *a;
+int *G::m_fn3(int) {
+ if (offsets) return 0;
+}
+
+void fn1() {
+ for (;;) a->m_fn3(0);
+}
Index: lto-streamer-out.c
===
--- lto-streamer-out.c (revision 215890)
+++ lto-streamer-out.c (working copy)
@@ -2077,7 +2077,10 @@ lto_output (void)
#endif
decl_state = lto_new_out_decl_state ();
lto_push_out_decl_state (decl_state);
- if (gimple_has_body_p (node->decl) || !flag_wpa)
+ if (gimple_has_body_p (node->decl) || !flag_wpa
+ /* Thunks have no body but they may be synthetized
+at WPA time. */
+ || DECL_ARGUMENTS (node->decl))
output_function (node);
else
copy_function (node);
Index: cgraphclones.c
===
--- cgraphclones.c (revision 215890)
+++ cgraphclones.c (working copy)
@@ -310,6 +310,11 @@ duplicate_thunk_for_node (cgraph_node *t
if (thunk_of->thunk.thunk_p)
node = duplicate_thunk_for_node (thunk_of, node);
+ /* We need to copy arguments, at LTO these mat not be read from function
+ section. */
+ if (!DECL_ARGUMENTS (thunk->decl))
+cgraph_get_body (thunk);
+
struct cgraph_edge *cs;
for (cs = node->callers; cs; cs = cs->next_caller)
if (cs->caller->thunk.thunk_p
PR 62121 (Segmentation fault in ipa-devirt.c:997)
Hi,
this is 4.9 version of patch fixing ICE on ipa-devirt.c:997.
The problem is that we get TYPE_SIZE NUll but code does not expect it.
Honza
PR ipa/62121
* ipa-devirt.c (restrict_to_inner_class): Do not ICE when type is
unknown.
* g++.dg/torture/pr62121.C: New testcase.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 215893)
+++ ipa-devirt.c(working copy)
@@ -994,7 +994,8 @@ give_up:
if ((TREE_CODE (type) != RECORD_TYPE
|| !TYPE_BINFO (type)
|| !polymorphic_type_binfo_p (TYPE_BINFO (type)))
- && (TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST
+ && (!TYPE_SIZE (type)
+ || TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST
|| (offset + tree_to_uhwi (TYPE_SIZE (expected_type)) <=
tree_to_uhwi (TYPE_SIZE (type)
return true;
Index: testsuite/g++.dg/torture/pr62121.C
===
--- testsuite/g++.dg/torture/pr62121.C (revision 0)
+++ testsuite/g++.dg/torture/pr62121.C (revision 0)
@@ -0,0 +1,12 @@
+// { dg-do compile }
+class A
+{
+ virtual double operator()();
+};
+class B : A
+{
+public:
+ double operator()();
+};
+extern B a[];
+int b = a[0]();
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 9/25/14 8:12, Chen Gang wrote: > OK, thanks, next month, I shall try Qemu for microblaze (I also focus on > Qemu, and try to make patches for it). > > And, I also need finish the testsuite under Darwin x86_64, next month for gcc. I finish tried testsuit under Darwin x86_64, originally, I incorrectly installed mpc: need "brew install libmpc", not "brew install mpc", and also need "brew link libmpc" which I missed. At present, except for libjave Throw_2.exe test, I guess all others are OK, please help check the result below, thanks. If it passes checking, next, I shall try to fix libjava Throw_2 issue within this month (others, include Throw_1 and Throw_3 are all OK). === g++ Summary === # of expected passes82961 # of unexpected failures891 # of expected failures 255 # of unresolved testcases 272 # of unsupported tests 3421 === gcc Summary === # of expected passes85011 # of unexpected failures30 # of expected failures 182 # of unresolved testcases 10 # of unsupported tests 2796 === gfortran Summary === # of expected passes46354 # of unexpected failures1 # of expected failures 38 # of unsupported tests 74 === gnat Summary === # of expected passes799 # of unexpected failures67 # of unexpected successes 18 # of unresolved testcases 382 # of unsupported tests 8 === objc Summary === # of expected passes5828 # of unexpected failures4 # of expected failures 6 # of unsupported tests 77 === boehm-gc Summary === # of expected passes12 # of unsupported tests 1 === libatomic Summary === # of expected passes54 === libffi Summary === # of expected passes1819 # of unsupported tests 55 === libgomp Summary === # of expected passes3194 # of unsupported tests 38 === libitm Summary === # of expected passes26 # of expected failures 3 # of unsupported tests 1 === libjava Summary === # of expected passes2574 # of unexpected failures4 /* The 4 issues are all related with Throw_2.exe */ # of expected failures 4 # of untested testcases 4 === libstdc++ Summary === # of expected passes8956 # of unexpected failures159 # of expected failures 69 # of unresolved testcases 38 # of unsupported tests 670 Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/5/14 11:15, Chen Gang wrote: > On 9/25/14 8:12, Chen Gang wrote: >> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on >> Qemu, and try to make patches for it). >> >> And, I also need finish the testsuite under Darwin x86_64, next month for >> gcc. > > I finish tried testsuit under Darwin x86_64, originally, I incorrectly > installed mpc: need "brew install libmpc", not "brew install mpc", and > also need "brew link libmpc" which I missed. > > At present, except for libjave Throw_2.exe test, I guess all others are > OK, please help check the result below, thanks. > Oh, sorry, I forgot to mention 2 things: - config with "--disable-multilibs", and I shall try normal configiure again (although I guess, it will also be OK), hope I can finish within 2 days. - And during test libjava, it will quit with error because of Throw_2, so I modified the related Makefile to skip it. > If it passes checking, next, I shall try to fix libjava Throw_2 issue > within this month (others, include Throw_1 and Throw_3 are all OK). > > === g++ Summary === > > # of expected passes 82961 > # of unexpected failures 891 > # of expected failures255 > # of unresolved testcases 272 > # of unsupported tests3421 > > === gcc Summary === > > # of expected passes 85011 > # of unexpected failures 30 > # of expected failures182 > # of unresolved testcases 10 > # of unsupported tests2796 > > === gfortran Summary === > > # of expected passes 46354 > # of unexpected failures 1 > # of expected failures38 > # of unsupported tests74 > > === gnat Summary === > > # of expected passes 799 > # of unexpected failures 67 > # of unexpected successes 18 > # of unresolved testcases 382 > # of unsupported tests8 > > === objc Summary === > > # of expected passes 5828 > # of unexpected failures 4 > # of expected failures6 > # of unsupported tests77 > > === boehm-gc Summary === > > # of expected passes 12 > # of unsupported tests1 > > === libatomic Summary === > > # of expected passes 54 > > === libffi Summary === > > # of expected passes 1819 > # of unsupported tests55 > > === libgomp Summary === > > # of expected passes 3194 > # of unsupported tests38 > > === libitm Summary === > > # of expected passes 26 > # of expected failures3 > # of unsupported tests1 > > === libjava Summary === > > # of expected passes 2574 > # of unexpected failures 4 /* The 4 issues are all related with > Throw_2.exe */ > # of expected failures4 > # of untested testcases 4 > > === libstdc++ Summary === > > # of expected passes 8956 > # of unexpected failures 159 > # of expected failures69 > # of unresolved testcases 38 > # of unsupported tests670 > > > Thanks. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Backport fix to PR61144 to GCC 4.9 branch
Hi,
this patch is in mainline for a while, but apparently I forgot to attach
PR info to it, so it did not make it to the release branch.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/61144
* varpool.c (ctor_for_folding): Do not fold WEAK symbols.
* gcc.dg/tree-ssa/pr61144.c: New testcase.
Index: varpool.c
===
--- varpool.c (revision 215895)
+++ varpool.c (working copy)
@@ -329,8 +329,16 @@ ctor_for_folding (tree decl)
/* Variables declared 'const' without an initializer
have zero as the initializer if they may not be
- overridden at link or run time. */
- if (!DECL_INITIAL (real_decl)
+ overridden at link or run time.
+
+ It is actually requirement for C++ compiler to optimize const variables
+ consistently. As a GNU extension, do not enfore this rule for user defined
+ weak variables, so we support interposition on:
+ static const int dummy = 0;
+ extern const int foo __attribute__((__weak__, __alias__("dummy")));
+ */
+ if ((!DECL_INITIAL (real_decl)
+ || (DECL_WEAK (decl) && !DECL_COMDAT (decl)))
&& (DECL_EXTERNAL (decl) || decl_replaceable_p (decl)))
return error_mark_node;
Index: testsuite/gcc.dg/tree-ssa/pr61144.c
===
--- testsuite/gcc.dg/tree-ssa/pr61144.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/pr61144.c (revision 0)
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-require-weak "" } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+static int dummy = 0;
+extern int foo __attribute__((__weak__, __alias__("dummy")));
+int bar() { if (foo) return 1; return 0; }
+/* { dg-final { scan-tree-dump-not "return 0" "optimized"} } */
