[Bug c++/58597] [c++11] ICE with lambda in default argument of template function

2015-01-14 Thread reichelt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58597

--- Comment #4 from Volker Reichelt  ---
The ICE disappered on the 4.9 branch in GCC 4.9.2.
But the testcase still crashes trunk with a different stack trace:


bug.cc:6:12: internal compiler error: Segmentation fault
 A a = 0;
^
0xcdc42f crash_signal
../../gcc/gcc/toplev.c:372
0x6943ae tsubst_default_argument(tree_node*, tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:10496
0x629f9f convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:6774
0x62a91d build_over_call
../../gcc/gcc/cp/call.c:7301
0x62f9b4 convert_like_real
../../gcc/gcc/cp/call.c:6253
0x62f799 convert_like_real
../../gcc/gcc/cp/call.c:6384
0x6395d7 build_user_type_conversion(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:3831
0x78897e ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:875
0x7969f5 expand_default_init
../../gcc/gcc/cp/init.c:1661
0x7969f5 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1830
0x7971e4 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1582
0x66cddc build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:5780
0x66cddc check_initializer
../../gcc/gcc/cp/decl.c:5924
0x66e79c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6607
0x756539 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17290
0x758185 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11600
0x7585b3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11474
0x760689 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11371
0x76098a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11257
0x760cc7 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4108
Please submit a full bug report, [etc.]


[Bug fortran/64591] ICE on use association of renamed extended type

2015-01-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64591

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-14
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8.4 up to trunk (5.0).


[Bug fortran/64589] Linking error due to undefined integer symbol with unlimited polymorphism

2015-01-14 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64589

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-14
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. I get an ICE on this variant:


module m
contains
  subroutine fmt()
class(*), pointer :: arg
select type (arg)
type is (integer)
end select
  end subroutine
end module

program p
contains
  subroutine makeString(arg1)
class(*) :: arg1
  end subroutine 
  subroutine getSuffix()
use m
call makeString(1)
  end subroutine
end



 program p
 1
internal compiler error: in build_function_decl, bei fortran/trans-decl.c:1985
0x694062 build_function_decl
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:1982
0x69ac6e gfc_get_symbol_decl(gfc_symbol*)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:1469
0x6aba97 gfc_conv_variable
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:2008
0x6a7f22 gfc_conv_expr(gfc_se*, gfc_expr*)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6617
0x6aa56a gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:5990
0x6aa85c gfc_conv_structure(gfc_se*, gfc_expr*, int)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6508
0x6aa672 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6005
0x69a9c0 gfc_get_symbol_decl(gfc_symbol*)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:1603
0x6ad21e gfc_conv_intrinsic_to_class(gfc_se*, gfc_expr*, gfc_typespec)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:581
0x6a4431 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:4273
0x6d476e gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-stmt.c:419
0x67cdae trans_code
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:1728
0x69da5f gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5807
0x69dd57 gfc_generate_contained_functions
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:4946
0x69dd57 gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5738
0x639eb0 translate_all_program_units
/home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:4947
0x639eb0 gfc_parse_file()
/home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5144
0x678ba5 gfc_be_parse_file
/home/jweil/gcc/gcc50/trunk/gcc/fortran/f95-lang.c:228


[Bug ipa/64545] failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693

2015-01-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545

--- Comment #4 from Markus Trippelsdorf  ---
1653   int old_hints_est = estimate_edge_hints (edge); 

old_hints_est = 288 
estimate_edge_hints (edge) = 32


[Bug ipa/64545] failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693

2015-01-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545

--- Comment #5 from Markus Trippelsdorf  ---
1660   gcc_assert (old_hints_est == estimate_edge_hints (edge));


[Bug ipa/64545] failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693

2015-01-14 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545

--- Comment #6 from Jan Hubicka  ---
Hmm, that is same_scc hint. It would be great to have smaller testcase. I will
look into that tomorrow morning.

Honza


[Bug fortran/64591] [4.8/4.9/5 Regression] ICE on use association of renamed extended type

2015-01-14 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64591

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org
Summary|ICE on use association of   |[4.8/4.9/5 Regression] ICE
   |renamed extended type   |on use association of
   ||renamed extended type

--- Comment #2 from janus at gcc dot gnu.org ---
I see the ICE with 4.6 to trunk, but not with 4.4.7, so it's a regression.


[Bug tree-optimization/64590] Firefox 34 triggers GCC AVX bug (segfault: XPCCallContext::GetJSContext (this=0xfffc7fffe3e23980))

2015-01-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64590

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
That most likely means a failed assertion implemented on the mozilla side as
store to NULL pointer followed to __builtin_trap () just in case.
Anyway, that doesn't look like a reason for the -march=nehalem vs.
-march=sandybridge differences.  If that really turns a working binary into
non-working, perhaps try to bisect between -march=nehalem -O3 and
-march=sandybridge -O3 (forget about -floop-interchange -floop-strip-mine
-floop-block everywhere) built *.o files, until you find the problematic one. 
Then using __attribute__((target ("march=sandybridge"))) in -march=nehalem
compiled object (or vice versa) you could try to bisect between different
routines to find out where the problem is.


[Bug fortran/64591] [4.8/4.9/5 Regression] ICE on use association of renamed extended type

2015-01-14 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64591

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from janus at gcc dot gnu.org ---
Certainly a duplicate of PR 62044.

*** This bug has been marked as a duplicate of bug 62044 ***


[Bug fortran/62044] [4.8/4.9/5 Regression] ICE in USE statement with RENAME for extended derived type

2015-01-14 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #3 from janus at gcc dot gnu.org ---
*** Bug 64591 has been marked as a duplicate of this bug. ***


[Bug tree-optimization/64493] [4.8/4.9/5 Regression] ICE at -O3 on x86_64-linux-gnu

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64493

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 14 08:32:18 2015
New Revision: 219579

URL: https://gcc.gnu.org/viewcvs?rev=219579&root=gcc&view=rev
Log:
2015-01-14  Richard Biener  

PR tree-optimization/64493
PR tree-optimization/64495
* tree-vect-loop.c (vect_finalize_reduction): For double-reductions
assign the proper vectorized PHI to the inner loop exit PHIs.

* gcc.dg/vect/pr64493.c: New testcase.
* gcc.dg/vect/pr64495.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr64493.c
trunk/gcc/testsuite/gcc.dg/vect/pr64495.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c


[Bug tree-optimization/64495] [4.8/4.9/5 Regression] ICE at -O3 for trunk and wrong code for 4.8/4.9 on x86_64-linux-gnu

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64495

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 14 08:32:18 2015
New Revision: 219579

URL: https://gcc.gnu.org/viewcvs?rev=219579&root=gcc&view=rev
Log:
2015-01-14  Richard Biener  

PR tree-optimization/64493
PR tree-optimization/64495
* tree-vect-loop.c (vect_finalize_reduction): For double-reductions
assign the proper vectorized PHI to the inner loop exit PHIs.

* gcc.dg/vect/pr64493.c: New testcase.
* gcc.dg/vect/pr64495.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr64493.c
trunk/gcc/testsuite/gcc.dg/vect/pr64495.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c


[Bug tree-optimization/64493] [4.8/4.9 Regression] ICE at -O3 on x86_64-linux-gnu

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64493

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||5.0
Summary|[4.8/4.9/5 Regression] ICE  |[4.8/4.9 Regression] ICE at
   |at -O3 on x86_64-linux-gnu  |-O3 on x86_64-linux-gnu

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.


[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls

2015-01-14 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379

--- Comment #14 from Ramana Radhakrishnan  ---
(In reply to Donn Seeley from comment #13)
> BTW, this issue cropped up in Wind River Linux testing, not VxWorks.  I have
> no idea whether the VxWorks folks are using -mapcs-frame.  WR Linux will
> remove the -mapcs-frame flag from future builds; it was originally added to
> support patches to oprofile that we have since dropped.

Yes I've been asking the Linux kernel folks why they are using mapcs-frame. I'd
think if this has been added only for oprofile, this should now be dropped from
usage.

Thanks for the input on VxWorks, we'll draft something up about deprecating
this option.

Ramana


[Bug tree-optimization/64495] [4.8/4.9 Regression] ICE at -O3 for trunk and wrong code for 4.8/4.9 on x86_64-linux-gnu

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64495

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-valid-code,
   ||wrong-code
  Known to work||5.0
Summary|[4.8/4.9/5 Regression] ICE  |[4.8/4.9 Regression] ICE at
   |at -O3 for trunk and wrong  |-O3 for trunk and wrong
   |code for 4.8/4.9 on |code for 4.8/4.9 on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.


[Bug go/64595] New: cgo installed into wrong directory

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

Bug ID: 64595
   Summary: cgo installed into wrong directory
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: rguenth at gcc dot gnu.org
CC: cmang at google dot com

With --enable-version-specific-runtime-libs I get go and gofmt installed in
$prefix/bin but cgo is installed into $prefix/lib/gcc/$target/$version/cgo

That is inconsistent.

>From the install log:

[ 4801s] test -z "/usr/bin" || /usr/bin/mkdir -p
"/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/bin"
[ 4801s]   /usr/bin/install -c go
'/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/bin/./go-5'
[ 4801s]   /usr/bin/install -c gofmt
'/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/bin/./gofmt-5'
[ 4801s] test -z "/usr/lib64/gcc/x86_64-suse-linux/5" || /usr/bin/mkdir -p
"/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/lib64/gcc/x86_64-suse-linux/5"
[ 4801s]   /usr/bin/install -c cgo
'/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/lib64/gcc/x86_64-suse-linux/5/./cgo-5'

that is, why

bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT)
libexecsub_PROGRAMS = cgo$(EXEEXT)

?

There are also no manual pages or other documentation about these tools it
seems.


[Bug middle-end/64391] ICE: SIGSEGV in get_attrs_for (trans-mem.c:179) with -fgnu-tm and #pragma GCC ivdep

2015-01-14 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64391

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 14 08:43:53 2015
New Revision: 219581

URL: https://gcc.gnu.org/viewcvs?rev=219581&root=gcc&view=rev
Log:
PR middle-end/64391
* trans-mem.c (get_attrs_for): Return NULL_TREE if X is NULL_TREE.

* gcc.dg/tm/pr64391.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/tm/pr64391.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/trans-mem.c


[Bug middle-end/64391] ICE: SIGSEGV in get_attrs_for (trans-mem.c:179) with -fgnu-tm and #pragma GCC ivdep

2015-01-14 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64391

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed.



[Bug tree-optimization/59354] [4.8/4.9/5 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[4.8/4.9/5/Regression]  |[4.8/4.9/5 Regression]
   |Element swizzling produces  |Element swizzling produces
   |invalid result with -O3 |invalid result with -O3

--- Comment #8 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> It looks to me that cunrolli pass is messing up element swizzling code.
> 
> bisection-friendly C testcase:
> 
> --cut here--
> void abort (void);
> 
> unsigned int a[256];
> unsigned char b[256];
> 
> int main()
> {
>   int i, z, x, y;
> 
>   for(i = 0; i < 256; i++)
> a[i] = i % 5;
> 
>   for (z = 0; z < 16; z++)
> for (y = 0; y < 4; y++)
>   for (x = 0; x < 4; x++)
> b[y*64 + z*4 + x] = a[z*16 + y*4 + x];
> 
>   if (b[4] != 1)
> abort ();
> 
>   return 0;
> }
> --cut here--

This testcase works for me on trunk now (maybe one of my recent vectorizer
fixes) but it miscompiles on the 4.9 and 4.8 branches (4.7 seems to work).

Maybe somebody can bisect what fixed it on trunk? (and confirm the bug is
indeed gone on trunk)

[Bug middle-end/64592] [5 regression] tramp3d EH unwind tables are 50% bigger with mainline compared to GCC 4.9

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-linux
Version|unknown |5.0
   Target Milestone|--- |5.0

--- Comment #1 from Richard Biener  ---
accumulate-outgoing-args default setting change?


[Bug tree-optimization/59354] [4.8/4.9/5 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

--- Comment #9 from Jakub Jelinek  ---
I can reproduce it even with r219580.


[Bug tree-optimization/59354] [4.8/4.9/5 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread ville.voutilainen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

--- Comment #10 from Ville Voutilainen  ---
(In reply to Jakub Jelinek from comment #9)
> I can reproduce it even with r219580.

Likewise. People, remember to use -O3 when reproducing.


[Bug tree-optimization/64365] Predictive commoning after loop vectorization produces incorrect code.

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-14
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Can you provide an executable testcase that abort()s when miscompiled and
terminates successfully if not?  Thus something suitable for the testsuite?
That also makes it possible to bisect to a commit that broke this.

A hint may be

   :
+  _6 = MEM[(int *)in_7(D) + 24B(OVF)];
   goto ;

that appears in the pcom dump.


[Bug ipa/64583] [5 Regression] recent inliner changes cause Chromium build failure

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64583

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0


[Bug go/64595] cgo installed into wrong directory

2015-01-14 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #1 from Andreas Schwab  ---
According to http://golang.org/cmd/cgo/ cgo isn't supposed to be called
directly, but only via go tool cgo.  But the version suffix will probably break
it.


[Bug ipa/64545] failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693

2015-01-14 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
Also breaks profiledbootstrap autotester [1].

[1] https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00258.html

[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu

2015-01-14 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 13 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #5 from Jakub Jelinek  ---
> x % x for x == 0 is undefined behavior, so perhaps with the exception of
> sanitization we can just assume it is not 0 and thus fold x % x to 0.
> Or does e.g. Ada/Java require something different?

See the inconsistent handing of % vs. / in fold (we fold 0 % x to 0
but preserve literal 0 % 0 - we don't fold 0 / x to 0).

In my view we should just go ahead and fold, though with 
-fnon-call-exceptions one may do

 try {
  x % x
  abort ();
 } catch (...) {
 }

and throw from inside a trap handler.  Which means that one can
catch undefined behavior.  IMHO -fnon-call-exceptions and sub-flags
like -ftrapv tell GCC to treat the specific undefined behavior as
defined - namely trapping.  We don't have a special flag for
divide-by-zero-traps though (it's not exactly "overflow").

So maybe with making the folding more consistent we should simply
add such flag, -fdivide-by-zero-traps which also makes modulo-by-zero
trap?


[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).

2015-01-14 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434

--- Comment #13 from rguenther at suse dot de  ---
On Tue, 13 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #12 from Jakub Jelinek  ---
> Shouldn't you cache the result of count_num_stmt in some SSA_NAME_VERSION
> indexed vector?  Otherwise it can be expensive on pathological testcases.
> And with the caching I'd hope it should be cheap enough that you could do that
> even outside of loops.

Yes, see my patch review


[Bug tree-optimization/59354] [4.8/4.9/5 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

--- Comment #11 from rguenther at suse dot de  ---
On Wed, 14 Jan 2015, ville.voutilainen at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
> 
> --- Comment #10 from Ville Voutilainen  
> ---
> (In reply to Jakub Jelinek from comment #9)
> > I can reproduce it even with r219580.
> 
> Likewise. People, remember to use -O3 when reproducing.

Will try in a non-dev tree then (and then identify which of the gazillion
local changes I have "fixes" it...)


[Bug target/64460] ARM ICE on valid code

2015-01-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460

--- Comment #9 from ktkachov at gcc dot gnu.org ---
(In reply to Joel Sherrill from comment #8)
> (In reply to ktkachov from comment #7)
> > I guess the testcase is flaky.
> > I've posted the patch to fix the ICE and the reasoning behind it at
> > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00686.html
> 
> Can you try again with the full test case? The head still fails for me at
> -O2 and -Os but not -O1. The location in toplev.c has moved down a few lines.
> 

My patch has not gone in yet, did you try applying it by hand and trying it
out?
I just tried the full testcase on r219461 and it ICEs without my patch and
compiles fine with my patch applied


[Bug c++/64596] New: Friendship not recognized and template param deduction error

2015-01-14 Thread petschy at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64596

Bug ID: 64596
   Summary: Friendship not recognized and template param deduction
error
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com

Explanation of the attached code: Str is a stream class, Txn is its helper,
thus needs access to Str's private members. There is also a Glue class that is
supposed to glue together a stream implementation and the streamed type. This
way the streamed type needs to grant friend access only to Glue, and need not /
should not know about the streams. The stream might also grant friendship to
Glue. For a specific stream type and streamed type Glue should be specialized
and perform the actual streaming there, optionally using the private members of
the stream and the streamed type.

Implementing this I ran into two errors and though I have a workaround, it's
not clear to me that the errors are due to some strange interaction of the
language rules, or bugs in the compiler.

Plan A: the Txn class is separate from Str. Str wants to grant friendship to
Txn, but with the same E type only. template friend class Txn;
won't work as the compiler sees this as a specialization. To work around this I
used a templated using directive: template using Tx = Txn; and
granted friendship to Tx. Unfortunately this doesn't work, when Txn tries to
access the private member i, an error is reported.

Plan B: move Txn inside StrB. This solves the access problem, but then there's
a new error: the Glue specialization won't compile, telling me that the
template params cannot be deduced. This is strange, as the syntax is the same
as in Plan A.

Plan C: move Txn inside StrC, but create TxnC, a simple forwarder class
outside, too. This way the access works, since Txn is inside, and the Glue
specialization works since we glue the outside class, TxnC. However, this is
tedious with real code.

Tested with 4.9.1 and 5.0 (20141222), both give the same errors:

g++ -std=c++11 -Wall 20150114-friend.cpp 
20150114-friend.cpp:81:8: error: template parameters not deducible in partial
specialization:
 struct Glue, int> // error: template parameters not deducible in
partial specialization
^
20150114-friend.cpp:81:8: note: ‘E’
20150114-friend.cpp: In instantiation of ‘Txn::Txn(Txn::S&) [with E
= int; bool R = false; Txn::S = Str]’:
20150114-friend.cpp:45:38:   required from ‘static void Glue,
int>::Foo() [with E = int; bool R = false]’
20150114-friend.cpp:52:30:   required from here
20150114-friend.cpp:17:6: error: ‘int Str::i’ is private
  int i;
  ^
20150114-friend.cpp:28:3: error: within this context
   ++s.i; // error: ‘int Str::i’ is private
   ^

[Bug c++/64596] Friendship not recognized and template param deduction error

2015-01-14 Thread petschy at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64596

--- Comment #1 from petschy at gmail dot com ---
Created attachment 3
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3&action=edit
code


[Bug target/64460] ARM ICE on valid code

2015-01-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Jan 14 10:14:23 2015
New Revision: 219583

URL: https://gcc.gnu.org/viewcvs?rev=219583&root=gcc&view=rev
Log:
[ARM] Fix PR target/64460: Set 'shift' attr properly on some patterns.

PR target/64460
* config/arm/arm.md (*_multsi): Set 'shift' to 2.
(*_shiftsi): Set 'shift' attr to 3.

* gcc.target/arm/pr64460_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr64460_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog


[Bug target/64460] ARM ICE on valid code

2015-01-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Joel, can you try trunk after this commit to confirm that it fixes the ICE on
your end and close this off if ok?

Thanks,
Kyrill


[Bug target/64379] VFP register restore in ARM epilogue can break indirect tailcalls

2015-01-14 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379

--- Comment #15 from Eric Botcazou  ---
> Thanks for the input on VxWorks, we'll draft something up about deprecating
> this option.

Note that the system compiler uses APCS frames and DWARF2 EH on VxWorks 6,
which is the mainstream version as of this writing, so this cannot be done too
quickly
for the sake of compatibility with it.


[Bug ipa/64583] [5 Regression] recent inliner changes cause Chromium build failure

2015-01-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64583

--- Comment #3 from Markus Trippelsdorf  ---
Symbol diff gcc-2015-01-10 vs. trunk:

@@ -26,12 +26,11 @@
  U _ZN3WTF6String6appendEt
  U _ZN3WTF6StringC1EPKtj
  W
_ZN3WTF6VectorINS_6OwnPtrIN5blink20GraphicsContextStateEEELm0ENS_16DefaultAllocatorEE14appendSlowCaseINS_10PassOwnPtrIS3_vRKT_
- W
_ZN3WTF6VectorINS_6OwnPtrIN5blink20GraphicsContextStateEEELm0ENS_16DefaultAllocatorEE15reserveCapacityEm
  W
_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE14appendSlowCaseIS3_EEvRKT_
  W
_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE14expandCapacityEm
- W
_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE15reserveCapacityEm
  U _ZN3WTF8fastFreeEPv
  U _ZN5blink10FloatPointC1ERKNS_8IntPointE
+ W _ZN5blink10FontFamilyD1Ev
  W _ZN5blink10FontFamilyD2Ev
  n _ZN5blink10FontFamilyD5Ev
  U _ZN5blink11RenderTheme5themeEv

g++ --save-temps -MMD -MF
obj/third_party/WebKit/Source/web/blink_web.PopupListBox.o.d
-DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 -DDISABLE_NACL
-DCHROMIUM_BUILD -DTOOLKIT_VIEWS=1 -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1
-DUSE_ASH=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_DEFAULT_RENDER_THEME=1
-DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 -DUSE_CLIPBOARD_AURAX11=1
-DENABLE_ONE_CLICK_SIGNIN -DENABLE_PRE_SYNC_BACKUP -DENABLE_REMOTING=1
-DENABLE_WEBRTC=1 -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY
-DENABLE_NOTIFICATIONS -DUSE_UDEV -DDONT_EMBED_BUILD_METADATA
-DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PLUGINS=1
-DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1
-DENABLE_BACKGROUND=1 -DENABLE_GOOGLE_NOW=1 -DCLD_VERSION=2 -DENABLE_PRINTING=1
-DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1
-DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1
-DENABLE_SUPERVISED_USERS=1 -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1
-DV8_USE_EXTERNAL_STARTUP_DATA -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK
-DCHROME_PNG_WRITE_SUPPORT -DPNG_USER_CONFIG
-DENABLE_LAYOUT_UNIT_IN_INLINE_BOXES=0
-DWTF_USE_CONCATENATED_IMPULSE_RESPONSES=1 -DENABLE_INPUT_MULTIPLE_FIELDS_UI=1
-DENABLE_WEB_AUDIO=1 -DWTF_USE_WEBAUDIO_FFMPEG=1
-DWTF_USE_DEFAULT_RENDER_THEME=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0
-DSK_ENABLE_INST_COUNT=0 -DSK_SUPPORT_GPU=1
'-DGR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h"'
-DSK_ENABLE_LEGACY_API_ALIASING=1 -DSK_ATTR_DEPRECATED=SK_NOTHING_ARG1
-DGR_GL_IGNORE_ES3_MSAA=0 -DSK_WILL_NEVER_DRAW_PERSPECTIVE_TEXT
-DSK_LEGACY_DRAWPICTURECALLBACK -DSK_USE_POSIX_THREADS
-DU_STATIC_IMPLEMENTATION -DUSE_LIBPCI=1 -DUSE_GLIB=1 -DUSE_NSS=1
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_FORTIFY_SOURCE=2 -Igen
-I../../third_party/angle/include -I../../third_party/skia/include/utils
-I../../third_party/WebKit/Source -I../.. -I../../skia/config
-I../../third_party/khronos -I../../gpu -I../../third_party/WebKit -Igen/blink
-I../../third_party/libpng -I../../third_party/zlib -I../../third_party/libwebp
-I../../third_party/ots/include -I../../third_party/iccjpeg
-I../../third_party/libjpeg_turbo -I../../third_party/icu/source/i18n
-I../../third_party/qcms/src -I../../third_party/skia/src/core
-I../../third_party/skia/include/core -I../../third_party/skia/include/effects
-I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu
-I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops
-I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports
-I../../skia/ext -I../../third_party/icu/source/common
-I../../third_party/npapi -I../../third_party/npapi/bindings -I../../v8/include
-fstack-protector --param=ssp-buffer-size=4 -pthread -fno-strict-aliasing -Wall
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe
-fPIC -Wno-unused-local-typedefs -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/harfbuzz -m64 -march=x86-64 -O2
-fno-ident -fdata-sections -ffunction-sections -funwind-tables
-Wno-c++0x-compat -fno-exceptions -fno-rtti -fno-threadsafe-statics
-fvisibility-inlines-hidden -Wsign-compare -Wno-c++0x-compat -std=gnu++11
-Wno-narrowing -Wno-literal-suffix -c
../../third_party/WebKit/Source/web/PopupListBox.cpp -o
obj/third_party/WebKit/Source/web/blink_web.PopupListBox.o


[Bug tree-optimization/54742] Switch elimination in FSM loop

2015-01-14 Thread yroux at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742

--- Comment #41 from Yvan Roux  ---
Author: yroux
Date: Wed Jan 14 10:22:48 2015
New Revision: 219584

URL: https://gcc.gnu.org/viewcvs?rev=219584&root=gcc&view=rev
Log:
gcc/
2015-01-14  Yvan Roux  

Backport from trunk r218451.
2014-12-06  James Greenhalgh  
Sebastian Pop  
Brian Rzycki  

PR tree-optimization/54742
* params.def (max-fsm-thread-path-insns, max-fsm-thread-length,
max-fsm-thread-paths): New.

* doc/invoke.texi (max-fsm-thread-path-insns, max-fsm-thread-length,
max-fsm-thread-paths): Documented.

* tree-cfg.c (split_edge_bb_loc): Export.
* tree-cfg.h (split_edge_bb_loc): Declared extern.

* tree-ssa-threadedge.c (simplify_control_stmt_condition): Restore the
original value of cond when simplification fails.
(fsm_find_thread_path): New.
(fsm_find_control_statement_thread_paths): New.
(thread_through_normal_block): Call find_control_statement_thread_paths.

* tree-ssa-threadupdate.c (dump_jump_thread_path): Pretty print
EDGE_FSM_THREAD.
(verify_seme): New.
(duplicate_seme_region): New.
(thread_through_all_blocks): Generate code for EDGE_FSM_THREAD edges
calling duplicate_seme_region.

* tree-ssa-threadupdate.h (jump_thread_edge_type): Add EDGE_FSM_THREAD.

gcc/testsuite/
2015-01-14  Yvan Roux  

Backport from trunk r218451.
2014-12-06  James Greenhalgh  
Sebastian Pop  
Brian Rzycki  

PR tree-optimization/54742
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: New test.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: New test.


Added:
   
branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
   
branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
Modified:
branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_9-branch/gcc/doc/invoke.texi
branches/linaro/gcc-4_9-branch/gcc/params.def
branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
branches/linaro/gcc-4_9-branch/gcc/tree-cfg.c
branches/linaro/gcc-4_9-branch/gcc/tree-cfg.h
branches/linaro/gcc-4_9-branch/gcc/tree-ssa-threadedge.c
branches/linaro/gcc-4_9-branch/gcc/tree-ssa-threadupdate.c
branches/linaro/gcc-4_9-branch/gcc/tree-ssa-threadupdate.h


[Bug ipa/64583] [5 Regression] recent inliner changes cause Chromium build failure

2015-01-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64583

--- Comment #4 from Markus Trippelsdorf  ---
Created attachment 34445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34445&action=edit
unreduced testcase


[Bug ipa/64307] [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -fPIC -fipa-icf

2015-01-14 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64307

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Martin Liška  ---
Fixed in 5.0.0.

[Bug tree-optimization/59354] [4.8/4.9/5 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

--- Comment #12 from Richard Biener  ---
Ok, we SLP the first block

node
stmt 0 b[_17] = _24;

stmt 1 b[_3] = _50;

stmt 2 b[_93] = _99;

stmt 3 b[_104] = _110;

node
stmt 0 _24 = (unsigned char) _23;

stmt 1 _50 = (unsigned char) _63;

stmt 2 _99 = (unsigned char) _98;

stmt 3 _110 = (unsigned char) _109;

node
stmt 0 _23 = a[_21];

stmt 1 _63 = a[_64];

stmt 2 _98 = a[_97];

stmt 3 _109 = a[_108];

and for all other instances claim the load permutation is not supported.

For the stmts visble above the load permutation _is_ 1:1, but as we need
to gobble up more loads due to the truncation the effective SLP group
we deal with has gaps (bah, the gaps code...)

Thus the underlying issue is that we have

t.c:13:3: note: Detected interleaving of size 16
t.c:13:3: note: Detected interleaving of size 4
t.c:13:3: note: Detected interleaving of size 4
t.c:13:3: note: Detected interleaving of size 4
t.c:13:3: note: Detected interleaving of size 4

with the group-size of the stores (4) determining the SLP group size but
the analysis code being confused by the non-matching group size of the
loads.

In the end we should probably split up the groups if a single group ends up
being refered to in different SLP instances (thus also postpone most of
the dependence-kind tests until after SLP discovery).  Let's see if a simple
workaround doesn't regress anything.

Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 219581)
+++ gcc/tree-vect-slp.c (working copy)
@@ -729,8 +729,11 @@ vect_build_slp_tree_1 (loop_vec_info loo
 ???  We should enhance this to only disallow gaps
 inside vectors.  */
   if ((unrolling_factor > 1
-  && GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) == stmt
-  && GROUP_GAP (vinfo_for_stmt (stmt)) != 0)
+  && ((GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) == stmt
+   && GROUP_GAP (vinfo_for_stmt (stmt)) != 0)
+  /* If the group is split up then GROUP_GAP
+ isn't correct here, nor is GROUP_FIRST_ELEMENT.  */
+  || GROUP_SIZE (vinfo_for_stmt (stmt)) > group_size))
  || (GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) != stmt
  && GROUP_GAP (vinfo_for_stmt (stmt)) != 1))
 {


[Bug libffi/64572] r219477 breaks bootstrap on x86_64 darwin

2015-01-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64572

--- Comment #12 from Dominique d'Humieres  ---
> I can confirm these now. Executing 'make -k check' in 
> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-
> darwin14.1.0/i386/libffi doesn't cause -m32 to be passed to the test suite
> but 'make -k check RUNTESTFLAGS="--target_board=unix'{-m32}'"' does.

This is not darwin specific: see
https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg01376.html.

At https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg01372.html, I see

=== libffi tests ===


Running target unix

=== libffi Summary ===

# of expected passes2204

i.e., no unix/-m32.

Should we open a new PR for that?


[Bug target/61413] __ARM_SIZEOF_WCHAR_T is constant 32 -- should be 4 or 2

2015-01-14 Thread renlin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61413

--- Comment #4 from renlin at gcc dot gnu.org ---
Author: renlin
Date: Wed Jan 14 11:02:24 2015
New Revision: 219587

URL: https://gcc.gnu.org/viewcvs?rev=219587&root=gcc&view=rev
Log:
[ARM]Fix definition of __ARM_SIZEOF_WCHAR_T.

Backport from mainline:
2014-08-12 Ramana Radhakrishnan 

PR target/61413
* config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Fix definition
of __ARM_SIZEOF_WCHAR_T.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/arm/arm.h


[Bug target/61413] __ARM_SIZEOF_WCHAR_T is constant 32 -- should be 4 or 2

2015-01-14 Thread renlin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61413

renlin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||renlin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from renlin at gcc dot gnu.org ---
backport to branch 4.8 & 4.9.


[Bug middle-end/64415] [5 Regression] ICE: verify_ssa failed / segmentation fault with LTO

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64415

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed (in a different way).


[Bug middle-end/64415] [5 Regression] ICE: verify_ssa failed / segmentation fault with LTO

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64415

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 14 11:06:18 2015
New Revision: 219588

URL: https://gcc.gnu.org/viewcvs?rev=219588&root=gcc&view=rev
Log:
2015-01-14  Richard Biener  

PR lto/64415
* tree-inline.c (insert_debug_decl_map): Check destination
function MAY_HAVE_DEBUG_STMTS.
(insert_init_debug_bind): Likewise.
(insert_init_stmt): Remove redundant check.
(remap_gimple_stmt): Drop debug stmts if the destination
function has var-tracking assignments disabled.

* gcc.dg/lto/pr64415_0.c: New testcase.
* gcc.dg/lto/pr64415_1.c: Likewise. 

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr64415_0.c
trunk/gcc/testsuite/gcc.dg/lto/pr64415_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


[Bug c++/64588] [C++11] Wrong number of template arguments when template template parameter is template alias.

2015-01-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64588

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 64587 ***


[Bug c++/64587] [C++11] Wrong number of template arguments when template template parameter is template alias.

2015-01-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64587

--- Comment #1 from Jonathan Wakely  ---
*** Bug 64588 has been marked as a duplicate of this bug. ***


[Bug target/64377] nios2 compile error in options-save.c

2015-01-14 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377

--- Comment #16 from Martin Liška  ---
Thank you for testing, there's patch I've just sent to gcc-patches ML:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01008.html.

Martin

[Bug tree-optimization/64541] FRE pass optimization failure

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org
Summary|.fre1 pass optimization |FRE pass optimization
   |failure |failure

--- Comment #1 from Richard Biener  ---
The sources are different in that 2.c dereferences *p one more time after
*q is stored to while 1.c dereferences *q for the return value.  Thus an
equivalent 2.c would be

int f (int ** p, int ** q)
{
++*p;
*q = *p;
return **q;
}

it is true that we can still optimize the original 2.c but only because
*p and *q are equivalent (but it is probably not worthwhile the compile-time
cost 
handling this). That is, we have to assume that p == q and thus the store to *q
invalidates the previously load *p.

I also think we have a duplicate report for this somewhere.

Simpler testcase (which is probably that in the duplicate):

int foo (int *p, int *q)
{
  *p = 1;
  *q = 1;
  return *p;
}


[Bug target/64453] Live high register not saved in function prolog on ARM with -Os

2015-01-14 Thread thopre01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64453

--- Comment #1 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Wed Jan 14 11:51:40 2015
New Revision: 219592

URL: https://gcc.gnu.org/viewcvs?rev=219592&root=gcc&view=rev
Log:
2015-01-14  Thomas Preud'homme  

gcc/
PR target/64453
* config/arm/arm.c (callee_saved_reg_p): Define.
(arm_compute_save_reg0_reg12_mask): Use callee_saved_reg_p to check if
register is callee saved instead of !call_used_regs[reg].
(thumb1_compute_save_reg_mask): Likewise.

gcc/testsuite/
PR target/64453
* gcc.target/arm/pr64453.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr64453.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/64541] FRE pass optimization failure

2015-01-14 Thread skvadrik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541

--- Comment #2 from Ulya  ---
> we have to assume that p == q and thus the store to *q invalidates the 
> previously load *p

I see.
It seemed to me from GIMPLE dumps that both cases are equally easy to optimize,
perhaps I'm missing something.


[Bug tree-optimization/64541] FRE pass optimization failure

2015-01-14 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 14 Jan 2015, skvadrik at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
> 
> --- Comment #2 from Ulya  ---
> > we have to assume that p == q and thus the store to *q invalidates the 
> > previously load *p
> 
> I see.
> It seemed to me from GIMPLE dumps that both cases are equally easy to 
> optimize,
> perhaps I'm missing something.

1:

  _6 = *p_2(D);
  *q_7(D) = _6;
  _9 = *q_7(D);
  _10 = *_9;

it's easy to see that the load _9 = *q_7(D) results in _6.

2:

  *p_2(D) = _4;
  _6 = *p_2(D);
  *q_7(D) = _6;
  _9 = *p_2(D);
  _10 = *_9;

not so much here for the load _9 = *p_2(D) as I explained
(the store *q_7(D) = _6 aliases it)


[Bug tree-optimization/64541] FRE pass optimization failure

2015-01-14 Thread skvadrik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541

--- Comment #4 from Ulya  ---
Ah! Now I see the problem, thanks.


[Bug tree-optimization/64365] Predictive commoning after loop vectorization produces incorrect code.

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365

--- Comment #3 from Richard Biener  ---
extern void abort (void);
extern int memcmp (const void * , const void *, __SIZE_TYPE__);

void __attribute__((noinline,noclone))
foo(int *in)
{
for (int i = 14; i >= 10; i--) {
in[i - 8] -= in[i];
in[i - 5] += in[i] * 2;
in[i - 4] += in[i];
}
}

int main()
{
  int x[16];
  int y[16] = { 0, 1, -22, -8, -8, 40, 38, 42, 46, 50, 24, 11, 12, 13, 14, 15
};
  int i;

  for (i = 0; i < 16; ++i)
{
  x[i] = i;
  __asm__ volatile ("");
}

  foo (x);

  if (memcmp (x, y, sizeof (x)) != 0)
abort ();

  return 0;
}


[Bug tree-optimization/64365] [5 Regression] Predictive commoning after loop vectorization produces incorrect code.

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||4.9.2
   Target Milestone|--- |5.0
Summary|Predictive commoning after  |[5 Regression] Predictive
   |loop vectorization produces |commoning after loop
   |incorrect code. |vectorization produces
   ||incorrect code.
  Known to fail||5.0


[Bug c++/59937] [constexpr] bogus diagnostic "used in its own initializer"

2015-01-14 Thread jota.uve at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59937

Javier V. Gómez  changed:

   What|Removed |Added

 CC||jota.uve at hotmail dot com

--- Comment #2 from Javier V. Gómez  ---
I found another case that worked in G++ 4.8.3 but fails in 4.9:

-
main.cpp: 
-
int main ()
{
constexpr int n = 2;
A a;
B b;
b.foo();
}

-
a.hpp: 
-
template  class A
{
static constexpr size_t getN() {return n;}
};

-
b.hpp: 
-
class B 
{
void foo ()
{
//has access to a A object
constexpr int n = a.getN();
A a2;
}
};


Compiler output:
B.hpp: error: the value of ‘n’ is not usable in a constant expression
 A a2;
   ^
B.hpp: note: ‘ndims’ used in its own initializer
 constexpr int n = a.getN();
   ^

[Bug rtl-optimization/57518] [4.8 Regression] Redundant insn generated in LRA

2015-01-14 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #12 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #11)
> GCC 4.8.4 has been released.

If this won't be backported to 4.8 why keep this open ? 

Ramana


[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)

2015-01-14 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ramana at gcc dot gnu.org


[Bug middle-end/64577] No -Wpadded warning on padding bitfields

2015-01-14 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64577

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |middle-end

--- Comment #1 from Marek Polacek  ---
-Wpadded is implemented in stor-layout.c, so moving to middle-end component.


[Bug tree-optimization/64365] [5 Regression] Predictive commoning after loop vectorization produces incorrect code.

2015-01-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r214678.


[Bug tree-optimization/64365] [4.9/5 Regression] Predictive commoning after loop vectorization produces incorrect code.

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365

Richard Biener  changed:

   What|Removed |Added

  Known to work|4.9.2   |4.8.3
Summary|[5 Regression] Predictive   |[4.9/5 Regression]
   |commoning after loop|Predictive commoning after
   |vectorization produces  |loop vectorization produces
   |incorrect code. |incorrect code.
  Known to fail||4.9.2

--- Comment #5 from Richard Biener  ---
Testcase that also fails on the 4.9 branch:

extern void abort (void);
extern int memcmp (const void * , const void *, __SIZE_TYPE__);

void __attribute__((noinline,noclone))
foo(int *in)
{
  int i;
  for (i = 62; i >= 10; i--)
{
  in[i - 8] -= in[i];
  in[i - 5] += in[i] * 2;
  in[i - 4] += in[i];
}
}

int main()
{
  int x[64];
  int y[64] = { 0, 1, -2380134, -1065336, -1026376, 3264240, 3113534, 2328130,
3632054, 3839634, 2380136, 1065339, 1026380, 1496037, 1397286, 789976, 386408,
450984, 597112, 497464, 262008, 149184, 194768, 231519, 173984, 87753, 60712,
82042, 87502, 60014, 30050, 25550, 33570, 32386, 20464, 10675, 10868, 13329,
11794, 6892, 3988, 4564, 5148, 4228, 2284, 1568, 1848, 1943, 1472, 741, 628,
702, 714, 474, 230, 234, 238, 242, 120, 59, 60, 61, 62, 63 };
  int i;

  for (i = 0; i < 64; ++i)
{
  x[i] = i;
  __asm__ volatile ("");
}

  foo (x);

  if (memcmp (x, y, sizeof (x)) != 0)
abort ();

  return 0;
}


[Bug c++/59937] [constexpr] bogus diagnostic "used in its own initializer"

2015-01-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59937

--- Comment #3 from Jonathan Wakely  ---
(In reply to Javier V. Gómez from comment #2)
> I found another case that worked in G++ 4.8.3 but fails in 4.9:

This example is complete nonsense. Why is it split across three files? Why
doesn't main.cpp include anything? Why is everything private? Why is 'a'
undeclared in B::foo()? Why does the diagnostic talk about 'ndims' which isn't
declared anywhere?

It's useless as a test or an example of the error.

[Bug c++/59937] [constexpr] bogus diagnostic "used in its own initializer"

2015-01-14 Thread jota.uve at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59937

--- Comment #4 from Javier V. Gómez  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Javier V. Gómez from comment #2)
> > I found another case that worked in G++ 4.8.3 but fails in 4.9:
> 
> This example is complete nonsense. Why is it split across three files? Why
> doesn't main.cpp include anything? Why is everything private? Why is 'a'
> undeclared in B::foo()? Why does the diagnostic talk about 'ndims' which
> isn't declared anywhere?
> 
> It's useless as a test or an example of the error.

I tried to simplify as much as possible the issue, since I detected the error
in a big piece of code. I didn't pretend to create a compilable example. ndims
is what I called n (copy and paste...).

The important point of my example is that constexpr int n = a.getN(); fails
when A::getN() just returns a template parameter value previously set by a
constexpr anywhere else.

[Bug rtl-optimization/902] x86 optimization bug with sibling call and -fomit-frame-pointer

2015-01-14 Thread yroux at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=902

--- Comment #12 from Yvan Roux  ---
Author: yroux
Date: Wed Jan 14 12:53:04 2015
New Revision: 219597

URL: https://gcc.gnu.org/viewcvs?rev=219597&root=gcc&view=rev
Log:
2015-01-14  Yvan Roux  

Fix Linaro PR #902

Partial Backport from trunk r211798.
2014-06-18  Radovan Obradovic  
Tom de Vries  

* config/arm/arm.c (arm_emit_call_insn): Add IP and CC clobbers to
CALL_INSN_FUNCTION_USAGE.

Backport from trunk r209800.
2014-04-25  Tom de Vries  

* expr.c (clobber_reg_mode): New function.
* expr.h (clobber_reg): New function.


Modified:
branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c
branches/linaro/gcc-4_9-branch/gcc/expr.c
branches/linaro/gcc-4_9-branch/gcc/expr.h


[Bug ipa/64583] [5 Regression] recent inliner changes cause Chromium build failure

2015-01-14 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64583

--- Comment #5 from Markus Trippelsdorf  ---
For example:

_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE15reserveCapacityEm/24866
(void WTF::Vector::reserveCapacity(size_t) [with
T = blink::PopupItem*; long unsigned int inlineCapacity = 0ul; Allocator =
WTF::DefaultAllocator; size_t = long unsigned int]) @0x7f549a1f9dc8
 Type: function definition analyzed
  Visibility: externally_visible public weak comdat
comdat_group:_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE15reserveCapacityEm
one_only visibility:hidden
  References:  
   
Referring:
  Availability: available
  First run: 0
  Function flags: body

vs.

_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE15reserveCapacityEm/24866
(void WTF::Vector::reserveCapacity(size_t) [with
T = blink::PopupItem*; long unsigned int inlineCapacity = 0ul; Allocator =
WTF::DefaultAllocator; size_t = long unsigned int]) @0x7f35e46eadc8
  Type: function definition analyzed   
   
Visibility: public weak comdat
comdat_group:_ZN3WTF6VectorIPN5blink9PopupItemELm0ENS_16DefaultAllocatorEE15reserveCapacityEm
one_only visibility:hidden
  References:
  Referring:
  Function void WTF::Vector::reserveCapacity(size_t) [with T = blink::PopupItem*; long unsigned
int inlineCapacity = 0ul; Allocator = WTF::DefaultAllocator; size_t = long
unsigned int]/24866 is inline copy in void WTF::Vector::expandCapacity(size_t) [with T = blink::PopupItem*; long unsigned
int inlineCapacity = 0ul; Allocator = WTF::DefaultAllocator; size_t = long
unsigned int]/24594
  Availability: available
  First run: 0
  Function flags: body


[Bug go/64595] cgo installed into wrong directory

2015-01-14 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #2 from Ian Lance Taylor  ---
Right, cgo is not run directly.  It is run by the go tool.  It is in effect an
internal program like cc1.

The version suffix should be fine if libexecsubdir in libgo matches
libexecsubdir in gotools, as the go tool will locate cgo via the variable
theGccgoToolDir written to version.go by libgo/Makefile.  I'll see if that
works with --enable-versions-specific-runtime-libs.

The docs are online at http://golang.org/cmd/{go,gofmt,cgo} which is where most
people read them.The docs come from the program source
(libgo/go/cmd/*/doc.go).  The programs also have -help options.  Would you like
me to add small man pages that direct people to the web pages?


[Bug tree-optimization/64365] [4.9/5 Regression] Predictive commoning after loop vectorization produces incorrect code.

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365

--- Comment #6 from Richard Biener  ---
ICK.  Data-ref analysis issue with respect to how we handle pointer IVs
in dr_analyze_indices.  This results in

(compute_affine_dependence
  stmt_a: MEM[(int *)vectp_in.21_137] = vect__12.23_139;
  stmt_b: vect__16.26_145 = MEM[(int *)vectp_in.24_143];
(analyze_overlapping_iterations
  (chrec_a = {204B(OVF), +, 18446744073709551600}_1)
  (chrec_b = {216B(OVF), +, 18446744073709551600}_1)
(analyze_siv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = no dependence)
  (overlaps_b = no dependence))
)
  (overlap_iterations_a = no dependence)
  (overlap_iterations_b = no dependence))
) -> no dependence

but this is only because 216 + n * (-16) never aliases index-wise.  That is,
data-ref analysis doesn't know about access sizes and in this case we have
partly overlapping vector accesses (it would treat exact overlaps correctly).
Unfortunately with partial overlaps being possible there is no way to
reduce a [ offset, size ] range down to a single index (even if all sizes
are equal).  In this special case we may see that the initial condition
is a constant and thus somehow gracefully "fail" (and for non-constant
initial condition hope we can't compute the dependence distance).

The pragmatic solution is to simply make possibly overlapping accesses
have distinct bases by adjusting CHREC_LEFT to be a multiple of the
access size.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 219592)
+++ gcc/tree-data-ref.c (working copy)
@@ -883,6 +883,8 @@ dr_analyze_innermost (struct data_refere
@@ -970,7 +972,8 @@ dr_analyze_indices (struct data_referenc

   /* If the address operand of a MEM_REF base has an evolution in the
  analyzed nest, add it as an additional independent access-function.  */
-  if (TREE_CODE (ref) == MEM_REF)
+  if (TREE_CODE (ref) == MEM_REF
+  && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST)
 {
   op = TREE_OPERAND (ref, 0);
   access_fn = analyze_scalar_evolution (loop, op);
@@ -992,6 +995,15 @@ dr_analyze_indices (struct data_referenc
fold_convert (ssizetype, memoff));
  memoff = build_int_cst (TREE_TYPE (memoff), 0);
}
+ /* Adjust the offset so it is a multiple of the access type
+size and thus we separate bases that can possibly be used
+to produce partial overlaps (which the access_fn machinery
+cannot handle).  */
+ wide_int rem
+   = wi::mod_trunc (off, TYPE_SIZE_UNIT (TREE_TYPE (ref)), SIGNED);
+ off = wide_int_to_tree (ssizetype, wi::sub (off, rem));
+ memoff = wide_int_to_tree (TREE_TYPE (memoff), rem);
+ /* And finally replace the initial condition.  */
  access_fn = chrec_replace_initial_condition
  (access_fn, fold_convert (orig_type, off));
  /* ???  This is still not a suitable base object for


[Bug go/64595] cgo installed into wrong directory

2015-01-14 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 14 Jan 2015, ian at airs dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
> 
> --- Comment #2 from Ian Lance Taylor  ---
> Right, cgo is not run directly.  It is run by the go tool.  It is in effect an
> internal program like cc1.

Ah - the README didn't say that.

> The version suffix should be fine if libexecsubdir in libgo matches
> libexecsubdir in gotools, as the go tool will locate cgo via the variable
> theGccgoToolDir written to version.go by libgo/Makefile.  I'll see if that
> works with --enable-versions-specific-runtime-libs.

Any example use that will end up executing cgo so I can check it out 
locally?

> The docs are online at http://golang.org/cmd/{go,gofmt,cgo} which is where 
> most
> people read them.The docs come from the program source
> (libgo/go/cmd/*/doc.go).  The programs also have -help options.  Would you 
> like
> me to add small man pages that direct people to the web pages?

Yes, that would be convenient!  (obviously cgo doesn't need a manpage 
then)


[Bug target/64387] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er

2015-01-14 Thread tocarip at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387

--- Comment #3 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Wed Jan 14 13:45:49 2015
New Revision: 219598

URL: https://gcc.gnu.org/viewcvs?rev=219598&root=gcc&view=rev
Log:
PR target/64387

gcc/
* config/i386/sse.md (vec_unpacks_hi_v8sf): Fix predicate.
(vec_unpacks_hi_v16sf): Ditto.

testsuite/
* gcc.target/i386/pr64387.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr64387.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog


[Bug target/64393] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512vbmi

2015-01-14 Thread tocarip at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64393

--- Comment #3 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Wed Jan 14 13:49:58 2015
New Revision: 219599

URL: https://gcc.gnu.org/viewcvs?rev=219599&root=gcc&view=rev
Log:
PR target/64393

gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX512VBMI_SET):
Enable AVX512BW.
(OPTION_MASK_ISA_AVX512BW_UNSET): Disable AVX512VBMI.
* config/i386/i386.c (ix86_hard_regno_mode_ok): Don't check
AVX512VBMI, as it implies AVX512BW.

testsuite/

* gcc.target/i386/pr64393.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr64393.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/i386/i386-common.c
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


[Bug target/64386] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw

2015-01-14 Thread tocarip at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64386

--- Comment #3 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Wed Jan 14 13:55:06 2015
New Revision: 219600

URL: https://gcc.gnu.org/viewcvs?rev=219600&root=gcc&view=rev
Log:
PR target/64386

gcc/
PR target/64386
* config/i386/i386.c (ix86_expand_sse_cmp): Handle V64QImode,
V32HImode.

testsuite/ 
* gcc.target/i386/pr64386.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr64386.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

2015-01-14 Thread amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

--- Comment #24 from Andrew Macleod  ---
Author: amacleod
Date: Wed Jan 14 13:58:35 2015
New Revision: 219601

URL: https://gcc.gnu.org/viewcvs?rev=219601&root=gcc&view=rev
Log:

2015-01-14  Andrew MacLeod  

PR middle-end/59448
* builtins.c (get_memmodel): Promote consume to acquire always.
* testsuite/gcc.dg/atomic-invalid.c: Remove obselete test for illegal
consume in an atomic_exchange.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/atomic-invalid.c


[Bug tree-optimization/59354] [4.8/4.9/5 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 14 14:06:07 2015
New Revision: 219603

URL: https://gcc.gnu.org/viewcvs?rev=219603&root=gcc&view=rev
Log:
2015-01-14  Richard Biener  

PR tree-optimization/59354
* tree-vect-slp.c (vect_build_slp_tree_1): Treat loads from
groups larger than the slp group size as having gaps.

* gcc.dg/vect/pr59354.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr59354.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c


[Bug tree-optimization/59354] [4.8/4.9 Regression] Element swizzling produces invalid result with -O3

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
Summary|[4.8/4.9/5 Regression]  |[4.8/4.9 Regression]
   |Element swizzling produces  |Element swizzling produces
   |invalid result with -O3 |invalid result with -O3

--- Comment #14 from Richard Biener  ---
Fixed on trunk sofar.


[Bug tree-optimization/64597] New: ICE when optimizing with AutoFDO annotation

2015-01-14 Thread rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64597

Bug ID: 64597
   Summary: ICE when optimizing with AutoFDO annotation
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
CC: dehao at gcc dot gnu.org
Target: x86_64-linux-gnu

Created attachment 34446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34446&action=edit
testcase

Compiling the attached testcase with -g -fauto-profile=profile.gcov  -O2,
generates the following ICE.

Note that the testcase has been reduced from the original, but still exhibits
the same ICE.

try.cc: In member function ‘void regwayobj::makebound2(regboundart&,
regboundart&)’:
try.cc:167771832:1: internal compiler error: tree check: expected ssa_name,
have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2745
0x128a0ba tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/rearnsha/gnusrc/gcc/trunk/gcc/tree.c:9255
0x6df619 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/rearnsha/gnusrc/gcc/trunk/gcc/tree.h:2770
0x10ba592 walk_aliased_vdefs_1
/home/rearnsha/gnusrc/gcc/trunk/gcc/tree-ssa-alias.c:2745
0x10ba79d walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*, tree_node*,
void*), void*, bitmap_head**, bool*)
/home/rearnsha/gnusrc/gcc/trunk/gcc/tree-ssa-alias.c:2797
0xd667a8 parm_ref_data_preserved_p
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-prop.c:992
0xd66c66 ipa_load_from_parm_agg_1
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-prop.c:1104
0xd66d02 ipa_load_from_parm_agg(ipa_node_params*, gimple_statement_base*,
tree_node*, int*, long*, bool*)
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-prop.c:1124
0xd5088a unmodified_parm_or_parm_agg_item
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-inline-analysis.c:1621
0xd522f2 will_be_nonconstant_predicate
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-inline-analysis.c:2082
0xd54519 estimate_function_body_sizes
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-inline-analysis.c:2701
0xd55746 compute_inline_parameters(cgraph_node*, bool)
/home/rearnsha/gnusrc/gcc/trunk/gcc/ipa-inline-analysis.c:2954
0x1766e45 early_inline
/home/rearnsha/gnusrc/gcc/trunk/gcc/auto-profile.c:1549
0x1766f90 auto_profile
/home/rearnsha/gnusrc/gcc/trunk/gcc/auto-profile.c:1613
0x17671ce execute
/home/rearnsha/gnusrc/gcc/trunk/gcc/auto-profile.c:1716
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/64515] Segmentation fault during linker operation in gcc for arm-none-eabi

2015-01-14 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64515

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Marek Polacek  ---
Let's close this.


[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.

2015-01-14 Thread cameron314 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161

Cameron  changed:

   What|Removed |Added

 CC||cameron314 at gmail dot com

--- Comment #12 from Cameron  ---
VS2013 accepts this too.


[Bug c/64509] _Generic throws error in unselected generic association

2015-01-14 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64509

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Marek Polacek  ---
(In reply to Martien de Jong from comment #4)
> BTW, I notice that
> 
> ./gcc/ginclude/tgmath.h
> 
> uses
> 
> __builtin_classify_type
> __builtin_types_compatible_p
> __builtin_choose_expr
> 
> Will it move to using _Generic() ?

I think it will over time (with a proper __GNUC_PREREQ guard).

Anyway, there is nothing to do for this bug, so closing.


[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.

2015-01-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161

--- Comment #13 from Jonathan Wakely  ---
EDG gives the same error as GCC


[Bug go/64595] cgo installed into wrong directory

2015-01-14 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #4 from Ian Lance Taylor  ---
To invoke cgo, put this code in a file foo.go and type "go run foo.go" (or "go
build foo.go && ./foo").


package main

// #include 
// void cprintln(const char *s) { puts(s); }
import "C"

func main() {
C.cprintln(C.CString("Hello, world"))
}


[Bug fortran/64528] [5 Regression] ICE: in process_constraint, at tree-ssa-structalias.c:3002 with -O -fno-tree-ccp -fno-tree-dce

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64528

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.


[Bug middle-end/64415] [5 Regression] ICE: verify_ssa failed / segmentation fault with LTO

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64415

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
*** Bug 64498 has been marked as a duplicate of this bug. ***


[Bug middle-end/64498] [5 Regression] Cannot build Firefox with LTO: ICE in substitute_and_fold_dom_walker::before_dom_children

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64498

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Richard Biener  ---
Should be fixed now.

*** This bug has been marked as a duplicate of bug 64415 ***


[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353

--- Comment #6 from Richard Biener  ---
Note the testcase is bogus because xx is clearly loading from global memory and
thus should be pure only.

Of course we should still not ICE here and treat xx as if it were const.

One possibility is to simply never apply IPA SRA to const functions.

Note that we will miscompile things if you change C::i to

void C::i()
{
  x = 1;
  if (xx())
   x = 0;
}

and you add noinline to xx.  sinking will then sink the x = 1 store
to the else arm (because of the bogus const attribute).


[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)

2015-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340

--- Comment #4 from Richard Biener  ---
ISTR that preloading pid_t was necessary for ada (basically all types required
from some builtins are required to be preloaded).


[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-01-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Can this be closed now?


[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986

2015-01-14 Thread enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353

--- Comment #7 from Ilya Enkovich  ---
Right, wrong const attribute causes no VUSE for calls to the function which
leads to # VUSE <.MEM> generated for added loads and requires SSA update.

We may actually call update_ssa only in case of missing VUSE still allowing
optimization for functions wrongly marked as const.


[Bug target/64460] ARM ICE on valid code

2015-01-14 Thread joel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460

Joel Sherrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Joel Sherrill  ---
(In reply to ktkachov from comment #11)
> Joel, can you try trunk after this commit to confirm that it fixes the ICE
> on your end and close this off if ok?

Based on today's results, I am closing this one. The following shows my
compiler version and compiling the original test case.

Thanks.

$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 5.0.0 20150114 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$  ~/test-gcc/install-head/bin/arm-rtems4.11-gcc -mcpu=xscale -Os -c
/tmp/gumstix.c 
$  ~/test-gcc/install-head/bin/arm-rtems4.11-gcc -mcpu=xscale -O2 -c
/tmp/gumstix.c


[Bug middle-end/64498] [5 Regression] Cannot build Firefox with LTO: ICE in substitute_and_fold_dom_walker::before_dom_children

2015-01-14 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64498

--- Comment #6 from Martin Liška  ---
(In reply to Richard Biener from comment #5)
> Should be fixed now.
> 
> *** This bug has been marked as a duplicate of bug 64415 ***

I can confirm that it works for me.

Thanks,
Martin

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

2015-01-14 Thread cbaylis at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #6 from cbaylis at gcc dot gnu.org ---
There is still a lot to do. I have patches in progress for Aarch64 loads and
stores. Aarch64 shifts still need doing, and everything for ARM.


[Bug middle-end/64592] [5 regression] tramp3d EH unwind tables are 50% bigger with mainline compared to GCC 4.9

2015-01-14 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592

--- Comment #2 from Jan Hubicka  ---
> accumulate-outgoing-args default setting change?
Nope, 4.9 already had -mno-accumulate-outgoing-args with -Os.


[Bug ipa/64545] failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693

2015-01-14 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545

--- Comment #8 from Jan Hubicka  ---
Curious it happens only with FDO... I am looking into that now.


[Bug target/62066] config/arm/arm.c:25298: possible missing call to va_end ?

2015-01-14 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62066

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-14
 CC||ktkachov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'll fix it up when I get some time.


[Bug middle-end/64592] [5 regression] tramp3d EH unwind tables are 50% bigger with mainline compared to GCC 4.9

2015-01-14 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592

--- Comment #3 from Jan Hubicka  ---
With help of Jakub we managed to figure out that on my setup it is because GCC
5.0 defaults to no .cfi directives, while GCC 4.9 uses them.
This seems to be because cfi working advance test, but we do not see ho this
test changed recently.

It may be helpful to update binutils on tester machines at opensuse.org


[Bug sanitizer/64350] TSAN fails after stress-testing for a while

2015-01-14 Thread bernd.edlinger at hotmail dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bernd Edlinger  ---
fixed by r219545


[Bug libgcc/64598] New: var-tracking.c has internal compiler error

2015-01-14 Thread hayder.alkhalissi at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598

Bug ID: 64598
   Summary: var-tracking.c has internal compiler error
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hayder.alkhalissi at googlemail dot com


[Bug libgcc/64598] var-tracking.c has internal compiler error

2015-01-14 Thread hayder.alkhalissi at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598

--- Comment #1 from hayder.alkhalissi at googlemail dot com ---
Hi,

I am trying to create cross compiler by using gcc-4.9.1.
During the procdure, I got this error:

/crosstool-ng-1.20.0/.build/src/gcc-4.9.1/gcc/var-tracking.c:5824:1: internal
compiler error: Segmentation fault

Could you please help me ?

Thanks in advance


[Bug libgcc/64598] var-tracking.c has internal compiler error

2015-01-14 Thread hayder.alkhalissi at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598

--- Comment #2 from hayder.alkhalissi at googlemail dot com ---
Created attachment 34447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34447&action=edit
Screen shot


[Bug libgcc/64598] var-tracking.c has internal compiler error

2015-01-14 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598

--- Comment #3 from Andrew Pinski  ---
What options are you using to configure GCC?  What target are you trying to
compile for?  What version of GCC are you starting with?


[Bug libgcc/64598] var-tracking.c has internal compiler error

2015-01-14 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-01-14
 Ever confirmed|0   |1


  1   2   >