[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #8 from Michael Karcher  ---
The patch looks like it should work fine, I guess John Paul Adrian Glaubitz is
going to test it soon. But I wonder whether the determination of alignment is
in types.cc really needed, as user-specified alignment directives can only make
alignment stricter. So always passing 4 to implicit variable should do no harm
and keep the code simpler.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Can someone with m68k hardware please test the patch at
https://golang.org/cl/35478?  Thanks.  (To download just the patch as a zip
file: https://go-review.googlesource.com/changes/35478/revisions/1/patch?zip).

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||diagnostic
   Last reconfirmed||2017-01-20
  Component|c++ |tree-optimization
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  r235817 is the first revision that issues the warning.  Changing
finalDigits to take n by value eliminates the warning,

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
I don't think it's the type descriptors that need to be aligned, I think it's
just the GC symbol pointers.  Those are the ones whose names end in "$gc" in
the list above.

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.

[Bug libstdc++/72793] pointer_traits is too strict about rebinding

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Jonathan Wakely  ---
Fixed for gcc 7.

[Bug libstdc++/72792] allocator_traits is too strict about rebinding

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Jonathan Wakely  ---
Fixed for gcc 7.

[Bug libstdc++/72792] allocator_traits is too strict about rebinding

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 20 02:36:16 2017
New Revision: 244680

URL: https://gcc.gnu.org/viewcvs?rev=244680&root=gcc&view=rev
Log:
PR72792 PR72793 relax requirements on rebind members

PR libstdc++/72792
PR libstdc++/72793
* include/bits/alloc_traits.h (__allocator_traits_base::__rebind):
Replace with class template using void_t.
(__alloc_rebind): Define in terms of
__allocator_traits_base::__rebind.
(allocator_traits): Remove unconditional static_assert for
rebind_alloc.
* include/bits/ptr_traits.h (__replace_first_arg): Remove type member.
(pointer_traits::__rebind): Replace with class template using void_t.
(pointer_traits::rebind): Define in terms of __rebind.
(pointer_traits): Remove unconditional static_assert for rebind.
* testsuite/20_util/allocator_traits/members/rebind_alloc.cc: New test.
* testsuite/20_util/pointer_traits/rebind.cc: New test.

Added:
   
trunk/libstdc++-v3/testsuite/20_util/allocator_traits/members/rebind_alloc.cc
trunk/libstdc++-v3/testsuite/20_util/pointer_traits/rebind.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/alloc_traits.h
trunk/libstdc++-v3/include/bits/ptr_traits.h

[Bug libstdc++/72793] pointer_traits is too strict about rebinding

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 20 02:36:16 2017
New Revision: 244680

URL: https://gcc.gnu.org/viewcvs?rev=244680&root=gcc&view=rev
Log:
PR72792 PR72793 relax requirements on rebind members

PR libstdc++/72792
PR libstdc++/72793
* include/bits/alloc_traits.h (__allocator_traits_base::__rebind):
Replace with class template using void_t.
(__alloc_rebind): Define in terms of
__allocator_traits_base::__rebind.
(allocator_traits): Remove unconditional static_assert for
rebind_alloc.
* include/bits/ptr_traits.h (__replace_first_arg): Remove type member.
(pointer_traits::__rebind): Replace with class template using void_t.
(pointer_traits::rebind): Define in terms of __rebind.
(pointer_traits): Remove unconditional static_assert for rebind.
* testsuite/20_util/allocator_traits/members/rebind_alloc.cc: New test.
* testsuite/20_util/pointer_traits/rebind.cc: New test.

Added:
   
trunk/libstdc++-v3/testsuite/20_util/allocator_traits/members/rebind_alloc.cc
trunk/libstdc++-v3/testsuite/20_util/pointer_traits/rebind.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/alloc_traits.h
trunk/libstdc++-v3/include/bits/ptr_traits.h

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Jan 20 02:27:46 2017
New Revision: 244679

URL: https://gcc.gnu.org/viewcvs?rev=244679&root=gcc&view=rev
Log:
PR go/79146
crypto/elliptic: explicitly ignore p256_s390x.go

The file only works if used in conjunction with assembly code not
(yet) written for gccgo.

Fixes GCC PR 79146.

Reviewed-on: https://go-review.googlesource.com/35477

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/crypto/elliptic/p256_s390x.go

[Bug c++/79091] [7 regression] ICE in write_unnamed_type

[s...@li-snyder.org]

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

--- Comment #7 from scott snyder  ---
Confirmed that this fixes the original problem from which the test case
was derived.  Thanks!

[Bug libstdc++/69321] Error on use of non-copyable type with any_cast

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Jonathan Wakely  ---
Fixed for gcc 7.

[Bug target/79140] gcc.target/powerpc/ssp-1.c fails starting with its introduction in r244562

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Fri Jan 20 01:22:27 2017
New Revision: 244677

URL: https://gcc.gnu.org/viewcvs?rev=244677&root=gcc&view=rev
Log:
rs6000: Fix the new SSP guard configuration code (PR79140)

I foolishly tested this with r241087 reverted.  After that revision
default_stack_protect_guard is no longer called if the compiler defaults
to using the TLS guard, which of course is the wrong thing to do if
there is some other way to enable the global guard.

This fixes it.


PR target/78875
PR target/79140
* config/rs6000/rs6000.c (TARGET_STACK_PROTECT_GUARD): Unconditionally
define to rs6000_init_stack_protect_guard.
(rs6000_init_stack_protect_guard): New function.

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

[Bug libstdc++/69321] Error on use of non-copyable type with any_cast

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 20 01:22:54 2017
New Revision: 244678

URL: https://gcc.gnu.org/viewcvs?rev=244678&root=gcc&view=rev
Log:
PR69321 fix any_cast(any*) for non-copyable T

PR libstdc++/69321
* include/experimental/any (__any_caster): Avoid instantiating
manager function for types that can't be stored in any.
* include/std/any (__any_caster): Likewise.
* testsuite/20_util/any/misc/any_cast.cc: Test non-copyable type.
* testsuite/experimental/any/misc/any_cast.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/any
trunk/libstdc++-v3/include/std/any
trunk/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
trunk/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Author: segher
Date: Fri Jan 20 01:22:27 2017
New Revision: 244677

URL: https://gcc.gnu.org/viewcvs?rev=244677&root=gcc&view=rev
Log:
rs6000: Fix the new SSP guard configuration code (PR79140)

I foolishly tested this with r241087 reverted.  After that revision
default_stack_protect_guard is no longer called if the compiler defaults
to using the TLS guard, which of course is the wrong thing to do if
there is some other way to enable the global guard.

This fixes it.


PR target/78875
PR target/79140
* config/rs6000/rs6000.c (TARGET_STACK_PROTECT_GUARD): Unconditionally
define to rs6000_init_stack_protect_guard.
(rs6000_init_stack_protect_guard): New function.

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

[Bug c++/59960] accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1 and t2 have different template types

[martindorey at gmail dot com]

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

Martin Dorey  changed:

   What|Removed |Added

 CC||martindorey at gmail dot com

--- Comment #1 from Martin Dorey  ---
This is still reproducible in gcc-7.  This is much like one of the (simpler)
test cases in:

Bug #79009 - Missing 'inconsistent deduction for ‘auto’' error when having a
dependent initializer and a nondependent one in the same declaration

... in which the OP explains the reason for this bug.

[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[martindorey at gmail dot com]

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

Martin Dorey  changed:

   What|Removed |Added

 CC||martindorey at gmail dot com

--- Comment #1 from Martin Dorey  ---
In my testing today, gcc 4.7.2, gcc 6.2.1 and Debian experimental's gcc 7.0.0
20161230, among other versions, reject the one-argument foo and bar
instantiations from the OP's testcase, as I think they should.  They accept the
two-argument foo, I think incorrectly, an accepts-invalid bug.  (clang rejects
all three.)  But the Subject line's use of "nondependent" suggests the OP is
reporting an accepts-invalid error on the one-argument instantiations.  Could
it be that's a regression between 20161230 and 2017-01-05?  I don't feel the
two-argument foo - the bug I can reproduce - is covered by the Subject line. 
That's OK, as:

Bug #59960 - accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1 and t2 have
different template types

... looks to have reported much the same thing, some three years earlier.  It's
unloved by any cc:s and, unlike this PR, has no Depends-on.

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 20 00:33:25 2017
New Revision: 244675

URL: https://gcc.gnu.org/viewcvs?rev=244675&root=gcc&view=rev
Log:
PR64903 simplify last fix to std::is_partitioned

PR libstdc++/64903
* include/bits/stl_algo.h (is_partitioned): Use increment instead of
std::advance.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h

[Bug libstdc++/54043] [LWG 2221] cout << nullptr does not work

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
The result is supposed to be a null-terminated string, so we could do what
glibc's printf does for null pointers and print "(nil)" but we'd have to widen
the string to the stream's char_type. Alternatively we could just print '0'.

Either way we probably need to define the function for C++11 or compile the
src/c++11/ostream-inst.cc file as C++17 so that the explicit instantiation
definition includes the new member function.

[Bug target/79127] [7 Regression] Error: invalid register for .seh_savexmm in matmul_i4.c

[ian_harvey at bigpond dot com]

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

Ian Harvey  changed:

   What|Removed |Added

 CC||ian_harvey at bigpond dot com

--- Comment #15 from Ian Harvey  ---
See also pr65782.

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |RESOLVED
Version|unknown |7.0
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #3 from Jonathan Wakely  ---
It is meant to return __p, so I fixed the return type. There was also a friend
declaration missing.

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 20 00:07:14 2017
New Revision: 244668

URL: https://gcc.gnu.org/viewcvs?rev=244668&root=gcc&view=rev
Log:
PR79156 fix std::__enable_shared_from_this extension

PR libstdc++/79156
* include/bits/shared_ptr_base.h (__enable_shared_from_this_base):
Fix return type.
(__enable_shared_from_this): Declare __shared_ptr as a friend.
* testsuite/ext/shared_ptr/1.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/ext/shared_ptr/
trunk/libstdc++-v3/testsuite/ext/shared_ptr/1.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug target/79144] cmpstrnsi optimization breaks glibc

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #4 from Alan Modra  ---
Fixed

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Jonathan Wakely  ---
Fixed for gcc 7.

[Bug c++/64382] ICE due to use of `this` inside a lambda that captures everything by ref inside a member function of a class template

[abutcher at gcc dot gnu.org]

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

Adam Butcher  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|DUPLICATE   |---
   Target Milestone|--- |7.0

--- Comment #6 from Adam Butcher  ---
Reopened and unmarked as dup of 61636.  At the time the backtrace was the same
and I submitted a patch series solving both.  Since Nathan's fix for 61636 has
since been accepted and pushed, this one needs an additional change.

My original April 2015 patch still applies for this but I will resubmit to
gcc-patches against latest master.

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 23:30:18 2017
New Revision: 244661

URL: https://gcc.gnu.org/viewcvs?rev=244661&root=gcc&view=rev
Log:
PR64903 fix number of predicate tests in std::is_partitioned

PR libstdc++/64903
* include/bits/stl_algo.h (is_partioned): Don't retest the partition
point.
* testsuite/25_algorithms/is_partitioned/2.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/is_partitioned/2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #9 from Tony Kelman  ---
How can we help get this moving towards resolution? This has kept us stuck on
GCC 4.9, which is getting increasingly problematic. We can attempt to reduce
this to "minimal working piece of opt.exe with gcc 4.9" vs "broken equivalent
piece with gcc 5+," but given the IPA nature of r217587 I'm not sure how that
will go.

[Bug target/79144] cmpstrnsi optimization breaks glibc

[amodra at gcc dot gnu.org]

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

--- Comment #3 from Alan Modra  ---
Author: amodra
Date: Thu Jan 19 23:19:19 2017
New Revision: 244659

URL: https://gcc.gnu.org/viewcvs?rev=244659&root=gcc&view=rev
Log:
[RS6000] PR79144, cmpstrnsi optimization breaks glibc

glibc compiled with current gcc-7 fails one test due to strcmp and
strncmp appearing in the PLT.  This is because the inline expansion of
those functions falls back to a function call, but doesn't use the asm
name for the call.

PR target/79144
* config/rs6000/rs6000.c (expand_strn_compare): Get the asm name
for strcmp and strncmp from corresponding builtin decl.

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

[Bug libstdc++/51965] Redundant move constructions in heap algorithms

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-24 00:00:00 |2017-1-19
   Target Milestone|--- |8.0

--- Comment #16 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #5)
> (The split into push_heap and __push_heap is just so the first part can be
> inlined without the second, right?)
> 
> A more direct adaptation of the old code to rvalue references would be:
> 
>   std::__push_heap(__first, _DistanceType((__last - __first) - 1),
>_DistanceType(0), _ValueType(_GLIBCXX_MOVE(*(__last -
> 1;

I tried doing this and it didn't seem to help the testcase attached here.

> Without the named temporary value, the compiler can perform copy elision.
> Aliaksandr's patch looks like a different way to achieve the same goal.

The patch doesn't apply cleanly, but I made the equivalent changes to the
latest code and found some regressions, so I'll revisit it for gcc 8.

> Note that the current code thus seems to have a performance regression in
> C++03 compared to before the introduction of moves.

Yes.

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 23:07:52 2017
New Revision: 244656

URL: https://gcc.gnu.org/viewcvs?rev=244656&root=gcc&view=rev
Log:
PR67085 pass comparison functions by reference in heap algorithms

PR libstdc++/67085
* include/bits/predefined_ops.h (_Iter_less_val, _Val_less_iter): Add
converting constructors from _Iter_less_iter.
(_Iter_comp_val, _Val_comp_iter): Add converting constructors from
_Iter_comp_iter.
(__iter_comp_val(_Iter_comp_iter): Use converting constructor.
(__val_comp_iter(_Iter_comp_iter): Likewise.
* include/bits/stl_heap.h (__is_heap_until, __push_heap, __pop_heap)
(__make_heap, __sort_heap): Change _Compare parameters to references.
(__is_heap, push_heap, __adjust_heap, __pop_heap, pop_heap)
(__make_heap, make_heap, sort_heap, is_heap_until): Pass comparison
functions as lvalues.
(is_heap): Call __is_heap_until directly to avoid copying __comp.
* testsuite/23_containers/priority_queue/67085.cc: Adjust test to
count copies during construction with empty sequence.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/predefined_ops.h
trunk/libstdc++-v3/include/bits/stl_heap.h
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #13 from Jonathan Wakely  ---
The total sum of copies + moves is now lower, so even types without move
semantics will benefit:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 1 + 2
After 3 calls to push: 4 + 8
After 3 calls to pop : 9 + 14

[Bug target/69992] test case gcc.dg/sms-4.c fails

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
At some point the doloop analysis must have changed and as a result declared
that the loop might run infinitely if compiled with -m64. This in turn causes
SMS to bail out and the test fails. The following patch fixes it on powerpc
-m64:

Index: gcc/testsuite/gcc.dg/sms-4.c
===
--- gcc/testsuite/gcc.dg/sms-4.c(revision 244540)
+++ gcc/testsuite/gcc.dg/sms-4.c(working copy)
@@ -12,9 +12,9 @@

 __attribute__ ((noinline))
 void
-foo (int size, int *ap, int *bp, int *cp, int *dstp)
+foo (long size, int *ap, int *bp, int *cp, int *dstp)
 {
-  unsigned int i, n = size;
+  unsigned long i, n = size;
   int changed = 0;

   for (i = 0; i < n; i++)

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #25 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #24)
> Would you mind applying this to the 6.x branch? That was where the issue was
> initially spotted.

Sure, but let's wait for a week if everything works OK in the master.

> I don't know what to do about this extra line in rtemself.h though. It was
> not present in the master 
> 
> #define IX86_NO_LIBGCC_TFMODE

Let's leave this, since i386-rtems doesn't implement TFmode soft-fp. Master
enables TFmode soft-fp for all x86 targets by default.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
The test has gone back to not failing anymore at some point:

https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01932.html

I don't know why.

[Bug target/79160] gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-unknown-linux-gnu
 CC||wschmidt at gcc dot gnu.org
   Host||powerpc64-unknown-linux-gnu
  Build||powerpc64-unknown-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
This was on a power8 system.

[Bug target/79160] New: gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE

[seurer at gcc dot gnu.org]

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

Bug ID: 79160
   Summary: gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make -k check-gcc RUNTESTFLAGS=powerpc.exp=vsx-elemrev-4.c

Using /home/seurer/gcc/gcc-trunk/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/powerpc.exp
...
FAIL: gcc.target/powerpc/vsx-elemrev-4.c scan-assembler-times lxvx 40
FAIL: gcc.target/powerpc/vsx-elemrev-4.c scan-assembler-times stxvx 40


Target: powerpc64-unknown-linux-gnu
Configured with: /home/seurer/gcc/gcc-trunk/configure
--prefix=/home/seurer/gcc/install/gcc-trunk --enable-languages=c,fortran,c++
--with-cpu=power8 --enable-multilib
--with-as=/home/seurer/binutils/install/binutils-2.26/bin/as
--with-ld=/home/seurer/binutils/install/binutils-2.26/bin/ld

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[dmalcolm at gcc dot gnu.org]

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

--- Comment #17 from David Malcolm  ---
Remaining XFAILs for this bug:
  c-c++-common/pr69558.c (C++ only)

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm  ---
(In reply to David Malcolm from comment #10)
> The lines in comment #9 came from 18f0e0e551a995687e1822aabb9b7d7ee8f11492
> aka r186971 (affecting gcc.dg/cpp/pragma-diagnostic-2.c)

This was:
  "[PATCH 07/11] Fix -Wuninitialized for -ftrack-macro-expansion"
  * "https://gcc.gnu.org/ml/gcc-patches/2012-04/msg00574.html'

as part of this kit:
  "Patches to enable -ftrack-macro-expansion by default"
* https://gcc.gnu.org/ml/gcc-patches/2012-04/msg00532.html

[Bug target/69992] test case gcc.dg/sms-4.c fails

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-19
 CC||acsawdey at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #24 from Joel Sherrill  ---
Would you mind applying this to the 6.x branch? That was where the issue was
initially spotted.

I don't know what to do about this extra line in rtemself.h though. It was not
present in the master 

#define IX86_NO_LIBGCC_TFMODE

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
The lines in comment #9 came from 18f0e0e551a995687e1822aabb9b7d7ee8f11492
aka r186971 (affecting gcc.dg/cpp/pragma-diagnostic-2.c)

[Bug target/78478] Compile Error for i386-rtems

[uros at gcc dot gnu.org]

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

--- Comment #23 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:38:44 2017
New Revision: 244653

URL: https://gcc.gnu.org/viewcvs?rev=244653&root=gcc&view=rev
Log:
PR target/78478
Revert:
2013-11-05  Uros Bizjak  

* config/i386/rtemself.h (LONG_DOUBLE_TYPE_SIZE): New define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/rtemself.h

[Bug c++/79159] New: [7 regression] spurious array-bounds warning

[s...@li-snyder.org]

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

Bug ID: 79159
   Summary: [7 regression] spurious array-bounds warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

hi -

gcc version 7.0.0 20170119 gives what appears to be a spurious warning
for this example when compiling with -O3 (tested on x86_64-pc-linux-gnu):


void foo(float tmpCorr[9][9]);
float bar;

void finalDigits(int& n)
{
  float tmpCorr[9][9] = {{0}};

  foo(tmpCorr);
  for (int i = 0; i < n; i++) {
for (int j = i+1; j < n; j++) {
  bar = tmpCorr[i][j];
}
  }
}



$ ~/gcc/build/gcc/cc1plus -quiet  -O3 -Wall x.cc
x.cc: In function ‘void finalDigits(int&)’:
x.cc:11:25: warning: array subscript is above array bounds [-Warray-bounds]
   bar = tmpCorr[i][j];
 ^

I do not see this warning with gcc 6.3.1.

This doesn't make sense, since there is no basis for making any assumptions
about the value of the iteration limit n.

The warning goes away if i remove the call to foo(), if function parameter
is changed to be passed by value rather than by reference, or if the lower
limit of the j iteration is changed to i rather than i+1.

[Bug target/79158] New: gcc.target/powerpc/pr70669.c fails on powerpc BE

[seurer at gcc dot gnu.org]

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

Bug ID: 79158
   Summary: gcc.target/powerpc/pr70669.c fails on powerpc BE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test case was added in r234995 where it failed for both BE and LE. 
Sometime later it was fixed for LE but still fails for BE.

Run on a powerpc8 BE system.

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr70669.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -O2 -mcpu=power8
-mfloat128 -ffat-lto-objects -S   -o pr70669.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr70669.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mcpu=power8
-mfloat128 -ffat-lto-objects -S -o pr70669.s
PASS: gcc.target/powerpc/pr70669.c (test for excess errors)
PASS: gcc.target/powerpc/pr70669.c scan-assembler mfvsrd
FAIL: gcc.target/powerpc/pr70669.c scan-assembler mtvsrd
FAIL: gcc.target/powerpc/pr70669.c scan-assembler-times stxvd2x 1
PASS: gcc.target/powerpc/pr70669.c scan-assembler-times lxvd2x 1

Configured with: /home/seurer/gcc/gcc-test2/configure
--prefix=/home/seurer/gcc/install/gcc-test2 --enable-languages=c,fortran,c++
--with-cpu=power8 --disable-bootstrap
--with-as=/home/seurer/binutils/install/binutils-2.26/bin/as
--with-ld=/home/seurer/binutils/install/binutils-2.26/bin/ld : (reconfigured)
/home/seurer/gcc/gcc-test2/configure
--prefix=/home/seurer/gcc/install/gcc-test2 --with-cpu=power8
--disable-bootstrap
--with-as=/home/seurer/binutils/install/binutils-2.26/bin/as
--with-ld=/home/seurer/binutils/install/binutils-2.26/bin/ld
CC=/home/seurer/gcc/install/gcc-5.4.0/bin/gcc
LDFLAGS=-L/home/seurer/gcc/install/gcc-5.4.0/lib64
CXX=/home/seurer/gcc/install/gcc-5.4.0/bin/g++
--enable-languages=c,c++,fortran,lto --no-create --no-recursion

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
(In reply to David Malcolm from comment #8)
> The following testcases still have xfails:
>   c-c++-common/pr69543-3.c
>   c-c++-common/pr69543-4.c
> so this isn't quite fixed yet.

These XFAILs are fixed (for both C and C++) by deleting these lines within
tree-ssa-uninit.c:warn_uninit:

175   location = linemap_resolve_location (line_table, location,
176LRK_SPELLING_LOCATION, NULL);

so that the location used for the warning retains any virtual location, rather
than flattening it to the physical location.  Am not yet sure of the impact of
such a change.

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

[abutcher at gcc dot gnu.org]

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

--- Comment #26 from Adam Butcher  ---
(In reply to Nathan Sidwell from comment #25)
> Fixed.  We capture this if we find at least one non-static member function. 
> This agrees with Clang's implementation, after discussion with Richard Smith.
> 

Nice.  Your [much cleaner] patch sorts out the starred case above too.  With
GCC master (7.0.0 20170119) with your patch the results are:

  auto l0 = [&](auto z) { f (z); };// C:8 G:1 G':8 G'':8
  auto l1 = [&](auto) { f (2.4); };// C:8 G:1 G':8 G'':1 * fixed :)
  auto l2 = [&](auto) { O::x (2.4); }; // C:8 G:1 G':1 G'':1
  auto l3 = [&](auto) { N::y (2.4); }; // C:1 G:1 G':1 G'':1
  auto l4 = [&](auto) { }; // C:1 G:1 G':1 G'':1
  auto l5 = [&](int z) { f (z); }; // C:8 G:8 G':8 G'':8
  auto l6 = [&](int) { f (2.4); }; // C:8 G:1 G':1 G'':1
  auto l7 = [&](int) { O::x (2.4); };  // C:8 G:1 G':1 G'':1
  auto l8 = [&](int) { N::y (2.4); };  // C:1 G:1 G':1 G'':1
  auto l9 = [&](int) { };  // C:1 G:1 G':1 G'':1

with closure sizes indicated for C = Clang RELEASE_391/final, G = GCC prior to
fix, G' = GCC with my old patch, G'' = latest GCC with your patch.

It's interesting you reference Clang's implementation though as, judging by the
results of the above test, Clang is capturing 'this' far more often than it
should be; even in cases where a enclosed class member is not referenced at all
(in extreme cases the referenced fn is a static member function of a completely
different class).  And even stranger, Clang appears to behave the same for
monomorphic lambdas too.  Not sure what's going on there.

[Bug fortran/79154] omp declare simd in pure function?

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #0)
> Created attachment 40550 [details]
> the fortran program
> 
> I tried to build the program (see attachment) with gfortran (5.4.0
> linux,cygwin 6.2.0,6.3.0 mingw 6.2.0 linux ...)
> it gave me this error:
> test_simd.f90:6:6:
> 
>  !$omp declare simd(add)
>   1
> Error: OpenMP directives at (1) may not appear in PURE or ELEMENTAL
> procedures

AFAIK, GCC support OpenMP 4.0.  On p. 26 of OpenMP 4.0 Standard, one
finds

  Restrictions

  The following restriction applies to all OpenMP directives:
  · OpenMP directives may not appear in PURE or ELEMENTAL procedures.

so you get the above error message.  I'll note that OpenMP 4.5 Standard
states
Restrictions

The following restriction applies to all OpenMP directives:

  Restrictions

  · OpenMP directives, except SIMD and declare target directives,
may not appear in pure
procedures.

I'll further note that the GCC wiki page for OpenMP sugeests that
no one is actively working on $.5 support.

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
The following testcases still have xfails:
  c-c++-common/pr69543-3.c
  c-c++-common/pr69543-4.c
so this isn't quite fixed yet.

[Bug testsuite/63256] [5/6/7 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[acsawdey at gcc dot gnu.org]

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

--- Comment #10 from acsawdey at gcc dot gnu.org ---
Looking at this again. Present state of play is:

sms-4.c fails with -m64 BE and LE
sms-8.c fails with -m32 BE

[Bug fortran/79157] New: gfortran crashed on sparc with openmpi build

[ikozhukhov at gmail dot com]

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

Bug ID: 79157
   Summary: gfortran crashed on sparc with openmpi build
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ikozhukhov at gmail dot com
  Target Milestone: ---

i have DilOS - illumos based platform.
i have DilOS on SPARC T5220
i have gcc-5.4.1 64bit bootstrap with GNU AS + illumos ld
$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/gcc/5/lib/gcc/sparcv9-sun-solaris2.11/5.4.0/lto-wrapper
Target: sparcv9-sun-solaris2.11
Configured with: ../configure --prefix=/usr/gcc/5
--build=sparcv9-sun-solaris2.11 --bindir=/usr/gcc/5/bin
--sbindir=/usr/gcc/5/sbin --libdir=/usr/gcc/5/lib --libexecdir=/usr/gcc/5/lib
--infodir=/usr/gcc/5/share/info --mandir=/usr/gcc/5/share/man
--target=sparcv9-sun-solaris2.11 --enable-targets=sparc-sun-solaris2.11
--enable-shared --enable-plugins --enable-lto --enable-initfini-array
--enable-tls --enable-threads=posix --with-build-config=no --with-system-zlib
gcc_cv_ld_as_needed=no --disable-bootstrap --without-gnu-ld
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran,objc --with-gnu-as
--with-as=/usr/bin/gas
Thread model: posix
gcc version 5.4.0 (GCC) 

try to build openmpi and i can see message about:

configure:35796: checking size of Fortran CHARACTER
configure:35864: gcc-6 -DNDEBUG -g -O2 -mcpu=v9 -D_REENTRANT -finline-functions
-fno-strict-aliasing -I. -c conftest.c
configure:35871: $? = 0
configure:35881: gfortran -g -O2  conftestf.f90 conftest.o -o conftest  
configure:35888: $? = 0
configure:35932: ./conftest
configure:35939: $? = 0
configure:35955: result: 1
configure:35978: checking for C type corresponding to CHARACTER
configure:36024: result: char
configure:36093: checking alignment of Fortran CHARACTER
configure:36171: gcc -DNDEBUG -g -O2 -mcpu=v9 -D_REENTRANT -finline-functions
-fno-strict-aliasing -I. -c conftest.c
configure:36178: $? = 0
configure:36188: gfortran -g -O2 conftestf.f conftest.o -o conftest  
conftestf.f:1:0:

   program falign
 ^
internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:36195: $? = 1
configure:36212: result: Error!
configure:36214: error: Could not determine alignment of CHARACTER

i have reproduced crash with steps from configure script.

i tried to reproduce it by gcc-6.3.0 + GNU AS + illumos ld - but it is working
without crash.
problem with gcc-5.4 on SPARC on illumos based platform.

if you want/need access to to SPARC - please let me know - i can provide zone
where you can try reproduce it and use for your investigation.

[Bug target/78478] Compile Error for i386-rtems

[uros at gcc dot gnu.org]

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

--- Comment #22 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:00:53 2017
New Revision: 244651

URL: https://gcc.gnu.org/viewcvs?rev=244651&root=gcc&view=rev
Log:
PR target/78478
* config/ax_check_define.m4: New file.

libgfortran/ChangeLog:

PR target/78478
* acinclude.m4: Include ../config/ax_check_define.m4
* configure.ac: Check if _SOFT_FLOAT is defined.
* configure.host (i?86 | x86_64): Use fpu-generic when
have_soft_float is set.
* configure: Regenerate.


Added:
trunk/config/ax_check_define.m4
Modified:
trunk/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/configure.host

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to mib.bugzilla from comment #0)
> Changing "friend void" to "friend auto" would be a simple fix.

That wouldn't compile in C++11 mode. I think shouldn't return anything.

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-19
 Ever confirmed|0   |1

[Bug libstdc++/79156] New: incorrect c++ usage in gcc7 void function returns a value

[mib.bugzilla at gmail dot com]

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

Bug ID: 79156
   Summary: incorrect c++ usage in gcc7  void function
returns a value
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com
  Target Milestone: ---

Hello, I work on the Intel c++ compiler and I found this problem when compiling
the gcc7 version of  dated Jan 1, 2017. I believe the error message is
accurate and it could be fixed with a minor change.

In file included from
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/bits/shared_ptr.h(52),
 from
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/memory(81),
 from mem.cpp(1):
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/bits/shared_ptr_base.h(1823):
error: return value type does not match the function type
{ return __p; }


The function being complained about looks like this:
 friend void
  __enable_shared_from_this_base(const __shared_count<_Lp>&,
 const __enable_shared_from_this* __p)
  { return __p; }

  mutable __weak_ptr<_Tp, _Lp>  _M_weak_this;
};

Changing "friend void" to "friend auto" would be a simple fix.

Thanks and regards, Melanie Blower (melanie dot blower at intel dot com)

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 20:29:07 2017
New Revision: 244650

URL: https://gcc.gnu.org/viewcvs?rev=244650&root=gcc&view=rev
Log:
Fix unsafe moves inside loops

PR libstdc++/67085
* include/bits/stl_heap.h (__is_heap): Use _GLIBCXX_MOVE.
(__make_heap, __sort_heap): Don't use _GLIBCXX_MOVE inside loops.
* testsuite/23_containers/priority_queue/67085.cc: Adjust expected
number of copies.
* testsuite/25_algorithms/make_heap/movable.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/make_heap/movable.cc
  - copied, changed from r244648,
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_heap.h
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[mattyclarkson at gmail dot com]

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

--- Comment #9 from Matt Clarkson  ---
(In reply to Jonathan Wakely from comment #7)
> GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has,
> i.e. the GCC major version, as an integer constant, but defined by the
> library headers not the compiler).
> 
> If that macro is present you have a version of libstdc++ that provides a
> working . To be really sure you could check it's defined to a value
> >= 5, in order to handle (hypothetical) unofficial 4.7 or 4.8 builds that
> have the patch backported.

Sweet! Will update the snippet on Stack Overflow. Thank you for this, you the
man ;)

[Bug target/79155] New: Typo in cpuid.h comment

[myriachan at gmail dot com]

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

Bug ID: 79155
   Summary: Typo in cpuid.h comment
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

x86's gcc/config/i386/cpuid.h contains the following comment:

/* Return highest supported input value for cpuid instruction.  ext can
   be either 0x0 or 0x800 to return highest supported value for
   basic or extended cpuid information.  Function returns 0 if cpuid
   is not supported or whatever cpuid returns in eax register.  If sig
   pointer is non-null, then first four bytes of the signature
   (as found in ebx register) are returned in location pointed by sig.  */

The second hex constant should be 0x8000, with one more zero.  The
implementation of __get_cpuid below uses 0x8000 correctly.

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I see no warning at -O0 on

  snprintf (buffer, 4, "%03hx", val & 0xfff);

or at -O2 on:

  snprintf (buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);

(It does warn at -O0 as expected.)  This is on x86_64 (both ILP32 and LP64) but
there are known issues in VRP that have been seen to lead to false positives.

What target are you seeing false positives on and with what revision?

[Bug fortran/79154] New: omp declare simd in pure function?

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 79154
   Summary: omp declare simd in pure function?
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

Created attachment 40550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40550&action=edit
the fortran program

I tried to build the program (see attachment) with gfortran (5.4.0 linux,cygwin
6.2.0,6.3.0 mingw 6.2.0 linux ...)
it gave me this error:
test_simd.f90:6:6:

 !$omp declare simd(add)
  1
Error: OpenMP directives at (1) may not appear in PURE or ELEMENTAL procedures

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #20)

> Looks like it works, Thanks.
> 
> Based on my testing,  these need to be applied to both the gcc 6 branch and
> master. Should I just commit them with the PR noted or do they need to go
> through gcc-patches first?

The i386/rtemself.h change is OK and can be committed to gcc-7 and gcc-6
branch. Please post this patch to gcc-patches first, and state that it is
pre-approved.

Regarding gfortran patch, I will propose the patch that detects _SOFT_FLOAT at
configure time to libgfortran ML. So, I'll take care of this part.

[Bug c/79049] Unknown escape sequence not correctly pointed out

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-19
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Notes to self: warning is emitted by convert_escape in libcpp/charset.c:1466
here:
1461  /* diagnostic.c does not support "%03o".  When it does, this
1462 code can use %03o directly in the diagnostic again.  */
1463  char buf[32];
1464  sprintf(buf, "%03o", (int) c);
1465  cpp_error (pfile, CPP_DL_PEDWARN,
1466 "unknown escape sequence: '\\%s'", buf);

when first parsing the string token, via cpp_interpret_string, and so
loc_readers is NULL.

[Bug c/79153] New: -Wimplicit-fallthrough missed warning

[sirl at gcc dot gnu.org]

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

Bug ID: 79153
   Summary: -Wimplicit-fallthrough missed warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

I believe this testcase modeled after real code should warn when falling
through into 'case 4'.

int
test (int v1, int v2)
{
  switch (v1)
{
case 3:
  switch (v2)
{
case 1:
  return 28;
case 2:
  return 38;
case 3:
  return 88;
}
case 4:
  return 168;
}
  return -1;
}

[Bug c/79152] New: -Wimplicit-fallthrough false positive triggered by goto statements

[sirl at gcc dot gnu.org]

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

Bug ID: 79152
   Summary: -Wimplicit-fallthrough false positive triggered by
goto statements
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This strange creduce'd testcase warns with current trunk:

typedef struct {
char *   bs;
} xstruct;

void test (char ch, long handle) {
switch (ch) {
case 1:
goto label1;
goto label;
(ch) = *(((xstruct *) (handle))->bs++);
label:
label1:
((xstruct *) handle)->bs ;
}
}

# gcc-trunk -c -Wimplicit-fallthrough testcase.c
testcase.c: In function 'test':
testcase.c:10:14: warning: this statement may fall through
[-Wimplicit-fallthrough=]
 (ch) = *(((xstruct *) (handle))->bs++);
 ~^
testcase.c:11:1: note: here
 label:
 ^

I believe this is a false positive. I hope the creduce'd testcase is enough to
highlight the problem.

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 18:26:41 2017
New Revision: 244648

URL: https://gcc.gnu.org/viewcvs?rev=244648&root=gcc&view=rev
Log:
PR67085 move comparison functions in heap operations

PR libstdc++/67085
* include/bits/stl_heap.h (push_heap, __adjust_heap, __pop_heap)
(pop_heap, __make_heap, make_heap, __sort_heap, sort_heap): Use
_GLIBCXX_MOVE when passing comparison function to other functions.
(is_heap_until, is_heap): Use std::move when passing comparison
function.
* testsuite/23_containers/priority_queue/67085.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_heap.h

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

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

--- Comment #4 from Franz Sirl  ---
Hmm, %hhd is not usable on some of our platforms and also only really helpful
with exact %x outputs:

  snprintf(buffer, 3, "%02hhx", val);

What about:

  snprintf(buffer, 4, "%03hx", val & 0xfff);

Here the 'h' modifier doesn't help at all and also in my eyes 'val & 0xfff' or
'abs(val % 100)' would be much more natural range limiters for warning
suppression. It's a pity there isn't at least a minimum "arguments-only-VRP"
even at -O0.

Can't we have another level or two for -Wformat-truncation that only warns when
VRP is active?

Note that I believe that

  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);

shouldn't warn when VRP is active. Seems to be a minor deficiency in VRP.

[Bug c++/79130] [C++17] FI20 change vs. direct initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

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

[Bug tree-optimization/79151] New: Missed vectorization with identical formulas

[tkoenig at gcc dot gnu.org]

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

Bug ID: 79151
   Summary: Missed vectorization with identical formulas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Consider the following code. The function "scalar" contains two formulas in a
function which are identical, except for the coefficients which
differ.

This could be vectorized.  As an example of how this could be done,
see the function "vector" where vectorization intrinsics are used.

You will see that "vector" is much shorter; all the operations are
done using vector intrinsics.

This is for x86_64-pc-linux-gnu.

#include 

void scalar(const double *restrict a, const double *restrict b,
double x, double *ar, double *br)
{
  double ra, rb;
  int i;

  ra = a[0] + a[1]/x - 1.0/(a[0]-a[1]);
  rb = b[0] + b[1]/x - 1.0/(b[0]-b[1]);

  *ar = ra;
  *br = rb;
}

void vector(const double *restrict a, const double *restrict b,
double x, double *ar, double *br)
{
  typedef double v2do __attribute__((vector_size (16)));
  v2do c0, c1, r;

  c0[0] = a[0];
  c0[1] = b[0];
  c1[0] = a[1];
  c1[1] = b[1];

  r = c0 + c1/x - 1.0/(c0-c1);
  *ar = r[0];
  *br = r[1];
}

double a[] = {1.0, -1.5};
double b[] = {1.3, -1.2};

int main()
{
  double x = 1.24;
  double ar, br;

  scalar(a, b, x, &ar, &br);
  printf("%f %f\n", ar, br);
  vector(a, b, x, &ar, &br);
  printf("%f %f\n", ar, br);

  return 0;
}

Assembly for the function "scalar":

scalar:
.LFB11:
.cfi_startproc
movsd   8(%rdi), %xmm4
movsd   8(%rsi), %xmm5
movapd  %xmm4, %xmm1
movsd   (%rdi), %xmm2
movapd  %xmm5, %xmm7
divsd   %xmm0, %xmm1
divsd   %xmm0, %xmm7
addsd   %xmm2, %xmm1
subsd   %xmm4, %xmm2
movapd  %xmm2, %xmm4
movsd   (%rsi), %xmm3
movsd   .LC0(%rip), %xmm2
movapd  %xmm7, %xmm0
movapd  %xmm2, %xmm6
addsd   %xmm3, %xmm0
subsd   %xmm5, %xmm3
divsd   %xmm4, %xmm6
divsd   %xmm3, %xmm2
subsd   %xmm6, %xmm1
movsd   %xmm1, (%rdx)
subsd   %xmm2, %xmm0
movsd   %xmm0, (%rcx)
ret

Assembly for the function "vector":

vector:
.LFB12:
.cfi_startproc
movsd   8(%rsi), %xmm2
movsd   8(%rdi), %xmm3
unpcklpd%xmm0, %xmm0
unpcklpd%xmm2, %xmm3
movapd  .LC1(%rip), %xmm2
movsd   (%rdi), %xmm1
movapd  %xmm3, %xmm4
movhpd  (%rsi), %xmm1
divpd   %xmm0, %xmm4
movapd  %xmm4, %xmm0
addpd   %xmm1, %xmm0
subpd   %xmm3, %xmm1
divpd   %xmm1, %xmm2
addpd   %xmm2, %xmm0
movlpd  %xmm0, (%rdx)
movhpd  %xmm0, (%rcx)
ret

[Bug c++/62161] more precise locations for command-line diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Given that the driver takes the user-supplied command line and uses it to
invoke cc1 etc, the command-line seen by cc1 doesn't bear a simple relationship
to the one the user provided.

So I don't know if there's a good way to implement this.

Notes:

c-opts.c:c_finish_options creates the  linemap by calling:

1381  cb_file_change (parse_in,
1382  linemap_check_ordinary (linemap_add (line_table,
LC_RENAME, 0,
1383  
_(""), 0)));

[Bug rtl-optimization/79150] New: ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[toma.tabacu at imgtec dot com]

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

Bug ID: 79150
   Summary: ICE: in commit_one_edge_insertion, at cfgrtl.c:2077
for the gcc.dg/pr77834.c test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toma.tabacu at imgtec dot com
  Target Milestone: ---

gcc.dg/pr77834.c has been failing on mips-mti-elf and mips-mti-linux-gnu with
the default options since around 7 November (I haven't checked, but I assume
it's since it was committed) with the following ICE:

gcc/gcc/testsuite/gcc.dg/pr77834.c: In function ‘foo’:
gcc/gcc/testsuite/gcc.dg/pr77834.c:18:1: internal compiler error: in
commit_one_edge_insertion, at cfgrtl.c:2077
 }
 ^
0x8e76c4 commit_one_edge_insertion(edge_def*)
gcc/gcc/cfgrtl.c:2077
0x8c7665 execute
gcc/gcc/cfgexpand.c:6430
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.

Here's the compiler version:

$ ~/obj-mips-mti-linux-gnu/gcc/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=~/obj-mips-mti-linux-gnu/gcc/gcc/xgcc
Target: mips-mti-linux-gnu
Configured with: ~/src/gcc/configure CFLAGS='-O0 -g3' CXXFLAGS='-O0 -g3'
--prefix=~/install-mips-mti-linux-gnu --disable-multilib
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-libssp
--disable-libmudflap --disable-decimal-float --with-mips-plt
--target=mips-mti-linux-gnu --enable-languages=c,c++,fortran
--with-sysroot=~/install-mips-mti-linux-gnu/sysroot --enable-__cxa_atexit
--enable-checking=all
Thread model: posix
gcc version 7.0.0 20170119 (experimental) (GCC) 

I've looked into this a little, but I'd appreciate some help.
Sorry for being so late in reporting this.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Martin Sebor  ---
> Thanks.  The patch looks good to me.  You should be able to commit the patch
> without approval.

Indeed, done.

Rainer

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at gcc dot gnu.org]

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

--- Comment #12 from Rainer Orth  ---
Author: ro
Date: Thu Jan 19 17:42:50 2017
New Revision: 244647

URL: https://gcc.gnu.org/viewcvs?rev=244647&root=gcc&view=rev
Log:
Fix gcc.dg/attr-alloc_size-4.c on i?86 (PR testsuite/79051)

PR testsuite/79051
* gcc.dg/attr-alloc_size-4.c (test_int_range) [__i386__ ||
__x86_64__]: Allow for target i?86-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c

[Bug target/77455] [AArch64] eh_return implementation fails

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from wilco at gcc dot gnu.org ---
Fixed on trunk in r244547:

This patch simplifies the handling of EH return.  We force the use of the
frame pointer so the return location is always at FP + 8.  This means we
can emit a simple volatile access in EH_RETURN_HANDLER_RTX without needing md
patterns, splitters and frame offset calculations.  The new implementation also
fixes various bugs in aarch64_final_eh_return_addr, which does not work with
-fomit-frame-pointer, alloca or outgoing arguments.

gcc/
* config/aarch64/aarch64.md (eh_return): Remove pattern and splitter.
* config/aarch64/aarch64.h (AARCH64_EH_STACKADJ_REGNUM): Remove.
(EH_RETURN_HANDLER_RTX): New define.
* config/aarch64/aarch64.c (aarch64_frame_pointer_required):
Force frame pointer in EH return functions.
(aarch64_expand_epilogue): Add barrier for eh_return.
(aarch64_final_eh_return_addr): Remove.
(aarch64_eh_return_handler_rtx): New function.
* config/aarch64/aarch64-protos.h (aarch64_final_eh_return_addr):
Remove.
(aarch64_eh_return_handler_rtx): New prototype.

testsuite/
* gcc.target/aarch64/eh_return.c: New test.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #20 from Joel Sherrill  ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Joel Sherrill from comment #18)
> > I changed that line to 
> > 
> > #ifdef _SOFT_FLOAT
> > #include "config/fpu-generic.h"
> > 
> > and it built. Is that OK?
> 
> Yes.

Looks like it works, Thanks.

Based on my testing,  these need to be applied to both the gcc 6 branch and
master. Should I just commit them with the PR noted or do they need to go
through gcc-patches first?

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
The changes in r244150 turned some internal copies into moves, improving the PR
70898 testcase from 61 seconds to 29 seconds.

If I modify the testcase attached here to track moves as well as copies, GCC 6
prints:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 4 + 0
After 3 calls to push: 16 + 0
After 3 calls to pop : 33 + 0

Since r244150 GCC 7 trunk prints:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 2 + 2
After 3 calls to push: 8 + 8
After 3 calls to pop : 17 + 16

I'm testing a patch that reduces the PR 70898 test to under 4s and makes the
attachment here print:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 1 + 3
After 3 calls to push: 4 + 12
After 3 calls to pop : 7 + 26

This doesn't help if your comparison function is only copyable and not movable,
but it's 2017 not 2007 so I think that's OK.

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Matt Clarkson from comment #2)
> Because wehen I compile with clang against the libstdc++ the problem will
> still occur and __GNUC__ will not be defined.

N.B. Clang does define __GNUC__ but it always defines it to 4 (and defines
__GNUC_MINOR__ to 1 and __GNUC_PATCHLEVEL__ to 2, because it identifies as GCC
4.1.2, the last release Apple shipped for their OS).

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.0 |7.0

--- Comment #7 from Jonathan Wakely  ---
GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has, i.e.
the GCC major version, as an integer constant, but defined by the library
headers not the compiler).

If that macro is present you have a version of libstdc++ that provides a
working . To be really sure you could check it's defined to a value >=
5, in order to handle (hypothetical) unofficial 4.7 or 4.8 builds that have the
patch backported.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Thanks.  The patch looks good to me.  You should be able to commit the patch
without approval.

[Bug target/71648] C++ ICE on ppc64 with -m64

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
This actually appears to be fixed in GCC 6 as well, so the fix must have been
backported.  Konstantinos, can you please try with GCC 6.3 and confirm that the
problem goes away for you?

Thanks,
Bill

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 16:40:46 2017
New Revision: 244642

URL: https://gcc.gnu.org/viewcvs?rev=244642&root=gcc&view=rev
Log:
PR78905 define _GLIBCXX_RELEASE macro

PR libstdc++/78905
* doc/xml/manual/abi.xml (abi.versioning.history): Add markup to
macro names, filenames, and literal values. Document _GLIBCXX_RELEASE.
Document that the deprecated _GLIBCXX_VERSION macro was removed for
the 4.0.0 release.
* doc/html/*: Regenerate.
* include/Makefile.am (_GLIBCXX_RELEASE): Set value.
* include/Makefile.in: Regenerate.
* include/bits/c++config (_GLIBCXX_RELEASE): Add #define.
* testsuite/ext/profile/mutex_extensions_neg.cc: Use lineno of 0 in
dg-error.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/html/manual/abi.html
trunk/libstdc++-v3/doc/xml/manual/abi.xml
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/bits/c++config
trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
Created attachment 40549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40549&action=edit
GCC 7 -fmem-report

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
Created attachment 40548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40548&action=edit
GCC 6 -fmem-report

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
Depending on memory layout of the structure, but these 2 structures increase
memory of about ((32+88)*3258685)/(1024**2) ~372 MB.

[Bug tree-optimization/71264] [5 Regression] ICE in convert_move

[ro at gcc dot gnu.org]

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

--- Comment #23 from Rainer Orth  ---
(In reply to rguent...@suse.de from comment #22)
> On Mon, 24 Oct 2016, ebotcazou at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264
> > 
> > --- Comment #21 from Eric Botcazou  ---
> > > It is supposed to be vectorized on targets w/o V4QImode support.
> > > Not sure if the list of targets that FAIL the testcase would be smaller
> > > if I change the scan to an explicit list of targets (x86)?
> > 
> > Not sure indeed, it passes on PowerPC & PowerPC64 too for example.
> > 
> > > Meanwhile just add more targets to the xfail -- it really is a missed
> > > optimization as I guess for example arm also has V4SImode.
> > 
> > There is no XFAIL currently but we can certainly add one.
> 
> Ah, right ... my tree has local changes:
> 
> Index: gcc/testsuite/gcc.dg/vect/pr71264.c
> ===
> --- gcc/testsuite/gcc.dg/vect/pr71264.c (revision 241395)
> +++ gcc/testsuite/gcc.dg/vect/pr71264.c (working copy)
> @@ -7,6 +7,8 @@ typedef uint8_t footype __attribute__((v
>  void test(uint8_t *ptr, uint8_t *mask)
>  {
>footype mv;
> +  ptr = __builtin_assume_aligned (ptr, __alignof__ (footype));
> +  mask = __builtin_assume_aligned (mask, __alignof__ (footype));
>__builtin_memcpy(&mv, mask, sizeof(mv));
>for (unsigned i = 0; i < 16; i += 4)
>  {
> @@ -17,4 +19,4 @@ void test(uint8_t *ptr, uint8_t *mask)
>  }
>  }
>  
> -/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } 
> } */
> +/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" { 
> xfail sparc*-*-* } } } */

Shouldn't this patch be applied then?

  Rainer

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[mpf at gcc dot gnu.org]

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

--- Comment #14 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Thu Jan 19 16:05:59 2017
New Revision: 244640

URL: https://gcc.gnu.org/viewcvs?rev=244640&root=gcc&view=rev
Log:
MIPS: PR target/78176 add -mlxc1-sxc1.

gcc/

PR target/78176
* config.gcc (supported_defaults): Add lxc1-sxc1.
(with_lxc1_sxc1): Add validation.
(all_defaults): Add lxc1-sxc1.
* config/mips/mips.opt (mlxc1-sxc1): New option.
* gcc/config/mips/mips.h (OPTION_DEFAULT_SPECS): Add a default for
mlxc1-sxc1.
(TARGET_CPU_CPP_BUILTINS): Add builtin_define for
__mips_no_lxc1_sxc1.
(ISA_HAS_LXC1_SXC1): Gate with mips_lxc1_sxc1.
* gcc/doc/invoke.texi (-mlxc1-sxc1): Document the new option.
* doc/install.texi (--with-lxc1-sxc1): Document the new option.

gcc/testsuite/

* gcc.target/mips/lxc1-sxc1-1.c: New file.
* gcc.target/mips/lxc1-sxc1-2.c: Likewise.
* gcc.target/mips/mips.exp (mips_option_groups): Add ghost option
HAS_LXC1.
(mips_option_groups): Add -m[no-]lxc1-sxc1.
(mips-dg-init): Detect default -mno-lxc1-sxc1.
(mips-dg-options): Handle HAS_LXC1 arch upgrade/downgrade.

Added:
trunk/gcc/testsuite/gcc.target/mips/lxc1-sxc1-1.c
trunk/gcc/testsuite/gcc.target/mips/lxc1-sxc1-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/mips/mips.h
trunk/gcc/config/mips/mips.opt
trunk/gcc/doc/install.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/mips.exp

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth  ---
Created attachment 40547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40547&action=edit
proposed patch

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #22 from Martin Liška  ---
Btw. sizeof(value_range) == 32 and sizeof(ipa_bits) == 88 on a x86_64 machine.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #9 from Rainer Orth  ---
(In reply to Martin Sebor from comment #7)

Unfortunately, that change is still wrong and causes failures on e.g.
i386-pc-solaris2.12 and
i686-pc-linux-gnu:


Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:142:3:
warning: argument 1 range [1236, 2147483647] exceeds maximum object size 1234
[-Walloc-size-larger-than=]

If you match __i386__ in the #if, you need to do the same in the target
selector,
as in the attached patch.

Tested with the appropriate runtest invocation on i386-pc-solaris2.12 and
amd64-pc-solaris2.12.

  Rainer

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #19 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #18)
> I changed that line to 
> 
> #ifdef _SOFT_FLOAT
> #include "config/fpu-generic.h"
> 
> and it built. Is that OK?

Yes.

[Bug target/71648] C++ ICE on ppc64 with -m64

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
This appears to be fixed on trunk -- between David and me we've tested this on
AIX 32- and 64-bit, PPC64LE on P8, and PPC64 on P7.  We'll need to bisect and
see what fixed the problem and work on a backport for GCC 6.

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[vehre at gcc dot gnu.org]

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

--- Comment #12 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Thu Jan 19 15:52:32 2017
New Revision: 244637

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

2017-01-19  Andre Vehreschild  

PR fortran/70696
* trans-decl.c (gfc_build_qualified_array): Add static decl to parent
function only, when the decl-context is not the translation unit.

gcc/testsuite/ChangeLog:

2017-01-19  Andre Vehreschild  

PR fortran/70696
* gfortran.dg/coarray_43.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/coarray_43.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
Looking at distinct number of value ranges and bits, we can get:

grep hash_vr /tmp/7.dump.ipa | sort | uniq -c | wc -l
65224

grep hash_bits /tmp/7.dump.ipa | sort | uniq -c | wc -l
13421

Where total # of jump functions at the end of WPA is 3258685.

[Bug target/79144] cmpstrnsi optimization breaks glibc

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Alan,
  Thanks for jumping in here. What I tried yesterday was this code to try to
get the correct name:

+ const char *id =
+   IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
+   (builtin_decl_explicit (BUILT_IN_STRCMP)));
+ if (id == NULL || *id == 0)
+   id = "strcmp";
+ else if (*id == '*')
+   id++;
+ emit_library_call_value (gen_rtx_SYMBOL_REF (Pmode, id),
+  target, LCT_NORMAL, GET_MODE (target), 2,
+  force_reg (Pmode, XEXP (src1, 0)), Pmode,
+  force_reg (Pmode, XEXP (src2, 0)), Pmode);

But this didn't work for reasons I don't quite understand.

The other discussion of this starts here on gcc-patches:

https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00843.html

[Bug target/79127] [7 Regression] Error: invalid register for .seh_savexmm in matmul_i4.c

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 19 15:41:15 2017
New Revision: 244636

URL: https://gcc.gnu.org/viewcvs?rev=244636&root=gcc&view=rev
Log:
PR target/79127
* acinclude.m4 (LIBGFOR_CHECK_AVX512F): Ensure the test clobbers
some zmm16+ registers to verify they are handled by unwind info
properly if needed.
* configure: Regenerated.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #18 from Joel Sherrill  ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Joel Sherrill from comment #16)
> > Thanks for all the feedback. With this patch, it now builds. Is the style of
> > change to configure.host OK?
> 

> +#ifdef _SOFT_FLOAT
> +#include "fpu-generic.h"
> +
This seems like a good solution but the build can't find fpu-generic.h

In file included from ../../../../gcc/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h:27:25: fatal error: fpu-generic.h: No such file or directory
 #include "fpu-generic.h"

I changed that line to 

#ifdef _SOFT_FLOAT
#include "config/fpu-generic.h"

and it built. Is that OK?

[Bug rtl-optimization/79149] New: bad optimization on MIPS and ARM leading to excessive stack usage in some cases

[arnd at linaro dot org]

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

Bug ID: 79149
   Summary: bad optimization on MIPS and ARM leading to excessive
stack usage in some cases
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 40546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40546&action=edit
compressed preprocessed source for wp512 crypto from linux kernel

Build-testing the Linux kernel on MIPS shows warnings about possible kernel
stack overflow in the kernel's crypto libraries, in particular the wp512
algorithm, as the stack frame grows beyond the normal per-function limit of
1024 bytes we use in the kernel.

I have been able to avoid the problem by turning off two specific
optimizations,
and I have reproduced the same thing with both gcc-4.9 and gcc-7.0:

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-7.0.0 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 1128 bytes is larger
than 100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-7.0.0 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i 
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 304 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-4.9.3 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 1096 bytes is larger
than 100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-4.9.3 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i 
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic 
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 272 bytes is larger than
100 bytes [-Wframe-larger-than=]

To cross-check the problem, I have tried compiling the same file on ARM, which
shows similar results but stays below the warning limit:

/home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.0 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 816 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.0 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i 
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 344 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-4.9.3 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 840 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-4.9.3 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 376 bytes is larger than
100 bytes [-Wframe-larger-than=]

However, using an x86 compiler, the frame for the same source is always under
300 bytes, and the options have no effect.

[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #5 from Bill Schmidt  ---
Work is complete.

[Bug rtl-optimization/79148] New: stack addresses are spilled to stack slots on x86-64 at -Os instead of rematerializing the addresses

[froydnj at gcc dot gnu.org]

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

Bug ID: 79148
   Summary: stack addresses are spilled to stack slots on x86-64
at -Os instead of rematerializing the addresses
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: froydnj at gcc dot gnu.org
  Target Milestone: ---

Noticed this while browsing around Firefox source code compiled with GCC 5.4; a
colleague confirms that this happens with 6.3 as well.  Compiling:

https://people.mozilla.org/~nfroyd/Unified_cpp_widget0.ii.gz

(Tried to get it under the attachment limit with xz, didn't happen)

with options:

-mtune=generic -march=x86-64 -g -Os -std=gnu++11 -fPIC -fno-strict-aliasing
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-freorder-blocks -fno-omit-frame-pointer -fstack-protector-strong

gives, for the function
_ZN7mozilla6widget11GfxInfoBase20GetFeatureStatusImplEiPiR18nsAString_internalRK8nsTArrayINS0_13GfxDriverInfoEER19nsACString_internalPNS0_15OperatingSystemE
a bit of code that looks like:

.LVL3402:
leaq-784(%rbp), %rax  [1a]
.LVL3403:
movq%rax, %rdi
.LVL3404:
movq%rax, -816(%rbp)  [1b]
call_ZN12nsAutoStringC1Ev
.LVL3405:
.loc 14 887 0
leaq-624(%rbp), %rax  [2a]
movq%rax, %rdi
movq%rax, -824(%rbp)  [2b]
call_ZN12nsAutoStringC1Ev
.LVL3406:
.loc 14 888 0
leaq-464(%rbp), %rax  [3a]
movq%rax, %rdi
movq%rax, -800(%rbp)  [3b]
call_ZN12nsAutoStringC1Ev
.LVL3407:
.loc 14 889 0
movq(%r12), %rax
movq-816(%rbp), %rsi  [1c]
movq%r12, %rdi
call*104(%rax)
.LVL3408:
.loc 14 890 0
testl   %eax, %eax
js  .L2479
movq(%r12), %rax
movq-824(%rbp), %rsi  [2c]
movq%r12, %rdi
call*120(%rax)
.LVL3409:
.loc 14 889 0
testl   %eax, %eax
js  .L2479
.loc 14 891 0
movq(%r12), %rax
movq-800(%rbp), %rsi  [3c]
movq%r12, %rdi
call*168(%rax)

The problem here, for each of the trio of instructions marked [1], [2], and
[3], is that the instructions [1b], [2b], and [3b] that store the stack
addresses are really unnecessary; replacing [1c], [2c], and [3c] with the `lea`
instructions from [1a], [2a], and [3a] is the same size and doesn't require the
stack slot storage, so we could eliminate those instructions ([1b], [2b], and
[3b]) and (possibly) make the stack frame smaller as well.

I think rematerializing the stack addresses on x86/x86-64 ought always to be a
win in terms of size (I don't know whether you'd want to make the same choices
when compiling for speed); I think it'd be a similar win for RISC-y chips, at
least so long as the stack frame sizes are reasonably small.

[Bug middle-end/44440] [5/6/7 regression] ira_initialization and buitins construction taking too much of startup time

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Now I get (for 500 invocations)
   real   user  sys
 GCC 7:0m9.816s   0m6.274s  0m3.546s
 GCC 6:0m7.880s   0m4.253s  0m3.605s
 GCC 5:0m7.655s   0m4.264s  0m3.159s
 GCC 4.6:  0m7.271s   0m4.094s  0m3.085s

We used to lazilly initialize regalloc cost tables before IRA was merged. I
think it contributes to major part of the slowdown.

Note that newly, in addition to the regclass cost, we do fair amount of
software simulated multiplies and divides

   4.59%  cc1  cc1[.] do_multiply   
   3.11%  cc1  [kernel.kallsyms]  [k] clear_page
   3.01%  cc1  libc-2.19.so   [.] memset
   2.86%  cc1  cc1[.] ggc_internal_alloc
   2.83%  cc1  [kernel.kallsyms]  [k] page_fault
   2.79%  cc1  [kernel.kallsyms]  [k] filemap_map_pages 
   2.45%  cc1  cc1[.] init_reg_sets_1   
   2.22%  cc1  cc1[.] do_add
   2.18%  cc1  libc-2.19.so   [.] __GI___strcmp_ssse3   
   2.02%  cc1  cc1[.] ht_lookup_with_hash   
   1.85%  cc1  cc1[.] do_divide 
   1.49%  cc1  cc1[.] hash_table::find_with_hash
   1.41%  cc1  [kernel.kallsyms]  [k] unmap_single_vma  
   1.37%  cc1  [kernel.kallsyms]  [k] release_pages 
   1.29%  cc1  cc1[.] decl_attributes   
   1.21%  cc1  libc-2.19.so   [.] _int_malloc   
   1.19%  cc1  libc-2.19.so   [.] strlen
   1.12%  cc1  cc1[.] normalize

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |7.0
Summary|Bootstrpping go on s390x|[7 Regression]
   |fails; redefined symbols|Bootstrapping go on s390x
   ||fails; redefined symbols

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Look at tree-ssanames.c:range_info_def for "tricks" (make them variable size):

/* Value range information for SSA_NAMEs representing non-pointer variables. 
*/

struct GTY ((variable_size)) range_info_def {
  /* Minimum, maximum and nonzero bits.  */
  TRAILING_WIDE_INT_ACCESSOR (min, ints, 0)
  TRAILING_WIDE_INT_ACCESSOR (max, ints, 1)
  TRAILING_WIDE_INT_ACCESSOR (nonzero_bits, ints, 2)
  trailing_wide_ints <3> ints;
};