[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Dominique d'Humieres  ---
Compiling gfortran.dg/goacc/coarray.f95 with '-fcoarray=single -fopenacc' gives
now an ICE

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:23:0:

 !$acc parallel loop reduction(+:a)


internal compiler error: in lower_oacc_reductions, at omp-low.c:5437

The change occurred between revisions r231086 (no ICE) and r231131 (ICE).

[Bug c/68656] [4.9/5/6 Regression] warning about disabled var-tracking uses odd location info

2015-12-02 Thread aldot at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68656

--- Comment #2 from Bernhard Reutner-Fischer  ---
(In reply to Richard Biener from comment #1)
> Which version worked ok?  I think these warnings should simply not output

4.7.4 worked ok.
4.8.5 onward behave like current trunk a.k.a 6.0

> any location (well, as we now have per-function optimization settings such
> warning
> may apply only for certain functions...)

If it's per-function, it'd be ok to output the location, i'd say.
For file-scope it doesn't make sense to me.

thanks,

[Bug target/68634] [6 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2284 w/ -O2 -fmodulo-sched

2015-12-02 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68634

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Yeah, same issue.

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

[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes

2015-12-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Dec  2 15:08:18 2015
New Revision: 231181

URL: https://gcc.gnu.org/viewcvs?rev=231181=gcc=rev
Log:
Fix ambiguity with multiple enable_shared_from_this bases

PR libstdc++/56383
* testsuite/20_util/enable_shared_from_this/56383.cc: New.
* include/bits/shared_ptr_base.h (__enable_shared_from_this): Make
friend declaration match previous declaration of
__enable_shared_from_this_helper.
* include/bits/shared_ptr.h (enable_shared_from_this): Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/56383.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr.h
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug lto/68658] New: [6 Regression] LTO - bogus redefinition of warning

2015-12-02 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68658

Bug ID: 68658
   Summary: [6 Regression] LTO - bogus redefinition of warning
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

I have the following three-file program. Compiling it without LTO or with GCC 5
works, but with GCC 6 + LTO, I get:

g++ -O2 -flto one.cc two.cc
one.cc:3:5: error: redefinition of ‘int one::func()’
 int one::func() { return 1;}
 ^~~

one.h:3:15: note: ‘virtual int one::func()’ previously defined here
   virtual int func();
   ^~~~

one.cc: In function ‘int bar(one)’:
one.cc:5:5: error: redefinition of ‘int bar(one)’
 int bar(class one y) {
 ^~~

one.h:6:5: note: ‘int bar(one)’ previously defined here
 int bar(class one y);
 ^~~



==> one.h <==
class one {
 public:
  virtual int func();
};

int bar(class one y);

==> one.cc <==
#include "one.h"

int one::func() { return 1;}

int bar(class one y) {
  return y.func();
}

==> two.cc <==
#include "one.h"

int main() {
  class one x;
  return bar(x);
}

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

2015-12-02 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620

--- Comment #1 from Christophe Lyon  ---
The problem happens when trying to extract subregs from V4HF.

On big-endian, CANNOT_CHANGE_MODE_CLASS returns 1, which at some point makes
xpart = operand_subword (x, i, 1, mode); (in emit_move_multi_word)
return NULL in xpart, later trigging the assert.

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

2015-12-02 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657

Tobias Burnus  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
Due to commit r228094 (2015-09-24), which started checking using CL_WARNING.

[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
We ICE on this assert:
  gcc_assert (TREE_CODE (arg) == PARM_DECL && POINTER_TYPE_P (TREE_TYPE
(arg)));
because the type of arg is OFFSET_TYPE.  Which is--in tree.def--described as "a
pointer relative to an object".  So I guess we should allow OFFSET_TYPEs like
this:
--- gcc/tree.c
+++ gcc/tree.c
@@ -13850,7 +13850,9 @@ nonnull_arg_p (const_tree arg)
   tree t, attrs, fntype;
   unsigned HOST_WIDE_INT arg_num;

-  gcc_assert (TREE_CODE (arg) == PARM_DECL && POINTER_TYPE_P (TREE_TYPE
(arg)));
+  gcc_assert (TREE_CODE (arg) == PARM_DECL
+ && (POINTER_TYPE_P (TREE_TYPE (arg))
+ || TREE_CODE (TREE_TYPE (arg)) == OFFSET_TYPE));

   /* The static chain decl is always non null.  */
   if (arg == cfun->static_chain_decl)

[Bug tree-optimization/68599] [6 Regression] gcc.dg/tree-ssa/pr45122.c and tree-vrp.c

2015-12-02 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68599

--- Comment #4 from Jeffrey A. Law  ---
Patch posted, waiting on review.

[Bug c/68193] _Generic -Woverflow false alarm

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193

--- Comment #3 from Marek Polacek  ---
I think some kind of delayed warning could help (so parse expressions and print
possible warnings to some "printer" and then print warnings from this "printer"
only for the association that matched).  Because of "default:" selectors we
can't parse just the one that matches.

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

2015-12-02 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0

--- Comment #1 from Tobias Burnus  ---
Seems as if "Warning" is missing in the second line of the *.opt.

Also affected seem to be:

c-family/c.opt:Wpsabi
c-family/c.opt-C ObjC C++ ObjC++ LTO Var(warn_psabi) Init(1) Undocumented
LangEnabledBy(C ObjC C++ ObjC++,Wabi)

c-family/c.opt:Wfloat-conversion
c-family/c.opt-C ObjC C++ ObjC++ Var(warn_float_conversion) LangEnabledBy(C
ObjC C++ ObjC++,Wconversion)

java/lang.opt:Wdeprecated
java/lang.opt-Java Var(warn_deprecated)

java/lang.opt:Wextraneous-semicolon
java/lang.opt-Java Var(flag_extraneous_semicolon)

java/lang.opt:Wout-of-date
java/lang.opt-Java Var(flag_newer) Init(1)

java/lang.opt:Wredundant-modifiers
java/lang.opt-Java Var(flag_redundant)

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread cesar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

cesar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cesar at gcc dot gnu.org

--- Comment #10 from cesar at gcc dot gnu.org ---
Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I
don't think this test case is valid anymore. 

Basically, this test is trying to preform a reduction on a coarrray. Unlike
openmp, openacc does not support array reductions. In fact, if you convert 'a'
to a regular array, it would also cause an ICE.

One of the solutions I was considering was to error if any array variables are
used in as reduction variables. But I was thinking that would be too
conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the
reduction is specifically operating on var element 1.

The problem I came across here is that reductions on array elements in openmp
are rejected as errors and I not sure why. I spent some time looking at it, but
I kept on getting preempted by other tasks. This may be the case where the
behavior of reductions in openmp diverges from openacc. 

With that in mind, I'm not sure why the ICE was exposed all of the sudden. My
changes mostly updated the way that gang is parsed and how clauses in combined
constructs are split. It looks like a sorry disappeared because the ICE occurs
in omp-low.c.

[Bug preprocessor/57580] Repeated _Pragma message directives in macro causes problems

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57580

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-02
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
Created attachment 36889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36889=edit
gcc6-pr57580.patch

It is only broken if you do -save-temps, or use say ccache that does it for you
under the hood.

[Bug c/68657] New: [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

2015-12-02 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657

Bug ID: 68657
   Summary: [6 Regression] "gcc -Werror=sign-conversion test.i"
shows invalid: -Wsign-conversion is not an option that
controls warnings
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Using  touch test.ii test.i  with
  gcc -Werror=sign-conversion test.i
or
  g++ -Werror=sign-conversion test.i
shows:

cc1plus: error: -Werror=sign-conversion: -Wsign-conversion is not an option
that controls warnings


Using GCC 5 it works.

In  gcc/c-family/c.opt, one has:

Wsign-conversion
C ObjC C++ ObjC++ Var(warn_sign_conversion) LangEnabledBy(C ObjC,Wconversion)
Warn for implicit type conversions between signed and unsigned integers.

[Bug tree-optimization/68659] New: [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

2015-12-02 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659

Bug ID: 68659
   Summary: [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c
(internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -O2
-fgraphite-identity  -S -m32 -o id-pr45230-1.s
../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function ‘main’:
../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal compiler error:
Segmentation fault
 main ()
 ^~~~

0x106e622b crash_signal
../../gcc/toplev.c:334
0x107ec79c copy_prop_visit_phi_node
../../gcc/tree-ssa-copy.c:349
0x10868f2b simulate_stmt
../../gcc/tree-ssa-propagate.c:327
0x1086a327 simulate_block
../../gcc/tree-ssa-propagate.c:483
0x1086a327 ssa_propagate(ssa_prop_result (*)(gimple*, edge_def**, tree_node**),
ssa_prop_result (*)(gphi*))
../../gcc/tree-ssa-propagate.c:926
0x107ebbd3 execute_copy_prop
../../gcc/tree-ssa-copy.c:605
0x107ebbd3 execute
../../gcc/tree-ssa-copy.c:636

a94f1e5b00dee567897c91cdadb16dc46f3911e0 is the first bad commit

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231097
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug gcov-profile/68603] [6 Regression] FAIL: g++.dg/gcov/gcov-1.C

2015-12-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68603

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug web/68660] "5.2" instead of "5.3" on the main page at https://gcc.gnu.org/

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68660

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Why?  5.3 has not been released yet.

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux

2015-12-02 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #59 from Christophe Lyon  ---
I think this can be closed.

[Bug libfortran/68652] gamma function hangs on some arguments, returns NaN on other ones

2015-12-02 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68652

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Also works for me on Linux.

[Bug target/68655] SSE2 cannot vec_perm of low and high part

2015-12-02 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655

Uroš Bizjak  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Uroš Bizjak  ---
CC Jakub.

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

2015-12-02 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67778

Segher Boessenkool  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #13 from Segher Boessenkool  ---
*** Bug 68634 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

2015-12-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654

--- Comment #5 from Richard Biener  ---
Interesting the only effect could be different GC allocation pattern because
the non-splice variant may end up re-allocating the target vector multiple
times.  But this alone should never change code generation.

So - can you share a preprocessed file where code generation changes with
this revision?

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

2015-12-02 Thread afomin.mailbox at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654

--- Comment #4 from Alexander Fomin  ---
It should, but for some reason we see a stable reproducible degradation between
r228667 and r228668...

[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero

2015-12-02 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #13 from Jeffrey A. Law  ---
I wouldn't lose any sleep if init-regs.c disappeared.

The comment about the ARM ISA being unable to encode certain cases isn't a
strong case in my mind to do something like init-regs.c.  We've dealt with
similar problems in other ports -- you just have to get creative in other ways.
 I can recall dealing with ports that couldn't encode a nop-move for example.

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

--- Comment #11 from Thomas Schwinge  ---
(In reply to cesar from comment #10)
> Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I
> don't think this test case is valid anymore. 

But still shouldn't result in an ICE.

> Basically, this test is trying to preform a reduction on a coarrray. Unlike
> openmp, openacc does not support array reductions. In fact, if you convert
> 'a' to a regular array, it would also cause an ICE.

Should possibly be rejected with an appropriate error diagnostic, but not cause
an ICE.

> One of the solutions I was considering was to error if any array variables
> are used in as reduction variables. But I was thinking that would be too
> conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the
> reduction is specifically operating on var element 1.

Hmm, but is that useful enough to consider this special case?

> The problem I came across here is that reductions on array elements in
> openmp are rejected as errors and I not sure why. I spent some time looking
> at it, but I kept on getting preempted by other tasks. This may be the case
> where the behavior of reductions in openmp diverges from openacc. 
> 
> With that in mind, I'm not sure why the ICE was exposed all of the sudden.
> My changes mostly updated the way that gang is parsed and how clauses in
> combined constructs are split. It looks like a sorry disappeared because the
> ICE occurs in omp-low.c.

Quite right ("sorry disappeared"; see
.

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jules at gcc dot gnu.org

--- Comment #9 from Dominique d'Humieres  ---
> The change occurred between revisions r231086 (no ICE) and r231131 (ICE).

Reduced range from https://gcc.gnu.org/ml/gcc-regression/2015-12/

r231109 (no ICE), r231121 (ICE), likely r231112 or r231118.

[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes

2015-12-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|5.3 |4.9.4

--- Comment #3 from Jonathan Wakely  ---
I'm about to fix this on trunk, and will backport to the branches after 5.3 is
released.

[Bug lto/68658] [6 Regression] LTO - bogus redefinition of warning

2015-12-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68658

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

2015-12-02 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-02
 CC||spop at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin14 with -m32, but not with -m64. No ICE with
r231086, r231131 gives

/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function
'main':
/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: error:
missing PHI def
 main ()
 ^~~~

/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: error:
missing PHI def
p1_14 = PHI <(28), (33)>
/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal
compiler error: verify_gimple failed

/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal
compiler error: Abort trap: 6

and r231168 (configured with --enable-checking=release)

/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function
'main':
/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal
compiler error: Segmentation fault: 11
 main ()
 ^~~~


/opt/gcc/_clean/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal
compiler error: Abort trap: 6

[Bug lto/68658] [6 Regression] LTO - bogus redefinition of warning

2015-12-02 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68658

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  ---
Close as INVALID.

I had an accidentally generated and outdated .gch lying around - which
seemingly got included. - Works after removing it.

[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32

2015-12-02 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636

--- Comment #2 from Jan Smets  ---
The vreg pass is different

OLD

ode_label 16 9 17 6 2 "" [1 uses])
(note 17 16 18 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 18 17 0 6 (set (mem/v:SI (reg/f:SI 194 [ iftmp$0 ]) [2 *iftmp$0_1+0 S4
A32])
(const_int 0 [0])) test.c:5 281 {*movsi_internal}
 (nil))


NEW

(note 17 16 18 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 18 17 19 6 (set (mem/v:BLK (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S4 A8])
(unspec:BLK [
(const_int 0 [0])
(mem/v:QI (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S1 A8])
] UNSPEC_STORE_LEFT)) test2.c:5 276 {mov_swl}
 (nil))
(insn 19 18 0 6 (set (mem/v:BLK (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S4 A8])
(unspec:BLK [
(const_int 0 [0])
(mem/v:QI (plus:SI (reg/f:SI 194 [ D.1495 ])
(const_int 3 [0x3])) [1 *_1+3 S1 A8])
(mem/v:BLK (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S4 A8])
] UNSPEC_STORE_RIGHT)) test2.c:5 278 {mov_swr}
 (nil))


I'm not sure how to proceed from here.

Thanks

[Bug web/68660] New: "5.2" instead of "5.3" on the main page at https://gcc.gnu.org/

2015-12-02 Thread leo at yuriev dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68660

Bug ID: 68660
   Summary: "5.2" instead of "5.3" on the main page at
https://gcc.gnu.org/
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leo at yuriev dot ru
  Target Milestone: ---

"Release Series and Status" on the top of https://gcc.gnu.org/

- now see "GCC 5.2 (changes)" 
- but should be "GCC 5.3 (changes)"

[Bug c/68637] Array of function pointers with attribute leads to wrong code

2015-12-02 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68637

--- Comment #3 from H.J. Lu  ---
Run-time test:

[hjl@gnu-6 pr68637]$ cat x.i
extern void (*bar[]) (int, int) __attribute__ ((regparm (2)));

void
foo (void)
{
  bar[0] (1, 2);
}
[hjl@gnu-6 pr68637]$ cat main.i
static void 
__attribute__ ((regparm (2)))
bar0 (int i, int j)
{
  if (i != 1 || j != 2)
__builtin_abort ();
}

typedef void (*func_t) (int, int) __attribute__ ((regparm (2)));

func_t bar[] =
{
  bar0,
};

extern void foo (void);

int
main ()
{
  foo ();
  return 0;
}
[hjl@gnu-6 pr68637]$ make CC=gcc x
gcc -O2 -m32 -S -o x.s x.i
x.i:1:1: warning: ‘regparm’ attribute only applies to function types
[-Wattributes]
 extern void (*bar[]) (int, int) __attribute__ ((regparm (2)));
 ^
gcc -O2 -m32 -S -o main.s main.i
gcc -O2 -m32 -o x x.s main.s
[hjl@gnu-6 pr68637]$ ./x
Aborted
[hjl@gnu-6 pr68637]$

[Bug target/68655] SSE2 cannot vec_perm of low and high part

2015-12-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655

--- Comment #1 from Richard Biener  ---
typedef int v4si __attribute__((vector_size(16)));

v4si bar (v4si a, v4si b)
{
  return __builtin_shuffle (a, b, (v4si) { 0, 1, 4, 5 });
}

works just fine using shufps.

It might be that the generic optabs code should try using larger element modes
if the permutation allows that.  It already tries QImode as fallback.

OTOH as

v8hi baz (v8hi a, v8hi b)
{
  return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 12, 13, 14, 15 });
}

works and uses shufpd the x86 backend seems to be somewhat prepared for
the above.

[Bug web/68660] "5.2" instead of "5.3" on the main page at https://gcc.gnu.org/

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68660

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
What will become 5.3 is called 5.2.1 now.  Furthermore, we've been listing the
last released version from that branch there for many years this way, it is not
something new.

[Bug c/68162] [5 Regression] Incompatible pointer type using a typedef

2015-12-02 Thread jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

Joseph S. Myers  changed:

   What|Removed |Added

Summary|[5/6 Regression]|[5 Regression] Incompatible
   |Incompatible pointer type   |pointer type using a
   |using a typedef |typedef

--- Comment #16 from Joseph S. Myers  ---
Fixed for GCC 6.

[Bug c++/68290] g++.dg/concepts/auto1.C FAILs

2015-12-02 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Dec  2 16:41:02 2015
New Revision: 231189

URL: https://gcc.gnu.org/viewcvs?rev=231189=gcc=rev
Log:
PR c++/68290
* constraint.cc (make_constrained_auto): Move to...
* pt.c (make_auto_1): Add set_canonical parameter and set
TYPE_CANONICAL on the type only if it is true.
(make_decltype_auto): Adjust call to make_auto_1.
(make_auto): Likewise.
(splice_late_return_type): Likewise.
(make_constrained_auto): ...here.  Call make_auto_1 instead of
make_auto and pass false.  Set TYPE_CANONICAL directly.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constraint.cc
trunk/gcc/cp/pt.c

[Bug ipa/65654] [7 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO

2015-12-02 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654

--- Comment #8 from Jan Hubicka  ---
> It was made P1 to make you fix it during stage1 of GCC 6 ;)
Yep, I even made patch in last P3 for turning to sreals, but then did not have
time to pull it out.
I will look it up - it needed some changes to gengtype because it fails on
classes with certain
operators.

Those stages1 are too short...

Honza

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

2015-12-02 Thread jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162

--- Comment #15 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Dec  2 18:24:23 2015
New Revision: 231194

URL: https://gcc.gnu.org/viewcvs?rev=231194=gcc=rev
Log:
Fix TYPE_MAIN_VARIANT construction for arrays of qualified typedefs (PR
c/68162).

PR c/68162 reports a spurious warning about incompatible types
involving arrays of const double, constructed in one place using a
typedef for const double and in another place literally using const
double.

The problem is that the array of the typedef was incorrectly
constructed without a TYPE_MAIN_VARIANT being an array of unqualified
elements as it should be (though it seems some more recent change
resulted in this producing incorrect diagnostics, likely the support
for C++-style handling of arrays of qualified type).  This patch fixes
the logic in grokdeclarator to determine first_non_attr_kind, which is
used to determine whether it is necessary to use the TYPE_MAIN_VARIANT
of the type in the declaration specifiers.

However, fixing that logic introduces a failure of
gcc.dg/debug/dwarf2/pr47939-4.c, a test introduced along with
first_non_attr_kind.  Thus, it is necessary to track the original
qualified typedef when qualifying an array type, to use it rather than
a newly-constructed type, to avoid regressing regarding typedef names
in debug info.  This is done along lines I suggested in
: track the
original type and the number of levels of array indirection at which
it appears, and, in possibly affected cases, pass extra arguments to
c_build_qualified_type (with default arguments to avoid needing to
pass those extra arguments explicitly everywhere).  Given Richard's
recent fix to dwarf2out.c, this allows the C bug to be fixed without
causing debug information regressions.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/c:
PR c/68162
* c-decl.c (grokdeclarator): Set first_non_attr_kind before
following link from declarator to next declarator.  Track original
qualified type and pass it to c_build_qualified_type.
* c-typeck.c (c_build_qualified_type): Add arguments
orig_qual_type and orig_qual_indirect.

gcc/c-family:
PR c/68162
* c-common.h (c_build_qualified_type): Add extra default
arguments.

gcc/cp:
PR c/68162
* tree.c (c_build_qualified_type): Add extra arguments.

gcc/testsuite:
PR c/68162
* gcc.dg/pr68162-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68162-1.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68193] _Generic -Woverflow false alarm

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193

--- Comment #5 from Marek Polacek  ---
Yes, so this would be somehow tied to c_inhibit_evaluation_warnings as in we
warn for
  0 ? foo () : 2;
if foo() wasn't declared but not for the div-by-zero here:
  0 ? 1 / 0 : 2;

[Bug c/64868] C front-end rejects valid syntax.

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug preprocessor/68638] [6 Regression] ICE in linemap_macro_map_lookup

2015-12-02 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I was planning to investigate this today -- you beat me to it :)
You're right, today's trunk compiles the test case just fine.  Closing as
fixed.

[Bug c/68193] _Generic -Woverflow false alarm

2015-12-02 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193

--- Comment #4 from joseph at codesourcery dot com  ---
I agree delaying warnings would help, but you'd need to distinguish 
warnings relating to execution of the code that should be disabled in 
unevaluated code from warnings that should always be present (which 
include but aren't limited to pedwarns).  For example, you shouldn't lose 
a diagnostic for an implicit function declaration just because it's in an 
unevaluated _Generic selection.

[Bug tree-optimization/68550] [6 Regression] ICE: verify_gimple failed Error: missing PHI def

2015-12-02 Thread Joost.VandeVondele at mat dot ethz.ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68550

--- Comment #2 from Joost VandeVondele  
---

The following simpler looking testcase fails at -O1:

> cat bug.f90
SUBROUTINE PD2VAL(RES,NDERIV,TG1,TG2,C0)
INTEGER, PARAMETER :: dp=8
REAL(KIND=dp), INTENT(OUT)  :: res(*)
REAL(KIND=dp), INTENT(IN)   :: TG1, TG2, C0(105,*)
REAL(KIND=dp)   :: T1(0:13), T2(0:13)
 DO K=1,NDERIV+1
  RES(K)=RES(K)+DOT_PRODUCT(T1(0:7),C0(70:77,K))*T2(6)
  RES(K)=RES(K)+DOT_PRODUCT(T1(0:4),C0(91:95,K))*T2(9)
  RES(K)=RES(K)+DOT_PRODUCT(T1(0:3),C0(96:99,K))*T2(10)
 ENDDO
END SUBROUTINE PD2VAL

> gfortran  -O1 -fcheck=bounds -floop-nest-optimize bug.f90
bug.f90:1:0:

 SUBROUTINE PD2VAL(RES,NDERIV,TG1,TG2,C0)


Error: missing PHI def
val.0_68 = PHI <(4), 0.0(6)>
bug.f90:1:0: internal compiler error: verify_gimple failed
0xbad719 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5082

[Bug tree-optimization/68550] [6 Regression] ICE: verify_gimple failed Error: missing PHI def

2015-12-02 Thread spop at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68550

Sebastian Pop  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |spop at gcc dot gnu.org

--- Comment #3 from Sebastian Pop  ---
Looking at it.  Thanks for the nice reduced testcases.

[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #3 from Marek Polacek  ---
Patch posted.

[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

2015-12-02 Thread huguesdelassus at hotmail dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415

Hugues de Lassus  changed:

   What|Removed |Added

 CC||huguesdelassus at hotmail dot 
fr

--- Comment #13 from Hugues de Lassus  ---
For me it affects gcc 5.2.0 compiled for native target x86_64-unknown-linux-gnu
as well.

[Bug tree-optimization/63914] [4.9 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:517

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63914

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE in set_lattice_value,   |[4.9 Regression] ICE in
   |at tree-ssa-ccp.c:517   |set_lattice_value, at
   ||tree-ssa-ccp.c:517

--- Comment #6 from Marek Polacek  ---
Fixed for 5/6, still ICEs with 4.9.

[Bug c++/68290] g++.dg/concepts/auto1.C FAILs

2015-12-02 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
.

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread cesar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

--- Comment #12 from cesar at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #11)
> (In reply to cesar from comment #10)
> > Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I
> > don't think this test case is valid anymore. 
> 
> But still shouldn't result in an ICE.

I agree.

> > Basically, this test is trying to preform a reduction on a coarrray. Unlike
> > openmp, openacc does not support array reductions. In fact, if you convert
> > 'a' to a regular array, it would also cause an ICE.
> 
> Should possibly be rejected with an appropriate error diagnostic, but not
> cause an ICE.

Yeah, I know. I was just raising this as a known issue that I'm working on.

> > One of the solutions I was considering was to error if any array variables
> > are used in as reduction variables. But I was thinking that would be too
> > conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the
> > reduction is specifically operating on var element 1.
> 
> Hmm, but is that useful enough to consider this special case?

Probably. Besides it also affects the c and c++ front ends. 

> > The problem I came across here is that reductions on array elements in
> > openmp are rejected as errors and I not sure why. I spent some time looking
> > at it, but I kept on getting preempted by other tasks. This may be the case
> > where the behavior of reductions in openmp diverges from openacc. 
> > 
> > With that in mind, I'm not sure why the ICE was exposed all of the sudden.
> > My changes mostly updated the way that gang is parsed and how clauses in
> > combined constructs are split. It looks like a sorry disappeared because the
> > ICE occurs in omp-low.c.
> 
> Quite right ("sorry disappeared"; see
>  schwinge.homeip.net%3E>.

Ok. I'm testing a patch which teaches the fortran front end to error on any
type of array reductions. It's a little bit conservative because it doesn't
permit reductions on array elements yet. But at least it doesn't ICE. If you
want, I can take a look at those gimplifier changes once I'm done with this.
Otherwise, I still need to work on the c++ routine error messages.

[Bug target/68661] New: __attribute__ ((no_caller_saved_registers)) trashes stack

2015-12-02 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68661

Bug ID: 68661
   Summary: __attribute__ ((no_caller_saved_registers)) trashes
stack
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: vaalfreja at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 no-caller-saved-2]$ cat x.i 
extern void bar0 (int, int) __attribute__ ((no_caller_saved_registers));

void
foo (void)
{
  bar0 (1, 2);
}
[hjl@gnu-6 no-caller-saved-2]$ cat main.i
void 
__attribute__ ((no_caller_saved_registers))
bar0 (int i, int j)
{
  if (i != 1)
__builtin_abort ();

  if (j != 2)
__builtin_abort ();
}

extern void foo (void);

int
main ()
{
  foo ();
  return 0;
}
[hjl@gnu-6 no-caller-saved-2]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -Og -g -m32 -S -o x.s x.i
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -Og -g -m32 -S -o main.s
main.i
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -Og -g -m32 -o x x.s main.s
./x
Makefile:12: recipe for target 'all' failed
make: *** [all] Aborted
[hjl@gnu-6 no-caller-saved-2]$

[Bug web/68660] "5.2" instead of "5.3" on the main page at https://gcc.gnu.org/

2015-12-02 Thread leo at yuriev dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68660

--- Comment #2 from Leo Yuriev  ---
Hm, it is a devel-status of 5.3, not 5.2

[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug lto/68662] New: [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

2015-12-02 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662

Bug ID: 68662
   Summary: [6 regression] FAIL: gcc.dg/lto/20090210
c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto
-flto-partition=none -fuse-linker-plugin
-fno-fat-lto-objects
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-*-*

$ gcc/xgcc -Bgcc/ -O2 -flto -flto-partition=none -fuse-linker-plugin
-fno-fat-lto-objects -c -m32 -o c_lto_20090210_0.o
../gcc/testsuite/gcc.dg/lto/20090210_0.c
$ gcc/xgcc -Bgcc/ -O2 -flto -flto-partition=none -fuse-linker-plugin
-fno-fat-lto-objects -fPIC -c -m32 -o c_lto_20090210_1.o
../gcc/testsuite/gcc.dg/lto/20090210_1.c
$ gcc/xgcc -Bgcc/ c_lto_20090210_0.o c_lto_20090210_1.o -O2 -flto
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects -m32 -o
gcc-dg-lto-20090210-11.exe -save-temps
c_lto_20090210_0.s: Assembler messages:
c_lto_20090210_0.s:30: Error: syntax error; end of line, expected `('
lto-wrapper: fatal error: gcc/xgcc returned 1 exit status
compilation terminated.
/usr/powerpc64-suse-linux/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ tail -n +30 c_lto_20090210_0.s | head -n 1
lwz 28,.LC0-(30)

4c4a180dae54e5a879c76015b3ed181283190872 is the first bad commit
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230915
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread cesar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

cesar at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from cesar at gcc dot gnu.org ---
Fixed in r231204. Array reductions aren't supported in OpenACC 2.0. So now the
fortran front end generates error when it encounters such a reduction.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

2015-12-02 Thread bugzilla-gcc at thewrittenword dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919

--- Comment #19 from The Written Word  
---
The latest linker patch for HP-UX 11.23/IA is PHSS_44401 and the latest for
HP-UX 11.31/IA is PHSS_44402. Both are dated 2015/10/24.

[Bug middle-end/65534] tailcall not optimized away

2015-12-02 Thread aldot at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534

--- Comment #3 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #2)
> (In reply to Jan Hubicka from comment #1)
> > > #ifndef OPTIMIZE_MANUALLY
> > > void setutent(void) {
> > > ((void)0);
> > > __setutent_unlocked();
> > > ((void)0);
> > > }
> > > #else
> > > extern __typeof (__setutent_unlocked) setutent
> > > __attribute__ ((alias ("__setutent_unlocked")));
> > > #endif
> > 
> > I do not think GCC can safely optimize this, becuase in the first
> > case  != &__setutent_unlocked, wile in the optimized
> > case the addresses are equal.
> 
> Note that __setutent_unlocked is static, so i don't see how this specific
> case would prevent optimization?

gcc-6 stage1 passed.
Honza, please explain how'd that prevent optimization?

[Bug lto/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

2015-12-02 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662

Andreas Schwab  changed:

   What|Removed |Added

 Blocks||67548
   Target Milestone|--- |6.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
[Bug 67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

2015-12-02 Thread cesar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

--- Comment #13 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Dec  2 19:59:27 2015
New Revision: 231204

URL: https://gcc.gnu.org/viewcvs?rev=231204=gcc=rev
Log:
gcc/fortran/
PR fortran/63861
* openmp.c (gfc_match_omp_clauses): Allow subarrays for acc reductions.
(resolve_omp_clauses): Error on any acc reductions on arrays.

gcc/testsuite/
* gfortran.dg/goacc/array-reduction.f90: New test.
* gfortran.dg/goacc/assumed.f95: Update expected diagnostics.
* gfortran.dg/goacc/coarray.f95: Likewise.
* gfortran.dg/goacc/coarray_2.f90: Likewise.
* gfortran.dg/goacc/reduction-2.f95: Likewise.
* gfortran.dg/goacc/reduction.f95: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/goacc/array-reduction.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/assumed.f95
trunk/gcc/testsuite/gfortran.dg/goacc/coarray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/coarray_2.f90
trunk/gcc/testsuite/gfortran.dg/goacc/reduction-2.f95
trunk/gcc/testsuite/gfortran.dg/goacc/reduction.f95

[Bug tree-optimization/68550] [6 Regression] ICE: verify_gimple failed Error: missing PHI def

2015-12-02 Thread spop at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68550

--- Comment #4 from Sebastian Pop  ---
Author: spop
Date: Wed Dec  2 20:40:17 2015
New Revision: 231206

URL: https://gcc.gnu.org/viewcvs?rev=231206=gcc=rev
Log:
fix PR68550: do not handle ISL loop peeled statements

In case ISL did some loop peeling, like this:

  S_8(0);
  for (int c1 = 1; c1 <= 5; c1 += 1) {
S_8(c1);
  }
  S_8(6);

we should not copy loop-phi nodes in S_8(0) or in S_8(6).

PR tree-optimization/68550
* graphite-isl-ast-to-gimple.c (copy_loop_phi_nodes): Add dump.
(copy_bb_and_scalar_dependences): Do not code generate loop peeled
statements.

* gfortran.dg/graphite/pr68550-1.f90: New.
* gfortran.dg/graphite/pr68550-2.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr68550-1.f90
trunk/gcc/testsuite/gfortran.dg/graphite/pr68550-2.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug go/66147] [5/6 Regression] go fails to cross build

2015-12-02 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.3 |6.0

--- Comment #3 from Ian Lance Taylor  ---
This should be somewhat better on trunk.  Closing tentatively, but please
reopen if you find more problems.  Thanks.

(It's also to backport to GCC 5 branch when the branch reopens.)

[Bug jit/66054] bootstrap comparison failure with --enable-host-shared

2015-12-02 Thread aldot at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66054

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug go/66147] [5/6 Regression] go fails to cross build

2015-12-02 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Dec  2 19:27:58 2015
New Revision: 231199

URL: https://gcc.gnu.org/viewcvs?rev=231199=gcc=rev
Log:
./:
PR go/66147
* Makefile.tpl (HOST_EXPORTS): Add XGCC_FLAGS_FOR_TARGET.
* Makefile.in: Regenerate.
gotools/:
PR go/66147
* Makefile.am (GOCOMPILER): In NATIVE case, add
$(XGCC_FLAGS_FOR_TARGET).

Modified:
trunk/ChangeLog
trunk/Makefile.in
trunk/Makefile.tpl
trunk/gotools/ChangeLog
trunk/gotools/Makefile.am
trunk/gotools/Makefile.in

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/66949] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu in tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66949

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #4 from Marek Polacek  ---
I'll try to figure out what's going on here.

[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for GCC 6+.

[Bug lto/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

2015-12-02 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662

--- Comment #1 from Jan Hubicka  ---
That looks like (latent?) bug in the target asm output - we should not produce
invalid asm based on visibility changes.  I will see if I can reproduce it on
gcc compile farm.

[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  2 19:39:11 2015
New Revision: 231201

URL: https://gcc.gnu.org/viewcvs?rev=231201=gcc=rev
Log:
PR target/68647
* optabs.c (expand_doubleword_popcount, expand_doubleword_parity):
New functions.
(expand_unop): Use them.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68647.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Wed Dec  2 20:01:37 2015
New Revision: 231205

URL: https://gcc.gnu.org/viewcvs?rev=231205=gcc=rev
Log:
PR c/68513
* gcc.dg/pr68513.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68513.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853

2015-12-02 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Dec  2 19:29:17 2015
New Revision: 231200

URL: https://gcc.gnu.org/viewcvs?rev=231200=gcc=rev
Log:
PR c++/68653
* tree.c (nonnull_arg_p): Allow OFFSET_TYPE.

* g++.dg/warn/nonnull3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/nonnull3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/67337] [4.9/5/6 Regression] Segmentation fault on a template class

2015-12-02 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67337

--- Comment #6 from Markus Trippelsdorf  ---
Author: trippels
Date: Wed Dec  2 19:57:55 2015
New Revision: 231203

URL: https://gcc.gnu.org/viewcvs?rev=231203=gcc=rev
Log:
Fix c++/67337 (segfault in mangle.c)

PR c++/67337
* mangle.c (write_template_prefix): Guard against context==NULL.

Added:
trunk/gcc/testsuite/g++.dg/template/pr67337.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c

[Bug c++/67337] [4.9/5 Regression] Segmentation fault on a template class

2015-12-02 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67337

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
Summary|[4.9/5/6 Regression]|[4.9/5 Regression]
   |Segmentation fault on a |Segmentation fault on a
   |template class  |template class

--- Comment #7 from Markus Trippelsdorf  ---
Fixed on trunk. Will commit backports after gcc-5.3 comes out.

[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)

2015-12-02 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 1 Dec 2015, afomin.mailbox at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800
> 
> --- Comment #5 from Alexander Fomin  ---
> Richard, are there any updates on this?
> 
> If BB vectorization support for reductions does not fit your plans for stage3,
> we'd like to fix the regression by doing a partial revert described above.

I will fix this PR in stage3 by either improving vectoirzation here
or partially reverting the commit.  Stay tuned.

[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-02
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Uroš Bizjak  ---
I'll take this.

[Bug ipa/68331] [meta-bug] fipa-pta issues

2015-12-02 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331

--- Comment #8 from rguenther at suse dot de  ---
On Tue, 1 Dec 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
> 
> --- Comment #5 from vries at gcc dot gnu.org ---
> Created attachment 36885
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36885=edit
> Abort solve_graph after num_edge passes threshold
> 
> This patch aborts solve_graph after stats.num_edges passes 4.000.000.
> 
> Using this patch, in combination with a -fipa-pta on-by-by-default patch, I'm
> able to do a no-bootstrap build and reg-test.
> 
> Test failures:
> ...
> libstdc++.sum:FAIL: experimental/filesystem/path/concat/strings.cc execution
> test
> libstdc++.sum:FAIL: experimental/filesystem/path/construct/locale.cc execution
> test
> ...

I think limiting the number of edges is somewhat odd.  I'd rather
limit the number of varinfos created initially and maybe the number
of solver iterations.

And add some statistics to the whole solving process.

Note that in theory the solver can just coalesce more vars (and thus
edges) to make the solution quicker (and more imprecise).  So giving
up completely (and wasting work already done) isn't necessary.  Of
course the result from (IPA) PTA will then be a lot less "reliable"
and reducing a testcase might end up "fixing" wrong-code bugs just
because the solution becomes more precise (or the other way around).

One has to visualize the solving process for some moderately complex
testcase as I think the cycle elimination during the solving doesn't
work reliably with the solving turning complex constraint into
edges (well, not sure).  Having unmerged direct cycles just slows
down the solving and increases the memory use for the solutions.

[Bug c++/66858] [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi

2015-12-02 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858

--- Comment #2 from Andrew Pinski  ---
This is related to maybe_retrofit_in_chrg somehow.

[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

--- Comment #4 from Jakub Jelinek  ---
I also wonder when we have expand_doubleword_clz if we couldn't handle
expand_doubleword_ctz similarly.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

2015-12-02 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432

--- Comment #16 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Dec  2 09:08:49 2015
New Revision: 231161

URL: https://gcc.gnu.org/viewcvs?rev=231161=gcc=rev
Log:
PR 68432: Add a target hook to control size/speed optab choices

The problem in the PR is that some i386 optabs FAIL when
optimising for size rather than speed.  The gimple level generally
needs access to this information before calling the generator,
so this patch adds a new hook to say whether an optab should
be used when optimising for size or speed.  It also has a "both"
option for cases where we want code that is optimised for both
size and speed.

I've passed the optab to the target hook because I think in most
cases that's more useful than the instruction code.  We could pass
both if there's a use for it though.

At the moment the match-and-simplify code doesn't have direct access
to the target block, so for now I've used "both" there.

Tested on x86_64-linux-gnu and powerpc64-linux-gnu.

gcc/
PR tree-optimization/68432
* coretypes.h (optimization_type): New enum.
* doc/tm.texi.in (TARGET_OPTAB_SUPPORTED_P): New hook.
* doc/tm.texi: Regenerate.
* target.def (optab_supported_p): New hook.
* targhooks.h (default_optab_supported_p): Declare.
* targhooks.c (default_optab_supported_p): New function.
* predict.h (function_optimization_type): Declare.
(bb_optimization_type): Likewise.
* predict.c (function_optimization_type): New function.
(bb_optimization_type): Likewise.
* optabs-query.h (convert_optab_handler): Define an overload
that takes an optimization type.
(direct_optab_handler): Likewise.
* optabs-query.c (convert_optab_handler): Likewise.
(direct_optab_handler): Likewise.
* internal-fn.h (direct_internal_fn_supported_p): Take an
optimization_type argument.
* internal-fn.c (direct_optab_supported_p): Likewise.
(multi_vector_optab_supported_p): Likewise.
(direct_internal_fn_supported_p): Likewise.
* builtins.c (replacement_internal_fn): Update call to
direct_internal_fn_supported_p.
* gimple-match-head.c (build_call_internal): Likewise.
* tree-vect-patterns.c (vect_recog_pow_pattern): Likewise.
* tree-vect-stmts.c (vectorizable_internal_function): Likewise.
* tree.c (maybe_build_call_expr_loc): Likewise.
* config/i386/i386.c (ix86_optab_supported_p): New function.
(TARGET_OPTAB_SUPPORTED_P): Define.
* config/i386/i386.md (asinxf2): Remove optimize_insn_for_size_p check.
(asin2, acosxf2, acos2, log1pxf2, log1p2)
(expNcorexf3, expxf2, exp2, exp10xf2, exp102, exp2xf2)
(exp22, expm1xf2, expm12, ldexpxf3, ldexp3)
(scalbxf3, scalb3, rint2, round2)
(xf2, 2): Likewise.

gcc/testsuite/
* gcc.target/i386/pr68432-1.c: New test.
* gcc.target/i386/pr68432-2.c: Likewise.
* gcc.target/i386/pr68432-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68432-1.c
trunk/gcc/testsuite/gcc.target/i386/pr68432-2.c
trunk/gcc/testsuite/gcc.target/i386/pr68432-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/coretypes.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/gimple-match-head.c
trunk/gcc/internal-fn.c
trunk/gcc/internal-fn.h
trunk/gcc/optabs-query.c
trunk/gcc/optabs-query.h
trunk/gcc/predict.c
trunk/gcc/predict.h
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree.c

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

2015-12-02 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #17 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug target/68651] New: [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53

2015-12-02 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68651

Bug ID: 68651
   Summary: [5/6 Regression][AArch64] Missing combination of
shift-by-one with other arithmetic patterns with
-mcpu=cortex-a53
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

Consider the testcases:

int
foo (int x)
{
  return (x * 2) & 65535;
}

int
bar (int x, int y)
{
  return (x * 2) | y;
}

With GCC 4.9 for aarch64 with -O2 -mcpu=cortex-a53 we generated:
foo:
ubfiz   w0, w0, 1, 15
ret

bar:
orr w0, w1, w0, lsl 1
ret

whereas with GCC 5 and trunk we fail to combine:
foo:
add w0, w0, w0
uxthw0, w0
ret

bar:
add w0, w0, w0
orr w0, w0, w1
ret

This is because of updated costs information for cortex-a53 which leads to
x * 2 being expanded as x + x rather than x << 1 and combine can't merge the
PLUS form.

This can be fixed simply by mutating the pattern during recog_for_combine in a
similar way to change_zero_ext

[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0

2015-12-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640

--- Comment #1 from Richard Biener  ---
Is it used because it ends up in the static chain of the omp_fn and uses the
same (original) qualifiers?  And the static chain itself is passed "by
reference"
and thus gets its fields looked at and restrict extracted.

int
foo (int *__restrict__ ap)
{
  int *bp = ap;
#pragma omp parallel for
  for (unsigned int idx = 0; idx < N; idx++)
ap[idx] = bp[idx];
}

I believe this testcase is invalid as you access *ap through bp which is
not based on ap.

But your point is that "based on" is not properly passed through the
OMP lowering which will split out the use into a separate function
thus violating the constraints we set for restrict in PTA (_only_
derive it from parameters because their scope is fixed).

This would mean you need to drop restrict qualifiers for any pointers
you "leak" to the static chain (in the static chain field-decls type).

Yes, if we fix visit_loadstore for

  /* ???  We need to make sure 'ptr' doesn't include any of
 the restrict tags we added bases for in its points-to set.  */
  return false;

you may be able to create a miscompile here (if you manage to create a
valid testcase in the first place)

[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 36888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36888=edit
gcc6-pr68647.patch

Untested fix.


[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

--- Comment #3 from Jakub Jelinek  ---
Sorry Uros, forgot to assign this to myself before I've started to work on it.

[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

2015-12-02 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> Sorry Uros, forgot to assign this to myself before I've started to work on
> it.

Ah, nice. I have a target-dependent patch for this, but I agree that generic
solution is better.

[Bug target/68648] [4.9/5/6 Regression][ARM] ICE: fail to generate BIC(immediate) instruction

2015-12-02 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68648

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5
Version|5.1.1   |4.9.4
   Keywords||ice-on-valid-code
   Last reconfirmed||2015-12-02
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[5/6][ARM] ICE: fail to |[4.9/5/6 Regression][ARM]
   |generate BIC(immediate) |ICE: fail to generate
   |instruction |BIC(immediate) instruction
   Target Milestone|--- |4.9.5
  Known to fail||4.9.4, 5.2.1, 6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed with 4.9, 5 and trunk. 4.8 branch doesn't ICE

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

2015-12-02 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064

--- Comment #5 from Markus Trippelsdorf  ---
Any update on this issue?

[Bug c/68663] New: Build failure on AIX 7.1

2015-12-02 Thread bugzilla-gcc at thewrittenword dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663

Bug ID: 68663
   Summary: Build failure on AIX 7.1
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla-gcc at thewrittenword dot com
  Target Milestone: ---

I tried building gcc-4.9.3 on AIX 7.1 as follows:
  $ gtar jxf gcc-4.9.3.tar.bz2
  $ cd gcc-4.9.3
  $ mkdir .obj
  $ cd .obj
  $ PATH=/opt/TWWfsw/gcc44/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 \
  ../configure LDFLAGS="-Wl,-brtl -Wl,blibpath:/opt/TWWfsw/libcloog018/lib:\
/opt/TWWfsw/libgmp51/lib:/opt/TWWfsw/libisl012/lib:/opt/TWWfsw/libmpc10/lib:\
/opt/TWWfsw/libmpfr31/lib:/usr/lib" --enable-nls --with-included-gettext \
--enable-shared --enable-threads --enable-languages="c,c++" \
--with-local-prefix=/tmp/gcc49 --with-cloog=/opt/TWWfsw/libcloog018 \
--with-gmp=/opt/TWWfsw/libgmp51 --with-isl=/opt/TWWfsw/libisl012 \
--with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
--prefix=/tmp/gcc49
  ...
  $ PATH=/opt/TWWfsw/gcc44/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 gmake

The build failed with the following:
/bin/sh /opt/build/china/gcc-4.9.3/gcc/../move-if-change tmp-output.c
insn-output.c
echo timestamp > s-output
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-4.9.3/gcc
-I/opt/build/china/gcc-4.9.3/gcc/. -I/opt/build/china/gcc-4.9.3/gcc/../include
-I./../intl -I/opt/build/china/gcc-4.9.3/gcc/../libcpp/include
-I/opt/TWWfsw/libgmp51/include -I/opt/TWWfsw/libmpfr31/include
-I/opt/TWWfsw/libmpc10/include 
-I/opt/build/china/gcc-4.9.3/gcc/../libdecnumber
-I/opt/build/china/gcc-4.9.3/gcc/../libdecnumber/dpd -I../libdecnumber
-I/opt/build/china/gcc-4.9.3/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/opt/TWWfsw/libcloog018/include -I/opt/TWWfsw/libisl012/include  -o
insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo
insn-output.c
/tmp//cczwRBC6.s: Assembler messages:
/tmp//cczwRBC6.s:1357: Error: value of 000117c0 too large for field of
2 bytes at 046e
/tmp//cczwRBC6.s:1491: Error: value of 000117c0 too large for field of
2 bytes at 05ee
/tmp//cczwRBC6.s:1624: Error: value of 000117c0 too large for field of
2 bytes at 0772
/tmp//cczwRBC6.s:1757: Error: value of 000117c0 too large for field of
2 bytes at 08f6
/tmp//cczwRBC6.s:1909: Error: value of 000117c4 too large for field of
2 bytes at 0aa6
/tmp//cczwRBC6.s:2043: Error: value of 000117c0 too large for field of
2 bytes at 0c2a
/tmp//cczwRBC6.s:2179: Error: value of 000117c0 too large for field of
2 bytes at 0db6
/tmp//cczwRBC6.s:2285: Error: value of 000117c8 too large for field of
2 bytes at 0eca
/tmp//cczwRBC6.s:2435: Error: value of 000117c0 too large for field of
2 bytes at 1086
...

[Bug fortran/68600] Inlined MATMUL is too slow.

2015-12-02 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600

--- Comment #9 from Thomas Koenig  ---

> I took the example code found in
> http://wiki.cs.utexas.edu/rvdg/HowToOptimizeGemm/ where the register based
> vector computations are explicitly called via the SSE registers and
> converted it to use the builtin gcc vector extensions.  I had to experiment
> a little to get some of the equivalent operations of the original code.

Nice one, I think we can use this as a basis for a new library
function in 7.1.

It probably will be necessary to add some zero-padding in some places
where the matix dimensions are not divisible by four.

[Bug tree-optimization/68550] [6 Regression] ICE: verify_gimple failed Error: missing PHI def

2015-12-02 Thread spop at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68550

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #5 from Sebastian Pop  ---
fixed

[Bug c/68656] [4.9/5/6 Regression] warning about disabled var-tracking uses odd location info

2015-12-02 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68656

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-02
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
This is "documented" here: https://gcc.gnu.org/wiki/DiagnosticsGuidelines

When the diagnostic does not refer to a particular source code location, it
should use an explicit UNKNOWN_LOCATION rather than no location at all (since
the latter uses input_location implicitly and who knows what that is pointing
at). It is always better to pass input_location explicitly rather than
implicitly. 

Unfortunately, there are still many many places in GCC that use warning/error
instead of warning_at/error_at.

(In reply to Richard Biener from comment #1)
> Which version worked ok?  I think these warnings should simply not output
> any location (well, as we now have per-function optimization settings such
> warning
> may apply only for certain functions...)

Is process_options called at all for per-function optimization settings? It
doesn't seem to. There is a finish_options that actually takes a location_t
argument and it is called for per-function optimization options.

[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0

2015-12-02 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > int
> > foo (int *__restrict__ ap)
> > {
> >   int *bp = ap;
> > #pragma omp parallel for
> >   for (unsigned int idx = 0; idx < N; idx++)
> > ap[idx] = bp[idx];
> > }
> > 
> > I believe this testcase is invalid as you access *ap through bp which is
> > not based on ap.
> > 
> 
> Modifying ap to point to a copy of *ap will modify the value of bp (when
> done before the copy from ap to bp), so to me it looks like bp is based on
> ap.

I suppose your line of reasoning is what you wrote here (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885#c15 ):
...
The standard has some interesting wording to define "based-on".  IIRC
it goes like a pointer is based on 'p' if the value of the pointer
changes when you modify 'p'.  I think that only allows for expressions
based on p, like (p + 1) or [2].  It does _not_ allow for new
temporaries, like q = p + 1; as if you modify p q doesn't change.
...
?

At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67705#c1 I find:
...
3 In what follows, a pointer expression E is said to be based on object P if
(at some sequence point in the execution of B prior to the evaluation of E)
modifying P to point to a copy of the array object into which it formerly
pointed would change the value of E).
...

Hmm, my reasoning was that in this example, modifying ap at sequence point 2, 
changes the value of bp at the point of evaluation of bp (*bp = 1). 
...
{
  /* sequence point 1.  */
  unsigned int *restrict ap = ...;
  /* sequence point 2.  */
  unsigned int *bp = ap;
  /* sequence point 3.  */
  *ap = 1;
  /* sequence point 4.  */
  *bp = 1;
  /* sequence point 5.  */
}
...

So AFAIU the difference in interpretation is related to whether the sequence
point mentioned in the standard relates to:
a. both the point of modifying P, and sampling the value of E to determine
   whether it changed, or just
b. just the point of modifying P, while the value of E is sampled at the
mentioned
   'evaluation of E'.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

2015-12-02 Thread amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659

--- Comment #2 from amker at gcc dot gnu.org ---
I will have a look.

[Bug c++/68184] [4.9/5/6 Regression] Exception from a virtual function does not get caught

2015-12-02 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68184

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Thu Dec  3 04:13:33 2015
New Revision: 231217

URL: https://gcc.gnu.org/viewcvs?rev=231217=gcc=rev
Log:

PR ipa/68184
* g++.dg/torture/pr68184.C: New testcase.
* cgraphunit.c (cgraph_node::analyze): Set can_throw_external.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr68184.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68184] [4.9/5 Regression] Exception from a virtual function does not get caught

2015-12-02 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68184

Jan Hubicka  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression]|[4.9/5 Regression]
   |Exception from a virtual|Exception from a virtual
   |function does not get   |function does not get
   |caught  |caught

--- Comment #7 from Jan Hubicka  ---
Fixed on trunk so far

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

2015-12-02 Thread alm at sibmail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919

--- Comment #20 from Alexander  ---
I have no issue to build it now.
Only important thing that is sed must be GNU.
(can check it in config.log)

[Bug c/67106] [6 Regression] ICE: verify_type failed: type variant differs by TYPE_PACKED. with -g -fpack-struct

2015-12-02 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67106

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

2015-12-02 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649

--- Comment #7 from Jan Hubicka  ---
The function is:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality
attributes 
value >>
arg-types 
chain 
chain 
chain 
chain  chain >
pointer_to_this >
addressable public external QI file a.f90 line 3 col 0 align 8 context
>

Second decl is:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality
attributes 
value >>
arg-types 
chain 
chain 
chain 
chain  chain >
pointer_to_this >
addressable public external QI file a.f90 line 4 col 0 align 8 context
>


The reason is that the declaration is duplicated (that by itself is a bug
violating one-decl rule) and we warn because reference type 0x76cc3888 is
not compatible with reference type 0x76cc33f0. They point to different type
of structure:

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76cc3690
fields 
unsigned DI file a.f90 line 3 col 0
size 
unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain >
reference_to_this  chain >
unsigned DI size  unit size 
align 64 symtab 0 alias set 6 structural equality>

compared to:

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76cc31f8
fields 
unsigned DI file a.f90 line 4 col 0
size 
unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain >
reference_to_this  chain >
unsigned DI size  unit size 
align 64 symtab 0 alias set 7 structural equality>

Notice the difference in size of the records.
This will indeed make TBAA code to believe that those two pointers are not
compatible. In libgfortran there is 
void
reshape_r8 (gfc_array_r8 * const restrict ret, 
gfc_array_r8 * const restrict source, 
shape_type * const restrict shape,
gfc_array_r8 * const restrict pad, 
shape_type * const restrict order)

ideally the fortran-fe produced declaration of reshape_r8 should be just one
per unit and interoperable with the declaration above that is pointer to:
#define GFC_ARRAY_DESCRIPTOR(r, type) \
struct {\
  type *base_addr;\
  size_t offset;\
  index_type dtype;\
  descriptor_dimension dim[r];\
}

[Bug lto/68556] [6 Regression] -r -flto test failures

2015-12-02 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68556

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
I believe these are fixed now?

[Bug bootstrap/68667] GCC trunk build fails compiling graphite-isl-ast-to-gimple.c

2015-12-02 Thread vekumar at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68667

--- Comment #1 from vekumar at gcc dot gnu.org ---
(In reply to vekumar from comment #0)
> Build breaks while compiling graphite related file.
> Occurred with trunk r231212.
> 
> (Snip) 
> ../../gcc-fsf-trunk/gcc/graphite-isl-ast-to-gimple.c: In member function
> âtree_node* translate_isl_ast_to_gimple::binary_op_to_tree(tree,
> isl_ast_expr*,,
>  ivs_params&)â:
> ../../gcc-fsf-trunk/gcc/graphite-isl-ast-to-gimple.c:591:10: error:
> âisl_ast_op_zdiv_râ was not declared in this scope
>  case isl_ast_op_zdiv_r:
>   ^
> ../../gcc-fsf-trunk/gcc/graphite-isl-ast-to-gimple.c: In member function
> âtree_node*
> translate_isl_ast_to_gimple::gcc_expression_from_isl_expr_op(tree,
> isl_ast_expr*, ivs_params&)â:
> ../../gcc-fsf-trunk/gcc/graphite-isl-ast-to-gimple.c:762:10: error:
> âisl_ast_op_zdiv_râ was not declared in this scope
>  case isl_ast_op_zdiv_r:
>   ^
> Makefile:1085: recipe for target 'graphite-isl-ast-to-gimple.o' failed
> make[2]: *** [graphite-isl-ast-to-gimple.o] Error 1
> (Snip)

I do ./contrib/download_prerequisites in to the gcc folder and it downloaded
isl-0.14.

[Bug c++/68645] [6 Regression] FAIL: c-c++-common/attr-simd-3.c -std=gnu++11 (test for excess errors)

2015-12-02 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68645

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

  1   2   >