[Bug c/67610] strcpy BUG

[soekchl at 163 dot com]

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

--- Comment #4 from Luke  ---
Thank you!

[Bug c/67611] strcpy BUG

[soekchl at 163 dot com]

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

--- Comment #3 from Luke  ---
Thank you!

[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)

[y.gribov at samsung dot com]

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

--- Comment #7 from Yury Gribov  ---
FYI I'd prefer to keep current BIT_IOR_EXPR approach in asan_expand_check_ifn
as it allows for efficient implementation for ARM targets (as compared to two
successive branches currently used in LLVM).

[Bug c/67610] strcpy BUG

[soekchl at 163 dot com]

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

--- Comment #5 from Luke  ---
I'm so sorry, I did not read the instructions properly, giving you trouble.

[Bug middle-end/67401] Incorrect expand of __atomic_compare_exchange_8 using __sync_val_compare_and_swap_8

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Fixed.

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[manu at gcc dot gnu.org]

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

--- Comment #28 from Manuel López-Ibáñez  ---
(In reply to baoshan from comment #27)
> > It seems GCC at some moment unrolls the loop and creates such block with
> > those ranges. Probably, the block is unreachable, but it would be better to
> > not create it in the first place. Finding out where and why it is created
> > would help to figure out a fix.
> 
> 
> At pass "cunrolli", it would unroll the loops according the estimated
> iterate times. The problem is at this time it use array
> ref(infer_loop_bounds_from_ref) to infer the iterate times which is not
> accurate. The inaccurate iterate times result the extra blocks.

The question is why is it inaccurate? Note that cunrolli says:


Statement _14 = baz[_9];
 is executed at most 5 (bounded by 5) + 1 times in loop 2.
Loop 2 iterates at most 6 times.
Analyzing # of iterations of loop 2
  exit condition [i_2 + 4294967295, + , 4294967295] != 0
  bounds on difference of bases: -4294967295 ... 0
Applying pattern match.pd:71, generic-match.c:9500
  result:
# of iterations i_2 + 4294967295, bounded by 4294967295
Estimating sizes for loop 2
 BB: 7, after_exit: 0
  size:   2 if (j_3 != 0)
   Exit condition will be eliminated in last copy.
 BB: 6, after_exit: 1
  size:   1 _9 = j_3 + 4294967295;
  size:   0 _10 = (long unsigned int) _9;
Applying pattern match.pd:71, generic-match.c:9500
Applying pattern match.pd:136, generic-match.c:6019
  size:   1 _11 = _10 * 4;
Applying pattern match.pd:71, generic-match.c:9500
Applying pattern match.pd:136, generic-match.c:6019
  size:   1 _13 = bar_12(D) + _11;
  size:   1 _14 = baz[_9];
  size:   1 *_13 = _14;
size: 7-0, last_iteration: 2-2
  Loop size: 7
  Estimated size after unrolling: 28
pr59124.c:8:5: note: loop turned into non-loop; it never loops.
pr59124.c:8:5: note: loop with 7 iterations completely unrolled
Last iteration exit edge was proved true.
Forced statement unreachable: _14 = baz[_9];


However, it is clear that _14 = baz[_9] is executed only 5 times (not 5 times +
1). Why is this estimate wrong?

[Bug other/67634] New: Can't preserve bound register in interrupt handler

[hjl.tools at gmail dot com]

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

Bug ID: 67634
   Summary: Can't preserve bound register in interrupt handler
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com
Blocks: 67552
  Target Milestone: ---

[hjl@gnu-6 interrupt-6]$ cat bnd.i 
void
__attribute__((interrupt))
fn1 (void)
{
  asm ("#"
   :
   : 
   : "bnd0");
}
[hjl@gnu-6 interrupt-6]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mmpx -g -S -o bnd.s bnd.i
bnd.i: In function ‘fn1’:
bnd.i:9:1: error: insn does not satisfy its constraints:
 }
 ^
(insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
(reg:DI 77 bnd0)) bnd.i:4 61 {*pushdi2_rex64}
 (expr_list:REG_DEAD (reg:DI 77 bnd0)
(nil)))
bnd.i:9:1: internal compiler error: in extract_constrain_insn, at recog.c:2200
0xcf01e5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/gnu/import/git/sources/gcc/gcc/rtl-error.c:109
0xcf0245 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/export/gnu/import/git/sources/gcc/gcc/rtl-error.c:120
0xca21a2 extract_constrain_insn(rtx_insn*)
/export/gnu/import/git/sources/gcc/gcc/recog.c:2200
0xcb080f copyprop_hardreg_forward_1
/export/gnu/import/git/sources/gcc/gcc/regcprop.c:778
0xcb2040 execute
/export/gnu/import/git/sources/gcc/gcc/regcprop.c:1268
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:27: recipe for target 'bnd.s' failed
make: *** [bnd.s] Error 1
[hjl@gnu-6 interrupt-6]$ 

We can't use push to save bound registers.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
[Bug 67552] [meta] x86 interrupt attribute

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez  ---
(In reply to Paul Eggert from comment #10)
> In tzcode the problem can be worked around by using a #define rather than a
> static constant, but many C programmers nowadays prefer avoiding #define

__attribute__((unused)) should silence the warning when inappropriate.

Another alternative is to only warn if the variable is defined in the main file
(MAIN_FILE_P) as opposed to an included file.

> It'd be fine to add an option to enable the new warning, but please don't
> enable them merely because -Wall or -Wunused-variable is specified.

The problem with not adding options to at least -Wall or -Wextra is that they
will be almost never used, even if they are only noisy for a small percentage
of cases, which just may need a bit of fine-tuning or accepting some false
negatives to avoid some false positives. 

We have a lot of options that are not in Wall or Wextra just because they were
noisy in some particular cases, and it was easier to move them out of the way
than to fix them. Since they are not used, there is small motivation to ever
fix them.

[Bug middle-end/67401] Incorrect expand of __atomic_compare_exchange_8 using __sync_val_compare_and_swap_8

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Fri Sep 18 18:26:13 2015
New Revision: 227914

URL: https://gcc.gnu.org/viewcvs?rev=227914=gcc=rev
Log:
PR middle-end/67401
* optabs.c (expand_atomic_compare_and_swap): Move result of emitting
sync_compare_and_swap_optab libcall to target_oval.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/optabs.c

[Bug libffi/65441] FAIL: libffi.call/float2.c -W -Wall -Wno-psabi (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Created attachment 36348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36348=edit
Proposed patch

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
I think this should be backported to GCC 5.  Even if it might not be triggered
often, there is a possibility for silent wrong-code bugs.

[Bug libstdc++/67620] New: _GLIBCXX_USE_CXX11_ABI=1 fails to catch ios_base::failure

[cctsai57 at gmail dot com]

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

Bug ID: 67620
   Summary: _GLIBCXX_USE_CXX11_ABI=1 fails to catch
ios_base::failure
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cctsai57 at gmail dot com
  Target Milestone: ---

#include 
#include 
#include 
using namespace std;

int main()
{
ifstream f;
f.exceptions(ifstream::failbit);

try {
  f.open("file_does_not_exit");// throw ios_base::failure
}
catch (const ios_base::failure )
{
// g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=0
cout << "typeid(iof) : " << typeid(iof).name() << '\n';
}
catch (const exception )
{
// g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=1. Bug? Why?
cout << "typeid(ex)  : " << typeid(ex).name() << '\n';
}
}

$ g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=0 a.cpp -static && ./a.out
typeid(iof) : NSt8ios_base7failureE
$ g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=1 a.cpp -static && ./a.out
typeid(ex)  : NSt8ios_base7failureE

Description:
Let `f.open()' throw `ios_base::failure'.  If compiled with
-D_GLIBCXX_USE_CXX11_ABI=1, the above code fails to catch `ios_base::failure',
but `exception' insead.

gcc version:
gcc version 5.2.1 20150917 (GCC)
gcc version 6.0.0 20150917 (experimental) (GCC)

[Bug bootstrap/67622] New: [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch

[ro at gcc dot gnu.org]

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

Bug ID: 67622
   Summary: [6 regression] Solaris/SPARC bootstrap fails compiling
stage2 stdc++.h.gch/O2ggnu++0x.gch
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: davem at gcc dot gnu.org, ebotcazou at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
 Build: sparc-sun-solaris2.*

Between 20150911 and 20150917 (r227886), Solaris/SPARC bootstrap started to
fail
in stage2:

$ /var/gcc/regression/trunk/11-gcc/build/./gcc/xgcc -shared-libgcc
-B/var/gcc/regression/trunk/11-gcc/build/./gcc -nostdinc++
-L/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs
-L/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include-x c++-header -nostdinc++ -g -O2 
-I/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11
-I/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include
-I/vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/vol/gcc/src/hg/trunk/local/libstdc++-v3/include/precompiled/stdc++.h -o
sparc-sun-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/char_traits.h:39:0,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/ios:40,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/istream:38,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/sstream:38,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/complex:45,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/ccomplex:38,
 from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/include/precompiled/stdc++.h:52:
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/stl_algobase.h:898:68:
error: template definition of non-template 'static bool
std::__lexicographical_compare<_BoolType>::__lc(_II1, _II1, _II2, _II2)'
   __lc(_II1 __first1, _II1 __last1, _II2 __first2, _II2 __last2)
^
In file included from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/ios:40:0,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/istream:38,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/sstream:38,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/complex:45,
 from
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/ccomplex:38,
 from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/include/precompiled/stdc++.h:52:
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/char_traits.h:145:74:
error: template definition of non-template 'static int
__gnu_cxx::char_traits<_CharT>::compare(const char_type*, const char_type*,
std::size_t)'
 compare(const char_type* __s1, const char_type* __s2, std::size_t __n)
  ^
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/char_traits.h:158:32:
error: template definition of non-template 'static std::size_t
__gnu_cxx::char_traits<_CharT>::length(const char_type*)'
 length(const char_type* __p)
^
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/char_traits.h:169:69:
error: template definition of non-template 'static const char_type*
__gnu_cxx::char_traits<_CharT>::find(const char_type*, std::size_t, const
char_type&)'
 find(const char_type* __s, std::size_t __n, const char_type& __a)
 ^
/var/gcc/regression/trunk/11-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/char_traits.h:180:65:
error: template definition of non-template 'static
__gnu_cxx::char_traits<_CharT>::char_type*

[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
(In reply to Yury Gribov from comment #7)
> FYI I'd prefer to keep current BIT_IOR_EXPR approach in
> asan_expand_check_ifn as it allows for efficient implementation for ARM
> targets (as compared to two successive branches currently used in LLVM).

Aha.  Then I don't know if we want to change this.  Please someone decide ;).

[Bug target/67619] New: ICE at -O1 and above on x86_64-linux-gnu in int_mode_for_mode, at stor-layout.c:425

[su at cs dot ucdavis.edu]

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

Bug ID: 67619
   Summary: ICE at -O1 and above on x86_64-linux-gnu in
int_mode_for_mode, at stor-layout.c:425
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It also affects 4.6.x through 5.2.x: 
(1) hang: 4.6.x and 4.7.x 
(2) ICE: 4.8.x to 5.2.x 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150917 (experimental) [trunk revision 227862] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$ 
$ gcc-trunk -O1 -c small.c
small.c: In function ‘foo’:
small.c:9:3: internal compiler error: in int_mode_for_mode, at
stor-layout.c:425
   __builtin_eh_return (l, p);
   ^
0xa9f22b int_mode_for_mode(machine_mode)
../../gcc-trunk/gcc/stor-layout.c:425
0x7ec67e emit_move_via_integer
../../gcc-trunk/gcc/expr.c:3143
0x7f8d9a emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expr.c:3524
0x7f90d4 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expr.c:3592
0x7dcae2 copy_to_reg(rtx_def*)
../../gcc-trunk/gcc/explow.c:578
0x7d558f expand_builtin_eh_return(tree_node*, tree_node*)
../../gcc-trunk/gcc/except.c:
0x6d48f4 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc-trunk/gcc/builtins.c:6450
0x7f46d2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-trunk/gcc/expr.c:10473
0x6f54a3 expand_expr
../../gcc-trunk/gcc/expr.h:255
0x6f54a3 expand_call_stmt
../../gcc-trunk/gcc/cfgexpand.c:2647
0x6f54a3 expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3534
0x6f54a3 expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3697
0x6f6b9a expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5700
0x6fda46 execute
../../gcc-trunk/gcc/cfgexpand.c:6286
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





void
foo ()
{
  unsigned long l;
  void *p = 0; 

  __builtin_unwind_init ();
  l = 0; 
  __builtin_eh_return (l, p);
}

[Bug c++/67621] New: Syntax error for template function of template class

[physik3 at gmx dot net]

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

Bug ID: 67621
   Summary: Syntax error for template function of template class
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physik3 at gmx dot net
  Target Milestone: ---

Hey guys,

I think I have found a bug in the GCC C++ frontend.

I have a template class which provides a function with additional template
parameters. This works fine if the class is parameterized with a non-template
type or a template type whose arguments are fixed, but the compiler throws a
syntax error if the class is parameterized with a template class itself whose
argument is open.

I could downsize the problem to the following minimal example:

template
struct Foo {

template void foo(void) {}

};

template
struct Bar {

};

int main(void) {
Foo foo1;
foo1.foo(); // this line works
Foo foo2;
foo2.foo(); // this line works
return 0;
}

template
void baz(void) {
Foo foo;
foo.foo(); // this line gives a compiler error
}


GCC quits with "error: expected ‘;’ before ‘int’". Because I cannot see any
syntactical error, I guess it is a bug in GCC. Moreover, the Visual Studio
compiler accepts this code.

I detected this working with version 4.8.3, but I verified that it also affects
the newer 5.2.1 release.

Best

[Bug tree-optimization/67612] Unable to vectorize DOT_PROD_EXPR (PMADDWD?)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-18
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think DOT_PROD_EXRP is only supported as reduction operation right now.  It
would need to be supported in vectorizable_conversion.  Disabling DOT_PROD
pattern detection makes the loop vectorized (but with awkward code...).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug rtl-optimization/67619] ICE at -O1 and above on x86_64-linux-gnu in int_mode_for_mode, at stor-layout.c:425

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-18
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Patch in testing:

--cut here--
Index: except.c
===
--- except.c(revision 227896)
+++ except.c(working copy)
@@ -2219,7 +2219,7 @@ expand_builtin_eh_return (tree stackadj_tree ATTRI
 VOIDmode, EXPAND_NORMAL);
   tmp = convert_memory_address (Pmode, tmp);
   if (!crtl->eh.ehr_stackadj)
-crtl->eh.ehr_stackadj = copy_to_reg (tmp);
+crtl->eh.ehr_stackadj = copy_addr_to_reg (tmp);
   else if (tmp != crtl->eh.ehr_stackadj)
 emit_move_insn (crtl->eh.ehr_stackadj, tmp);
 #endif
@@ -2228,7 +2228,7 @@ expand_builtin_eh_return (tree stackadj_tree ATTRI
 VOIDmode, EXPAND_NORMAL);
   tmp = convert_memory_address (Pmode, tmp);
   if (!crtl->eh.ehr_handler)
-crtl->eh.ehr_handler = copy_to_reg (tmp);
+crtl->eh.ehr_handler = copy_addr_to_reg (tmp);
   else if (tmp != crtl->eh.ehr_handler)
 emit_move_insn (crtl->eh.ehr_handler, tmp);

--cut here--

[Bug c++/67621] Syntax error for template function of template class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to physik3 from comment #0)
>   foo.foo(); // this line gives a compiler error

This needs to be:

foo.template foo();

See https://womble.decadent.org.uk/c++/template-faq.html#disambiguation

[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||cctsai57 at gmail dot com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 67620 has been marked as a duplicate of this bug. ***

[Bug c++/16233] unhelpful error message when "template" is omitted

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2012-04-12 11:50:00 |2015-9-18

--- Comment #6 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #3)
> Confirmed, here is shorter example:
> template void B(V a)
> {
>   a.Foo ();
> }

We still give the same error, just with a caret location now:

templ.cc: In function ‘void B(V)’:
templ.cc:3:9: error: expected primary-expression before ‘int’
   a.Foo ();
 ^
templ.cc:3:9: error: expected ‘;’ before ‘int’


whereas Clang is much better:

templ.cc:3:5: error: use 'template' keyword to treat 'Foo' as a dependent
template name
  a.Foo ();
^
template 
1 error generated.

[Bug libstdc++/67620] _GLIBCXX_USE_CXX11_ABI=1 fails to catch ios_base::failure

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
This is already known, and work is ongoing to make it do the right thing.

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

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at gcc dot gnu.org]

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

--- Comment #28 from Jeffrey A. Law  ---
Author: law
Date: Fri Sep 18 19:33:48 2015
New Revision: 227922

URL: https://gcc.gnu.org/viewcvs?rev=227922=gcc=rev
Log:
[PATCH] const_and_copies is no longer file scoped

PR tree-optimization/47679
* tree-ssa-dom.c (const_and_copies): No longer file scoped.  Move
it here ...
(dom_opt_dom_walker): New private member holding the const_and_copies
object.  Update constructor.
(pass_dominator::execute): Corresponding changes to declaration
and initialization of const_and_copies.  Update constructor call
for the dom_opt_dom_walker object.
(record_temporary_equivalences): Accept const_and_copies argument
pass it down to children as needed.
(record_equality): Likewise.
(record_equivalences_from_incoming_edge): Likewise.
(cprop_into_successor_phis, optimize_stmt): Likewise.
(eliminate_redundant_computations): Likewise.
(dom_opt_dom_walker::thread_across_edge): Update access to
const_and_copies object and pass it to children as needed.
(dom_opt_dom_walker::before_dom_children): Similarly.
(dom_opt_dom_walker::after_dom_children): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug bootstrap/67347] [alpha] unused function vms_asm_out_constructor

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

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

--- Comment #1 from Mikhail Maltsev  ---
I believe this warning was fixed in revision range (r227480, r227896].

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[pangbw at gmail dot com]

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

--- Comment #29 from baoshan  ---

> However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> times + 1). Why is this estimate wrong?

The max value of n is 6, so the max value of i is 5 as "i < n", then the max
value of j is 4 as "j = i - 1" which means the max iterate times is 4.

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[pangbw at gmail dot com]

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

--- Comment #27 from baoshan  ---
> It seems GCC at some moment unrolls the loop and creates such block with
> those ranges. Probably, the block is unreachable, but it would be better to
> not create it in the first place. Finding out where and why it is created
> would help to figure out a fix.


At pass "cunrolli", it would unroll the loops according the estimated iterate
times. The problem is at this time it use array ref(infer_loop_bounds_from_ref)
to infer the iterate times which is not accurate. The inaccurate iterate times
result the extra blocks.

I am not sure which way to go at this point. Should we add value range
propagation in/before "cunrolli" so we can get the accurate iterate times? or
We just disable the warning being reported at "vrp" pass?

[Bug middle-end/67401] Incorrect expand of __atomic_compare_exchange_8 using __sync_val_compare_and_swap_8

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Fri Sep 18 18:24:09 2015
New Revision: 227913

URL: https://gcc.gnu.org/viewcvs?rev=227913=gcc=rev
Log:
PR middle-end/67401
* optabs.c (expand_atomic_compare_and_swap): Move result of emitting
sync_compare_and_swap_optab libcall to target_oval.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/optabs.c

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[manu at gcc dot gnu.org]

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

--- Comment #30 from Manuel López-Ibáñez  ---
(In reply to baoshan from comment #29)
> > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> > times + 1). Why is this estimate wrong?
> 
> The max value of n is 6, so the max value of i is 5 as "i < n", then the max
> value of j is 4 as "j = i - 1" which means the max iterate times is 4.

True! Well, that reinforces my point that something is very wrong in the
estimation. What is it?

[Bug fortran/67615] ICE on using arithmetic if with array instead of scalar

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> This patch to resolve.c catches the problem.  Watch for
> cut-n-paste corruption of tabs.
> 
> @@ -10377,12 +10381,11 @@ gfc_resolve_code (gfc_code *code, gfc_na
>   }
>  
> case EXEC_ARITHMETIC_IF:
> - if (t
> - && code->expr1->ts.type != BT_INTEGER
> - && code->expr1->ts.type != BT_REAL)
> -   gfc_error ("Arithmetic IF statement at %L requires a numeric "
> -  "expression", >expr1->where);
>  
> + if (t && (code->expr1->rank > 0 || !gfc_numeric_ts
> (>expr1->ts)))
> +   gfc_error ("Arithmetic IF statement at %L requires a scalar "
> +  "numeric expression", >expr1->where);
> + 
>   resolve_branch (code->label1, code);
>   resolve_branch (code->label2, code);
>   resolve_branch (code->label3, code);
> 
> Whoops.  Needs for for BT_COMPLEX.

Better patch

@@ -10377,12 +10381,13 @@ gfc_resolve_code (gfc_code *code, gfc_na
  }

case EXEC_ARITHMETIC_IF:
- if (t
- && code->expr1->ts.type != BT_INTEGER
- && code->expr1->ts.type != BT_REAL)
-   gfc_error ("Arithmetic IF statement at %L requires a numeric "
-  "expression", >expr1->where);

+ if (t && (code->expr1->rank > 0
+   || !(code->expr1->ts.type == BT_REAL
+|| code->expr1->ts.type == BT_INTEGER)))
+   gfc_error ("Arithmetic IF statement at %L requires a scalar "
+  "REAL or INTEGER expression", >expr1->where);
+ 
  resolve_branch (code->label1, code);
  resolve_branch (code->label2, code);
  resolve_branch (code->label3, code);

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at gcc dot gnu.org]

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

--- Comment #29 from Jeffrey A. Law  ---
Author: law
Date: Sat Sep 19 02:56:15 2015
New Revision: 227931

URL: https://gcc.gnu.org/viewcvs?rev=227931=gcc=rev
Log:
[PATCH] avail_expr_stack is no longer file scoped

   PR tree-optimization/47679
* tree-ssa-dom.c (avail_exprs_stack): No longer file scoped.  Move
it here ...
(dom_opt_dom_walker): New private member holding the avail_exprs_stack
object.  Update constructor.
(pass_dominator::execute):  Corresponding chagnes to declaration
and initialization of avail_exprs_stack.  Update constructor call
for dom_opt_dom_walker object.
(lookup_avail_expr, record_cond): Accept additional argument.  Pass
it down to children as needed.
(record_equivalences_from_incoming_edge): Likewise.
(eliminate_redundant_computations): Likewise.
(record_equivalences_from_stmt): Likewise.
(simplify_stmt_for_jump_threading): Likewise.
(record_temporary_equivalences): Likewise.
(optimize_stmt): Likewise.
(dom_opt_dom_walker::thread_across_edge): Update access to
avail_exprs_stack object and pass it to children as needed.
(dom_opt_dom_walker::before_dom_children): Similarly.
(dom_opt_dom_walker::after_dom_children): Similarly.
* tree-ssa-threadedge.c (pfn_simplify): New typedef.
(record_temporary_equivalences_from_stmts_at_dest): Use new typedef.
Add avail_expr_stack argument.  Pass it to children as needed.
(dummy_simplify): Likewise.
(simplify_control_stmt_condition): Likewise.
(thread_around_empty_blocks): Likewise.
(thread_through_normal_block): Likewise.
(thread_across_edge): Likewise.
* tree-ssa-threadedge.h (thread_across_edge): Update prototype.
* tree-vrp.c (simplify_stmt_for_jump_threading): Update.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-threadedge.c
trunk/gcc/tree-ssa-threadedge.h
trunk/gcc/tree-vrp.c

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #5 from Oleg Endo  ---
Kaz, do you think it's OK to backport this to GCC 5?  It looks like the patch
is not so intrusive...

[Bug rtl-optimization/67635] New: [SH] ifcvt missed optimization

[olegendo at gcc dot gnu.org]

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

Bug ID: 67635
   Summary: [SH] ifcvt missed optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

At least on SH, the following:

bool test (int a, int b, int* r)
{
  return __builtin_mul_overflow (a, b, r);
}

compiled with -m4 -ml -O2 results in:

dmuls.l r5,r4
mov #0,r0
sts macl,r1
sts mach,r2
cmp/gt  r1,r0
subcr3,r3
cmp/eq  r2,r3<<
bf  .L6  <<
.L2:
rts
mov.l   r1,@r6
.align 1
.L6:
bra .L2
mov #1,r0


The expected code would be:
dmuls.l r5,r4
mov #0,r0
sts macl,r1
sts mach,r2
cmp/gt  r1,r0
subcr3,r3
cmp/eq  r2,r3// T = r2 == r3
mov #-1,r0
negcr0,r0// T = r2 != r3
rts
mov.l   r1,@r6


Alternatively, in cases zero-displacement branches are fast (e.g. SH4):
dmuls.l r5,r4
mov #0,r0
sts macl,r1
sts mach,r2
cmp/gt  r1,r0
subcr3,r3
cmp/eq  r2,r3
bt  0f
mov #1,r0
0:
rts
mov.l   r1,@r6


I think I have seen similar cases before, where something tries to preserve the
zero constant in a reg.  Instead of overwriting it with a cstore value {0,1},
conditional branches are created for the non-zero paths.

If conditional move patterns are enabled on SH with -mpretend-cmove the
conditional branches go away:

dmuls.l r5,r4
mov #-1,r0
sts macl,r2
sts mach,r3
sts macl,r1
shllr2
subcr2,r2
cmp/eq  r3,r2
mov.l   r1,@r6
rts
negcr0,r0

But enabling -mpretend-cmove on SH has some other side effects and currently is
not safe (PR 58517).

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

[eggert at gnu dot org]

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

--- Comment #12 from Paul Eggert  ---
(In reply to Manuel López-Ibáñez from comment #11)

> Another alternative is to only warn if the variable is defined in the main
> file (MAIN_FILE_P) as opposed to an included file.

Thanks, this is a reasonable suggestion; it would fix the cry-wolf problem for
tzcode, which is what prompted me to object to the original proposal.

The alternative of littering the code with many instances of __attribute__
((unused)) (or is it __attribute ((used)? I can never remember) is less
appealing.

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[pangbw at gmail dot com]

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

--- Comment #31 from baoshan  ---
(In reply to Manuel López-Ibáñez from comment #30)
> (In reply to baoshan from comment #29)
> > > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> > > times + 1). Why is this estimate wrong?
> > 
> > The max value of n is 6, so the max value of i is 5 as "i < n", then the max
> > value of j is 4 as "j = i - 1" which means the max iterate times is 4.
> 
> True! Well, that reinforces my point that something is very wrong in the
> estimation. What is it?

At the pass "cunrolli", it infers the iterative times by checking the array's
boundary, as we have "unsigned baz[6];", it would think the max value of
iterative times is 6.

[Bug c++/67632] explicit instantiation omits copy constructor and others

[jlink at drw dot com]

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

--- Comment #3 from Joseph Link  ---
Yeah, watch out for the copy constructor that takes an allocator.  That one's
there.  The compiler generated one is not.

[Bug c++/67632] New: explicit instantiation omits copy constructor and others

[jlink at drw dot com]

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

Bug ID: 67632
   Summary: explicit instantiation omits copy constructor and
others
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlink at drw dot com
  Target Milestone: ---

When I compile the follow test case with g++ -std=c++11 -c, and view the output
with nm, it shows that the std::unordered_map copy constructor is never
emitted:

% cat t.cc 
#include 
template class std::unordered_map;
% g++ -std=c++11 -c t.cc
% 

If I compile the following and link it with the above, I'll get the undefined
reference:

% cat x.cc 
#include 
extern template class std::unordered_map;
std::unordered_map copy(
   const std::unordered_map & a) { return a; }

main() {}

% g++ -std=c++11 t.o x.cc 
/tmp/cc0dF94P.o: In function `copy(std::unordered_map > const&)':
x.cc:(.text+0x1f): undefined reference to `std::unordered_map
>::unordered_map(std::unordered_map > const&)'
collect2: error: ld returned 1 exit status

This seems like a clear bug, right?  Either the explicit instantiation should
emit everything, or the use of extern template should know what still needs to
be emitted locally.

[Bug c++/67631] brace initialization bug

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-18
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.2.1, 6.0

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat bra.ii
class X
{
public:
  X (int);
  explicit operator unsigned ();
};
unsigned
foo ()
{
  return unsigned{ X (0) };
}
markus@x4 tmp % icpc -Wall -Wextra -c -std=c++14 bra.ii
markus@x4 tmp % clang++ -Wall -Wextra -c -std=c++14 bra.ii
markus@x4 tmp % g++ -Wall -Wextra -c -std=c++14 bra.ii
bra.ii: In function ‘unsigned int foo()’:
bra.ii:10:26: error: cannot convert ‘X’ to ‘unsigned int’ in initialization
   return unsigned{ X (0) };
  ^

[Bug libgcc/67624] arm/fp16.c __gnu_f2h_internal has wrong pattern for INF/NAN

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
All NaNs should have the top mantissa bit set in the result of the 
conversion (i.e. the result of the conversion should always be a quiet 
NaN, not a signaling NaN) - setting that bit also ensures the result is 
not an infinity.  Then I think the remaining bits in the mantissa of the 
result should match the corresponding high bits in the mantissa of the 
source (which appears to be what the hardware conversion instructions are 
documented to do).

[Bug c++/67633] New: decltype on parenthesized class member access of a prvalue sometimes return wrong results

[rs2740 at gmail dot com]

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

Bug ID: 67633
   Summary: decltype on parenthesized class member access of a
prvalue sometimes return wrong results
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Per the resolution of CWG 616, given struct A { double x; };, decltype((A().x))
should be double&&.

However, the following snippet (incorrectly) compiles:

struct A { double x; };
using t1 = double;
using t1 = decltype((A().x));

Note that the following snippet (correctly) does not compile:

struct A { double x; };
struct B : A {};
using t1 = double;
using t1 = decltype((B().x));

[Bug c++/67632] explicit instantiation omits copy constructor and others

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #2 from Markus Trippelsdorf  ---
Reopened. I've tested for the wrong symbol.
I let others handle this.

[Bug c++/67631] New: brace initialization bug

[howard.hinnant at gmail dot com]

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

Bug ID: 67631
   Summary: brace initialization bug
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howard.hinnant at gmail dot com
  Target Milestone: ---

I expect this program to compile and not assert when run:

#include 

template 
void
test(const U& uo)
{
T t{uo};
U u{t};
assert(u == uo);
t = T{uo};
u = U{t};
assert(u == uo);
}

class X
{
unsigned char data_;
public:
explicit X(unsigned data)
: data_(data)
{}

explicit operator unsigned() const {return data_;}

friend bool operator==(const X& x, const X& y)
{
return x.data_ == y.data_;
}
};

int
main()
{
test(X{3});
}

I get:

prog.cc: In instantiation of 'void test(const U&) [with T = unsigned int; U =
X]':
prog.cc:34:24:   required from here
prog.cc:10:7: error: cannot convert 'const X' to 'unsigned int' in
initialization
 t = T{uo};
   ^

[Bug c++/67632] explicit instantiation omits copy constructor and others

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Markus Trippelsdorf  ---
I cannot reproduce this issue with 4.9.3. Please update.

[Bug other/67630] ymm and zmm register aren't preserved in interrupt handler

[hjl.tools at gmail dot com]

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

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

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

[eggert at gnu dot org]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #10 from Paul Eggert  ---
This topic came up on the libc-alpha mailing list.  The proposed change would
break compilation of tzcode, which has a private header that defines static
constants not all of which are used in every file that includes the header.

In tzcode the problem can be worked around by using a #define rather than a
static constant, but many C programmers nowadays prefer avoiding #define when
possible, and static constants let you do that in many cases. (An enum wouldn't
work for the tzcode case, as the values might be outside int range.)  Also, in
many environments macros are invisible to the debugger but static constants are
visible, so the static constants are nicer for people debugging their code.

This reminds me of when gcc -Wmissing-declarations used to diagnose every
C99-style inline function in an include file (GCC bug 63877). The warning was
put in and tested, but the tests used only old-fashioned C programming styles,
and the warning caused real problems by people using a more modern C style.

It'd be fine to add an option to enable the new warning, but please don't
enable them merely because -Wall or -Wunused-variable is specified.

[Bug tree-optimization/67283] GCC regression over inlining of returned structures

[alalaw01 at gcc dot gnu.org]

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

--- Comment #13 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Fri Sep 18 10:55:11 2015
New Revision: 227901

URL: https://gcc.gnu.org/viewcvs?rev=227901=gcc=rev
Log:
completely_scalarize arrays as well as records.

gcc/:

PR tree-optimization/67283
* tree-sra.c (type_consists_of_records_p): Rename to...
(scalarizable_type_p): ...this, add case for ARRAY_TYPE.
(completely_scalarize_record): Rename to...
(completely_scalarize): ...this, add ARRAY_TYPE case, move some code
to:
(scalarize_elem): New.
(analyze_all_variable_accesses): Follow renamings.

gcc/testsuite/:

* gcc.dg/tree-ssa/sra-15.c: New.
* gcc.dg/tree-ssa/sra-16.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-15.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug fortran/67623] interaction between cpp and Fortran

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I think multi-line strings like this are not well supported by C/C++. 
Eventually fortran needs to tell the preprocessor it allows them.

[Bug c++/67621] Syntax error for template function of template class

[physik3 at gmx dot net]

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

--- Comment #2 from physik3 at gmx dot net ---
Hi.

(In reply to Jonathan Wakely from comment #1)
> (In reply to physik3 from comment #0)
> > foo.foo(); // this line gives a compiler error
> 
> This needs to be:
> 
> foo.template foo();
> 
> See https://womble.decadent.org.uk/c++/template-faq.html#disambiguation

Thank you, you are completely right.

Would it be hard to implement that GCC prints a message like "Did you forget
keyword template?" in this situation?

[Bug fortran/67623] interaction between cpp and Fortran

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Blocks||28662

--- Comment #3 from Manuel López-Ibáñez  ---
Fortran devs need to add a Fortran mode to CPP.

Related to PR28662.

Tobias already mentioned this here:
https://gcc.gnu.org/ml/gcc/2014-11/msg00357.html

See also the comments in https://gcc.gnu.org/ml/gcc/2014-12/msg3.html and
follow-ups.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
[Bug 28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x

[Bug fortran/67623] New: interaction between cpp and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 67623
   Summary: interaction between cpp and Fortran
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The C(++) preprocessor that is invoked on .F90 files can change Fortran
strings, leading to unexpected results. While it is OK to remove things that
are truly C comments (e.g. from headers included), this should not happen in
Fortran strings? At least gfortran and ifort show different behavior.

> cat test.F90
#define FOO
WRITE(6,*) "&
&/* foobar */&
"
END
> gfortran test.F90 ; ./a.out

> ifort test.F90 ; ./a.out
 /* foobar */
>

[Bug other/67552] [meta] x86 interrupt attribute

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
I think we should place

 if (current_function_decl && ix86_is_interrupt_p ())
{
  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
{
  if (!STACK_REGNO_P (i) && !MMX_REGNO_P (i))
{
  if (i == BP_REG || i == SP_REG)
continue;
  if (i >= ARGP_REG && i <= FRAME_REG)
continue;
  call_used_regs[i] = 0;
  fixed_regs[i] = 0;
}
}
}

at the beginning of ix86_conditional_register_usage.

[Bug fortran/67623] interaction between cpp and Fortran

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
int main()
{
  printf ("Hello\
  /*  */\
  world");
}

works as expected though:

> ./a.out 
Hello /*  */  world


but then libcpp doesn't know about fortrans continuation character?  And C
does not accept a literal newline (we're escaping that).

[Bug c++/16233] unhelpful error message when "template" is omitted

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||physik3 at gmx dot net

--- Comment #7 from Manuel López-Ibáñez  ---
*** Bug 67621 has been marked as a duplicate of this bug. ***

[Bug c++/67621] Syntax error for template function of template class

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Resolution|INVALID |DUPLICATE

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to physik3 from comment #2)
> Would it be hard to implement that GCC prints a message like "Did you forget
> keyword template?" in this situation?

It seems it is because nobody has fixed it in the last 11 years. A first step
would be to identify in gcc/cp/parser.c when g++ parses "<" then decides that
this cannot be a template argument (but perhaps it is decided earlier, when it
checks that no 'template' keyword was given).

Any help welcome, too many things to fix in GCC and too few people to work on
them.

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

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Fri Sep 18 07:57:00 2015
New Revision: 227896

URL: https://gcc.gnu.org/viewcvs?rev=227896=gcc=rev
Log:
2015-09-18  Richard Biener  

PR tree-optimization/66142
* fold-const.c (operand_equal_p): When OEP_ADDRESS_OF
treat MEM[] and x the same.
* tree-ssa-sccvn.h (vn_reference_fold_indirect): Remove.
* tree-ssa-sccvn.c (vn_reference_fold_indirect): Return true
when we simplified sth.
(vn_reference_maybe_forwprop_address): Likewise.
(valueize_refs_1): When we simplified through
vn_reference_fold_indirect or vn_reference_maybe_forwprop_address
set valueized_anything to true.
(vn_reference_lookup_3): Use stmt_kills_ref_p to see whether
one ref kills the other instead of just a offset-based test.
* tree-ssa-alias.c (stmt_kills_ref_p): Use OEP_ADDRESS_OF
for the operand_equal_p test to compare bases and also compare
sizes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
This ought to be resolved for 5/6.

[Bug c/56566] bogus "is narrower than values of its type" warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Seems to be fixed long time ago.

[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
(In reply to Yury Gribov from comment #7)
> FYI I'd prefer to keep current BIT_IOR_EXPR approach in
> asan_expand_check_ifn as it allows for efficient implementation for ARM
> targets (as compared to two successive branches currently used in LLVM).

Ugh.  Then perhaps we should decide based on some costs.
We have LOGICAL_OP_NON_SHORT_CIRCUIT and BRANCH_COST, unfortunately the former
is to decide on very cheap computation with roughly the same probabilities,
rather than this case where the cheaper condition is much more likely, and
BRANCH_COST can't be really compared to insn costs.
So perhaps base this say on targetm.have_conditional_execution () ?

[Bug sanitizer/67626] New: Erroneous report on downcast to __numpunct_cache

[sduvan.gcc at gmail dot com]

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

Bug ID: 67626
   Summary: Erroneous report on downcast to __numpunct_cache
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sduvan.gcc at gmail dot com
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: ---

Created attachment 36347
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36347=edit
Preprocessed source code

For the testcase below, it seems to me that ubsan is confused. The locale
stores 'facet*':s in its cache which are downcast by __use_cache::operator() to
retrieve the actual type (std::__numpunct_cache). Moreover,
__numpunct_cache is a template and no type, as indicated in the error message
below.

Reduced testcase:

#include 

int main() {
  std::locale loc(std::locale(), new std::num_put());
  std::num_put const& np = std::use_facet>(loc);
  char buf[256];
  struct ios : std::ios_base {} ios;
  np.put(buf, ios, '0', 1l);
}

bash> /usr/local/products/gcc/5.2.0/bin/g++ -fsanitize=undefined -std=gnu++11
-o bug bug.C -Wl,-rpath,/usr/local/products/gcc/5.2.0/lib64
bash> ./bug
/usr/local/products/gcc/5.2.0/include/c++/5.2.0/bits/locale_facets.tcc:72:67:
runtime error: downcast of address 0x7f57533d21e0 which does not point to an
object of type '__numpunct_cache'
0x7f57533d21e0: note: object is of type 'std::__numpunct_cache'
00 00 00 00  d8 5f 3c 53 57 7f 00 00  01 00 00 00 00 00 00 00  8a bd 38 53 57
7f 00 00  00 00 00 00
 ^~~
 vptr for 'std::__numpunct_cache'
/usr/local/products/gcc/5.2.0/include/c++/5.2.0/bits/locale_facets.tcc:880:2:
runtime error: member access within address 0x7f57533d21e0 which does not point
to an object of type '__numpunct_cache'
0x7f57533d21e0: note: object is of type 'std::__numpunct_cache'
00 00 00 00  d8 5f 3c 53 57 7f 00 00  01 00 00 00 00 00 00 00  8a bd 38 53 57
7f 00 00  00 00 00 00
 ^~~
 vptr for 'std::__numpunct_cache'


bash> /usr/local/products/gcc/5.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/5.2.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/5.2.0/lib/gcc/x86_64-suse-linux/5.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-5.2.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/5.2.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.25.1/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.25.1/bin/ld.gold
--with-gmp=/usr/local/products/gcc/gmp-5.0.1
--with-mpfr=/usr/local/products/gcc/mpfr-3.0.0
--with-mpc=/usr/local/products/gcc/mpc-0.8.2 --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
gcc version 5.2.0 (GCC)

[Bug tree-optimization/67628] [tree-optimization] (a && b) && c shows better codegen than a && (b && c)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-18
 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This is due to the fold-const.c optimization which should not be there any
more. You need to do benchmarking on x86 also if you remove it. 

I have not done that yet which is why I have not submitted the patch to fix
this.

[Bug other/67627] New: libatomic parallel build failure

[nsz at gcc dot gnu.org]

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

Bug ID: 67627
   Summary: libatomic parallel build failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

hard to reproduce, but the failure is

make[5]: Entering directory `/XX/obj/gcc4/arm-none-linux-gnueabihf/libatomic'
.deps/fsub_8_.lo.Ppo:87: *** missing separator.  Stop.

and the cause is that .deps/fsub_8_.lo.Ppo is a makefile fragment generated by
a compilation step that is run concurrently with another make reading this
file.

some relevant bits from libatomic/Makefile.in:

### begin

LTLIBRARIES = $(noinst_LTLIBRARIES) $(toolexeclib_LTLIBRARIES)
toolexeclib_LTLIBRARIES = libatomic.la
noinst_LTLIBRARIES = libatomic_convenience.la
libatomic_la_DEPENDENCIES = $(libatomic_la_LIBADD) $(libatomic_version_dep)
libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix \
_$(s)_.lo,$(SIZEOBJS))) $(am__append_1) $(am__append_2) \
$(am__append_3)

M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo

libatomic.la: $(libatomic_la_OBJECTS) $(libatomic_la_DEPENDENCIES)
$(EXTRA_libatomic_la_DEPENDENCIES).
$(libatomic_la_LINK) -rpath $(toolexeclibdir) $(libatomic_la_OBJECTS)
$(libatomic_la_LIBADD) $(LIBS)

all-multi:
$(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE)

all-am: Makefile $(LTLIBRARIES) all-multi auto-config.h

-include $(wildcard $(DEPDIR)/*.Ppo)

%_.lo: Makefile
$(LTCOMPILE) $(M_DEPS) $(M_SIZE) $(M_IFUNC) -c -o $@ $(M_SRC)

### end

when all-am is built, building $(LTLIBRARIES) (the *_.lo targets) can run in
parallel with all-multi.

the all-multi target rereads the Makefile so reevaluates "-include $(wildcard
$(DEPDIR)/*.Ppo)", but those files are generated in a non-atomic way by gcc -MF
during the build of *_.lo targets.

[Bug tree-optimization/67628] New: [tree-optimization] (a && b) && c shows better codegen than a && (b && c)

[ktkachov at gcc dot gnu.org]

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

Bug ID: 67628
   Summary: [tree-optimization] (a && b) && c shows better codegen
than a && (b && c)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Consider the two functions:
int
foo1 (int a, int b, int c, int d)
{
  return a > b && b <= c && c > d;
}

int
foo2 (int a, int b, int c, int d)
{
  return a > b && (b <= c && c > d);
}

On aarch64 foo1 generates:
foo1:
cmp w1, w2
ccmpw2, w3, 4, le
ccmpw0, w1, 4, gt
csetw0, gt
ret

but for foo2 generates:
foo2:
cmp w0, w1
ble .L4
cmp w1, w2
csetw1, le
cmp w2, w3
csetw0, gt
and w0, w1, w0
ret


Something similar is observed on x86_64 where foo2 contains a conditional
branch instruction where foo1 is a single basic block

In foo2 we end up generating multiple basic blocks whereas for foo1 we manage
to merge them all into 1 basic block which ends up going through the
conditional-compare pass nicely.

Looking at the final .optimized tree dump the foo1 tree is:
  _BoolD.2673 _1;
  _BoolD.2673 _4;
  _BoolD.2673 _6;
  _BoolD.2673 _10;
  _BoolD.2673 _11;
  intD.7 _12;

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  # RANGE [0, 1]
  _4 = a_2(D) > b_3(D);
  # RANGE [0, 1]
  _6 = b_3(D) <= c_5(D);
  # RANGE [0, 1]
  _10 = c_5(D) > d_8(D);
  # RANGE [0, 1]
  _1 = _6 & _10;
  # RANGE [0, 1]
  _11 = _1 & _4;
  # RANGE [0, 1] NONZERO 1
  _12 = (intD.7) _11;
  # VUSE <.MEM_9(D)>
  return _12;
;;succ:   EXIT [100.0%] 




whereas for foo2 it's more complex:
  intD.7 iftmp.0_1;
  _BoolD.2673 _5;
  _BoolD.2673 _7;
  _BoolD.2673 _8;
  intD.7 _10;
  _BoolD.2673 _11;

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  if (a_2(D) > b_3(D))
goto ;
  else
goto ;
;;succ:   3 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;4 [50.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 0, freq 5000, maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE)
;;pred:   2 [50.0%]  (TRUE_VALUE,EXECUTABLE)
  # RANGE [0, 1]
  _5 = b_3(D) <= c_4(D);
  # RANGE [0, 1]
  _7 = c_4(D) > d_6(D);
  # RANGE [0, 1]
  _8 = _5 & _7;
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE)
;;pred:   3 [100.0%]  (FALLTHRU,EXECUTABLE)
;;2 [50.0%]  (FALSE_VALUE,EXECUTABLE)
  # _11 = PHI <_8(3), 0(2)>
  # RANGE [0, 1] NONZERO 1
  iftmp.0_1 = (intD.7) _11;
  # VUSE <.MEM_9(D)>
  return iftmp.0_1;
;;succ:   EXIT [100.0%] 



If we were to pick some kind of canonicalization for these equivalent
expressions it would make life easier for later passes to generate consistent
code.

[Bug tree-optimization/67628] [tree-optimization] (a && b) && c shows better codegen than a && (b && c)

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> This is due to the fold-const.c optimization which should not be there any
> more. You need to do benchmarking on x86 also if you remove it. 
> 

could you elaborate what optimization is that?
Is it a matter of fold-const.c or match.pd canonicalizing the expression in
some way?

[Bug tree-optimization/67628] [tree-optimization] (a && b) && c shows better codegen than a && (b && c)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to ktkachov from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This is due to the fold-const.c optimization which should not be there any
> > more. You need to do benchmarking on x86 also if you remove it. 
> > 
> 
> could you elaborate what optimization is that?
> Is it a matter of fold-const.c or match.pd canonicalizing the expression in
> some way?

The optimization is converting andif into and. Basically ifcombine pass does
not recombine them if fold-const does it early on.

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Now that sanitisers are complaining about this we should really fix it.

[Bug libgcc/67624] New: arm/fp16.c __gnu_f2h_internal has wrong pattern for INF/NAN

[pekka.jaaskelainen at parmance dot com]

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

Bug ID: 67624
   Summary: arm/fp16.c __gnu_f2h_internal has wrong pattern for
INF/NAN
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pekka.jaaskelainen at parmance dot com
  Target Milestone: ---

I believe the f2h conversion routine uses wrong mask for INF/NAN in the early
shortcut. It seems to be the case also in the gcc HEAD.

This should fix it:

--- arm/fp16.c  2015-09-18 15:53:51.069011932 +0300
+++ fp16.c  2015-09-18 15:50:50.653013393 +0300
@@ -35,7 +35,7 @@
 {
   if (!ieee)
return sign;
-  return sign | 0x7e00 | (mantissa >> 13);
+  return sign | 0x7c00 | (mantissa >> 13);
 }

   if (aexp == 0 && mantissa == 0)

[Bug libstdc++/66624] libstdc++ iostream uninitialized data

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
markus@x4 ~ % clang++ -fsanitize=undefined -O0 -g t.cc
markus@x4 ~ % gdb ./a.out
Reading symbols from ./a.out...done.
(gdb) b __ubsan::ScopedReport::~ScopedReport
Breakpoint 1 at 0x41f5c0: file
/home/markus/llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc, line 364.
(gdb) run
Starting program: /home/markus/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.1/include/g++-v5/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value for type
'std::_Ios_Fmtflags'

Breakpoint 1, __ubsan::ScopedReport::~ScopedReport (this=0x7fffdec0,
__in_chrg=) at
/home/markus/llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc:364
364 ScopedReport::~ScopedReport() {
(gdb) up
#1  0x00420a5f in handleLoadInvalidValue (Data=,
Val=4294967221, Opts=...) at
/home/markus/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:375
375: ErrorType::InvalidEnumLoad);
(gdb) up
#2  0x00422dd3 in __ubsan::__ubsan_handle_load_invalid_value
(Data=, Val=)
at /home/markus/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:385
385   handleLoadInvalidValue(Data, Val, Opts);
(gdb) up
#3  0x00425cad in std::operator&= (__a=@0xf09ec0: 4098, __b=4294967221)
at /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.1/include/g++-v5/bits/ios_base.h:102
102   { return __a = __a & __b; }
(gdb) up
#4  0x00425a21 in std::ios_base::setf (this=0xf09ea8 ,
__fmtfl=std::_S_hex, __mask=std::_S_basefield)
at
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.1/include/g++-v5/bits/ios_base.h:660
660   _M_flags &= ~__mask;
(gdb) p __mask
$1 = std::_S_basefield
(gdb)

[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Another case is -Wdeclaration-after-statement:

int
fn (int m)
{
  if (m > 0)
return -1;
  int a;
}

[Bug libstdc++/66624] libstdc++ iostream uninitialized data

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to TC from comment #5)
> Is this not a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158?

Yes.

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

[Bug c++/67625] New: some constexpr expressions rejected as enumerator value

[matthijsvanduin at gmail dot com]

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

Bug ID: 67625
   Summary: some constexpr expressions rejected as enumerator
value
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthijsvanduin at gmail dot com
  Target Milestone: ---

GCC 5.2.1 rejects the following code (with -std=gnu++11 or later):

constexpr uint16_t bswap16( uint16_t x ) {
return __builtin_bswap16( x );
}
constexpr int foo_1 = bswap16(1);
enum { foo_2 = foo_1 };
enum { foo_3 = __builtin_bswap16(1) };
enum { foo_4 = bswap16(1) };

with the error message "enumerator value for ‘foo_4’ is not an integer
constant", while the other three definitions of the same constant are accepted.


This is a regression w.r.t. 4.9.3

[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses

[olegendo at gcc dot gnu.org]

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

--- Comment #23 from Oleg Endo  ---
Thanks for the interesting test/use case.

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #10 from Markus Trippelsdorf  ---
*** Bug 66624 has been marked as a duplicate of this bug. ***

[Bug middle-end/67619] ICE at -O1 and above on x86_64-linux-gnu in int_mode_for_mode, at stor-layout.c:425

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|rtl-optimization|middle-end
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |4.9.4

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 CC||jvdelisle at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #29 from Jerry DeLisle  ---
I happened to just get Cygwin installed and running on my Windows box.  Let me
run some tests and see if I can understand this.

[Bug libgcc/67624] arm/fp16.c __gnu_f2h_internal has wrong pattern for INF/NAN

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Yes, the existing code looks wrong in that infinity gets converted to NaN.

Your patch, however, is not right either, since it can convert some NaNs (where
only the bottom 13 bits are non-zero) to infinity.

I'd need to think a bit more on what the exact conversion needs to be in these
cases.

[Bug fortran/67615] ICE on using arithmetic if with array instead of scalar

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
This patch to resolve.c catches the problem.  Watch for
cut-n-paste corruption of tabs.

@@ -10377,12 +10381,11 @@ gfc_resolve_code (gfc_code *code, gfc_na
  }

case EXEC_ARITHMETIC_IF:
- if (t
- && code->expr1->ts.type != BT_INTEGER
- && code->expr1->ts.type != BT_REAL)
-   gfc_error ("Arithmetic IF statement at %L requires a numeric "
-  "expression", >expr1->where);

+ if (t && (code->expr1->rank > 0 || !gfc_numeric_ts
(>expr1->ts)))
+   gfc_error ("Arithmetic IF statement at %L requires a scalar "
+  "numeric expression", >expr1->where);
+ 
  resolve_branch (code->label1, code);
  resolve_branch (code->label2, code);
  resolve_branch (code->label3, code);

Whoops.  Needs for for BT_COMPLEX.

[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues

[miyuki at gcc dot gnu.org]

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

Bug 67347 Summary: [alpha] unused function vms_asm_out_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67347

   What|Removed |Added

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

[Bug middle-end/67619] ICE at -O1 and above on x86_64-linux-gnu in int_mode_for_mode, at stor-layout.c:425

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Sep 18 16:27:51 2015
New Revision: 227909

URL: https://gcc.gnu.org/viewcvs?rev=227909=gcc=rev
Log:
PR middle-end/67619
* except.c (expand_builtin_eh_return): Use copy_addr_to_reg to copy
the address to a register.

testsuite/ChangeLog:

PR middle-end/67619
* gcc.dg/torture/pr67619.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67619.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/except.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at gcc dot gnu.org]

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

--- Comment #27 from Jeffrey A. Law  ---
Author: law
Date: Fri Sep 18 15:29:01 2015
New Revision: 227908

URL: https://gcc.gnu.org/viewcvs?rev=227908=gcc=rev
Log:
[PATCH] Break out phi-only cprop into its own file

PR tree-optimization/47679
* Makefile.in (OBJS): Add tree-ssa-phionlycprop.o
* tree-ssa-dom.c: Remove unnecessary header includes.
(remove_stmt_or_phi): Moved from here into tree-ssa-phionlycprop.c
(get_rhs_or_phi_arg, get_lhs_or_phi_result): Likewise.
(propagate_rhs_into_lhs, eliminate_const_or_copy): Likewise.
(eliminate_degenerate_phis_1, pass_phi_only_cprop): Likewise.
(pass_phi_only_cprop::execute): Likewise.
(make_pass_phi_only_cprop): Likewise.
* tree-ssa-phionlycprop.c: New file with moved code.  Eliminate
uses of file scoped statics by passing the required objects
as parameters wherever needed.

Added:
trunk/gcc/tree-ssa-phionlycprop.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/tree-ssa-dom.c

[Bug c/67629] New: bogus -Wreturn-type in a function with tautological if-else

[msebor at gcc dot gnu.org]

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

Bug ID: 67629
   Summary: bogus -Wreturn-type in a function with tautological
if-else
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing Marek's patch for PR 64249 I noticed that both gcc and g++
incorrectly issue a -Wreturn-type warning for the following snippet:

$ cat u.c && xgcc -Wreturn-type -c u.c
int foo (_Bool a) {
if (a) return 0;
else if (!a) return 1;
}
u.c: In function ‘foo’:
u.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

[Bug other/67630] New: ymm and zmm register aren't preserved in interrupt handler

[hjl.tools at gmail dot com]

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

Bug ID: 67630
   Summary: ymm and zmm register aren't preserved in interrupt
handler
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com
  Target Milestone: ---

[hjl@gnu-6 interrupt-5]$ make clean
rm -f *.o *.so *.s *.i.* *.x.*
[hjl@gnu-6 interrupt-5]$ cat ymm.i
void
__attribute__((interrupt))
fn1 (void)
{
  asm ("#"
   :
   : 
   : "ymm0");
}
[hjl@gnu-6 interrupt-5]$ make ymm.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mavx -S -o ymm.s ymm.i
[hjl@gnu-6 interrupt-5]$ cat ymm.s
.file   "ymm.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  fn1
.type   fn1, @function
fn1:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
vmovaps %xmm0, (%rsp)
.cfi_offset 17, -32
#APP
# 5 "ymm.i" 1
#
# 0 "" 2
#NO_APP
vzeroupper
vmovaps (%rsp), %xmm0
addq$24, %rsp
.cfi_def_cfa_offset 8
iret
.cfi_endproc
.LFE0:
.size   fn1, .-fn1
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 6.0.0 20150917 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 interrupt-5]$

[Bug other/67630] ymm and zmm register aren't preserved in interrupt handler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-18
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
ix86_compute_frame_layout has

  /* Align and set SSE register save area.  */
  if (frame->nsseregs)
{
  /* The only ABI that has saved SSE registers (Win64) also has a
 16-byte aligned default stack, and thus we don't need to be
 within the re-aligned local stack frame to save them.  */
  gcc_assert (INCOMING_STACK_BOUNDARY >= 128); 
  offset = (offset + 16 - 1) & -16;
  offset += frame->nsseregs * 16; 
}

It isn't true for interrupt handler.