[Bug c++/69549] New: Named Address Spaces does not compile in C++

[thiago at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549

Bug ID: 69549
   Summary: Named Address Spaces does not compile in C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

It works in C:

$ cat test.c
__seg_gs char * ptr;
$ gcc -c test.c && echo Success
Success

But not in C++:

$ gcc -xc++ -c test.c
test.c:1:1: error: ‘__seg_gs’ does not name a type

Even though it's advertised as supported:

$ gcc -xc++ -dM -E /dev/null | grep SEG_GS   
#define __SEG_GS 1

[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes

[balakrishnan.erode at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143

Balakrishnan B  changed:

   What|Removed |Added

Version|4.9.2   |5.3.0
  Known to fail||5.3.0
   Severity|normal  |major

[Bug middle-end/69545] [6 Regression] FAIL: gfortran.dg/graphite/pr42285.f90 -O (internal compiler error)

[spop at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69545

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #2 from Sebastian Pop  ---
Fixed in r232966 by reverting r232939.

[Bug target/69548] New: libatomic fails to build with -Os on powerpc64-linux

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69548

Bug ID: 69548
   Summary: libatomic fails to build with -Os on powerpc64-linux
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

Compiling the following testcase on gcc-5 or gcc-4.9 with -Os -mcpu=power8
-mbig -S

typedef unsigned U_16 __attribute__((mode(TI)));
U_16
libat_exchange_16 (U_16 *mptr, U_16 newval)
{
  return __atomic_exchange_n (mptr, newval, 5);
}

results in an assembler error "Error: operand out of domain (7 is not a
multiple of 2)"

The failing insn is "lqarx 7,0,9".

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

--- Comment #11 from H.J. Lu  ---
(In reply to H.J. Lu from comment #10)
> Created attachment 37512 [details]
> A new patch
> 
> I am testing this now.

No regressions on x86-64.  I will leave it to Vladimir.

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-29
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
The memory clobber stays until almost the end.
Confirmed.  Hmm, I thought there was another bug like this which talks about
the same issue.

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547

--- Comment #2 from Martin Sebor  ---
The problem first appeared with r222135.

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |6.0

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547

Martin Sebor  changed:

   What|Removed |Added

  Known to work||5.3.0
Summary|no-op array initializer |[6 regression] no-op array
   |emits an empty loop |initializer emits an empty
   ||loop
  Known to fail||6.0

--- Comment #1 from Martin Sebor  ---
As it turns out, GCC 5.3.0 generates code without the loop, so this can be
considered a regression.

[Bug middle-end/69547] New: no-op array initializer emits an empty loop

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547

Bug ID: 69547
   Summary: no-op array initializer emits an empty loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Given code like the following, even at -O2 GCC emits a loop iterating over all
the uninitialized elements in the array.

struct A { A () { } };

void foo (void*, int);

void bar () {
enum { N = 64 };
A a [N];
foo (&a, N);
}

For example, the powerpc64le object code looks like this but the same no-op
loop can be found in x86_64 object code:

 <_Z3barv>:
   0:   00 00 4c 3c addis   r2,r12,0
   4:   00 00 42 38 addir2,r2,0
   8:   a6 02 08 7c mflrr0
   c:   40 00 20 39 li  r9,64
  10:   a6 03 29 7d mtctr   r9
  14:   10 00 01 f8 std r0,16(r1)
  18:   a1 ff 21 f8 stdur1,-96(r1)
  1c:   00 00 42 60 ori r2,r2,0
  20:   00 00 00 42 bdnz20 <_Z3barv+0x20>   <<< no-op loop on ctr
  24:   20 00 61 38 addir3,r1,32
  28:   40 00 80 38 li  r4,64
  2c:   01 00 00 48 bl  2c <_Z3barv+0x2c>
  30:   00 00 00 60 nop
  34:   60 00 21 38 addir1,r1,96
  38:   10 00 01 e8 ld  r0,16(r1)
  3c:   a6 03 08 7c mtlrr0
  40:   20 00 80 4e blr

I expected the loop to be eliminated by the middle end but I can see it even in
the last optimization pass:

u.cpp.210t.optimized

;; Function void bar() (_Z3barv, funcdef_no=3, decl_uid=2141, cgraph_uid=3,
symbol_order=3)

Removing basic block 5
void bar() ()
{
  unsigned long ivtmp.12;
  struct A a[64];
  unsigned long _10;
  struct A * _15;

  :
  ivtmp.12_14 = (unsigned long) &a;
  _10 = (unsigned long) &MEM[(void *)&a + 64B];

  :
  # ivtmp.12_13 = PHI 
  _15 = (struct A *) ivtmp.12_13;
  ivtmp.12_12 = ivtmp.12_13 + 1;
  if (_10 == ivtmp.12_12)
goto ;
  else
goto ;

  :
  foo (&a, 64);
  a ={v} {CLOBBER};
  return;

}

[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546

--- Comment #2 from Jakub Jelinek  ---
Will have a look.

[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-29
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This started with r210113.

[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/69533] [6 Regression] python miscompilation

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
I've reproduced this and I'm now bisecting.

[Bug middle-end/69546] New: [5/6 Regression] wrong code with -O and simple int128 arithmetics

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546

Bug ID: 69546
   Summary: [5/6 Regression] wrong code with -O and simple int128
arithmetics
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*, aarch64-*, powerpc64-*, sparc64-*

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

Output:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-232939-checking-yes-rtl-df-nobootstrap-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --disable-bootstrap --without-cloog --without-ppl
--without-isl --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-232939-checking-yes-rtl-df-nobootstrap-nographite
Thread model: posix
gcc version 6.0.0 20160128 (experimental) (GCC) 

$ gcc -O testcase.c
$ ./a.out 

Aborted

All tested __int128-capable targets are affected. (x86_64, powerpc64, aarch64,
sparc64)

Tested revisions:
r232939 - FAIL (after PR69399 fix)
5-branch r232545 - FAIL
4_9-branch r232544 - OK
4_[678]-branch - OK

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69542

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/69545] [6 Regression] FAIL: gfortran.dg/graphite/pr42285.f90 -O (internal compiler error)

[spop at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69545

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #1 from Sebastian Pop  ---
I guess this issue is due to isl-0.14.  With isl-0.15 it is passing.
I will have a look.

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506

--- Comment #4 from Jonathan Wakely  ---
OK thanks, I'll commit it tomorrow.

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506

--- Comment #3 from Roger Orr  ---
Tested: bootstrap build on cygwin with your patch completed successfully.

I used:
../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcc-trunk
make -j5
make install

Thank you :-)

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[gang.chen.5i5j at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901

--- Comment #22 from Chen Gang  ---
(In reply to Mark Wielaard from comment #21)

[...]

> Although in C a static const is not really like a #define I suspect that
> there are cases where they are used as such in header files. If that is the
> major reason for why there are people opposed to the warning then what we
> could do is hide such (non-)usage of static const variables from header
> files behind -Wextra and only explicitly warn for static const variable
> defined (and then not used) in the main file.
> 

For me, what you said above sounds reasonable. :-)

[Bug pch/68176] [4.9/5 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] all|[4.9/5 Regression] all pch
   |pch tests fail on eglibc|tests fail on eglibc
   |systems (with   |systems (with
   |bits/predefs.h) |bits/predefs.h)

--- Comment #13 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 28 22:35:20 2016
New Revision: 232956

URL: https://gcc.gnu.org/viewcvs?rev=232956&root=gcc&view=rev
Log:
PR pch/68176
* files.c (_cpp_find_file): Set file->implicit_preinclude even if
included from file->implicit_preinclude header.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/files.c

[Bug fortran/69520] Implement reversal of -fcheck options

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
> I don't have a strong opinion on whether the prefix for disabling
> should be "no" or "no-", or whether both should be accepted.
> The present patch implements the first variant.  If there is some
> guideline to use the latter, the changes are obviously trivial.

I'ld prefer "no-".

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 28 22:32:47 2016
New Revision: 232955

URL: https://gcc.gnu.org/viewcvs?rev=232955&root=gcc&view=rev
Log:
PR target/69459
* config/i386/constraints.md (C): Only accept constant zero operand.
(BC): New constraint.
* config/i386/sse.md (*mov_internal): Use BC constraint
instead of C constraint.
* doc/md.texi (Machine Constraints): Update description
of C constraint.

testsuite/ChangeLog:

PR target/69459
* gcc.target/i386/pr69459.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr69459.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/md.texi
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/69543] [6 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543

--- Comment #1 from David Malcolm  ---
Breakpoint 4, linemap_compare_locations (set=0x77ff6000, pre=2147483641,
post=post@entry=2147483656) at ../../src/libcpp/line-map.c:1326

(gdb) call inform (2147483641, "pre=2147483641")
../../src/gcc/testsuite/c-c++-common/pr69453.c: In function ‘test’:
../../src/gcc/testsuite/c-c++-common/pr69453.c:6:5: note: pre=2147483641
 _Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
 ^
../../src/gcc/testsuite/c-c++-common/pr69453.c:13:3: note: in expansion of
macro ‘YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN’
   YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
   ^
(gdb) p /x 2147483641
$15 = 0x7ff9

(gdb) call inform (2147483656, "post=2147483656")
../../src/gcc/testsuite/c-c++-common/pr69453.c:14:12: note: post=2147483656
   *++yyvsp = yylval;
   ~^~~~
(gdb) p /x 2147483656
$8 = 0x8008

(gdb) p l0
$16 = 2147483641
(gdb) p l1
$17 = 312096
(gdb) p /x l0
$18 = 0x7ff9

Then, after the call to:
1338  if ((pre_virtual_p = linemap_location_from_macro_expansion_p (set,
l0)))
1339l0 = linemap_resolve_location (set, l0,
1340   LRK_MACRO_EXPANSION_POINT,
1341   NULL);
1342
we have:
(gdb) p /x l0
$21 = 0x8004

so we have a comparison of locations, one (l0) from a macro expansion, the
other not (l1).

linemap_compare_locations concludes by executing this:
1368  return l1 - l0;
giving this rather nonsensical result:
Value returned is $25 = -2147171556

If I'm reading this right, it thus regards the "ignored" as happening *after*
the source line of interest, hence the latter erroneously isn't affected by the
_Pragma.

[Bug fortran/69544] [5/6 Regression] Internal compiler error with -Wall and where

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 CC||manu at gcc dot gnu.org
Summary|Internal compiler error |[5/6 Regression] Internal
   |with -Wall and where|compiler error with -Wall
   ||and where
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed as a regression between revisions r217961 (2014-11-22, warning) and
r218255 (2014-12-02, ICE). The warning was



Warning: CHARACTER expression will be truncated in assignment (8/12) at (1)

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37509|0   |1
is obsolete||

--- Comment #10 from H.J. Lu  ---
Created attachment 37512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37512&action=edit
A new patch

I am testing this now.

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68400

--- Comment #6 from Steve Ellcey  ---
Author: sje
Date: Thu Jan 28 22:28:04 2016
New Revision: 232954

URL: https://gcc.gnu.org/viewcvs?rev=232954&root=gcc&view=rev
Log:
PR target/68400
* gcc.target/mips/mips.exp (mips_option_groups): Add stack-protector.
* gcc.target/mips/pr68400.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr68400.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/mips.exp

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68400

--- Comment #5 from Steve Ellcey  ---
Author: sje
Date: Thu Jan 28 22:25:55 2016
New Revision: 232952

URL: https://gcc.gnu.org/viewcvs?rev=232952&root=gcc&view=rev
Log:
2016-01-28  Steve Ellcey  

PR target/68400
* config/mips/mips.c (and_operands_ok): Add MIPS16 check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

--- Comment #9 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #8)
> Is the r229087 change still needed after r229458?

Backout r229087 doesn't cause gcc.target/i386/pr67609-2.c nor 
gcc.target/i386/pr67609.c to fail.

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176

--- Comment #11 from Nix  ---
Confirmed fixed (properly this time).

[Bug middle-end/69545] New: [6 Regression] FAIL: gfortran.dg/graphite/pr42285.f90 -O (internal compiler error)

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69545

Bug ID: 69545
   Summary: [6 Regression] FAIL: gfortran.dg/graphite/pr42285.f90
 -O  (internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: spop at gcc dot gnu.org
  Target Milestone: ---

On Fedora x86-64, r232939 gave

FAIL: gfortran.dg/graphite/pr42285.f90   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42285.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr42334-1.f   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42334-1.f   -O  (test for excess errors)

pawn -ignore SIGHUP
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../gfortran
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gfortran/../../
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libgfortran/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -O2 -floop-interchange
-S -o pr42334-1.s
/export/gnu/import/git/sources/gcc/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f:3:0:
internal compiler error: in get_rename_from_scev, at
graphite-isl-ast-to-gimple.c:1591
0x17f5a2d translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, basic_block_def*, basic_block_def*, vec)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1591
0x17f6050 translate_isl_ast_to_gimple::rename_uses(gimple*,
gimple_stmt_iterator*, basic_block_def*, loop*, vec)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1720
0x17f867d
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:2585
0x17f8e15
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:2798
0x17f3a9d
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:935
0x17f3e6b translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1039
0x17f3bb7 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:964
0x17f3e8c translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1043
0x17f31b9 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:685
0x17f3764 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:854
0x17f3e30 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1032
0x17f31b9 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:685
0x17f36ef translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:846
0x17f3e30 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1032
0x17f3bb7 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:964
0x17f3e8c translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:1043
0x17f9a92 graphite_regenerate_ast_isl(scop*)
   
/export/gnu/import/git/sources/gcc/gcc/graphite-isl-ast-to-gimple.c:3172
0x17f09c3 graphite_transform_loops()
/export/gnu/import/git/sources/gcc/gcc/graphit

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[joshuahykes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

Josh Hykes  changed:

   What|Removed |Added

 CC||joshuahykes at yahoo dot com

--- Comment #17 from Josh Hykes  ---
I think the problem I'm seeing is the same issue; I'm posting it here for an
additional test case:

$ cat scan_bug.f90 
   module test_mod
!
   type t1
  character(8)  :: string
   end type t1
!
   type t2
 type(t1), pointer :: fp(:)
   end type t2
!
   type t3
  type(t2), pointer :: as
   end type t3
!
   type(t3), pointer :: as_typ(:)=>null()
!
   character(8),  pointer, public :: p(:)
!
   contains
!
   subroutine as_set_alias (i)
!
   implicit none
!
   integer, intent(in):: i
!
 p => as_typ(i)%as%fp(:)%string
!
   end subroutine as_set_alias
!
   end module test_mod

   program test_prog
   use test_mod
   call as_set_alias(1)
   end program test_prog

$ gfortran scan_bug.f90 
/tmp/cccR3cNH.o: In function `__test_mod_MOD_as_set_alias':
scan_bug.f90:(.text+0x139): undefined reference to `span.0'
collect2: error: ld returned 1 exit status

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/joshua2/opt/gcc/linux-64/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/configure
--prefix=/home/joshua2/opt/gcc/linux-64/gcc-5.1.0
Thread model: posix
gcc version 5.1.0 (GCC)

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[kelvin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #7 from kelvin at gcc dot gnu.org ---
The "official" description of the built-in atomic operations
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html) states "GCC
allows any integral scalar or pointer type that is 1, 2, 4, or 8 bytes in
length. 16-byte integral types are also allowed if ‘__int128’ (see __int128) is
supported by the architecture."

It appears that this test case represents illegal source code.  (Rather than
aborting with an internal compiler error, the compiler should report an error
message due to the illegal use of this built-in API.)

[Bug target/57816] ICE compiling __builtin_sqrt with powerpc-none-eabispe with -mpowerpc-gpopt

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57816

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
The test case compiles successfully with this week's trunk configured with
--host=x86_64-pc-linux-gnu --target=powerpc-eabispe.  Please reopen this bug if
I missed something and it still fails for you.

$ cat t.c && /build/sysroot/powerpc-eabispe/bin/powerpc-eabispe-gcc -c -O2
-ffast-math -fno-inline -fno-unroll-loops -mpowerpc-gpopt -fno-ident t.c
void
foo (double x, double y)
{
if (x != __builtin_sqrt (y))
  __builtin_abort ();
}

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69542

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 28 21:08:23 2016
New Revision: 232949

URL: https://gcc.gnu.org/viewcvs?rev=232949&root=gcc&view=rev
Log:
PR middle-end/69542
* lra-remat.c (calculate_local_reg_remat_bb_data): Only consider
non-debug insns.

* gcc.dg/torture/pr69542.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69542.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-remat.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module procedure"

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
I could be wrong but I do not agree that this is valid code. I will turn to it
tomorrow. I believe that a MODULE SUBROUTINE/FUNCTION declaration cannot appear
in the contained part of a module.

This is the legal version, which compiles correctly:
module A

  interface
 module subroutine A1(i)
   integer i
 end subroutine A1
  end interface
end module

submodule(a) a_son
contains

  module subroutine A1(i)
integer  i

print *, 'A::A1(): i == ', i
  end subroutine A1
end submodule


I will check the standard and, either way, I will fix the problem.

Paul

[Bug target/17381] Unnecessary register move for float extend

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17381

--- Comment #9 from Martin Sebor  ---
Author: msebor
Date: Thu Jan 28 21:05:39 2016
New Revision: 232947

URL: https://gcc.gnu.org/viewcvs?rev=232947&root=gcc&view=rev
Log:
PR target/17381 - Unnecessary register move for float extend

2016-01-28  Martin Sebor  

PR target/17381
* gcc.target/powerpc/pr17381.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr17381.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69542

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 28 21:01:51 2016
New Revision: 232946

URL: https://gcc.gnu.org/viewcvs?rev=232946&root=gcc&view=rev
Log:
PR middle-end/69542
* lra-remat.c (calculate_local_reg_remat_bb_data): Only consider
non-debug insns.

* gcc.dg/torture/pr69542.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69542.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-remat.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Is the r229087 change still needed after r229458?

[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Note, this regressed with r225463.

[Bug target/3920] [PPC] wrong register number for CTR in stabs

[mattiase at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3920

--- Comment #10 from Mattias Engdegård  ---
Stabs is rather obsolete and I don't personally care about it any more. As far
as I can tell from the source (GCC 5.3 and GDB 7.10), the problem (wrong CTR
numbering in stabs) is still there, but if it were up to me I wouldn't waste
any time on it.

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #37510|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

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

Updated patch in testing.

[Bug fortran/69544] New: Internal compiler error with -Wall and where

[joshuahykes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544

Bug ID: 69544
   Summary: Internal compiler error with -Wall and where
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joshuahykes at yahoo dot com
  Target Milestone: ---

Adding -Wall causes a compiler error on code that compiles okay without -Wall.
See example:


$ cat where_ice.f90 
   subroutine where_ice (i,j)
!
   implicit none
!
   integer, parameter :: n = 10

   real(4)   :: x(n,n,2)
   character(8)  :: y(n,n,2)
!
   integer   :: i
   integer   :: j
   real(4)   :: arr(n)
!
   character(12) :: txt(5)
!
   where (arr(1:9) > -1.e+6)  x(1:9,i,j) = arr(1:9)
   where (txt(1:3) /= ''   )  y(1:3,i,j) = txt(1:3)
!
   end subroutine where_ice


$ gfortran -c where_ice.f90 


$ gfortran -Wall -c where_ice.f90 

in gfc_format_decoder, at fortran/error.c:1121
0x5e0fae gfc_format_decoder
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/error.c:1121
0x10479bf pp_format(pretty_printer*, text_info*)
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/pretty-print.c:613
0x1044d7d diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/diagnostic.c:865
0x5e260a gfc_warning_now(int, char const*, ...)
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/error.c:1244
0x644997 resolve_ordinary_assign
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/resolve.c:9367
0x644997 gfc_resolve_code(gfc_code*, gfc_namespace*)
   
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/resolve.c:10182
0x642157 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/resolve.c:9254
0x64243c gfc_resolve_code(gfc_code*, gfc_namespace*)
   
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/resolve.c:10081
0x644d92 resolve_codes
   
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/resolve.c:15055
0x644e72 gfc_resolve(gfc_namespace*)
   
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/resolve.c:15083
0x63081a resolve_all_program_units
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/parse.c:5280
0x63081a gfc_parse_file()
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/parse.c:5523
0x670355 gfc_be_parse_file
/home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/gcc/fortran/f95-lang.c:228
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/joshua2/opt/gcc/linux-64/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/configure
--prefix=/home/joshua2/opt/gcc/linux-64/gcc-5.1.0
Thread model: posix
gcc version 5.1.0 (GCC)

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #10 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #9)
> We need to adjust md.texi too.
> Also, I see there are 7 different uses of constraint "C" in i386.md with
> general_operand predicate, are you sure you don't want "BC" for those?
> Stuff like
> *movti_internal
> *movdi_internal
> *movsi_internal
> *movtf_internal
> *movxf_internal
> *movdf_internal
> *movsf_internal
> Though, all those don't use vector mode on those operands, and I bet
> standard_sse_constant_p in that case never returns 2, so maybe that is fine.

Yes this is fine. The function checks for vector mode, which is never the case
in above examples. We could introduce nonimmediate_or_sse_const_operand with
corresponding BC constraint, but not today.

> But then there is another thing, the old "C" would never match anything, not
> even the const0_rtx/CONST0_RTX, if !TARGET_SSE, while your patch matches it
> no matter whether -msse is on or not.  E.g. for the above mentioned
> *mov*_internal insns, but there it is used if the destination is y, x, v
> constraint.  But e.g. in *movxf_internal it is into o.

Indeed. Let's write "C" constraint to check
"standard_sse_constant_p (...) == 1".

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #9 from Jakub Jelinek  ---
We need to adjust md.texi too.
Also, I see there are 7 different uses of constraint "C" in i386.md with
general_operand predicate, are you sure you don't want "BC" for those?
Stuff like
*movti_internal
*movdi_internal
*movsi_internal
*movtf_internal
*movxf_internal
*movdf_internal
*movsf_internal
Though, all those don't use vector mode on those operands, and I bet
standard_sse_constant_p in that case never returns 2, so maybe that is fine.

But then there is another thing, the old "C" would never match anything, not
even the const0_rtx/CONST0_RTX, if !TARGET_SSE, while your patch matches it no
matter whether -msse is on or not.  E.g. for the above mentioned *mov*_internal
insns, but there it is used if the destination is y, x, v constraint.  But e.g.
in *movxf_internal it is into o.

[Bug preprocessor/69543] New: _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543

Bug ID: 69543
   Summary: _Pragma does not apply within macro
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02243.html
reported a regression introduced by r232893 (for PR preprocessor/69126)

Minimal reproducer seems to be:
$ cat /tmp/test.c
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wuninitialized\"")\
_Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
# define YY_IGNORE_MAYBE_UNINITIALIZED_END \
_Pragma ("GCC diagnostic pop")

void test (char yylval)
{
  char *yyvsp;
  YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
  *++yyvsp = yylval;
  YY_IGNORE_MAYBE_UNINITIALIZED_END
}

$ ./xgcc -B. -c /tmp/test.c -Wall
/tmp/test.c: In function 'test':
/tmp/test.c:12:12: warning: 'yyvsp' is used uninitialized in this
function [-Wuninitialized]
   *++yyvsp = yylval;
   ~^~~~

$ ./xgcc -B. -c /tmp/test.c -save-temps
$ ./xgcc -B. -c test.i -Wall
(compiles with no warnings)

[Bug target/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02245.html

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

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

Patch in testing.

[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module procedure"

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
Summary|[6 Regression] Compiler |[6 Regression] [F08]
   |segfaults on invalid|Compiler segfaults on
   |testcase|"module procedure"

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> The only place where I find "module subroutine" is in codes related to
> submodules.

Ah, good point. Unfortunately I'm completely ignorant of all the submodule
stuff. So the test case may be valid after all (not sure about that) ...

[Bug target/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Let me propose a fix for the test.

[Bug fortran/69524] [6 Regression] Compiler segfaults on invalid testcase

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Dominique d'Humieres  ---
> > With gfortran 5.2.1, I do not get an ICE, but several errors, starting with:
> > 
> >   module subroutine A1(i)
> >  1
> > Error: Unclassifiable statement at (1)
>
> I guess the main question is why this error is not being triggered on trunk.

The only place where I find "module subroutine" is in codes related to
submodules.

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176

--- Comment #10 from Nix  ---
Argh, scratch that -- I need to test a tree that *doesn't* have the original
patch reverted! Doing that now, will report back once that's done.

[Bug fortran/69524] [6 Regression] Compiler segfaults on invalid testcase

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[6 Regression] Compiler |[6 Regression] Compiler
   |segfaults on simple |segfaults on invalid
   |testcase|testcase

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> With gfortran 5.2.1, I do not get an ICE, but several errors, starting with:
> 
>   module subroutine A1(i)
>  1
> Error: Unclassifiable statement at (1)

I guess the main question is why this error is not being triggered on trunk.

[Bug fortran/69524] [6 Regression] Compiler segfaults on simple testcase

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524

--- Comment #3 from janus at gcc dot gnu.org ---
Here is a slightly reduced test case:

module A
  interface
module subroutine A1
end
  end interface
contains
  subroutine A1
  end
end

It's still invalid, but gives less errors with gfortran-5.

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > 
> > > I'd say the i386 backend just should add a new constraint for CONST0_RTX
> > > only and use it wherever the all ones is not allowed.  As "C" is 
> > > documented,
> > > probably the new "BC" constraint should be const0/CONST0_RTX only, and I
> > > think at least the vector_move_operand, reg_or_0_operand and likely the
> > > const_int_operand cases too should be changed to "BC".  At least that way
> > > the RA and other spots will not try to satisfy it with something that 
> > > can't
> > > match.
> > 
> > Yes, let's go this way.
> 
> Ok, will work on it tomorrow.

Heh, it looks we can change "C" constraint to mean only zero. Please consider
following testcase:

--cut here--
typedef int __v4si __attribute__ ((__vector_size__ (16)));

void test (void)
{
  asm volatile ("%0" : : "C" ( (__v4si) { -1, -1, -1, -1 } ));
}
--cut here--

This is the only way "C" constraint can be satisfied by non-zero operand.
Trying to compile this, we get:

c.c: In function ‘test’:
c.c:6:1: internal compiler error: in ix86_print_operand, at
config/i386/i386.c:17289

17284 /* We have patterns that allow zero sets of memory, for instance.
17285In 64-bit mode, we should probably support all 8-byte vectors,
17286since we can in fact encode that into an immediate.  */
17287 if (GET_CODE (x) == CONST_VECTOR)
17288   {
17289 gcc_assert (x == CONST0_RTX (GET_MODE (x)));
17290 x = const0_rtx;
17291   }

Based on this evidence, there is no way "C" constraint ca be used with non-zero
immediate. So, let's change "C" constraint to:

;; This can theoretically be any mode's CONST0_RTX.
(define_constraint "C"
  "Constant zero."
  (match_test "op == const0_rtx || op == CONST0_RTX (GET_MODE (op))"))

and add new BC constraint

(define_constraint "BC"
  "@internal SSE constant operand."
  (match_test "standard_sse_constant_p (op)"))

that is used only in SSE move pattern:

(define_insn "*mov_internal"
  [(set (match_operand:VMOVE 0 "nonimmediate_operand"   "=v,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand" 
"BC,vm,v"))]
  "TARGET_SSE
   && (register_operand (operands[0], mode)
   || register_operand (operands[1], mode))"

[Bug fortran/69524] [6 Regression] Compiler segfaults on simple testcase

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
  Known to work||5.2.1
Summary|[ICE] [F95] Compiler|[6 Regression] Compiler
   |segfaults on simple |segfaults on simple
   |testcase @ -O0  |testcase
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> With gfortran 5.2.1, I do not get an ICE

However, I can indeed reproduce the ICE with trunk. Thus, it's a regression.

[Bug fortran/69484] [5 Regression] documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69484

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from janus at gcc dot gnu.org ---
Fixed on trunk and the gcc-5 branch. Closing.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355

--- Comment #24 from Jakub Jelinek  ---
(In reply to Martin Jambor from comment #23)
> The testcase I posted to comment #19 fails also on the 4.9 branch so I
> will test and commit the patch there too.
> 
> Jakub, can I close the bug afterwards or do you want to backport the
> gcc/tree-dfa.c (the patch in comment#11) to gcc 5 as well?

If the bug is fixed in gcc 5 and/or 4.9 through your patch, the tree-dfa.c
change is not needed there, let's keep tree-dfa.c as is there.

[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535

Richard Henderson  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #3 from Richard Henderson  ---
Combine turns

(insn 35 33 36 2 (parallel [
(set (reg:SI 123 [ u32_2 ])
(lshiftrt:SI (reg/v:SI 108 [ u32_2 ])
(reg/v:QI 94 [ u8_3 ])))
(clobber (reg:CC 17 flags))
]) z.c:21 562 {*lshrsi3_1}
 (expr_list:REG_DEAD (reg/v:SI 108 [ u32_2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 36 35 59 2 (set (reg:DI 125 [ u32_2 ])
(zero_extend:DI (reg:SI 123 [ u32_2 ]))) z.c:22 131 {*zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SI 123 [ u32_2 ])
(nil)))
...
(insn 37 59 38 2 (set (subreg:DI (reg:TI 124 [ u32_2 ]) 0)
(reg:DI 125 [ u32_2 ])) z.c:22 85 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 125 [ u32_2 ])
(nil)))

into

(note 35 33 36 2 NOTE_INSN_DELETED)
(note 36 35 59 2 NOTE_INSN_DELETED)
(insn 37 59 38 2 (set (subreg:DI (reg:TI 124 [ u32_2 ]) 0)
(subreg:DI (reg/v:SI 108 [ u32_2 ]) 0)) z.c:22 85 {*movdi_internal}
 (expr_list:REG_DEAD (reg/v:SI 108 [ u32_2 ])
(nil)))

I'm not sure how it decided to drop the lshiftrt, but the change
from (zero_extend:DI (reg:SI X)) to (subreg:DI (reg:SI X)) is
completely invalid.  The final rtl explicitly says that the high
32 bits of the DImode value are unused, which from the PR is
obviously wrong.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355

--- Comment #23 from Martin Jambor  ---
The testcase I posted to comment #19 fails also on the 4.9 branch so I
will test and commit the patch there too.

Jakub, can I close the bug afterwards or do you want to backport the
gcc/tree-dfa.c (the patch in comment#11) to gcc 5 as well?

[Bug fortran/69484] [5 Regression] documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69484

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Jan 28 18:42:36 2016
New Revision: 232940

URL: https://gcc.gnu.org/viewcvs?rev=232940&root=gcc&view=rev
Log:
2016-01-28  Janus Weil  

PR fortran/69484
* invoke.texi: Fix documentation of -Wall with respect to -Wtabs.

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/invoke.texi

[Bug target/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-28
 CC||rth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Henderson  ---
Confirmed.

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

--- Comment #7 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to H.J. Lu from comment #5)
> > Created attachment 37509 [details]
> > A patch
> > 
> > I am testing this.
> 
> Many post-reload splitters in i386.md check their operands with REG_P, based
> on the premise that there are no subregs after registers are allocated.
> 
> I don't know what will break if this is not the case anymore.

I think subregs of vector registers are special.  We need to exam all
SSE_REG_P usage in *.md files.

[Bug target/68543] [AArch64] Implement overflow arithmetic standard names {u,}{add,sub,mul}v4 and/or negv3

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68543

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 CC||rth at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #5 from Richard Henderson  ---
Confirmed.

Note that negv3 isn't required if subv4 accepts zero as
its first argument.

I don't believe that there is anything that aarch64 can usefully do
with mulv4 -- generic code should use the widening multiplies
as efficiently as anything we can do.

Patch for some of this at

  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01903.html

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

--- Comment #6 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #5)
> Created attachment 37509 [details]
> A patch
> 
> I am testing this.

Many post-reload splitters in i386.md check their operands with REG_P, based on
the premise that there are no subregs after registers are allocated.

I don't know what will break if this is not the case anymore.

[Bug rtl-optimization/69447] [5 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447

--- Comment #22 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Henderson from comment #21)
> Fixed.

Thanks, but I think there's been some fallout in PR 69447.

[Bug rtl-optimization/69447] [5 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #21 from Richard Henderson  ---
Fixed.

[Bug rtl-optimization/69447] [5 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447

--- Comment #20 from Richard Henderson  ---
Author: rth
Date: Thu Jan 28 18:11:27 2016
New Revision: 232938

URL: https://gcc.gnu.org/viewcvs?rev=232938&root=gcc&view=rev
Log:
PR rtl-opt/69447

  * lra-remat.c (subreg_regs): New.
  (dump_candidates_and_remat_bb_data): Dump it.
  (operand_to_remat): Reject if operand in subreg_regs.
  (set_bb_regs): Collect subreg_regs.
  (lra_remat): Init and free subreg_regs.  Compute
  calculate_local_reg_remat_bb_data before create_cands.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr69447.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-remat.c

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176

--- Comment #9 from Nix  ---
Tested on the same old GCC 4.9 build tree and eglibc system that failed in the
original report (for maximum reproducibility): it works, the regression is
cured.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355

--- Comment #22 from Martin Jambor  ---
Author: jamborm
Date: Thu Jan 28 18:04:00 2016
New Revision: 232937

URL: https://gcc.gnu.org/viewcvs?rev=232937&root=gcc&view=rev
Log:
[PR 69355] Correct hole detection when total_scalarization fails

2016-01-28  Martin Jambor  

PR tree-optimization/69355
* tree-sra.c (analyze_access_subtree): Correct hole detection when
total_scalarization fails.

testsuite/
* gcc.dg/tree-ssa/pr69355.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-sra.c

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #6 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> 
> > I'd say the i386 backend just should add a new constraint for CONST0_RTX
> > only and use it wherever the all ones is not allowed.  As "C" is documented,
> > probably the new "BC" constraint should be const0/CONST0_RTX only, and I
> > think at least the vector_move_operand, reg_or_0_operand and likely the
> > const_int_operand cases too should be changed to "BC".  At least that way
> > the RA and other spots will not try to satisfy it with something that can't
> > match.
> 
> Yes, let's go this way.

Ok, will work on it tomorrow.
> 
> > And then there is the question if and what should change on the LRA side.
> 
> IMO, to avoid issues like this, ICE with unrecognized insn should be
> triggered when operand satisfies constraint, but not predicate.

If I manually set INSN_CODE to -1 when recog in lra fails, I get the ICE later
on.

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530

--- Comment #5 from H.J. Lu  ---
Created attachment 37509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37509&action=edit
A patch

I am testing this.

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305

--- Comment #13 from Richard Henderson  ---
Author: rth
Date: Thu Jan 28 17:48:22 2016
New Revision: 232936

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

  * config/aarch64/aarch64-modes.def (CC_Cmode): New
  * config/aarch64/aarch64-protos.h: Update.
  * config/aarch64/aarch64.c (aarch64_zero_extend_const_eq): New.
  (aarch64_select_cc_mode): Add check for use of CC_Cmode.
  (aarch64_get_condition_code_1): Handle CC_Cmode.
  * config/aarch64/aarch64.md (addti3): Use adddi3_compareC.
  (*add3_compareC_cconly_imm): New.
  (*add3_compareC_cconly): New.
  (*add3_compareC_imm): New.
  (add3_compareC): New.
  (add3_carryin, *addsi3_carryin_uxtw): Sort compare operand
  to be first.  Use aarch64_carry_operation.
  (*add3_carryin_alt1, *addsi3_carryin_alt1_uxtw): Remove.
  (*add3_carryin_alt2, *addsi3_carryin_alt2_uxtw): Remove.
  (*add3_carryin_alt3, *addsi3_carryin_alt3_uxtw): Remove.
  (subti3): Use subdi3_compare1.
  (*sub3_compare0): Rename from sub3_compare0.
  (sub3_compare1): New.
  (*sub3_carryin0, *subsi3_carryin_uxtw): New.
  (*sub3_carryin): Use aarch64_borrow_operation.
  (*subsi3_carryin_uxtw): Likewise.
  (*ngc, *ngcsi_uxtw): Likewise.
  (*sub3_carryin_alt, *subsi3_carryin_alt_uxtw): New.
  * config/aarch64/iterators.md (DWI): New.
  * config/aarch64/predicates.md (aarch64_carry_operation): New.
  (aarch64_borrow_operation): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-modes.def
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/iterators.md
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/gcc.target/aarch64/ccmp_1.c
trunk/gcc/testsuite/gcc.target/aarch64/tst_3.c

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)

> I'd say the i386 backend just should add a new constraint for CONST0_RTX
> only and use it wherever the all ones is not allowed.  As "C" is documented,
> probably the new "BC" constraint should be const0/CONST0_RTX only, and I
> think at least the vector_move_operand, reg_or_0_operand and likely the
> const_int_operand cases too should be changed to "BC".  At least that way
> the RA and other spots will not try to satisfy it with something that can't
> match.

Yes, let's go this way.

> And then there is the question if and what should change on the LRA side.

IMO, to avoid issues like this, ICE with unrecognized insn should be triggered
when operand satisfies constraint, but not predicate.

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69542

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
2016-01-28  Jakub Jelinek  

PR middle-end/69542
* lra-remat.c (calculate_local_reg_remat_bb_data): Only consider
non-debug insns.

--- gcc/lra-remat.c.jj  2016-01-28 15:07:24.0 +0100
+++ gcc/lra-remat.c 2016-01-28 18:24:43.778297120 +0100
@@ -694,7 +694,7 @@ calculate_local_reg_remat_bb_data (void)

   FOR_EACH_BB_FN (bb, cfun)
 FOR_BB_INSNS (bb, insn)
-  if (INSN_P (insn))
+  if (NONDEBUG_INSN_P (insn))
set_bb_regs (bb, insn);
 }

fixes this, just waiting for testcase and will bootstrap/regtest it.

[Bug middle-end/69542] New: [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69542

Bug ID: 69542
   Summary: [6 Regression] -fcompare-debug failure in
simplify-rtx.c on i?86 since r232905
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

r232905 breaks bootstrap on i686-linux, with miscompare of simplify-rtx.o.
I'm still reducing testcase for this, but have bisected it to this commit
already.
Guess either the
 if (regno >= FIRST_PSEUDO_REGISTER && reg->subreg_p)
680  bitmap_set_bit (&subreg_regs, regno);
or perhaps the whole set_bb_regs function should not be called for DEBUG_INSNs.
I think it shouldn't contain any type != OP_IN regs anyway, nor REG_DEAD notes.

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69542

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69450

--- Comment #15 from Jonathan Wakely  ---
Amker, if you're talking about aarch64-*-*gnu* then that's not this bug
(because this is about HP-UX). I assume you're using glibc from git, in which
case see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413#c2

[Bug target/65546] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546

--- Comment #5 from Bill Schmidt  ---
For GCC 6, this is just a testcase error.  The failing assertion requires this
clause now that we can vectorize the loop using misaligned loads/stores:

{ target { ! vect_hw_misalign } }

I'll get that fixed shortly, then see what's up on 4.9 and 5.

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517

--- Comment #5 from Jason Merrill  ---
By the way, it was removed in r219359.

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517

--- Comment #4 from Jason Merrill  ---
(In reply to Martin Sebor from comment #3)
> Just to clarify: it's the program that crashes, not GCC (so removing the
> ice-on-invalid-code keyword).
> 
> But I also think that rejecting or at least loudly diagnosing the code would
> be preferable to letting it run off the rails.  We have tentatively agreed
> on this approach in a separate thread
> (https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02167.html) so someone just
> needs to put together a patch.  I'll see if I can find the time to do it if
> no one beats me to it.

Thanks.

> With that said, I wonder if restoring the exception that 4.9.3 would be
> feasible.  It seems like the ideal solution, in line with the array new
> expression.  Jason. were there problems with it that the exception throwing
> code had to be removed?

The only issue was that the exception class was removed from the working paper,
so it isn't part of C++14.  I'm open to restoring the throwing code, but we
should probably use a different exception type, either bad_array_new_length or
an extension.

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So, we have here:
(insn 42 41 43 2 (set (reg:V4SI 318)
(const_vector:V4SI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])) pr69459.c:14 1220 {*movv4si_internal}
 (expr_list:REG_EQUIV (const_vector:V4SI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil)))
...
(insn 245 242 246 4 (set (reg/v:V4SI 295 [ v16u32_1 ])
(vec_merge:V4SI (vec_duplicate:V4SI (const_int 4160055 [0x3f7a37]))
(reg:V4SI 318)
(const_int 1 [0x1]))) pr69459.c:23 2489 {vec_setv4si_0}
 (expr_list:REG_DEAD (reg:V4SI 318)
(expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 4160055 [0x3f7a37])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil
and LRA changes this into:
...
(insn 245 481 246 4 (set (reg/v:V4SI 24 xmm3 [orig:295 v16u32_1 ] [295])
(vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int -120 [0xff88])) [5 %sfp+-256 S4
A128]))
(const_vector:V4SI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(const_int 1 [0x1]))) pr69459.c:23 2489 {vec_setv4si_0}
 (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 4160055 [0x3f7a37])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil)))
This is because the "C" constraint allows not just CONST0_RTX, but also
selected all ones vectors, including the V4SI all ones vector.
The vec_setv4si_0 insn uses the "C" constraints with "vector_move_operand"
predicate, the all ones vector fails the vector_move_operand predicate, but for
whatever reason LRA doesn't try to undo it and doesn't invalidate the cached
insn code, so we happily assembly it.  But instead of the desired { 0x3f7a37,
-1, -1, -1 } vector we get { 0x3f7a37, 0, 0, 0 }.

I'd say the i386 backend just should add a new constraint for CONST0_RTX only
and use it wherever the all ones is not allowed.  As "C" is documented,
probably the new "BC" constraint should be const0/CONST0_RTX only, and I think
at least the vector_move_operand, reg_or_0_operand and likely the
const_int_operand cases too should be changed to "BC".  At least that way the
RA and other spots will not try to satisfy it with something that can't match.

And then there is the question if and what should change on the LRA side.

i386.md:(match_operand:XI 1 "vector_move_operand"  "C ,vm,v"))]
i386.md:(match_operand:OI 1 "vector_move_operand"  "C ,vm,v"))]
i386.md:(match_operand:TI 1 "general_operand"  "riFo,re,C,vm,v"))]
i386.md:(match_operand:DI 1 "general_operand" "riFo,riF,Z,rem,i,re,C
,*y,m  ,*y,*Yn,r   ,C ,*v,m ,*v,v,*Yj,*v,r   ,*Yj ,*Yn ,*r ,*km,*k,*k"))]
i386.md:(match_operand:SI 1 "general_operand" "g ,re,C ,*y,*y ,rm ,C
,*v,m ,*v,*Yj,*v,r   ,*krm,*k"))]
i386.md:(match_operand:TF 1 "general_operand"  "C
,xm,x,*roF,*rC"))]
i386.md:(match_operand:XF 1 "general_operand" "fm,f,G,roF,r , *roF,*r,F
,C,roF,rF"))]
i386.md:(match_operand:DF 1 "general_operand" "Yf*fm,Yf*f,G   ,roF,r
,*roF,*r,F ,rm,rC,C ,F ,C,v,m,v,C ,*x,m ,*x,Yj,r ,roF,rF,rmF,rC"))]
i386.md:(match_operand:SF 1 "general_operand" "Yf*fm,Yf*f,G  
,rmF,rF,C,v,m,v,Yj,r  ,*y ,m  ,*y,*Yn,r   ,rmF,rF"))]
i386.md:  [(match_operand: 1 "vector_move_operand" "xmC")
mmx.md: (match_operand:MMXMODE 1 "vector_move_operand" "rCo,rC,C,rm,rC,C  ,!y,m
 ,?!y,?!Yn,r   ,C,v,m,v,C ,*x,m ,*x,Yj,r ,*Yj,!Yn"))]
mmx.md:   (match_operand:SF 2 "vector_move_operand"  "ym,C")))]
mmx.md:   (match_operand:SI 2 "vector_move_operand"  "ym,C")))]
sse.md: (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "C
,vm,v"))]
sse.md:   (match_operand:V48_AVX512VL 2 "vector_move_operand" "0C,0C")
sse.md:   (match_operand:VI12_AVX512VL 2 "vector_move_operan

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69450

--- Comment #14 from Jonathan Wakely  ---
(In reply to amker from comment #13)
> I also saw this issue on aarch64, will test if the patch fixes it.

It's a C library conflict, not hardware-specific, so "aarch64" is not relevant.

The patch only affects HP-UX so unless you're running that on aarch64(!) it
won't make any difference.

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69450

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #13 from amker at gcc dot gnu.org ---
(In reply to John David Anglin from comment #12)
> Fixed.

I also saw this issue on aarch64, will test if the patch fixes it.

Thanks,

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |

--- Comment #3 from Martin Sebor  ---
Just to clarify: it's the program that crashes, not GCC (so removing the
ice-on-invalid-code keyword).

But I also think that rejecting or at least loudly diagnosing the code would be
preferable to letting it run off the rails.  We have tentatively agreed on this
approach in a separate thread
(https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02167.html) so someone just
needs to put together a patch.  I'll see if I can find the time to do it if no
one beats me to it.

With that said, I wonder if restoring the exception that 4.9.3 would be
feasible.  It seems like the ideal solution, in line with the array new
expression.  Jason. were there problems with it that the exception throwing
code had to be removed?

[Bug tree-optimization/69541] check ssa more often in parloops

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69541

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug tree-optimization/69541] New: check ssa more often in parloops

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69541

Bug ID: 69541
   Summary: check ssa more often in parloops
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

It happens that we run into a parloops ssa update failure while processing loop
y, but the faulty ssa was introduced while processing loop x. This is somewhat
confusing, and it probably makes sense to verify ssa after processing each
loop:
 ...
@@ -2413,11 +2416,18 @@ gen_parallel_loop (struct loop *loop,
   if (reduction_list->elements () > 0)
 create_call_for_reduction (loop, reduction_list, &clsn_data);

+  update_ssa (TODO_update_ssa);
+  verify_ssa (true, true);
+
   scev_reset ();

   /* Free loop bound estimations that could contain references to
...
Perhaps only if flag_checking.

Furthermore, to pinpoint where the error is introduced, I tend to move the
update_ssa/verify_ssa calls backwards in gen_parallel_loop. But that doesn't
work at points were we always have invalid ssa, which is the case before
gen_parallel loop.  This patch fixes that:
...
diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index 139e38c..2086a21 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -1411,6 +1411,8 @@ separate_decls_in_region (edge entry, edge exit,
   nvar = create_tmp_var (build_pointer_type (type), ".paral_data_load");
   *new_arg_struct = make_ssa_name (nvar);

+  SSA_NAME_IS_DEFAULT_DEF (*new_arg_struct) = 1;
+  SSA_NAME_DEF_STMT (*new_arg_struct) = gimple_build_nop ();
   ld_st_data->store = *arg_struct;
   ld_st_data->load = *new_arg_struct;
   ld_st_data->store_bb = bb0;
@@ -2070,6 +2072,7 @@ create_parallel_loop (struct loop *loop, tree loop_fn,
tree data,

  assign_stmt = gimple_build_assign (new_data,
 fold_convert (TREE_TYPE
(new_data), param));
+ SSA_NAME_IS_DEFAULT_DEF (new_data) = 0;
  gsi_insert_before (&gsi, assign_stmt, GSI_SAME_STMT);
}
...

[Bug c++/68949] [5/6 Regression] Implicit initialization of array member silently miscompiling.

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68949

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed.

[Bug c++/67407] [6 regression] ice in friend_accessible_p

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/65608] [meta-bug] friend issues

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
Bug 65608 depends on bug 67407, which changed state.

Bug 67407 Summary: [6 regression] ice in friend_accessible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407

   What|Removed |Added

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

[Bug c/69540] New: add a short info on .so priority in -l

[arkadiusz at drabczyk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69540

Bug ID: 69540
   Summary: add a short info on .so priority in -l
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arkadiusz at drabczyk dot org
  Target Milestone: ---

Not a big thing but just to limit a discrepancy between what gcc says
and what it actually does I think it's a good idea to add a few words
about .so to a description of -l in gcc/doc/invoke.texi.  Currently
only .a files are mentioned but in fact not only are .so also searched
but have priority over .a.  It could be something like:

"The only difference between using an @option{-l} option and
specifying a file name is that @option{-l} surrounds @var{library}
with @samp{lib} and @samp{.so} on systems with shared libraries
support or with @samp{.a} if @var{library} with @samp{.so} is not
found and on all other system and searches several directories."

Anybody who needs more details will look into ld manual anyway.

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526

--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #7)
> (In reply to amker from comment #6)
> 
> > It comes from loop niter analysis, as in may_eliminate_iv, we have:
> > 
> > (gdb) call debug_generic_expr(desc->niter)
> > n_5(D) + 4294967295
> 
> and this is correct? I.e. the number of iterations is n - 1? I'd naively
> expect 
>   desc->niter = n_5(D)
> 
> (Again, it might be necessary for some reason escapes me currently)

It confused me too, but niter in tree_niter_desc means the number of time latch
is executed, as commented in tree-ssa-loop.h:

  tree niter;   /* The expression giving the number of iterations of
   a loop (provided that assumptions == true and
   may_be_zero == false), more precisely the number
   of executions of the latch of the loop.  */

[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526

--- Comment #7 from rdapp at linux dot vnet.ibm.com ---
(In reply to amker from comment #6)

> It comes from loop niter analysis, as in may_eliminate_iv, we have:
> 
> (gdb) call debug_generic_expr(desc->niter)
> n_5(D) + 4294967295

and this is correct? I.e. the number of iterations is n - 1? I'd naively expect 
  desc->niter = n_5(D)

(Again, it might be necessary for some reason escapes me currently)

[Bug driver/40200] ''gcc file.cpp -o file.cpp'' overwrites input file

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40200

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmalcolm at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from David Malcolm  ---
Yes, this has bitten me (esp. with Makefiles).

Looks like this was implemented in r217391; resolving as dup of PR 36312.

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

[Bug driver/36312] should refuse to overwrite input file with output file

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312

David Malcolm  changed:

   What|Removed |Added

 CC||_paul at bk dot ru

--- Comment #20 from David Malcolm  ---
*** Bug 40200 has been marked as a duplicate of this bug. ***

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #5)
> I still don't quite get why the "n - 1" is needed. Do we need it to possibly
> have an exit condition like
> 
>  if (i != n-1) or 
>  if (i <= n-1)?
> 
> Am I missing something really obvious here?

The dump before ivopt is as below:

  :
  if (n_5(D) != 0)
goto ;
  else
goto ;

  :
  return;

  :

  :
  # i_18 = PHI <0(4), i_14(7)>
  _6 = (long unsigned int) i_18;
  _7 = _6 * 8;
  _9 = out_8(D) + _7;
  _11 = in_10(D) + _7;
  _12 = *_11;
  *_9 = _12;
  i_14 = i_18 + 1;
  i.0_4 = (unsigned int) i_14;
  if (i.0_4 < n_5(D))
goto ;
  else
goto ;

  :
  goto ;

  :
  goto ;


It comes from loop niter analysis, as in may_eliminate_iv, we have:

(gdb) call debug_generic_expr(desc->niter)
n_5(D) + 4294967295

[Bug target/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

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662

--- Comment #12 from Peter Bergner  ---
Should we add an assert somewhere to ensure that flag_pic and
TARGET_RELOCATABLE are consistent?

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.8.5, 4.9.4, 5.3.1, 6.0

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed on other branches too

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on trunk at least