[Bug tree-optimization/78305] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-11
 Ever confirmed|0   |1

--- Comment #2 from Marc Glisse  ---
fold_negate_expr/negate_expr_p somehow miss that -(y/x) cannot be turned into
(-y)/x when y might be INT_MIN.

[Bug sanitizer/78294] -fsanitize=thread broken

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #2 from Maxim Ostapenko  ---
The testcase also works for me with Glibc 2.24 and dynamic libtsan:

max@max:/tmp$ echo "int main(){}" | ~/install/master/bin/g++ -fsanitize=thread 
-L/home/max/install/glibc/usr/lib -L/home/max/install/glibc/lib
-I/home/max/install/glibc/include -Wl,-rpath=/home/max/install/glibc/lib
-Wl,--dynamic-linker=/home/max/install/glibc/lib/ld-2.24.90.so 
-Wl,-rpath=/home/max//install/master/lib64  -x c++ - && ./a.out
max@max:/tmp$ echo $?
0
max@max:/tmp$ ldd a.out 
linux-vdso.so.1 =>  (0x7ffe0edb)
libtsan.so.0 => /home/max//install/master/lib64/libtsan.so.0
(0x7f6d97505000)
libstdc++.so.6 => /home/max//install/master/lib64/libstdc++.so.6
(0x7f6d97183000)
libm.so.6 => /home/max/install/glibc/lib/libm.so.6 (0x7f6d96e7f000)
libgcc_s.so.1 => /home/max/install/glibc/lib/libgcc_s.so.1
(0x7f6d96c69000)
libc.so.6 => /home/max/install/glibc/lib/libc.so.6 (0x7f6d968d)
libdl.so.2 => /home/max/install/glibc/lib/libdl.so.2
(0x7f6d966cc000)
librt.so.1 => /home/max/install/glibc/lib/librt.so.1
(0x7f6d964c4000)
libpthread.so.0 => /home/max/install/glibc/lib/libpthread.so.0
(0x7f6d962a7000)
/home/max/install/glibc/lib/ld-2.24.90.so =>
/lib64/ld-linux-x86-64.so.2 (0x7f6d985bc000)

[Bug target/78213] [7 Regression] -fself-test fails on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Then we should clearly error out or sorry when with -fself-test we see
non-empty TU.

[Bug middle-end/17308] nonnull attribute not as useful as it could

[frankhb1989 at gmail dot com]

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

frankhb1989 at gmail dot com changed:

   What|Removed |Added

 CC||frankhb1989 at gmail dot com

--- Comment #13 from frankhb1989 at gmail dot com ---
It should be noted that current implementation is conflict with assertions in
some cases, as in
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VA2QCXJGXVLH43327TRR5UM2BP52DWIC/.
The purpose of such an attribute is not emphasized in the documentation, which
leads to the confusion.

I'm actually not against the semantics it implies, but I find the warning
actually reduce its availability for other reasons.

Note `assert` is required to be supported by the standard, so it will work
across different implementations, including those do not support
`__attribute__` at all. To get the code portable, the attributes will always be
wrapped in macros whose names are not reserved identifiers. It should be
natural that by conditionally defining such macros as nothing, each
configuration of every implementation would be happy eventually, because
modifying assertions everywhere in current code (instead modifying the macros)
is obviously infeasible in general.

A question is, when to disable the attribute?

For debug build configurations (with `NDEBUG` undefined), it has almost no side
effect by conditional definition based on some conditions (like `NDEBUG`),
except one: the conditions may have to be duplicated in #ifdef/#if in different
places of the code. It is still not a big trouble for `assert` normally, but it
can be a disaster for custom assertion macros when the conditions are
complicated enough. And though rarely, it can be a nightmare after the
condition macros are defined (after necessary #undef) more than once, by
different authors of the code.

For release configurations (such as builds with properly defined `NDEBUG`), the
problem is more serious. Since the attribute is designed as a hint of
optimization, it should not be defined as nothing besides debugging. But to
modify all occurrence of assertions is still even more absurd, whether they
will generate code or not.

So there is a dilemma: which one to keep, the assertions or the attribute?
Removing the assertions is infeasible; unconditionally disabling the attribute
is illogical (and totally nonsense for old versions of GCC which I need to
adapt to). And clearly, I don't want to maintain multiple copies of the code
just for different build configurations; I definitely need both of them in such
cases. Thus either choice is essentially bad.

The final workaround (*not the fix*) is to disable the warning itself, which is
configuration-neutral and it should does work at least as old versions of GCC.
However, old compiler drivers do not recognize such options. To maintain the
divergence in build scripts is dirty. So it should better be... pragmas? The
last problem: #pragma or _Pragma to disable such diagnostics does not work. Is
it a bug, or unsupported at all?

[Bug sanitizer/78294] -fsanitize=thread broken

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #1 from Dmitry Vyukov  ---
Humm... This is puzzling.

Just in case, you set LD_LIBRARY_PATH to point to the new libtsan.so?

ScopedInterceptor already called cur_thread here:
#4  0x76f43b90 in __tsan::ScopedInterceptor::ScopedInterceptor
and it did not crash.

But then 
#2  0x76f8b00a in
__tsan::ScopedIgnoreInterceptors::ScopedIgnoreInterceptors
calls cur_thread again and it ends up in __tls_get_addr, which crashes...

I've just built gcc version 7.0.0 2016 (experimental) (GCC), and your repro
works. Although, I have a different kernel and glibc.

However, __tsan::Initialize does not contain a call to __tls_get_addr to get
the address of cur_thread:

0006da60 <__tsan::Initialize(__tsan::ThreadState*)>:
   6da60:   80 3d 25 73 47 00 00cmpb   $0x0,0x477325(%rip)#
4e4d8c <__tsan::Initialize(__tsan::ThreadState*)::is_initialized>
   6da67:   74 07   je 6da70
<__tsan::Initialize(__tsan::ThreadState*)+0x10>
   6da69:   f3 c3   repz retq 
   6da6b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
   6da70:   41 57   push   %r15
   6da72:   41 56   push   %r14
   6da74:   41 55   push   %r13
   6da76:   41 54   push   %r12
   6da78:   55  push   %rbp
   6da79:   53  push   %rbx
   6da7a:   48 83 ec 48 sub$0x48,%rsp
   6da7e:   c6 05 07 73 47 00 01movb   $0x1,0x477307(%rip)#
4e4d8c <__tsan::Initialize(__tsan::ThreadState*)::is_initialized>
   6da85:   48 89 7c 24 18  mov%rdi,0x18(%rsp)
   6da8a:   64 48 8b 04 25 00 00mov%fs:0x0,%rax
   6da91:   00 00 
   6da93:   48 03 05 fe 9e 26 00add0x269efe(%rip),%rax#
2d7998 <_DYNAMIC+0xa10>
   6da9a:   48 8d 3d 6f ce 00 00lea0xce6f(%rip),%rdi# 7a910
<__tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long,
unsigned long long)>
   6daa1:   48 8d 0d 1c 09 04 00lea0x4091c(%rip),%rcx#
ae3c4 <__tsan::MutexSet::kMaxSize+0x1024>
   6daa8:   83 80 98 02 02 00 01addl   $0x1,0x20298(%rax)


The instructions are:

   6da8a:   64 48 8b 04 25 00 00mov%fs:0x0,%rax
   6da93:   48 03 05 fe 9e 26 00add0x269efe(%rip),%rax
   6daa8:   83 80 98 02 02 00 01addl   $0x1,0x20298(%rax)

which is reasonable for initial_exec tls.

Please post disassembly of these frames and point to the exact call sites:

#2  0x76f8b00a in
__tsan::ScopedIgnoreInterceptors::ScopedIgnoreInterceptors (this=) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.h:549
#3  __tsan::Initialize (thr=thr@entry=0x76277780) at
../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:331

[Bug fortran/78293] [5/6/7 Regression] SIGABRT with function result used as argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
I have a most of the way working patch for this PR. Or, at least, I have found
the sensitive point and can persuade the testcase to run correctly. To my
astonishment, there is but one trivial regression. I need to check for memory
leaks before I post the patch, however.

Cheers

Paul

[Bug target/78213] [7 Regression] -fself-test fails on aarch64

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
(In reply to Aldy Hernandez from comment #5)
> Confirmed with a cross build with:
> 
> cat >a.c < int i;  
> void bar(); 
> void foo()
> {
> while (i--)
> bar();
> }
> EOF
> ./xgcc -fself-test -S a.c -B./

FWIW I've only been attempting to support running -fself-test with *empty*
source files; expect tests to start failing if you try to also compile
something at the same time.

[Bug fortran/77505] Negative character length not treated as LEN=0

[elizebethp at gmail dot com]

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

Elizebeth Punnoose  changed:

   What|Removed |Added

 CC||elizebethp at gmail dot com

--- Comment #3 from Elizebeth Punnoose  ---
The segmentation fault is reproducible on x86 & ARM64, with the top of trunk.
I have now added a check in trans-array.c:trans_array_constructor()
to check for character lengths less than zero, for character arrays.
If the length is found to be negative, a warning message is printed that the
length will be considered as LEN=0, and the length is set to zero.

Index: trans-array.c
===
--- trans-array.c   (revision 241960)
+++ trans-array.c   (working copy)
@@ -2226,6 +2226,8 @@
   gfc_ss_info *ss_info;
   gfc_expr *expr;
   gfc_ss *s;
+  tree neg_len;
+  char *msg;

   /* Save the old values for nested checking.  */
   old_first_len = first_len;
@@ -2271,6 +2273,19 @@
  gfc_conv_expr_type (_se, expr->ts.u.cl->length,
  gfc_charlen_type_node);
  ss_info->string_length = length_se.expr;
+
+  /* Check if the length is negative, if so print a warning
+ and consider the length as zero. */
+  neg_len = fold_build2_loc (input_location, LT_EXPR,
+ boolean_type_node,
+ ss_info->string_length, build_int_cst
(gfc_charlen_type_node, 0));
+  msg = xasprintf ("Negative character length will be treated as
LEN=0");
+  gfc_trans_runtime_check (false, true, neg_len, _se.pre,
where, msg);
+  free(msg);
+  ss_info->string_length = fold_build3_loc (input_location, COND_EXPR,
gfc_charlen_type_node,
+ neg_len, gfc_index_zero_node,
ss_info->string_length);
+  ss_info->string_length = gfc_evaluate_now (ss_info->string_length,
_se.pre);
+
  gfc_add_block_to_block (_loop->pre, _se.pre);
  gfc_add_block_to_block (_loop->post, _se.post);
}

The test suite has run clean with the above changes merged on top of trunk.
Kindly review and provide your suggestions if any.
I will post the patch on the gcc-patches mail list, if there is no objection.

[Bug target/78213] [7 Regression] -fself-test fails on aarch64

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #5 from Aldy Hernandez  ---
Confirmed with a cross build with:

cat >a.c <
Date:   Fri Oct 21 13:52:53 2016 +

Start adding selftests for print_rtx
gcc/ChangeLog:
* print-rtl-function.c (flag_compact): Move extern decl to...
* print-rtl.h (flag_compact): ...here.
* rtl-tests.c (selftests::assert_rtl_dump_eq): New function.
(ASSERT_RTL_DUMP_EQ): New macro.   
(selftest::test_dumping_regs): New function.   
(selftest::test_dumping_insns): New function.
(selftest::test_uncond_jump): Add uses of ASSERT_RTL_DUMP_EQ on
the insns.
(selftest::rtl_tests_c_tests): Call the new test functions.



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

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
(In reply to Aldy Hernandez from comment #1)
> I cannot reproduce this on a cross build from x86-64 Linux to
> --target=powerpc-*-linux-gnu.  I cannot reproduce on neither mainline nor 2
> months back on mainline.
> 
> Does this problem still exist in the latest mainline?

For me, yes:

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161106 -mno-lra -Os -c -w
buwdtjav.c 
buwdtjav.c: In function 'hx':
buwdtjav.c:25:1: internal compiler error: in push_reload, at reload.c:1344
 }
 ^
0x30331d906a3 push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/gcc/reload.c:1343
0x30331d96acb find_reloads(rtx_insn*, int, int, int, short*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/gcc/reload.c:4027
0x30331da8854 calculate_needs_all_insns
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/gcc/reload1.c:1474
0x30331da8854 reload(rtx_insn*, int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/gcc/reload1.c:988
0x30331c2dd6e do_reload
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/gcc/ira.c:5386
0x30331c2dd6e execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/gcc/ira.c:5558
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

But maybe you also need -fno-PIC -fno-stack-protector?

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161106 -mno-lra -Os -fPIC
-fstack-protector -c -w buwdtjav.c
% echo $?
0

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161106 -v
Using built-in specs.
COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161106
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106/lto-wrapper
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20161106/work/gcc-7-20161106/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/7.0.0-alpha20161106
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106/include/g++-v7
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/7.0.0-alpha20161106/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
Thread model: posix
gcc version 7.0.0-alpha20161106 20161106 (experimental) (GCC)

[Bug c++/77849] [5/6 Regression] Warning about deprecated enum even when "-Wdeprecated-declarations" is off

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

[Bug c++/77849] [5/6 Regression] Warning about deprecated enum even when "-Wdeprecated-declarations" is off

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
Summary|[5/6/7 Regression] Warning  |[5/6 Regression] Warning
   |about deprecated enum even  |about deprecated enum even
   |when|when
   |"-Wdeprecated-declarations" |"-Wdeprecated-declarations"
   |is off  |is off

--- Comment #1 from Aldy Hernandez  ---
Confirmed on gcc5 and gcc6 branches.

Cannot be confirmed on mainline.  Removing GCC 7 tag.

By the way, was this ever working prior to GCC 5 to be marked as a regression?

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #22)
> (In reply to Iain Sandoe from comment #3)
> > (In reply to Maxim Ostapenko from comment #1)
> > > Eh, mine.
> > > 
> > > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange,
> > > it seems that it's an Objective-C declaration, right?
> > 
> > It's declaring os_trace_payload_t to of type "Apple block" (like a lambda
> > that can be used over the whole of c-family);  Apple blocks are currently
> > not supported by GCC.  There is no realistic work-around, any interface
> > using blocks will fail, and thus either those interfaces need to be excluded
> > from tests, or the tests skipped/xfailed.
> >
> 
> To be specific, they're not supported by the FSF release of GCC. Apple's
> fork of GCC supported blocks back before they ditched it for clang, so this
> isn't just a clang extension.

Apple's blocks implementation was never submitted "upstream" is my
understanding, it's not present in any branch on an FSF server (and thus we
can't use it, even if it were usable 4.2 => 7.0, which it isn't without
significant re-work).

(Let's not side-track this PR - perhaps we should just file one to cover
missing blocks support, 63651 already discusses two different problems).

[Bug tree-optimization/71380] [7 Regression] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2498

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #1 from Aldy Hernandez  ---
Confirmed on a cross build.  Started with:

commit 410372fef14173261ce8e547db98eafb3174921f
Author: rguenth 
Date:   Thu May 19 07:39:52 2016 +

2016-05-19  Richard Biener  

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

* gcc.dg/autopar/outer-6.c: Adjust to avoid redundant store.
* gcc.dg/graphite/scop-18.c: Likewise.
* gcc.dg/pr41783.c: Disable LIM.
* gcc.dg/tree-ssa/loadpre10.c: Likewise.
* gcc.dg/tree-ssa/loadpre23.c: Likewise.
* gcc.dg/tree-ssa/loadpre24.c: Likewise.
* gcc.dg/tree-ssa/loadpre25.c: Likewise.
* gcc.dg/tree-ssa/loadpre4.c: Likewise.
* gcc.dg/tree-ssa/loadpre8.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-18.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-20.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-3.c: Likewise.
* gfortran.dg/pr42108.f90: Likewise.


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

[Bug tree-optimization/78305] Wrong constant folding

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>-0x4000 * a

int a = 2;

Does that not overflow?

[Bug tree-optimization/78305] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 78305
   Summary: Wrong constant folding
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC 7.0.0 for x86_64 miscompiles the following code.


% cat test.c
int main (void)
{
int a = 2;
int b = 1;

int t = -1 * ( -0x4000 * a / ( -0x2000 + b ) )  / -1;

if (t != 4) __builtin_abort();

return 0;
}
% gcc-7.0 test.c
% ./a.out
zsh: abort (core dumped)  ./a.out
% gcc-7.0 -v
Using built-in specs.
COLLECT_GCC=gcc-7.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-7.0.0/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-7.0.0 --disable-nls
--disable-multilib --program-suffix=-7.0 --enable-languages=c
Thread model: posix
gcc version 7.0.0 20161108 (experimental) (GCC)

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-11
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
I cannot reproduce this on a cross build from x86-64 Linux to
--target=powerpc-*-linux-gnu.  I cannot reproduce on neither mainline nor 2
months back on mainline.

Does this problem still exist in the latest mainline?

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #22 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Maxim Ostapenko from comment #1)
> > Eh, mine.
> > 
> > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange,
> > it seems that it's an Objective-C declaration, right?
> 
> It's declaring os_trace_payload_t to of type "Apple block" (like a lambda
> that can be used over the whole of c-family);  Apple blocks are currently
> not supported by GCC.  There is no realistic work-around, any interface
> using blocks will fail, and thus either those interfaces need to be excluded
> from tests, or the tests skipped/xfailed.
>

To be specific, they're not supported by the FSF release of GCC. Apple's fork
of GCC supported blocks back before they ditched it for clang, so this isn't
just a clang extension. Bug 63651 has more stuff about support for blocks in
FSF GCC.

[Bug tree-optimization/78121] [7 Regression] ice in set_value_range

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||aldyh at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Aldy Hernandez  ---
Fixed in mainline.

[Bug c/78304] New: -Wformat doesn't warn anymore for inttypes.h format string argument type mismatches

[mark at gcc dot gnu.org]

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

Bug ID: 78304
   Summary: -Wformat doesn't warn anymore for inttypes.h format
string argument type mismatches
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark at gcc dot gnu.org
  Target Milestone: ---

For this program:

#include 
#include 

int
main (int argc, char **argv)
{
  size_t size = argc;
  printf ("size: %" PRIu32 "\n", size);
  return 0;
}

gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) warns when given -Wformat:

t.c: In function ‘main’:
t.c:8:3: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘size_t’ [-Wformat=]
   printf ("size: %" PRIu32 "\n", size);
   ^

gcc (GCC) 7.0.0 20161110 (experimental) doesn't give any warning with -Wformat.

Note that both versions do warn when using "size: %u\n" as format string:

t.c: In function ‘main’:
t.c:8:19: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
   printf ("size: %u\n", size);
  ~^
  %lu

They also both warn when using normal string concatenation:

 t.c: In function ‘main’:
t.c:8:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
   printf ("size: %" "u" "\n", size);
   ^
t.c:8:22: note: format string is defined here
   printf ("size: %" "u" "\n", size);
  ^
  %" "lu

They even both warn when doing the format string define in the file itself:

#include 

#define UFORMAT "u"

int
main (int argc, char **argv)
{
  size_t size = argc;
  printf ("size: %" UFORMAT "\n", size);
  return 0;
}

But gcc 4.8.5 has a better warning message:

t.c: In function ‘main’:
t.c:9:3: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘size_t’ [-Wformat=]
   printf ("size: %" UFORMAT "\n", size);
   ^

While 7.0.0 gives the somewhat cryptic:

t.c: In function ‘main’:
t.c:3:18: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
 #define UFORMAT "u"
  ^

[Bug target/78303] New: PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be

[meissner at gcc dot gnu.org]

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

Bug ID: 78303
   Summary: PowerPC vec-init-{1,2,4,5,8,9} tests do not run on
-mlittle -maltivec=be
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I was fixing PR 78243, and I decided to try the vec-init-{1,2,4,5,8,9} tests
that I wrote when I was adding power8/power9 vector init/extract support with
the -maltivec=be option.  None of the vec-init tests run with -maltivec=be.

This option says that even though we are running on a little endian target, the
ordering of elements within Altivec/VSX registers is still big endian to allow
code that was targeted towards the big endian PowerPC to run.

I tested both GCC 6 and the current GCC 7 sources, and both fail.

[Bug c/37998] Unclear documentation of -fno-common

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from sandra at gcc dot gnu.org ---
Fixed on trunk.

[Bug rtl-optimization/78127] [5/6/7 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #1 from Aldy Hernandez  ---
Confirmed with a cross build.

[Bug middle-end/78225] [7 Regression] FAIL: gcc.dg/gomp/pr27573.c (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-11
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
I cannot reproduce on a cross build with --target=hppa-unknown-linux-gnu.  Is
this problem still present in mainline, but is not reproducible with a cross
build?

tor~/bld/t/gcc$ ./cc1 a.c -quiet -fno-diagnostics-show-caret
-fdiagnostics-color=never   -O2 -fopenmp -fprofile-generate  -I.
tor~/bld/t/gcc$ ./cc1plus a.c -quiet -fno-diagnostics-show-caret
-fdiagnostics-color=never   -O2 -fopenmp -fprofile-generate  -I.
tor~/bld/t/gcc$ cat a.c
/* PR middle-end/27573 */
/* { dg-do compile } */
/* { dg-require-profiling "-fprofile-generate" } */
/* { dg-options "-O2 -fopenmp -fprofile-generate" } */

extern int puts (const char *);

int
main (void)
{
  int i, j = 8;
#pragma omp parallel
  {
puts ("foo");
for (i = 1; i < j - 1; i++)
  ;
  }
  return 0;
}

[Bug libstdc++/78302] is_move_constructible_v<tuple> should be false

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
Ugh, quasi-dup, I suppose. But if I'm reading the correspondence correctly, the
ABI breaking is only because of triviality, correct?

So if we just want to make is_move_constructible not lie, it should be possible
to do something like adding an empty base at the top level that is either
movable or not depending on __and_...> so that
the tuple(tuple&&) =default; will become deleted for nonmovable elements?

[Bug c++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-11
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
As Solaris boxes with their header files are not readily available (at least to
me), would you mind attaching a preprocessed reduced testcase exhibiting the
behavior?  Thanks.

[Bug c/37998] Unclear documentation of -fno-common

[sandra at gcc dot gnu.org]

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov 10 23:56:30 2016
New Revision: 242062

URL: https://gcc.gnu.org/viewcvs?rev=242062=gcc=rev
Log:
2016-11-10  Sandra Loosemore  

PR c/37998

gcc/
* doc/invoke.texi (Code Gen Options) [-fno-common]: Use correct
terminology.  Expand to remove ambiguity.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug libstdc++/78302] is_move_constructible_v<tuple> should be false

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
See also PR 71301.

[Bug fortran/44348] ICE in build_function_decl

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> The test in comment 2 compiles without error at revision r242002
> although I think it is invalid. It gives an ICE with r241962.

This is due to r241972 (pr77596).

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

--- Comment #12 from DIL  ---
Indeed, thanks again.

[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> The tests z7.f90, z8.f90, and z9.f90 compiles without error
> at revision r242002 although I think they are invalid.
> They give an ICE with r241962.

This is due to r241972 (pr77596).

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> Not yet.  I won't have time to apply the patch until
> tomorrow or Saturday.  I posted the patch to bugzilla
> so it does not get lost.  Once it is in the source tree,
> you can use svn to pull the source down.

You can also pull the source down and apply the patch yourself.

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

--- Comment #10 from DIL  ---
Thanks!

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Thu, Nov 10, 2016 at 10:40:15PM +, liakhdi at ornl dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
> 
> --- Comment #8 from DIL  ---
> Is there a way to download the GCC source with this patch applied?
> 

Not yet.  I won't have time to apply the patch until
tomorrow or Saturday.  I posted the patch to bugzilla
so it does not get lost.  Once it is in the source tree,
you can use svn to pull the source down.

[Bug rtl-optimization/78232] [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Thu Nov 10 22:45:39 2016
New Revision: 242059

URL: https://gcc.gnu.org/viewcvs?rev=242059=gcc=rev
Log:
combine: Do not call simplify from inside change_zero_ext (PR78232)

When combine splits a three-insn combination into two instructions it
can reuse i2dest for the temporary result of the first new instruction.
However all information it has in reg_stat about that register will be
stale.  This results in the simplify_gen_binary calls in change_zero_ext
using out-of-date information, which makes it think one of the ANDs
generated there always results in 0, and it doesn't get better from there.

This can also happen if a splitter in the MD uses nonzero_bits (for
example).  I tried to make the splitting code in combine save and restore
the i2dest reg_stat info, but that causes one of the acats tests to fail.

This whole reg_stat thing needs an overhaul, and/or we shouldn't reuse
i2dest for unrelated purposes when splitting.

This patch changes change_zero_ext to do the expected simplifications
itself and not call simplify_gen_*.


PR rtl-optimization/78232
* combine.c (try_combine): Add a big comment about why reusing i2dest
is undesirable.
(change_zero_ext): Do not call simplify_gen_binary, do the
simplifications manually.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug fortran/78297] ICE in finish_equivalences, at fortran/trans-common.c:1246

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug ipa/78296] [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kugan at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #0)
> spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc
> -B/home/seurer/gcc/build/gcc-test2/gcc/
> /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/vrp7.c
> -fno-diagnostics-show-caret -fdiagnostics-color=never -O2
> -fdump-ipa-cp-details -S -o vrp7.s
> PASS: gcc.dg/ipa/vrp7.c (test for excess errors)
> FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param
> 0 \\[-10, 9\\]" 1
> 
>   === gcc Summary ===
> 
> # of expected passes  1
> # of unexpected failures  1

Thanks for the report. This is expected as I have reverted r241990 which does
this optimization. I will repost r241990 when I have fixed the bootstrap
comparison issue at the earliest.

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

--- Comment #8 from DIL  ---
Is there a way to download the GCC source with this patch applied?

[Bug libstdc++/78302] New: is_move_constructible_v<tuple> should be false

[rs2740 at gmail dot com]

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

Bug ID: 78302
   Summary: is_move_constructible_v should be
false
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

#include 
#include 

struct nonmovable
{
nonmovable(nonmovable&&) = delete;
};
static_assert(!std::is_move_constructible_v); //fires

It's not clear whether this is required by the standard (the standard depicts a
defaulted move constructor, and core language rules say that a defaulted move
constructor is defined as deleted if a subobject cannot be moved), but in any
event this should probably return false as a QoI matter.

[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450

[foreese at gcc dot gnu.org]

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

--- Comment #4 from Fritz Reese  ---
Author: foreese
Date: Thu Nov 10 21:57:13 2016
New Revision: 242058

URL: https://gcc.gnu.org/viewcvs?rev=242058=gcc=rev
Log:
Fix ICE and improve errors for invalid anonymous structure declarations.

PR fortran/78277
* gcc/fortran/decl.c (gfc_match_data_decl): Gracefully handle bad
anonymous structure declarations.

PR fortran/78277
* gcc/testsuite/gfortran.dg/dec_structure_17.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dec_structure_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Nov 10 21:42:36 2016
New Revision: 242056

URL: https://gcc.gnu.org/viewcvs?rev=242056=gcc=rev
Log:
PR c++/77337 - auto return and lambda

* pt.c (tsubst_friend_function): Don't set DECL_INITIAL.
(instantiate_decl): It's OK to defer a constexpr function.
* cp-tree.h (DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION): Check
DECL_LANG_SPECIFIC.
* decl2.c (decl_defined_p): Use it.  No longer static.
* decl.c (redeclaration_error_message): Use decl_defined_p.
* constexpr.c (cxx_eval_call_expression): Set input_location around
call to instantiate_decl.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
Here's a patch that allows the reduced testcase compile.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 241667)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11719,7 +11719,8 @@ resolve_fl_var_and_proc (gfc_symbol *sym
   /* Assume that use associated symbols were checked in the module ns.
 Class-variables that are associate-names are also something special
 and excepted from the test.  */
-  if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->assoc)
+  if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->attr.dummy
+ && !sym->assoc)
{
  gfc_error ("CLASS variable %qs at %L must be dummy, allocatable "
 "or pointer", sym->name, >declared_at);

[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

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

--- Comment #9 from François Dumont  ---
Fix with rev 242055 which simply remove format_word method.

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Thu, Nov 10, 2016 at 09:06:15PM +, dominiq at lps dot ens.fr wrote:
>
> Confirmed from 4.8 up to trunk (7.0). It would be nice to have a reduced
> reproducer.
> 

I certainly agree with!  It took a bit to get this.

module gfc_base

   implicit none

   integer, parameter:: INTD=4
   integer, parameter:: INTL=8
   integer(INTD), parameter :: GFC_TRUE=1, GFC_FALSE=0

   type gfc_cont_elem_t
  class(*), pointer, private:: value_p=>NULL()
  integer(INTD), private:: alloc=GFC_FALSE
  contains
 procedure, public:: construct=>ContElemConstruct
   end type gfc_cont_elem_t

   abstract interface
  function gfc_copy_i(obj,ierr) result(clone)
 import:: INTD
 class(*), pointer:: clone
 class(*), intent(in):: obj
 integer(INTD), intent(out), optional:: ierr
  end function gfc_copy_i
   end interface

   private ContElemConstruct

   contains

  subroutine ContElemConstruct(this,obj,ierr,assoc_only,copy_constr_func)
 class(gfc_cont_elem_t), intent(inout):: this
 class(*), target, intent(in):: obj
 integer(INTD), intent(out), optional:: ierr
 logical, intent(in), optional:: assoc_only
 procedure(gfc_copy_i), optional:: copy_constr_func
  end subroutine ContElemConstruct

 end module gfc_base

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0). It would be nice to have a reduced
reproducer.

[Bug c++/78301] New: noexcept() operator rejects sibling method call without object

[TonyELewis at hotmail dot com]

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

Bug ID: 78301
   Summary: noexcept() operator rejects sibling method call
without object
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TonyELewis at hotmail dot com
  Target Milestone: ---

This code fails to compile under g++ (including "gcc HEAD 7.0.0 201611" on
http://melpon.org/wandbox):

struct a {
void inner() const {}
void outer() const noexcept( noexcept( inner() ) ) {
inner();
}
};

with the error:

a.cpp:3:47: error: cannot call member function ‘void a::inner() const’ without
object
  void outer() const noexcept( noexcept( inner() ) ) {
   ^

Both Clang and MSVC accept this code, presumably treating the call to inner()
in the same way to the call in the body of outer(). This seems sensible. Is
there any principled reason g++ rejects it. If not, please can g++ be altered
to handle this inline with Clang and MSVC? Many thanks.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
> Created attachment 40012 [details]
> Untested fix 2.

Bootstrap completed successfully with this patch.

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

--- Comment #4 from DIL  ---
Created attachment 40019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40019=edit
Source file

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

--- Comment #3 from DIL  ---
Created attachment 40018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40018=edit
Source file

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

--- Comment #2 from DIL  ---
Created attachment 40017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40017=edit
Source file

[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to DIL from comment #0)
> Source code: https://gitlab.com/DmitryLyakh/GFC.git
> 

Please attach the source to the PR.

[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450

[foreese at gcc dot gnu.org]

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

--- Comment #3 from Fritz Reese  ---
Created attachment 40016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40016=edit
patch for pr78277

> https://gcc.gnu.org/ml/fortran/2016-11/msg00087.html

Patch proposed, will commit soon unless someone finds issue with it.

[Bug fortran/78300] New: Failure to compile a Fortran-2003 code with an optional dummy procedure argument.

[liakhdi at ornl dot gov]

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

Bug ID: 78300
   Summary: Failure to compile a Fortran-2003 code with an
optional dummy procedure argument.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liakhdi at ornl dot gov
  Target Milestone: ---

Source code: https://gitlab.com/DmitryLyakh/GFC.git

The minimal reproducer can be created by taking only three source files from
GFC:
gfortran -c dil_basic.F90
gfortran -c timers.F90
gfortran -c -DNO_GNU gfc_base.F90 (GFORTRAN fails to compile if you define
-DNO_GNU)

If you look inside gfc_base.F90 line 240 (subroutine ContElemConstruct), you
will see the exact place where the compile error occurs. For some reason, it
has problems with an optional dummy procedure argument. I believe this is a
compiler bug. All other compilers I tried compile and run the code fine (Cray,
PGI, XL, probably Intel as well).

Please help fixing this problem in gfortran. Thanks!

[Bug fortran/78299] New: ICE in expand_omp_for_static_nochunk, at omp-low.c:9622

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

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

Bug ID: 78299
   Summary: ICE in expand_omp_for_static_nochunk, at
omp-low.c:9622
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Invalid code affects version 6 and 7 in combination with
option -fcheck=all or -fcheck=bounds :


$ cat z1.f90
program p
   integer, parameter :: n = 8
   integer :: i, j
   real :: x(n), y(n)
   x = 1.0
   y = 2.0
   do j = 1, 9
  !$omp parallel workshare
  !$omp parallel default(shared)
  !$omp do
  do i = 1, n
 x(i) = x(i) * y(9)
  end do
  !$omp end do
  !$omp end parallel
  !$omp end parallel workshare
   end do
end


$ cat z2.f90
program p
   integer, parameter :: n = 8
   integer :: i, j
   real :: x(n), y(n)
   x = 1.0
   y = 2.0
   do j = 1, 9
  !$omp parallel do
  do i = 1, n
 x(i) = x(i) * y(9)
  end do
  !$omp end parallel do
   end do
end


$ gfortran-7-20161106 -fopenmp -fcheck=all z1.f90
z1.f90:12:25:

  x(i) = x(i) * y(9)
 1
Warning: Array reference at (1) is out of bounds (9 > 8) in dimension 1
z1.f90:10:0:

   !$omp do

internal compiler error: in expand_omp_for_static_nochunk, at omp-low.c:9622
0xb1402b expand_omp_for_static_nochunk
../../gcc/omp-low.c:9622
0xb2ae64 expand_omp_for
../../gcc/omp-low.c:11596
0xb2b47a expand_omp
../../gcc/omp-low.c:13826
0xb2b230 expand_omp
../../gcc/omp-low.c:13812
0xb2b230 expand_omp
../../gcc/omp-low.c:13812
0xb2b230 expand_omp
../../gcc/omp-low.c:13812
0xb2daed execute_expand_omp
../../gcc/omp-low.c:14051

[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #4 from Pat Haugen  ---
Fixed.

[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  ---
Author: pthaugen
Date: Thu Nov 10 18:55:57 2016
New Revision: 242047

URL: https://gcc.gnu.org/viewcvs?rev=242047=gcc=rev
Log:
PR rtl-optimization/78241
* loop-unroll.c (unroll_loop_runtime_iterations): Don't adjust 'niter',
but
emit initial peel copy if niter expr is not reliable.

* gcc.dg/pr78241.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr78241.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-unroll.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78298] New: ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115

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

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

Bug ID: 78298
   Summary: ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Gives an ICE down to at least 4.8, at -Og, -Os, -O1 or higher.
Effectively legal code, but program contains an (here unused)
internal subroutine/function with access to some variables.


$ cat z1.f90
program p
   integer :: i, j, n
   n = 2
   !$omp parallel
   !$omp do
   do i = 1, n
  !$omp parallel
  !$omp do
  do j = 1, n
 call sub(i)
  end do
  !$omp end parallel
   end do
   !$omp end parallel
   !call unused()
contains
   subroutine sub(x)
  integer :: x
   end
   subroutine unused()
  i = 0
  j = 0
   end
end


$ gfortran-7-20161106 -fopenmp -O2 z1.f90
z1.f90:7:0:

   !$omp parallel

internal compiler error: in lookup_decl_in_outer_ctx, at omp-low.c:4115
0xb1df28 lookup_decl_in_outer_ctx
../../gcc/omp-low.c:4115
0xb407a3 lower_send_shared_vars
../../gcc/omp-low.c:6259
0xb407a3 lower_omp_taskreg
../../gcc/omp-low.c:15681
0xb32306 lower_omp_1
../../gcc/omp-low.c:17033
0xb32306 lower_omp
../../gcc/omp-low.c:17177
0xb3200c lower_omp_1
../../gcc/omp-low.c:17025
0xb3200c lower_omp
../../gcc/omp-low.c:17177
0xb4246d lower_omp_for
../../gcc/omp-low.c:15133
0xb324d6 lower_omp_1
../../gcc/omp-low.c:17040
0xb324d6 lower_omp
../../gcc/omp-low.c:17177
0xb3200c lower_omp_1
../../gcc/omp-low.c:17025
0xb3200c lower_omp
../../gcc/omp-low.c:17177
0xb403aa lower_omp_taskreg
../../gcc/omp-low.c:15659
0xb32306 lower_omp_1
../../gcc/omp-low.c:17033
0xb32306 lower_omp
../../gcc/omp-low.c:17177
0xb3166c lower_omp_1
../../gcc/omp-low.c:17016
0xb3166c lower_omp
../../gcc/omp-low.c:17177
0xb3200c lower_omp_1
../../gcc/omp-low.c:17025
0xb3200c lower_omp
../../gcc/omp-low.c:17177
0xb391ef execute_lower_omp
../../gcc/omp-low.c:17912

[Bug fortran/78297] ICE in finish_equivalences, at fortran/trans-common.c:1246

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

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

--- Comment #1 from Gerhard Steinmetz  
---

Compiles with both items in common block.


$ cat z2.f90
module m
   real :: a(2), b(2)
   real :: c(2), d(2)
   equivalence (a, b)
   equivalence (c, d)
   common /xcom/ a, c
end
block data
   use m
end block data

[Bug fortran/78297] New: ICE in finish_equivalences, at fortran/trans-common.c:1246

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

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

Bug ID: 78297
   Summary: ICE in finish_equivalences, at
fortran/trans-common.c:1246
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Gives an ICE down to at least 4.8 :


$ cat z1.f90
module m
   real :: a(2), b(2)
   real :: c(2), d(2)
   equivalence (a, b)
   equivalence (c, d)
   common /xcom/ a
end
block data
   use m
end block data


$ gfortran-7-20161106 -c z1.f90
z1.f90:10:0:

 end block data

internal compiler error: Segmentation fault
0xc3a64f crash_signal
../../gcc/toplev.c:338
0x747490 finish_equivalences
../../gcc/fortran/trans-common.c:1246
0x747490 gfc_trans_common(gfc_namespace*)
../../gcc/fortran/trans-common.c:1289
0x74d1b0 gfc_generate_block_data(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6524
0x6e2133 gfc_parse_file()
../../gcc/fortran/parse.c:6102
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
> Did you regen fixincl.x (with ./genfixes in the source tree)?

I did a clean bootstrap, but I did know that I had to run ./genfixes. BTW you
probably mean ./fixincludes/genfixes, isn't it?

I am currently bootstrapping again with the patch in comment 15: machine busy
for the next 2 hours.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from Dominique d'Humieres  ---
[...]
> Bootstrap is still broken with the patch:
[...]
Did you regen fixincl.x (with ./genfixes in the source tree)?

A macOS 10.12 bootstrap is currently running: the fix for 
isn't complete.  I'd based it on an older version off
opensource.apple.com.  I'll post a fixed version once it's ready.

Rainer

[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
> Created attachment 40013 [details]
> proposed fixincludes-based patch
>
> The attached patch passes fixincludes make check.  I'll have to wait until
> tonight to test it for real on macOS 10.12, though.

Bootstrap is still broken with the patch:

libtool: compile:  /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/bin/
-B/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/lib/ -isystem
/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/include -isystem
/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../work/libsanitizer/sanitizer_common -I.. -I
../../../../work/libsanitizer/include -isystem
../../../../work/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin16.1.0
-I../../../../work/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-MT sanitizer_mac.lo -MD -MP -MF .deps/sanitizer_mac.Tpo -c
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc  -fno-common
-DPIC -o .libs/sanitizer_mac.o
In file included from
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:39:0:
/usr/include/os/trace.h:204:15: error: expected unqualified-id before '^' token
 typedef void (^os_trace_payload_t)(xpc_object_t xdict);
   ^
/usr/include/os/trace.h:204:15: error: expected ')' before '^' token
In file included from /usr/include/Availability.h:180:0,
 from /usr/include/stdio.h:65,
 from
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:21:
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
...
/usr/include/asl.h:1086:147: error: 'message' was not declared in this scope
 asl_object_t asl_match(asl_object_t data, asl_object_t querylist, size_t
*last, size_t start, size_t count, uint32_t duration, int32_t direction)
__API_DEPRECATED("os_log(3) has replaced asl(3)", macosx(10.10,10.12),
ios(8.0,10.0), watchos(2.0,3.0), tvos(9.0,10.0));
   
   ^
/usr/include/asl.h:1086:147: note: suggested alternative: 'rusage'
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc: In function
'void __sanitizer::LogFullErrorReport(const char*)':
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:53:
warning: suggest braces around empty body in an 'else' statement [-Wempty-bod]
   os_trace("Sanitizer tool reported a failure.");
 ^
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:55:
warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
   os_trace("Consult syslog for more information.");
   ^
make[4]: *** [sanitizer_mac.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libsanitizer] Error 2
make: *** [all] Error 2

[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
(also noticed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59650#c2)
We already seem to have special code for half-initialized complex numbers.

[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-10
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/72808] [6/7 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
The difference is that the CONST_DECL is added only to one RECORD_TYPE and not
to its variants in:
  if (context && context == current_class_type && !SCOPED_ENUM_P (enumtype))
{
  /* In something like `struct S { enum E { i = 7 }; };' we put `i'
 on the TYPE_FIELDS list for `S'.  (That's so that you can say
 things like `S::i' later.)  */

  /* The enumerator may be getting declared outside of its enclosing
 class, like so:

   class S { public: enum E : int; }; enum S::E : int { i = 7; };

 For which case we need to make sure that the access of `S::i'
 matches the access of `S::E'.  */
  tree saved_cas = current_access_specifier;
  if (TREE_PRIVATE (TYPE_NAME (enumtype)))
current_access_specifier = access_private_node;
  else if (TREE_PROTECTED (TYPE_NAME (enumtype)))
current_access_specifier = access_protected_node;
  else
current_access_specifier = access_public_node;

  finish_member_declaration (decl);

  current_access_specifier = saved_cas;
}

For dwarf2out purposes the extra CONST_DECL doesn't mean anything, because it
is ignored for non-fortran/ada.  So, either we change the type verifier to
ignore extra CONST_DECLs among TYPE_FIELDS, or if we have some way in the FE
how to figure out if fixup_type_variants has been already called or will be
still called, then we could for the case where it has been called already call
it again or just update TYPE_FIELDS manually on the variant types, or append to
TYPE_FIELDS rather than prepend if the type has been finalized already.

[Bug ipa/78296] New: [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78296
   Summary: [7 regression] test case gcc.dg/ipa/vrp7.c fails
starting with r242032
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/vrp7.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-ipa-cp-details
-S -o vrp7.s
PASS: gcc.dg/ipa/vrp7.c (test for excess errors)
FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0
\\[-10, 9\\]" 1

=== gcc Summary ===

# of expected passes1
# of unexpected failures1

[Bug fortran/78290] Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 Ever confirmed|0   |1

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

[Bug fortran/78293] [5/6/7 Regression] SIGABRT with function result used as argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 CC||mikael at gcc dot gnu.org
  Known to work||4.9.3
Summary|SIGABRT with function   |[5/6/7 Regression] SIGABRT
   |result used as argument |with function result used
   ||as argument
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from gcc5 up to trunk (7.0). This is caused by revision r225926
(pr61831) for gcc-6 and r232482 for gcc-5.

[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450

[foreese at gcc dot gnu.org]

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

foreese at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2016-11-09 00:00:00 |2016-11-10
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from foreese at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> Invalid code together with option -fdec, affects versions 6 and 7 :
> 
...
> $ gfortran-7-20161106 -fdec -c z1.f90
> z1.f90:11:19:
> 
>  structure t.
>1
> Error: Syntax error in data declaration at (1)
> z1.f90:14:9:
> 
>end structure
>  1
> Error: Expecting END SUBROUTINE statement at (1)
> f951: internal compiler error: Segmentation fault
> 0xc3a64f crash_signal
> ../../gcc/toplev.c:338
> 0x6952d0 is_anonymous_component
...

I'll have a patch soon.

For the curious reader:

The underlying cause is the fact that an anonymous structure declaration is
created at the line of error "structure t.", but the data declaration error
aborts the matcher and undoes the parse stack for the following structure
declaration which should become part of the anonymous definition. This doesn't
allow the matcher to finish the anonymous declaration. 

Due to the abort, the following components are added to the enclosing
"structure /s/", and the anonymous inner structure is never completed. The ICE
is specifically because the "zero_comp" attribute is never set, even though the
abort of the matcher causes no components to be assigned to the inner
structure.

The correct solution is not just to add null-guards to compare_components;
rather to fix the error handling around the bad anonymous inner structure
declaration. The anonymous inner structure should continue being parsed as
normal, while an error is still emitted about the bad variable-decl ("t.").

[Bug middle-end/78295] New: [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[jsm28 at gcc dot gnu.org]

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

Bug ID: 78295
   Summary: [7 Regression] Spurious -Wuninitialized warning for
vector element assignment
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

On x86_64-linux-gnu, with -O2 -Wall, the code

typedef double vectype __attribute__ ((__vector_size__ (16)));

vectype
f (double x)
{
  vectype t;
  for (int i = 0; i < 2; i++)
t[i] = x;
  return t;
}

produces a spurious warning

t.c: In function 'f':
t.c:8:10: warning: 't' is used uninitialized in this function [-Wuninitialized]
 t[i] = x;
 ~^~~

which does not appear with GCC 6.  Even if storing to a vector element is
represented internally as loading the whole vector then modifying it, this
should not result in a warning, as *logically* the assignment does not use an
uninitialized value.

This results in errors building the glibc testsuite for x86_64, as it has code
like the above to initialize vectors.

[Bug sanitizer/78294] New: -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

Bug ID: 78294
   Summary: -fsanitize=thread broken
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

markus@x4 ~ % echo "int main(){}" | g++ -fsanitize=thread -x c++ - && ./a.out
[1]4123 segmentation fault  ./a.out


Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x76f4312d in __interceptor___tls_get_addr (arg=0x76ff7f68) at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:2421
#2  0x76f8b00a in
__tsan::ScopedIgnoreInterceptors::ScopedIgnoreInterceptors (this=) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.h:549
#3  __tsan::Initialize (thr=thr@entry=0x76277780) at
../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:331
#4  0x76f43b90 in __tsan::ScopedInterceptor::ScopedInterceptor
(this=this@entry=0x7fffe490, thr=0x76277780, pc=140737353072294,
fname=0x76fc5eea "__cxa_atexit") at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:256
#5  0x76f44e67 in __interceptor___cxa_atexit (f=f@entry=0x77efd480
,
arg=arg@entry=0x77ff2410 , dso=0x77ff2280) at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:399
#6  0x77efbea6 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
../../../../gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:214
#7  _GLOBAL__sub_I_compatibility_c__0x.cc(void) () at
../../../../gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:257
#8  0x77de73a3 in call_init (env=0x7fffe568, argv=0x7fffe558,
argc=1, l=) at dl-init.c:72
#9  _dl_init (main_map=0x77ffe130, argc=1, argv=0x7fffe558,
env=0x7fffe568) at dl-init.c:120
#10 0x77dd6c5a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0001 in ?? ()
#12 0x7fffe88a in ?? ()
#13 0x in ?? ()

Using the static version libtsan.a works fine.

markus@x4 ~ % uname -snrvmio
Linux x4 4.9.0-rc3-00450-gffbcbfca846e-dirty #79 SMP Sat Nov 5 20:22:52 CET
2016 x86_64 AuthenticAMD GNU/Linux

markus@x4 ~ % /lib64/libc-2.24.90.so
GNU C Library (GNU libc) development release version 2.24.90, by Roland McGrath
et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.0.0 20161031 (experimental).
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
.

[Bug fortran/78293] New: SIGABRT with function result used as argument

[abensonca at gmail dot com]

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

Bug ID: 78293
   Summary: SIGABRT with function result used as argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code dies with a SIGABRT at run time in gfortran 7.0.0 
(r241975), and also in gfortran 6.2.1. As far as I can see it's valid code, 
but I wanted to get a second opinion on that before opening a PR.

-Andrew

--
module m
  implicit none

  type t
 integer, allocatable, dimension(:) :: r
  end type t

contains

  function tt(a,b)
implicit none
type(t), allocatable, dimension(:) :: tt
type(t), intent(in), dimension(:) :: a,b
allocate(tt(2))
allocate(tt(1)%r(1))
allocate(tt(2)%r(1))
return
  end function tt

  function ts()
implicit none
type(t), allocatable, dimension(:) :: ts
allocate(ts(1))
allocate(ts(1)%r(1))
return
  end function ts

end module m

program p
  use m
  implicit none
  type(t), dimension(2) :: c
  c=tt(ts(),ts())
end program p


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

$ gfortran t.F90
$ a.out
*** Error in `a.out': free(): invalid pointer: 0x02189f50 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7570b)[0x2aceab27c70b]
/lib64/libc.so.6(+0x7deaa)[0x2aceab284eaa]
/lib64/libc.so.6(cfree+0x4c)[0x2aceab28840c]
a.out[0x4016ab]
a.out[0x40171c]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x2aceab227731]
a.out[0x4007b9]
=== Memory map: 
0040-00402000 r-xp  fd:03 9574876/
home/abenson/Galacticus/v0.9.4/a.out
00601000-00602000 r--p 1000 fd:03 9574876/
home/abenson/Galacticus/v0.9.4/a.out
00602000-00603000 rw-p 2000 fd:03 9574876/
home/abenson/Galacticus/v0.9.4/a.out
02187000-021a8000 rw-p  00:00 0  
[heap]
2aceaa55-2aceaa574000 r-xp  fd:01 400265 /usr/
lib64/ld-2.23.so
2aceaa574000-2aceaa576000 rw-p  00:00 0 
2aceaa5c-2aceaa5c4000 rw-p  00:00 0 
2aceaa773000-2aceaa774000 r--p 00023000 fd:01 400265 /usr/
lib64/ld-2.23.so
2aceaa774000-2aceaa775000 rw-p 00024000 fd:01 400265 /usr/
lib64/ld-2.23.so
2aceaa775000-2aceaa776000 rw-p  00:00 0 
2aceaa776000-2aceaa8a4000 r-xp  fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2aceaa8a4000-2ace4000 ---p 0012e000 fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2ace4000-2ace5000 r--p 0012e000 fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2ace5000-2ace6000 rw-p 0012f000 fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2ace6000-2ace7000 rw-p  00:00 0 
2ace7000-2aceaabaf000 r-xp  fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaabaf000-2aceaadae000 ---p 00108000 fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaadae000-2aceaadaf000 r--p 00107000 fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaadaf000-2aceaadb rw-p 00108000 fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaadb-2aceaadc6000 r-xp  fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaadc6000-2aceaafc5000 ---p 00016000 fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaafc5000-2aceaafc6000 r--p 00015000 fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaafc6000-2aceaafc7000 rw-p 00016000 fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaafc7000-2aceab006000 r-xp  fd:01 409963 /usr/
lib64/libquadmath.so.0.0.0
2aceab006000-2aceab205000 ---p 0003f000 fd:01 409963 /usr/
lib64/libquadmath.so.0.0.0
2aceab205000-2aceab206000 r--p 0003e000 fd:01 409963 /usr/
lib64/libquadmath.so.0.0.0

[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Sorry for that.  Yes, GCC still requires vect_max_reduc to vectorize the loop,
I will amend the test case.

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Here is the reason failing with haswell.
The loop is vectorized by vf=4, but iteration distance for all possible
predictive commoning chains are at most 2 (by iterations), so after vf=4
vectorization, there is no predictive commoning opportunities.

[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967

[seurer at linux dot vnet.ibm.com]

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

--- Comment #1 from Bill Seurer  ---

r241967 | amker | 2016-11-08 08:08:06 -0600 (Tue, 08 Nov 2016) | 3 lines

gcc/testsuite
* gcc.dg/vect/vect-cond-2.c: Drop xfail.

[Bug testsuite/78292] New: [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78292
   Summary: [7 regression] test case gcc.dg/vect/vect-cond-2.c
fails starting with r241967
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

These still are expected to fail, at least on powerpc.

spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mpower8-vector
-ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details
-lm -o ./vect-cond-2.exe
PASS: gcc.dg/vect/vect-cond-2.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-trunk/gcc::/home/seurer/gcc/build/gcc-trunk/gcc:/home/wschmidt/gcc/install/gcc-6.2.0/lib64
spawn [open ...]
PASS: gcc.dg/vect/vect-cond-2.c execution test
FAIL: gcc.dg/vect/vect-cond-2.c scan-tree-dump-times vect "vectorized 1 loops"
1
Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -flto -ffat-lto-objects
-maltivec -mpower8-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details  -lm-o ./vect-cond-2.exe(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects
-maltivec -mpower8-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -lm -o ./vect-cond-2.exe
PASS: gcc.dg/vect/vect-cond-2.c -flto -ffat-lto-objects (test for excess
errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-trunk/gcc::/home/seurer/gcc/build/gcc-trunk/gcc:/home/wschmidt/gcc/install/gcc-6.2.0/lib64
spawn [open ...]
PASS: gcc.dg/vect/vect-cond-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-cond-2.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1
testcase /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect.exp
completed in 1 seconds

=== gcc Summary ===

# of expected passes4
# of unexpected failures2

[Bug tree-optimization/77309] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code
   |code at -Os and above on|at -Os and above on
   |x86_64-linux-gnu (in the|x86_64-linux-gnu (in the
   |64-bit mode)|64-bit mode)

--- Comment #4 from Jakub Jelinek  ---
Assuming this is fixed now on the trunk.

[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is rejected starting with r239268, P0170R1 implementation.  clang++
doesn't seem to implement that part of C++17 from what I can see.  Whether the
test is valid C++17 or not I'll defer to others.

[Bug tree-optimization/77856] [7 Regression] wrong code at -O2 on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
To me this looks like a LRA bug.  In *.ira we have:
(insn 210 18 20 3 (set (reg:SI 225 [ c.f1 ])
(const_int 1 [0x1])) "pr77856.c":24 82 {*movsi_internal}
 (expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
...
(insn 23 21 25 3 (parallel [
(set (reg:SI 119 [ _45 ])
(ashiftrt:SI (reg:SI 225 [ c.f1 ])
(subreg:QI (reg:SI 117 [ _42 ]) 0)))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 563 {*ashrsi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashiftrt:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil
(insn 25 23 3 3 (parallel [
(set (reg:SI 120 [ _46 ])
(ashift:SI (reg:SI 225 [ c.f1 ])
(subreg:QI (reg:SI 117 [ _42 ]) 0)))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 529 {*ashlsi3_1}
 (expr_list:REG_DEAD (reg:SI 225 [ c.f1 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil)

(insn 3 25 4 3 (set (reg:SI 152 [ _81 ])
(const_int 1 [0x1])) "pr77856.c":24 82 {*movsi_internal}
 (expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
...
(insn 280 81 123 3 (set (reg:SI 240 [orig:152 _81 ] [152])
(reg:SI 152 [ _81 ])) "pr77856.c":32 82 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 152 [ _81 ])
(nil)))
and in *.reload we have:
(insn 210 337 336 3 (set (reg:SI 0 ax [orig:225 c.f1 ] [225])
(const_int 1 [0x1])) "pr77856.c":24 82 {*movsi_internal}
 (expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
...
(insn 23 287 286 3 (parallel [
(set (reg:SI 5 di [orig:119 _45 ] [119])
(ashiftrt:SI (reg:SI 5 di [orig:119 _45 ] [119])
(reg:QI 2 cx [243])))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 563 {*ashrsi3_1}
 (expr_list:REG_EQUAL (ashiftrt:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil)))
(insn 286 23 290 3 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])) [5 %sfp+-1004 S4 A32])
(reg:SI 5 di [orig:119 _45 ] [119])) "pr77856.c":15 82
{*movsi_internal}
 (nil))
(insn 290 286 25 3 (set (reg:QI 2 cx [245])
(reg:QI 3 bx [orig:117 _42 ] [117])) "pr77856.c":15 85
{*movqi_internal}
 (nil))
(insn 25 290 289 3 (parallel [
(set (reg:SI 0 ax [orig:225 c.f1 ] [225])
(ashift:SI (reg:SI 0 ax [orig:225 c.f1 ] [225])
(reg:QI 2 cx [245])))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 529 {*ashlsi3_1}
 (expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil)))
(insn 289 25 3 3 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 24 [0x18])) [5 %sfp+-1000 S4 A32])
(reg:SI 0 ax [orig:225 c.f1 ] [225])) "pr77856.c":15 82
{*movsi_internal}
 (nil))
(note 3 289 333 3 NOTE_INSN_DELETED)
...
(insn 280 81 123 3 (set (reg:SI 3 bx [orig:152 _81 ] [152])
(reg:SI 0 ax [orig:152 _81 ] [152])) "pr77856.c":32 82
{*movsi_internal}
 (nil))

So, %ebx doesn't hold 1 as it is supposed to, but 1 << %ecx (64).
Vlad, could you please have a look?

[Bug c++/78291] New: overload resolution prefers non-member operator to member operator when should be ambiguous

[barry.revzin at gmail dot com]

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

Bug ID: 78291
   Summary: overload resolution prefers non-member operator to
member operator when should be ambiguous
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This example:

struct A {
template 
void operator==(T const& ) const;

template 
friend void operator==(T const&, A const& ) { }
};

int main() {
A{} == A{};
}

compiles and runs (tried 4.8.2, 5.4, 6.2, and 7.0). gcc picks the non-member
overload here. But both overloads are equally viable, so this should be
ambiguous.

[Bug fortran/78290] New: Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument

[andybugreports at gmail dot com]

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

Bug ID: 78290
   Summary: Gfortran incorrectly creates a copy of an array passed
to an array pointer dummy argument
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andybugreports at gmail dot com
  Target Milestone: ---

The following code demonstrates incorrect behaviour of a array pointer being
passed to an array pointer dummy argument. As highlighted in the comment, the
compiler seems to generate a copy of the array rather than passing a pointer to
it. "sub1" seems to be doing the right thing, but due to the copy and what
looks like incorrect behaviour to attempt to copy some of it back the result is
wrong. Removing the line shown later in the source stops the copy occurring and
fixes the problem. Bug 53800 looks potentially similar:

PROGRAM main
  IMPLICIT NONE 
  INTEGER,PARAMETER::KI=4,KF=8,KL=4

  TYPE mytype
INTEGER(KIND=KI)::i=1_KI
REAL(KIND=KF)::r=2.0_KF
LOGICAL(KIND=KL)::z=.TRUE._KL
  END TYPE mytype

  TYPE(mytype),DIMENSION(50),SAVE,TARGET::ta

  INTEGER(KIND=KI),DIMENSION(3),SAVE,TARGET::ia=1_KI
  INTEGER(KIND=KI),DIMENSION(:),POINTER::ia2=>NULL()
  INTEGER(KIND=KI),DIMENSION(:),POINTER,SAVE::ipsave=>NULL()
  INTEGER(KIND=KI),DIMENSION(:),POINTER::ip=>NULL()

  ALLOCATE(ia2(5)); ia2=2_KI

  ip=>ia; NULLIFY(ipsave)
  CALL sub1(ip)
  WRITE(*,*)'ia',ia
  WRITE(*,*)'ip',ip
  WRITE(*,*)'ipsave',ipsave

  ip=>ta%i !!! Works if you comment this line out !!!

! At writes: isave should point to ia which should be changed to all 3s
! ip should point to ip2
! Produces:
! ia   2   2   2
! ip   2   2   2
! ipsave   3   3   3
!
! Should produce:
! ia   3   3   3
! ip   2   2   2   2   2
! ipsave   3   3   3
!
! Seems to be creating a copy of ia and setting argument ipa as a pointer this,
and 
! changes to this never get transferred back to ia
! Also does not transfer back change of target or INOUT argugment
! Works if you comment out the line "ip=>ta%i" 
!
CONTAINS

   SUBROUTINE sub1(ipa)
 INTEGER(KIND=KI),DIMENSION(:),POINTER,INTENT(INOUT)::ipa ! Fortran 2003
 ! INTEGER(KIND=KI),DIMENSION(:),POINTER::ipa ! Fortan 95
 ipsave=>ipa 
 ipsave=3_KI
 ipa=>ia2
   END SUBROUTINE sub1

END PROGRAM main

[Bug target/77761] [7 Regression] wrong code with -fschedule-insns -mavx512f --param=max-pending-list-length=512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-10
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r238991.

[Bug fortran/77703] [6/7 Regression] ICE on assignment to pointer function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[yroux at gcc dot gnu.org]

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

--- Comment #5 from Yvan Roux  ---
Ok, I'll validate the fix.

[Bug libgomp/78289] OpenMP produces high CPU load if used in more than one process

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
It is user's/programmer's responsibility to prevent oversubscribing the CPU. 
You can use OMP_NUM_THREADS=nn in environment, num_threads clause on parallel
region, or if you really want to oversubscribe the CPU, you can tune whether
the library will do busy waiting or not and how much (OMP_WAIT_POLICY=active,
OMP_WAIT_POLICY=passive, GOMP_SPINCOUNT=, affinity, ..., omp_* APIs that allow
to fine tune the earlier mentioned env var settings, etc.

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

Untested fix.

The primary bug here is in the FEs/gimplifier, they shouldn't create a
TREE_STATIC artificial var with variable length size.  I believe we have PRs
for that though, and I think it is desirable to do the right thing even in this
target hook though.  There is no need to test decl != NULL again, this is all
in a block guarded with if (decl && DECL_P (decl)).  Furthermore, I think we
shouldn't put the odd-sized stuff into section anchors.  And, while
max_anchor_offset is HOST_WIDE_INT, the other uses cast those to unsigned
HOST_WIDE_INT anyway.  Plus using DECL_SIZE and comparing against
max_anchor_offset * BITS_PER_UNIT is too ugly, we already have DECL_SIZE_UNIT
in bytes.

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
But for tests:
FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times pcom
"Executing predictive commoning without unrolling" 1
FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times pcom
"Predictive commoning failed: no suitable chains" 0

they happened before 20161011.  I tried revision at:
commit ab93a7014158ec67a0b34e2986742da8a55013f9
Author: sje 
Date:   Wed Oct 5 18:42:10 2016 +

2016-10-05  Steve Ellcey  

* MAINTAINERS: Update email address after it got reverted.


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

And it's not working either?

[Bug libgomp/78289] New: OpenMP produces high CPU load if used in more than one process

[s.schuel...@ids-imaging.de]

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

Bug ID: 78289
   Summary: OpenMP produces high CPU load if used in more than one
process
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s.schuel...@ids-imaging.de
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40014=edit
gcc -O2 omp.c -lpthread -fopenmp -o omp

We discovered that our application performs very bad on Linux when two or more
processes are started which use OpenMP.
I've removed line by line from the source to find the bottleneck until there
were no more lines to remove.

I attached a simple program that exposes the problem.
In the first step eight Threads are created which run a empty openmp for loop
1 times. After that eigth Processes are created using fork() each running
the same loop 1.

The Thread based version takes about 1 second and the fork() version 3 minutes
30 seconds on a i7 4790

Problem could be reproduced on ubuntu 12.04, 16.04

compile attachment:
gcc -O2 omp.c -lpthread -fopenmp -o omp

[Bug tree-optimization/78257] missing memcmp optimization with constant arrays

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Martin Sebor from comment #4)
> Created attachment 40008 [details]
> Very lightly tested patch.
> 
> The attached (only superficially tested) patch changes fold_bultin_memcmp to
> fold the comparison over the length of the arrays rather than just the first
> pair of bytes.  Does it look reasonable?

I played a bit with the patch and it's nice that it can handle(In reply to
Martin Sebor from comment #4)
> Created attachment 40008 [details]
> Very lightly tested patch.
> 
> The attached (only superficially tested) patch changes fold_bultin_memcmp to
> fold the comparison over the length of the arrays rather than just the first
> pair of bytes.  Does it look reasonable?

I played a bit with the patch and it ICEs with:

#include 
#include 

const int i[] = { 16843009 };
const char k[] = {1, 1, 1, 1};

int main()
{
  unsigned test = sizeof(i) * 1;
  assert (__builtin_memcmp (i, k, test) == 0);
  return 0;
}

and without an optimization level, it can produce tons of assembly code:
#include 
#include 

#define ctor(N) {N, N, N, N, N, N, N, N, N, N, N, N}

const int i[] = ctor(123456);
const int k[] = ctor(123456);

int main()
{
  assert (__builtin_memcmp (i, k, sizeof i) == 0);
  return 0;
}

folding2.c.004t.gimple:
   
i.1_1 = 
_2 = MEM[(const unsigned char * {ref-all})i.1_1];
k.2_3 = 
_4 = MEM[(const unsigned char * {ref-all})k.2_3];
if (_2 == _4) goto ; else goto ;
:
_5 =  + 1;
_6 = *_5;
_7 =  + 1;
_8 = *_7;
if (_6 == _8) goto ; else goto ;
:
_9 =  + 2;
_10 = *_9;
_11 =  + 2;
_12 = *_11;
if (_10 == _12) goto ; else goto ;
:
_13 =  + 3;
_14 = *_13;
_15 =  + 3;
_16 = *_15;
if (_14 == _16) goto ; else goto ;
:
_17 =  + 4;
_18 = *_17;
_19 =  + 4;
_20 = *_19;

Martin

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[ro at gcc dot gnu.org]

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

--- Comment #17 from Rainer Orth  ---
Created attachment 40013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40013=edit
proposed fixincludes-based patch

The attached patch passes fixincludes make check.  I'll have to wait until
tonight
to test it for real on macOS 10.12, though.

  Rainer

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
It's because the loop is vectorized by vf=2 with -mavx2, while by vf=4 with
-march=haswell.  In that case the peeled prolog iterates more than 1 times,
resulting in test failure.

[Bug middle-end/78103] Failure to optimize with __builtin_clzl

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
With trunk on arm-linux-gnueabihf, nearly identical code is generated for
findLastSet and findLastSet2.

findLastSet:
cmp r0, #0
clzne   r0, r0
rsbne   r0, r0, #32
bx  lr

findLastSet2:
cmp r0, #0
clzne   r0, r0
eorne   r0, r0, #31
addne   r0, r0, #1
bx  lr

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Preapproved.  If/once Rainer will have a fixincludes patch, this can be
reverted.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[m.ostapenko at samsung dot com]

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

--- Comment #15 from Maxim Ostapenko  ---
Created attachment 40012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40012=edit
Untested fix 2.

Ok, thanks.

I'm attaching a second short-term fix for now.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Thanks for the references and explanation.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog

--- Comment #2 from Richard Biener  ---
The var-tracking data-flow problem is basically (at least) quadratic in size. 
We do lots of stuff to mitigate that but that itself takes time...