[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ch3root at openwall dot com]

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

--- Comment #27 from Alexander Cherepanov  ---
On 06/12/2016 01:09 AM, joseph at codesourcery dot com wrote:
>>> C11 does not
>>> consider sNaNs, and TS 18661 is explicitly stating otherwise for them.
>>
>> You are talking about C11 + TS 18661 which is a different version of C.
>
> The semantics of C11 + TS 18661 are a refinement of those of C11 (with
> sNaNs in C11 being trap representations by virtue of not acting like any
> kind of value considered by C11, so a refinement of C11 semantics can
> apply any semantics it likes to them).

Ok, I see. It seems that it would be fine with C11 to consider sNaN and 
qNaN alternative representations of the same value when traps are off 
but it would be incompatible with TS 18661 so it's more convenient to 
consider sNaN a trap representation. This makes the question of traps 
irrelevant and makes it compatible with TS 18661.

>> I'm not sure. It would be nice to have such a clear distinction between
>> values and representations but C is tricky. What is the value of a union
>> after memset? Suppose a value stored into an active member of a union
>> admits several representations, is taking inactive member of this union
>> (aka type-punning) is required to give the same result before and after
>> applying lvalue-to-rvalue conversion to the union?
>>
>> Heck, even the example that started this PR is not that easy. If a
>> member of a structure has a trap representation what is the value of
>> this structure? Is copying of this structure required to preserve the
>> exact representation of this member? Can this trap representation be
>> changed to a non-trap one?
>
> All these memory model issues would best be raised directly with WG14,

What is the best way to do it?

> possibly working together with the Cerberus people, not with individual
> implementations.

I'm afraid I don't quite understand their approach/aim and the choice of 
questions. OTOH one of the most useful to me results from the whole work 
was your reply to their questionnaire. Thank you for this!

>> So the idea is that gcc on x86-32 with feenableexcept(FE_INVALID) could
>> be made conforming with C11 + TS 18661? Is there anything there that
>
> As soon as you use feenableexcept you are completely outside the scope of
> any standards.

Isn't feenableexcept what IEC 60559 describes in the clause 8.1: 
"Language standards should define, and require implementations to 
provide, means for the user to associate alternate exception handling 
attributes with blocks (see 4.1)."? Why it's not in TS 18661?

Or you mean that a mode with traps for the invalid operation exception 
is not supported by gcc at all? Then this bug is mostly non-issue 
because IMHO the main problem is crashing and not the changes of 
representations of NaNs.

>> allows to trap on a return from a function (when the result of the
>> function is not used)? C11, 6.8.6.4p3, talks about a conversion "as if
>> by assignment" only for a case of differing types and I don't see TS
>> 18661 patching this clause of C11.
>
> The intent is clear, because C11 + Annex F semantics are meant to be a
> refinement of those of base C11 (Annex F being an optional extension to
> base C11), and from F.6 you can tell that such cases must be permitted to
> do a conversion to the same type, so it must be intended to allow such a
> conversion.  But I'll raise this for clarification in TS 18661 anyway.

Yes, this is probably a simple case. I haven't seen F.6 before but it 
surprising doesn't change 6.8.6.4p3 much.

I'm less sure about mere lvalue-to-rvalue conversion. Trapping at lvalue 
conversion makes impossible to apply isnan  to sNaNs even though 
"[...] these macros raise no floating-point exceptions, even if an 
argument is a signaling NaN."

>> I mean bug 57484 is more important case than lone loads from volatiles.
>
> 57484 is a closed C++ bug.  I think you mean 56831 as the substantive QoI
> bug for such cases.

No. 56831 is about passing sNaNs to functions as arguments. This 
conforms to TS 18661 and this could be fixed in gcc. The same for 
assignment.

57484 is about returning a value from a function. This is technically 
not conforming and this couldn't be fixed in gcc without breaking ABI. 
If a separate bug for C is required I can file one.

[Bug rtl-optimization/71532] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[amodra at gmail dot com]

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

--- Comment #3 from Alan Modra  ---
*** Bug 71531 has been marked as a duplicate of this bug. ***

[Bug middle-end/71531] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Alan Modra  ---
Dup.  See https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01098.html

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

[Bug libfortran/48925] Code cleanup in write_float.def

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Created attachment 38707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38707=edit
A preliminary patch

This patch does a major reorganization of the code for writing formatted real
numbers.

Actual writing is lifted up into write_float_string. This allows the kind=4
char unit code to be consolidated there and removed from the macros in
write_float.def.  write_float is renamed to get_float_string and returns a
pointer to a null terminated string containing the final result of formatting.

output_float is renamed build_float string, it no longer writes the result.

Buffer allocation is consolidated into a helper function. This done to allow
two separate buffers later for write_complex to enable padding the formatted
complex with leading blanks and no intervening spaces (right justification in
the default field width for list directed writes)

Yet to be done:

1)Currently have an extra xmalloc down deep in build_float_string and
build_infnan_string. I want to get rid of xmalloc here and combine it with the
allocation in write_real, etc. My intent is to have a single buffer with an
area for scratch or working and another area for the result.

2)Modify write complex to use the new helper functions and resolve pr48852.

Reviews and testing appreciated. Have not checked for leaks yet.

[Bug libstdc++/71547] Error in std::result_of - fail if function returns pointer to function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
That's not a valid use of std::result_of. Func2 is the type of a function that
takes an int* argument and returns a Func1. To use it with result_of you need
to ask what the type would be if you called a Func2 with an argument of type
int* i.e. result_of::type (and the answer would be Func1, because
that's what a Func2 returns when called with an int*).

[Bug libstdc++/71545] [6/7 Regression] Incorrect irreflexive comparison debug check in std::lower_bound

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-15
  Known to work||5.3.0
Summary|Incorrect irreflexive   |[6/7 Regression] Incorrect
   |comparison debug check in   |irreflexive comparison
   |std::lower_bound|debug check in
   ||std::lower_bound
 Ever confirmed|0   |1

[Bug tree-optimization/71550] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

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

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes.

This is a regression from 6.1.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160615 (experimental) [trunk revision 237485] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-6.1 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ 


---


int a = 3, b, c, f, g, h;
unsigned d;
char *e;

int
main ()
{
  for (; a; a--)
{
  int i;
  if (h && i)
__builtin_printf ("%d%d", c, f);
  i = 0;
  for (; i < 2; i++)
if (g)
  for (; d < 10; d++)
b = *e;
  i = 0;
  for (; i < 1; i++)
;
}
  return 0;
}

[Bug c++/55203] No unused warning for variables of non-trivial types

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Sergio Martins from comment #11)
> Did the patch for [warn_unused] get in ?

Yes: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html

[Bug debug/71549] New: ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

[su at cs dot ucdavis.edu]

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

Bug ID: 71549
   Summary: ICE on valid code at -O2 and -O3 with -g enabled in
64-bit mode on x86_64-linux-gnu: in simplify_subreg,
at simplify-rtx.c:5952
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  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
-O2 and -O3 with -g enabled on x86_64-linux-gnu in the 64-bit mode (but not in
the 32-bit mode). 

It is a regression from 6.1.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160615 (experimental) [trunk revision 237485] (GCC) 
$ 
$ gcc-trunk -m64 -Os -g small.c
$ gcc-6.1 -m64 -O2 -g small.c
$ 
$ gcc-trunk -m64 -O2 -g small.c
small.c: In function ‘main’:
small.c:21:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5952
 }
 ^
0xba9fab simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc-source-trunk/gcc/simplify-rtx.c:5951
0xbaa5c9 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../gcc-source-trunk/gcc/simplify-rtx.c:6171
0xeab2db vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8435
0x7e9b59 cselib_expand_value_rtx_1
../../gcc-source-trunk/gcc/cselib.c:1648
0x7eb53e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeab763 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8330
0xeab763 vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8492
0x7e9a75 cselib_expand_value_rtx_1
../../gcc-source-trunk/gcc/cselib.c:1683
0x7eb53e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeab763 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8330
0xeab763 vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8492
0x7eb53e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeab763 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8330
0xeab763 vt_expand_loc_callback
../../gcc-source-trunk/gcc/var-tracking.c:8492
0x7e9a75 cselib_expand_value_rtx_1
../../gcc-source-trunk/gcc/cselib.c:1683
0x7eb53e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-source-trunk/gcc/cselib.c:1530
0xeaa359 vt_expand_var_loc_chain
../../gcc-source-trunk/gcc/var-tracking.c:8330
0xeaa359 vt_expand_1pvar
../../gcc-source-trunk/gcc/var-tracking.c:8605
0xeaa359 emit_note_insn_var_location(variable**, emit_note_data*)
../../gcc-source-trunk/gcc/var-tracking.c:8660
0xead3da traverse_noresize<emit_note_data*, emit_note_insn_var_location>
../../gcc-source-trunk/gcc/hash-table.h:950
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


--


struct S1
{
  int f0;
  int f1;
  int f2;
  int:4;
} a, b;

void
fn1 (struct S1 p1)
{
  a = p1;
  int c = p1.f0;
}

int
main ()
{
  fn1 (b);
  return 0;
}

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
Does the patch still exist? Did it fail testing?

[Bug c++/71548] New: Invalid declaration involving template template param causes crash

[dude4891 at xemaps dot com]

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

Bug ID: 71548
   Summary: Invalid declaration involving template template param
causes crash
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dude4891 at xemaps dot com
  Target Milestone: ---

Created attachment 38706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38706=edit
input that crashes compiler

Here is a 9-line file (no includes) which causes various versions of g++ to
crash. I tested versions 4.7.3, 5.2.0, and 6.1.0; the bug was present in all.

Command line: 'g++ -std=c++11 bugmin.cpp'.


The output with -v for a run with version 6.1 is:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/usr/local --disable-multilib
--without-mpc --without-mpfr --without-gmp --without-cloog --without-isl
--enable-languages=c,c++
Thread model: posix
gcc version 6.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/cc1plus -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp
-mtune=generic -march=x86-64 -auxbase main -std=c++11 -version -o
/tmp/ccLwXocj.s
GNU C++11 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0

/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/x86_64-pc-linux-gnu

/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/backward
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e6557bfcf1105af72e8a2699b63dcd66
main.cpp: In substitution of 'template void f(S) [with T =
]':
main.cpp:11:8:   required from here
main.cpp:11:8: internal compiler error: Segmentation fault
 f(s);
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/71547] New: Error in std::result_of - fail if function returns pointer to function

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 71547
   Summary: Error in std::result_of - fail if function returns
pointer to function
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---


#include 
typedef void(*Func1)(int);
typedef Func1(*Func2)(int*);
typedef typename std::result_of::type Type1;


$ g++ -c -o test.o test.cc -std=c++11
test.cc:4:41: error: ‘type’ in ‘class std::result_of’
does not name a type
 typedef typename std::result_of::type Type1;
 ^
$ g++ --version
g++ (GCC) 5.3.0
Copyright (C) 2015 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.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-3.x86_64/src/gcc-5.3.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-3.x86_64/src/gcc-5.3.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.3.0 (GCC)

[Bug c++/71546] New: lambda capture fails with "was not declared in this scope"

[stefaan.deroeck at gmail dot com]

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

Bug ID: 71546
   Summary: lambda capture fails with "was not declared in this
scope"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefaan.deroeck at gmail dot com
  Target Milestone: ---

The following code fails to compile:

#include 

int main()
{
  int x1;
  [e = std::make_shared  (), x1]() {};
}

saying:
/tmp/gcc-explorer-compiler116515-85-117auiu/example.cpp: In function 'int
main()':
6 : error: 'x1' was not declared in this scope
[e = std::make_shared  (), x1]() {};
^~
6 : error: redeclaration of 'x1'
5 : note: previous declaration 'int x1'
int x1;
^~
Compilation failed

(tested on gcc.godbolt.org, using gcc-6.1 -std=c++14)

[Bug libstdc++/71545] Incorrect irreflexive comparison debug check in std::lower_bound

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I concur with the reporter, lower_bound and related functions from 25.5.3 did
got a special exception rule as of LWG 270,

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270

[Bug c++/71534] Initializing a static constexpr data member of a base class by using a static constexpr data member of a derived class should be an error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
We have been interpreting the relevant text in temp.inst, p1 that:

"The implicit instantiation of a class template specialization causes the
implicit instantiation of the declarations, but not of the definitions, [...]
static data members [...]; and it causes the implicit instantiation of the
definitions of unscoped member enumerations and member anonymous unions."

to mean that the only the declaration but not the initializer of the static
const data member declared in a class is instantiated, and resolving other bug
reports like this one as invalid (for example, bug 58848 and bug 70820).

But the interpretation in the stackoverflow response that the initializer
expression for a static const data member initialized in the class is actually
part of the declaration does seem to be supported by the text in
class.static.data, p3 (quoted below) and by two other implementations I tried
(Clang 3.8 and EDG eccp 4.11):

"A static data member of literal type can be declared in the class definition
with the constexpr specifier; if so, its declaration shall specify a
brace-or-equal-initializer in which every initializer-clause that is an
assignment-expression is a constant expression. [...] The member shall still be
defined in a namespace scope if it is odr-used (3.2) in the program and the
namespace scope definition shall not contain an initializer."

I CC Jason for his opinion.

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|5.2.0   |7.0
 Resolution|--- |FIXED
   Assignee|gjl at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #4 from Georg-Johann Lay  ---
Implemented for v7.

[Bug c++/71527] wrong type mismatch while template argument deduction/substitution

[benni.buch at gmail dot com]

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

--- Comment #1 from Benjamin Buch  ---
I simplified the example code:

// Example ==
// A compile time int-type
template < int I >
struct size{};


// The problem:
template < typename T, int N >
void f(size< N >, T(&&)[N]){}


int main(){
// OK: T is int
f(size< 2 >(), {0, 1});

// Bug: wrong type mismatch, T should be float
f< float >(size< 2 >(), {0, 1});

// OK: error conflicting types
/* f(size< 2 >(), {0, 1.f}); */

// Bug: wrong type mismatch, T should be float
f< float >(size< 2 >(), {0, 1.f});
}
//===


~$ g++ -o main -std=c++14 main.cpp 
bug.cpp: In function ‘int main()’:
bug.cpp:16:32: error: no matching function for call to ‘f(size<2>,
)’
  f< float >(size< 2 >(), {0, 1});
^
bug.cpp:8:6: note: candidate: template void f(size, T
(&&)[N])
 void f(size< N >, T(&&)[N]){}
  ^
bug.cpp:8:6: note:   template argument deduction/substitution failed:
bug.cpp:16:32: note:   mismatched types ‘float’ and ‘int’
  f< float >(size< 2 >(), {0, 1});  
^
bug.cpp:22:34: error: no matching function for call to ‘f(size<2>,
)’
  f< float >(size< 2 >(), {0, 1.f});
  ^
bug.cpp:8:6: note: candidate: template void f(size, T
(&&)[N])
 void f(size< N >, T(&&)[N]){}  
  ^
bug.cpp:8:6: note:   template argument deduction/substitution failed:
bug.cpp:22:34: note:   mismatched types ‘float’ and ‘int’
  f< float >(size< 2 >(), {0, 1.f});
  ^

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[noamb at bollweevil dot gdbg.org]

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

--- Comment #4 from noamb  ---
(In reply to noamb from comment #3)

> However, presence of options that are invalid for
> 4.9.3 in that list makes me think that perhaps the correct list of options
> in that (moderately old) version is just different.

The same behavior (incorrect with -O1, correct with full list of specific
options) is also present on linux gfortran 4.9.3 when the list of options
turned on by -O1 is automatically generated by "-O1 -Q --help=optimizers":

tin 1035 : gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu/4.9.3/libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gnu/4.9.3
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.9.3 (GCC) 

tin 1036 : gfortran -O1 orig_example.F90 ; ./a.out
 The following line should print 100
   589837704

tin 1037 : gfortran `gfortran -O1 -Q --help=optimizers | grep enabled | awk
'{print $1}'` orig_example.F90 ; ./a.out 
f951: warning: command line option ‘-frtti’ is valid for C++/ObjC++ but not for
Fortran
f951: warning: command line option ‘-fno-threadsafe-statics’ is valid for
C++/ObjC++ but not for Fortran
f951: warning: variable tracking requested, but useless unless producing debug
info
 The following line should print 100
 100

[Bug libstdc++/71545] New: Incorrect irreflexive comparison debug check in std::lower_bound

[daniel.grunwald at gmail dot com]

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

Bug ID: 71545
   Summary: Incorrect irreflexive comparison debug check in
std::lower_bound
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.grunwald at gmail dot com
  Target Milestone: ---

Compile the following with `g++-6 -D_GLIBCXX_DEBUG` and run the resulting
program:

#include 
#include 
#include 
#include 

constexpr int TABLE_SIZE = 1;
typedef int TableEntryNumber;
int table[TABLE_SIZE] = {
33
};

int main() {
std::vector v = { 0, 10, 20, 30, 40, 50 };
// Find the first entry greater or equal to table[0]:
auto it = std::lower_bound(
v.begin(), v.end(), 0,
[] (int val, TableEntryNumber tableIndex)
{
assert(tableIndex < TABLE_SIZE);
return val < table[tableIndex];
});
std::cout << *it << std::endl; // 40
}

Running this program results in:
  /usr/include/c++/6/bits/stl_algo.h:2029:
  Error: comparison doesn't meet irreflexive requirements, assert(!(a < a)).
  [...] Aborted

I think this is a false positive, and would expect the program to print the
result "40" instead.

In my reading of the standard, the binary search algorithms do not require comp
to induce a strict weak ordering on the sequence, but merely require the
sequence to be partitioned with respect to `comp(..., value)`.

Thus, these function should not perform the requires_irreflexive_pred debug
check.

Workaround:
  I can make TableEntryNumber a struct containing an integer, as the debug
check is skipped if the two comparator arguments are incompatible types.

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> I do not observe correct behavior with the options that the previous comment
> list s as being turned on by -O1 (this is on OS X 10.10, macports gfortran
> 4.9.3):

gfortran-fsf-5: error: unrecognized command line option '-fssa-backprop'
gfortran-fsf-4.9: error: unrecognized command line option '-fssa-phiopt'

So these options are not available for 4.9 and older. For 4.8.5 and 4.9.3 on
x86_64-apple-darwin15 (fink builds or mine ones), I get

[Book15] f90/bug% gfortran-fsf-4.8 pr71544.f90 -fauto-inc-dec
-fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers
-fdce -fdefer-pop -fdse -fforward-propagate -fguess-branch-probability
-fif-conversion2 -fif-conversion -finline-functions-called-once
-fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants
-fmove-loop-invariants -freorder-blocks -fshrink-wrap -fsplit-wide-types
-ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
-ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter
-funit-at-a-time -fomit-frame-pointer
[Book15] f90/bug% ./a.out  
 The
following line should print 100
 100

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[noamb at bollweevil dot gdbg.org]

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

--- Comment #3 from noamb  ---
(In reply to noamb from comment #2)

> I do not observe correct behavior with the options that the previous comment
> list s as being turned on by -O1 (this is on OS X 10.10, macports gfortran
> 4.9.3):

Sorry - this is wrong.  It was just failing to recompile because of the uknown
-fssa-* options.   Once I actually recompile with the long list of
optimizations documented as corresponding to -O1, it does work correctly, as
the first comment says.  However, presence of options that are invalid for
4.9.3 in that list makes me think that perhaps the correct list of options in
that (moderately old) version is just different.

[Bug target/71281] [7 Regression] ICE on gcc trunk on knl, wsm, ivb and bdw targets (tree-ssa-reassoc)

[anton.mitrokhin at phystech dot edu]

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

Anton Mitrokhin  changed:

   What|Removed |Added

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

--- Comment #10 from Anton Mitrokhin  ---
It works now, thank you!

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[noamb at bollweevil dot gdbg.org]

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

noamb  changed:

   What|Removed |Added

 CC||noamb at bollweevil dot 
gdbg.org

--- Comment #2 from noamb  ---
From Dominique d'Humieres
> Duplicate of pr71412?

This one is probably related, but does not actually involve calling a C
routine.  Also, that previous bug has different dependence on -O level (works
with -O0, fails with -O1, -O2, -O3, at least on OS X gfortran 4.9.3 from
macports)

I do not observe correct behavior with the options that the previous comment
list s as being turned on by -O1 (this is on OS X 10.10, macports gfortran
4.9.3):

[bernstei@rhodium tmp]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/4.9.3/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc49/gcc49/work/gcc-4.9.3/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.9
--with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--disable-isl-version-check --with-cloog=/opt/local
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc49 4.9.3_0'
Thread model: posix
gcc version 4.9.3 (MacPorts gcc49 4.9.3_0) 

[bernstei@rhodium tmp]$ gfortran  -fauto-inc-dec -fbranch-count-reg
-fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop
-fdse -fforward-propagate -fguess-branch-probability -fif-conversion2
-fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile
-fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks
-fshrink-wrap -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp
-ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop
-ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time
-fomit-frame-pointer -fstrict-aliasing t.F90
gfortran: error: unrecognized command line option '-fssa-backprop'
gfortran: error: unrecognized command line option '-fssa-phiopt'

[bernstei@rhodium tmp]$ ./a.out 
 The following line should print 100
   0

[Bug c/71538] Obvious optimization related to arrays aren't performed.

[sasho648 at gmail dot com]

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

--- Comment #4 from sasho648 at gmail dot com ---
More *shocking* example will be:

struct tx { int a[6], b[6]; } *f();

void (main)() 
{
int *p = f()->b;

if(p == NULL)
printf("What?"); 
}


Compiling with "gcc -Ofast -c test.c -o a.out" will result in this assembly
output:

;main function

sub rsp, 8
xor eax, eax
callf
cmp rax, 0FFE8h
jz  short loc_26

loc_21: 
add rsp, 8
retn
; ---

loc_26: 
pop rdx
mov edi, offset format ; "What?"
xor eax, eax

loc_2E: 
jmp printf

;main function end

Keeping the printf branch which at least for me is amazing.

[Bug fortran/71412] iso_c_bindings and optimization interaction bug

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-15
 Ever confirmed|0   |1

--- Comment #12 from Dominique d'Humieres  ---
Duplicate of pr71544?

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-15
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr71412?

Present from 4.8 up to trunk (7.0).

A workaround is to compile the test at -O1 with -finline-small-functions
(turned on by -O2 and above).

Note that compiling the test with all the documented optimization turned on by
-O1, e.g.,

 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim
-fcprop-registers -fdce -fdefer-pop -fdse -fforward-propagate
-fguess-branch-probability -fif-conversion2 -fif-conversion
-finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference
-fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap
-fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp
-ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop
-ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time
-fomit-frame-pointer -fstrict-aliasing

gives the expected result. So the problem occurs for either an undocumented
option or an optimization not controlled by an option.

[Bug fortran/71544] New: gfortran compiler optimization bug when dealing with c-style pointers

[fortranbug at gmail dot com]

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

Bug ID: 71544
   Summary: gfortran compiler optimization bug when dealing with
c-style pointers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fortranbug at gmail dot com
  Target Milestone: ---

The code below produces different results with gfortran with -O1 as
compared with -O0, -O2, and -O3. We've tested this with gfortran
versions 4.8, 4.9, 5.2 and 5.3 and seen the same behavior in all
cases.  An even older version, 4.4.7 shipped with CentOS 6, works
as expected for all optimization levels.

A local pointer "a" in subroutine init() is used to allocate memory
and its location is stored in a c-pointer "cptr", which is saved
in a module.  An assignment "a=100" at the end of the init() routine
is apparently removed by the -O1 optimizer as dead code, but kept for
-O0, -O2 and -O3.   When it works (-O0, -O2, -O3), the initialization takes
effect and the program prints “100" in its second line.  When it doesn't (-O1),
it prints 0.

We discussed this behavior on comp.lang.fortran
   https://groups.google.com/forum/#!topic/comp.lang.fortran/wyMy8PqeVxA
and the consensus was that this is indeed an optimization bug.  The
bottom line is that there does not appear to be any reason in the
standard to expect that the data pointed to by ‘a' would become invalid
at the end of init(), and the compiler should detect that the call
to save_cptr() _can_ be creating an alias (and in fact it is), and
not treat the "a = 100" statement as dead code to be eliminated.
The specific parts of the standard that support this interpretation
are best summarized in Richard Maine's Jun 11 post in the
aforementioned  comp.lang.fortran thread.

---

module store_cptr
use, intrinsic :: iso_c_binding
implicit none
public
type(c_ptr), save :: cptr
end module store_cptr

subroutine init()
use, intrinsic :: iso_c_binding
implicit none
integer(c_int), pointer :: a
allocate(a)
call save_cptr(c_loc(a))
a = 100
end subroutine init

subroutine save_cptr(cptr_in)
use store_cptr
implicit none
type(c_ptr), intent(in) :: cptr_in
cptr = cptr_in
end subroutine save_cptr

program init_fails
use store_cptr
implicit none
integer(c_int), pointer :: val
call init()
call c_f_pointer(cptr,val)
print *,'The following line should print 100'
print *,val
end program init_fails

---

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[denisc at gcc dot gnu.org]

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

--- Comment #3 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Wed Jun 15 16:43:35 2016
New Revision: 237487

URL: https://gcc.gnu.org/viewcvs?rev=237487=gcc=rev
Log:
Correct Changelog entry:
PR target/67353
* config/avr/avr.c (avr_set_current_function): Warn misspelled
interrupt/ signal handler if -Wmisspelled-isr flag is enabled.
* config/avr/avr.opt (Wmisspelled-isr): New warning flag. Enabled
by default to warn misspelled interrupt/ signal handler.
* doc/invoke.texi (AVR Options): Document it. Update description
for -nodevicelib option.


Modified:
trunk/gcc/ChangeLog

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[denisc at gcc dot gnu.org]

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

--- Comment #2 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Wed Jun 15 16:40:07 2016
New Revision: 237486

URL: https://gcc.gnu.org/viewcvs?rev=237486=gcc=rev
Log:
PR target/67353
* config/avr/avr.c (avr_set_current_function): Warn misspelled
interrupt/ signal handler if -Wmisspelled-isr flag is enabled.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.opt
trunk/gcc/doc/invoke.texi

[Bug tree-optimization/71438] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (by tree vectorizer)

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from alahay01 at gcc dot gnu.org ---
Same issue as PR71439, which is now fixed.

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

[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #5 from alahay01 at gcc dot gnu.org ---
*** Bug 71438 has been marked as a duplicate of this bug. ***

[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jun 15 15:49:40 2016
New Revision: 237484

URL: https://gcc.gnu.org/viewcvs?rev=237484=gcc=rev
Log:
gcc/

PR middle-end/71529
* ipa-chkp.c (chkp_build_instrumented_fndecl): Fix
DECL_CONTEXT for copied arguments.

gcc/testsuite/

PR middle-end/71529
* gcc.target/i386/pr71529.C: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-chkp.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71483] [7 Regression] g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from alahay01 at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/71483] [7 Regression] g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”

[alahay01 at gcc dot gnu.org]

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Wed Jun 15 15:45:47 2016
New Revision: 237483

URL: https://gcc.gnu.org/viewcvs?rev=237483=gcc=rev
Log:
2016-06-15  Alan Hayward  

gcc/
PR tree-optimization/71483
* tree-vect-loop.c (vectorizable_live_operation): Pick correct index
for slp

testsuite/
PR tree-optimization/71483
* g++.dg/vect/pr71483.c: New


Added:
trunk/gcc/testsuite/g++.dg/vect/pr71483.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[mikpelinux at gmail dot com]

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

--- Comment #10 from Mikael Pettersson  ---
(In reply to Eric Botcazou from comment #9)
> > Created attachment 38699 [details]
> > Tentative fix.
> 
> It successfully passed a full bootstrap/test cycle on SPARC/Solaris.

I can test it on SPARC/Linux on Friday.

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #7 from Paolo Carlini  ---
Should be fixed again, in a much better way.

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 15 15:23:40 2016
New Revision: 237482

URL: https://gcc.gnu.org/viewcvs?rev=237482=gcc=rev
Log:
/cp
2016-06-15  Paolo Carlini  

PR c++/70202
* decl.c (xref_basetypes): Revert r117839 changes; add fix-up
code at the end of the for loop; also revert r159637 changes,
add back the gcc_assert.
* cp-tree.h (xref_basetypes): Adjust declaration.
* parser.c (cp_parser_class_head): Adjust xref_basetypes call.

/testsuite
2016-06-15  Paolo Carlini  

PR c++/70202
* g++.dg/inherit/crash6.C: New.
* g++.dg/inherit/union2.C: Likewise.
* g++.dg/inherit/virtual12.C: Likewise.
* g++.dg/inherit/virtual13.C: Likewise.
* g++.dg/inherit/virtual1.C: Tweak dg-* tests.

Added:
trunk/gcc/testsuite/g++.dg/inherit/crash6.C
trunk/gcc/testsuite/g++.dg/inherit/union2.C
trunk/gcc/testsuite/g++.dg/inherit/virtual12.C
trunk/gcc/testsuite/g++.dg/inherit/virtual13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/inherit/virtual1.C

[Bug c++/71543] New: [concepts] ICE on ill-formed declaration of a parameter with a constrained-type-specifier in a requires expression

[tom at honermann dot net]

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

Bug ID: 71543
   Summary: [concepts] ICE on ill-formed declaration of a
parameter with a constrained-type-specifier in a
requires expression
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed code triggers an ICE in gcc trunk r236947.  The code
is ill-formed because constrained-type-specifiers are not permitted to declare
parameters in requires expressions.

$ cat t.cpp
template
concept bool C1 = true;
template
concept bool C2 = requires(C1 c1) {};

$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236947
Node Kind: directory
Schedule: normal
Last Changed Author: jason
Last Changed Rev: 236947
Last Changed Date: 2016-05-31 15:49:22 -0400 (Tue, 31 May 2016)

$ gcc --version
gcc (GCC) 7.0.0 20160531 (experimental)
...

$ g++ -c -std=c++1z -fconcepts t.cpp 
t.cpp:4:28: internal compiler error: in synthesize_implicit_template_parm, at
cp/parser.c:37843
 concept bool C2 = requires(C1 c1) {};
^~
0x753793 synthesize_implicit_template_parm
../../gcc-trunk/gcc/cp/parser.c:37843
0x7539cc cp_parser_maybe_constrained_type_specifier
../../gcc-trunk/gcc/cp/parser.c:16463
0x753af8 cp_parser_nonclass_name
../../gcc-trunk/gcc/cp/parser.c:16541
0x761d41 cp_parser_type_name
../../gcc-trunk/gcc/cp/parser.c:16347
0x761d41 cp_parser_simple_type_specifier
../../gcc-trunk/gcc/cp/parser.c:16261
0x75dbdd cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:15914
0x773494 cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:12758
0x775159 cp_parser_parameter_declaration
../../gcc-trunk/gcc/cp/parser.c:20448
0x7759a4 cp_parser_parameter_declaration_list
../../gcc-trunk/gcc/cp/parser.c:20263
0x775e44 cp_parser_parameter_declaration_clause
../../gcc-trunk/gcc/cp/parser.c:20184
0x7592db cp_parser_requirement_parameter_list
../../gcc-trunk/gcc/cp/parser.c:24391
0x7592db cp_parser_requires_expression
../../gcc-trunk/gcc/cp/parser.c:24362
0x7592db cp_parser_primary_expression
../../gcc-trunk/gcc/cp/parser.c:5098
0x762775 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6688
0x760b5c cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7986
0x76ad47 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8663
0x76b333 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8764
0x76bc24 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9051
0x76c06a cp_parser_constant_expression
../../gcc-trunk/gcc/cp/parser.c:9321
0x76c8c4 cp_parser_initializer_clause
../../gcc-trunk/gcc/cp/parser.c:20837
...

[Bug lto/71536] lto1 ICE: func-static constant in openmp offloaded function

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
The ICE triggers when the static variable is optimized out. This passes:

#pragma omp declare target
void foo ()
{
  static int __attribute__((used)) v;
}
#pragma omp end declare target

int main()
{
  #pragma omp target
  foo();
}

With s/used/unused/ it ICEs.

[Bug rtl-optimization/71532] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug lto/71535] ICE in LTO1 with -fopenmp offloading

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #1 from Alexander Monakov  ---
I wonder if the testcase has invalid code. On one hand, without "omp declare
target" on 'Process', the compiler does not need to emit accel code for it, so
it would fail to link at mkoffload/link time. On the other hand, the intention
seems to be to allow code with references to standard functions (at least
libm/libc), even though those functions don't have "omp declare target" on
their external declarations. And, it doesn't look like that the OpenMP 4.5 spec
explicitly makes this invalid. For variables, 2.10.4 mentions that "A variable
referenced in a target region but not the target construct that is not declared
in the target region must appear in a declare target directive."

In any case, the compiler should fail more gracefully than ICE.

Minimal testcase is just

void foo ()
{
  asm ("");
}

int main ()
{
#pragma omp target
  foo ();
}

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> Created attachment 38699 [details]
> Tentative fix.

It successfully passed a full bootstrap/test cycle on SPARC/Solaris.

[Bug rtl-optimization/71532] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Simpler testcase:
int foo (int, int, int, int, int, int, int, int, int, int)
__attribute__((pure));
int bar (int, int, int, int, int, int, int, int, int, int)
__attribute__((pure));

int
test (void)
{
  int a = foo (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
  a += bar (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
  return a;
}

The question is if const/pure function can clobber the argument slots in which
the arguments are passed to it.
CSE doesn't invalidate those, so with -O2 -march=corei7 -mtune=slm we get all
the arguments written to the stack just once, not twice.

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 15 Jun 2016, ienkovich at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
> 
> --- Comment #9 from Ilya Enkovich  ---
> Created attachment 38704
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38704=edit
> Enable masks comparison with no new patterns
> 
> Here is a version without additional patterns (mask conversion pattern is
> slightly extended).  It appeared to be smaller than I thought.

I like this more.  Please also adjust the cost accordingly.
I suppose by passing
 (1 + bitop1 != NOP_EXPR + bitop2 != NOP_EXPR) * ncopies
to vect_model_simple_cost.

Thanks,
Richard.

[Bug tree-optimization/71403] [7 Regression] wrong code (segfault) at -O3 on x86_64-linux-gnu

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Wed, 15 Jun 2016, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
> 
> Jan Hubicka  changed:
> 
>What|Removed |Added
> 
>  CC||rguenther at suse dot de
> 
> --- Comment #10 from Jan Hubicka  ---
> 
> > What I don't see is any reasonable API for invaliding the saved iteration
> > data.  It appears to be attached to the loop with no way to update it.
> 
> Updating is usually done by hand because it depends on particular loop
> transform you make.  See unrollin/vectorizing/peeling code and search for
> any_upper_bound.
> 
> Here you fuse two loops and I think the reasonable thing is to claim that
> original loops no longer exists i.e. remove it and let loop fixup code to
> discover the new loop.  This is Richard's area, so he may have different
> preferences. Obviously the two estimates can be merged, because the loop
> iterates at most inner_upper_bound*outer_upper_bound times..

Re-discovering the loop should be done only as a last resort.  It does
for example lose the fact that you might have specified #pragma ivdep
on the outer one.  Or the simduid for OMP simd loops.

So it's an interesting one at least ;)

But I can't see how you really can "merge" the loops via threading
as threading doesn't adjust IVs so there will be two loops remaining.

I'd have to have a closer look on the testcase (before the fix I guess)
but I'm leaving for vacation really soon.

[Bug c++/71542] unhelpfull error for wrong initializer of initializer list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-15
 Ever confirmed|0   |1

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ienkovich at gcc dot gnu.org]

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

--- Comment #9 from Ilya Enkovich  ---
Created attachment 38704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38704=edit
Enable masks comparison with no new patterns

Here is a version without additional patterns (mask conversion pattern is
slightly extended).  It appeared to be smaller than I thought.

[Bug tree-optimization/71403] [7 Regression] wrong code (segfault) at -O3 on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #10 from Jan Hubicka  ---

> What I don't see is any reasonable API for invaliding the saved iteration
> data.  It appears to be attached to the loop with no way to update it.

Updating is usually done by hand because it depends on particular loop
transform you make.  See unrollin/vectorizing/peeling code and search for
any_upper_bound.

Here you fuse two loops and I think the reasonable thing is to claim that
original loops no longer exists i.e. remove it and let loop fixup code to
discover the new loop.  This is Richard's area, so he may have different
preferences. Obviously the two estimates can be merged, because the loop
iterates at most inner_upper_bound*outer_upper_bound times..

Honza

[Bug c++/71542] New: unhelpfull error for wrong initializer of initializer list

[denis.campredon at gmail dot com]

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

Bug ID: 71542
   Summary: unhelpfull error for wrong initializer of initializer
list
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

For the following code


#include 

struct s
{
int *i;
};
void f()
{   
std::initializer_list initializer = {{false}};
s array[] = {{true}, {true}};
}
---

g++ emits the following error message :
---
main.cpp: In function 'void f()':
main.cpp:10:42: error: could not convert '{{false}}' from '' to 'std::initializer_list'
 std::initializer_list a = {{false}};
  ^
main.cpp:11:32: error: cannot convert 'bool' to 'int*' in initialization
 s array[] = {{true}, {true}};
^
main.cpp:11:32: error: cannot convert 'bool' to 'int*' in initialization
--

But the message for the initializer_list is not really helpfull. I'd expect a
similar message than with the array.

[Bug c/71538] Obvious optimization related to arrays aren't performed.

[sasho648 at gmail dot com]

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

--- Comment #3 from sasho648 at gmail dot com ---
But if it's NULL for the cast it'll invoke UB I believe. Shouldn't the
optimizer assume that UB never occur?

[Bug c++/71541] destructor of condition_variable_any crashes with static linkage

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
You need to link to libpthread to use std::condition_variable_any.

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ienkovich at gcc dot gnu.org]

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

--- Comment #8 from Ilya Enkovich  ---
Created attachment 38703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38703=edit
Enable masks comparison using patterns

(In reply to rguent...@suse.de from comment #7)
>
> Sounds reasonable though less patterns are IMHO better (patterns should
> be only used when combining N > 1 scalar stmts to M >= 1 new scalar stmts,
> single scalar stmts can be handled in complex ways in the vectorizable_*
> functions).

This can be handled in vectorizable_comparison but it would make it much more
complex and in fact it would mean a copy of a part of vectorizable_operation
into vectorizable_comparison.

I attach a pattern variant.  I can also prepare vectorizable_comparison
enhancement variant to compare and choose.

[Bug c++/71541] destructor of condition_variable_any crashes with static linkage

[gcc_bugzilla at haphi dot de]

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

--- Comment #2 from gcc_bugzilla at haphi dot de ---
Created attachment 38702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38702=edit
preprocessed file of trivial repro case

[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from alahay01 at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu

[alahay01 at gcc dot gnu.org]

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Wed Jun 15 10:53:01 2016
New Revision: 237476

URL: https://gcc.gnu.org/viewcvs?rev=237476=gcc=rev
Log:
2016-06-15  Alan Hayward  

gcc/
PR tree-optimization/71439
* tree-vect-loop.c (vect_analyze_loop_operations): Additional check for
live PHIs.

testsuite/
PR tree-optimization/71439
* gcc.dg/vect/pr71439.c: New


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr71439.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug c++/71541] destructor of condition_variable_any crashes with static linkage

[gcc_bugzilla at haphi dot de]

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

--- Comment #1 from gcc_bugzilla at haphi dot de ---
compiled with:
> gcc -static -o trivial_repro_case trivial_repro_case.cpp
> ./trivial_repro_case
> Segmentation fault (core dumped)

output of gcc -v:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
> 5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
> --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-5 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi 
> --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx 
> --enable-plugin --with-system-zlib --disable-browser-plugin 
> --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
> --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04)

[Bug c++/71541] New: destructor of condition_variable_any crashes with static linkage

[gcc_bugzilla at haphi dot de]

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

Bug ID: 71541
   Summary: destructor of condition_variable_any crashes with
static linkage
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc_bugzilla at haphi dot de
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 38701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38701=edit
trivial repro case

The attached trivial test program crashes on several linux 64bit systems when
linked with "-static", or "-static-libgcc -static-libstdc++".

The problem also occurs with gcc 5.3.0.

The problem does not occur on a raspberry pi with gcc 6.1.1
(armv7l-unknown-linux-gnueabihf).

[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 7

[Bug rtl-optimization/71532] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/71531] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/71533] -fdump-tree-fre1 hangs while printing an unnormal long double

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-15
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We hang in real_to_decimal_for_mode.

[Bug libgcc/71540] Issue to building gcc-4.8.3 on ppc64le-redhat-linux platform

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

[Bug c/71538] Obvious optimization related to arrays aren't performed.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I don't think the C standard says that p cannot be a NULL pointer for this
cast.

[Bug libgcc/71540] Issue to building gcc-4.8.3 on ppc64le-redhat-linux platform

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
GCC 4.8 is no longer supported, I suggest to go to redhat bugzilla.

[Bug libgcc/71540] New: Issue to building gcc-4.8.3 on ppc64le-redhat-linux platform

[nirajkumarpandey at gmail dot com]

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

Bug ID: 71540
   Summary: Issue to building gcc-4.8.3 on ppc64le-redhat-linux
platform
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nirajkumarpandey at gmail dot com
  Target Milestone: ---

Hi , 

I am getting the following error while building gcc-4.8.3 on
ppc64le-redhat-linux platform.

checking for ppc64le-redhat-linux-gcc... /tmp/1/gcc-build/./gcc/xgcc
-B/tmp/1/gcc-build/./gcc/ -B/tmp/gcc-new/ppc64le-redhat-linux/bin/
-B/tmp/gcc-new/ppc64le-redhat-linux/lib/ -isystem
/tmp/gcc-new/ppc64le-redhat-linux/include -isystem
/tmp/gcc-new/ppc64le-redhat-linux/sys-include
checking for suffix of object files... configure: error: in
`/tmp/1/gcc-build/ppc64le-redhat-linux/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/tmp/1/gcc-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/tmp/1/gcc-build'
make: *** [all] Error 2

/tmp/1/gcc-build/ppc64le-redhat-linux/libgcc/config.log says:

configure:3374: /tmp/1/gcc-build/./gcc/xgcc -B/tmp/1/gcc-build/./gcc/
-B/tmp/gcc-new/ppc64le-redhat-linux/bin/
-B/tmp/gcc-new/ppc64le-redhat-linux/lib/ -isystem
/tmp/gcc-new/ppc64le-redhat-linux/include -isystem
/tmp/gcc-new/ppc64le-redhat-linux/sys-include-o conftest -g -O2  
conftest.c  >&5
In file included from :0:0:
/usr/include/stdc-predef.h:1:0: internal compiler error: Aborted
 /* Copyright (C) 1991-2012 Free Software Foundation, Inc.
 ^
0x10785c17 crash_signal
../../gcc-4.8.3/gcc/toplev.c:332
0x10f8c74b _cpp_process_line_notes
../../gcc-4.8.3/libcpp/lex.c:956
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
configure:3377: $? = 1


I have using the following options while running configure:

../gcc-4.8.3/configure --prefix=/tmp/gcc-new --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++
--enable-plugin --enable-initfini-array --disable-libgcj
--enable-gnu-indirect-function --enable-secureplt --with-long-double-128
--enable-targets=powerpcle-linux --disable-multilib --with-cpu-64=power7
--with-tune-64=power8 --build=ppc64le-redhat-linux


Can someone please help me to fix this. 

Thanks in advance.

Reagrds
Niraj

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Tue, 14 Jun 2016, segher at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
> 
> --- Comment #2 from Segher Boessenkool  ---
> (In reply to Richard Biener from comment #1)
> > It looks like we didn't adjust the bitfield read paths for the mem model
> > because in practice it doesn't matter and it may generate larger/slower code
> > not to do loads in larger types on some archs.
> 
> It still generates correct (or at least working) code, yeah.
> 
> > Note that we conservatively compute the extent for
> > DECL_BIT_FIELD_REPRESENTATIVE
> > by prefering smaller modes.  There's some ??? in
> > finish_bitfield_representative
> > and the above remark about tail padding re-use is only implemented via
> > prefering
> > smaller modes.  Thus when adding a 'long foo' after csum_level the
> > representative doesn't change to 64bit width but stays at 8bits (both are
> > valid from the C++ memory model).
> 
> Smaller modes are slightly better here, they allow more efficient insn
> sequences to manipulate the data, esp. on big endian.  For example on
> PowerPC, on BE, our 16-bit immediates (in e.g. ior) can handle QImode
> and HImode, but not DImode; and e.g. the rlwinm insn can handle SImode
> but not DImode.  In general, with smaller modes you do not need to
> worry about preserving the other bits.
> 
> > Note that the proposed simple lowering of bitfield accesses on GIMPLE would
> > do accesses of DECL_BIT_FIELD_REPRESENTATIVE and thus in this case use byte
> > accesses.
> 
> That would be lovely :-)

On my list for GCC 7 ;-)

> > I suppose we want to be less conservative about 
> > DECL_BIT_FIELD_REPRESENTATIVE
> > and leave it up to the target how to do the actual accesses.
> 
> Maybe.  Always smallest is a good choice for PowerPC at least.

Note the middle-end in extract_bit_field says using a larger mode is
always better because it is better for CSE (not sure about that argument
if you only look at a single stmt).

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 14 Jun 2016, ienkovich at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
> 
> --- Comment #6 from Ilya Enkovich  ---
> I think we should disable vectorization of boolean comparison (except '==' and
> '!=') and handle them applying patterns.  E.g. a > b ==> a & !b, a >= b ==> a 
> |
> !b etc.  Bitwise operations are better because work for both vector and scalar
> masks.

Sounds reasonable though less patterns are IMHO better (patterns should
be only used when combining N > 1 scalar stmts to M >= 1 new scalar stmts,
single scalar stmts can be handled in complex ways in the vectorizable_*
functions).

[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes

[ch3root at openwall dot com]

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

--- Comment #9 from Alexander Cherepanov  ---
On 2016-06-12 00:59, joseph at codesourcery dot com wrote:
>> Ok, what about this:
>
> This bug is closed as INVALID.  No-one will pay any attention to comments
> on a closed bug proposing different examples that might or might not be
> valid and might or might not be related.  Different examples should go in
> different bugs; such bugs can be closed as duplicates if necessary.

I see, thanks for the explanation! I filed 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71522 . Indeed, it's better 
to treat it as a separate issue.

OTOH this PR could be used as an reference about trap representation in 
long double.

[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes

[ch3root at openwall dot com]

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

--- Comment #8 from Alexander Cherepanov  ---
Here is a more clear illustration that gcc treats this representation as 
a trap representation. The previous example could be explained by this 
representation being an alternative representation for some value and 
glibc treating it differently from gcc. Now the influence of libc is 
eliminated. The only place where long double values appear is the == 
operator which is implemented by gcc.

For ordinary values (and given that d1 and d2 are not pointers:-) we have:
d1 and d2 have the same representation and the result of the == operator 
is well-defined and should be the same for both variables.

Relevant rules:
C11, 6.2.6.1p4: "Two values (other than NaNs) with the same object 
representation compare equal"
C11, 6.5.9p3: "For any pair of operands, exactly one of the relations is 
true."

But we see that the results for d1 and d2 differ and depend on the 
optimizations level. Thus, yes, this is a trap representation in gcc.

The same is true for clang.

Source code:

--
#include 
#include 

int main()
{
   long double d1, d2;

   memset(, 'A', sizeof d1);
   memcpy(, "", sizeof d2);

   printf("%d %d\n", d1 == d1, d2 == d2);
}
--

gcc (GCC) 7.0.0 20160614 (experimental):

--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
0 0

$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
0 1
--

clang version 3.9.0 (trunk 271312):

--
$ clang -std=c11 -Weverything test.c && ./a.out
0 0

$ clang -std=c11 -Weverything -O3 test.c && ./a.out
1 0
--