Re: [PATCH] Run DCE after if conversion
On 03/10/2015 11:27 AM, Richard Biener wrote: > On Tue, Mar 10, 2015 at 10:19 AM, Andreas Krebbel > wrote: >> On 03/10/2015 10:12 AM, Steven Bosscher wrote: >>> On Tue, Mar 10, 2015 at 8:57 AM, Andreas Krebbel wrote: * gcc/ifcvt.c (if_convert): >>> >>> ...yes...? >> >> Damn. mklog is still not able to do the complete job for me ;) >> >>> Tiny nail, huge hammer. This triggers a full re-scan of all insns and >>> a re-calculation of all dataflow problems. >>> >>> The transformations in ifcvt are all simple enough that it should be >>> possible to just clean up that redundant insn at the site where the >>> code transformation is performed. >> >> Agreed. I was hoping to get this low risk version into 5.0. > > Low risk? High risk of heavy compile-time regression I'd say > (make a testcase that triggers a lot of iteration). Just to have some numbers I did run a -j1 GCC bootstrap twice with and without the patch on x86_64. Best results for both are: clean: 21459s patched: 21314s There rather appears to be a trend towards reduced compile time perhaps due to the reduced number of INSNs to be processed in the RTL passes between the two ifcvt runs (loop optimization, combine, fwprop, dse,...)?! I also tried to measure the testsuite runs but the results show a big variance. So what I have right now does not qualify as a benchmark. Bye, -Andreas- > > Is this fixing a regression in some way? > > Richard. > >> Bye, >> >> -Andreas- >> >> >
Re: [Patch, Fortran, PR 64787, v1] Invalid code on sourced allocation of class(*) character string
Dear Andre,
I have bootstrapped and regtested successfully r221474 with your set of
patches. I am seeing some more fixes, but also some new ICEs and segfaults
(some of them being regressions):
(1) The patches fix pr63230.
(2) The test in pr51550 compiles, but segfaults at run time.
(3) The original test in pr64787 segfaults at run time.
(4) I get a new ICE for the following test (from pr51946):
module integrable_model_module
implicit none
type, abstract, public :: integrable_model
contains
procedure(default_constructor), deferred :: empty_instance
end type
abstract interface
function default_constructor(this) result(blank_slate)
import :: integrable_model
class(integrable_model), intent(in) :: this
class(integrable_model), allocatable :: blank_slate
end function
end interface
contains
subroutine integrate(this)
class(integrable_model), intent(inout) :: this
class(integrable_model), allocatable :: residual
allocate(residual, source=this%empty_instance())
end subroutine
end module integrable_model_module
pr51946.f90:23:0:
allocate(residual, source=this%empty_instance())
1
internal compiler error: in conv_function_val, at fortran/trans-expr.c:3462
(5) The tests in pr51208 comment 1 segfault at run time (IMO they are
invalid: SUM of unallocated arrays).
(6) The following variant of pr64125 now compiles (duplicate of pr63230)
module test
type t_string
private
character(len=:), allocatable :: chars
end type t_string
contains
pure subroutine string_assign_from_array( left, right )
! The target string
type(t_string), intent(out) :: left
! The source string
character, dimension(:), intent(in) :: right
! Copy memory
allocate( character(len=size(right)) :: left%chars )
left%chars = transfer( right, left%chars )
end subroutine string_assign_from_array
end module test
(7) The following variant of pr54070 gives an ICE (it compiles without the
patches, but segfaults at run time)
interface
function f(a)
character(len=*) :: a
character(len=:),allocatable :: f(:)
end function
end interface
character(len=10) :: tmp(2)
tmp = f('abc')
!print *, f('abc')
end
function f(a)
character(len=*) :: a
character(len=:),allocatable :: f(:)
allocate(f(2),source=a)
print *, a
! f = a
! print *, f
end function
pr54070_1_db_1.f90:14:0:
allocate(f(2),source=a)
1
internal compiler error: Segmentation fault: 11
pr54070_1_db_1.f90:14:0: internal compiler error: Abort trap: 6
(8) The following variant of pr55901 now compiles, but segfault at run time
class (*), allocatable :: a
type :: mytype
integer :: i
class(*), allocatable :: c
end type
type(mytype) :: b
allocate (a, source = "hello")
select type (a)
type is (character(*))
print *, a, len (a)
end select
if (allocated (a)) deallocate (a)
allocate (a, source = "goodbye")
select type (a)
type is (character(*))
print *, a, len (a)
end select
call foo (b%c, a)
select type (z => b%c)
type is (character(*))
print *, z, len (z)
z = "it is nice to meet you"
end select
select type (z => b%c)
type is (character(*))
print *, z, len (z)
end select
if (allocated (b%c)) deallocate (b%c)
allocate (b%c, source = "goodbye")
select type (z => b%c)
type is (character(*))
print *, z, len (z)
end select
if (allocated (b%c)) deallocate (b%c)
call foo (b%c, 42)
select type (z => b%c)
type is (INTEGER)
print *, z
end select
contains
subroutine foo (dest, src)
class (*), allocatable :: dest
class (*) :: src
allocate (dest, source = src)
end subroutine
end
I may have missed some other failure/success in my tests, but I think the
above is enough for now.
Thanks for working on this problem,
Dominique
Re: [PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads
On March 16, 2015 8:45:18 PM GMT+01:00, Jeff Law wrote:
>On 03/16/15 13:27, Jakub Jelinek wrote:
>> On Wed, Mar 11, 2015 at 03:30:36PM -0600, Jeff Law wrote:
>>> +#ifndef GCC_GCSE__COMMONH
>>> +#define GCC_GCSE__COMMONH
>>
>> GCC_GCSE_COMMON_H instead?
>:-) Will fix.
>
>>
>>> @@ -1308,8 +1396,19 @@ gcse_after_reload_main (rtx f
>ATTRIBUTE_UNUSED)
>>>
>>> if (expr_table->elements () > 0)
>>> {
>>> + /* Knowing which MEMs are transparent through a block can
>signifiantly
>>> +increase the number of reundant loads found. So compute
>transparency
>>> +information for for each memory expression in the hash table. */
>>
>> s/for for/for/ ?
>Similarly.
>
>
>>
>>> + df_analyze ();
>>> + /* This can not be part of the normal allocation routine
>because
>>> +we have to know the number of elements in the hash table. */
>>> + transp = sbitmap_vector_alloc (last_basic_block_for_fn
>(cfun),
>>> +expr_table->elements ());
>>> + bitmap_vector_ones (transp, last_basic_block_for_fn (cfun));
>>> + expr_table->traverse
>(dump_file);
>>> eliminate_partially_redundant_loads ();
>>> delete_redundant_insns ();
>>> + sbitmap_vector_free (transp);
>>>
>>> if (dump_file)
>>> {
>>
>> What effect does the patch have on compile time on say x86_64 or
>ppc64?
>I'll test both. In the common case, the cost is going to be the basic
>bookkeeping so that we can compute the transparent property. The
>actual
>computation of transparency and everything else is guarded on having
>something in the hash tables -- and the overwhelming majority of the
>time there's nothing in the hash tables.
>
>Regardless, I'll pin down boxes and do some testing.
>
>
>>
>> I'm slightly leaning towards trying it even in stage4, but if e.g.
>richi
>> disagrees, we could defer it to stage1 too.
>I'd be OK either way. I just want us to make a decision one way or the
If it fixes a regression then OK for trunk, otherwise please wait for stage 1
to open.
Richard.
>other :-)
>
>Jeff
Re: RFC: Avoid calling convert_to_mode with invalid rtl.
> What do you think of the attached patch ? Is it suitable for submission > once the sources are out of stage 4 ? (No regressions with an > x86_64-pc-linux-gnu toolchain and several fixes for an rl78-elf toolchain). Yes, I think it's appropriate for the next stage 1, bearing in mind that there is probably a small risk of pessimization on some targets (x32 comes to mind). -- Eric Botcazou
Re: [patch c++]: Fix for PR/65390
On 03/16/2015 03:22 PM, Kai Tietz wrote: 2015-03-16 19:07 GMT+01:00 Jason Merrill : If there is an alignment mismatch without user intervention, there is a problem, we can't just ignore it. Where we run into trouble is with array types where the version built earlier has not been laid out yet but the new one has been. I've been trying to deal with that by making sure that we lay out the original type as well, but obviously that isn't working for this case. Why not? Well, TYPE_ALIGN (t) is set to 32, and it differs to TYPE_ALIGN (result) (value 8), and TYPE_USER_ALIGN isn't set. I suppose we could avoid checking TYPE_ALIGN if neither TYPE_USER_ALIGN nor TYPE_SIZE are set on 't', but checking TYPE_USER_ALIGN isn't enough. For t TYPE_SIZE is set, but it isn't a constant (as it is an variably modified type). TYPE_ALIGN should still be correct in that case. So we need to figure out why result is getting the wrong alignment. Jason
Re: [patch c++]: Fix for PR/65390
2015-03-17 13:36 GMT+01:00 Jason Merrill : > On 03/16/2015 03:22 PM, Kai Tietz wrote: >> >> 2015-03-16 19:07 GMT+01:00 Jason Merrill : >>> >>> If there is an alignment mismatch without user intervention, there is a >>> problem, we can't just ignore it. >>> >>> Where we run into trouble is with array types where the version built >>> earlier has not been laid out yet but the new one has been. I've been >>> trying to deal with that by making sure that we lay out the original type >>> as >>> well, but obviously that isn't working for this case. Why not? >> >> >> Well, TYPE_ALIGN (t) is set to 32, and it differs to TYPE_ALIGN >> (result) (value 8), and TYPE_USER_ALIGN isn't set. >> >>> I suppose we could avoid checking TYPE_ALIGN if neither TYPE_USER_ALIGN >>> nor >>> TYPE_SIZE are set on 't', but checking TYPE_USER_ALIGN isn't enough. >> >> >> For t TYPE_SIZE is set, but it isn't a constant (as it is an variably >> modified type). > > > TYPE_ALIGN should still be correct in that case. So we need to figure out > why result is getting the wrong alignment. > > Jason > By debugging in build_cplus_array_type I see that type is marked as dependent. This is caused by type-max being an expression non-constant. So we later on don't layout this type. So result isn't a comlete layout type. by callling layout_type on result, alignment fits. Kai
[patch] Handle final classes in std::throw_with_nested()
Stephan Lavavej pointed out some flaws in our std::nested_exception,
most of which I fixed with the recent rewrite for GCC 5, but I didn't
check for final classes.
Tested x86_64-linux, committed to trunk.
commit 7202d181bc2aa72432ef472ace1a37bc841b51c5
Author: Jonathan Wakely
Date: Mon Mar 16 17:54:08 2015 +
* libsupc++/nested_exception.h: Do not try to derive from final
classes.
* testsuite/18_support/nested_exception/throw_with_nested.cc: Test
final class.
diff --git a/libstdc++-v3/libsupc++/nested_exception.h b/libstdc++-v3/libsupc++/nested_exception.h
index 7f7e14e..a716f75 100644
--- a/libstdc++-v3/libsupc++/nested_exception.h
+++ b/libstdc++-v3/libsupc++/nested_exception.h
@@ -108,7 +108,7 @@ namespace std
{ throw static_cast<_Up&&>(__t); }
};
- template
+ template
struct _Throw_with_nested_helper : _Throw_with_nested_impl<_Tp>
{ };
diff --git a/libstdc++-v3/testsuite/18_support/nested_exception/throw_with_nested.cc b/libstdc++-v3/testsuite/18_support/nested_exception/throw_with_nested.cc
index f1a0e9a..7ebf3b7 100644
--- a/libstdc++-v3/testsuite/18_support/nested_exception/throw_with_nested.cc
+++ b/libstdc++-v3/testsuite/18_support/nested_exception/throw_with_nested.cc
@@ -26,6 +26,8 @@ struct derived : std::nested_exception { };
struct not_derived { virtual ~not_derived() noexcept; };
inline not_derived::~not_derived() noexcept = default;
+struct uninheritable final { };
+
void test01()
{
bool test __attribute__((unused)) = false;
@@ -72,9 +74,29 @@ void test02()
VERIFY( test );
}
+void test03()
+{
+ bool test __attribute__((unused)) = false;
+
+ try
+ {
+std::throw_with_nested(uninheritable());
+ }
+ catch (const std::nested_exception&)
+ {
+VERIFY( false );
+ }
+ catch(const uninheritable&)
+ {
+test = true;
+ }
+ VERIFY( test );
+}
+
int main()
{
test01();
test02();
+ test03();
return 0;
}
Re: [patch] PR lto/65276 remove odr_violated assert
On 02/03/15 18:43, Aldy Hernandez wrote: TYPE_BINFO is null when no optimization is used, but odr_violated is unset. Fixed and approved in the PR by Honza. Tested on x86-64 Linux. Committed to mainline. Hi, I believe your testcase does not work for arm-none-eabi: Executing on host: /arm-none-eabi/obj/gcc2/gcc/testsuite/g++8/../../xg++ -B/arm-none-eabi/obj/gcc2/gcc/testsuite/g++8/../../ cp_lto_pr65276_0.o cp_lto_pr65276_1.o g++_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/include/arm-none-eabi -I/arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/include -I/src/gcc/libstdc++-v3/libsupc++ -I/src/gcc/libstdc++-v3/include/backward -I/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -O0 -std=c++11 -specs=rdimon.specs -Wa,-mno-warn-deprecated -L/arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs -B/arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -o g++-dg-lto-pr65276-01.exe(timeout = 300) spawn /arm-none-eabi/obj/gcc2/gcc/testsuite/g++8/../../xg++ -B/arm-none-eabi/obj/gcc2/gcc/testsuite/g++8/../../ cp_lto_pr65276_0.o cp_lto_pr65276_1.o g++_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/include/arm-none-eabi -I/arm-none-eabi/obj/gcc2/arm-none-eabi/libstdc++-v3/include -I/src/gcc/libstdc++-v3/libsupc++ -I/src/gcc/libstdc++-v3/include/backward -I/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -O0 -std=c++11 -specs=rdimon.specs -Wa,-mno-warn-deprecated -L/arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs -B/arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -o g++-dg-lto-pr65276-01.exe /tmp/61243907.0/ccwrV09Z.ltrans0.ltrans.o:(.rodata+0x0): multiple definition of `typeinfo for std::exception' /arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_exception.o):(.rodata._ZTISt9exception+0x0): first defined here /tmp/61243907.0/ccwrV09Z.ltrans0.ltrans.o:(.rodata+0x8): multiple definition of `typeinfo name for std::exception' /arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_exception.o):/src/gcc/libstdc++-v3/libsupc++/eh_exception.cc:35: first defined here collect2: error: ld returned 1 exit status compiler exited with status 1 output is: /tmp/61243907.0/ccwrV09Z.ltrans0.ltrans.o:(.rodata+0x0): multiple definition of `typeinfo for std::exception' /arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_exception.o):(.rodata._ZTISt9exception+0x0): first defined here /tmp/61243907.0/ccwrV09Z.ltrans0.ltrans.o:(.rodata+0x8): multiple definition of `typeinfo name for std::exception' /arm-none-eabi/obj/gcc2/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_exception.o):/src/gcc/libstdc++-v3/libsupc++/eh_exception.cc:35: first defined here collect2: error: ld returned 1 exit status FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11 UNRESOLVED: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o execute -flto -O0 -std=c++11 Kind regards, Alex
[patch] Remove duplicate libstdc++ tests
I noticed that testsuite/30_threads/shared_lock/modifiers/2.cc is
almost identical to 1.cc in the same directory, except for the diff
shown in the attached patch. That file was copied from
testsuite/30_threads/unique_lock/modifiers/2.cc which is almost
identical to 1.cc in that directory.
So I'm applying the attached patch to remove the unused variable name,
and deleting the duplicate tests.
Tested x86_64-linux, committed to trunk.
commit 0fbc10a08ea44dc6cf8c503b3e18899aecac0cc9
Author: Jonathan Wakely
Date: Tue Mar 17 16:24:41 2015 +
* testsuite/30_threads/shared_lock/modifiers/1.cc: Remove name of
unused exception variable.
* testsuite/30_threads/unique_lock/modifiers/1.cc: Likewise.
* testsuite/30_threads/shared_lock/modifiers/2.cc: Remove duplicate
test.
* testsuite/30_threads/unique_lock/modifiers/2.cc: Likewise.
diff --git a/libstdc++-v3/testsuite/30_threads/shared_lock/modifiers/1.cc b/libstdc++-v3/testsuite/30_threads/shared_lock/modifiers/1.cc
index 2d61582..9f20039 100644
--- a/libstdc++-v3/testsuite/30_threads/shared_lock/modifiers/1.cc
+++ b/libstdc++-v3/testsuite/30_threads/shared_lock/modifiers/1.cc
@@ -55,7 +55,7 @@ int main()
VERIFY( !(bool)l1 );
VERIFY( (bool)l2 );
}
- catch (const std::system_error& e)
+ catch (const std::system_error&)
{
VERIFY( false );
}
diff --git a/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/1.cc b/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/1.cc
index 917b0fb..ffb9fe4 100644
--- a/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/1.cc
+++ b/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/1.cc
@@ -55,7 +55,7 @@ int main()
VERIFY( !(bool)l1 );
VERIFY( (bool)l2 );
}
- catch (const std::system_error& e)
+ catch (const std::system_error&)
{
VERIFY( false );
}
[C++ Patch] PR 65340
Hi,
this minor [5 Regression], an ICE on invalid, seems just matter of
passing the tsubst_flags_t argument from build_over_call to mark_used
and then guarding require_deduced_type in the latter. Tested x86_64-linux.
Thanks,
Paolo.
/
2015-03-17 Paolo Carlini
PR c++/65340
* call.c (build_over_call): Pass the tsubst_flags_t argument to
mark_used.
* decl2.c (mark_used): Guard the require_deduced_type call with
complain & tf_error.
2015-03-17 Paolo Carlini
PR c++/65340
* g++.dg/cpp1y/pr65340.C: New.
Index: cp/call.c
===
--- cp/call.c (revision 221476)
+++ cp/call.c (working copy)
@@ -7486,7 +7486,7 @@ build_over_call (struct z_candidate *cand, int fla
}
if (!already_used
- && !mark_used (fn))
+ && !mark_used (fn, complain))
return error_mark_node;
if (DECL_VINDEX (fn) && (flags & LOOKUP_NONVIRTUAL) == 0
Index: cp/decl2.c
===
--- cp/decl2.c (revision 221476)
+++ cp/decl2.c (working copy)
@@ -5037,7 +5037,8 @@ mark_used (tree decl, tsubst_flags_t complain)
&& uses_template_parms (DECL_TI_ARGS (decl)))
return true;
- require_deduced_type (decl);
+ if (complain & tf_error)
+require_deduced_type (decl);
/* If we don't need a value, then we don't need to synthesize DECL. */
if (cp_unevaluated_operand != 0)
Index: testsuite/g++.dg/cpp1y/pr65340.C
===
--- testsuite/g++.dg/cpp1y/pr65340.C(revision 0)
+++ testsuite/g++.dg/cpp1y/pr65340.C(working copy)
@@ -0,0 +1,19 @@
+// PR c++/65340
+// { dg-do compile { target c++14 } }
+
+template Type constant;
+namespace reflect {
+namespace functors {
+ struct recurse { auto operator()(, ); }; // { dg-error "expected" }
+}
+ auto &recurse = constant < functors :: recurse > ;
+}
+namespace functors {
+struct traverse {
+ template
+ auto operator()(Algo, Value) -> decltype(reflect
+ :: recurse(0, 0));
+};
+}
+auto &traverse = constant < functors :: traverse > ;
+operator()()->decltype(traverse(0, 0)) // { dg-error "use of|expected" }
Re: [Patch, fortran] PR59198 - [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
On Tue, Mar 17, 2015 at 06:28:03AM +0100, Paul Richard Thomas wrote: > Dear Tobias, > > As far as I can see, without the patch, gfc_get _derived_type goes > into a continuous loop trying to build the abstract type. Why this is > not the case with an additional non-procedure pointer component, I do > not know. I suspect that there is a corner case out there that will > challenge this patch but I was unable to generate it. I decided > therefore to commit, with an additional condition in the loop to > prevent repeated attempts to build the component field. > > Committed to trunk as revision 221474. Note, the proc_ptr_comp_45.f90 testcase fails on i686-linux (unless -mfpmath=sse -msse2 or -ffloat-store) even at -O0, cos (1.570796327) is folded into constant and the runtime function doesn't return exactly the same result, because of extended precision. So, either you should allow a few ulps epsilon, or use some other function where you get reasonably exact result. Jakub
C++ PATCH for c++/65061 (using-declaration of template)
By the time we get to the lower have of cp_parser_template_name, we
don't need to keep the USING_DECL around, we can strip it away and just
deal with the underlying template.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0c6a93e343cbd6ce5c5c341b65eca721b58dae46
Author: Jason Merrill
Date: Mon Mar 16 09:40:04 2015 -0400
PR c++/65061
* parser.c (cp_parser_template_name): Call strip_using_decl.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a209ee6..a18f38c 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -14051,6 +14051,8 @@ cp_parser_template_name (cp_parser* parser,
/*ambiguous_decls=*/NULL,
token->location);
+ decl = strip_using_decl (decl);
+
/* If DECL is a template, then the name was a template-name. */
if (TREE_CODE (decl) == TEMPLATE_DECL)
{
diff --git a/gcc/testsuite/g++.dg/inherit/using8.C b/gcc/testsuite/g++.dg/inherit/using8.C
new file mode 100644
index 000..b7677c8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/inherit/using8.C
@@ -0,0 +1,15 @@
+// PR c++/65061
+
+struct B
+{
+ template
+ struct S {};
+};
+
+struct D : B
+{
+ using B::S;
+
+ template
+ void doIt(/*struct*/ S&);
+};
[PATCH] Add pre-reload splitter for low part SI/DImode extraction out of vector regs (PR target/65078)
Hi!
This patch fixes a regression where since the removal of specialized
builtin from _mm_storel_epi64 we force the extraction of DImode (or SImode)
low value out of 16/32/64 byte vector registers into memory.
As the vector extraction is from a vector register with a different
element mode, the expander doesn't know it might be beneficial to subreg it
to a vector mode with the same size, but different element mode and do
vector extraction out of that. This patch adds a pre-reload splitter that
will turn it into such a vector extraction. At least for the -m32
DImode extraction directly into memory, I think teaching RA to do that would
be much harder.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-03-17 Jakub Jelinek
PR target/65078
* config/i386/sse.md (movsi/movdi -> vec_extract_*_0 splitter): New.
* gcc.target/i386/pr65078-1.c: New test.
* gcc.target/i386/pr65078-2.c: New test.
* gcc.target/i386/pr65078-3.c: New test.
* gcc.target/i386/pr65078-4.c: New test.
* gcc.target/i386/pr65078-5.c: New test.
* gcc.target/i386/pr65078-6.c: New test.
--- gcc/config/i386/sse.md.jj 2015-01-23 20:52:13.0 +0100
+++ gcc/config/i386/sse.md 2015-03-17 15:57:31.274655235 +0100
@@ -12805,6 +12805,65 @@ (define_split
operands[1] = adjust_address (operands[1], mode, offs);
})
+;; Turn SImode or DImode extraction from arbitrary SSE/AVX/AVX512F
+;; vector modes into vec_extract*.
+(define_split
+ [(set (match_operand:SWI48x 0 "nonimmediate_operand")
+ (match_operand:SWI48x 1 "register_operand"))]
+ "can_create_pseudo_p ()
+ && GET_CODE (operands[1]) == SUBREG
+ && REG_P (SUBREG_REG (operands[1]))
+ && (GET_MODE_CLASS (GET_MODE (SUBREG_REG (operands[1]))) == MODE_VECTOR_INT
+ || (GET_MODE_CLASS (GET_MODE (SUBREG_REG (operands[1])))
+ == MODE_VECTOR_FLOAT))
+ && SUBREG_BYTE (operands[1]) == 0
+ && TARGET_SSE
+ && (GET_MODE_SIZE (GET_MODE (SUBREG_REG (operands[1]))) == 16
+ || (GET_MODE_SIZE (GET_MODE (SUBREG_REG (operands[1]))) == 32
+ && TARGET_AVX)
+ || (GET_MODE_SIZE (GET_MODE (SUBREG_REG (operands[1]))) == 64
+ && TARGET_AVX512F))
+ && (mode == SImode || TARGET_64BIT || MEM_P (operands[0]))"
+ [(set (match_dup 0) (vec_select:SWI48x (match_dup 1)
+(parallel [(const_int 0)])))]
+{
+ rtx tmp;
+ operands[1] = SUBREG_REG (operands[1]);
+ switch (GET_MODE_SIZE (GET_MODE (operands[1])))
+{
+case 64:
+ if (mode == SImode)
+ {
+ tmp = gen_reg_rtx (V8SImode);
+ emit_insn (gen_vec_extract_lo_v16si (tmp,
+ gen_lowpart (V16SImode,
+ operands[1])));
+ }
+ else
+ {
+ tmp = gen_reg_rtx (V4DImode);
+ emit_insn (gen_vec_extract_lo_v8di (tmp,
+ gen_lowpart (V8DImode,
+ operands[1])));
+ }
+ operands[1] = tmp;
+ /* FALLTHRU */
+case 32:
+ tmp = gen_reg_rtx (mode);
+ if (mode == SImode)
+ emit_insn (gen_vec_extract_lo_v8si (tmp, gen_lowpart (V8SImode,
+ operands[1])));
+ else
+ emit_insn (gen_vec_extract_lo_v4di (tmp, gen_lowpart (V4DImode,
+ operands[1])));
+ operands[1] = tmp;
+ break;
+case 16:
+ operands[1] = gen_lowpart (mode, operands[1]);
+ break;
+}
+})
+
(define_insn "*vec_concatv2si_sse4_1"
[(set (match_operand:V2SI 0 "register_operand" "=Yr,*x,x, Yr,*x,x, x,
*y,*y")
(vec_concat:V2SI
--- gcc/testsuite/gcc.target/i386/pr65078-1.c.jj2015-03-17
15:43:43.735200197 +0100
+++ gcc/testsuite/gcc.target/i386/pr65078-1.c 2015-03-17 16:08:17.022117378
+0100
@@ -0,0 +1,61 @@
+/* PR target/65078 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2" } */
+/* { dg-additional-options "-mregparm=2" { target ia32 } } */
+/* { dg-final { scan-assembler-not "\\(%\[er\]sp\\)" } } */
+
+typedef unsigned char V __attribute__((vector_size (16)));
+typedef unsigned long long W __attribute__((vector_size (16)));
+typedef unsigned int T __attribute__((vector_size (16)));
+
+void
+f1 (unsigned long long *x, V y)
+{
+ *x = ((W)y)[0];
+}
+
+#if defined(__x86_64__) || defined(ALL)
+unsigned long long
+f2 (V y)
+{
+ return ((W)y)[0];
+}
+#endif
+
+void
+f3 (unsigned int *x, V y)
+{
+ *x = ((T)y)[0];
+}
+
+unsigned int
+f4 (V y)
+{
+ return ((T)y)[0];
+}
+
+void
+f5 (unsigned long long *x, W y)
+{
+ *x = ((W)y)[0];
+}
+
+#if defined(__x86_64__) || defined(ALL)
+unsigned long long
+f6 (W y)
+{
+ return ((W)y)[0];
+}
+#endif
+
+void
+f7 (unsigned int *x, T y)
+{
+ *x = ((T)y)[0];
+}
+
+unsigned int
+f8 (T y)
+{
+ return ((T)y)[0];
+}
--- gcc/tes
Re: [PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads
On 03/17/2015 04:35 AM, Richard Biener wrote: I'll test both. In the common case, the cost is going to be the basic bookkeeping so that we can compute the transparent property. The actual computation of transparency and everything else is guarded on having something in the hash tables -- and the overwhelming majority of the time there's nothing in the hash tables. Regardless, I'll pin down boxes and do some testing. I'm slightly leaning towards trying it even in stage4, but if e.g. richi disagrees, we could defer it to stage1 too. I'd be OK either way. I just want us to make a decision one way or the If it fixes a regression then OK for trunk, otherwise please wait for stage 1 to open. It fixes 64317 which is a P2 regression. jeff
Re: [gofrontend-dev] GO tools for gccgo cross
On Tue, Mar 17, 2015 at 7:36 AM, wrote: > I have a patch to get gccgo to work on cross. > > Is it too late to try and get this into gcc 5.0? I think it's still possible. Depends on how small and safe it is. Ian > On Tuesday, February 3, 2015 at 2:18:39 PM UTC-6, Ian Lance Taylor wrote: >> >> On Tue, Feb 3, 2015 at 11:52 AM, Lynn A. Boger >> wrote: >> > >> > I've been experimenting with the go tools and how to make them work for >> > cross gccgo builds. >> > >> > In golang I think there is just one 'go' tool and the cross build >> > targets >> > are specified by the setting of GOARCH and GOOS. So why couldn't the >> > same >> > be done with gccgo? >> > >> > That means, on any given system, I think we just need to build the >> > native >> > gccgo and the go tools that are built with it. No need to build >> > different >> > go tools for each cross target. If a cross build is needed, then set >> > the >> > GOARCH and GOOS values appropriately and invoke the native go (for >> > gccgo) >> > tool. Source changes are needed for the go tool source to determine the >> > correct cross compiler name based on the GOARCH and GOOS settings, and >> > then >> > use that cross compiler where needed for building or linking instead of >> > always using "gccgo". I was able to make these changes and get this to >> > work >> > -- I built gccgo programs targeted for ppc64le on an x86_64. >> >> I agree that setting GOARCH and GOOS should change the default name of >> the gccgo compiler that the go tool uses. >> >> Ian > > -- > You received this message because you are subscribed to the Google Groups > "gofrontend-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to gofrontend-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Run DCE after if conversion
On 03/17/2015 02:17 AM, Andreas Krebbel wrote: Just to have some numbers I did run a -j1 GCC bootstrap twice with and without the patch on x86_64. Best results for both are: clean: 21459s patched: 21314s There rather appears to be a trend towards reduced compile time perhaps due to the reduced number of INSNs to be processed in the RTL passes between the two ifcvt runs (loop optimization, combine, fwprop, dse,...)?! I also tried to measure the testsuite runs but the results show a big variance. So what I have right now does not qualify as a benchmark. And reality is it's getting harder and harder to benchmark this kind of thing with turbo modes and such.A single run isn't sufficient unless you've locked the box into a particular cpu frequency. jeff
Re: [PATCH][expmed] Calculate mult-by-const cost properly in mult_by_coeff_cost
On 03/16/2015 04:12 AM, Kyrill Tkachov wrote: Hi all, Eyeballing the mult_by_coeff_cost function I think it has a typo/bug. It's supposed to return the cost of multiplying by a constant 'coeff'. It calculates that by taking the cost of a MULT rtx by that constant and comparing it to the cost of synthesizing that multiplication, and returning the cheapest. However, in the MULT rtx cost calculations it creates a MULT rtx of two REGs rather than the a REG and the GEN_INT of coeff as I would expect. This patches fixes that in the obvious way. Tested aarch64-none-elf and bootstrapped on x86_64-linux-gnu. I'm guessing this is stage 1 material at this point? Thanks, Kyrill 2015-03-13 Kyrylo Tkachov * expmed.c (mult_by_coeff_cost): Pass CONT_INT rtx to MULT cost calculation rather than fake_reg. I'd think stage1, unless you can point to a bug, particularly a regression. Jeff
Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386
On 03/15/2015 02:30 PM, Richard Sandiford wrote: Ilya Enkovich writes: This patch allows propagation of loop invariants for i386 if propagated value is a constant to be used in address operand. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk or stage 1? Is it necessary for this to be a target hook? The concept doesn't seem particularly target-specific. We should only propagate into the address if the new cost is no greater than the old cost, but if the address meets that condition and if propagating at this point in the pipeline is a win on x86, then wouldn't it be a win for other targets too? Agreed. And unless this is a regression, it should be queued for stage1. jeff
Re: Fix for PRs 36043, 58744 and 65408
On 03/14/2015 07:02 AM, Alan Modra wrote: This is Richi's prototype patch in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043#c23 with fixes for blocks larger than one reg, big-endian, and BLOCK_REG_PADDING. I also removed the operand_subword_force since we may as well let narrow_bit_field_mem in extract_bit_field do that for us. It is necessary to do the BLOCK_REG_PADDING shift after we've loaded the block or else repeat the bit-field extraction in that case. Bootstrapped and regression tested (-m32 and -m64) x86_64-linux and powerpc64-linux. OK to apply? I'll also throw together a testcase or three. For execute tests I'm thinking of using sbrk to locate an odd sized struct such that access past the end segfaults, rather than mmap/munmap as was done in the pr36043 testcase. Does that sound reasonable? PR target/65408 PR target/58744 PR middle-end/36043 * calls.c (load_register_parameters): Don't load past end of mem unless suitably aligned. I think this is probably a stage1 item. Richi, Jakub, Joseph, do any of you think we should try to push this into gcc-5? jeff
Re: [C PATCH] Fix up file-scope _Atomic expansion (PR c/65345)
On 03/12/2015 11:37 AM, Marek Polacek wrote:
The PR shows that the compiler ICEs whenever it tries to expand an atomic
operation at the file scope. That happens because it creates temporaries
via create_tmp_var, which also pushes the variable into the current binding,
but that can't work if current_function_decl is NULL. The fix is I think to
only generate the temporaries during gimplification. Turned out that the
TARGET_EXPRs are tailor-made for this, so I've used them along with changing
create_tmp_var calls to create_tmp_var_raw that does not push the variable
into the current binding.
But this wasn't enough to handle the following case:
_Atomic int i = 5;
void f (int a[i += 1]) {}
To make it work I had to tweak the artificial labels that build_atomic_assign
creates to not ICE in gimplification. The comment in store_parm_decls sums
it up. It uses walk_tree, but I think this will be only rarely exercised in
practice, if ever; I think programs using such a construction are thin on the
ground.
I tried comparing .gimple dumps with/without the patch on
_Atomic int q = 4;
void
f (void)
{
q += 2;
}
and I see no code changes.
This is not a regression, so not sure if I shouldn't defer this patch to the
next stage1 at this juncture...
Comments?
Bootstrapped/regtested on x86_64-linux.
2015-03-12 Marek Polacek
PR c/65345
* c-decl.c (set_labels_context_r): New function.
(store_parm_decls): Call it via walk_tree_without_duplicates.
* c-typeck.c (convert_lvalue_to_rvalue): Use create_tmp_var_raw
instead of create_tmp_var. Build TARGET_EXPR instead of
COMPOUND_EXPR.
(build_atomic_assign): Use create_tmp_var_raw instead of
create_tmp_var. Build TARGET_EXPRs instead of MODIFY_EXPR.
* gcc.dg/pr65345-1.c: New test.
* gcc.dg/pr65345-2.c: New test.
My inclination is to defer unless it's painfully safe (like your removal
of unused functions) or it's a regression of some sorts.
jeff
Re: [PATCH] Make split_block and create_basic_block type-safe
On 03/12/2015 07:20 AM, Richard Biener wrote: After noticing tree-parloop.c passing crap to split_block (a tree rather than a gimple or an rtx) I noticed those CFG functions simply take void * pointers. The following patch fixes that and adds two overloads, one for GIMPLE use and one for RTL use. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Ok at this stage? Thanks, Richard. 2015-03-12 Richard Biener * cfghooks.h (create_basic_block): Replace with two overloads for RTL and GIMPLE. (split_block): Likewise. * cfghooks.c (split_block): Rename to ... (split_block_1): ... this. (split_block): Add two type-safe overloads for RTL and GIMPLE. (split_block_after_labels): Call split_block_1. (create_basic_block): Rename to ... (create_basic_block_1): ... this. (create_basic_block): Add two type-safe overloads for RTL and GIMPLE. (create_empty_bb): Call create_basic_block_1. * cfgrtl.c (fixup_fallthru_exit_predecessor): Use split_block_after_labels. * omp-low.c (expand_parallel_call): Likewise. (expand_omp_target): Likewise. (simd_clone_adjust): Likewise. * tree-chkp.c (chkp_get_entry_block): Likewise. * cgraphunit.c (init_lowered_empty_function): Use the GIMPLE create_basic_block overload. (cgraph_node::expand_thunk): Likewise. * tree-cfg.c (make_blocks): Likewise. (handle_abnormal_edges): Likewise. * tree-inline.c (copy_bb): Likewise. Seems reasonable since it's very low risk and removes a difficult to reproduce & diagnose compile-time issue. But ultimately I think it's the release managers' call here. Jeff
[debug-early] equate new DIE with DW_AT_specificationto a previous declaration
Hi Jason.
I merged mainline into the debug-early branch and I ran into a problem
compiling a libstdc++ file with -fno-implicit-templates. The attached
patch is what I used to solve the problem but I wanted to run it by you,
to make sure I'm not overlooking something silly, or worse...something
much more complicated.
The reduced testcase is the following, compiled with
-fno-implicit-templates -g -O2 -std=gnu++11:
class Object
{
public:
void Method();
};
void funky()
{
Object foobar;
foobar.Method();
}
template
void
Object::Method()
{
}
In mainline, we call gen_subprogram_die() twice for
Object::Method(): once, while generating class members, and once
while inlining (outlining_inline_function hook). The debug-early path
is somewhat different, and we end up calling gen_subprogram_die() three
times, the last of which ICEs. What happens is the following...
We call gen_subprogram_die() as usual while generating class members,
but then we call it again by virtue of it being a reachable function.
This extra call will follow the DW_AT_specification code path because we
have a previously cached die:
subr_die = new_die (DW_TAG_subprogram, context_die, decl);
add_AT_specification (subr_die, old_die);
add_pubname (decl, subr_die);
The problem is that, for -fno-implicit-templates, the decl is now
DECL_EXTERNAL, which means we never equate this new "DIE with
DW_AT_specification" to the DECL. That is, we never fall through here:
else if (!DECL_EXTERNAL (decl))
{
HOST_WIDE_INT cfa_fb_offset;
struct function *fun = DECL_STRUCT_FUNCTION (decl);
if (!old_die || !get_AT (old_die, DW_AT_inline))
equate_decl_number_to_die (decl, subr_die);
However, when we call gen_subprogram_die() the third time through the
outlining_inline_function hook (late debug), we again try to add a
DW_AT_specification to the DIE cached from the first time around, but
this time we ICE because we're not supposed to have multiple
DW_AT_specification's pointing to the same DIE (the old original DIE).
My solution is just to call equate_decl_number_to_die() as soon as we
create the DW_AT_specification marked DIE the second time around. The
third time we will just pick up this last cached DIE with
DW_AT_specification, mark it as DW_AT_inline, and voila, everything
works. The dwarf generation is as mainline, and we can build libstdc++
with no regressions to the guality testsuite.
Does this sound reasonable, or is this something a lot more complicated?
Thanks.
Aldy
commit 0a49042b9151e0387efc5f87c32cb24968896ae4
Author: Aldy Hernandez
Date: Tue Mar 17 12:29:27 2015 -0700
Equate new DIE containing a DW_AT_specification, to the original
declaration.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 86815be..c7345d9 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -18809,6 +18809,8 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
TYPE_UNQUALIFIED, context_die);
}
+ if (early_dwarf_dumping)
+ equate_decl_number_to_die (decl, subr_die);
}
}
/* Anything else... create a brand new DIE. */
Re: [C PATCH] Fix up file-scope _Atomic expansion (PR c/65345)
On Tue, Mar 17, 2015 at 01:32:20PM -0600, Jeff Law wrote: > My inclination is to defer unless it's painfully safe (like your removal of > unused functions) or it's a regression of some sorts. I think I also slightly prefer deferring this patch; it's not exactly in the "painfully safe" category. Marek
Re: [Patch, fortran] PR59198 - [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
Oh bother! Thanks Jakub - I did wonder about that but thought that the same function would yield the same result :-( Thanks. I will put it right. Paul On 17 March 2015 at 18:32, Jakub Jelinek wrote: > On Tue, Mar 17, 2015 at 06:28:03AM +0100, Paul Richard Thomas wrote: >> Dear Tobias, >> >> As far as I can see, without the patch, gfc_get _derived_type goes >> into a continuous loop trying to build the abstract type. Why this is >> not the case with an additional non-procedure pointer component, I do >> not know. I suspect that there is a corner case out there that will >> challenge this patch but I was unable to generate it. I decided >> therefore to commit, with an additional condition in the loop to >> prevent repeated attempts to build the component field. >> >> Committed to trunk as revision 221474. > > Note, the proc_ptr_comp_45.f90 testcase fails on i686-linux (unless > -mfpmath=sse -msse2 > or -ffloat-store) even at -O0, cos (1.570796327) is folded into constant and > the runtime > function doesn't return exactly the same result, because of extended > precision. > So, either you should allow a few ulps epsilon, or use some other function > where you get reasonably exact result. > > Jakub -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
[wwwdocs] Update my association in steering committee list
I have checked in this change. Validated as XHTML 1.0 Transitional. Jim Index: htdocs/steering.html === RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v retrieving revision 1.39 diff -r1.39 steering.html 41c41 < Jim Wilson (Cisco) --- > Jim Wilson (Linaro)
Re: [PATCH] pr 63354 - gcc -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
Hi Martin, Sorry for the late answer... On Sun, Mar 15, 2015 at 05:39:59PM -0600, Martin Sebor wrote: > I tested the changes in powerpc64*-linux-* native builds and on > an x86_64 host in a build for the powerpc-unknown-linux-gnu and > powerpc64-apple-darwin targets. Of these, the -mprofile-kernel > option is only accepted for powerpc64*-linux-* (which was also > confirmed by inspecting the sources) so I adjusted the test > target accordingly and kept the body of > rs6000_keep_leaf_when_profiled you suggested. That looks fine to me for stage 1. The comment could use some updating though ;-) Segher
[debug-early] allow DW_TAG_type_unit's in limbo
Twiddle the assert. A DW_TAG_type_unit in limbo can happen under normal circumstances while breaking out comdat types. Found while running the gdb testsuite. Committed to branch. Aldy commit 1c2137a25b7ffa2ab71fe4d534ab149624c5c841 Author: Aldy Hernandez Date: Tue Mar 17 16:50:14 2015 -0700 Allow DW_TAG_type_unit's in limbo. They can happen in late debug while breaking out comdat types. diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index c7345d9..30c6cc6 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -4943,6 +4943,7 @@ new_die (enum dwarf_tag tag_value, dw_die_ref parent_die, tree t) because the limbo list should not persist past LTO streaming. */ if (tag_value != DW_TAG_compile_unit + && tag_value != DW_TAG_type_unit && !early_dwarf_dumping /* Allow nested functions to live in limbo because they will only temporarily live there, as decls_for_scope will fix
Re: [PATCH] Disable all target libraries if not building gcc
On Mon, Mar 16, 2015 at 8:01 PM, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 7:26 PM, H.J. Lu wrote:
>> On Mon, Mar 16, 2015 at 4:43 PM, H.J. Lu wrote:
>>> On Mon, Mar 16, 2015 at 4:41 PM, Joseph Myers
>>> wrote:
On Mon, 16 Mar 2015, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 3:50 PM, Joseph Myers
> wrote:
> > On Fri, 13 Mar 2015, H.J. Lu wrote:
> >
> >> I am working on SHF_COMPRESSED support:
> >>
> >> http://www.sco.com/developers/gabi/latest/ch4.sheader.html
> >>
> >> I will import zlib from GCC source tree into binutils-gdb tree. But
> >> zlib
> >> failed to build as a target library in binutils-gdb. There is no need
> >> to
> >> build target libraries if not building gcc. OK for master?
> >
> > This is definitely wrong. newlib / libgloss is a target library that
> > certainly makes sense to build separately from GCC, and the toplevel
> > configure / build code should be identical in all three repositories
> > (GCC,
> > binutils-gdb, newlib-cygwin).
>
> We need to work out something to avoid building target libraries
> in binutils.
I suggest not building zlib as a target library unless libgcj is also
being built as a target library, given that there should be no need to
built it as a target library in isolation.
>>>
>>> The logic is there. But somehow it doesn't work for binutils.
>>> I will take another look.
>>>
>>
>> Here is a patch. It excludes target-zlib if target-libjava isn't built.
>> Tested in binutils and GCC with java.
>>
>
> This version is more flexible to support future target libraries
> which depend on target zlib.
>
I reverted my previous commit and checked in this one.
--
H.J.
From 54564569062ee2cc7690aa96323c0dc5622efeef Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 17 Mar 2015 17:05:38 -0700
Subject: [PATCH] Exclude target-zlib if target-libjava isn't built
* configure.ac (target_configdirs): Exclude target-zlib if
target-libjava isn't built.
* configure: Regenerated.
---
ChangeLog| 6 ++
configure| 12 +---
configure.ac | 12 +---
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f018cc4..9b1895b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2015-03-17 H.J. Lu
+ * configure.ac (target_configdirs): Exclude target-zlib if
+ target-libjava isn't built.
+ * configure: Regenerated.
+
+2015-03-17 H.J. Lu
+
Sync with GCC
2014-06-13 Thomas Schwinge
diff --git a/configure b/configure
index 9e54319..b719d38 100755
--- a/configure
+++ b/configure
@@ -6432,9 +6432,6 @@ Supported languages are: ${potential_languages}" "$LINENO" 5
ac_configure_args=`echo " $ac_configure_args" | sed -e "s/ '--enable-languages=[^ ]*'//g" -e "s/$/ '--enable-languages="$enable_languages"'/" `
-else
- # Disable all target libraries if not building gcc.
- target_configdirs=
fi
# Handle --disable- generically.
@@ -6554,6 +6551,15 @@ for i in ${target_configdirs_all} ; do
fi
done
+# Exclude target-zlib if target-libjava isn't built.
+case ${target_configdirs} in
+*target-libjava*)
+ ;;
+*)
+ target_configdirs="`echo ${target_configdirs} | sed -e 's/target-zlib//'`"
+ ;;
+esac
+
# libiberty-linker-plugin is special: it doesn't have its own source directory,
# so we have to add it after the preceding checks.
if test x"$extra_linker_plugin_flags$extra_linker_plugin_configure_flags" != x
diff --git a/configure.ac b/configure.ac
index eaf4661..a4e4c7d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2129,9 +2129,6 @@ Supported languages are: ${potential_languages}])
AC_SUBST(stage1_languages)
ac_configure_args=`echo " $ac_configure_args" | sed -e "s/ '--enable-languages=[[^ ]]*'//g" -e "s/$/ '--enable-languages="$enable_languages"'/" `
-else
- # Disable all target libraries if not building gcc.
- target_configdirs=
fi
# Handle --disable- generically.
@@ -2251,6 +2248,15 @@ for i in ${target_configdirs_all} ; do
fi
done
+# Exclude target-zlib if target-libjava isn't built.
+case ${target_configdirs} in
+*target-libjava*)
+ ;;
+*)
+ target_configdirs="`echo ${target_configdirs} | sed -e 's/target-zlib//'`"
+ ;;
+esac
+
# libiberty-linker-plugin is special: it doesn't have its own source directory,
# so we have to add it after the preceding checks.
if test x"$extra_linker_plugin_flags$extra_linker_plugin_configure_flags" != x
--
2.1.0
Re: [C++ Patch] PR 65340
On 03/17/2015 01:09 PM, Paolo Carlini wrote: - require_deduced_type (decl); + if (complain & tf_error) +require_deduced_type (decl); I think we want to return false if there's a problem here so that we don't just silently accept this in SFINAE context. So probably we want to replace the call with an inlined form like earlier in mark_used. Are there other places that still need to pass complain to mark_used? Jason
Re: [C++ Patch] PR 65340
Hi,
On 03/18/2015 01:11 AM, Jason Merrill wrote:
On 03/17/2015 01:09 PM, Paolo Carlini wrote:
- require_deduced_type (decl);
+ if (complain & tf_error)
+require_deduced_type (decl);
I think we want to return false if there's a problem here so that we
don't just silently accept this in SFINAE context. So probably we
want to replace the call with an inlined form like earlier in mark_used.
Indeed, I was a bit nervous about that, should have asked... Anyway, the
below is finishing testing.
Are there other places that still need to pass complain to mark_used?
Well, if we are talking about functions getting a tsubst_flags_t and
*not* passing it down to mark_used, there are quite a few - see
attached. I didn't feel like raising the issue at this time because in
all those cases, at variance with the specific case we are changing for
the bug, the return value of mark_used is *not* checked, thus is we
suppress the errors in SFINAE context we would like to also add a check
and return early, but in general, doing that when we are *outside*
SFINAE changes what happens during error recovery, thus it seems a bit
risky fiddling with those right now...
Thanks,
Paolo.
/
Index: cp/call.c
===
--- cp/call.c (revision 221481)
+++ cp/call.c (working copy)
@@ -7486,7 +7486,7 @@ build_over_call (struct z_candidate *cand, int fla
}
if (!already_used
- && !mark_used (fn))
+ && !mark_used (fn, complain))
return error_mark_node;
if (DECL_VINDEX (fn) && (flags & LOOKUP_NONVIRTUAL) == 0
Index: cp/decl2.c
===
--- cp/decl2.c (revision 221481)
+++ cp/decl2.c (working copy)
@@ -5037,7 +5037,12 @@ mark_used (tree decl, tsubst_flags_t complain)
&& uses_template_parms (DECL_TI_ARGS (decl)))
return true;
- require_deduced_type (decl);
+ if (undeduced_auto_decl (decl))
+{
+ if (complain & tf_error)
+ error ("use of %qD before deduction of %", decl);
+ return false;
+}
/* If we don't need a value, then we don't need to synthesize DECL. */
if (cp_unevaluated_operand != 0)
Index: testsuite/g++.dg/cpp1y/pr65340.C
===
--- testsuite/g++.dg/cpp1y/pr65340.C(revision 0)
+++ testsuite/g++.dg/cpp1y/pr65340.C(working copy)
@@ -0,0 +1,19 @@
+// PR c++/65340
+// { dg-do compile { target c++14 } }
+
+template Type constant;
+namespace reflect {
+namespace functors {
+ struct recurse { auto operator()(, ); }; // { dg-error "expected" }
+}
+ auto &recurse = constant < functors :: recurse > ;
+}
+namespace functors {
+struct traverse {
+ template
+ auto operator()(Algo, Value) -> decltype(reflect
+ :: recurse(0, 0)); // { dg-error
"use of" }
+};
+}
+auto &traverse = constant < functors :: traverse > ;
+operator()()->decltype(traverse(0, 0)) // { dg-error "no match|expected" }
Index: cp/call.c
===
--- cp/call.c (revision 221481)
+++ cp/call.c (working copy)
@@ -5968,7 +5968,7 @@ build_op_delete_call (enum tree_code code, tree ad
argarray[0] = addr;
for (i = 1; i < nargs; i++)
argarray[i] = CALL_EXPR_ARG (placement, i);
- mark_used (fn);
+ mark_used (fn, complain);
return build_cxx_call (fn, nargs, argarray, complain);
}
else
@@ -7390,7 +7390,7 @@ build_over_call (struct z_candidate *cand, int fla
the implementation elided its use. */
if (!trivial || DECL_DELETED_FN (fn))
{
- mark_used (fn);
+ mark_used (fn, complain);
already_used = true;
}
Index: cp/class.c
===
--- cp/class.c (revision 221481)
+++ cp/class.c (working copy)
@@ -7651,8 +7651,8 @@ resolve_address_of_overloaded_function (tree targe
/* Make =delete work with SFINAE. */
if (DECL_DELETED_FN (fn) && !(flags & tf_error))
return error_mark_node;
-
- mark_used (fn);
+
+ mark_used (fn, flags);
}
/* We could not check access to member functions when this
Index: cp/decl.c
===
--- cp/decl.c (revision 221481)
+++ cp/decl.c (working copy)
@@ -14594,7 +14594,7 @@ cxx_maybe_build_cleanup (tree decl, tsubst_flags_t
ordinary FUNCTION_DECL. */
fn = lookup_name (id);
arg = build_address (decl);
- mark_used (decl);
+ mark_used (decl, complain);
cleanup = cp_build_function_call_nary (fn, complain, arg, NULL_TREE);
if (cleanup == error_mark_node)
return error_mark_node;
@@ -14637,7 +14637,7 @@ cxx_maybe_build_cleanup (tree decl, tsubst_flags_t
&& !lookup_attribute ("warn_unused", TYPE_ATTRIBUTES (TREE_TYPE (decl
Re: [debug-early] equate new DIE with DW_AT_specificationto a previous declaration
On 03/17/2015 03:58 PM, Aldy Hernandez wrote:
The problem is that, for -fno-implicit-templates, the decl is now
DECL_EXTERNAL, which means we never equate this new "DIE with
DW_AT_specification" to the DECL. That is, we never fall through here:
else if (!DECL_EXTERNAL (decl))
{
HOST_WIDE_INT cfa_fb_offset;
struct function *fun = DECL_STRUCT_FUNCTION (decl);
if (!old_die || !get_AT (old_die, DW_AT_inline))
equate_decl_number_to_die (decl, subr_die);
However, when we call gen_subprogram_die() the third time through the
outlining_inline_function hook (late debug), we again try to add a
DW_AT_specification to the DIE cached from the first time around, but
this time we ICE because we're not supposed to have multiple
DW_AT_specification's pointing to the same DIE (the old original DIE).
Why are we outlining a DECL_EXTERNAL function?
Incidentally,
/* If we have no location information, this must be a
partially generated DIE from early dwarf generation.
Fall through and generate it. */
Why aren't we checking dumped_early here?
Jason
Re: [C++ Patch] PR 65340
On 03/17/2015 10:03 PM, Paolo Carlini wrote: Hi, On 03/18/2015 01:11 AM, Jason Merrill wrote: On 03/17/2015 01:09 PM, Paolo Carlini wrote: - require_deduced_type (decl); + if (complain & tf_error) +require_deduced_type (decl); I think we want to return false if there's a problem here so that we don't just silently accept this in SFINAE context. So probably we want to replace the call with an inlined form like earlier in mark_used. Indeed, I was a bit nervous about that, should have asked... Anyway, the below is finishing testing. OK. Are there other places that still need to pass complain to mark_used? Well, if we are talking about functions getting a tsubst_flags_t and *not* passing it down to mark_used, there are quite a few - see attached. I didn't feel like raising the issue at this time because in all those cases, at variance with the specific case we are changing for the bug, the return value of mark_used is *not* checked, thus is we suppress the errors in SFINAE context we would like to also add a check and return early, but in general, doing that when we are *outside* SFINAE changes what happens during error recovery, thus it seems a bit risky fiddling with those right now... Agreed, let's defer this until stage 1. Jason
Re: Fix for PRs 36043, 58744 and 65408
On Tue, Mar 17, 2015 at 01:28:41PM -0600, Jeff Law wrote: > On 03/14/2015 07:02 AM, Alan Modra wrote: > > PR target/65408 > > PR target/58744 > > PR middle-end/36043 > > * calls.c (load_register_parameters): Don't load past end of > > mem unless suitably aligned. > I think this is probably a stage1 item. Richi, Jakub, Joseph, do any of you > think we should try to push this into gcc-5? Some (severity) background to PR65408. The bug came from SAP HANA (en.wikipedia.org/wiki/SAP_HANA), a crash that happens on powerpc64 and powerpc64le. aarch64 would also be susceptible to the crash since it also loads 16 bytes for the 12-byte struct. x86_64 only loads 12 bytes (i386.c:construct_container generates a parallel with a DImode and SImode load). However the underlying bug is there and hits x86_64 too for the pr58744 and pr36043 testcases.. -- Alan Modra Australia Development Lab, IBM
Re: [PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads
On Tue, Mar 17, 2015 at 11:27 AM, Jeff Law wrote: > On 03/17/2015 04:35 AM, Richard Biener wrote: > >>> I'll test both. In the common case, the cost is going to be the basic >>> bookkeeping so that we can compute the transparent property. The >>> actual >>> computation of transparency and everything else is guarded on having >>> something in the hash tables -- and the overwhelming majority of the >>> time there's nothing in the hash tables. >>> >>> Regardless, I'll pin down boxes and do some testing. >>> >>> I'm slightly leaning towards trying it even in stage4, but if e.g. >>> >>> richi disagrees, we could defer it to stage1 too. >>> >>> I'd be OK either way. I just want us to make a decision one way or the >> >> >> If it fixes a regression then OK for trunk, otherwise please wait for >> stage 1 to open. > > It fixes 64317 which is a P2 regression. I had a pass which I inherited from my predecessor which was basically doing the same as your patch: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/postreload-load.c;h=2652e51f8eca310d51db3a30e5f6c8847be436ce;hb=refs/heads/apinski/thunderx-cost But I like your patch much better than this one. I saw many loads being removed for AARCH64 also at -Ofast -funroll-loops on SPEC 2006 with this pass. But it seemed to due to subregs which I had mentioned at https://gcc.gnu.org/ml/gcc/2015-01/msg00125.html . When I get a chance I can test your patch out on AARCH64 and disable "my" pass to see if "my" pass catches more than your patch. Thanks, Andrew > > jeff >
