RE: [PATCH] Update config.sub from upstream config repo
On Fri, 2 Jan 2015, James Bowman wrote: > Sorry, should have been clearer. > > Please can someone review and apply this patch, as I don't have write access > to the tree. Thanks. JFTR: to "apply this patch" to config.sub and config.guess is not the way to do it; not a valid request. Review of patches here is not correct: do that upstream. "Someone please import the newest upstream version" is the way to go. Done (to 714957f9 aka. 2015-01-01) also for gdb+binutils. I thought we had this written down somewhere, but maybe it's only in the gdb+binutils MAINTAINERS file. HNY. brgds, H-P
Fix a MinGW warning in libiberty/strerror.c
When compiling GDB 7.8.1, I get this warning in libiberty: gcc -c -DHAVE_CONFIG_H -O0 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ./strerror.c -o strerror.o ./strerror.c:472:12: warning: '_sys_nerr' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] ./strerror.c:473:14: warning: '_sys_errlist' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] This happens because the MinGW system headers have some special magic for these variables, which are imported from a system shared library. The solution I propose is to refrain from declaring variables that are actually macros, because this should be a sign that something tricky is going on: --- libiberty/strerror.c~0 2014-06-11 18:34:41 +0300 +++ libiberty/strerror.c2014-12-30 08:12:00 +0200 @@ -469,8 +469,13 @@ #else + +#ifndef sys_nerr extern int sys_nerr; +#endif +#ifndef sys_errlist extern char *sys_errlist[]; +#endif #endif OK to commit this (with a suitable ChangeLog entry)?
Re: [WWW] Update index.html and gcc-5/changes.html to reflect offloading changes.
On Tuesday 2014-12-30 18:49, Kirill Yukhin wrote: > I hope I taken into account all your inputs. > Updated patch in the bottom. This looks good, thank you Kirill. The only small detail I'd make is replacing the explicit "Details" link and making "offloading support was added to GCC" that link. Good ahead and commit with this change. Gerald
[Patch, Fortran + Testsuite] Fix coarray handling in modules
As found by Alessandro: Statically allocated coarrays in declared in the
specification part of a module didn't work (link-time failure). The
reason was that the associated coarray token was wrongly mangled and not
a public tree.
I additionally propagated the dg-compile-aux-modules support to caf.dg
(currently unused).
That's fixed by the attached patch.
OK for the trunk?
Tobias
2015-01-02 Tobias Burnus
* trans-decl.c (gfc_build_qualified_array): Fix coarray tokens
for module coarrays with -fcoarray=lib.
2015-01-02 Tobias Burnus
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Add.
* gfortran.dg/coarray/codimension_2.f90: New.
* gfortran.dg/coarray/codimension_2a.f90: New.
* gfortran.dg/coarray_35.f90: New.
* gfortran.dg/coarray_35a.f90: New.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 75b84f1..9ef6bfc 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -819,10 +819,22 @@ gfc_build_qualified_array (tree decl, gfc_symbol * sym)
&& GFC_TYPE_ARRAY_CAF_TOKEN (type) == NULL_TREE)
{
tree token;
+ tree token_type = build_qualified_type (pvoid_type_node,
+ TYPE_QUAL_RESTRICT);
+
+ if (sym->module && (sym->attr.use_assoc
+ || sym->ns->proc_name->attr.flavor == FL_MODULE))
+ {
+ tree token_name
+ = get_identifier (gfc_get_string (GFC_PREFIX ("caf_token%s"),
+ IDENTIFIER_POINTER (gfc_sym_mangled_identifier (sym;
+ token = build_decl (DECL_SOURCE_LOCATION (decl), VAR_DECL, token_name,
+ token_type);
+ TREE_PUBLIC (token) = 1;
+ }
+ else
+ token = gfc_create_var_np (token_type, "caf_token");
- token = gfc_create_var_np (build_qualified_type (pvoid_type_node,
- TYPE_QUAL_RESTRICT),
- "caf_token");
GFC_TYPE_ARRAY_CAF_TOKEN (type) = token;
DECL_ARTIFICIAL (token) = 1;
TREE_STATIC (token) = 1;
diff --git a/gcc/testsuite/gfortran.dg/coarray/caf.exp b/gcc/testsuite/gfortran.dg/coarray/caf.exp
index 011b5c9..e4e3798 100644
--- a/gcc/testsuite/gfortran.dg/coarray/caf.exp
+++ b/gcc/testsuite/gfortran.dg/coarray/caf.exp
@@ -43,6 +43,21 @@ global DG_TORTURE_OPTIONS torture_with_loops
torture-init
set-torture-options $DG_TORTURE_OPTIONS
+global gfortran_test_path
+global gfortran_aux_module_flags
+set gfortran_test_path $srcdir/$subdir
+set gfortran_aux_module_flags $DEFAULT_FFLAGS
+proc dg-compile-aux-modules { args } {
+global gfortran_test_path
+global gfortran_aux_module_flags
+if { [llength $args] != 2 } {
+ error "dg-set-target-env-var: needs one argument"
+ return
+}
+dg-test $gfortran_test_path/[lindex $args 1] "" $gfortran_aux_module_flags
+# cleanup-modules isn't intentionally invoked here.
+}
+
# Main loop.
foreach test [lsort [glob -nocomplain $srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]] {
# If we're only testing specific files and this isn't one of them, skip it.
@@ -65,12 +80,14 @@ foreach test [lsort [glob -nocomplain $srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]]
foreach flags $option_list {
verbose "Testing $nshort (single), $flags" 1
+set gfortran_aux_module_flags "-fcoarray=single $flags"
dg-test $test "-fcoarray=single $flags" ""
cleanup-modules ""
}
foreach flags $option_list {
verbose "Testing $nshort (libcaf_single), $flags" 1
+set gfortran_aux_module_flags "-fcoarray=lib $flags -lcaf_single"
dg-test $test "-fcoarray=lib $flags -lcaf_single" ""
cleanup-modules ""
}
diff --git a/gcc/testsuite/gfortran.dg/coarray/codimension_2.f90 b/gcc/testsuite/gfortran.dg/coarray/codimension_2.f90
new file mode 100644
index 000..b211f9b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/codimension_2.f90
@@ -0,0 +1,14 @@
+! { dg-do link }
+! { dg-additional-sources codimension_2a.f90 }
+!
+! To be used with codimension_2a.f90
+! Check that the coarray declared in the module is accessible
+! by doing a link test
+!
+! Contributed by Alessandro Fanfarillo.
+!
+module global_coarrays
+ implicit none
+ integer,parameter :: n=10
+ integer :: b(10)[*]
+end module global_coarrays
diff --git a/gcc/testsuite/gfortran.dg/coarray/codimension_2a.f90 b/gcc/testsuite/gfortran.dg/coarray/codimension_2a.f90
new file mode 100644
index 000..8eb472c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/codimension_2a.f90
@@ -0,0 +1,26 @@
+! { dg-do compile { target { ! *-*-* } } }
+! SKIP THIS FILE
+!
+! Used by codimension_2.f90
+!
+! Check that the coarray declared in the module is accessible
+! by doing a link test
+!
+! Contributed by Alessandro Fanfarillo.
+!
+program testmod
+ use global_coarrays
+ implicit none
+
+ integer :: me
+
+ me = this_image()
+
+ b = me
+
+ if(me==1) then
+ b(:) = b(:)[2]
+ write(*,*) b
+ end if
+
+end program testmod
diff --git a/gcc/testsuite/gfortran.dg/coarray/collectives_4.f90 b/gcc/testsuite/gfortran.dg/coarray/collectives_4.f90
new file mode 100644
index 000..6e7be46
--- /dev/null
+++ b/gcc/testsuite/gf
Re: [Patch, Fortran] PR 60507: Passing function call into procedure argument not caught
2014-12-31 19:13 GMT+01:00 Tobias Burnus : >> here is a patch to improve diagnostics for dummy procedures. Regtested >> on x86_64-unknown-linux-gnu. Ok for trunk? > > Looks good to me. Thanks for the patch! Thanks, committed as r219141. Cheers, Janus >> 2014-12-29 Janus Weil >> >> PR fortran/60507 >> * interface.c (is_procptr_result): New function to check if an >> expression is a procedure-pointer result. >> (compare_actual_formal): Use it. >> >> 2014-12-29 Janus Weil >> >> PR fortran/60507 >> * gfortran.dg/dummy_procedure_11: New.
[Patch, Fortran, OOP] PR 57562: ICE due to extended derived type with PARAMETER attribute
Hi all,
the attached patch fixes a problem with PARAMETER variables of
extended derived type: When resolving component references to the such
variables, we have to find the right component of the corresponding
structure constructor expression, which is done by the function
'find_component_ref'.
This function could not handle extended derived types, and so that is
what the patch does. For extended derived types, the first component
always represents the parent type. We have to iterate through the
whole inheritance chain, in order to check in which parent type the
desired component is located and fetch the corresponding constructor
component.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-02 Janus Weil
PR fortran/57562
* expr.c (find_component_ref): Deal with extended types.
2015-01-02 Janus Weil
PR fortran/57562
* gfortran.dg/extends_16.f90: New.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (Revision 219141)
+++ gcc/fortran/expr.c (Arbeitskopie)
@@ -1270,12 +1270,23 @@ depart:
static gfc_constructor *
find_component_ref (gfc_constructor_base base, gfc_ref *ref)
{
- gfc_component *comp;
- gfc_component *pick;
+ gfc_component *pick = ref->u.c.component;
gfc_constructor *c = gfc_constructor_first (base);
- comp = ref->u.c.sym->components;
- pick = ref->u.c.component;
+ gfc_symbol *dt = ref->u.c.sym;
+ int ext = dt->attr.extension;
+
+ /* For extended types, check if the desired component is in one of the
+ * parent types. */
+ while (ext>0 && gfc_find_component (dt->components->ts.u.derived, pick->name,
+ true, true))
+{
+ dt = dt->components->ts.u.derived;
+ c = gfc_constructor_first (c->expr->value.constructor);
+ ext--;
+}
+
+ gfc_component *comp = dt->components;
while (comp != pick)
{
comp = comp->next;
! { dg-do run }
!
! PR 57562: [OOP] ICE due to extended derived type with PARAMETER attribute
!
! Contributed by
type :: Parent
integer :: member1 = 0
end type
type, extends(Parent) :: Child
integer :: member2 = 0
end type
type(Child), parameter :: object = Child(23, 42)
if (object%member1 /= 23) call abort
if (object%member2 /= 42) call abort
end
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
> As found by Alessandro: Statically allocated coarrays in declared in the > specification part of a module didn't work (link-time failure). The reason > was that the associated coarray token was wrongly mangled and not a public > tree. > > I additionally propagated the dg-compile-aux-modules support to caf.dg > (currently unused). OK. It’s probably best to commit the two parts as separate commits, though. FX
Re: [PATCH] Fix PR libstdc++/64422
On 1 January 2015 at 08:50, Bernd Edlinger wrote: > Hi, > > this patch fixes unresolved externals with c++98 std::string templates. > > Boot-strapped and Regression-tested on x86_64-linux-gnu. > OK for trunk? The misc-inst.cc change looks good but as this is a libstdc++ bug the testcase should be under the libstdc++-v3/testsuite dir and the patch should be CC'd to the libstdc++ list.
Re: [Patch, Fortran] add co_reduce to libcaf_single
An early PING. Last year, Tobias Burnus wrote: Looking through the stashed patches, I realized a pending (unsubmitted) patch, showing that both a test case for CO_REDUCE was missing and that libcaf_single didn't include co_reduce. This patch adds them. Build and regtested on x86-64-gnu-linux. OK for the trunk? [Still to do for co_reduce: Checking whether any recent changes to the coarray draft requires changes to that feature. I think there were changes to co_reduce.] Tobias PS: For GCC 5, I really should complete the coarray support: add LOCKING as missing F2008 feature (basic support only; currently its pretending to always succeed), catch at compile time unsupported features (rather than to fail at run time with wrong results) plus adding vector support in libcaf_single.
Re: [PATCH] Fix PR libstdc++/64422
Hi, On 01/02/2015 04:33 PM, Jonathan Wakely wrote: The misc-inst.cc change looks good but as this is a libstdc++ bug the testcase should be under the libstdc++-v3/testsuite dir and the patch should be CC'd to the libstdc++ list. ... and shouldn't be a dg-do run, I would add. Paolo.
Re: [Patch, Fortran] add co_reduce to libcaf_single
Hi Tobias, > Looking through the stashed patches, I realized a pending (unsubmitted) > patch, showing that both a test case for CO_REDUCE was missing and that > libcaf_single didn't include co_reduce. > > This patch adds them. > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? looks rather trivial to me. All the correctness checking for CO_REDUCE is already there, right? Cheers, Janus
Re: [Patch, Fortran, OOP] PR 57562: ICE due to extended derived type with PARAMETER attribute
2015-01-02 17:02 GMT+01:00 Tobias Burnus :
> + int ext = dt->attr.extension;
> + while (ext>0 && gfc_find_component (dt->components->ts.u.derived,
> pick->name,
> + true, true))
> +{
> + dt = dt->components->ts.u.derived;
> + c = gfc_constructor_first (c->expr->value.constructor);
> + ext--;
> +}
>
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
>
> Style comment: "ext>0" should be written as "ext > 0".
Good point. Will fix.
> Additionally, I'd prefer a test case which has another level of inheritance.
> (Like the attached test case.)
Sure, then I'll just use that one ...
> Otherwise, it looks okay. Thanks!
Thanks for the review!
Cheers,
Janus
Re: [Patch, libstdc++/64441] Fix sub_match::first and second
On 2 January 2015 at 01:29, Tim Shen wrote: > Oh, errr... I'm not sure if it needs a review by probably Jonathan? I think it qualifies as obvious and so doesn't need approval, but please wait for me to rotate the ChangeLog file, so we start a new file for 2015. I'm going to do that in the next hour (or sooner, if I can get a good network connection).
Re: [Patch, Fortran] add co_reduce to libcaf_single
Hi Janus, Janus Weil wrote: Looking through the stashed patches, I realized a pending (unsubmitted) patch, showing that both a test case for CO_REDUCE was missing and that libcaf_single didn't include co_reduce. This patch adds them. Build and regtested on x86-64-gnu-linux. OK for the trunk? looks rather trivial to me. All the correctness checking for CO_REDUCE is already there, right? Do you mean compile-time diagnostic for invalid arguments? Yes, those are at gfortran.dg/coarray_collectives_9.f90 to gfortran.dg/coarray_collectives_16.f90. For run time, this patch adds a check, albeit it is not really checkable with num_images() == 1. The multi-image library libcaf_mpi of OpenCoarrays currently only supports co_sum/min/max and co_broadcast and not yet co_reduce. Tobias
Re: [Patch, Fortran, OOP] PR 57562: ICE due to extended derived type with PARAMETER attribute
Committed as r219144.
Cheers,
Janus
2015-01-02 17:13 GMT+01:00 Janus Weil :
> 2015-01-02 17:02 GMT+01:00 Tobias Burnus :
>> + int ext = dt->attr.extension;
>> + while (ext>0 && gfc_find_component (dt->components->ts.u.derived,
>> pick->name,
>> + true, true))
>> +{
>> + dt = dt->components->ts.u.derived;
>> + c = gfc_constructor_first (c->expr->value.constructor);
>> + ext--;
>> +}
>>
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
>>
>> Style comment: "ext>0" should be written as "ext > 0".
>
> Good point. Will fix.
>
>
>> Additionally, I'd prefer a test case which has another level of inheritance.
>> (Like the attached test case.)
>
> Sure, then I'll just use that one ...
>
>
>> Otherwise, it looks okay. Thanks!
>
> Thanks for the review!
>
> Cheers,
> Janus
Re: std::stoi and std::to_string on MinGW
On 22/12/14 16:41 +, Jonathan Wakely wrote:
Thanks, Kai. Here's the full patch, which enables std::stoi etc.
(everything except std::to_wstring) for MinGW.org
Tested powerpc64-linux, committed to trunk.
I shouldn't have removed the dg-require-string-conversions from the
tests, because that means they get run on platforms without C99
support, and so they FAIL.
Fixed with this patch, tested x86_64-linux, committed to trunk.
I've also rotated the libstdc++ ChangeLog.
commit e76c1af5a0c36704012fb174832ff0f49b1df43c
Author: Jonathan Wakely
Date: Fri Jan 2 15:42:41 2015 +
PR libstdc++/64438
* testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:
Revert removal of dg-require-string-conversions.
* testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/
stoull.cc: Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/
to_string.cc: Likewise.
index 000..d8ea607
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc
index e7fea9e..b9de1cd 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-string-conversions "" }
// 2009-11-11 Paolo Carlini
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc
index fa9dedb..5e3060c 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-string-conversions "" }
// 2008-06-15 Paolo Carlini
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc
index 16b9fc2..607f97b 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-string-conversions "" }
// 2008-06-15 Paolo Carlini
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc
index 1032e6e..6c0fb98 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-string-conversions "" }
// 2008-06-15 Paolo Carlini
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc
index df6ad78..9cdb4b0 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-string-conversions "" }
// 2008-06-15 Paolo Carlini
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
index e201780..039534c 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-string-conversions "" }
// 2008-06-15 Paolo Carlini
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc
index b5ced9f..dce8fdf 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/ch
[patch] libstdc++/64468 set TAB_SIZE=8 in doxygen cfg
Make Doxygen use the right tab size. Committed to trunk. commit d8314acccb012f4c166ef2667b08190d31a308d1 Author: Jonathan Wakely Date: Fri Jan 2 15:56:22 2015 + PR libstdc++/64468 * doc/doxygen/user.cfg.in: Set correct TAB_SIZE. diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in b/libstdc++-v3/doc/doxygen/user.cfg.in index 019462e..ff2db48 100644 --- a/libstdc++-v3/doc/doxygen/user.cfg.in +++ b/libstdc++-v3/doc/doxygen/user.cfg.in @@ -208,7 +208,7 @@ SEPARATE_MEMBER_PAGES = NO # uses this value to replace tabs by spaces in code fragments. # Minimum value: 1, maximum value: 16, default value: 4. -TAB_SIZE = 4 +TAB_SIZE = 8 # This tag can be used to specify a number of aliases that act as commands in # the documentation. An alias has the form:
Re: [Patch, libstdc++/64441] Fix sub_match::first and second
On 2 January 2015 at 16:19, Jonathan Wakely wrote: > On 2 January 2015 at 01:29, Tim Shen wrote: >> Oh, errr... I'm not sure if it needs a review by probably Jonathan? > > I think it qualifies as obvious and so doesn't need approval, but > please wait for me to rotate the ChangeLog file, so we start a new > file for 2015. I'm going to do that in the next hour (or sooner, if I > can get a good network connection). That's done now, so please go ahead and commit the fix.
Re: [Patch, Fortran] add co_reduce to libcaf_single
2015-01-02 17:24 GMT+01:00 Tobias Burnus : >>> Looking through the stashed patches, I realized a pending (unsubmitted) >>> patch, showing that both a test case for CO_REDUCE was missing and that >>> libcaf_single didn't include co_reduce. >>> >>> This patch adds them. >>> >>> Build and regtested on x86-64-gnu-linux. >>> OK for the trunk? >> >> looks rather trivial to me. All the correctness checking for CO_REDUCE >> is already there, right? > > Do you mean compile-time diagnostic for invalid arguments? Yeah, that's what I meant. > Yes, those are at > gfortran.dg/coarray_collectives_9.f90 to > gfortran.dg/coarray_collectives_16.f90. Yes, just found those. > For run time, this patch adds a check, albeit it is not really checkable > with num_images() == 1. You mean via the STAT and ERRMSG arguments? In any case, the patch is ok from my side. Cheers, Janus
RE: [PATCH] Fix PR libstdc++/64422
Hi, On Fri, 2 Jan 2015 16:41:38, Paolo Carlini wrote: > > Hi, > > On 01/02/2015 04:33 PM, Jonathan Wakely wrote: >> The misc-inst.cc change looks good but as this is a libstdc++ bug the >> testcase should be under the libstdc++-v3/testsuite dir and the patch >> should be CC'd to the libstdc++ list. > ... and shouldn't be a dg-do run, I would add. > > Paolo. How about this? I verified that the test case is still able to detect the missing symbols. Actually I was not quite sure where to add the test case. Is it OK here? Thanks Bernd. libstdc++v3/ChangeLog: 2015-01-01 Bernd Edlinger PR libstdc++/64422 * src/c++98/misc-inst.cc (string::erase): Add missing overloads. (string::insert): Likewise. (string::replace): Likewise. (wstring::erase): Likewise. (wstring::insert): Likewise. (wstring::replace): Likewise. * testsuite/21_strings/basic_string/types/64422.cc: New testcase. patch-pr64422.diff Description: Binary data
Re: [Patch, i386] Support AES, F16C, BMI and BMI2 targets in multiversioning
On Wed, Dec 31, 2014 at 02:38:09PM +0100, Allan Sandfeld Jensen wrote: > On Wednesday 31 December 2014, Jakub Jelinek wrote: > > On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: > > > I recently wanted to use multiversioning for BMI2 specific extensions > > > PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, > > > and also added AES, F16C and BMI1 for completeness. > > > > AES nor F16C doesn't make any sense IMHO for multiversioning, you need > > special intrinsics for that anyway and when you use them, the function will > > fail to compile without those features. > > Multiversioning only makes sense for ISA features the compiler uses for > > normal C/C++ code without any intrinsics. > > > I disagree. You just include the intrinsics and use them. Inside a function > with the right target rule they will work even if they don't outside. This > works even without multiversioning, e.g. just specific functions with > specific > targets. I don't understand. Target attribute for aes or f16c of course makes sense, but that is already supported. But for multiversioning, you can't have intrinsics vs. other code depending on what the function is multiversioned for. So, you either don't use them at all, then multiversioning on it doesn't make sense, or you include them, and get errors because intrinsics are used in a function that doesn't support aes or f16c. Jakub
Re: [wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html
On 12/30/2014 10:44 AM, Jason Merrill wrote: On 12/27/2014 07:56 PM, Ed Smith-Rowland wrote: I would like peoples opinion of adding another column to the tables indicating C++ feature status for C++11 and C++14 that contains the relevant SD-6 feature macro. Sure, that makes sense. Jason Jason, I seem unable to commit to wwwdocs. Could you or someone else commit this for me? Thanks, Ed
Re: [PATCH] Instrument bit field and unaligned accesses for TSAN
On Mon, Dec 29, 2014 at 09:20:57PM +0100, Bernd Edlinger wrote: > --- gcc/sanitizer.def (revision 218963) > +++ gcc/sanitizer.def (working copy) > @@ -188,6 +188,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE8, "__tsa > BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) > DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE16, "__tsan_write16", > BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) > +DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_READ_RANGE, "__tsan_read_range", > + BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) > +DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE_RANGE, "__tsan_write_range", > + BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) > > DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOMIC8_LOAD, > "__tsan_atomic8_load", For the BUILT_IN_VPTR_UPDATE builtin you also need to change the prototype, to BT_FN_VOID_PTR_PTR. Do you have a testcase for the __tsan_vptr_update bug? Can you submit it separately, because it probably is desirable also for the 4.9 and 4.8 branches. > @@ -173,13 +227,21 @@ instrument_expr (gimple_stmt_iterator gsi, tree ex >gimple_set_location (g, loc); >gimple_seq_add_stmt_without_update (&seq, g); > } > - if (rhs == NULL) > + if ((size & -size) != size || size > 16 Isn't (size & (size - 1)) == 0 a better check? Otherwise LGTM. Jakub
Re: [PATCH] Fix PR libstdc++/64422
On 2 January 2015 at 18:05, Bernd Edlinger wrote: > > Hi, > > On Fri, 2 Jan 2015 16:41:38, Paolo Carlini wrote: >> >> Hi, >> >> On 01/02/2015 04:33 PM, Jonathan Wakely wrote: >>> The misc-inst.cc change looks good but as this is a libstdc++ bug the >>> testcase should be under the libstdc++-v3/testsuite dir and the patch >>> should be CC'd to the libstdc++ list. >> ... and shouldn't be a dg-do run, I would add. >> >> Paolo. > > How about this? I verified that the test case is still able to detect > the missing symbols. > Actually I was not quite sure where to add the test case. Is it OK here? It isn't testing the member types, so I think either in 21_strings/basic_string/ or 21_strings/basic_string/modifiers/ (since all the missing symbols happen to be ones defined in the "modifiers" subclause). For some reason that I don't really know, we put the FSF copyright and GPLv3+exception copying permission statement in all libstdc++ tests, please see one of the existing tests for the exact wording. OK for trunk after moving it to one of those other directories and adding the copyright boilerplate - thanks very much for fixing it.
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
On Jan 2, 2015, at 3:28 AM, Tobias Burnus wrote: > As found by Alessandro: Statically allocated coarrays in declared in the > specification part of a module didn't work (link-time failure). The reason > was that the associated coarray token was wrongly mangled and not a public > tree. > > I additionally propagated the dg-compile-aux-modules support to caf.dg > (currently unused). > OK for the trunk? So, I usually let the fortran people review and comment on things like this. They do a great job and seems pretty straight forward. I looked at it and didn’t see anything that was objectionable to me. Seems usual and customary.
RE: [PATCH] Instrument bit field and unaligned accesses for TSAN
On Fri, 2 Jan 2015 20:01:02, Jakub Jelinke wrote: > > On Mon, Dec 29, 2014 at 09:20:57PM +0100, Bernd Edlinger wrote: > >> --- gcc/sanitizer.def (revision 218963) >> +++ gcc/sanitizer.def (working copy) >> @@ -188,6 +188,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE8, "__tsa >> BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) >> DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE16, "__tsan_write16", >> BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) >> +DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_READ_RANGE, "__tsan_read_range", >> + BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) >> +DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE_RANGE, "__tsan_write_range", >> + BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST) >> >> DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOMIC8_LOAD, >> "__tsan_atomic8_load", > > For the BUILT_IN_VPTR_UPDATE builtin you also need to change > the prototype, to BT_FN_VOID_PTR_PTR. Do you have a testcase for the > __tsan_vptr_update bug? Can you submit it separately, because it > probably is desirable also for the 4.9 and 4.8 branches. > OK, I will do that. I removed the __tsan_vptr_update stuff from the patch, for now. It will probably be difficult for me to find a test case for this, because I am not really sure what __tsan_vptr_update is actually good for, (i.e. the use case). >> @@ -173,13 +227,21 @@ instrument_expr (gimple_stmt_iterator gsi, tree ex >> gimple_set_location (g, loc); >> gimple_seq_add_stmt_without_update (&seq, g); >> } >> - if (rhs == NULL) >> + if ((size & -size) != size || size> 16 > > Isn't (size & (size - 1)) == 0 a better check? > Yes, that's of course better, Thanks. I think I should also change the function type of BUILT_IN_READ_RANGE and BUILT_IN_WRITE_RANGE to BT_FN_VOID_PTR_SIZE? I attached the updated version of the patch. Is that OK too? Thanks Bernd. > Otherwise LGTM. > > Jakub gcc/ChangeLog: 2015-01-02 Bernd Edlinger Instrument bit field and unaligned accesses for TSAN. * asan.c (initialize_sanitizer_builtins): New function type BT_FN_VOID_PTR_SIZE. * sanitizer.def (BUILT_IN_TSAN_READ_RANGE): New built-in function. (BUILT_IN_TSAN_WRITE_RANGE): New built-in function. * tsan.c (instrument_expr): Handle COMPONENT_REF and BIT_FIELD_REF. Use BUILT_IN_TSAN_READ_RANGE and BUILT_IN_TSAN_WRITE_RANGE for unaligned memory regions. testsuite/ChangeLog: 2015-01-02 Bernd Edlinger * c-c++-common/tsan/bitfield_race.c: New testcase. * g++.dg/tsan/aligned_vs_unaligned_race.C: Fixed. patch-tsan-bitfields.diff Description: Binary data
Re: [PATCH] Instrument bit field and unaligned accesses for TSAN
On Fri, Jan 02, 2015 at 10:06:29PM +0100, Bernd Edlinger wrote: > OK, I will do that. > I removed the __tsan_vptr_update stuff from the patch, for now. Guess we should ask Dmitry about that. > It will probably be difficult for me to find a test case for this, > because I am not really sure what __tsan_vptr_update is actually good for, > (i.e. the use case). > I think I should also change the function type of BUILT_IN_READ_RANGE > and BUILT_IN_WRITE_RANGE to BT_FN_VOID_PTR_SIZE? You should use BT_FN_VOID_PTR_PTRMODE for those instead, and you don't need to initialize it in asan.c - it is already initialized there. size_t might be a different integer type from uptr. Jakub
RE: [PATCH] Instrument bit field and unaligned accesses for TSAN
Hi, On Fri, 2 Jan 2015 22:29:01, Jakub Jelinek wrote: > > On Fri, Jan 02, 2015 at 10:06:29PM +0100, Bernd Edlinger wrote: >> OK, I will do that. >> I removed the __tsan_vptr_update stuff from the patch, for now. > > Guess we should ask Dmitry about that. > >> It will probably be difficult for me to find a test case for this, >> because I am not really sure what __tsan_vptr_update is actually good for, >> (i.e. the use case). > >> I think I should also change the function type of BUILT_IN_READ_RANGE >> and BUILT_IN_WRITE_RANGE to BT_FN_VOID_PTR_SIZE? > > You should use BT_FN_VOID_PTR_PTRMODE for those instead, and you don't need to > initialize it in asan.c - it is already initialized there. > size_t might be a different integer type from uptr. > > Jakub Dmitry, while I wrote this patch, I became aware of a minor flaw in GCC's instrumentation of __tsan_vptr_update. That is, currently we pass only the address of the vptr that is about to be written to this function, but the second parameter, the value that will be written, is always garbage. Jakub asked for a test case, but I am not sure about what is the use case, where this would make a difference. Can you shed some light on this? Thanks. Jakub, I changed the function type to BT_FN_VOID_PTR_PTRMODE, is the patch OK now? Thanks Bernd. gcc/ChangeLog: 2015-01-02 Bernd Edlinger Instrument bit field and unaligned accesses for TSAN. * sanitizer.def (BUILT_IN_TSAN_READ_RANGE): New built-in function. (BUILT_IN_TSAN_WRITE_RANGE): New built-in function. * tsan.c (instrument_expr): Handle COMPONENT_REF and BIT_FIELD_REF. Use BUILT_IN_TSAN_READ_RANGE and BUILT_IN_TSAN_WRITE_RANGE for unaligned memory regions. testsuite/ChangeLog: 2015-01-02 Bernd Edlinger * c-c++-common/tsan/bitfield_race.c: New testcase. * g++.dg/tsan/aligned_vs_unaligned_race.C: Fixed. patch-tsan-bitfields.diff Description: Binary data
Re: [PATCH] Instrument bit field and unaligned accesses for TSAN
On Fri, Jan 02, 2015 at 11:01:56PM +0100, Bernd Edlinger wrote: > gcc/ChangeLog: > 2015-01-02 Bernd Edlinger > > Instrument bit field and unaligned accesses for TSAN. > * sanitizer.def (BUILT_IN_TSAN_READ_RANGE): New built-in function. > (BUILT_IN_TSAN_WRITE_RANGE): New built-in function. > * tsan.c (instrument_expr): Handle COMPONENT_REF and BIT_FIELD_REF. > Use BUILT_IN_TSAN_READ_RANGE and BUILT_IN_TSAN_WRITE_RANGE for > unaligned memory regions. > > testsuite/ChangeLog: > 2015-01-02 Bernd Edlinger > > * c-c++-common/tsan/bitfield_race.c: New testcase. > * g++.dg/tsan/aligned_vs_unaligned_race.C: Fixed. Ok for trunk. Jakub
Re: [Patch, libstdc++/64441] Fix sub_match::first and second
On Fri, Jan 2, 2015 at 8:54 AM, Jonathan Wakely wrote: > That's done now, so please go ahead and commit the fix. Committed. I obviously used wrong branch (which doesn't include the actual change) for testing so I missed the testing failure. Sorry about that. :( -- Regards, Tim Shen
Fixed my previous check-in (tsan.c)
Unfortunately I did the check for not-power-of-two in the wrong way.
Committed as obvious.
Index: ChangeLog
===
--- ChangeLog (Revision 219151)
+++ ChangeLog (Revision 219152)
@@ -1,5 +1,9 @@
2015-01-02 Bernd Edlinger
+ * tsan.c (instrument_expr): corrected previous checkin.
+
+2015-01-02 Bernd Edlinger
+
Instrument bit field and unaligned accesses for TSAN.
* sanitizer.def (BUILT_IN_TSAN_READ_RANGE): New built-in function.
(BUILT_IN_TSAN_WRITE_RANGE): New built-in function.
Index: tsan.c
===
--- tsan.c (Revision 219151)
+++ tsan.c (Revision 219152)
@@ -227,7 +227,7 @@
gimple_set_location (g, loc);
gimple_seq_add_stmt_without_update (&seq, g);
}
- if ((size & (size - 1)) == 0 || size> 16
+ if ((size & (size - 1)) != 0 || size> 16
|| align < MIN (size, 8) * BITS_PER_UNIT)
{
builtin_decl = builtin_decl_implicit (is_write
Re: [PATCH] Fix PR libstdc++/64422
On 02/01/15 19:59 +, Jonathan Wakely wrote: On 2 January 2015 at 18:05, Bernd Edlinger wrote: Hi, On Fri, 2 Jan 2015 16:41:38, Paolo Carlini wrote: Hi, On 01/02/2015 04:33 PM, Jonathan Wakely wrote: The misc-inst.cc change looks good but as this is a libstdc++ bug the testcase should be under the libstdc++-v3/testsuite dir and the patch should be CC'd to the libstdc++ list. ... and shouldn't be a dg-do run, I would add. Paolo. How about this? I verified that the test case is still able to detect the missing symbols. Actually I was not quite sure where to add the test case. Is it OK here? It isn't testing the member types, so I think either in 21_strings/basic_string/ or 21_strings/basic_string/modifiers/ (since all the missing symbols happen to be ones defined in the "modifiers" subclause). For some reason that I don't really know, we put the FSF copyright and GPLv3+exception copying permission statement in all libstdc++ tests, please see one of the existing tests for the exact wording. OK for trunk after moving it to one of those other directories and adding the copyright boilerplate - thanks very much for fixing it. One small tweak to the commit, the copyright date on the new file should be just 2015. Committed to trunk. commit df6648533281d52cf9eadd6e0c319daf1c00a9bb Author: Jonathan Wakely Date: Fri Jan 2 22:44:39 2015 + * testsuite/21_strings/basic_string/modifiers/64422.cc: Fix copyright date. diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc index 4b37ba9..524261a 100644 --- a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc +++ b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc @@ -1,6 +1,6 @@ // 2015-01-02 Bernd Edlinger -// Copyright (C) 2005-2015 Free Software Foundation, Inc. +// Copyright (C) 2015 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
[doc, committed] tidy -fopt-info documentation
I noticed that the documentation for -fopt-info in invoke.texi had
numerous markup problems. While I was tidying that up, I saw that it
also said contradictory things about the defaults in different
paragraphs, so I fixed that as well by consolidating the discussion (and
checking the source code for what the default really is). I also did
some light copy-editing.
I've checked this in as an obvious cleanup, since it's boring tech
writer stuff and not a substantive change. ;-)
-Sandra
2015-01-02 Sandra Loosemore
gcc/
* doc/invoke.texi ([-fopt-info]): Fix markup, consolidate
discussion of defaults, light copy-editing.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219119)
+++ gcc/doc/invoke.texi (working copy)
@@ -6772,52 +6772,37 @@ Enable all the available tree dumps with
@opindex fopt-info
Controls optimization dumps from various optimization passes. If the
@samp{-@var{options}} form is used, @var{options} is a list of
-@samp{-} separated options to select the dump details and
-optimizations. If @var{options} is not specified, it defaults to
-@option{optimized} for details and @option{optall} for optimization
-groups. If the @var{filename} is not specified, it defaults to
-@file{stderr}. Note that the output @var{filename} will be overwritten
-in case of multiple translation units. If a combined output from
-multiple translation units is desired, @file{stderr} should be used
-instead.
+@samp{-} separated option keywords to select the dump details and
+optimizations.
-The options can be divided into two groups, 1) options describing the
-verbosity of the dump, and 2) options describing which optimizations
+The @var{options} can be divided into two groups: options describing the
+verbosity of the dump, and options describing which optimizations
should be included. The options from both the groups can be freely
mixed as they are non-overlapping. However, in case of any conflicts,
-the latter options override the earlier options on the command
-line. Though multiple -fopt-info options are accepted, only one of
-them can have @option{=filename}. If other filenames are provided then
-all but the first one are ignored.
+the later options override the earlier options on the command
+line.
-The dump verbosity has the following options
+The following options control the dump verbosity:
@table @samp
@item optimized
Print information when an optimization is successfully applied. It is
up to a pass to decide which information is relevant. For example, the
-vectorizer passes print the source location of loops which got
+vectorizer passes print the source location of loops which are
successfully vectorized.
@item missed
Print information about missed optimizations. Individual passes
-control which information to include in the output. For example,
-
-@smallexample
-gcc -O2 -ftree-vectorize -fopt-info-vec-missed
-@end smallexample
-
-will print information about missed optimization opportunities from
-vectorization passes on stderr.
+control which information to include in the output.
@item note
Print verbose information about optimizations, such as certain
transformations, more detailed messages about decisions etc.
@item all
Print detailed optimization information. This includes
-@var{optimized}, @var{missed}, and @var{note}.
+@samp{optimized}, @samp{missed}, and @samp{note}.
@end table
-The second set of options describes a group of optimizations and may
-include one or more of the following.
+One or more of the following option keywords can be used to describe a
+group of optimizations:
@table @samp
@item ipa
@@ -6833,47 +6818,69 @@ Enable dumps from all optimizations. Thi
the optimization groups listed above.
@end table
-For example,
+If @var{options} is
+omitted, it defaults to @samp{optimized-optall}, which means to dump all
+info about successful optimizations from all the passes.
+
+If the @var{filename} is provided, then the dumps from all the
+applicable optimizations are concatenated into the @var{filename}.
+Otherwise the dump is output onto @file{stderr}. Though multiple
+@option{-fopt-info} options are accepted, only one of them can include
+a @var{filename}. If other filenames are provided then all but the
+first such option are ignored.
+
+Note that the output @var{filename} is overwritten
+in case of multiple translation units. If a combined output from
+multiple translation units is desired, @file{stderr} should be used
+instead.
+
+In the following example, the optimization info is output to
+@file{stderr}:
+
+@smallexample
+gcc -O3 -fopt-info
+@end smallexample
+
+This example:
@smallexample
gcc -O3 -fopt-info-missed=missed.all
@end smallexample
+@noindent
outputs missed optimization report from all the passes into
-@file{missed.all}.
+@file{missed.all}, and this one:
-As another example,
@smallexample
-gcc -O3 -fopt-info-inline-o
[doc, committed] fix typos in docs/comments for devirtualization optimizations
I noticed a number of typos in the documentation for the
devirtualization optimization options in invoke.texi, also in the short
option description in common.opt. When I was browsing the code to make
sure I understood the purpose of these options, I noticed that there
were very many more typos in the comments in ipa-devirt.c. I've made a
pass through everything to clean things up and checked in this patch
under the "obvious fix" rule.
There were a couple things I didn't address here:
* I suggest renaming the function type_known_to_have_no_deriavations_p
to type_known_to_have_no_derivations_p. (I suppose such a code change
requires a complete bootstrap and regression test I'm lazy)
* I noticed the comments documenting possible_polymorphic_call_targets
appear to be describing parameters and behavior that aren't there any
more. I'll leave fixing that up to somebody who has a deeper
understanding of the code.
-Sandra
2015-01-02 Sandra Loosemore
gcc/
* doc/invoke.texi (Option Summary): Fix spelling of
-fdevirtualize-at-ltrans.
([-fdevirtualize]): Fix markup.
([-fdevirtualize-speculatively]): Fix typo.
([-fdevirtualize-at-ltrans]): Likewise. Make description less
implementor-speaky.
* common.opt (fdevirtualize-at-ltrans): Likewise.
* ipa-devirt.c: Fix typos in comments throughout the file.
(ipa_devirt): Fix typos in format strings for dump output.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219154)
+++ gcc/doc/invoke.texi (working copy)
@@ -378,7 +378,7 @@ Objective-C and Objective-C++ Dialects}.
-fcx-limited-range @gol
-fdata-sections -fdce -fdelayed-branch @gol
-fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively @gol
--devirtualize-at-ltrans -fdse @gol
+-fdevirtualize-at-ltrans -fdse @gol
-fearly-inlining -fipa-sra -fexpensive-optimizations -ffat-lto-objects @gol
-ffast-math -ffinite-math-only -ffloat-store -fexcess-precision=@var{style} @gol
-fforward-propagate -ffp-contract=@var{style} -ffunction-sections @gol
@@ -7772,7 +7772,7 @@ are enabled independently at different o
@opindex fdevirtualize
Attempt to convert calls to virtual functions to direct calls. This
is done both within a procedure and interprocedurally as part of
-indirect inlining (@code{-findirect-inlining}) and interprocedural constant
+indirect inlining (@option{-findirect-inlining}) and interprocedural constant
propagation (@option{-fipa-cp}).
Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
@@ -7781,14 +7781,15 @@ Enabled at levels @option{-O2}, @option{
Attempt to convert calls to virtual functions to speculative direct calls.
Based on the analysis of the type inheritance graph, determine for a given call
the set of likely targets. If the set is small, preferably of size 1, change
-the call into an conditional deciding on direct and indirect call. The
+the call into a conditional deciding between direct and indirect calls. The
speculative calls enable more optimizations, such as inlining. When they seem
useless after further optimization, they are converted back into original form.
@item -fdevirtualize-at-ltrans
@opindex fdevirtualize-at-ltrans
-Perform extra streaming needed for agressive devirtualization during LTO local
-transformation stage. This option enables more devirtualization but
+Stream extra information needed for aggressive devirtualization when running
+the link-time optimizer in local transformation mode.
+This option enables more devirtualization but
significantly increases the size of streamed data. For this reason it is
disabled by default.
Index: gcc/common.opt
===
--- gcc/common.opt (revision 219153)
+++ gcc/common.opt (working copy)
@@ -1064,7 +1064,7 @@ Delete useless null pointer checks
fdevirtualize-at-ltrans
Common Report Var(flag_ltrans_devirtualize)
-Perofrm extra streaming to support more agressive devirtualization at LTO ltrans stage.
+Stream extra data to support more aggressive devirtualization in LTO local transformation mode
fdevirtualize-speculatively
Common Report Var(flag_devirtualize_speculatively) Optimization
Index: gcc/ipa-devirt.c
===
--- gcc/ipa-devirt.c (revision 219153)
+++ gcc/ipa-devirt.c (working copy)
@@ -19,7 +19,7 @@ You should have received a copy of the G
along with GCC; see the file COPYING3. If not see
[GOOGLE] Refine LIPO aux function removal
Fixes a problem caused by my recent change to allow aux functions to
be removed. They need to be kept until after LIPO linking/static
promotion, since they affect the promoted names of any static
variables defined within their context.
Passes regression and internal testing. Ok for google/4_9?
Thanks,
Teresa
2015-01-02 Teresa Johnson
Google ref b/18882262.
* cgraph.c (cgraph_can_remove_if_no_direct_calls_and_refs_p): Keep
aux functions until after LIPO linking.
Index: cgraph.c
===
--- cgraph.c(revision 219100)
+++ cgraph.c(working copy)
@@ -2462,8 +2462,13 @@ cgraph_can_remove_if_no_direct_calls_and_refs_p (s
{
gcc_assert (!node->global.inlined_to);
/* Extern inlines can always go, we will use the external definition. */
- if (DECL_EXTERNAL (node->decl) || cgraph_is_aux_decl_external (node))
+ if (DECL_EXTERNAL (node->decl))
return true;
+ /* Aux functions are safe to remove, but only once static promotion is
+ complete since they may affect promoted names if they are the context
+ for any static variables. */
+ if (cgraph_pre_profiling_inlining_done && cgraph_is_aux_decl_external (node))
+return true;
/* When function is needed, we can not remove it. */
if (node->force_output || node->used_from_other_partition)
return false;
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [GOOGLE] Refine LIPO aux function removal
ok.
David
On Fri, Jan 2, 2015 at 10:19 PM, Teresa Johnson wrote:
> Fixes a problem caused by my recent change to allow aux functions to
> be removed. They need to be kept until after LIPO linking/static
> promotion, since they affect the promoted names of any static
> variables defined within their context.
>
> Passes regression and internal testing. Ok for google/4_9?
>
> Thanks,
> Teresa
>
> 2015-01-02 Teresa Johnson
>
> Google ref b/18882262.
> * cgraph.c (cgraph_can_remove_if_no_direct_calls_and_refs_p): Keep
> aux functions until after LIPO linking.
>
> Index: cgraph.c
> ===
> --- cgraph.c(revision 219100)
> +++ cgraph.c(working copy)
> @@ -2462,8 +2462,13 @@ cgraph_can_remove_if_no_direct_calls_and_refs_p (s
> {
>gcc_assert (!node->global.inlined_to);
>/* Extern inlines can always go, we will use the external definition. */
> - if (DECL_EXTERNAL (node->decl) || cgraph_is_aux_decl_external (node))
> + if (DECL_EXTERNAL (node->decl))
> return true;
> + /* Aux functions are safe to remove, but only once static promotion is
> + complete since they may affect promoted names if they are the context
> + for any static variables. */
> + if (cgraph_pre_profiling_inlining_done && cgraph_is_aux_decl_external
> (node))
> +return true;
>/* When function is needed, we can not remove it. */
>if (node->force_output || node->used_from_other_partition)
> return false;
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
