[Bug tree-optimization/71077] gcc -lto raises ICE

[saguryev.gnu at gmail dot com]

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

--- Comment #1 from Sergey  ---
Upd: with the reduced testcase the problem hid out after May 3; here is a
bigger  testcase which reveals it reliably :

output_inline_function() { rest_of_compilation(); }
*a;
b, c, d, e;
sched_analyze() {
  for (; b; b++) {
c = 0;
for (; c < 32; c++)
  if (b & 1 << c)
a[b + c] = d;
  }
}

schedule_insns() { e = sched_analyze; }
main() { schedule_insns(); }

[Bug lto/71077] New: gcc -lto raises ICE

[saguryev.gnu at gmail dot com]

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

Bug ID: 71077
   Summary: gcc -lto raises ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saguryev.gnu at gmail dot com
  Target Milestone: ---

gcc raises ICE as follows starting from rev. 235653 :

[#  0001] {2186}$>  ./gcc -O3 -flto  -march=core-avx2 O768_r.c
[ warnings snipped ]
O768_r.c:3:1: warning: return type defaults to 'int' [-Wimplicit-int]
 main() {
 ^~~~ 
O768_r.c: In function 'main':
O768_r.c:3:1: internal compiler error: in find_taken_edge_cond_expr, at
tree-cfg.c:2235
 main() {
 ^
0xa9fe03 find_taken_edge_cond_expr
../../..//src/235653/gcc/tree-cfg.c:2235
0xa9fe03 find_taken_edge(basic_block_def*, tree_node*)
../../..//src/235653/gcc/tree-cfg.c:2182
0xc5880c thread_through_normal_block
../../..//src/235653/gcc/tree-ssa-threadedge.c:1077
0xc5a124 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*,
avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*))
../../..//src/235653/gcc/tree-ssa-threadedge.c:1274
0xce641f identify_jump_threads
../../..//src/235653/gcc/tree-vrp.c:10184
0xce641f vrp_finalize
../../..//src/235653/gcc/tree-vrp.c:10256
0xce641f execute_vrp
../../..//src/235653/gcc/tree-vrp.c:10345
0xce641f execute
../../..//src/235653/gcc/tree-vrp.c:10430
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: ./gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[#  0001] {2187}$>  cat  O768_r.c
*a;
b, c, d;
main() {
  for (;; b++) {
c = 0;
for (; c < 32; c++)
  if (b & 1 << c)
a[b + c] = d;
  }
}

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[john.ettedgui at gmail dot com]

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

--- Comment #10 from John Ettedgui  ---
I tried to rebuild my gcc with Kal's patch but it fails with this error:

"make[6]: *** No rule to make target '../src/c++11/libc++11convenience.la',
needed by 'libstdc++.la'.  Stop."

I don't understand how it relates to the patch, and I have no issue rebuilding
without the patch.
Should I use the patch against 6.2 trunk and not 6.1.1?

Thanks

[Bug middle-end/71076] [6/7 Regression] error: missing PHI def

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-12
 CC||trippels at gcc dot gnu.org
  Component|c++ |middle-end
Summary|Internal compiler error |[6/7 Regression] error:
   ||missing PHI def
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
x.ii: In function ‘void foo()’:
x.ii:22:6: error: missing PHI def
 void foo() {
  ^~~
iftmp.0_12 = PHI <0.0(4), _11(11), (5)>
x.ii:22:6: internal compiler error: verify_gimple failed
0xd8a706 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5166
0xc7ead3 execute_function_todo
../../gcc/gcc/passes.c:1964
0xc7f48b execute_todo
../../gcc/gcc/passes.c:2016

[Bug c++/71076] New: Internal compiler error

[manisandro at gmail dot com]

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

Bug ID: 71076
   Summary: Internal compiler error
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manisandro at gmail dot com
  Target Milestone: ---

Following is with gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC) 

Following code snippet compiled as

g++ -c -O  foo.cpp -o foo.o

produces an ICE:

foo.cpp:


extern "C" {
  extern float sqrtf (float);
}

template  struct Foo
{
Foo();
T a() const;
Foo b() const;
};

template 
Foo Foo::b() const
{
T x = a();
T y = x < 0 ? 0 : ::sqrtf (x);
return y == T(0) ? Foo() : Foo();
}

struct Bar
{
~Bar();
};

void foo()
{
Bar bar;
Foo dir = Foo().b();
}

[Bug c++/71075] New: Broken diagnostic: 'integer_cst' not supported by 'dump_decl'

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 71075
   Summary: Broken diagnostic: 'integer_cst' not supported by
'dump_decl'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

I'm not sure how this isn't a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51229 , but that bug has been
marked RESOLVED FIXED since 2011, and this bug still reproduces in GCC 7.0.

template struct A {};
template void foo(A) {}
int main() {
foo(A());
}



prog.cc: In function 'int main()':
prog.cc:4:19: error: no matching function for call to 'foo(A)'
 foo(A());
   ^
prog.cc:2:27: note: candidate: template void foo(A)
 template void foo(A) {}
   ^~~
prog.cc:2:27: note:   template argument deduction/substitution failed:
prog.cc:4:19: note:   template argument '2' does not match '#'integer_cst' not
supported by dump_decl#'
 foo(A());
   ^



Notice the last diagnostic line above: "template argument '2' does not match
'#'integer_cst' not supported by dump_decl#'".

I think GCC is correct in rejecting the input program; it just doesn't
understand how to print the resulting diagnostic.

[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)

[romain.geissler at amadeus dot com]

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

--- Comment #3 from Romain Geissler  ---
Please note that this is the only target lib that fails for me. Others (like
libgomp) are fine.

[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)

[romain.geissler at amadeus dot com]

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

--- Comment #2 from Romain Geissler  ---
The very same thing happens with gcc 6.1.1.

[Bug c/71074] New: combine.c in simplify_comparison sanitizer detects left shift of negative value

[zeccav at gmail dot com]

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

Bug ID: 71074
   Summary: combine.c in simplify_comparison sanitizer detects
left shift of negative value
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -O2 sanitizer undefined runtime error */
/* In gcc trunk 7.0 */
/* ../../gcc7/gcc/combine.c:12340:18: runtime error: left shift of negative
value -13 */
/* combine.c:12340 is "const_op <<= INTVAL (XEXP (op0, 1));" */
/* From PR target/49238 */
int bar (void);

void
foo (unsigned long long a, int b)
{
  int i;

for (a = -12; a >= 10; a = bar ())
  break;

if (i == bar () || bar () >= a)
  bar ();
}

[Bug c/71074] combine.c in simplify_comparison sanitizer detects left shift of negative value

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug rtl-optimization/70825] x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target|x86_64, aarch64 |x86_64, aarch64, powerpc64*

--- Comment #3 from Bill Schmidt  ---
Also on powerpc64:

.file   "gorp.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl test_atomic_cmpxchg
.type   test_atomic_cmpxchg, @function
test_atomic_cmpxchg:
li 9,23
stw 9,-16(1)  <-- unnecessary
sync
.L2:
lwarx 9,0,3
cmpwi 0,9,23
bne 0,.L3
li 9,42
stwcx. 9,0,3
bne 0,.L2
isync
.L3:
blr

[Bug c/43651] add warning for duplicate qualifier

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

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

--- Comment #9 from Mikhail Maltsev  ---
Fixed for GCC 7.

[Bug c/43651] add warning for duplicate qualifier

[miyuki at gcc dot gnu.org]

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

--- Comment #8 from Mikhail Maltsev  ---
Author: miyuki
Date: Wed May 11 20:23:37 2016
New Revision: 236142

URL: https://gcc.gnu.org/viewcvs?rev=236142&root=gcc&view=rev
Log:
PR43651: add warning for duplicate qualifier

gcc/c/

PR c/43651
* c-decl.c (declspecs_add_qual): Warn when -Wduplicate-decl-specifier
is enabled.
* c-errors.c (pedwarn_c90): Return true if warned.
* c-tree.h (pedwarn_c90): Change return type to bool.
(enum c_declspec_word): Add new enumerator cdw_atomic.

gcc/

PR c/43651
* doc/invoke.texi (Wduplicate-decl-specifier): Document new option.

gcc/testsuite/

PR c/43651
* gcc.dg/Wduplicate-decl-specifier-c11.c: New test.
* gcc.dg/Wduplicate-decl-specifier.c: Likewise.

gcc/c-family/

PR c/43651
* c.opt (Wduplicate-decl-specifier): New option.

Added:
trunk/gcc/testsuite/gcc.dg/Wduplicate-decl-specifier-c11.c
trunk/gcc/testsuite/gcc.dg/Wduplicate-decl-specifier.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-errors.c
trunk/gcc/c/c-tree.h
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug ada/71072] GNAT doesn't respect --enable-default-pie

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-11
 CC||ebotcazou at gcc dot gnu.org
Summary|[6/7] gnat doesn't respect  |GNAT doesn't respect
   |--enable-default-pie|--enable-default-pie
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
There is not enough information.  Please provide a testcase and a GCC command
line (no, a GPRbuild invocation doesn't qualify).

[Bug libstdc++/71073] New: debug-mode headers should include #pragma GCC system_header directives

[froydnj at gcc dot gnu.org]

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

Bug ID: 71073
   Summary: debug-mode headers should include #pragma GCC
system_header directives
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: froydnj at gcc dot gnu.org
  Target Milestone: ---

This change would help analysis tools cope with the code in the debug-mode
headers, usually by ignoring it.

[Bug ada/71072] New: [6/7] gnat doesn't respect --enable-default-pie

[doko at gcc dot gnu.org]

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

Bug ID: 71072
   Summary: [6/7] gnat doesn't respect --enable-default-pie
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

GCC 6 introduces the --enable-default-pie option, however it looks like gnat
doesn't respect this option.

Seen while running the examples/matrix test in gprbuild on x86_64-linux-gnu
(gnatgcc here is just a symlink to the gcc driver matching the gnat version):

make[1]: Entering directory '/tmp/adt-run.SU7baW/adttmp/examples/matrix'
gprconfig --batch --config Ada  --config C --config Fortran -o default.cgpr
Creating configuration file: default.cgpr
gprbuild
using project file matrix.gpr
gnatgcc -c -gnat05 main.adb
gfortran -c multmat.f
gcc -c initmat.c
gprbind main.bexch
gnatbind main.ali
gnatgcc -c b__main.adb
ar cr libmatrix.a ...
ranlib libmatrix.a
gfortran main.o -o main
/usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata' can not be used
when making a shared object; recompile with -fPIC
main.o: error adding symbols: Bad value
Makefile:2: recipe for target 'all' failed
make[1]: Leaving directory '/tmp/adt-run.SU7baW/adttmp/examples/matrix'
Makefile:5: recipe for target 'all' failed
collect2: error: ld returned 1 exit status
gprbuild: link of main.adb failed
make[1]: *** [all] Error 4

[Bug libstdc++/71049] [6/7 Regression] libstdc++ fails to build --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
fixed on trunk and gcc-6-branch

[Bug libstdc++/71049] [6/7 Regression] libstdc++ fails to build --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed May 11 19:06:45 2016
New Revision: 236137

URL: https://gcc.gnu.org/viewcvs?rev=236137&root=gcc&view=rev
Log:
libstdc++/71049 fix --disable-libstdcxx-dual-abi bootstrap

PR libstdc++/71049
* src/c++11/cow-stdexcept.cc [!_GLIBCXX_USE_DUAL_ABI]: Don't define
exception constructors with __sso_string parameters.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-stdexcept.cc

[Bug fortran/70855] [6/7 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/71071] New: [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[dimhen at gmail dot com]

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

Bug ID: 71071
   Summary: [7 regression] ICE --enable-checking=fold : fold
check: original tree changed by fold
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r236043 PASS
r236132 FAIL

/home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=fold --enable-languages=c,c++ --disable-multilib

/home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fpic -mlong-double-80
-DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I/home/dimhen/src/gcc_current/libgcc
-I/home/dimhen/src/gcc_current/libgcc/.
-I/home/dimhen/src/gcc_current/libgcc/../gcc
-I/home/dimhen/src/gcc_current/libgcc/../include
-I/home/dimhen/src/gcc_current/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov
-c /home/dimhen/src/gcc_current/libgcc/libgcov-driver.c
/home/dimhen/src/gcc_current/libgcc/libgcov-driver.c: In function
'__gcov_dump_one':
/home/dimhen/src/gcc_current/libgcc/libgcov-driver.c:855:3: internal compiler
error: fold check: original tree changed by fold
   if (root->dumped)
   ^~
0xa3931f fold_check_failed
/home/dimhen/src/gcc_current/gcc/fold-const.c:12099
0xa3a05c fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:12358
0x11e7407 generic_simplify_186
/home/dimhen/build/gcc_current/gcc/generic-match.c:6903
0x1224527 generic_simplify_NE_EXPR
/home/dimhen/build/gcc_current/gcc/generic-match.c:27430
0x1229e7a generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/build/gcc_current/gcc/generic-match.c:29656
0xa2e7af fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:9265
0xa39f9c fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:12347
0x80aa18 c_fully_fold_internal
/home/dimhen/src/gcc_current/gcc/c/c-fold.c:305
0x80a147 c_fully_fold(tree_node*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/c/c-fold.c:90
0x7de299 c_parser_condition
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5314
0x7de2f7 c_parser_paren_condition
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5331
0x7de775 c_parser_if_statement
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5493
0x7ddac5 c_parser_statement_after_labels
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5138
0x7dd543 c_parser_compound_statement_nostart
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4858
0x7dcf5a c_parser_compound_statement
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4693
0x7d7fb7 c_parser_declaration_or_fndef
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:2105
0x7d6b98 c_parser_external_declaration
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1549
0x7d6740 c_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1430
0x801c9e c_parse_file()
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:17915
0x8602ec c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1064
Please submit a full bug report,

[Bug c++/71069] -Waddress didn't catch all cases

[eugene.zelenko at gmail dot com]

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

--- Comment #1 from Eugene Zelenko  ---
Sorry for mistake in original report. -Waddress should report such problems.

[Bug target/71070] New: MPX gives a false positive when allocating a string longer than 16 bytes on the stack

[alexo_o at ukr dot net]

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

Bug ID: 71070
   Summary: MPX gives a false positive when allocating a string
longer than 16 bytes on the stack
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexo_o at ukr dot net
  Target Milestone: ---

Created attachment 38471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38471&action=edit
Preprocessed file

It works only if:
* it is a string, not an array of chars
* the string is longer than 16 bytes
* the string is allocated on the stack

For example, #BR is thrown in the following line:

string long_string("A long string with more than 16 symbols");

Full preprocessed source is attached.

System setup:

* GCC version: 6.1.0 (also appears with 5.3.0)
* the system type: Linux f8714f7988cf 4.2.0-35-generic #40-Ubuntu SMP Tue Mar
15 22:15:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
* Configured with: gcc/src/configure --enable-languages=c,c++
--disable-multilib --enable-libmpx
* Compilation flags: -O3 -fcheck-pointer-bounds -mmpx -lmpx

Output:

short string: short string
Allocated a big object
Saw a #BR! status 1 at 0x7f8eb754f148



That is, the last line is a false positive. 

Full output with -v -save-temps:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /root/bin/gcc/src/configure --enable-languages=c,c++
--disable-multilib --enable-libmpx : (reconfigured) ../src/configure
--enable-languages=c,c++ --disable-multilib --enable-libmpx
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-fcheck-pointer-bounds' '-mmpx' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE test.cpp -mmpx -mtune=generic
-march=x86-64 -fcheck-pointer-bounds -O3 -fpch-preprocess -o test.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-fcheck-pointer-bounds' '-mmpx' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1plus -fpreprocessed
test.ii -quiet -dumpbase test.cpp -mmpx -mtune=generic -march=x86-64 -auxbase
test -O3 -version -fcheck-pointer-bounds -o test.s
GNU C++ (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 316654f71ace181278f48334ff2cbcb8
COLLECT_GCC_OPTIONS='-O3' '-fcheck-pointer-bounds' '-mmpx' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.26 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.26.20160125
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../:/lib/:/usr/lib/
Reading specs from
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib64/libmpx.spec
COLLECT_GCC_OPTIONS='-O3' '-fcheck-pointer-bounds' '-mmpx' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/collect2 -plugin
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/liblto_plugin.so
-plugin-opt=/usr/local/libexec/gcc/x86_64-unknown-linu

[Bug c++/71069] New: Extend -Wnonnull-compare to address of reference

[eugene.zelenko at gmail dot com]

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

Bug ID: 71069
   Summary: Extend -Wnonnull-compare to address of reference
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com
  Target Milestone: ---

I had crash in optimized build because pointer check is skipped in next
situation (null pointer is sneaked into container):

void setData( Data &data ) {
  _current_data = &data;
  if ( _current_data )
_set_data.insert( _current_data );
}

I think will be good idea to report such situations in -Wnonnull-compare.

[Bug middle-end/71062] [7 regression] r235622 and restrict pointers

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I don't think it's valid to optimize for comparisons, where dereference 
doesn't occur, based on restrict; restrict is only about how an object is 
accessed (and as long as the object doesn't get modified, multiple 
pointers, restricted and otherwise, can be used to access it; it's only if 
the object is modified[*] that the rules about restrict come into play).

[*] Including the deemed modifications from "Every access that modifies X 
shall be considered also to modify P, for the purposes of this subclause." 
to deal with multiple levels of restricted pointers.

[Bug tree-optimization/70876] ICE in chkp_find_bounds: Unexpected tree code with_size_expr

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Will you please check gcc 6.1 with your fix against bug 70877?

I get an ICE, could it be a regression?

gcc -fcheck-pointer-bounds  -mmpx gccerr36.c
gccerr36.c: In function ‘bar’:
gccerr36.c:12:8: warning: function called through a non-compatible type
   d = ((double (*) (int)) foo) (i);
   ~^~~
gccerr36.c: In function ‘bar.chkp’:
gccerr36.c:12:5: internal compiler error: in convert_move, at expr.c:268
   d = ((double (*) (int)) foo) (i);
   ~~^~
0x768d88 convert_move(rtx_def*, rtx_def*, int)
../../gcc-6.1.0/gcc/expr.c:268
0x76e585 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc-6.1.0/gcc/expr.c:5483
0x76e9ff expand_assignment(tree_node*, tree_node*, bool)
../../gcc-6.1.0/gcc/expr.c:5175
0x691b0c expand_call_stmt
../../gcc-6.1.0/gcc/cfgexpand.c:2658
0x691b0c expand_gimple_stmt_1
../../gcc-6.1.0/gcc/cfgexpand.c:3548
0x691b0c expand_gimple_stmt
../../gcc-6.1.0/gcc/cfgexpand.c:3714
0x6934a5 expand_gimple_basic_block
../../gcc-6.1.0/gcc/cfgexpand.c:5720
0x698386 execute
../../gcc-6.1.0/gcc/cfgexpand.c:6335

[Bug fortran/71068] New: ICE in check_data_variable(): Bad expression

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71068
   Summary: ICE in check_data_variable(): Bad expression
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With this wrong code :

$ cat z1.f90
program p
   integer :: a(2)[*]
   data a(1)[1] /1/
   data a(2)[1] /2/
end

$ gfortran-6 -fcoarray=lib z1.f90
f951: internal compiler error: check_data_variable(): Bad expression



Whereas :

$ gfortran-6 -fcoarray=single z1.f90
z1.f90:4:7:

data a(2)[1] /2/
   1
Error: DATA element ‘a’ at (1) cannot have a coindex
z1.f90:3:7:

data a(1)[1] /1/
   1
Error: DATA element ‘a’ at (1) cannot have a coindex

[Bug fortran/71067] ICE on data initialization with insufficient value or wrong boz-constants

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
A) correct with parameter :

$ cat z3.f90
program p
   integer, parameter :: i = 0
   integer :: z(2)
   data z /2*i/
   print *, z
end

$ gfortran-6 z3.f90
$ a.out
   0   0



B) wrong code detected with scalars :

$ cat z5.f90
program p
   integer :: a, b, c
   data a /b1'/
   data b /o1'
   data c /z1
end

$ gfortran-6 z5.f90
z5.f90:3:13:

data a /b1'/
 1
Error: Symbol ‘b1’ must be a PARAMETER in DATA statement at (1)
z5.f90:4:13:

data b /o1'
 1
Error: Symbol ‘o1’ must be a PARAMETER in DATA statement at (1)
z5.f90:5:13:

data c /z1
 1
Error: Symbol ‘z1’ must be a PARAMETER in DATA statement at (1)

[Bug fortran/71067] New: ICE on data initialization with insufficient value or wrong boz-constants

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71067
   Summary: ICE on data initialization with insufficient value or
wrong boz-constants
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With a missing parameter attribute, or value not initialized :

$ cat z1.f90
program p
   integer :: i = 0
   integer :: z(2)
   data z /2*i/
end

$ gfortran-6 z1.f90
f951: internal compiler error: free_expr0(): Bad expr type



$ cat z2.f90
program p
   integer :: i, z(2)
   data z /2*i/
end

$ gfortran-6 z2.f90
f951: internal compiler error: free_expr0(): Bad expr type



Incidentally observed, with wrong boz-constants :

$ cat z4.f90
program p
   integer :: a(2), b(2), c(2)
   data a /2*b1'/
   data b /2*o1'
   data c /2*z1
end

$ gfortran-6 z4.f90
f951: internal compiler error: free_expr0(): Bad expr type

[Bug fortran/71066] New: ICE in set_loop_bounds, at fortran/trans-array.c:4680

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71066
   Summary: ICE in set_loop_bounds, at fortran/trans-array.c:4680
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This first example is partially related to pr50410 :

$ cat z1.f90
program p
   type t
  real, allocatable :: a(:,:)
   end type
   type(t), pointer :: x
   data x%a / 1.0 /
end

$ gfortran-6 z1.f90
internal compiler error: in set_loop_bounds, at fortran/trans-array.c:4680

---

Another situation :

$ cat z3.f90
program p
   real :: a(2,2)[*]
   data a /4*0.0/
end

$ gfortran-6 -fcoarray=single z3.f90
$ gfortran-6 -fcoarray=lib z3.f90
internal compiler error: in set_loop_bounds, at fortran/trans-array.c:4680

[Bug fortran/57197] [Fortran-Dev][Regression] ICE in record_reference, at cgraphbuild.c:66

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
For me, test compiles now without ICE -- same with "use thing" added.

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698]

[Bug tree-optimization/71006] [6/7 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize

[chengniansun at gmail dot com]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #3 from Chengnian Sun  ---
Hi, 

Can you help check whether the following test case is a duplicate? Thanks. 



$: 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 20160511 (experimental) [trunk revision 236116] (GCC)
$:
$: gcc-trunk -O1 small.c
small.c: In function ‘fn1_BOUOUtg_1828_f2’:
small.c:2:6: error: type mismatch in binary expression
 void fn1_BOUOUtg_1828_f2() {
  ^~~
int

int

unsigned int

_4 = a.0_1 ^ b.2_6;
small.c:2:6: internal compiler error: verify_gimple failed
0xbfe24f verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5166
0xaeca62 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1964
0xaed45b execute_todo
../../gcc-source-trunk/gcc/passes.c:2016
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
int a, b;
void fn1_BOUOUtg_1828_f2() {
  unsigned c = 8 < 10;
  int d = fn1_BOUOUtg_1828_f2 || 8;
  b = d ^ a ^ c ^ b;
}

int main() { return 0; }
$:

[Bug fortran/56765] [OOP] compilation errors/ICE with polymorphic array

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #6 from Gerhard Steinmetz  
---
On my environment, all tests compile now without an ICE.
(also tested with several other compile options)

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698]


$ gfortran-6 -Wall -Wextra pr56765_comment0_t2.f90
$ a.out

$ gfortran-6 -Wall -Wextra pr56765_comment0_t3.f90
pr56765_comment0_t3.f90:4:4:

 u => sub()
1
Error: Different ranks in pointer assignment at (1)

$ gfortran-6 -Wall -Wextra pr56765_comment4.f90
$ a.out

[Bug c++/71024] Missing warning for contradictory attributes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/71024] Missing warning for contradictory attributes

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed May 11 17:07:37 2016
New Revision: 236129

URL: https://gcc.gnu.org/viewcvs?rev=236129&root=gcc&view=rev
Log:
PR c++/71024
* c-common.c (diagnose_mismatched_attributes): New function.
* c-common.h (diagnose_mismatched_attributes): Declare.

* c-decl.c (diagnose_mismatched_decls): Factor out code to
diagnose_mismatched_attributes and call it.

* decl.c (duplicate_decls): Call diagnose_mismatched_decls.

* c-c++-common/attributes-3.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/attributes-3.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug other/71064] nvptx offloading: "long double" data type

[amonakov at gcc dot gnu.org]

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

--- Comment #1 from Alexander Monakov  ---
> (It's generally tuned for speed instead of precision, and does not strive for 
> full IEEE-754 conformance.)

(PTX is an abstract ISA, if it's tuned for anything it's the simplicity of
abstraction and matching for the underlying GPU ISA well enough; why do you
claim it doesn't strive for IEEE-754 conformance? if you look at the PTX ISA
spec, you'll see remarks on compliance, such as full compliance for +-*/ sqrt
fma on recent hardware implementations; supporting extended fp types is
optional).

Compilation can succeed if 'double' and 'long double' happen to be binary
compatible, like what offloading from ARM would have.  Otherwise, diagnosing
that as a target compiler error is the right thing to do.  Falling back is not
practical, because in the general case the boundary the double<->long double
translation would need to happen is: individual memory accesses in offloaded
code.

An exception are situations where data in 'long double' type is never exchanged
across the host-device boundary: all long double variables referenced in the
target region are private to it.  You still need to make sure that sizeof(long
double) matches, but then on memory accesses you can load/store leftmost 8
bytes (of 16) into a PTX register and operate on it.

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #5)
> Sure, and sorry for duplicated work.  Now how to test this properly in
> gcc.misc-tests/help.exp...

Thanks.
Ah, I was not aware of gcc.misc-tests/help.exp
I was just planning to add a single "int a;" in dg.exp and look for dg-error
counting on it ICEing when the bug manifests.
But I suppose help.exp should be the canonical place for these...

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #3)
> FWIW, my fix was
> 
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -1641,6 +1641,11 @@ common_handle_option (struct gcc_options *opts,
>   {
> ++ a;
> pflags = & exclude_flags;
> +   if (*a == '\0')
> + {
> +   error_at (loc, "missing argument to %qs", "--help=^");
> +   break;
> + }
>   }
> else
>   pflags = & include_flags;


Ah, this looks a bit cleaner and shorter than what I had in mind.
Would you mind testing/submitting yours instead?

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from Marek Polacek  ---
Sure, and sorry for duplicated work.  Now how to test this properly in
gcc.misc-tests/help.exp...

[Bug middle-end/71065] New: Missing diagnostic for statements between OpenMP 'target' and 'teams'

[amonakov at gcc dot gnu.org]

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

Bug ID: 71065
   Summary: Missing diagnostic for statements between OpenMP
'target' and 'teams'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

OpenMP 4.5 says (4.0 had a similar restriction, sans 'declarations'):

If specified, a teams construct must be contained within a target construct.
That target construct must contain no statements, declarations or directives
outside of the teams construct.

As a result GCC should reject this:

void f()
{
#pragma omp target
  {
asm("");
#pragma omp teams
  ;
  }
}


(as I understand, 'if' clause on the 'target' pragma allows the user to run
their code in the target region prior to entering 'teams' region anyway, but
still diagnosing the above should be useful)

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
FWIW, my fix was

--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1641,6 +1641,11 @@ common_handle_option (struct gcc_options *opts,
  {
++ a;
pflags = & exclude_flags;
+   if (*a == '\0')
+ {
+   error_at (loc, "missing argument to %qs", "--help=^");
+   break;
+ }
  }
else
  pflags = & include_flags;

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The bug in opts.c is:

if (* a == '^')
  {
++ a;
pflags = & exclude_flags;
  }
else
  pflags = & include_flags;

comma = strchr (a, ',');
if (comma == NULL)
  len = strlen (a);
else
  len = comma - a;
if (len == 0)
  {
a = comma + 1;
continue;
  }

For "^" a is advanced to "", 'comma' after the strchr is NULL, 'len' is
therefore 0 but then a is set to comma + 1, which is invalid and is dereference
at the top of the loop.

[Bug target/70830] [6/7 Regression] ARM interrupt attribute: push/pop do not support {reglist}^

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00395.html

[Bug other/71064] New: nvptx offloading: "long double" data type

[tschwinge at gcc dot gnu.org]

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

Bug ID: 71064
   Summary: nvptx offloading: "long double" data type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, bernds at gcc dot gnu.org,
jakub at gcc dot gnu.org, nathan at gcc dot gnu.org
Blocks: 70945
  Target Milestone: ---

Offloading to nvptx (that is, OpenACC only, currently) does not support the
"long double" data type:

int main()
{
  long double ld;

#pragma acc parallel copyout(ld)
  ld = 0.0L;

  if (ld != 0.0L)
__builtin_abort();

  return 0;
}

... results in: "lto1: fatal error: unsupported mode XF".

The PTX ISA does not support a floating point data type with more than 64-bits.
 (It's generally tuned for speed instead of precision, and does not strive for
full IEEE-754 conformance.)

We can either continue to error out (in a more user-friendly way).  Or,
(perhaps only for "-ffast-math" or similar?) implement "long double" with the
maximum available precision (that is, that of "double"; this will require
conversion at run time of "long double" values at the offloading boundary),
whilst perhaps emitting a warning about the reduced precision.  Unless that's
what's required because GCC generally does it that way, it does not appear
appealing to add a lot of "soft-fp" support code to emulate the target's
higher-precision "long double" data type for the nvptx offloading target.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
[Bug 70945] Offloading: compatibility of target and offloading toolchains

[Bug driver/71063] New: ICE: Segmentation fault with --help="^"

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71063
   Summary: ICE: Segmentation fault with --help="^"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

gcc --help="^"
ICEs with:
cc1: internal compiler error: Segmentation fault
0xae26d2 crash_signal
$SRC/gcc/toplev.c:333
0x11da90c common_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int, int, unsigned int, cl_option_handlers const*,
diagnostic_context*)
$SRC/gcc/opts.c:1615
0x11dde00 handle_option
$SRC/gcc/opts-common.c:981
0x11ddf98 read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*)
$SRC/gcc/opts-common.c:1180
0xa16f22 read_cmdline_options
$SRC/gcc/opts-global.c:229
0xa16f22 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*)
$SRC/gcc/opts-global.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

ICEs at least as far back as 4.6

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Heh, confirmed.

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On May 11, 2016 3:52:43 PM GMT+02:00, "wschmidt at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
>
>--- Comment #3 from Bill Schmidt  ---
>Sorry, accidentally saved before finishing my thoughts.
>
>How do we "inform" the middle-end that a DI subreg of a DF is very
>expensive? 

I have the same question.

>This differs wildly by processor for us.  We "can" always do the
>subreg, it's
>just that on older processors we do it in a horrible way.

But it seems you do that during reload only?  OTOH not exposing the memory
temporary is probably done to help combine which would be confused by memory
and because getting rid of the memory slot is not possible later.

Catch-22 ...

Note we exposed DF to DI subregs similarly before.

We expose vector element extracts the same way.

So I'm looking for a way to compose a predicate for what kind of 'subregs' are
undesirable (those that need to go through memory).  Given the expander choice
there likely is no such predicate today.

Richard.

[Bug middle-end/71062] [7 regression] r235622 and restrict pointers

[andre.simoesdiasvieira at arm dot com]

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

Andre Vieira  changed:

   What|Removed |Added

 Target||arm
Summary|[bugzilla] r235622 and  |[7 regression] r235622 and
   |restrict pointers   |restrict pointers

--- Comment #1 from Andre Vieira  ---
Register keyword here is superfluous. It is all down to the restrict keyword.

[Bug middle-end/71062] New: [bugzilla] r235622 and restrict pointers

[andre.simoesdiasvieira at arm dot com]

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

Bug ID: 71062
   Summary: [bugzilla] r235622 and restrict pointers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andre.simoesdiasvieira at arm dot com
  Target Milestone: ---

Hi there,

I have encountered a new FAIL when testing newlib-nano for the arm-none-eabi
toolchain which I believe is caused by a change in code generation for
freopen.c.

After some investigation I was able to trace the issue back to a pointer
comparison with a restrict qualified pointer. See below a small piece of code
that illustrates the issue.

$cat t.c
extern const char bar;

int
foo (register char *__restrict p)
{
  if (p == &bar)
return 1;

  return 0;
}

Since revision r235622, the pointer comparison here is evaluated to false
during compilation and the whole basic block is optimized away.

After some inner struggle and quite a few passes over the restrict definition
in the C99 standard(Committee Draft -- April 12, 2011, N1570) I think this
assumption that p and &bar can't point to the same object might be invalid.

Yes, the C-standard defines the '&' operator to yield a pointer to the object.
Though the formal definition of restrict only seems to apply to the
dereferencing of pointers. In this case, we do not dereference the pointer
created by '&bar' and thus do not access the object that 'p' might be pointing
to.

Does my reasoning make sense? I find it quite difficult to wrap my head around
the definition of restrict.

Cheers,
Andre

[Bug target/69979] ARM naked function attribute not handling structs bigger than 32 bits correctly

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-05-11
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
Reopening given last comment - there seems to be something more to dig into
here.

[Bug target/70809] [AArch64] aarch64_vmls pattern should be rejected if -ffp-contract=off

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I'm testing a patch to remove that pattern.
If -ffp-contract=fast then an fma operation will be generated so we'll get the
fmls anyway.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[ktietz at gcc dot gnu.org]

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

--- Comment #9 from Kai Tietz  ---
Created attachment 38470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38470&action=edit
updated patch

Well, DECL_P check is indeed superfluous, but I added to point out we are
checking here for declarations.  but VAR_P should be indeed enough.

The OBJ_TYPE_REF hunk is related to PR/71029, and can be ignored. I removed it
from update.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||john.ettedgui at gmail dot com

--- Comment #6 from Kai Tietz  ---
*** Bug 71054 has been marked as a duplicate of this bug. ***

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Comment on attachment 38469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38469
suggested patch

DECL_P check doesn't make sense, of course all VAR_Ps are also DECL_Ps, but no
need to verify that.  Why the OBJ_TYPE_REF change?

[Bug target/70904] ICE: Max. number of generated reload insns per insn is achieved (90) with -fno-split-wide-types @ aarch64

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Vladimir Makarov  ---
(In reply to Jiong Wang from comment #2)
> (In reply to Zdenek Sojka from comment #0)
> > Created attachment 38393 [details]
> > reduced testcase
> > 
> > Compiler output:
> > $ aarch64-unknown-linux-gnu-gcc -O -fno-split-wide-types testcase.c 
> > testcase.c: In function 'foo':
> > testcase.c:8:1: internal compiler error: Max. number of generated reload
> > insns per insn is achieved (90)
> > 
> >  }
> >  ^
> > 0x9dafa9 lra_constraints(bool)
> > /repo/gcc-trunk/gcc/lra-constraints.c:4440
> > 0x9c63dc lra(_IO_FILE*)
> > /repo/gcc-trunk/gcc/lra.c:2290
> > 0x96de19 do_reload
> > /repo/gcc-trunk/gcc/ira.c:5425
> > 0x96de19 execute
> > /repo/gcc-trunk/gcc/ira.c:5609
> 
> From rtl dump, reload is trying to insert the following reload insn
> 
>   r93:OI = r80:OI
> 
> r93 is with general register class and r80 is with vector register
> class. r93 was created to meet the constraint inside insn 17, and was to
> replace the vector register r80 inside the subreg, as vector register
> can't be used as index register.
> 
> (insn 17 11 20 2 (set (mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI
> (reg:OI 80 [ D.2754 ]) 0)
> (const_int 4 [0x4]))  
> (const_int 34 [0x22])
> (const_int 0 [0]))
> (reg/f:DI 83)) [1 *_9+0 S4 A32])
> (const_int 0 [0])) bug-1.c:7 49 {*movsi_aarch64}
> 
> reload here is trying to reload the inner register r80 instead of the whole
> subreg,
> thus creating a new "OImode (vector register)" to "OImode (general register"
> move
> which can't be supported in hardware and caused further endless reload.
> 
> For mode with size bigger than word_mode, there won't be "mov" between
> two registers with different classes, but there normally will be "mov"
> which transfers element of vector register into the general register, and
> this normally will be a subreg.
> 
> So I think we should teach reload about this to reload the whole subreg
> if above conditions met.
> 
> Comments?
> 
> (CCed RA maintainer Vlad)
> 
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 14d5f1d..0ca7a7d 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -1307,7 +1307,15 @@ process_addr_reg (rtx *loc, bool check_only_p,
> rtx_insn **before, rtx_insn **aft
> 
>subreg_p = GET_CODE (*loc) == SUBREG;
>if (subreg_p)
> -loc = &SUBREG_REG (*loc);
> +{
> +  reg = SUBREG_REG (*loc);
> +  mode = GET_MODE (reg);
> +
> +  if (in_class_p (reg, cl, &new_class)
> + || GET_MODE_SIZE (mode) <= GET_MODE_SIZE (word_mode))
> +   loc = &SUBREG_REG (*loc);
> +}
> +
>reg = *loc;
>mode = GET_MODE (reg);
>if (! REG_P (reg))

In general the patch looks ok for me.  It is probably the right place to fix
it.  I'd add a comment for condition of checking the mode size and use ptr_mode
instead of word_mode.

With these changes the patch is ok for me.  Of course, you need to test it also
on x86-64 (especially on GCC testsuite).  Even if it looks ok to me, the
reality can be different because LRA/reload works with many target details
whose interaction is very hard to predict.

Jiong, thank you for working on this PR.

[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jnorris at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Resolution|FIXED   |---
   Assignee|unassigned at gcc dot gnu.org  |jnorris at gcc dot 
gnu.org

--- Comment #6 from Thomas Schwinge  ---
Per
:
PowerPC GNU/Linux target fixed on trunk in r236098; still needs to be fixed on
gcc-6-branch.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #7 from Kai Tietz  ---
Created attachment 38469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38469&action=edit
suggested patch

This fixes the issue for me. Additionally this change addresse reported issue
for PR 71029, which was about too long folding about OBJ_TYPE_REFs.

[Bug c++/71054] [6/7 Regression] ICE: in expand_expr_real_2, at expr.c:8097

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #5 from Kai Tietz  ---
it is a duplicate.

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

[Bug tree-optimization/71055] [7 Regression] FAIL: gcc.dg/torture/pr53663-1.c -Os execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71055] [7 Regression] FAIL: gcc.dg/torture/pr53663-1.c -Os execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed May 11 14:04:32 2016
New Revision: 236122

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

PR tree-optimization/71055
* tree-ssa-sccvn.c (vn_reference_lookup_3): When native-interpreting
sth with precision not equal to access size verify we don't chop
off bits.

* gcc.dg/torture/pr71055.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71055.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |schedule_generic_params_die |schedule_generic_params_die
   |s_gen, at dwarf2out.c:24142 |s_gen, at dwarf2out.c:24142
  Known to fail||6.1.0

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

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

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed May 11 13:59:34 2016
New Revision: 236121

URL: https://gcc.gnu.org/viewcvs?rev=236121&root=gcc&view=rev
Log:
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:
trunk/gcc/testsuite/g++.dg/debug/pr71057.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Sorry, accidentally saved before finishing my thoughts.

How do we "inform" the middle-end that a DI subreg of a DF is very expensive? 
This differs wildly by processor for us.  We "can" always do the subreg, it's
just that on older processors we do it in a horrible way.

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #2 from Bill Schmidt  ---
Yes, the test using -mcpu=power5 means we don't have direct moves between FPRs
and GPRs, so the move has to go through memory, which is what this appears to
have been designed to test.  But now we are storing the value twice, once in
its original location and once in a stack temp, and we have lost the ability to
just do a load-word instead of a load-doubleword/shift.

[Bug fortran/70855] [6/7 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 11 13:18:05 2016
New Revision: 236120

URL: https://gcc.gnu.org/viewcvs?rev=236120&root=gcc&view=rev
Log:
PR fortran/70855
* frontend-passes.c (inline_matmul_assign): Disable in !$omp workshare.

* gfortran.dg/gomp/pr70855.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr70855.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/70855] [6/7 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 11 13:16:48 2016
New Revision: 236119

URL: https://gcc.gnu.org/viewcvs?rev=236119&root=gcc&view=rev
Log:
PR fortran/70855
* frontend-passes.c (inline_matmul_assign): Disable in !$omp workshare.

* gfortran.dg/gomp/pr70855.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr70855.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[mpolacek at gcc dot gnu.org]

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

--- Comment #19 from Marek Polacek  ---
Markus recently committed a patch (r235580) that points out that this attribute
should only be used for debugging.

[Bug c++/71024] Missing warning for contradictory attributes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-11
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Testing a patch.

[Bug libstdc++/71049] [6/7 Regression] libstdc++ fails to build --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed May 11 12:39:28 2016
New Revision: 236118

URL: https://gcc.gnu.org/viewcvs?rev=236118&root=gcc&view=rev
Log:
libstdc++/71049 fix --disable-libstdcxx-dual-abi bootstrap

PR libstdc++/71049
* src/c++11/cow-stdexcept.cc [!_GLIBCXX_USE_DUAL_ABI]: Don't define
exception constructors with __sso_string parameters.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc

[Bug tree-optimization/70986] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in combine_blocks, at tree-if-conv.c:2219

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Other loop opts don't necessarily like this (I get regressions).

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[shatz at dsit dot co.il]

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

--- Comment #18 from shatz at dsit dot co.il ---
(In reply to Manuel López-Ibáñez from comment #15)
> (In reply to shatz from comment #14)
> > It is not documented that __attribute__((optimize(""))) works reliably when
> 
> Unfortunately, you should not expect the optimize attribute to work
> reliably: https://gcc.gnu.org/wiki/FAQ#optimize_attribute_broken

Regular users like me don't read this page and probable can't be realistically
expected to read it.
So, if the situation is really as bad as mentioned there, it should be
mentioned in the places that users do read.
Like these: 
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Function-Attributes.html#Function-Attributes
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes

[Bug tree-optimization/71006] [6/7 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #2 from Ilya Enkovich  ---
Looking at it

[Bug target/71061] [ARM] is not setting instruction length for pop* patterns

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-11
 Ever confirmed|0   |1

[Bug target/71061] New: [ARM] is not setting instruction length for pop* patterns

[jiwang at gcc dot gnu.org]

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

Bug ID: 71061
   Summary: [ARM] is not setting instruction length for pop*
patterns
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: minor
  Priority: P3
 Component: target
  Assignee: jiwang at gcc dot gnu.org
  Reporter: jiwang at gcc dot gnu.org
  Target Milestone: ---
Target: arm*

This is causing wrong size calculation and may affect some rtl pass, for
example bb-order where copy_bb_p needs accurate insn length info.

This have eventually part of the reason for
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00639.html where bb-order failed
to do the bb copy.

For the fix, I think we should extend arm_attr_length_push_multi to pop*
pattern.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Jim Wilson from comment #6)
> Testing the vcond_mask* patch with make check gave 6 regressions for both
> armhf and aarch64.
> 
> FAIL: gcc.dg/vect/pr65947-10.c (internal compiler error)
> FAIL: gcc.dg/vect/pr65947-10.c (test for excess errors)
> FAIL: gcc.dg/vect/pr65947-10.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
> FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (internal compiler
> error)
> FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (test for excess
> errors)
> FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects  scan-tree-dump-times
> vec
> t "LOOP VECTORIZED" 2
> 
> The problem here looks like a flaw in the vcond* patterns.  They support int
> and fp compare operands, but only int selection operands.  E.g. for 
>   (A op B ? X : Y)
> A and B can be either int or fp, but X and Y can only be int.  Adding the
> vcond_mask* patterns apparently causes gcc to call vcond* in ways it didn't
> before, and that exposes the problem.
> 
> The x86 port is the only port with vcond and vcond_mask patterns, and it
> supports all four combinations if int/fp compare/select operands, so it
> appears that aarch64 should also.
> 
> I will need time to figure out how to fix the vcond* problems before I can
> formally submit the vcond_mask* patch.

Hi Jim,
We have a patch which supports all vcond/vcondu patterns (AArch64 yet)
including missing ones.  The patch also introduces vec_cmp&vcond_mask because
it re-implements vcond/vcondu using these two patterns.  It will be ready for
review shortly, but this issue itself needs vectorizer fix I think.

[Bug target/71053] [6/7 Regression] Volatile read optimized into endless loop

[michael at weiser dot dinsnail.net]

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

--- Comment #2 from Michael Weiser  ---
Also happens with trunk r236113:

# ~/bin/gcc-trunk-20160511-avr/bin/avr-g++ -Wall -Wextra -fno-strict-aliasing
-fwrapv -fno-aggressive-loop-optimizations -Os t.c -o t.S -S -v
Using built-in specs.
Reading specs from
/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/device-specs/specs-avr2
COLLECT_GCC=/Users/michael/bin/gcc-trunk-20160511-avr/bin/avr-g++
Target: avr
Configured with: ../configure
--prefix=/Users/michael/bin/gcc-trunk-20160511-avr
--with-gmp=/Users/michael/bin/gcc-6.1.0-avr
--with-mpfr=/Users/michael/bin/gcc-6.1.0-avr
--with-mpc=/Users/michael/bin/gcc-6.1.0-avr --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 7.0.0 20160511 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-Os' '-o' 't.S' '-S' '-v'
'-specs=device-specs/specs-avr2'
 /Users/michael/bin/gcc-trunk-20160511-avr/libexec/gcc/avr/7.0.0/cc1plus -quiet
-v t.c -mn-flash=6 -mskip-bug -quiet -dumpbase t.c -auxbase-strip t.S -Os -Wall
-Wextra -version -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -o t.S -mn-flash=6 -mskip-bug -fno-rtti
-fno-enforce-eh-specs -fno-exceptions
GNU C++14 (GCC) version 7.0.0 20160511 (experimental) (avr)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 7.3.0
(clang-703.0.29), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl
version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/../../../../avr/include/c++/7.0.0"
ignoring nonexistent directory
"/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/../../../../avr/include/c++/7.0.0/avr"
ignoring nonexistent directory
"/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/../../../../avr/include/c++/7.0.0/backward"
ignoring nonexistent directory
"/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/../../../../avr/sys-include"
ignoring nonexistent directory
"/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/include
 /Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/include-fixed
End of search list.
GNU C++14 (GCC) version 7.0.0 20160511 (experimental) (avr)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 7.3.0
(clang-703.0.29), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl
version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1b5e53108dfd5a746e8d5a73cd24bdb2
COMPILER_PATH=/Users/michael/bin/gcc-trunk-20160511-avr/libexec/gcc/avr/7.0.0/:/Users/michael/bin/gcc-trunk-20160511-avr/libexec/gcc/avr/7.0.0/:/Users/michael/bin/gcc-trunk-20160511-avr/libexec/gcc/avr/:/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/:/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/
LIBRARY_PATH=/Users/michael/bin/gcc-trunk-20160511-avr/lib/gcc/avr/7.0.0/
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-Os' '-o' 't.S' '-S' '-v'
'-specs=device-specs/specs-avr2'
# grep -4 rjmp t.S
.L__stack_usage = 0
lds r24,1
sbrs r24,0
.L4:
rjmp .L4
.L5:
ldi r24,0
ldi r25,0
/* epilogue start */

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  ---
> I've just been notified that the bug is fixed in Xcode 7.3.1. 
> Will try that as soon as it hits the Appstore.

I have Xcode 7.3.1 since May 4.

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
6.1.1 is not a release, it's the current development snapshot from the gcc-6
branch. It will be fixed in a later version.

[Bug tree-optimization/71060] Compiler reports "loop vectorized" but actually it was not

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
Ok, so in this case the issue is not different base objects but operand_equal_p
returning zero because

3058  || (MR_DEPENDENCE_CLIQUE (arg0)
3059  != MR_DEPENDENCE_CLIQUE (arg1))
3060  || (MR_DEPENDENCE_BASE (arg0)
3061  != MR_DEPENDENCE_BASE (arg1)))

and thus indeed restrict info.  restrict info is not preserved when
if-conversion
creates MASK_{LOAD,STORE}.

[Bug middle-end/71002] [6 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression]|[6 Regression]
   |-fstrict-aliasing breaks|-fstrict-aliasing breaks
   |Boost's short string|Boost's short string
   |optimization implementation |optimization implementation

--- Comment #12 from Richard Biener  ---
Mitigated on trunk sofar.

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Wed May 11 10:24:11 2016
New Revision: 236117

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

PR middle-end/71002
* alias.c (reference_alias_ptr_type): Preserve alias-set zero
if the langhook insists on it.
* fold-const.c (make_bit_field_ref): Add arg for the original
reference and preserve its alias-set.
(decode_field_reference): Take exp by reference and adjust it
to the original memory reference.
(optimize_bit_field_compare): Adjust callers.
(fold_truth_andor_1): Likewise.
* gimplify.c (gimplify_expr): Adjust in-SSA form test.

* g++.dg/torture/pr71002.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr71002.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/fold-const.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71002] [6 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression]|[6 Regression]
   |-fstrict-aliasing breaks|-fstrict-aliasing breaks
   |Boost's short string|Boost's short string
   |optimization implementation |optimization implementation

--- Comment #12 from Richard Biener  ---
Mitigated on trunk sofar.

[Bug fortran/70855] [6/7 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 38468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38468&action=edit
gcc7-pr70855.patch

Untested simple fix (that is backportable too).
If we want to parallelize this, I'd say the right thing would be still to
disable the inlining during frontend passes when in omp workshare, make the
inline_matmul_assign function no longer static and during omp workshare
translation call that with some special arguments that would arrange for it to
be properly parallelized.  We'd need to ensure that the c = 0 clearing is split
to threads the same way as the following loop, and that each entry in the c
array is only set and modified in the same thread.

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[tuwwcn at gmail dot com]

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

--- Comment #8 from Wei-Wei Tu  ---
Would this bug be fixed in gcc 6.1.1 or in later version?

[Bug tree-optimization/70876] ICE in chkp_find_bounds: Unexpected tree code with_size_expr

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #3 from Ilya Enkovich  ---
Fixed

[Bug middle-end/70877] [MPX] ICE in in convert_move

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
Fixed

[Bug middle-end/70877] [MPX] ICE in in convert_move

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed May 11 09:55:55 2016
New Revision: 236116

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

Backport from mainline r236088.
2016-05-10  Ilya Enkovich  

PR middle-end/70877
* tree-chkp.c (chkp_add_bounds_to_call_stmt): Handle
calls with type casted fndecl.

gcc/testsuite/

Backport from mainline r236088.
2016-05-10  Ilya Enkovich  

PR middle-end/70877
* gcc.target/i386/pr70877.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr70877.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-chkp.c

[Bug tree-optimization/70876] ICE in chkp_find_bounds: Unexpected tree code with_size_expr

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed May 11 09:51:49 2016
New Revision: 236115

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

Backport from mainline r236086.
2016-05-10  Ilya Enkovich  

PR tree-optimization/70876
* tree-chkp.c (chkp_find_bounds_1): Support WITH_SIZE_EXPR.
* gcc/calls.c (initialize_argument_information): Bind bounds
with corresponding args passed by reference.

gcc/testsuite/

Backport from mainline r236086.
2016-05-10  Ilya Enkovich  

PR tree-optimization/70876
* gcc.target/i386/pr70876.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr70876.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/calls.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-chkp.c

[Bug middle-end/70807] fwprop pass ICE with incoming CDI_DOMINATORS

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #5 from Ilya Enkovich  ---
Fixed

[Bug fortran/70855] [6/7 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r222864 aka PR37131 to be precise.

[Bug tree-optimization/71060] Compiler reports "loop vectorized" but actually it was not

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yeah, I guess it's the same as PR65206 - a disconnect between dependence
analysis and versioning for aliasing.

I'm going to fix the diagnostic issue, the underlying issue is tracked in
PR65206.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Guess pretty much a dup of PR71054, at least the original issue is the same, we
have DECL_EXPR with VAR_DECL that has DECL_INITIAL of CONSTRUCTOR that contains
PTRMEM_CSTs inside of it.  And we never call cp_genericize_r or anything else
that would replace PTRMEM_CSTs on the CONSTRUCTOR.

[Bug middle-end/70807] fwprop pass ICE with incoming CDI_DOMINATORS

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed May 11 09:33:13 2016
New Revision: 236114

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

PR middle-end/70807
* cfgrtl.h (delete_insn_and_edges): Now return bool.
* cfgrtl.c (delete_insn_and_edges): Likewise.
* config/i386/i386.c (convert_scalars_to_vector): Remove
redundant code.
* cse.c (cse_insn): Compute cse_cfg_altered.
(delete_trivially_dead_insns): Likewise.
(cse_cc_succs): Likewise.
(rest_of_handle_cse): Free dominance info if required.
(rest_of_handle_cse2): Likewise.
(rest_of_handle_cse_after_global_opts): Likewise.

gcc/testsuite/

PR middle-end/70807
* gcc.dg/pr70807.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70807.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/cfgrtl.h
trunk/gcc/config/i386/i386.c
trunk/gcc/cse.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/70876] ICE in chkp_find_bounds: Unexpected tree code with_size_expr

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Fixed in trunk by r236086

[Bug tree-optimization/70916] [6 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "tree_operand_check"

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
The ICE is fixed, the second patch has been just an optimization, so shouldn't
be backported, but for the last patch dunno, I believe it already had some
follow up.

[Bug libstdc++/71049] [6/7 Regression] libstdc++ fails to build --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/71049] [6/7 Regression] libstdc++ fails to build --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-11
   Target Milestone|--- |6.2
 Ever confirmed|0   |1

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |7.0

--- Comment #1 from Richard Biener  ---
On GIMPLE this is now "optimized" to refer to the upper half of the double
with a BIT_FIELD_REF of the parameter d and the union is optimized away.
Ideally this results in (subreg:SI (reg:DF ...) 4) or an equivalent highpart.

It looks like expansion spills this to memory (in theory ok, you'd get sth
equivalent to the union) but then sth messes up things badly.  The GIMPLE
transform doesn't factor in that the store to u->val isn't dead after it.

RTL opt/target bug.

Equivalent code for pre-r236066 would be

unsigned int f (double d, words *u)
{
  u->val = d;
  return ((unsigned int *)&d)[1];
}

and compiling with -fno-strict-aliasing.

With -mcpu=power8 I get

f:
mfvsrd 9,1
stfd 1,0(4)
srdi 3,9,32
blr

Expansion does a df->di move and then extracts the bits via a shift.


So, as I suspected it might be neccessary to restrict the kind of
"subregs" we create.  The transform was designed to avoid the union for
the variant

typedef union {
double val;
struct {
unsigned int w1;
unsigned int w2;
};
} words;

unsigned int f (double d)
{
  words u;
  u.val = d;
  return u.w2;
}

but even for that RTL opts cannot recover the original code it seems
as the backend lies to the middle-end(?) in claiming it can do

(insn 6 5 7 (set (reg:DI 158)
(subreg:DI (reg/v:DF 156 [ d ]) 0)) t.c:13 -1
 (nil))

but in reality it later goes through memory for this which when done
at expansion time would have resulted in the same code as when being
present with the union.

[Bug tree-optimization/71060] New: Compiler reports "loop vectorized" but actually it was not

[niva at niisi dot msk.ru]

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

Bug ID: 71060
   Summary: Compiler reports "loop vectorized" but actually  it
was not
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru
  Target Milestone: ---

Created attachment 38467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38467&action=edit
The test case to reproduce the problem

I compile the attached test8.c as follows:

/usr/local/bin/gcc   -O3 -S -mavx -fopt-info-vec-optimized -DSCOUT -Wall
-Wextra -Werror -Wno-unknown-pragmas test8.c -o test8.s3

The output is:

test8.c:24:2: note: loop vectorized
test8.c:24:2: note: loop versioned for vectorization because of possible
aliasing

But the resulting assembler code contains no vector instructions. 

Other problems related to this test are:

1. The pointers in this function has the restrict specifier, so there should be
no loop versioning.

2. I tried to use -ftree-loop-if-convert-stores but it did not help.

Possibly this bug is the same as 65206.

[Bug c++/71054] [6/7 Regression] ICE: in expand_expr_real_2, at expr.c:8097

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The problem is that with the PTRMEM_CST handling moved from the gimplification
hook to genericization (the right thing), as apparently we don't genericize
DECL_INITIAL of VAR_DECLs, nothing handles the PTRMEM_CST anymore.
We have a DECL_EXPR with an artificial VAR_DECL in there that has DECL_INITIAL
set to a CONSTRUCTOR that contains PTRMEM_CST somewhere.
This is due to
  else if (IS_TYPE_OR_DECL_P (stmt))
*walk_subtrees = 0;
Shall we recurse on DECL_INITIAL when handling DECL_EXPRs, when handling the
VAR_Ps, something else?  Or just call a different walk_tree that only removes
the PTRMEM_CSTs and nothing else?

[Bug target/71053] [6/7 Regression] Volatile read optimized into endless loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
  Component|c++ |target
   Target Milestone|--- |6.2
Summary|[6.1 regression] Volatile   |[6/7 Regression] Volatile
   |read optimized into endless |read optimized into endless
   |loop|loop

--- Comment #1 from Richard Biener  ---
On x86_64 I get

main:
.LFB0:
.cfi_startproc
.L2:
movb1, %al
testb   $1, %al
je  .L2
xorl%eax, %eax
ret

and thus it works fine there.  Target issue.

[Bug c++/71054] [6/7 Regression] ICE: in expand_expr_real_2, at expr.c:8097

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2