[Bug c++/84840] New: ICE (in poplevel_class) for `auto` in alias declaration

[v.reshetnikov at gmail dot com]

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

Bug ID: 84840
   Summary: ICE (in poplevel_class) for `auto` in alias
declaration
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

The following C++ code causes an ICE in GCC 8.0.1 20180312 (tested with
https://godbolt.org/):

/* SOURCE */
struct S {
using type = void(auto);
};
/*** END SOURCE ***/


/* OUTPUT */
:3:1: internal compiler error: in poplevel_class, at
cp/name-lookup.c:4423
 };
 ^
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
/*** END OUTPUT ***/

[Bug c++/84839] New: ICE (Segmentation fault) when `decltype` is used with parameter pack

[v.reshetnikov at gmail dot com]

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

Bug ID: 84839
   Summary: ICE (Segmentation fault) when `decltype` is used with
parameter pack
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

The following C++ code causes an ICE in GCC 8.0.1 20180312 (tested with
https://godbolt.org/):
/* SOURCE */
template
struct S {
using fptr = void(*)(T... x, decltype(x)... y);
};

using F = S::fptr;
/*** END SOURCE ***/


/* OUTPUT */
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 4
/*** END OUTPUT ***/

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[dvitek at grammatech dot com]

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

--- Comment #13 from David Vitek  ---
Created attachment 43639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43639=edit
hack for g++4.5.3 and old libc compatibility

This is a nasty hack and you should check that your system's definition of
PTHREAD_COND_INITIALIZER is all zeroes before using it.

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[dvitek at grammatech dot com]

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

--- Comment #12 from David Vitek  ---
Created attachment 43638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43638=edit
patch for g++7.3 and old libc

This patch fixes the parse error with newer versions of g++

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[dvitek at grammatech dot com]

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

David Vitek  changed:

   What|Removed |Added

 CC||dvitek at grammatech dot com

--- Comment #11 from David Vitek  ---
I ran into this and figured out a solution.  There are actually two different
issues at play depending on which version of g++ is trying to build rwlock.cc.

g++ 7.3 can't deal with PTHREAD_COND_INITIALIZER being surrounded by parens in
the initializer list.  If we take away the parens, it parses great with g++
7.3.  I suspect this could be fixed in version control.  Specifically, the
string literal in the older definition of PTHREAD_COND_INITIALIZER does not
want to be converted to a character array.

g++ 4.5.3 refuses to parse any formulation I've been able to think of unless I
make the initializer list completely empty.  It just so happens that
PTHREAD_COND_INITIALIZER is a zero initializer with my libc, so the empty
initializer list is sufficient but abstraction-breaking.  You couldn't safely
commit this workaround to version control.

Details:
PTHREAD_COND_INITIALIZER expands to {{ 0, 0 }, 0, "", 0}

Here is the definition of pthread_cond_t:
struct _pthread_fastlock
{
  long int __status;
  int __spinlock;

};
typedef struct _pthread_descr_struct *_pthread_descr;
__extension__ typedef long long __pthread_cond_align_t;
typedef struct
{
  struct _pthread_fastlock __c_lock;
  _pthread_descr __c_waiting;
  char __padding[48 - sizeof (struct _pthread_fastlock)
   - sizeof (_pthread_descr) - sizeof (__pthread_cond_align_t)];
  __pthread_cond_align_t __align;
} pthread_cond_t;


struct S{
pthread_cond_t x;
/* g++ 7.3: error: no matching function for call to
'pthread_cond_t::pthread_cond_t()'
 * g++ 4.5.3: error: could not convert '{{0, 0}, 0, "", 0}' to
'pthread_cond_t'
 */
S() : x (PTHREAD_COND_INITIALIZER) {}
};


// Now without the parens:
struct S{
pthread_cond_t x;
/* g++ 7.3: Success!
 * g++ 4.5.3: error: could not convert '{{0, 0}, 0, "", 0}' to
'pthread_cond_t'
 */
S() : x PTHREAD_COND_INITIALIZER {}
};


Here are some stand-alone diagnostics that elucidate the root cause:

g++ 4.5.3 can't handle this code even with -std=gnu++0x.  I wasn't able to come
up with anything viable here besides {}.
struct S{
struct inner{
char A[1];
} x;
/* could not convert '{{0}}' to 'S::inner' */
S() : x {{0}} {};
};

g++ 7.3 doesn't like this:
struct R{
struct inner{
char __padding[1];
} x;
/* error: no matching function for call to 'R::inner::inner()' */
R() : x ({""}) {};
};

but it does like this:
struct R{
struct inner{
char __padding[1];
} x;
// OK
R() : x {""} {};
};

Two patches forthcoming...

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
FWIW C++ Core DR 739 is a DR against C++11 and C++98, so should be considered
to apply pre-C++14 too.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739

This has no bearing on the C behaviour though.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #12 from Jason Merrill  ---
Here's an implementation to play with.  It breaks lots of tests in the library,
which I'm not going to continue poking at now.  The deque warning in particular
seems tricky to address.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #11 from Jason Merrill  ---
Created attachment 43637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43637=edit
P

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker  ---
Thanks. I think between footnote 125 and DR#315 the intent is clear and this
bug report stands as written.

[Bug c++/84808] [8 Regression] ICE with constexpr and array

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 12 23:40:20 2018
New Revision: 258471

URL: https://gcc.gnu.org/viewcvs?rev=258471=gcc=rev
Log:
PR c++/84808
* constexpr.c (find_array_ctor_elt): Don't use elt reference after
first potential CONSTRUCTOR_ELTS reallocation.  Convert dindex to
sizetype.  Formatting fixes.

* g++.dg/cpp1y/constexpr-84808.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-84808.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84808] [8 Regression] ICE with constexpr and array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/84704] [8 Regression] internal compiler error: gimplification failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/84704] [8 Regression] internal compiler error: gimplification failed

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 12 23:39:21 2018
New Revision: 258470

URL: https://gcc.gnu.org/viewcvs?rev=258470=gcc=rev
Log:
PR c++/84704
* tree.c (stabilize_reference_1): Return save_expr (e) for
STATEMENT_LIST even if it doesn't have side-effects.

* g++.dg/debug/pr84704.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr84704.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
The response to C99 DR#315 says that for all the types not specifying 
"signed" or "unsigned" explicitly, if an implementation accepts them as 
bit-field types it's implementation-defined what the signedness is.  
That's compatible with C++ up to C++11 (C++14 removed the special-casing 
allowing plain int etc. bit-fields to be unsigned).

C11 footnote 125 explicitly refers to "typedef-name defined as int", so 
the intent is clear even if that's not explicit in normative text.

[Bug target/84838] Minor grammar fixes for x86 options

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Thanks for the patch which looks correct, but please send it to the gcc-patches
mailing list rather than attaching it here.

https://gcc.gnu.org/contribute.html#patches

[Bug libstdc++/84773] [7/8 Regression] Cross-compilers do not use aligned_alloc or _aligned_malloc for aligned-new

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for freebsd and mingw, but might still be a problem for other cross
targets.

[Bug libstdc++/84773] [7/8 Regression] Cross-compilers do not use aligned_alloc or _aligned_malloc for aligned-new

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 12 23:32:30 2018
New Revision: 258469

URL: https://gcc.gnu.org/viewcvs?rev=258469=gcc=rev
Log:
PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW
cross-compilers

PR libstdc++/84773
PR libstdc++/83662
* crossconfig.m4: Check for aligned_alloc etc. on freebsd and mingw32.
* configure: Regenerate.
* include/c_global/cstdlib [_GLIBCXX_HAVE_ALIGNED_ALLOC]
(aligned_alloc): Add using-declaration.
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: New test.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/18_support/aligned_alloc/
   
branches/gcc-7-branch/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/configure
branches/gcc-7-branch/libstdc++-v3/crossconfig.m4
branches/gcc-7-branch/libstdc++-v3/include/c_global/cstdlib

[Bug libstdc++/83662] std::aligned_alloc() not available

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 12 23:32:30 2018
New Revision: 258469

URL: https://gcc.gnu.org/viewcvs?rev=258469=gcc=rev
Log:
PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW
cross-compilers

PR libstdc++/84773
PR libstdc++/83662
* crossconfig.m4: Check for aligned_alloc etc. on freebsd and mingw32.
* configure: Regenerate.
* include/c_global/cstdlib [_GLIBCXX_HAVE_ALIGNED_ALLOC]
(aligned_alloc): Add using-declaration.
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: New test.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/18_support/aligned_alloc/
   
branches/gcc-7-branch/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/configure
branches/gcc-7-branch/libstdc++-v3/crossconfig.m4
branches/gcc-7-branch/libstdc++-v3/include/c_global/cstdlib

[Bug libstdc++/83662] std::aligned_alloc() not available

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

--- Comment #7 from Jonathan Wakely  ---
std::aligned_alloc is now available when ::aligned_alloc is provided by libc.

[Bug c/84838] New: Minor grammar fixes for x86 options

[dhgutteridge at hotmail dot com]

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

Bug ID: 84838
   Summary: Minor grammar fixes for x86 options
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhgutteridge at hotmail dot com
  Target Milestone: ---

Created attachment 43636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43636=edit
Patch to correct documentation

I noticed some minor grammatical errors in the x86 options section. "Nor" isn't
correct usage in these sentences, and there was a missing definite article (in
keeping with the style used elsewhere for that same option).

--- invoke.texi.orig2018-03-12 18:03:36.016800350 -0400
+++ invoke.texi 2018-03-12 18:50:10.065027987 -0400
@@ -27877,9 +27877,9 @@
 function attribute @code{indirect_branch}.  @xref{Function Attributes}.

 Note that @option{-mcmodel=large} is incompatible with
-@option{-mindirect-branch=thunk} nor
+@option{-mindirect-branch=thunk} and
 @option{-mindirect-branch=thunk-extern} since the thunk function may
-not be reachable in large code model.
+not be reachable in the large code model.

 Note that @option{-mindirect-branch=thunk-extern} is incompatible with
 @option{-fcf-protection=branch} and @option{-fcheck-pointer-bounds}
@@ -27898,9 +27898,9 @@
 @xref{Function Attributes}.

 Note that @option{-mcmodel=large} is incompatible with
-@option{-mfunction-return=thunk} nor
+@option{-mfunction-return=thunk} and
 @option{-mfunction-return=thunk-extern} since the thunk function may
-not be reachable in large code model.
+not be reachable in the large code model.


 @item -mindirect-branch-register

[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
Since we have docstring relicensing maintainers, I don't think this is an 
issue now.

[Bug libstdc++/84773] [7/8 Regression] Cross-compilers do not use aligned_alloc or _aligned_malloc for aligned-new

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 12 22:52:16 2018
New Revision: 258468

URL: https://gcc.gnu.org/viewcvs?rev=258468=gcc=rev
Log:
PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW
cross-compilers

PR libstdc++/84773
PR libstdc++/83662
* crossconfig.m4: Check for aligned_alloc etc. on freebsd and mingw32.
* configure: Regenerate.
* include/c_global/cstdlib [_GLIBCXX_HAVE_ALIGNED_ALLOC]
(aligned_alloc): Add using-declaration.
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/18_support/aligned_alloc/
trunk/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/crossconfig.m4
trunk/libstdc++-v3/include/c_global/cstdlib

[Bug libstdc++/83662] std::aligned_alloc() not available

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 12 22:52:16 2018
New Revision: 258468

URL: https://gcc.gnu.org/viewcvs?rev=258468=gcc=rev
Log:
PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW
cross-compilers

PR libstdc++/84773
PR libstdc++/83662
* crossconfig.m4: Check for aligned_alloc etc. on freebsd and mingw32.
* configure: Regenerate.
* include/c_global/cstdlib [_GLIBCXX_HAVE_ALIGNED_ALLOC]
(aligned_alloc): Add using-declaration.
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/18_support/aligned_alloc/
trunk/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/crossconfig.m4
trunk/libstdc++-v3/include/c_global/cstdlib

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
Sort of.

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 12 22:40:19 2018
New Revision: 258467

URL: https://gcc.gnu.org/viewcvs?rev=258467=gcc=rev
Log:
PR ada/82813
* gcc-interface/misc.c (gnat_post_options): Disable string overflow
warnings.

Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/gcc-interface/misc.c

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 12 22:40:05 2018
New Revision: 258466

URL: https://gcc.gnu.org/viewcvs?rev=258466=gcc=rev
Log:
PR ada/82813
* gcc-interface/misc.c (gnat_post_options): Disable string overflow
warnings.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c

[Bug ada/34118] enable stack checking (-fstack-check) by default

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #13 from Eric Botcazou  ---
Let's suspend it for now.

[Bug ada/34118] enable stack checking (-fstack-check) by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #12 from Eric Gallager  ---
Any update on this?

[Bug bootstrap/46981] multilib LD_LIBRARY_PATH prevents configuration of target libraries

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to David Edelsohn from comment #0)
> config-ml.in adjusts LD_LIBRARY_PATH for multilib target libraries.  This
> apparently was introduced to ensure that applications created by configure
> in multilib directories find the correct libraries:
> 
> http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00666.html
> 
> However, GCC cc1 now relies on libstdc++ via libppl and LD_LIBRARY_PATH will
> specify the 64 bit directory for the 64 bit multilib of a target library:
> 
> /tmp/201012005/powerpc-ibm-aix5.3.0.0/ppc64/libstdc++-v3/src/.libs
> 
> If libstdc++-v3 is configured and built before libgfortran, for example, 64
> bit libgfortran configure will fail because 32 bit cc1 finds the wrong
> version of libstdc++-v3.  LD_LIBRARY_PATH is affecting the host path, not
> only the target path.
> 
> I am not sure why this started to fail on AIX now (timing issue?), but it
> causes a bootstrap failure of target libraries.

I thought gcc didn't use libppl any longer?

[Bug c/84717] suffix for double constant is a GCC extension is not documented

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
The 'd' suffix, and the FLOAT_CONST_DECIMAL64 pragma, were in TR 
24732:2009.  Those features were not carried forward to the newer decimal 
floating-point specification in TS 18661-2:2015.

There haven't been any updates to the DFP support in GCC for the newer 
specification in TS 18661-2 (or -3, for additional types).  But the vast 
bulk of the changes in TS 18661-2 are library changes, not language ones, 
so there probably wouldn't be much to do there (beyond constant rounding 
modes, which aren't supported for binary floating-point either in GCC).  
And since we don't have -std modes for TR/TS documents, we don't really 
have a way to distinguish in GCC which DFP extensions came from which 
document (until TS 18661-1 and -2 at least get merged into C2x so -std=c2x 
-pedantic accepts features merged in there but not the features not merged 
in there).

[Bug c++/84837] [DR 1906] unqualified lookup in friend declaration

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

Summary|unqualified lookup in   |[DR 1906] unqualified
   |friend declaration  |lookup in friend
   ||declaration

--- Comment #1 from Nathan Sidwell  ---
I forgot the link to DR1906, which is now determined to be NAD

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1906

[Bug c++/84796] ICE in a template parameter pack expansion

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

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

Confirmed.  The bogus access is here in tsubst_pack_expansion:

11742 if (level <= levels)
11743   arg_pack = TMPL_ARG (args, level, idx);

(gdb) call debug_tree (args)
 
(gdb) p level
$5 = 1
(gdb) p idx
$6 = 0
(gdb) p levels
$7 = 1

Bisection with checked binaries shows this started with r208178; I'm able to
reproduce it with a checked build of gcc 7; it's only failing to show up for
regular gcc 7 builds since checking is turned off by default for release
builds.

[Bug tree-optimization/84830] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2388

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; it's hitting this assertion in compute_antic:
2387  /* Theoretically possible, but *highly* unlikely.  */
2388  gcc_checking_assert (num_iterations < 500);

Started with r253998.

[Bug c++/84835] [8 Regression] ICE in add_method, at cp/class.c:996

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/84835] [8 Regression] ICE in add_method, at cp/class.c:996

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
We should be resetting the language linkage to C++ before adding lambda members
(and the lambda type too?)

[Bug c++/84837] New: unqualified lookup in friend declaration

[nathan at gcc dot gnu.org]

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

Bug ID: 84837
   Summary: unqualified lookup in friend declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43635=edit
example

in a friend declaration of the form
class B::Y {
  friend int A::X::f (type);
}
(A & B are namespaces or enclosing classes).  what scopes are searched for
type?

[basic.lookup.unqual]p10, tells us we should search
  class A::X as for member lookup, then if not found perform an unqualified
lookup in the current scope -- that is B::Y, B, ::

We instead search A::X then B::Y then A then ::.

Other compilers also get this wrong in different ways.

The example fails to compile because we find non-types in scopes we should not
have searched.

[Bug c++/84835] [8 Regression] ICE in add_method, at cp/class.c:996

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||dmalcolm at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

Started somewhere between r251337 (unaffected) and r251347 (affected); possibly
r251340.

996   gcc_assert (!DECL_EXTERN_C_P (method));

(gdb) p method->decl_common.lang_specific->u.base.language
$16 = lang_c

[Bug c++/84836] [8 Regression] ICE in pop_local_binding, at cp/name-lookup.c:2054

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/84836] [8 Regression] ICE in pop_local_binding, at cp/name-lookup.c:2054

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||dmalcolm at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.  Started with r248687.

2054  gcc_assert (binding->type == decl);

(gdb) p ((struct lang_identifier*)id)->bindings->type
$8 = 

[Bug target/65146] alignment of _Atomic structure member is not correct

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to H.J. Lu from comment #7)
> > We need to first decide what we want out of i386 atomic.
> > Please send a post to
> > 
> > https://groups.google.com/forum/#!forum/ia32-abi
> 
> Did this ever get taken to the ABI group?
> 

I don't believe so.

[Bug target/65146] alignment of _Atomic structure member is not correct

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to H.J. Lu from comment #7)
> We need to first decide what we want out of i386 atomic.
> Please send a post to
> 
> https://groups.google.com/forum/#!forum/ia32-abi

Did this ever get taken to the ABI group?

GCC and Clang seem to give different results, so we have implementation
divergence causing ABI incompatibilities.

[Bug fortran/83939] Constraint C1290 (elemental function cannot be allocatable) not enforced

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
fixed on the 6-branch, 7-branch, and trunk.
Thanks for the bug report.

[Bug fortran/83939] Constraint C1290 (elemental function cannot be allocatable) not enforced

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Mar 12 18:26:28 2018
New Revision: 258457

URL: https://gcc.gnu.org/viewcvs?rev=258457=gcc=rev
Log:
2018-03-12  Steven G. Kargl  

PR fortran/83939
* resolve.c (resolve_fl_procedure): Enforce F2018:C15100.

2018-03-12  Steven G. Kargl  

PR fortran/83939
* gfortran.dg/pr83939.f90

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83939.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/84834] [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 43634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43634=edit
gcc8-pr84834.patch

Full untested patch.

[Bug libstdc++/71660] [6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Thiago Macieira from comment #14)
> It was trying to guard against exactly what you said above: that the
> alignment of a QAtomicInteger was exactly the same as the alignment of a
> plain T inside a struct, so one could replace a previous plain member with
> an atomic and keep binary compatibility. 

That is not expected to work.

> But it's clear now that atomic types may need extra alignment than the plain
> types. In hindsight, the check is unnecessary and should be removed; people
> should not expect to replace T with std::atomic or QAtomicInteger and
> keep ABI.

Agreed.

But what we do care about is comment 2, i.e. _Atomic(T) and std::atomic
should have the same alignment (both in an out of structs). Maybe that needs
the C front-end to change how _Atomic works, or maybe it needs the C++ library
to change how std::atomic works, but I want to keep this bug open while comment
2 gives different answers for C and C++.

[Bug middle-end/84834] [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
--- gcc/match.pd.jj 2018-03-06 08:06:13.0 +0100
+++ gcc/match.pd2018-03-12 19:18:24.144577077 +0100
@@ -3566,16 +3566,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (cond
   (ne (bit_and @0 integer_pow2p@1) integer_zerop)
-  integer_pow2p@2 integer_zerop)
- (with {
-int shift = (wi::exact_log2 (wi::to_wide (@2))
-- wi::exact_log2 (wi::to_wide (@1)));
-  }
-  (if (shift > 0)
-   (bit_and
-(lshift (convert @0) { build_int_cst (integer_type_node, shift); }) @2)
-   (bit_and
-(convert (rshift @0 { build_int_cst (integer_type_node, -shift); }))
@2
+  INTEGER_CST@2 integer_zerop)
+ (if (integer_pow2p (@2))
+  (with {
+ int shift = (wi::exact_log2 (wi::to_wide (@2))
+ - wi::exact_log2 (wi::to_wide (@1)));
+   }
+   (if (shift > 0)
+(bit_and
+ (lshift (convert @0) { build_int_cst (integer_type_node, shift); }) @2)
+(bit_and
+ (convert (rshift @0 { build_int_cst (integer_type_node, -shift); }))
+ @2)

 /* If we have (A & C) != 0 where C is the sign bit of A, convert
this into A < 0.  Similarly for (A & C) == 0 into A >= 0.  */
@@ -3595,8 +3597,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (cond
   (lt @0 integer_zerop)
-  integer_pow2p@1 integer_zerop)
- (if (!TYPE_UNSIGNED (TREE_TYPE (@0)))
+  INTEGER_CST@1 integer_zerop)
+ (if (integer_pow2p (@1)
+  && !TYPE_UNSIGNED (TREE_TYPE (@0)))
   (with {
 int shift = element_precision (@0) - wi::exact_log2 (wi::to_wide (@1)) -
1;
}

works for me.

[Bug fortran/83939] Constraint C1290 (elemental function cannot be allocatable) not enforced

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Mar 12 18:15:42 2018
New Revision: 258456

URL: https://gcc.gnu.org/viewcvs?rev=258456=gcc=rev
Log:
2018-03-12  Steven G. Kargl  

PR fortran/83939
* resolve.c (resolve_fl_procedure): Enforce F2018:C15100.

2018-03-12  Steven G. Kargl  

PR fortran/83939
* gfortran.dg/pr83939.f90

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83939.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/84834] [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c   |middle-end

--- Comment #3 from Richard Biener  ---
Confirmed.

/* If we have A < 0 ? C : 0 where C is a power of 2, convert
   this into a right shift or sign extension followed by ANDing with C.  */
(simplify
 (cond
  (lt @0 integer_zerop)
  integer_pow2p@1 integer_zerop)
 (if (!TYPE_UNSIGNED (TREE_TYPE (@0)))
  (with {
int shift = element_precision (@0) - wi::exact_log2 (wi::to_wide (@1)) - 1;
   }

wi:: only works for INTEGER_CSTs but integer_pow2p also returns nonzero
for _Complex numbers (unexpectedly).  The easiest fix is probably to
add a INTEGRAL_TYPE_P () check.

[Bug c++/84835] [8 Regression] ICE in add_method, at cp/class.c:996

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug c++/84836] [8 Regression] ICE in pop_local_binding, at cp/name-lookup.c:2054

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

[msebor at gcc dot gnu.org]

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

Bug 83456 Summary: -Wrestrict false positive on a non-overlapping memcpy in an 
inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83456

   What|Removed |Added

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

[Bug tree-optimization/83456] -Wrestrict false positive on a non-overlapping memcpy in an inline function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Patch committed in r258455.

[Bug tree-optimization/83456] -Wrestrict false positive on a non-overlapping memcpy in an inline function

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Mon Mar 12 18:04:16 2018
New Revision: 258455

URL: https://gcc.gnu.org/viewcvs?rev=258455=gcc=rev
Log:
PR tree-optimization/83456 - -Wrestrict false positive on a non-overlapping
memcpy in an inline function

gcc/ChangeLog:

PR tree-optimization/83456
* gimple-fold.c (gimple_fold_builtin_memory_op): Avoid warning
for perfectly overlapping calls to memcpy.
(gimple_fold_builtin_memory_chk): Same.
(gimple_fold_builtin_strcpy): Handle no-warning.
(gimple_fold_builtin_stxcpy_chk): Same.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Handle no-warning.

gcc/c-family/ChangeLog:

PR tree-optimization/83456
* gcc/c-family/c-common.c (check_function_restrict): Return bool.
Restore checking of bounded built-in functions.
(check_function_arguments): Also return the result
of warn_for_restrict.
* gcc/c-family/c-common.c (check_function_restrict): Return bool.
* gcc/c-family/c-warn.c (warn_for_restrict): Return bool.

gcc/testsuite/ChangeLog:

PR tree-optimization/83456
* c-c++-common/Wrestrict-2.c: Remove test cases.
* c-c++-common/Wrestrict.c: Same.
* gcc.dg/Wrestrict-12.c: New test.
* gcc.dg/Wrestrict-14.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-12.c
trunk/gcc/testsuite/gcc.dg/Wrestrict-14.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-warn.c
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wrestrict-2.c
trunk/gcc/testsuite/c-c++-common/Wrestrict.c
trunk/gcc/tree-ssa-strlen.c

[Bug c++/84836] New: [8 Regression] ICE in pop_local_binding, at cp/name-lookup.c:2054

[gs...@t-online.de]

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

Bug ID: 84836
   Summary: [8 Regression] ICE in pop_local_binding, at
cp/name-lookup.c:2054
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed before 20170618, gcc-7 compiles :


$ cat z1.cc
void foo (void)
{
  struct A;
  void A (int);
  void A (long);
}


$ gcc-7 -c z1.cc
$
$ gcc-8-20180311 -c z1.cc
z1.cc: In function 'void foo()':
z1.cc:5:16: internal compiler error: in pop_local_binding, at
cp/name-lookup.c:2054
   void A (long);
^
0x714919 pop_local_binding(tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:2054
0x6d7189 poplevel(int, int, int)
../../gcc/cp/decl.c:776
0x791d53 do_poplevel(tree_node*)
../../gcc/cp/semantics.c:451
0x792b2c finish_compound_stmt(tree_node*)
../../gcc/cp/semantics.c:1451
0x738887 cp_parser_compound_statement
../../gcc/cp/parser.c:11230
0x74a37e cp_parser_function_body
../../gcc/cp/parser.c:21778
0x74a37e cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21813
0x74ab40 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26828
0x74dce6 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26745
0x74dce6 cp_parser_init_declarator
../../gcc/cp/parser.c:19502
0x74ee0f cp_parser_simple_declaration
../../gcc/cp/parser.c:13057
0x74fba8 cp_parser_block_declaration
../../gcc/cp/parser.c:12883
0x7577ee cp_parser_declaration
../../gcc/cp/parser.c:12780
0x756356 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12656
0x75665f cp_parser_translation_unit
../../gcc/cp/parser.c:4561
0x75665f c_parse_file()
../../gcc/cp/parser.c:39005
0x80ce65 c_common_parse_file()
../../gcc/c-family/c-opts.c:1132

[Bug c/84834] [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r243255.

[Bug c++/84835] New: [8 Regression] ICE in add_method, at cp/class.c:996

[gs...@t-online.de]

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

Bug ID: 84835
   Summary: [8 Regression] ICE in add_method, at cp/class.c:996
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20170820 and 20170910 :


$ cat z1.cc
extern "C" { auto f = [](auto x) noexcept(noexcept(x)) { }; }


$ gcc-8-20170820 -c z1.cc
$
$ gcc-8-20180311 -c z1.cc
z1.cc:1:58: internal compiler error: in add_method, at cp/class.c:996
 extern "C" { auto f = [](auto x) noexcept(noexcept(x)) { }; }
  ^
0x691ae0 add_method(tree_node*, tree_node*, bool)
../../gcc/cp/class.c:996
0x6fc1db maybe_add_lambda_conv_op(tree_node*)
../../gcc/cp/lambda.c:1195
0x739da3 cp_parser_lambda_expression
../../gcc/cp/parser.c:10199
0x739da3 cp_parser_primary_expression
../../gcc/cp/parser.c:5261
0x744382 cp_parser_postfix_expression
../../gcc/cp/parser.c:7030
0x74bc5a cp_parser_unary_expression
../../gcc/cp/parser.c:8322
0x72bac9 cp_parser_cast_expression
../../gcc/cp/parser.c:9090
0x72c1dd cp_parser_binary_expression
../../gcc/cp/parser.c:9191
0x72c960 cp_parser_assignment_expression
../../gcc/cp/parser.c:9486
0x72d723 cp_parser_constant_expression
../../gcc/cp/parser.c:9770
0x72db47 cp_parser_initializer_clause
../../gcc/cp/parser.c:21916
0x72fffb cp_parser_initializer
../../gcc/cp/parser.c:21856
0x74d8eb cp_parser_init_declarator
../../gcc/cp/parser.c:19677
0x74ee0f cp_parser_simple_declaration
../../gcc/cp/parser.c:13057
0x74fba8 cp_parser_block_declaration
../../gcc/cp/parser.c:12883
0x7577ee cp_parser_declaration
../../gcc/cp/parser.c:12780
0x756356 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12656
0x756d27 cp_parser_linkage_specification
../../gcc/cp/parser.c:13842
0x757824 cp_parser_declaration
../../gcc/cp/parser.c:12717
0x756356 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12656

[Bug c/84834] [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  ---
Programs linked with glibc 2.26 will continue to work as expected.  
_LIB_VERSION has become a compat symbol, so it's newly linked programs 
that can't set it any more (and in static libm, and libm for new ports 
such as RISC-V, all the code relating to _LIB_VERSION and matherr is 
completely gone).

To use matherr with old glibc you needed to set _LIB_VERSION to _SVID_ 
(default is _POSIX_, libieee.a set it to _IEEE_, the difference between 
_POSIX_ and _IEEE_ is that _IEEE_ disables errno setting for *some* 
functions, not all).

[Bug c/84834] New: [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

[gs...@t-online.de]

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

Bug ID: 84834
   Summary: [7/8 Regression] ICE: tree check: expected
integer_cst, have complex_cst in to_wide, at
tree.h:5527
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161204 and 20161211 :


$ cat z1.c
_Complex int foo (int a)
{
  return (a < 0);
}


$ gcc-7-20161204 -c z1.c
$
$ gcc-8-20180311 -c z1.c
z1.c: In function 'foo':
z1.c:3:3: internal compiler error: tree check: expected integer_cst, have
complex_cst in to_wide, at tree.h:5527
   return (a < 0);
   ^~
0x606bdf tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9337
0x965404 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3388
0x965404 wi::to_wide(tree_node const*)
../../gcc/tree.h:5527
0x116b24d generic_simplify_COND_EXPR
.../gcc/generic-match.c:46976
0x11a6e50 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
.../gcc/generic-match.c:47541
0x943cc5 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:11324
0x946113 fold_build3_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:12388
0x94ac53 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9381
0x9651b4 fold(tree_node*)
../../gcc/fold-const.c:11965
0x7202b4 convert_and_check(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:1543
0x6c18e5 convert_for_assignment
../../gcc/c/c-typeck.c:6565
0x6c371d c_finish_return(unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:10166
0x70ce54 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5453
0x7083ca c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5078
0x708b16 c_parser_compound_statement
../../gcc/c/c-parser.c:4912
0x70a2c0 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2341
0x712733 c_parser_external_declaration
../../gcc/c/c-parser.c:1644
0x7131a9 c_parser_translation_unit
../../gcc/c/c-parser.c:1524
0x7131a9 c_parse_file()
../../gcc/c/c-parser.c:18411
0x76ddb5 c_common_parse_file()
../../gcc/c-family/c-opts.c:1132

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Mon, 12 Mar 2018, carlos at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
> 
> --- Comment #8 from Carlos O'Donell  ---
> (In reply to Florian Weimer from comment #6)
> > (In reply to Jakub Jelinek from comment #5)
> > > -mieee-fp does affect code generation on x86 and m68k, but I don't see how
> > > it is related to any changes in glibc.
> > > And besides code generation changes it affects whether -lieee is linked in
> > > or not.
> > 
> > It matters from the users' point of view.  I think it's better to give them
> > a build error when they use unsupported functionality, rather than giving
> > the wrong results at run time.  The overloaded nature of -mieee-fp makes
> > this difficult to achieve, though.
> 
> I agree.
> 
> My own opinion is that I would rather see a link-time failure for user
> applications that use any interfaces that are no longer supported for building
> new programs.
> 
> Therefore it is that -mieee-fp is no longer supported with glibc 2.27, you
> cannot use it, and it will not work. You must XFAIL any such tests if you are
> using a glibc with the obsoleted matherr, _LIB_VERSION, and libieee.a
> functionality.

So if a program linked gainst -lieee and glibc 2.26 is run on a system
with glibc 2.27 and thus obsolete/removed matherr support will it receive
any error at runtime or does it silently fail to run properly?  At
least libieee.a doesn't seem to provide anything that would cause such
a program fail to run?

If there's indeed no visible error besides matherr no longer being invoked
I see no issue with glibc providing an empty stub-libieee.a.

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug ipa/84833] New: [8 Regression] target_clones regression since r251047

[jakub at gcc dot gnu.org]

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

Bug ID: 84833
   Summary: [8 Regression] target_clones regression since r251047
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

__attribute__((noipa)) void
baz (void (*fn) (void))
{
  asm volatile ("" : "+g" (fn) : : "memory");
  fn ();
}

__attribute__((target_clones("arch=sandybridge", "default"))) static void
bar (void)
{
}

__attribute__((target_clones("arch=sandybridge", "default"))) void
foo (void)
{
  baz (bar);
}

int
main ()
{
}

no longer links.  Even previously it has been quite broken, as
57: 00400ae035 FUNCGLOBAL DEFAULT   13
bar._GLOBAL___baz.resolver
59: 00400ae035 IFUNC   GLOBAL DEFAULT   13 bar
were exported symbols even when the function actually were declared static, but
no it doesn't even link.

Another (though preexisting) bug is lack of optimization, if we have a call or
reference of a target_clones dispatcher in a function with the same
target_clones attribute (or maybe even just target attribute or similar), we
should optimize it at compile time into a reference to a particular target
clone.

Got into this from PR78808, the above is just an approximation of why PR78808
doesn't work on the trunk either.

[Bug tree-optimization/84817] gcc-8-8-20180310-1 FTBFS on GNU/Hurd due to commit: PR target/83712

[svante.signell at gmail dot com]

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

Svante Signell  changed:

   What|Removed |Added

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

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  ---
As I said in https://sourceware.org/bugzilla/show_bug.cgi?id=22951#c2 I 
think uses of -mieee-fp are cargo-culted just like those of -lieee.  I 
think the appropriate GCC fix is simply to make -mieee-fp not imply -lieee 
(unconditionally, not depending on whether target libc provides 
libieee.a); -lieee never reliably avoided errno setting, only for some 
functions.

[Bug tree-optimization/84817] gcc-8-8-20180310-1 FTBFS on GNU/Hurd due to commit: PR target/83712

[svante.signell at gmail dot com]

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

Svante Signell  changed:

   What|Removed |Added

Summary|PR tree-optimization/84526: |gcc-8-8-20180310-1 FTBFS on
   |gcc-8-8-20180310-1 FTBFS on |GNU/Hurd due to commit: PR
   |GNU/Hurd by removing "dead" |target/83712
   |code|

--- Comment #2 from Svante Signell  ---
Hello,

It seem like the changed file did not make the build to complete.
However, I found the revert patch you referred to:
gcc.git-b12c2c48c2c6aa1db9e6c50f6b26330d9caf.patch
and applied it to gcc-8-8-20180310-1, and the build completed. I did also build
gcc-8-8-20180312-2 and that went fine too. So you can close this bug now.

Thanks!

[Bug c++/84782] Rejects a maybe C++ code snippet

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Slight correction: the using-declaration doesn't have no effect in general, but
it shouldn't change the result of this program.

[Bug c++/84832] Base class member function incorrectly introduced by using-declarator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
EDG also accepts the code. I'm confirming this as an accepts-invalid bug, but
it's possible this is a defect in the standard instead and GCC and EDG are
doing the right thing.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
get_stored_val isn't called at all for me.  known_subrange_p is just never
true, there is no overlap between any of the stores.

[Bug target/18141] mips64-none-elf-gcc: Excessive NOPs with -march=r3000

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Dinar Temirbulatov from comment #2)
> proposed fix for this issue posted here
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01693.html and the GNU
> copyright assignment form available upon request.

Did your copyright assignment ever go through?

[Bug c++/84782] Rejects a maybe C++ code snippet

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Reduced:

struct c { static constexpr bool value = false; };

template  a declval();

template () = 1)>   // #1
  void h(int);

template 
  c h(...);

template using i = decltype(h(0));

struct k {
  k(const k &) = default;
  void operator=(k &&) = delete;
};
struct l : k {
  using k::operator=;   // #2
};

struct G {
  G(const G &);
  l q;
};

int j = i::value;

G::G(const G &) = default;



x.cc:28:1: note: ‘G::G(const G&)’ is implicitly deleted because the default
definition would be ill-formed:
 G::G(const G &) = default;
 ^
x.cc:28:1: error: use of deleted function ‘constexpr l::l(const l&)’
x.cc:17:7: note: ‘constexpr l::l(const l&)’ is implicitly declared as deleted
because ‘l’ declares a move constructor or move assignment operator
 class l : k {
   ^


The error is malformed for a start, we issue a note that doesn't follow any
error.

There seem to be two things involved here. The error is apparently triggered by
the SFINAE check at #1 which should silently fail instead of giving an error.
It seems to be an error because of the "using k::operator=;" line at #2 which
should have no effect.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su  ---
I still see the ICE with rev. 258447. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180312 (experimental) [trunk revision 258447] (GCC) 
$ 
$ gcctk -O3 -c small.c
during RTL pass: dse1
small.c: In function ‘fn1’:
small.c:12:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc95b2b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x146b5fb smallest_int_mode_for_size
../../gcc-source-trunk/gcc/machmode.h:842
0x146b5fb find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1701
0x146b5fb get_stored_val
../../gcc-source-trunk/gcc/dse.c:1847
0x146e183 record_store
../../gcc-source-trunk/gcc/dse.c:1557
0x146f08e scan_insn
../../gcc-source-trunk/gcc/dse.c:2545
0x146f08e dse_step1
../../gcc-source-trunk/gcc/dse.c:2657
0x146f08e rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3574
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[matz at gcc dot gnu.org]

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

--- Comment #9 from Michael Matz  ---
(In reply to Carlos O'Donell from comment #8)
> > It matters from the users' point of view.  I think it's better to give them
> > a build error when they use unsupported functionality, rather than giving
> > the wrong results at run time.  The overloaded nature of -mieee-fp makes
> > this difficult to achieve, though.
> 
> I agree.

Except, of course, that it isn't unsupported functionality.  On the contrary,
it now is the default in glibc.

Even worse: the non-libm aspect of -mieee-fp is also the default on linux.  So
giving -mieee-fp is a no-op on new glibc, while it is not one on old glibc
(adding libieee.a).  I don't see how the current link error can be avoided
in a sensible way from within gcc (sensible includes: "works with old and new
glibc").

[Bug debug/83941] Debug info generated with -flto contains useless forwarders

[jhonmerced5 at gmx dot com]

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

Jhon Merced  changed:

   What|Removed |Added

 CC||jhonmerced5 at gmx dot com

--- Comment #4 from Jhon Merced  ---
"Richard, I would go for dwg solution first as you suggested.

Jhon
http://datingsitegratis.be/

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[carlos at redhat dot com]

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

--- Comment #8 from Carlos O'Donell  ---
(In reply to Florian Weimer from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > -mieee-fp does affect code generation on x86 and m68k, but I don't see how
> > it is related to any changes in glibc.
> > And besides code generation changes it affects whether -lieee is linked in
> > or not.
> 
> It matters from the users' point of view.  I think it's better to give them
> a build error when they use unsupported functionality, rather than giving
> the wrong results at run time.  The overloaded nature of -mieee-fp makes
> this difficult to achieve, though.

I agree.

My own opinion is that I would rather see a link-time failure for user
applications that use any interfaces that are no longer supported for building
new programs.

Therefore it is that -mieee-fp is no longer supported with glibc 2.27, you
cannot use it, and it will not work. You must XFAIL any such tests if you are
using a glibc with the obsoleted matherr, _LIB_VERSION, and libieee.a
functionality.

Opinions vary though, since -mieee-fp is intended to require IEEE semantics,
and that is now the default in glibc, we could just keep silently supporting
-mieee-fp as the default.

I think that Joseph will need to comment on thoughts about the behaviour of
using deprecated interfaces.

[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

[david.applegate at woodplc dot com]

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

david.applegate at woodplc dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from david.applegate at woodplc dot com ---
Actually forget I mentioned that second bug - fixing it would cause us much
more pain than the first fix did!

Thanks for your time.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

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

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

--- Comment #7 from Andreas Schwab  ---
On m68k -mieee-fp is a no-op.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[fw at gcc dot gnu.org]

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

--- Comment #6 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #5)
> -mieee-fp does affect code generation on x86 and m68k, but I don't see how
> it is related to any changes in glibc.
> And besides code generation changes it affects whether -lieee is linked in
> or not.

It matters from the users' point of view.  I think it's better to give them a
build error when they use unsupported functionality, rather than giving the
wrong results at run time.  The overloaded nature of -mieee-fp makes this
difficult to achieve, though.

[Bug fortran/84778] Issue with character arguments of specified length (does not compile)

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Mon, Mar 12, 2018 at 10:16:19AM +, david.applegate at woodplc dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778
> 
> --- Comment #3 from david.applegate at woodplc dot com ---
> Thanks for the reply and the clarification.  
> 
> I have two comments to make regarding this if I may...
> 
> 1) Previous gfortran compilers were happy with the code.
>I also tested g95 and Ifort (admittedly aged versions
>of both).  Ifort also refused to compile the code while
>g95 did compile the code (you may not care I guess).  It
>is slightly irritating that gfortran is essentially not
>backwards compatible with previous versions.  Maybe
>gfortran should compile this code unless the users
>specify one of the -std=f95/f2003/f2008 switches?

If we wrapped every bug fix in a -std option, the gfortran
source code would become unreadable.  

> 2) What about array declaration? Gfortran 7.3 is happy to
>compile the following code, which presumably does not
>conform to the standard you mention, while Ifort refuses
>to compile this code:

It seems that you have found another bug.  It may one day
be fixed.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
-mieee-fp does affect code generation on x86 and m68k, but I don't see how it
is related to any changes in glibc.
And besides code generation changes it affects whether -lieee is linked in or
not.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[fw at gcc dot gnu.org]

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

--- Comment #4 from Florian Weimer  ---
Does -mieee-fp still impact code generation on i386?  What about x86-64 with
SSE2?

I would expect that existing users of -mieee-fp receive an error when they
compile and link with a upgraded glibc, so I don't think the missing archive is
necessarily a problem we need to fix.

However, if there is no way to request the code generator to change behavior,
then we have a problem.

[Bug c++/84783] Missing _mm256_permutexvar_epi64() intrinsic for AVX512VL

[sebastian.peryt at intel dot com]

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

--- Comment #2 from Sebastian Peryt  ---
Oh, ok I see now version in report. Sorry, my mistake. It was added to trunk
and not backported.

[Bug c++/84783] Missing _mm256_permutexvar_epi64() intrinsic for AVX512VL

[sebastian.peryt at intel dot com]

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

--- Comment #1 from Sebastian Peryt  ---
It was added in r249759 I can see it in latest trunk. Maybe you have some old
version of GCC?

[Bug target/83451] FAIL: gfortran.dg/matmul_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
It turns out we adjust the subreg in pa_emit_move_sequence but never emit
an insn with it.  The code just falls through and emits the unrecognizable
insn.  Testing a fix.

[Bug target/84827] [7/8 Regression] ICE in extract_insn, at recog.c:2311

[jakub at gcc dot gnu.org]

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

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 43633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43633=edit
gcc8-pr84827.patch

Untested fix.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[matz at gcc dot gnu.org]

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

--- Comment #3 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #2)
> I'd say the right thing is to keep libieee.a around, even if it will be an
> empty ar archive.

Agreed.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I'd say the right thing is to keep libieee.a around, even if it will be an
empty ar archive.

GCC is not the linker and doesn't have the library search logic the linker has,
so it is hard to add -lieee for -mieee-fp only if it exists and not otherwise.

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #1 from Michael Matz  ---
Note that the old libieee.a (which was only an object) set the global variable
_LIB_VERSION to _IEEE_.  That variable is (or was) checked by various libm
routines to conditionalize behaviour in error cases, which is the purpose of
-mieee-fp.  So that's what warranted the inclusion of -lieee in the past.

The change removing libieee from glibc also removed all handling of that global
variable, so the right thing to do for gcc is to not link against it if it
doesn't exist.  Which is of course a problem, as then you can't update glibc
without having to rebuild gcc :-/

[Bug c++/84832] New: Base class member function incorrectly introduced by using-declarator

[jaak at ristioja dot ee]

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

Bug ID: 84832
   Summary: Base class member function incorrectly introduced by
using-declarator
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaak at ristioja dot ee
  Target Milestone: ---

struct Base {
template 
void f(T &&) const {}
};

struct Derived: Base {
template 
void f(T &&) const {}

using Base::f;
};

int main() {
Derived const cd;
cd.f('x');
}

The following compiles fine with GCC and -std=c++11, but not with Clang. User
liliscent over at https://stackoverflow.com/q/49235124/3919155 thinks this is a
GCC bug, because Base::f should not be introduced by the using-declarator
because of [namespace.udecl]:

> When a using-declarator brings declarations from a
> base class into a derived class, member functions
> and member function templates in the derived class
> override and/or hide member functions and member
> function templates with the same name, parameter-
> type-list, cv-qualification, and ref-qualifier (if
> any) in a base class (rather than conflicting).
> Such hidden or overridden declarations are excluded
> from the set of declarations introduced by the
> using-declarator.

[Bug target/45616] internal compiler error: in note_invalid_constants, at config/arm/arm.c:11243

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Eric Gallager  ---
(In reply to Ian Bolton from comment #6)
> Technically, this is ICE on invalid code, but a more user-friendly error
> would be better.  As it happens, one has been added to trunk, as of 16th
> June.
> 
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01501.html
> 
> I will backport it to 4.5, unless Mr Brook wants to.

4.5 branch is closed, so a backport is unnecessary. Closing as FIXED.

[Bug target/84827] [7/8 Regression] ICE in extract_insn, at recog.c:2311

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:

/* PR 84827 */
/* { dg-do compile } */
/* { dg-options "-Ofast -fno-fp-int-builtin-inexact -ftrapping-math
-fno-associative-math" } */

long double
foo (long double a)
{
  return __builtin_roundl (a);
}

[Bug c++/84355] [7/8 Regression] ICE with failing template argument deduction

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Mar 12 14:40:45 2018
New Revision: 258451

URL: https://gcc.gnu.org/viewcvs?rev=258451=gcc=rev
Log:
PR c++/84355 - ICE with deduction for member class template.

* pt.c (tsubst) [TEMPLATE_TYPE_PARM]: Always substitute into
CLASS_PLACEHOLDER_TEMPLATE.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32

[zsojka at seznam dot cz]

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

--- Comment #9 from Zdenek Sojka  ---
(In reply to Segher Boessenkool from comment #8)
> Created attachment 43631 [details]
> proposed patch
> 
> I cannot reproduce that exact generated code; maybe it needs tuning for some
> particular CPU?
> 
> Could you try the attached patch?  Thanks!

I can confirm that r258444 FAILs, but r258449+patch PASSes the testcases (both
original and reduced).

[Bug c++/84802] [8 Regression] ICE in gimplify_decl_expr since r251433

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed, thanks.

[Bug c++/84820] [6/7/8 Regression] Bogus pointer-to-member accepted within template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-12
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug rtl-optimization/84806] [8 Regression] r258390 caused internal compiler error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
If it started with r258390, then it must have been fixed by r258415 which was
reversion thereof.

[Bug target/84828] ICE in verify_flow_info at gcc/cfghooks.c:265

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-12
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43632=edit
gcc8-pr84828.patch

Untested fix.

[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #8 from Segher Boessenkool  ---
Created attachment 43631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43631=edit
proposed patch

I cannot reproduce that exact generated code; maybe it needs tuning for some
particular CPU?

Could you try the attached patch?  Thanks!

[Bug c++/84676] [6/7/8 Regression] internal compiler error: Segmentation fault (build_new_op_1)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/84485] [6 Regression] Vectorising zero-stride rmw operation

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[6/7 Regression]|[6 Regression] Vectorising
   |Vectorising zero-stride rmw |zero-stride rmw operation
   |operation   |

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Applied to GCC 7 so far.

[Bug tree-optimization/84485] [6/7 Regression] Vectorising zero-stride rmw operation

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Mar 12 13:50:52 2018
New Revision: 258450

URL: https://gcc.gnu.org/viewcvs?rev=258450=gcc=rev
Log:
Don't vectorise zero-step rmw operations (PR 84485)

GCC 6 and 7 would vectorise:

void
f (unsigned long incx, unsigned long incy,
   float *restrict dx, float *restrict dy)
{
  unsigned long ix = 0, iy = 0;
  for (unsigned long i = 0; i < 512; ++i)
{
  dy[iy] += dx[ix];
  ix += incx;
  iy += incy;
}
}

without first proving that incy is nonzero.  This is a regression from
GCC 5.  It was fixed on trunk in r256644, which versioned the loop based
on whether incy is zero, but that's obviously too invasive to backport.
This patch instead bails out for possibly-zero steps in the place that
trunk would try a check for zeroness.

Also, the patch makes vect_analyze_data_ref_access check safelen
as well as force_vectorize.

2018-03-12  Richard Sandiford  

gcc/
PR tree-optimization/84485
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Return
true for zero dependence distances if the step might be zero,
and if there is no metadata that guarantees correctness.
(vect_analyze_data_ref_access): Check safelen as well as
force_vectorize.

gcc/testsuite/
PR tree-optimization/84485
* gcc.dg/vect/pr84485.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr84485.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-data-refs.c