[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def

2016-05-31 Thread Joost.VandeVondele at mat dot ethz.ch 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
Doesn't fail for me on x86, but similar to PR71351, which does fail.

[Bug tree-optimization/69068] [6/7 Regression] ICE in bb_contains_loop_phi_nodes, at graphite-isl-ast-to-gimple.c:1279

2016-05-31 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69068

--- Comment #8 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue May 31 07:07:26 2016
New Revision: 236907

URL: https://gcc.gnu.org/viewcvs?rev=236907&root=gcc&view=rev
Log:
Handle 3-arg phi in copy_bb_and_scalar_dependences

2016-05-31  Tom de Vries  

PR tree-optimization/69068
* graphite-isl-ast-to-gimple.c (copy_bb_and_scalar_dependences): Handle
phis with more than two args.

* gcc.dg/graphite/pr69068.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr69068.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault

2016-05-31 Thread Joost.VandeVondele at mat dot ethz.ch 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
simplified:

> cat bug.f90
  SUBROUTINE print_crys_symmetry(nc,v)
INTEGER :: nc
REAL(KIND=8), DIMENSION(3,48) :: v
INTEGER  :: n,i
vs = 0.0_8
DO n = 1, nc 
   DO i = 1, 3
  vs = vs + ABS(v(i,n))
   END DO
END DO
CALL foo(vs)
  END SUBROUTINE print_crys_symmetry

> gfortran  -c -O2 -floop-nest-optimize bug.f90
bug.f90:1:0:

   SUBROUTINE print_crys_symmetry(nc,v)

internal compiler error: Segmentation fault
0xba222f crash_signal
../../gcc/gcc/toplev.c:333
0xbf6247 ssa_default_def(function*, tree_node*)
../../gcc/gcc/tree-dfa.c:305
0xbf87a8 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc/gcc/tree-dfa.c:357
0xc33ab3 get_reaching_def
../../gcc/gcc/tree-into-ssa.c:1172
0xc33ab3 get_reaching_def

[Bug tree-optimization/69068] [6/7 Regression] ICE in bb_contains_loop_phi_nodes, at graphite-isl-ast-to-gimple.c:1279

2016-05-31 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69068

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue May 31 07:27:23 2016
New Revision: 236908

URL: https://gcc.gnu.org/viewcvs?rev=236908&root=gcc&view=rev
Log:
backport "Handle 3-arg phi in copy_bb_and_scalar_dependences"

2016-05-31  Tom de Vries  

backport:
2016-05-31  Tom de Vries  

PR tree-optimization/69068
* graphite-isl-ast-to-gimple.c (copy_bb_and_scalar_dependences): Handle
phis with more than two args.

* gcc.dg/graphite/pr69068.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/graphite/pr69068.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/graphite-isl-ast-to-gimple.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-31
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
The graphite transform does sth weird here ending up with a def not dominated
by its use.

[Bug middle-end/71348] [7 Regression] FAIL: gfortran.dg/graphite/pr68279.f90

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71348

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from Richard Biener  ---
Latent graphite problem.

/* Extract an affine expression from the chain of recurrence E.  */

static isl_pw_aff *
extract_affine_chrec (scop_p s, tree e, __isl_take isl_space *space)
{
  isl_pw_aff *lhs = extract_affine (s, CHREC_LEFT (e), isl_space_copy (space));
  isl_pw_aff *rhs = extract_affine (s, CHREC_RIGHT (e), isl_space_copy
(space));
  isl_local_space *ls = isl_local_space_from_space (space);
  unsigned pos = sese_loop_depth (s->scop_info->region, get_chrec_loop (e)) -
1;
  isl_aff *loop = isl_aff_set_coefficient_si
(isl_aff_zero_on_domain (ls), isl_dim_in, pos, 1);
  isl_pw_aff *l = isl_pw_aff_from_aff (loop);

  /* Before multiplying, make sure that the result is affine.  */
  gcc_assert (isl_pw_aff_is_cst (rhs)
  || isl_pw_aff_is_cst (l));

  return isl_pw_aff_add (lhs, isl_pw_aff_mul (rhs, l));
}

sese_loop_depth returns 0 as get_chrec_loop (e) is not inside the region.  This
makes pos equal to UINT_MAX and things go downhill.  Checking for the situation
here and returning NULL is not enough to fix the problem (that's as far as I
got before deciding to expose the latent issue).

Leaving to graphite knowing people.

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71347

Richard Biener  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com
   Target Milestone|--- |7.0

[Bug debug/71057] [6 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:24142

2016-05-31 Thread rguenther at suse dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 30 May 2016, romain.geissler at amadeus dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057
> 
> Romain Geissler  changed:
> 
>What|Removed |Added
> 
>  CC||romain.geissler at amadeus 
> dot com
> 
> --- Comment #6 from Romain Geissler  ---
> Hi,
> 
> I am facing the same kind of issue on a self-build gcc 6.1.1 with some
> proprietary code. Do you have any plan to backport this in the gcc6 branch ? 
> If
> needed, I can test your patch on my local occurence to confirm it actually
> works.

Yes, I'm planning to backport it soon.

[Bug tree-optimization/71352] New: ICE at -O1 and above on x86_64-linux-gnu: in zero_one_operation, at tree-ssa-reassoc.c:1251

2016-05-31 Thread su at cs dot ucdavis.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71352

Bug ID: 71352
   Summary: ICE at -O1 and above on x86_64-linux-gnu: in
zero_one_operation, at tree-ssa-reassoc.c:1251
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 6.1.x. 

This may be related to PR 71230 and PR 71263, but they have been fixed. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160530 (experimental) [trunk revision 236873] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$ gcc-6.1 -O1 -c small.c
$ 
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: in zero_one_operation, at
tree-ssa-reassoc.c:1251
 fn1 ()
 ^~~
0xd6d0de zero_one_operation
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:1250
0xd755b2 undistribute_ops_list
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:1604
0xd762a8 reassociate_bb
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5261
0xd75dc7 reassociate_bb
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5391
0xd78943 do_reassoc
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5505
0xd78943 execute_reassoc
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5592
0xd78943 execute
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5631
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





unsigned a, b, c, d, e;

void
fn1 ()
{
  unsigned f;
  e = f = d * -b + a * -c;
}

[Bug tree-optimization/69068] [6/7 Regression] ICE in bb_contains_loop_phi_nodes, at graphite-isl-ast-to-gimple.c:1279

2016-05-31 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69068

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #10 from vries at gcc dot gnu.org ---
Patch with testcase committed to trunk and 6 branch.

This fixes gfortran.dg/graphite/pr68279.f90 x86_64 -m64 failure as well.

[ gfortran.dg/graphite/pr68279.f90 x86_64 -m32 failure is due to PR71348 ]

Marking resolved-fixed.

[Bug tree-optimization/71352] [7 Regression] ICE at -O1 and above on x86_64-linux-gnu: in zero_one_operation, at tree-ssa-reassoc.c:1251

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71352

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-31
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
Summary|ICE at -O1 and above on |[7 Regression] ICE at -O1
   |x86_64-linux-gnu: in|and above on
   |zero_one_operation, at  |x86_64-linux-gnu: in
   |tree-ssa-reassoc.c:1251 |zero_one_operation, at
   ||tree-ssa-reassoc.c:1251
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug middle-end/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71311

--- Comment #2 from Richard Biener  ---
Bah, needs ref input and -Ofast to reproduce.  Probably a latent issue
somewhere.

[Bug c++/71248] crash on in-class initializer of array of pointer to member

2016-05-31 Thread paolo.carlini at oracle dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71248

--- Comment #3 from Paolo Carlini  ---
I meant that all the active release branches are fine.

[Bug c++/71353] New: ICE on valid code at -O1 and above on x86_64-linux-gnu: in binds_to_current_def_p, at symtab.c:2232

2016-05-31 Thread su at cs dot ucdavis.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71353

Bug ID: 71353
   Summary: ICE on valid code at -O1 and above on
x86_64-linux-gnu: in binds_to_current_def_p, at
symtab.c:2232
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk at
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 6.1.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160530 (experimental) [trunk revision 236873] (GCC) 
$ 
$ g++-trunk -O0 -c small.cpp
$ g++-6.1 -O1 -c small.cpp
$ 
$ g++-trunk -O1 -c small.cpp
_ZL3barv/1 (int bar()) @0x7f77e841e170
  Type: function definition analyzed alias transparent_alias weakref
  Visibility: weak
  References: foo/0 (alias)
  Referring: 
  Availability: available
  First run: 0
  Function flags: process
  Called by: _Z3bazv/2 (1.00 per call) (can throw external) 
  Calls: 
small.cpp: In function ‘int foo()’:
small.cpp:12:1: internal compiler error: in binds_to_current_def_p, at
symtab.c:2232
 }
 ^
0x9a72a8 symtab_node::binds_to_current_def_p(symtab_node*)
../../gcc-source-trunk/gcc/symtab.c:2232
0x9b0689 set_const_flag_1
../../gcc-source-trunk/gcc/cgraph.c:2488
0x9b059c set_const_flag_1
../../gcc-source-trunk/gcc/cgraph.c:2519
0x9b08ff cgraph_node::set_const_flag(bool, bool)
../../gcc-source-trunk/gcc/cgraph.c:2550
0x14c5791 execute
../../gcc-source-trunk/gcc/ipa-pure-const.c:1829
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





extern "C" __inline __attribute__ ((__gnu_inline__))
int foo () 
{
  return 0; 
}

static __typeof foo bar __attribute__ ((__weakref__ ("foo")));

void baz ()
{
  bar ();
}

[Bug target/71346] [AVX-512] AVX-512VL insn emitted when it is disabled

2016-05-31 Thread kyukhin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71346

--- Comment #3 from Kirill Yukhin  ---
Author: kyukhin
Date: Tue May 31 08:05:24 2016
New Revision: 236909

URL: https://gcc.gnu.org/viewcvs?rev=236909&root=gcc&view=rev
Log:
AVX-512. Limit constraint for scalar operand in split to AVX-512VL.

PR target/71346
gcc/
* config/i386/sse.md (define_insn_and_split "*vec_extractv4sf_0"): Use
`Yv' for scalar operand.
testsuite/
* gcc.target/i386/pr71346.c: New test.

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

[Bug tree-optimization/71352] [7 Regression] ICE at -O1 and above on x86_64-linux-gnu: in zero_one_operation, at tree-ssa-reassoc.c:1251

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71352

--- Comment #2 from Richard Biener  ---
Ok, it's factoring of -1 that is still broken.

[Bug tree-optimization/71230] [7 Regression] ICE : in zero_one_operation, at tree-ssa-reassoc.c:1230

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71230

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Richard Biener  ---
-> PR71352.

[Bug c++/71353] [7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in binds_to_current_def_p, at symtab.c:2232

2016-05-31 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71353

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-31
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid code at -O1|[7 Regression] ICE on valid
   |and above on|code at -O1 and above on
   |x86_64-linux-gnu: in|x86_64-linux-gnu: in
   |binds_to_current_def_p, at  |binds_to_current_def_p, at
   |symtab.c:2232   |symtab.c:2232
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug ipa/71353] [7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in binds_to_current_def_p, at symtab.c:2232

2016-05-31 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71353

Marek Polacek  changed:

   What|Removed |Added

  Component|c++ |ipa

--- Comment #2 from Marek Polacek  ---
Started with r235065.

[Bug target/71056] [6 Regression] __builtin_bswap32 NEON instruction error with -O3

2016-05-31 Thread ktkachov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue May 31 08:29:39 2016
New Revision: 236910

URL: https://gcc.gnu.org/viewcvs?rev=236910&root=gcc&view=rev
Log:
[ARM] PR target/71056: Don't use vectorized builtins when NEON is not available

PR target/71056
* config/arm/arm-builtins.c (arm_builtin_vectorized_function): Return
NULL_TREE early if NEON is not available.  Remove now redundant check
in ARM_CHECK_BUILTIN_MODE.

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


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/pr71056.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/arm-builtins.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/71056] [6 Regression] __builtin_bswap32 NEON instruction error with -O3

2016-05-31 Thread ktkachov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed for 6.2 as well. Thanks for the report.

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

2016-05-31 Thread ro at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923

Rainer Orth  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
Confirmed: I've just reverted the patch in a current tree, rebuilt cc1 and
rerun the affected testcases: all failures are gone.

  Rainer

[Bug tree-optimization/71354] New: gcc.dg/vect/vect-23.c FAILs

2016-05-31 Thread ro at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71354

Bug ID: 71354
   Summary: gcc.dg/vect/vect-23.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Created attachment 38606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38606&action=edit
vect-23.c.147t.vect

Between 20160506 and 20160512, the gcc.dg/vect/vect-23.c testcase began to FAIL
on Solaris/SPARC:

FAIL: gcc.dg/vect/vect-23.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 3 loops" 1
FAIL: gcc.dg/vect/vect-23.c scan-tree-dump-times vect "vectorized 3 loops" 1

Given that the testcase is XFAIL on the gcc-6 branch, this was most likely
caused by this patch:

2016-05-09  Bin Cheng  

* gcc.dg/tree-ssa/ifc-9.c: New test.
* gcc.dg/tree-ssa/ifc-10.c: New test.
* gcc.dg/tree-ssa/ifc-11.c: New test.
* gcc.dg/tree-ssa/ifc-12.c: New test.
* gcc.dg/vect/pr61194.c: Remove XFAIL.
* gcc.dg/vect/vect-23.c: Remove XFAIL.
* gcc.dg/vect/vect-mask-store-move-1.c: Revise test check.

I'm attaching the dump.

  Rainer

[Bug target/71355] New: Target not reachable svn link svn co svn://gcc.gnu.org/svn/gcc/trunk@223813

2016-05-31 Thread meerabo_shah at persistent dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71355

Bug ID: 71355
   Summary: Target not reachable svn link svn co
svn://gcc.gnu.org/svn/gcc/trunk@223813
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meerabo_shah at persistent dot com
  Target Milestone: ---

Hi Team,

From last two days we are unable to download source from this link 

svn co svn://gcc.gnu.org/svn/gcc/trunk@223813


Kindly look into the issue , or let us know if we have another link for the
same.

Thank you.

Regards,
Meerabo Shah

[Bug target/71355] Target not reachable svn link svn co svn://gcc.gnu.org/svn/gcc/trunk@223813

2016-05-31 Thread meerabo_shah at persistent dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71355

meerabo  changed:

   What|Removed |Added

   Severity|normal  |major

[Bug tree-optimization/71354] gcc.dg/vect/vect-23.c FAILs

2016-05-31 Thread ro at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71354

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/71346] [AVX-512] AVX-512VL insn emitted when it is disabled

2016-05-31 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71346

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

2016-05-31 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67310

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-31
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #8 from Uroš Bizjak  ---
Created attachment 38607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38607&action=edit
Proposed patch

Can you please test the attached patch?

(The patch also cleans up signature_CENTAUR_ebx handling considerably.)

[Bug web/71355] Target not reachable svn link svn co svn://gcc.gnu.org/svn/gcc/trunk@223813

2016-05-31 Thread sch...@linux-m68k.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71355

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|target  |web
 Resolution|--- |INVALID
   Severity|major   |normal

--- Comment #1 from Andreas Schwab  ---
r223813 doesn't exist on trunk.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

2016-05-31 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67310

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #38607|0   |1
is obsolete||

--- Comment #9 from Uroš Bizjak  ---
Created attachment 38608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38608&action=edit
Updated patch

Oops, please try this patch instead.

[Bug target/71356] New: Unable to reach trunk

2016-05-31 Thread meerabo_shah at persistent dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71356

Bug ID: 71356
   Summary: Unable to reach trunk
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meerabo_shah at persistent dot com
  Target Milestone: ---

Hi Team, 

we are getting below error while accessing trunk.

svn co svn://gcc.gnu.org/svn/gcc/trunk

Kindly provide alternative path to download source code

bash-4.2# svn co svn://gcc.gnu.org/svn/gcc/trunk
svn: E210002: Unable to connect to a repository at URL
'svn://gcc.gnu.org/svn/gcc/trunk'
svn: E210002: Network connection closed unexpectedly



Regards,
Meerabo Shah

[Bug debug/71057] [6 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:24142

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue May 31 09:58:50 2016
New Revision: 236912

URL: https://gcc.gnu.org/viewcvs?rev=236912&root=gcc&view=rev
Log:
2016-05-31  Richard Biener  

Backport from mainline
2016-05-11  Richard Biener  

PR debug/71057
* dwarf2out.c (retry_incomplete_types): Set early_dwarf.
(dwarf2out_finish): Move retry_incomplete_types call ...
(dwarf2out_early_finish): ... here.

* g++.dg/debug/pr71057.C: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/debug/pr71057.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/dwarf2out.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

2016-05-31 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66295

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-31
 CC||trippels at gcc dot gnu.org
  Known to work||4.9.3
Summary|LTO generates incorrect |[5/6/7 Regression] LTO
   |resolver call for function  |generates incorrect
   |multiversioning |resolver call for function
   ||multiversioning
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed.

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

2016-05-31 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71347

--- Comment #2 from amker at gcc dot gnu.org ---
Thanks for reporting this.

The dump after IVOPT now is:


  :
  # prephitmp_21 = PHI 
  # prephitmp_23 = PHI 
  # ivtmp.17_16 = PHI 
  _6 = prephitmp_21 * prephitmp_23;
  _4 = (void *) ivtmp.17_16;
  MEM[base: _4, offset: 0B] = _6;
  ivtmp.17_9 = ivtmp.17_16 + 8;
  if (ivtmp.17_9 != _26)
goto ;
  else
goto ;

  :
  _5 = (void *) ivtmp.17_9;
  pretmp_20 = MEM[base: _5, offset: 4294967288B];
  pretmp_22 = X[1];
  goto ;

That patch skips computing cost for sub iv_uses in a group:
Group 0:
  Type: ADDRESS
  Use 0.0:
At stmt:X[i_18] = _6;
At pos: X[i_18]
IV struct:
  Type: double *
  Base: (double *) (&X + 16)
  Step: 8
  Object:   (void *) &X
  Biv:  N
  Overflowness wrto loop niter: Overflow
  Use 0.1:
At stmt:pretmp_20 = X[_15];
At pos: X[_15]
IV struct:
  Type: double *
  Base: (double *) (&X + 16)
  Step: 8
  Object:   (void *) &X
  Biv:  N
  Overflowness wrto loop niter: Overflow

Though use 0.0/0.1 have same {base, step}, but there are in different program
point, so if iv_cand is increased before use 0.0, the first use is transformed
into: MEM[var_before, 0], and use 0.1 will be transformed into: MEM[var_after,
-8].  Now the two memory reference have different expressions, though access to
the same object.  Afterwards, DOM failed to CSE them.

It is hard to decide which sub iv_use we should compute the cost, and which one
we can skip computing the cost.  Maybe I should revert this part of code which
was introduced to save a small amount of compilation time.

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

2016-05-31 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66295

--- Comment #2 from Markus Trippelsdorf  ---
__attribute__((target("default"))) int foo() { return 1; }
__attribute__((target("arch=core2"))) int foo() { return 2; }
int main() {
  if (foo() != 1 && foo() != 2)
__builtin_abort();
}

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

2016-05-31 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66295

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
I will take a look.

[Bug web/71356] Unable to reach trunk

2016-05-31 Thread sch...@linux-m68k.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71356

Andreas Schwab  changed:

   What|Removed |Added

  Component|target  |web
Version|7.0 |unknown
   Severity|blocker |normal

[Bug web/71356] Unable to reach trunk

2016-05-31 Thread sch...@linux-m68k.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71356

--- Comment #1 from Andreas Schwab  ---
Anonymous connections are limited.  Try again later.

[Bug tree-optimization/71354] [7 Regression] gcc.dg/vect/vect-23.c FAILs

2016-05-31 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71354

--- Comment #1 from amker at gcc dot gnu.org ---
I think the case requires vect_cond which isn't enabled for sparc in
target-supports.exp.
I will add the requirement to the test.

[Bug target/71340] [RL78] -m64bit-doubles option is documented but not present

2016-05-31 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71340

Oleg Endo  changed:

   What|Removed |Added

 CC||kaushik.phatak@kpitcummins.
   ||com

--- Comment #1 from Oleg Endo  ---
CCing the author of the patch.

[Bug middle-end/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71311

--- Comment #3 from Richard Biener  ---
It's rhfuhf.F (exclusively).  Bisected with train, verified with ref.  Now I'd
need the equivalent of the optimize attribute for fortran...

Well.  Let's see if I can spot a reasonable difference in dumps.

[Bug debug/71057] [6 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:24142

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/68696] [6 Regression] FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1

2016-05-31 Thread ktkachov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68696

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue May 31 11:23:59 2016
New Revision: 236918

URL: https://gcc.gnu.org/viewcvs?rev=236918&root=gcc&view=rev
Log:
[AArch64] PR target/68696 FAIL: gcc.target/aarch64/vbslq_u64_1.c
scan-assembler-times bif\tv 1

PR target/68696
* config/aarch64/aarch64-simd.md (*aarch64_simd_bsl_alt):
New pattern.
(aarch64_simd_bsl_internal): Update comment to reflect
the above.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/aarch64-simd.md

[Bug tree-optimization/70390] [6/7 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

2016-05-31 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #4 from vries at gcc dot gnu.org ---
Still reproduces on 6 branch at r236908.

No longer reproduces on trunk since r236440:
...
2016-05-19  Richard Biener  

PR tree-optimization/70729
* passes.def: Move LIM pass before PRE.  Remove no longer
required copyprop and move first DCE out of the loop pipeline.
...

[Bug middle-end/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71311

--- Comment #4 from Richard Biener  ---
It's rhfuhf.F:ROFOCK.  Disabling vectorization fixes it.  One notable
difference
before vectorization MIN/MAX recognition caused by missing swapped comparison
handling in

/* Transform (@0 < @1 and @0 < @2) to use min,
   (@0 > @1 and @0 > @2) to use max */
(for op (lt le gt ge)
 ext (min min max max)
 (simplify
  (bit_and (op:s @0 @1) (op:s @0 @2))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
   (op @0 (ext @1 @2)

we'd need to add

/* Transform (@1 < @0 and @2 < @0) to use min,
   (@1 > @0 and @2 > @0) to use max */
(for op (lt le gt ge)
 ext (max max min min)
 (simplify
  (bit_and (op:s @1 @0) (op:s @2 @0))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
   (op (ext @1 @2) @0

plus a case for the operand order with @1 @0 @0 @2 (and adding :c to the
bit_and).

Adding the above "fixes" gamess, making the issue latent again.

[Bug tree-optimization/71352] [7 Regression] ICE at -O1 and above on x86_64-linux-gnu: in zero_one_operation, at tree-ssa-reassoc.c:1251

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71352

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue May 31 12:18:15 2016
New Revision: 236920

URL: https://gcc.gnu.org/viewcvs?rev=236920&root=gcc&view=rev
Log:
2016-05-31  Richard Biener  

PR tree-optimization/71352
* tree-ssa-reassoc.c (zero_one_operation): Handle op equal to
minus one and a negate.

* gcc.dg/tree-ssa/reassoc-45.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-45.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/71352] [7 Regression] ICE at -O1 and above on x86_64-linux-gnu: in zero_one_operation, at tree-ssa-reassoc.c:1251

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71352

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

2016-05-31 Thread glisse at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923

--- Comment #3 from Marc Glisse  ---
(In reply to Richard Biener from comment #1)
> We have vect_recog_mult_pattern that should have triggered here but that
> only tries replacement with LSHIFT_EXPR rather than also a simple plus
> for 2 * x.

I guess that would be something like

--- tree-vect-patterns.c(revision 236808)
+++ tree-vect-patterns.c(working copy)
@@ -2226,7 +2226,13 @@ vect_recog_mult_pattern (vec *
   power2_neg_val = wi::exact_log2 (wi::neg (oprnd1));

   /* Handle constant operands that are postive or negative powers of 2.  */
-  if (power2_val != -1)
+  if (power2_val == 1)
+{
+  pattern_stmt
+   = gimple_build_assign (vect_recog_temp_ssa_var (itype, NULL),
+  PLUS_EXPR, oprnd0, oprnd0);
+}
+  else if (power2_val != -1)
 {
   shift = build_int_cst (itype, power2_val);
   pattern_stmt

and something similar for the case *-2, it may be nicer to put this new ==1
case inside the !=-1 case (especially for power2_neg_val). But I don't think I
can easily test that, no sparc in the compile farm.

[Bug tree-optimization/71357] New: [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block follows the use for SSA_NAME) w/ -O2 -floop-nest-optimize

2016-05-31 Thread asolokha at gmx dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71357

Bug ID: 71357
   Summary: [7 Regression] [graphite] ICE: verify_ssa failed
(error: definition in block follows the use for
SSA_NAME) w/ -O2 -floop-nest-optimize
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160529 snapshot fails to compile the following reduced
testcase w/ -O2 (and above) -floop-nest-optimize:

int aj;
int xt[3];

void
qy (void)
{
  int e7;
  for (e7 = 0; e7 < 2; ++e7)
{
  int bs;
  for (bs = 1; bs < 4; ++bs)
for (aj = 0; aj < 2; ++aj)
  xt[e7 + e7] = xt[bs];
}
}

% gcc-7.0.0-alpha20160529 -c -O2 -floop-nest-optimize fj4zwaxo.c 
fj4zwaxo.c: In function 'qy':
fj4zwaxo.c:5:1: error: definition in block 30 follows the use
 qy (void)
 ^~
for SSA_NAME: _42 in statement:
_43 = _42 - graphite_IV.8_9;
fj4zwaxo.c:5:1: internal compiler error: verify_ssa failed

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

2016-05-31 Thread ro at CeBiTec dot Uni-Bielefeld.DE 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Marc Glisse  ---
> (In reply to Richard Biener from comment #1)
>> We have vect_recog_mult_pattern that should have triggered here but that
>> only tries replacement with LSHIFT_EXPR rather than also a simple plus
>> for 2 * x.
>
> I guess that would be something like
>
> --- tree-vect-patterns.c(revision 236808)
> +++ tree-vect-patterns.c(working copy)
> @@ -2226,7 +2226,13 @@ vect_recog_mult_pattern (vec *
>power2_neg_val = wi::exact_log2 (wi::neg (oprnd1));
>
>/* Handle constant operands that are postive or negative powers of 2.  */
> -  if (power2_val != -1)
> +  if (power2_val == 1)
> +{
> +  pattern_stmt
> +   = gimple_build_assign (vect_recog_temp_ssa_var (itype, NULL),
> +  PLUS_EXPR, oprnd0, oprnd0);
> +}
> +  else if (power2_val != -1)
>  {
>shift = build_int_cst (itype, power2_val);
>pattern_stmt
>
> and something similar for the case *-2, it may be nicer to put this new ==1
> case inside the !=-1 case (especially for power2_neg_val). But I don't think I
> can easily test that, no sparc in the compile farm.

That patch alone didn't make a difference when just rebuilding cc1 and
running the affected test cases.  If you provide me with a
complete patch, I can easily run it through its paces, though.

Rainer

[Bug tree-optimization/71357] [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block follows the use for SSA_NAME) w/ -O2 -floop-nest-optimize

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71357

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

2016-05-31 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923

--- Comment #5 from Richard Biener  ---
(In reply to Marc Glisse from comment #3)
> (In reply to Richard Biener from comment #1)
> > We have vect_recog_mult_pattern that should have triggered here but that
> > only tries replacement with LSHIFT_EXPR rather than also a simple plus
> > for 2 * x.
> 
> I guess that would be something like
> 
> --- tree-vect-patterns.c  (revision 236808)
> +++ tree-vect-patterns.c  (working copy)
> @@ -2226,7 +2226,13 @@ vect_recog_mult_pattern (vec *
>power2_neg_val = wi::exact_log2 (wi::neg (oprnd1));
>  
>/* Handle constant operands that are postive or negative powers of 2.  */
> -  if (power2_val != -1)
> +  if (power2_val == 1)
> +{
> +  pattern_stmt
> + = gimple_build_assign (vect_recog_temp_ssa_var (itype, NULL),
> +PLUS_EXPR, oprnd0, oprnd0);
> +}
> +  else if (power2_val != -1)
>  {
>shift = build_int_cst (itype, power2_val);
>pattern_stmt
> 
> and something similar for the case *-2, it may be nicer to put this new ==1
> case inside the !=-1 case (especially for power2_neg_val). But I don't think
> I can easily test that, no sparc in the compile farm.

It bails out before the above with the vecotr shift availability check.

[Bug c/71287] Possibly broken invocation of connect (and maybe other) syscalls

2016-05-31 Thread artpol84 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71287

--- Comment #10 from Artem Polyakov  ---
The same with gcc-6.1.0 (attached)

[Bug c/71287] Possibly broken invocation of connect (and maybe other) syscalls

2016-05-31 Thread artpol84 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71287

--- Comment #11 from Artem Polyakov  ---
Created attachment 38609
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38609&action=edit
req.i_gcc-6.1.0

[Bug c/71287] Possibly broken invocation of connect (and maybe other) syscalls

2016-05-31 Thread artpol84 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71287

--- Comment #12 from Artem Polyakov  ---
Created attachment 38610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38610&action=edit
req.s_gcc-6.1.0

[Bug c/71287] Possibly broken invocation of connect (and maybe other) syscalls

2016-05-31 Thread artpol84 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71287

--- Comment #13 from Artem Polyakov  ---
Oh, now I see what was going on!

This is a really masked error:

while( (rc = connect(sd, (struct sockaddr*)&address, addrlen) < 0) && (errno ==
EAGAIN) );

instead of:

while( (rc = connect(sd, (struct sockaddr*)&address, addrlen)) < 0 && (errno ==
EAGAIN) );

so the problem is in the code, not GCC: wrong operation sequence:
rc = (connect(sd, (struct sockaddr*)&address, addrlen) < 0)

instead of

(rc = (connect(sd, (struct sockaddr*)&address, addrlen)) < 0


So we can safely close this bug report. Sorry for the false alarm.

[Bug ada/71358] New: GNAT.Command_Line.Getopt fails if there are no switches

2016-05-31 Thread simon at pushface dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71358

Bug ID: 71358
   Summary: GNAT.Command_Line.Getopt fails if there are no
switches
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

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

A program had no switches (yet), and calling Getopt resulted in CE. Having
patched this, calling the program with -h or --help resulted in a different
crash.

A GDB session for the first (no switches) case gave

Catchpoint 1, CONSTRAINT_ERROR at 0x00011c1f in _ada_aes ()
at /Users/simon/Analytical_Engine/src/aes.adb:53
53 GNAT.Command_Line.Getopt (Command_Line_Config);
(gdb) bt
[...]
#5  0x00010009cad3 in __gnat_rcheck_CE_Access_Check (file=, 
line=) at a-except.adb:1202
#6  0x000100047c94 in gnat__command_line__getopt__2 (callback=0x0,
parser=0x101002000, 
concatenate=true) at /Users/simon/Analytical_Engine/src/g-comlin.adb:3457
#7  0x00011c1f in _ada_aes () at
/Users/simon/Analytical_Engine/src/aes.adb:53
(gdb) fr 6
#6  0x000100047c94 in gnat__command_line__getopt__2 (callback=0x0,
parser=0x101002000, 
concatenate=true) at /Users/simon/Analytical_Engine/src/g-comlin.adb:3457
3457  for S in Config.Switches'Range loop
(gdb) fr 6
#6  0x000100047c94 in gnat__command_line__getopt__2 (callback=0x0,
parser=0x101002000, 
concatenate=true) at /Users/simon/Analytical_Engine/src/g-comlin.adb:3457
3457  for S in Config.Switches'Range loop
(gdb) p config
$1 = (access gnat.command_line.command_line_configuration_record) 0x10070
(gdb) p config.all
$2 = (prefixes => 0x0, sections => 0x1003000a8, star_switch => false, aliases
=> 0x0, 
  usage => 0x1003029a8, help => 0x1003029c8, help_msg => 0x1003014a8, switches
=> 0x0)

I have a demonstrator and a patch.

[Bug c/71287] Possibly broken invocation of connect (and maybe other) syscalls

2016-05-31 Thread artpol84 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71287

Artem Polyakov  changed:

   What|Removed |Added

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

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

2016-05-31 Thread sirl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #6 from Franz Sirl  ---
Created attachment 38612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38612&action=edit
Testcase for -fsanitize=alignment

For this testcase compiled with -fsanitize=alignment/-fsanitize=undefined the
patch from comment#3 only shaves off about 4 seconds. The compiletime still
roughly doubles with each string added to the operator<< chain.

1)
time g++-6 -fsanitize=alignment tc3.cpp -c -ftime-report

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1575 kB (54%) ggc
 phase parsing   : 143.08 (100%) usr   0.00 ( 0%) sys 143.09 (100%)
wall 756 kB (26%) ggc
 phase opt and generate  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
   597 kB (20%) ggc
 register information:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 parser function body: 143.08 (100%) usr   0.00 ( 0%) sys 143.09 (100%)
wall 151 kB ( 5%) ggc
 integrated RA   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
49 kB ( 2%) ggc
 initialize rtl  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
12 kB ( 0%) ggc
 TOTAL : 143.10 0.00   143.12  
2939 kB

real2m23.132s
user2m23.108s
sys 0m0.008s

2)
g++-6 -v
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/6
--enable-ssp --disable-libssp --disable-libvtv --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-6 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.1.1 20160531 (SUSE Linux)

[Bug tree-optimization/69184] [6/7 Regression] ICE in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2685

2016-05-31 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69184

--- Comment #7 from vries at gcc dot gnu.org ---
No longer reproduces on trunk and 6 branch, due to fix for PR69068.

[Bug tree-optimization/71359] New: ICE at -Os and above in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, vec_safe_length)

2016-05-31 Thread chengniansun at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71359

Bug ID: 71359
   Summary: ICE at -Os and above in 32-bit and 64-bit modes on
x86_64-linux-gnu (Segmentation fault,
vec_safe_length)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160531 (experimental) [trunk revision 236912] (GCC) 
$: gcc-trunk -w -O3 small.c
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~
0xbbd02f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0xd08d70 vec_safe_length
../../gcc-source-trunk/gcc/vec.h:529
0xd08d70 loop_outer
../../gcc-source-trunk/gcc/cfgloop.h:456
0xd08d70 tree_unroll_loops_completely_1
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1347
0xd08ce0 tree_unroll_loops_completely_1
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1314
0xd08ce0 tree_unroll_loops_completely_1
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1314
0xd09013 tree_unroll_loops_completely(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1384
0xd09583 execute
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1593
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: cat small.c
char a[];
int b;
void fn1() {
  int i;
  for (;;) {
i = 0;
for (; i < 6; i++) {
  if (b)
for (;;)
  ;
  int c = a[i];
  printf("", i);
}
  }
}

int main() {}
$:

[Bug tree-optimization/71359] [7 Regression] ICE at -Os and above in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, vec_safe_length)

2016-05-31 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71359

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-31
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE at -Os and above in |[7 Regression] ICE at -Os
   |32-bit and 64-bit modes on  |and above in 32-bit and
   |x86_64-linux-gnu|64-bit modes on
   |(Segmentation fault,|x86_64-linux-gnu
   |vec_safe_length) |vec_safe_length)
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/71359] [7 Regression] ICE at -Os and above in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, vec_safe_length)

2016-05-31 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71359

--- Comment #2 from Marek Polacek  ---
commit eedd711b1de214484021ed233aef3d88b0c3988c
Author: hubicka 
Date:   Mon May 30 10:40:33 2016 +

* predict.h (force_edge_cold): Declare.
* predict.c (force_edge_cold): New function.
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Fix profile
updating.
(canonicalize_loop_induction_variables): Fix formating.

* gcc.dg/tree-ssa/cunroll-12.c: New testcase.
* gcc.dg/tree-ssa/cunroll-13.c: New testcase.
* gcc.dg/tree-ssa/cunroll-14.c: New testcase.


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

[Bug tree-optimization/71359] [7 Regression] ICE at -Os and above in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, vec_safe_length)

2016-05-31 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71359

--- Comment #3 from Marek Polacek  ---
Also ICEs if I change
char a[];
to
char a[1];

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

2016-05-31 Thread senthil.thecoder at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151

--- Comment #7 from Senthil Kumar Selvaraj  
---
Created attachment 38613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38613&action=edit
Tentative patch for 6.1

Looks like the right fix will need to somehow differentiate between jump tables
and other per function data when the function_rodata_section target hook is
invoked. I'll submit a tentative patch in the next couple of days that does
that.

However, I don't think that patch will get into 6.x, given that it changes the
target hook interface. The attached patch instead tries to work around the
problem, by letting default_elf_select_section run as usual, but then returning
a different section with the name reverted to the right prefix (rodata instead
of progmem), with the correct flags (MERGE and STRINGS)

[Bug tree-optimization/71359] [7 Regression] ICE at -Os and above in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, vec_safe_length)

2016-05-31 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71359

Marek Polacek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #4 from Marek Polacek  ---
Whoops, this is actually invalid code.

[Bug debug/71057] [6 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:24142

2016-05-31 Thread romain.geissler at amadeus dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057

--- Comment #10 from Romain Geissler  ---
Thanks ! The current gcc6 branch works fine now.

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

2016-05-31 Thread m.ostapenko at samsung dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #9 from Maxim Ostapenko  ---
Hm, looking to corresponding source code (dist/include/mozilla/gfx/Matrix.h):

 705   template
 706   size_t TransformAndClipRect(const RectTyped& aRect,
 707   const RectTyped& aClip,
 708   PointTyped* aVerts) const
 709   {
 710 // Initialize a double-buffered array of points in homogenous space 
 711 // with the input rectangle, aRect.
 712 Point4DTyped points[2]kTransformAndClipRectMaxVerts];
 713 Point4DTyped* dstPoint = points[0];

 727 // Iterate through each clipping plane and clip the polygon.
 728 // In each pass, we double buffer, alternating between points[0] and
 729 // points[1].
 730 for (int plane=0; plane < 4; plane++) {
 731   planeNormals[plane].Normalize();
 732 
 733   Point4DTyped* srcPoint = points[plane & 1];
 734   Point4DTyped* srcPointEnd = dstPoint;
 735   dstPoint = points[~plane & 1];
 736 
 737   Point4DTyped* prevPoint = srcPointEnd - 1;
 738   F prevDot = planeNormals[plane].DotProduct(*prevPoint);



I suspect this scenario to happen:

1) On iteration 2 (i == 1) dstPoint becomes points[0] at line 735.
2) Later on iteration 1 dstPoint doesn't change for some reason.
3) On iteration 3 (i == 2) srcPointEnd becomes srcPointEnd = dstPoint (==
point[0]) at line 734.
4) Later on iteration 3 prevPoint = srcPointEnd - 1 (point[-1]) at line 737.
5) At line 738 we use *prevPoint (points[-1]) that leads to ASan report (valid,
because points[-1] overflows).

Could you check this? If this is what happens, than ASan is innocent and
something else went wrong here.

[Bug c++/71248] crash on in-class initializer of array of pointer to member

2016-05-31 Thread paolo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71248

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May 31 17:17:29 2016
New Revision: 236931

URL: https://gcc.gnu.org/viewcvs?rev=236931&root=gcc&view=rev
Log:
/cp
2016-05-31  Paolo Carlini  

PR c++/71248
* decl.c (check_static_variable_definition): Use DECL_SOURCE_LOCATION
to obtain correct locations; avoid redundant diagnostics on
out-of-class definitions.

/testsuite
2016-05-31  Paolo Carlini  

PR c++/71248
* g++.dg/cpp0x/pr71248.C: New.
* g++.dg/cpp0x/auto7.C: Test column numbers too.
* g++.dg/cpp0x/constexpr-static8.C: Likewise.
* g++.dg/init/new37.C: Likewise.
* g++.dg/template/static1.C: Likewise.
* g++.dg/template/static2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr71248.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/auto7.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C
trunk/gcc/testsuite/g++.dg/init/new37.C
trunk/gcc/testsuite/g++.dg/template/static1.C
trunk/gcc/testsuite/g++.dg/template/static2.C

[Bug c++/71306] bogus -Wplacement-new with an array element

2016-05-31 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71306

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue May 31 17:24:22 2016
New Revision: 236934

URL: https://gcc.gnu.org/viewcvs?rev=236934&root=gcc&view=rev
Log:
PR c++/71306 - bogus -Wplacement-new with an array element

gcc/cp/ChangeLog:
2016-05-31  Martin Sebor  

PR c++/71306
* init.c (warn_placement_new_too_small): Handle placement new arguments
that are elements of arrays more carefully.  Remove a pointless loop.

gcc/testsuite/ChangeLog:
2016-05-31  Martin Sebor  

PR c++/71306
* g++.dg/warn/Wplacement-new-size-3.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/warn/Wplacement-new-size-3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/init.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71306] bogus -Wplacement-new with an array element

2016-05-31 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71306

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in 7.0 via 236902 and backported to 6.x in r236934.

[Bug c++/71248] crash on in-class initializer of array of pointer to member

2016-05-31 Thread paolo.carlini at oracle dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71248

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from Paolo Carlini  ---
Location fixed in trunk (for 7).

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

2016-05-31 Thread m.ostapenko at samsung dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291

--- Comment #10 from Maxim Ostapenko  ---
I've build Firefox locally with clang with optimizations disabled
(CFLAGS="-fsanitize=address -fsanitize-recover=address -O0") and got pretty the
same backtrace:

==12707==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fe22dbc417c at pc 0x7fe25e3b9ee5 bp 0x7fe22dbc40b0 sp 0x7fe22dbc40a8
READ of size 4 at 0x7fe22dbc417c thread T39 (Compositor)
#0 0x7fe25e3b9ee4 in mozilla::gfx::BasePoint4D
>::DotProduct(mozilla::gfx::Point4DTyped
const&) const /home/max/src/firefox/gfx/2d/BasePoint4D.h:101:68
#1 0x7fe25e3b7e6e in unsigned long
mozilla::gfx::Matrix4x4Typed::TransformAndClipRect(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped
const&, mozilla::gfx::PointTyped*) const
/home/max/src/firefox/gfx/2d/Matrix.h:738:19
#2 0x7fe25e3a2329 in mozilla::gfx::RectTyped mozilla::gfx::Matrix4x4Typed::TransformAndClipBounds(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped
const&) const /home/max/src/firefox/gfx/2d/Matrix.h:675:24
#3 0x7fe25ea08163 in
mozilla::layers::BasicCompositor::DrawQuad(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped
const&, mozilla::layers::EffectChain const&, float,
mozilla::gfx::Matrix4x4Typed const&,
mozilla::gfx::RectTyped const&)
/home/max/src/firefox/gfx/layers/basic/BasicCompositor.cpp:311:23
#4 0x7fe25e888778 in
mozilla::layers::Compositor::DrawQuad(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped
const&, mozilla::layers::EffectChain const&, float,
mozilla::gfx::Matrix4x4Typed const&)
/home/max/src/firefox/objdir-ff-asan-O0/dist/include/mozilla/layers/Compositor.h:331:7
#5 0x7fe25eb0b14f in
mozilla::layers::ColorLayerComposite::RenderLayer(mozilla::gfx::IntRectTyped
const&)::$_1::operator()(mozilla::layers::EffectChain&,
mozilla::gfx::RectTyped const&) const
/home/max/src/firefox/gfx/layers/composite/ColorLayerComposite.cpp:31:5
#6 0x7fe25ead8bdd in void
mozilla::layers::RenderWithAllMasks
const&)::$_1>(mozilla::layers::Layer*, mozilla::layers::Compositor*,
mozilla::gfx::IntRectTyped const&,
mozilla::layers::ColorLayerComposite::RenderLayer(mozilla::gfx::IntRectTyped
const&)::$_1)
/home/max/src/firefox/gfx/layers/composite/LayerManagerComposite.h:616:5
#7 0x7fe25ead8437 in
mozilla::layers::ColorLayerComposite::RenderLayer(mozilla::gfx::IntRectTyped
const&) /home/max/src/firefox/gfx/layers/composite/ColorLayerComposite.cpp:28:3
#8 0x7fe25eb749e6 in void
mozilla::layers::RenderLayers(mozilla::layers::ContainerLayerComposite*,
mozilla::layers::LayerManagerComposite*,
mozilla::gfx::IntRectTyped const&)
/home/max/src/firefox/gfx/layers/composite/ContainerLayerComposite.cpp:662:7
...
Address 0x7fe22dbc417c is located in stack of thread T39 (Compositor) at offset
28 in frame
#0 0x7fe25e3b6b8f in unsigned long
mozilla::gfx::Matrix4x4Typed::TransformAndClipRect(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped
const&, mozilla::gfx::PointTyped*) const
/home/max/src/firefox/gfx/2d/Matrix.h:709

  This frame has 20 object(s):
[32, 1056) 'points' <== Memory access at offset 28 underflows this variable
[1184, 1200) 'ref.tmp'
[1216, 1232) 'ref.tmp2'
[1248, 1264) 'ref.tmp4'
[1280, 1296) 'ref.tmp5'
[1312, 1328) 'ref.tmp11'
[1344, 1360) 'ref.tmp12'
[1376, 1392) 'ref.tmp18'
[1408, 1424) 'ref.tmp19'
[1440, 1504) 'planeNormals'
[1536, 1552) 'ref.tmp32'
[1568, 1584) 'ref.tmp35'
[1600, 1616) 'ref.tmp38'
[1632, 1648) 'ref.tmp42'
[1664, 1680) 'ref.tmp68'
[1696, 1712) 'coerce'
[1728, 1744) 'ref.tmp71'
[1760, 1768) 'p'
[1792, 1800) 'ref.tmp99'
[1824, 1832) 'ref.tmp100'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
/home/max/src/firefox/gfx/2d/BasePoint4D.h:101:68 in
mozilla::gfx::BasePoint4D
>::DotProduct(mozilla::gfx::Point4DTyped
const&) const
Shadow bytes around the buggy address:
  0x0ffcc5b707d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b707e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b707f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b70800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b70810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ffcc5b70820: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1[f1]
  0x0ffcc5b70830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b70840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b70850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b70860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc5b70870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:

[Bug ada/71317] Compiling gnat for rtems fails at s-taprop.adb

2016-05-31 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71317

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue May 31 18:59:36 2016
New Revision: 236938

URL: https://gcc.gnu.org/viewcvs?rev=236938&root=gcc&view=rev
Log:
* s-osinte-kfreebsd-gnu.ads (clock_getres): Define.
(Get_Page_Size): Remove duplicate and return int.

PR ada/71317
* s-osinte-rtems.ads (clock_getres): Define.
(Get_Page_Size): Remove duplicate and return int.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads
trunk/gcc/ada/s-osinte-rtems.ads

[Bug ada/71317] Compiling gnat for rtems fails at s-taprop.adb

2016-05-31 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71317

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue May 31 18:59:45 2016
New Revision: 236939

URL: https://gcc.gnu.org/viewcvs?rev=236939&root=gcc&view=rev
Log:
* s-osinte-kfreebsd-gnu.ads (clock_getres): Define.
(Get_Page_Size): Remove duplicate and return int.

PR ada/71317
* s-osinte-rtems.ads (clock_getres): Define.
(Get_Page_Size): Remove duplicate and return int.

Modified:
branches/gcc-6-branch/gcc/ada/ChangeLog
branches/gcc-6-branch/gcc/ada/s-osinte-kfreebsd-gnu.ads
branches/gcc-6-branch/gcc/ada/s-osinte-rtems.ads

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

2016-05-31 Thread gk at torproject dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291

Georg Koppen  changed:

   What|Removed |Added

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

--- Comment #11 from Georg Koppen  ---
Thanks a lot! I've informed the Mozilla people and updated their bug. Sorry for
the noise.

[Bug ada/71358] GNAT.Command_Line.Getopt fails if there are no switches

2016-05-31 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71358

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-31
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
The testcase yields a STORAGE_ERROR (segfault), which is not pretty indeed.

[Bug c++/71227] [6/7 Regression] template friend function cannot be resolved

2016-05-31 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71227

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue May 31 19:16:26 2016
New Revision: 236941

URL: https://gcc.gnu.org/viewcvs?rev=236941&root=gcc&view=rev
Log:
PR c++/71227 - specializing hidden friend

* pt.c (check_explicit_specialization): Give better diagnostic about
specializing a hidden friend.

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

[Bug c/71360] New: Wrong position for "warning: '0' flag ignored with precision and ‘%d’ gnu_printf format [-Wformat=]"

2016-05-31 Thread ch3root at openwall dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71360

Bug ID: 71360
   Summary: Wrong position for "warning: '0' flag ignored with
precision and ‘%d’ gnu_printf format [-Wformat=]"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
#include 

int main()
{
  printf("abc" "%05.3d\n", 1);
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:5:10: warning: '0' flag ignored with precision and ‘%d’ gnu_printf
format [-Wformat=]
   printf("abc" "%05.3d\n", 1);
  ^
abc  001
------

gcc version: gcc (GCC) 7.0.0 20160531 (experimental)

This is split from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70924 as it
seems to be a separate issue.

[Bug tree-optimization/71361] New: [7 Regression] Changes in ivopts caused perf regression on x86

2016-05-31 Thread iverbin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361

Bug ID: 71361
   Summary: [7 Regression] Changes in ivopts caused perf
regression on x86
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iverbin at gcc dot gnu.org
CC: amker.cheng at gmail dot com, izamyatin at gmail dot com,
kyukhin at gcc dot gnu.org
  Target Milestone: ---

r235805 leads to performance regression on x86.

Reduced testcase:

int arr_1[512];
int arr_2[512];

int main ()
{
int c1[512];
int c2[512];
int res[512];

for (int i = 0; i < 512; i++)
  arr_1[i] = arr_2[i] = c1[i] = c2[i] = i;

for (int l = 0; l < 100; l++)
  for (int k = 1; k <= 9; k++)
{
  int n1 = 1 << k;
  int n2 = n1 >> 1;

  for (int j = 0; j < n2; j++)
for (int i = j; i < 512; i += n1)
  {
int idx = i + n2;
int x1 = arr_1[idx] * c1[j] + arr_2[idx] * c2[j];
int x2 = arr_2[idx] * c1[j] + arr_1[idx] * c2[j];

arr_1[i] = x1;
arr_2[i] = x2;
arr_1[idx] = x1;
arr_2[idx] = x2;
  }
}

return 0;
}

Compilation options: -Ofast -m32 -fPIE
GCC is configured --with-arch=corei7 --with-cpu=corei7 --with-fpmath=sse
Run time on Sandy Bridge increased by ~20%
Run time on Atom increased by ~60%

Below are the dumps of the innermost loop after ivopts pass.

Before regression there are 2 induction variables, which are used as bases for
all 6 memory accesses:

  # i_66 = PHI 
  # ivtmp.19_63 = PHI 
  # ivtmp.20_17 = PHI 
  _59 = (void *) ivtmp.19_63;
  _58 = (sizetype) n2_20;
  _22 = MEM[base: _59, index: _58, step: 4, offset: 0B];
  _24 = _22 * pretmp_105;
  _55 = (void *) ivtmp.20_17;
  _54 = (sizetype) n2_20;
  _25 = MEM[base: _55, index: _54, step: 4, offset: 0B];
  _27 = _25 * pretmp_107;
  x1_28 = _24 + _27;
  _30 = _25 * pretmp_105;
  _31 = _22 * pretmp_107;
  x2_32 = _30 + _31;
  _51 = (void *) ivtmp.19_63;
  MEM[base: _51, offset: 0B] = x1_28;
  _50 = (void *) ivtmp.20_17;
  MEM[base: _50, offset: 0B] = x2_32;
  _57 = (void *) ivtmp.19_63;
  _56 = (sizetype) n2_20;
  MEM[base: _57, index: _56, step: 4, offset: 0B] = x1_28;
  _53 = (void *) ivtmp.20_17;
  _52 = (sizetype) n2_20;
  MEM[base: _53, index: _52, step: 4, offset: 0B] = x2_32;
  i_37 = n1_19 + i_66;
  ivtmp.19_95 = ivtmp.19_63 + _77;
  ivtmp.20_15 = ivtmp.20_17 + _12;
  if (i_37 <= 511)
goto ;
  else
goto ;

After regression there is only one induction variable, which is used as index
for 4 memory accesses.

  # i_66 = PHI 
  # ivtmp.22_63 = PHI 
  _22 = MEM[symbol: arr_1, index: ivtmp.22_63, offset: 0B];
  _24 = _22 * pretmp_105;
  _25 = MEM[symbol: arr_2, index: ivtmp.22_63, offset: 0B];
  _27 = _25 * pretmp_107;
  x1_28 = _24 + _27;
  _30 = _25 * pretmp_105;
  _31 = _22 * pretmp_107;
  x2_32 = _30 + _31;
  _17 = (sizetype) i_66;
  _15 = _17 * 4;
  MEM[symbol: arr_1, index: _15, offset: 0B] = x1_28;
  _14 = (sizetype) i_66;
  _12 = _14 * 4;
  MEM[symbol: arr_2, index: _12, offset: 0B] = x2_32;
  MEM[symbol: arr_1, index: ivtmp.22_63, offset: 0B] = x1_28;
  MEM[symbol: arr_2, index: ivtmp.22_63, offset: 0B] = x2_32;
  i_37 = n1_19 + i_66;
  ivtmp.22_95 = ivtmp.22_63 + _77;
  if (i_37 <= 511)
goto ;
  else
goto ;

As a result, the final assembly contains 13% more instructions.

Before regression:

  .L5:
movl(%edi,%ebx,4), %eax
movd%xmm1, %edx
movd%xmm0, %ecx
imull   (%esi,%ebx,4), %ecx
imull   %eax, %edx
addl%ecx, %edx
movd%xmm0, %ecx
imull   %ecx, %eax
movd%xmm1, %ecx
imull   (%esi,%ebx,4), %ecx
movl%edx, (%esi)
movl%edx, (%esi,%ebx,4)
movd%xmm5, %edx
addl%edx, %esi
addl%ecx, %eax
movl%eax, (%edi)
movl%eax, (%edi,%ebx,4)
movd%xmm4, %eax
addl%edx, %edi
addl%eax, -4124(%ebp)
movl-4124(%ebp), %ecx
cmpl$511, %ecx
jle .L5

After regression:

  .L5:
movd%xmm5, %edi
movd%xmm3, %edx
movd%xmm1, %ebx
imull   (%eax,%edx), %ebx
movd%xmm4, %ecx
movd%xmm4, %edx
imull   (%eax,%edi), %ecx
addl%ecx, %ebx
movd%xmm1, %ecx
imull   (%eax,%edi), %ecx
movd%ecx, %xmm0
movd%xmm3, %ecx
imull   (%eax,%ecx), %edx
movd%xmm0, %ecx
addl%edx, %ecx
movd%xmm3, %edx
movl%ebx, (%edx,%esi,4)
movd%xmm3, %edx
movl%ecx, (%edi,%esi,4)
addl-4124(%ebp), %esi
movd%xmm5, %edi
movl

[Bug c/71360] Wrong position for "warning: '0' flag ignored with precision and ‘%d’ gnu_printf format [-Wformat=]"

2016-05-31 Thread ch3root at openwall dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71360

--- Comment #1 from Alexander Cherepanov  ---
Sorry, old bug number is wrong, this is split from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70813.

[Bug c/70813] Wrong warning "'0' flag ignored with precision and ‘%d’ gnu_printf format"

2016-05-31 Thread ch3root at openwall dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70813

--- Comment #1 from Alexander Cherepanov  ---
Wrong position of this warning seems to be a separate issue, so I filed it as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70813 . This PR is about the fact
that this warning is emitted at all in this corner case.

[Bug c++/55813] Poorly named/documented option Wctor-dtor-privacy

2016-05-31 Thread kyle.strand at beckman dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55813

Kyle J Strand  changed:

   What|Removed |Added

 CC||kyle.strand at beckman dot com

--- Comment #4 from Kyle J Strand  ---
The behavior (even as of 5.1) still seems at odds with the documentation. In
particular, classes with *public* constructors *can* trigger this warning.

See http://stackoverflow.com/q/33157248/1858225 for discussion and sample code.

[Bug c/71362] New: Wrong position for "error: size of unnamed array is negative"

2016-05-31 Thread ch3root at openwall dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71362

Bug ID: 71362
   Summary: Wrong position for "error: size of unnamed array is
negative"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
int main()
{
  123 + sizeof(int[-1]);
}
--

Results:

--
$ gcc -std=c11 -pedantic test.c && ./a.out
test.c: In function ‘main’:
test.c:3:3: error: size of unnamed array is negative
   123 + sizeof(int[-1]);
   ^~~
--

gcc version: gcc (GCC) 7.0.0 20160531 (experimental)

[Bug c++/69009] [5/6 Regression] ICE in instantiate_decl, at cp/pt.c:21511

2016-05-31 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69009

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Tue May 31 19:49:16 2016
New Revision: 236946

URL: https://gcc.gnu.org/viewcvs?rev=236946&root=gcc&view=rev
Log:
PR c++/60095 - partial specialization of variable templates

PR c++/69515
PR c++/69009
* pt.c (instantiate_template_1): Don't put the partial
specialization in DECL_TI_TEMPLATE.
(partial_specialization_p, impartial_args): Remove.
(regenerate_decl_from_template): Add args parm.
(instantiate_decl): Look up the partial specialization again.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39a.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ51.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ52.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C

[Bug c++/69515] partial specialization of variable templates is broken

2016-05-31 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue May 31 19:49:16 2016
New Revision: 236946

URL: https://gcc.gnu.org/viewcvs?rev=236946&root=gcc&view=rev
Log:
PR c++/60095 - partial specialization of variable templates

PR c++/69515
PR c++/69009
* pt.c (instantiate_template_1): Don't put the partial
specialization in DECL_TI_TEMPLATE.
(partial_specialization_p, impartial_args): Remove.
(regenerate_decl_from_template): Add args parm.
(instantiate_decl): Look up the partial specialization again.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39a.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ51.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ52.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C

[Bug c++/60095] Dubious diagnostics for attempted surrogate call function

2016-05-31 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60095

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue May 31 19:49:16 2016
New Revision: 236946

URL: https://gcc.gnu.org/viewcvs?rev=236946&root=gcc&view=rev
Log:
PR c++/60095 - partial specialization of variable templates

PR c++/69515
PR c++/69009
* pt.c (instantiate_template_1): Don't put the partial
specialization in DECL_TI_TEMPLATE.
(partial_specialization_p, impartial_args): Remove.
(regenerate_decl_from_template): Add args parm.
(instantiate_decl): Look up the partial specialization again.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39a.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ51.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ52.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ39.C

[Bug fortran/70350] [5 Regression] ICE with -fcheck=all and array initialization

2016-05-31 Thread kristopher.kuhlman at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70350

Kris  changed:

   What|Removed |Added

 CC||kristopher.kuhlman at gmail 
dot co
   ||m

--- Comment #7 from Kris  ---
I can confirm this problem, but I didn't upload my similar 13-line test case.
Will a fix for this make it into 5.3.1 eventually?

It is a real bummer that --fcheck=all crashes gfortran on Ubuntu 16.04 LTS,
which will be supported for nearly 5 more years. 

gfortran --version
GNU Fortran (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413

[Bug libfortran/71363] New: Issue when sizeof(double) = sizeof(long double)

2016-05-31 Thread paul.mustiere at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71363

Bug ID: 71363
   Summary: Issue when sizeof(double) = sizeof(long double)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.mustiere at gmail dot com
  Target Milestone: ---

Hello,

I am building the GNU toolchain for Android with support for Fortran, and
encountered an issue when targeting x86 for the runtime library.

Note: I'm using the toolchain sources provided by Google, but as far as I can
tell the Fortran part is simply 4.9 since they are not trying to build with
Fortran.

In intrisics/cshift0.c, I get a 'duplicate case value'
(http://paste.ubuntu.com/16861425/). As far as I can tell:

- GFC_DTYPE_REAL_16 is defined (but not GFC_DTYPE_REAL_10), hence GFC_REAL_16
is defined as long double.
- sizeof(long double) = sizeof(double) = 8, which causes the duplicate case.

I find a workaround which consists of detecting both sizes in mk-kinds-h.sh and
checking that they are not equal before defining GFC_REAL_16. The rest of the
toolchain compiles fine, but I am not sure it's ideal.
Also, I'm curious as to why Fortran seems to be fine with real (kind=16) but C
doesn't seem to be able to hold variables that big.

I know I'm not using the regular GNU toolchain but any help is appreciated.

Cheers,
Paul Mustiere

[Bug ada/71358] GNAT.Command_Line.Getopt fails if there are no switches

2016-05-31 Thread simon at pushface dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71358

--- Comment #2 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #1)
> The testcase yields a STORAGE_ERROR (segfault), which is not pretty indeed.

Presumably because the GNAT RTS is compiled with checks disabled? Here
(x86_64-apple-darwin15) I get

$ ./bug 

Execution terminated by unhandled exception
raised CONSTRAINT_ERROR : erroneous memory access

[Bug c++/71330] [6/7 Regression] Compile time regression

2016-05-31 Thread ppalka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71330

--- Comment #11 from Patrick Palka  ---
(In reply to Patrick Palka from comment #10)
> I think the problem is with cp_fold_function() which does
> 
>   cp_walk_tree (&DECL_SAVED_TREE (fndecl), cp_fold_r, NULL, NULL);
> 
> and cp_fold_r is itself recursive so the number of calls made to cp_fold_r
> via cp_fold_function() is quadratic with respect to the size of the
> function's subexpressions.  The test case features a huge subexpression
> arising from the chain of overloaded <

[Bug c++/69515] partial specialization of variable templates is broken

2016-05-31 Thread tom at honermann dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515

--- Comment #6 from Tom Honermann  ---
(In reply to Jason Merrill from comment #5)
>   PR c++/60095 - partial specialization of variable templates

I believe this was intended to refer to PR c++/70095.

[Bug libstdc++/71364] New: [7 regression] recent tuple changes break range-v3 merge.cpp

2016-05-31 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71364

Bug ID: 71364
   Summary: [7 regression] recent tuple changes break range-v3
merge.cpp
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
CC: ville.voutilainen at gmail dot com
  Target Milestone: ---

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

I periodically check that G++ still builds Eric Niebler's range-v3 properly;
recently the merge.cpp test started failing.  This seems to be due to Ville's
recent tuple change.

[Bug c++/71365] New: [7 Regression] g++ reject access to parent's parent virtual method

2016-05-31 Thread zsojka at seznam dot cz 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71365

Bug ID: 71365
   Summary: [7 Regression] g++ reject access to parent's parent
virtual method
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 38615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38615&action=edit
testcase (from openttd)

Compiler output:
$ g++ accept.C 
accept.C: In member function 'virtual void C::foo()':
accept.C:7:55: error: 'A' is not a base of 'C'
 class C : public B { virtual void foo() { this->A::foo(); } };
   ^~~
I think this code is valid, and it is accepted by all GCC versions up to 6.1.1.
If it is invalid, the error message should be improved to mention, for example,
"direct base". Note the code is accepted if B is not a template.

[Bug libstdc++/71364] [7 regression] recent tuple changes break range-v3 merge.cpp

2016-05-31 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71364

--- Comment #1 from Jason Merrill  ---
Error message:

In file included from include/range/v3/begin_end.hpp:23:0,
 from include/range/v3/core.hpp:17,
 from test/algorithm/merge.cpp:19:
include/range/v3/utility/dangling.hpp: In instantiation of ‘constexpr
ranges::v3::tagged,
ranges::v3::dangling, int*>, ranges::v3::tag::in1, ranges::v3::tag::in2,
ranges::v3::tag::out>
ranges::v3::sanitize_fn::operator(),
ranges::v3::dangling, int*>, ranges::v3::tag::in1, ranges::v3::tag::in2,
ranges::v3::tag::out>(ranges::v3::tagged,
ranges::v3::dangling, int*>, ranges::v3::tag::in1, ranges::v3::tag::in2,
ranges::v3::tag::out>&) const’:
test/algorithm/merge.cpp:88:37:   required from here
include/range/v3/utility/dangling.hpp:154:56: error: could not convert
‘ranges::v3::sanitize_fn::operator(),
ranges::v3::dangling, int*>(std::tuple,
ranges::v3::dangling, int*>&) const((&
tup)->ranges::v3::tagged,
ranges::v3::dangling, int*>, ranges::v3::tag::in1, ranges::v3::tag::in2,
ranges::v3::tag::out>::)’ from
‘std::tuple, ranges::v3::dangling, int*>’ to
‘ranges::v3::tagged,
ranges::v3::dangling, int*>, ranges::v3::tag::in1, ranges::v3::tag::in2,
ranges::v3::tag::out>’

[Bug tree-optimization/71366] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

2016-05-31 Thread su at cs dot ucdavis.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71366

Bug ID: 71366
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
Segmentation fault
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 6.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160531 (experimental) [trunk revision 236912] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-6.1 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: Segmentation fault
 fn1 ()
 ^~~
0xbbd02f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0xd08d70 vec_safe_length
../../gcc-source-trunk/gcc/vec.h:529
0xd08d70 loop_outer
../../gcc-source-trunk/gcc/cfgloop.h:456
0xd08d70 tree_unroll_loops_completely_1
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1347
0xd08ce0 tree_unroll_loops_completely_1
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1314
0xd08ce0 tree_unroll_loops_completely_1
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1314
0xd09013 tree_unroll_loops_completely(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1384
0xd09583 execute
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1593
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


---


int a[1][2], b, c;

int
fn1 ()
{ 
  int d;
  for (; c;)
for (d = 2; d >= 0;)
  { 
int e[4], f = e[3];
if (f)
  return b;
d--;
for (;;)
  { 
c = a[0][d];
break;
  }
  }
  return 0;
}

[Bug libstdc++/71367] New: std::time_get does not implement 'r' or 'p'

2016-05-31 Thread beroset at ieee dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367

Bug ID: 71367
   Summary: std::time_get does not implement 'r' or 'p'
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beroset at ieee dot org
  Target Milestone: ---

Created attachment 38616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38616&action=edit
Short program demonstrating lack of %r support in std::time_get

The "%r" and "%p" formats don't seem to be supported yet for time_get, even
though they are both supported by time_put.  The %p is supposed to be the
locale's version of "AM" and "PM" (if any) and %r is equivalent to %I:%M:%S  %p
in the POSIX locale.

The compiler version:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC) 

Attached is a short program illustrated the bug.

[Bug jit/71334] gccjit's sized integers have different underlying types than stdint.h

2016-05-31 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71334

--- Comment #2 from David Malcolm  ---
For reference, I get this output on x86_64-pc-linux-gnu:

underlying size_t: gcc long unsigned int, gccjit unknown
underlying uint32_t: gcc unsigned int, gccjit unsigned int
underlying uint64_t: gcc long unsigned int, gccjit long long unsigned int

What's happening is that:

(a) gcc_jit_context_get_type returns pointer values
to a type internal to libgccjit (gcc::jit::recording::memento_of_get_type
within jit/jit-recording.[ch]).
The pointer you get back will be the same within a given gcc_jit_context
for a given value of enum gcc_jit_types.

(b) gcc_jit_context_get_int_type looks up the appropriate value for
enum gcc_jit_types and effectively calls gcc_jit_context_get_type on it,
so you get one of the pointer values above.

(c) GCC_JIT_TYPE_SIZE_T is its own value within enum gcc_jit_types, hence you
get a different pointer back.

(d) When the context is compiled, these instances get turned into gcc's "tree"
representation (see jit/jit-playback.c:get_tree_node_for_type), and at this
point, it will be using the same "tree" pointer internally if it's the same
type.   This is all opaque from the POV of the libgccjit client code.

Hopefully this clarifies things.

Is any of this a problem from the point of view of you using the library?  I
know we do some type-checking at the API boundary using pointer comparisons of
gcc_jit_type  * (in recording::type::accepts_writes_from, called from
libgccjit.c:compatible_types).

Hope this is helpful

[Bug ada/71317] Compiling gnat for rtems fails at s-taprop.adb

2016-05-31 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71317

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue May 31 21:28:26 2016
New Revision: 236949

URL: https://gcc.gnu.org/viewcvs?rev=236949&root=gcc&view=rev
Log:
* s-osinte-kfreebsd-gnu.ads (clock_getres): Define.

PR ada/71317
* s-osinte-rtems.ads (clock_getres): Define.

Modified:
branches/gcc-5-branch/gcc/ada/ChangeLog
branches/gcc-5-branch/gcc/ada/s-osinte-kfreebsd-gnu.ads
branches/gcc-5-branch/gcc/ada/s-osinte-rtems.ads

[Bug ada/71317] Compiling gnat for rtems fails at s-taprop.adb

2016-05-31 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71317

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.4

--- Comment #6 from Eric Botcazou  ---
Thanks for reporting and fixing the problem.

  1   2   >