[Bug c++/81836] New: ill-formed qualified name not diagnosed

[g...@arne-mertz.de]

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

Bug ID: 81836
   Summary: ill-formed qualified name not diagnosed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@arne-mertz.de
  Target Milestone: ---

Consider the following code:

typedef int foo;
namespace Foo {
int f();
foo g();
}

int ::Foo::f() { return 0; }
foo ::Foo::g() { return 1; }

This compiles in gcc 7.2.0 and 8.0.0 20170814, but should give an error in the
last line:

[expr.prim.id.qual] states, that `foo :: Foo` is a qualified ID. (`foo` is a
type-name). [basic.lookup.qual] then requires `foo` to denote a class,
enumeration or namespace. 

Clang, MSVC (and IAR) give diagnostics for this, see
https://godbolt.org/g/vhW9si

(`int :: Foo` is not a qualified ID because `int` is only a
simple-type-specifier, [dcl.type.simple])

But also consider open issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1828

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/14/2017 04:22 PM, Eric Gallager wrote:

I'm emailing this manually to the list because Bugzilla is down and I
can't file a bug on Bugzilla about Bugzilla being down. The error
message looks like this:


Bugzilla and the rest of gcc.gnu.org have been down much of
the afternoon/evening due to a hard drive upgrade (the old disk
apparently failed).  You're not the only one who found out about
it the hard way.  I (and I suspect most others) also discovered
it when things like Git and SVN (and Bugzilla) stopped working.

I've CC'd the gcc list to let others know (not sure what list
to subscribe to in order to get a heads up on these kinds of
maintenance issues).

Martin



Software error:

Can't connect to the database.
Error: Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)
  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?


For help, please send mail to the webmaster
(sourcemas...@sourceware.org), giving this error message and the time
and date of the error.

Unfortunately, the email address listed for the webmaster,
, sends me its own error message when I
try to email it, because the address apparently doesn't exist. I'm
forwarding a copy of the failure email with this message. Is there a
different address I should be emailing instead?

Thanks,
Eric Gallager

-- Forwarded message --
From: mailer-dae...@sourceware.org
Date: 14 Aug 2017 22:03:54 -
Subject: failure notice
To: eg...@gwmail.gwu.edu

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 24677 invoked by uid 89); 14 Aug 2017 22:03:52 -
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.5 required=5.0
tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no
version=3.3.2 spammy=
X-Spam-Status: No, score=0.5 required=5.0
tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no
version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level:
X-HELO: mail-wm0-f42.google.com
Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com)
(74.125.82.42)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon,
14 Aug 2017 22:03:51 +
Received: by mail-wm0-f42.google.com with SMTP id i66so3361599wmg.0
for ; Mon, 14 Aug 2017 15:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gwmail-gwu-edu.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=;
b=cvRTbJxAB1UKTO01xqOGTtvgLjbLLOumX/FUdM3ruLkvMpJx6QiO7X51cU6X6jcx24
 ReoVRxaW8NwWcVJts9JB5tPJSg/8+ljL8ywMoa9Aa6S1MQ4PS246aVgKM5aUNmaB1E+u
 NrQMAmsxixJG/wmrAnSpQ/imIt7XNHRBNnZ5/B1JiGAt3ChjHwTNKV/9W4fxydsJL9BE
 iL9D/duAl6C/RAvBPQ5BC0Kv+/HtzhH8bwgElbjP93hMJk/nAfceI7Rh/4zIgY5V6ZHS
 E7LzrUetB7aeyzdlTy6i/3Lsyb0wnUuocZdZtGndQD24WSngk3fInlHwWrcUVdTpRMQ5
 e4tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=;
b=GQbdg3EVSV+aMfKeSffGxae54jos3nNUt3qQWoSthUOEFy57YAeV5Fn86IOYLTw4fI
 gZKi7samoFHs0yHdF4sawi+xVMfZMzGPqGrJjsAIHYSE9T+o9vx0cEJPhPs0rswqinCO
 WovmT8Kh1jNEaIyxLwZGk07lt5oyWTk72zaT+CxWjamKbLJzDfqWMfpahDuTVI74QQie
 m8qtMTBQjek1Di51mxiBcuaLlr1xNqwrVS3JQEjdl2NCOBEDodLosGkUJCFR29hw6EAK
 ag3Lo96yUeNlfjOXv8/FYbCTrbcrhxbms02n0p3oK3cSHkoqZKcUOQQJzuNq0c38W9PU
 6A0w==
X-Gm-Message-State: AHYfb5ilSTxPFsi8yTAJsSJ6LpZu+DahzJygxoF6Q5usa2PIRZDQhD5i
b5akwEZnwfnttac6yAR/os3Kbj3Gqwbh
X-Received: by 10.80.215.68 with SMTP id i4mr25610854edj.258.1502748228995;
 Mon, 14 Aug 2017 15:03:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.129.227 with HTTP; Mon, 14 Aug 2017 15:03:48 -0700 (PDT)
From: Eric Gallager 
Date: Mon, 14 Aug 2017 18:03:48 -0400
Message-ID: 

[Bug middle-end/81596] backwards threader misses simple copy within the same BB

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Jump threading is a fairly high overhead solution for this problem.  Simple
const/copy propagation is a better solution in cases like this IMHO.

The overhead could be reduced with some changes to the updating algorithm that
I want to implement, but haven't yet.  So perhaps keep it open as a low
priority issue.

[Bug demangler/81835] New: cxxabi.h has invalid link in comment.

[chrisj at rtems dot org]

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

Bug ID: 81835
   Summary: cxxabi.h has invalid link in comment.
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisj at rtems dot org
  Target Milestone: ---

Tiny issue.

Looking over cxxabi.h I noticed a link in a comment about __cxa_demangle is not
valid anymore:

   *  See http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch39.html
   *  for other examples of use.

I am looking for the implementation of the demangler code we have on our
mebedded targets in RTEMS. A pointer to that location would be most welcomed.

Thanks
Chris

[Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Eric Gallager]

I'm emailing this manually to the list because Bugzilla is down and I
can't file a bug on Bugzilla about Bugzilla being down. The error
message looks like this:

Software error:

Can't connect to the database.
Error: Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)
  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?


For help, please send mail to the webmaster
(sourcemas...@sourceware.org), giving this error message and the time
and date of the error.

Unfortunately, the email address listed for the webmaster,
, sends me its own error message when I
try to email it, because the address apparently doesn't exist. I'm
forwarding a copy of the failure email with this message. Is there a
different address I should be emailing instead?

Thanks,
Eric Gallager

-- Forwarded message --
From: mailer-dae...@sourceware.org
Date: 14 Aug 2017 22:03:54 -
Subject: failure notice
To: eg...@gwmail.gwu.edu

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 24677 invoked by uid 89); 14 Aug 2017 22:03:52 -
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.5 required=5.0
tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no
version=3.3.2 spammy=
X-Spam-Status: No, score=0.5 required=5.0
tests=RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no
version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level:
X-HELO: mail-wm0-f42.google.com
Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com)
(74.125.82.42)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon,
14 Aug 2017 22:03:51 +
Received: by mail-wm0-f42.google.com with SMTP id i66so3361599wmg.0
for ; Mon, 14 Aug 2017 15:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gwmail-gwu-edu.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=;
b=cvRTbJxAB1UKTO01xqOGTtvgLjbLLOumX/FUdM3ruLkvMpJx6QiO7X51cU6X6jcx24
 ReoVRxaW8NwWcVJts9JB5tPJSg/8+ljL8ywMoa9Aa6S1MQ4PS246aVgKM5aUNmaB1E+u
 NrQMAmsxixJG/wmrAnSpQ/imIt7XNHRBNnZ5/B1JiGAt3ChjHwTNKV/9W4fxydsJL9BE
 iL9D/duAl6C/RAvBPQ5BC0Kv+/HtzhH8bwgElbjP93hMJk/nAfceI7Rh/4zIgY5V6ZHS
 E7LzrUetB7aeyzdlTy6i/3Lsyb0wnUuocZdZtGndQD24WSngk3fInlHwWrcUVdTpRMQ5
 e4tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=A6iFIzlnSazSObmM6Wb7tDW+ZAb4ojY1zG6bxpdCLCQ=;
b=GQbdg3EVSV+aMfKeSffGxae54jos3nNUt3qQWoSthUOEFy57YAeV5Fn86IOYLTw4fI
 gZKi7samoFHs0yHdF4sawi+xVMfZMzGPqGrJjsAIHYSE9T+o9vx0cEJPhPs0rswqinCO
 WovmT8Kh1jNEaIyxLwZGk07lt5oyWTk72zaT+CxWjamKbLJzDfqWMfpahDuTVI74QQie
 m8qtMTBQjek1Di51mxiBcuaLlr1xNqwrVS3JQEjdl2NCOBEDodLosGkUJCFR29hw6EAK
 ag3Lo96yUeNlfjOXv8/FYbCTrbcrhxbms02n0p3oK3cSHkoqZKcUOQQJzuNq0c38W9PU
 6A0w==
X-Gm-Message-State: AHYfb5ilSTxPFsi8yTAJsSJ6LpZu+DahzJygxoF6Q5usa2PIRZDQhD5i
b5akwEZnwfnttac6yAR/os3Kbj3Gqwbh
X-Received: by 10.80.215.68 with SMTP id i4mr25610854edj.258.1502748228995;
 Mon, 14 Aug 2017 15:03:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.129.227 with HTTP; Mon, 14 Aug 2017 15:03:48 -0700 (PDT)
From: Eric Gallager 
Date: Mon, 14 Aug 2017 18:03:48 -0400
Message-ID: 

[Bug c++/81850] New: OpenMP target enter data compilation issues

[thorstenkurth at me dot com]

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

Bug ID: 81850
   Summary: OpenMP target enter data compilation issues
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thorstenkurth at me dot com
  Target Milestone: ---

Created attachment 41990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41990=edit
Test case

Dear Sir/Madam,

g++ 7.1.1 cannot compile correct OpenMP 4.5 code. I have attached a small
example program I initially developer to demonstrate a compiler bug for XLC.
GCC throws the following error message on compilation:

g++ -O2 -std=c++11 -fopenmp -foffload=nvptx-none -c aclass.cpp -o aclass.o
In file included from aclass.h:2:0,
 from aclass.cpp:1:
masterclass.h: In member function 'void master::allocate(const unsigned int&)':
masterclass.h:10:50: error: 'master::data' is not a variable in 'map' clause
 #pragma omp target enter data map(alloc: data[0:size*sizeof(double)])
  ^~~~
masterclass.h:10:9: error: '#pragma omp target enter data' must contain at
least one 'map' clause
 #pragma omp target enter data map(alloc: data[0:size*sizeof(double)])
 ^~~
masterclass.h: In member function 'void master::deallocate()':
masterclass.h:15:51: error: 'master::data' is not a variable in 'map' clause
 #pragma omp target exit data map(release: data[:0])
   ^~~~
masterclass.h:15:9: error: '#pragma omp target exit data' must contain at least
one 'map' clause
 #pragma omp target exit data map(always, release: data[:0])


To me it seems that it cannot recognize the "alloc" clause. 

Best Regards
Thorsten Kurth

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Mon Aug 14 20:21:44 2017
New Revision: 251100

URL: https://gcc.gnu.org/viewcvs?rev=251100=gcc=rev
Log:
PR c/81117 - Improve buffer overflow checking in strncpy - part 2

gcc/ChangeLog:

PR c/81117
* doc/extend.texi (attribute nonstring): Document new attribute.

gcc/c-family/ChangeLog:

PR c/81117
* c-attribs.c (c_common_attribute_table): Add nonstring entry.
(handle_nonstring_attribute): New function.

gcc/testsuite/ChangeLog:

PR c/81117
* c-c++-common/attr-nonstring-1.c: New test.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/38592] eliminate some string comparisons

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Component|fortran |tree-optimization

--- Comment #8 from Thomas Koenig  ---
I think the best place to fix this is in the middle-end.

Here is a C test case:

int yes()
{
  char a[3];
  __builtin_memmove (a, "yes", 3);
return __builtin_memcmp(a,"yes",3);
}

This generates a memcmp with current trunk:

.LC0:
.string "yes"
.text
.p2align 4,,15
.globl  yes
.type   yes, @function
yes:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$25977, %eax
movl$3, %edx
leaq13(%rsp), %rdi
movl$.LC0, %esi
movw%ax, 13(%rsp)
movb$115, 15(%rsp)
callmemcmp
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   yes, .-yes
.ident  "GCC: (GNU) 8.0.0 20170730 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug c++/45113] absent or confusing diagnostics of invalid template argument list in implicit template class instantiation

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Clang has a nice error for test3

45113_3.cc:2:15: error: type-id cannot have a name
typedef U A;
  ^
45113_3.cc:2:21: error: type-id cannot have a name
typedef U A;
^
2 errors generated.

[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly

[roland.illig at gmx dot de]

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

--- Comment #5 from Roland Illig  ---
Thank you very much. The patch looks great.

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Mon Aug 14 18:35:13 2017
New Revision: 251098

URL: https://gcc.gnu.org/viewcvs?rev=251098=gcc=rev
Log:
PR c/81117 - Improve buffer overflow checking in strncpy - part 1

gcc/ChangeLog:

PR c/81117
* tree-diagnostic.c (default_tree_printer): Handle %G.
* gimple-pretty-print.h (percent_G_format): Declare new function.
* gimple-pretty-print.c (percent_G_format): Define.
* tree-pretty-print.c (percent_K_format): Add argument.

gcc/c/ChangeLog:

PR c/81117
* c-objc-common.c (c_objc_common_init): Handle 'G'.

gcc/c-family/ChangeLog:

PR c/81117
* c-format.h (T89_G): New macro.
* c-format.c (local_gcall_ptr_node): New variable.
(init_dynamic_diag_info): Initialize it.

gcc/cp/ChangeLog:

PR c/81117
* error.c (cp_printer): Handle 'G'.

gcc/testsuite/ChangeLog:

PR c/81117
* gcc.dg/format/gcc_diag-10.c: Exercise %G.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/c-family/c-format.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-objc-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/gimple-pretty-print.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/gcc_diag-10.c
trunk/gcc/tree-diagnostic.c
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree-pretty-print.h

[Bug c++/26426] Type layout bug

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I don't think this is a bug. B is the primary base class for Z so has already
been allocated (as part of the Y subobject, in I-2b), and so the B base class
of the X subobject is not allocated as part of the X (in III).

https://itanium-cxx-abi.github.io/cxx-abi/abi.html#a17

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #10)

> I'll look into this a bit some more.  However, these insn should be rare, so
> do not expect any noticeable application speed-up ...

From the Agner lists, it is not clear if "bitop mem, imm" is faster than
"movabs r, imm + logic_op mem, r". Looking at several tables, it looks that
that it is not; for some AMD and older Intel targets, RMW bitop looses
considerably.

[Bug c++/45113] absent or confusing diagnostics of invalid template argument list in implicit template class instantiation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Roman Kononov from comment #0)
> $cat test1.cpp
> template struct is_same { static bool const
> value=false; };
> template struct is_same { static bool const value=true; };
> template struct U {};
> struct Q { typedef U C; };
> typedef char check[is_same::value ? 1 : -1];
> 
> $g++ -std=gnu++0x -c test1.cpp && echo $?
> 0
> 
> In 14.3.1, the Standard says: "A template-argument for a template-parameter
> which is a type shall be a type-id." The test must fail compilation, and
> Q::C can not be int.

This now fails with:
$ /usr/local/bin/g++ -c -std=gnu++0x 45113.cc
45113.cc:4:33: error: template argument 1 is invalid
 struct Q { typedef U C; };
 ^
$

> 
> $cat test2.cpp
> template struct U {};
> typedef U B;
> 
> $g++ -std=gnu++0x -c test2.cpp 
> test2.cpp:2:25: error: invalid type in declaration before ';' token
> 
> This message is confusing.

This message is now:
$ /usr/local/bin/g++ -c -std=gnu++0x 45113_2.cc
45113_2.cc:2:22: error: template argument 1 is invalid
 typedef U B;
  ^
$

> 
> $cat test3.cpp 
> template struct U {};
> typedef U A;
> 
> $g++ -c test3.cpp 
> test3.cpp:2:22: error: wrong number of template arguments (1, should be 2)
> test3.cpp:1:40: error: provided for 'template struct U'
> test3.cpp:2:25: error: invalid type in declaration before ';' token
> 
> These messages are confusing.

This message is now:
$ /usr/local/bin/g++ -c -std=gnu++0x 45113_3.cc
45113_3.cc:2:22: error: wrong number of template arguments (1, should be 2)
 typedef U A;
  ^
45113_3.cc:1:40: note: provided for ‘template struct U’
 template struct U {};
^
$

Which I guess is still kinda confusing. So test1.cpp and test2.cpp are fixed,
but confirming for test3.cpp.

[Bug tree-optimization/81849] missing -Wstringop-overflow writing to the last element of a struct

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is expected and I thought was documented a few times over as an GNU
extension.

[Bug target/68485] ICE while building gpsd package on microblaze

[wbx at openadk dot org]

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

--- Comment #7 from Waldemar Brodkorb  ---
I tried compiling gaps 3.16.
Are you compiling the minimal test case?
Can you show the command line you are using?

[Bug tree-optimization/81849] New: missing -Wstringop-overflow writing to the last element of a struct

[msebor at gcc dot gnu.org]

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

Bug ID: 81849
   Summary: missing -Wstringop-overflow writing to the last
element of a struct
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses buffer overflow when using string functions like strcpy and
strncpy to write to struct members other than the last one, but it fails to
detect the same buffer overflow when writing to an array that's the last member
of a struct even when the size of the array is known to be non-zero.  That's
apparently because some code abuses the last element array element as a
flexible array member.  This choice may be necessary to avoid runtime aborts
when using _FORTIFY_SOURCE but it is not necessary to avoid warnings.  Code
that does this should be changed to replace the array with a flexible array
member or with the zero-length array extension and the warning would help with
that transition.

If it's thought important to provide an escape hatch from the stricter warning
(I'm not convinced it is) it may be worth considering making an exception for
memcpy but warning on all other functions.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wunused z.c
struct A
{
  char a[8];
  void (*pf)(void);
};

void f (struct A *a, const char *s)
{
  __builtin_strncpy (a->a, s, sizeof *a);   // -Wstringop-overflow (good)
}

struct B
{
  void (*pf)(void);
  char a[8];
};

void g (struct B *b, const char *s)
{
  __builtin_strncpy (b->a, s, sizeof *b);   // missing warning
}
z.c: In function ‘f’:
z.c:9:3: warning: ‘__builtin_strncpy’ writing 16 bytes into a region of size 8
overflows the destination [-Wstringop-overflow=]
   __builtin_strncpy (a->a, s, sizeof *a);   // -Wstringop-overflow (good)
   ^~

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #25 from Ian Lance Taylor  ---
I have no particular concerns with dropping the bitfield code, but clearly it
has to be tested on a couple of little-endian platforms.

[Bug target/78804] [RX] -m64bit-doubles does not work

[dj at redhat dot com]

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

--- Comment #24 from DJ Delorie  ---
"olegendo at gcc dot gnu.org"  writes:
> I don't know why it was decided to use this ABI.  Maybe some legacy
> stuff.

Compatibility with Renesas's compiler.

Re: [Bug target/78804] [RX] -m64bit-doubles does not work

[DJ Delorie]

"olegendo at gcc dot gnu.org"  writes:
> I don't know why it was decided to use this ABI.  Maybe some legacy
> stuff.

Compatibility with Renesas's compiler.

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #23 from Oleg Endo  ---
(In reply to Ian Lance Taylor from comment #22)
> The patch to make the structs themselves attribute((packed)) is approved.
> 

Thanks!

> If you want to investigate dropping the bitfield code entirely, that is fine
> with me.

What's your concern?  Which investigations do you have in mind?

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #22 from Ian Lance Taylor  ---
The patch to make the structs themselves attribute((packed)) is approved.

If you want to investigate dropping the bitfield code entirely, that is fine
with me.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Avi Kivity from comment #9)
> I believe the comment is wrong. Here's what the manual says:
> 
> "This instruction can be used with a LOCK prefix to allow the instruction to
> be executed atomically."
> 
> Implying that without the LOCK prefix, it is not atomic. XCHG is the only
> instruction that asserts LOCK implicitly.
> 
> Agner lists BTC reciprocal throughput as 1 for imm, mem case and 5 for reg,
> mem. The latter is slow, but perhaps still worthwhile as a replacement for
> the code in the first comment (but probably not when addressing a single
> word).

BTC/BTR/BTS with a memory operand (RMW) is indeed slower, but so are other
logic instructions. Following testcase:

--cut here--
extern unsigned long long a;

void
test (void)
{
  a &= ~(1ull << 55);
}
--cut here--

should generate RMW BTR instruction.

I'll look into this a bit some more.  However, these insn should be rare, so do
not expect any noticeable application speed-up ...

> Note there is also the BT instruction (with reciprocal throughput of 0.5!)

Yes, we already emit this.

[Bug preprocessor/77810] provide format_inform_at_substring to go with format_warning_at_substring

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Patch looks reasonable, and I can approve it.

CC me on it when you post it to gcc-patches.

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #21 from Oleg Endo  ---
(In reply to Ian Lance Taylor from comment #18)
> How could the size of that struct possibly be 12?  Can you figure out what
> is causing that to happen?  There are exactly 64 bits specified, and the
> fields are all packed.  The size ought to be 8.  I don't see what could
> cause it to be 12.
> 
> Also, I should have said that you need to compile with -m64bit-doubles.

Yeah, right.  D'uh, sorry.
With -m64bit-doubles it prints
12
0 2ec 0

But doesn't matter.  I already found out that the size is 12 bytes in comment
#8 above.  Packing the whole struct helps, as mentioned above.

I don't know why it was decided to use this ABI.  Maybe some legacy stuff.  RX
has those issues.  But I don't think it matters in this case.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[a...@cloudius-systems.com]

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

--- Comment #9 from Avi Kivity  ---
I believe the comment is wrong. Here's what the manual says:

"This instruction can be used with a LOCK prefix to allow the instruction to be
executed atomically."

Implying that without the LOCK prefix, it is not atomic. XCHG is the only
instruction that asserts LOCK implicitly.

Agner lists BTC reciprocal throughput as 1 for imm, mem case and 5 for reg,
mem. The latter is slow, but perhaps still worthwhile as a replacement for the
code in the first comment (but probably not when addressing a single word).

Note there is also the BT instruction (with reciprocal throughput of 0.5!)

[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|7.3 |---

[Bug middle-end/78098] error: interrupt service routine can't be called directly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|7.3 |---

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #20 from Oleg Endo  ---
(In reply to jos...@codesourcery.com from comment #17)
> Presumably the bit-field issue is RX defaulting to MS bit-field layout 
> (rx_is_ms_bitfield_layout suggests making the structure itself packed 
> should help).

Yep, the following also fixes the issue.

Index: libgcc/fp-bit.h
===
--- libgcc/fp-bit.h (revision 251045)
+++ libgcc/fp-bit.h (working copy)
@@ -355,7 +355,7 @@
 #endif

 #ifdef FLOAT_BIT_ORDER_MISMATCH
-  struct
+  struct __attribute__((__packed__))
 {
   fractype fraction:FRACBITS __attribute__ ((packed));
   unsigned int exp:EXPBITS __attribute__ ((packed));
@@ -365,7 +365,7 @@
 #endif

 #ifdef _DEBUG_BITFLOAT
-  struct
+  struct __attribute__((__packed__))
 {
   unsigned int sign:1 __attribute__ ((packed));
   unsigned int exp:EXPBITS __attribute__ ((packed));
@@ -373,7 +373,7 @@
 }
   bits_big_endian;

-  struct
+  struct __attribute__((__packed__))
 {
   fractype fraction:FRACBITS __attribute__ ((packed));
   unsigned int exp:EXPBITS __attribute__ ((packed));


But what's the point of having the bit-field code for little endian, while
there is already shift-and-mask code for big endian?

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #7)
> From i386.md:
> 
> ;; %%% bts, btr, btc, bt.
> ;; In general these instructions are *slow* when applied to memory,
> ;; since they enforce atomic operation.  When applied to registers,
> ;; it depends on the cpu implementation.  They're never faster than
> ;; the corresponding and/ior/xor operations, so with 32-bit there's
> ;; no point.  But in 64-bit, we can't hold the relevant immediates
> ;; within the instruction itself, so operating on bits in the high
> ;; 32-bits of a register becomes easier.

atomics involving btr/bts/btc were implemented a while ago for PR49244.

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #19 from Ian Lance Taylor  ---
OK, following Joseph's suggestion, what does this print when compiled with
-m64bit-doubles?

#include 

struct bits
{
  unsigned long long fraction:52 __attribute__ ((packed));
  unsigned int exp:11 __attribute__ ((packed));
  unsigned int sign:1 __attribute__ ((packed));
} __attribute__ ((packed));

double d = 1.0;

int
main ()
{
  struct bits *p;
  unsigned long long *pll;

  printf ("%zu\n", sizeof (struct bits));
  p = (struct bits *)
  printf ("%llx %x %x\n", (unsigned long long) p->fraction, p->exp, p->sign);
  pll = (unsigned long long*)
  printf ("%llx\n", *pll);
  return 0;
}

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #18 from Ian Lance Taylor  ---
How could the size of that struct possibly be 12?  Can you figure out what is
causing that to happen?  There are exactly 64 bits specified, and the fields
are all packed.  The size ought to be 8.  I don't see what could cause it to be
12.

Also, I should have said that you need to compile with -m64bit-doubles.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
From i386.md:

;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation.  When applied to registers,
;; it depends on the cpu implementation.  They're never faster than
;; the corresponding and/ior/xor operations, so with 32-bit there's
;; no point.  But in 64-bit, we can't hold the relevant immediates
;; within the instruction itself, so operating on bits in the high
;; 32-bits of a register becomes easier.

[Bug target/78804] [RX] -m64bit-doubles does not work

[joseph at codesourcery dot com]

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

--- Comment #17 from joseph at codesourcery dot com  ---
Presumably the bit-field issue is RX defaulting to MS bit-field layout 
(rx_is_ms_bitfield_layout suggests making the structure itself packed 
should help).

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[a...@cloudius-systems.com]

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

--- Comment #6 from Avi Kivity  ---
I believe bts/btc/btr can do more - they also calculate the word offset when
addressing memory, see first comment.

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo  ---
(In reply to Ian Lance Taylor from comment #15)
> What does this program print on rx?

12
6f883f80 0 0

> 
> Overall the softfp code is newer and probably better.  Converting rx to use
> the softfp code is probably a good idea.

I don't think I will have time for that in the near future.  It might be better
to fix fp-bit first and also avoid future surprises when somebody tries to use
it.

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
What does this program print on rx?

#include 

struct bits
{
  unsigned long long fraction:52 __attribute__ ((packed));
  unsigned int exp:11 __attribute__ ((packed));
  unsigned int sign:1 __attribute__ ((packed));
};

double d = 1.0;

int
main ()
{
  struct bits *p;

  printf ("%zu\n", sizeof (struct bits));
  p = (struct bits *)
  printf ("%llx %x %x\n", (unsigned long long) p->fraction, p->exp, p->sign);
  return 0;
}



Overall the softfp code is newer and probably better.  Converting rx to use the
softfp code is probably a good idea.

[Bug translation/79998] typo in diagnostic "specified bound %wu"

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Mon Aug 14 16:47:40 2017
New Revision: 251096

URL: https://gcc.gnu.org/viewcvs?rev=251096=gcc=rev
Log:
PR translation/79998 - typo in diagnostic "specified bound %wu"

gcc/ChangeLog:
* gimple-ssa-sprintf.c (pass_sprintf_length::handle_gimple_call):
Remove a stray space.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug translation/79998] typo in diagnostic "specified bound %wu"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|ASSIGNED|RESOLVED
  Component|tree-optimization   |translation
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Fixed in r251096.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86_64
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #5 from Uroš Bizjak  ---
Implemented in 8.0.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Aug 14 16:42:15 2017
New Revision: 251095

URL: https://gcc.gnu.org/viewcvs?rev=251095=gcc=rev
Log:
PR target/46091
* config/i386/i386.md (*anddi_1_btr): New insn_and_split pattern.
(*iordi_1_bts): Ditto.
(*xordi_1_btc): Ditto.

testsuite/ChangeLog:

PR target/46091
* gcc.target/i386/pr46091-1.c: New test.
* gcc.target/i386/pr46091-2.c: Ditto.
* gcc.target/i386/pr46091-3.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr46091-1.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-2.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/38087] Pseudo destructor call

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW

--- Comment #5 from Jonathan Wakely  ---
There's https://wg21.link/cwg555 but I don't think it changes anything here.

[expr.pseudo] definitely doesn't apply, as that only applies to non-class
types. (The bug title is wrong for the same reason, this is a destructor call,
not a pseudo destructor call.)

The current wording in [basic.lookup.classref] says "At least one of the
lookups shall find a name that refers to cv T." The object expression has type
C, but the lookup result for B does not find that type, so the code is invalid.

[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #9 from Wilco  ---
Fixed in r251094.

[Bug tree-optimization/79998] typo in diagnostic "specified bound %wu"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-14
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |trivial

--- Comment #1 from Martin Sebor  ---
Confirmed.  Let me fix it.

[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
Author: wilco
Date: Mon Aug 14 16:18:37 2017
New Revision: 251094

URL: https://gcc.gnu.org/viewcvs?rev=251094=gcc=rev
Log:
[AArch64] Fix longbranch test

Fix longbranch test so it still generates long tbz branches.

gcc/testsuite/
PR target/81643
* gcc.target/aarch64/long_branch_1.c: Improve testcase.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/long_branch_1.c

[Bug translation/79997] simple-ssa-sprintf i18n: wrong plural form in maybe_warn

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Depends on||77810
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  There are a few instances of this idiom in the file and elsewhere
in GCC.  The pass makes use of the format_warning_at_substring() function to do
the formatting and that function only comes in one form, and doesn't provide an
"overload" similar to warning_n or warning_at_rich_loc_n to format plural forms
of diagnostics (this enhancement request is being tracked in pr77810).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77810
[Bug 77810] provide format_inform_at_substring to go with
format_warning_at_substring

[Bug c++/44580] inconsistent "right-hand operand of comma has no effect"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I think GCC needs to avoid performing sprintf optimizations when it sees a
non-standard (i.e., undefined) format conversion (the sprintf pass does).

For Glibc customizations that override standard conversions like %s, the user
needs to explicitly disable the built-in sprintf handling, otherwise the
sprintf -> strcpy or printf -> puts optimizations will defeat them.  Carlos
O'Donell says the Glibc manual should also be updated to make this clear.  To
make it easy to disable all of them (and not forget, say vsnprintf), Carlos
suggests adding a convenience option as an alias for all of
-fno-builtin-{,v}{,f,s,sn}printf and -fno-builtin-{,f}printf-unlocked (at least
I think that's all of them, unless the checking forms also need to be
disabled).

[Bug c++/44520] improve diagnostic for ambiguous lookup

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, the g++ diagnostic is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44520.cc
44520.cc: In member function ‘void D::g()’:
44520.cc:10:5: error: ‘B1’ is an ambiguous base of ‘D’
   f();
 ^
$

[Bug c++/44400] GCC allows declaring a function having the name of the class using a typedef

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, g++ accepts it with neither warning nor error, while clang++ rejects
it like this:

$ /usr/local/bin/g++ -Wall -Wextra -pedantic -c 44400.cc
$ /sw/opt/llvm-3.1/bin/clang++ -Wall -Wextra -pedantic -c 44400.cc
44400.cc:2:14: error: member 'X' has the same name as its class
struct X { F X; };
 ^
44400.cc:2:14: error: constructor cannot have a return type
struct X { F X; };
   ~ ^
2 errors generated.
$

[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, text in the current docs is still pretty much the same as it was in
4.4.3.

[Bug c++/43454] warning with -Wall despite __attribute__ ((__unused__))

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
  Known to work||4.0.2
 Ever confirmed|0   |1
  Known to fail||4.0.4, 4.1.2, 4.2.4, 4.3.4,
   ||4.4.3, 8.0

--- Comment #2 from Eric Gallager  ---
Confirmed, output now looks like this now that there's underlining and stuff:

$ /usr/local/bin/g++ -c -Wall -S 43454.cc
43454.cc:7:44: warning: ‘check_moo’ defined but not used [-Wunused-variable]
 static int (* __attribute__ ((__unused__)) check_moo) (void) = gnulib::moo;
^
$

[Bug c++/80227] [5/6/7/8 Regression] SFINAE ambiguity with a pointer to array argument

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Idiomatic C++ code should not warn.

Clang and ICC accept the former and reject the latter. VC++ rejects both, which
is odd.

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from Eric Gallager  ---
(In reply to Roger Leigh from comment #6)
> Created attachment 18264 [details]
> Preprocessed source for g++-4.5.0 (svn 149777)

This compiles successfully without error for me with g++-8 (svn 250985), so I
guess I can close it.

[Bug c++/38087] Pseudo destructor call

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> I still think this is valid code ...  There are defect reports against this
> area too.

Which ones do you mean?

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #8 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #5)
> If it is getting you an internal error, then it is usually it is because the
> attachments are too big.
> 
> As for the other issue, there is a C++ defect report about this case, which
> consider this as dependent but a member as non dependent and all confusing
> happens with namelookup and such.

Link to the C++ DR? Is it still open?

[Bug c++/36685] clarify/diagnose use of weak constant

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed.

[Bug middle-end/81832] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2273

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Testing a patch.

[Bug c++/30812] enhancement: exception specification in __PRETTY_FUNCTION__

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
Confirming as an enhancement, although maybe a new identifier so as not to
break existing code? __PRETTIER_FUNCTION__?

[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'

[davidegrayson at gmail dot com]

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

David Grayson  changed:

   What|Removed |Added

 CC||davidegrayson at gmail dot com

--- Comment #5 from David Grayson  ---
This bug is still present, at least in GCC 6.3.0.  I have not tried a newer
version.

== Workarounds ==

For any GCC users getting an undefined reference error for "raise", you should
try providing the "-static" option to GCC when you link your program.

Alternatively, if you are compiling GCC yourself, you should find the
definition of LINK_GCC_C_SEQUENCE_SPEC in GCC's source code and change it to be
this:

--start-group %G %L --end-group

In my case, I am building a GCC 6.3.0 cross-compiler to target musl Linux, and
the definition I had to change was in "gcc/config/gnu-user.h".

You can see my build scripts here if you are interested in using GCC to build
static programs targeting Windows and Linux:

https://github.com/DavidEGrayson/nixcrpkgs


== Comments ==

Thank you for diagnosing this correctly, Rich Felker.  Also, your
musl-cross-make project was useful to me.

The core problem here is that LINK_GCC_C_SEQUENCE_SPEC is sometimes defined
like this:

%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}

You can run "gcc -dumpspecs" and look for "link_gcc_c_sequence" to see how it
was defined in your version of GCC.  The %G basically stands for "-lgcc" and
the %L basically stands for "-lc".  

The problem with that line is that it is confusing two different concepts:

A) The program is being linked with "-static".
B) The libc and GCC libraries used by the program are static.

A implies B, but B does not imply A.  I am using GCC to build static
applications so I don't have a shared version of libc or the GCC libraries, and
I want my programs to compile and link correctly even if the "-static" argument
is not supplied.

Why was this marked as "WORKSFORME", which is defined in by this bug tracker to
be "All attempts at reproducing this bug were futile, and ..."?  From the
conversation here it sure seems like there was no attempt to understand the
configuration of the original poster's GCC and system libraries and actually
reproduce the issue.  If anyone wants help reproducing this issue, I can easily
show you how to do it using my build scripts from the nixcrpkgs project.  One
of the advantages of Nix is that it's great for expressing how to build
software and compositions of software in a reliable and predictable way, so if
you have a Linux system you can just run a few commands and get the exact same
error I was getting when I tried to build a "hello world" program for the
Raspberry Pi.

[Bug c++/51277] Feature request: C++ diagnostic for ambiguous overloads

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #3 from Eric Gallager  ---
Confirming as an enhancement.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-14
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
Created attachment 41989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41989=edit
Patch in testing

[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
The situation should be much improved now.  Please let me know if you still see
i18n issues.

Bill

[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Aug 14 14:26:33 2017
New Revision: 251092

URL: https://gcc.gnu.org/viewcvs?rev=251092=gcc=rev
Log:
[gcc]

2017-08-14  Bill Schmidt  

PR target/79845
* config/rs6000/linux64.h (INVALID_64BIT): Use quoted strings.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Likewise.
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Use
quoted strings, and make more translator-friendly.
(darwin_rs6000_override_options): Likewise.
(rs6000_option_override_internal): Likewise.
(rs6000_return_in_memory): Fix overlong line.
(init_cmulative_args): Use quoted strings, and make more
translator-friendly.
(rs6000_pass_by_reference): Fix overlong line.
(def_builtin): Use quoted strings.
(altivec_expand_predicate_builtin): Use quoted strings, and make
more translator-friendly.
(htm_expand_builtin): Use quoted strings.
(cpu_expand_builtin): Use quoted strings, and make more
translator-friendly.
(altivec_expand_builtin): Likewise.
(paired_expand_predicate_builtin): Likewise.
(rs6000_invalid_builtin): Likewise.
(builtin_function_type): Use quoted strings.
(rs6000_expand_split_stack_prologue): Use quoted strings, and make
more translator-friendly.
(rs6000_trampoline_init): Likewise.
(rs6000_handle_altivec_attribute): Likewise.
(rs6000_inner_target_options): Use quoted strings.
(rs6000_disable_incompatible_switches): Likewise.
* config/rs6000/sysv4.h (SUBTARGET_OVERRIDE_OPTIONS): Use quoted
strings, and make more translator-friendly.
(SUBSUBTARGET_OVERRIDE_OPTIONS): Use quoted strings.

[gcc/testsuite]

2017-08-14  Bill Schmidt  

PR target/79845
* g++.dg/ext/altivec-cell-5.C: Adjust diagnostic strings.
* gcc.target/powerpc/altivec-cell-5.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-eq-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-gt-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-lt-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-cmp-exp-unordered-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-4.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-exp-5.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-4.c: Likewise.
* gcc.target/powerpc/bfp/scalar-extract-sig-5.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-1.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-10.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-11.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-4.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-5.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-7.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-8.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-11.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-6.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-7.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-neg-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-neg-3.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-neg-5.c: Likewise.
* gcc.target/powerpc/bfp/vec-extract-exp-2.c: Likewise.
* gcc.target/powerpc/bfp/vec-extract-exp-3.c: Likewise.
* gcc.target/powerpc/bfp/vec-extract-sig-2.c: Likewise.
* gcc.target/powerpc/bfp/vec-extract-sig-3.c: Likewise.
* gcc.target/powerpc/bfp/vec-insert-exp-2.c: Likewise.
* gcc.target/powerpc/bfp/vec-insert-exp-3.c: Likewise.
* gcc.target/powerpc/bfp/vec-insert-exp-6.c: Likewise.
* gcc.target/powerpc/bfp/vec-insert-exp-7.c: Likewise.
* gcc.target/powerpc/bfp/vec-test-data-class-2.c: Likewise.
* gcc.target/powerpc/bfp/vec-test-data-class-3.c: Likewise.
* gcc.target/powerpc/byte-in-either-range-1.c: Likewise.
* gcc.target/powerpc/byte-in-range-1.c: Likewise.
* gcc.target/powerpc/byte-in-set-1.c: Likewise.
* gcc.target/powerpc/byte-in-set-2.c: Likewise.
* gcc.target/powerpc/cmpb-3.c: Likewise.
* gcc.target/powerpc/crypto-builtin-2.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-1.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-11.c: Likewise.
* 

[Bug c++/15369] "Wrong" line number for static constructor function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||seongbae.park at gmail dot com

--- Comment #10 from Eric Gallager  ---
*** Bug 30257 has been marked as a duplicate of this bug. ***

[Bug c++/30257] static initializers are attributed to bogus line number in coverage.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Seongbae Park from comment #2)
> Yes, it looks like duplicate, although PR 15369 is against 3.4.

Still duplicate-ish enough. Closing.

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

[Bug c++/26426] Type layout bug

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
How are you getting the byte values? I compiled the testcase but I don't know
what I'm supposed to be looking for in the output...

$ /usr/local/bin/g++ -Wall -Wextra -Wreorder -Wpacked -Wpadded -c 26426.cc
$ size 26426.o
__TEXT  __DATA  __OBJC  others  dec hex
1237232 0   16  14855cd
$ nm 26426.o
041c s EH_frame1
012c S __ZN1AC2Ev
 U __ZN1AD2Ev
0148 S __ZN1BC2Ev
 U __ZN1BD2Ev
0164 S __ZN1XC2Ev
01ac S __ZN1XD2Ev
01f4 S __ZN1YC2Ev
 U __ZN1YD2Ev
007a T __ZN1ZC1Ev
 T __ZN1ZC2Ev
02e6 S __ZN1ZD0Ev
0222 S __ZN1ZD1Ev
038c S __ZTC1Z0_1Y
03a4 S __ZTC1Z4_1X
 U __ZTI1A
 U __ZTI1B
03f4 S __ZTI1X
 U __ZTI1Y
03d4 S __ZTI1Z
0417 S __ZTS1X
0414 S __ZTS1Z
0368 S __ZTT1Z
 U __ZTV1A
 U __ZTV1B
032c S __ZTV1Z
 U __ZTVN10__cxxabiv121__vmi_class_type_infoE
0311 S __ZTv0_n12_N1ZD0Ev
02d4 S __ZTv0_n12_N1ZD1Ev
 U __ZdlPvm
0323 S ___x86.get_pc_thunk.ax
0327 S ___x86.get_pc_thunk.bx
05c4 s l__ZTT1Z$non_lazy_ptr
05c8 s l__ZTV1A$non_lazy_ptr
05cc s l__ZTV1B$non_lazy_ptr
05c0 s l__ZTV1Z$non_lazy_ptr
$

[Bug middle-end/81801] [PATCH] Difference of two pointers generates signed overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|target  |middle-end

--- Comment #5 from Richard Biener  ---
Jakub ended up running into this as well with pointer sanitizing I think.  And
Marc prototyped POINTER_MINUS_EXPR -- I hope we can leaverage that for GCC 8.

[Bug c++/80227] [5/6/7/8 Regression] SFINAE ambiguity with a pointer to array argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc rejects the former and accepts the latter, although the
former should probably still get a warning anyways even if it's not supposed to
error, just for being confusing (in my
biased-against-c++-things-like-overloading opinion)

[Bug tree-optimization/81799] [8 Regression] ICE on valid code at -O3: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug c++/81787] [5/6/7/8 Regression] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |5.5
Summary|`#pragma GCC diagnostic |[5/6/7/8 Regression]
   |warning "-fpermissive"` no  |`#pragma GCC diagnostic
   |longer works since gcc 4.8  |warning "-fpermissive"` no
   ||longer works since gcc 4.8

[Bug c/81785] Segmentation fault for signed overflow in index expression when -fwrapv is enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||mpolacek at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
We emit

int k = -2147483648;
  return x + ((sizetype) ((long unsigned int) k * 4) + 18446744065119617028);

and it seems we end up zero-extending k.  I believe that's because of the
(premature) optimization in pointer_int_sum:

  /* If what we are about to multiply by the size of the elements
 contains a constant term, apply distributive law
 and multiply that constant term separately.
 This helps produce common subexpressions.  */
  if ((TREE_CODE (intop) == PLUS_EXPR || TREE_CODE (intop) == MINUS_EXPR)
  && !TREE_CONSTANT (intop)
  && TREE_CONSTANT (TREE_OPERAND (intop, 1))
  && TREE_CONSTANT (size_exp)
  /* If the constant comes from pointer subtraction,
 skip this optimization--it would cause an error.  */
  && TREE_CODE (TREE_TYPE (TREE_OPERAND (intop, 0))) == INTEGER_TYPE
  /* If the constant is unsigned, and smaller than the pointer size,
 then we must skip this optimization.  This is because it could cause
 an overflow error if the constant is negative but INTOP is not.  */
  && (!TYPE_UNSIGNED (TREE_TYPE (intop))
  || (TYPE_PRECISION (TREE_TYPE (intop))
  == TYPE_PRECISION (TREE_TYPE (ptrop)
{
  enum tree_code subcode = resultcode;
  tree int_type = TREE_TYPE (intop);
  if (TREE_CODE (intop) == MINUS_EXPR)
subcode = (subcode == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR);
  /* Convert both subexpression types to the type of intop,
 because weird cases involving pointer arithmetic
 can result in a sum or difference with different type args.  */
  ptrop = build_binary_op (EXPR_LOCATION (TREE_OPERAND (intop, 1)),
   subcode, ptrop,
   convert (int_type, TREE_OPERAND (intop, 1)),
   true);
  intop = convert (int_type, TREE_OPERAND (intop, 0));
}


compilable testcase:

int * __attribute__((__noinline__, __noclone__))
foo(int x[])
{
  int k = (-__INT_MAX__ - 1);
  return x + (k - __INT_MAX__);
}

I suggest trying to remove the above...  (doing so fixes the testcase)

[Bug c++/71192] Coredump - SIGSEGV exception handling on GCC 4.8.2 in Solaris 11.3, Solaris 11.2 works with same GCC version

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Could you please:

- attach the preprocessed source that triggers this bug
- try again with a version of GCC that is still supported, and
- specify your full target triplet?

[Bug c++/67075] Infinite GC loop with ggc-min-expand=0

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #2)
> Sounds more like ggc_collect is now always doing the gc and there are a lot
> of ggc_collect calls. 
> 
> So what is happening we are close to your 32M limit you set, so any garbage
> that is produced in a pass will cause the next call to ggc_collect to always
> collect. This means there a lot of calls to ggc_collect but in the normal
> case (non 0 case), it does not matter. 
> 
> You might want to try 5.2 as 4.8.x is no longer supported and there have
> been some memory reductions happened since 4.8.x.

Changing to WAITING until reporter tries a supported version.

[Bug c++/39466] frepo relinking causes error - object in .o but not in .rpo or vice versa

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from Eric Gallager  ---
I can't reproduce with current gcc on i386-apple-darwin9.8.0, compilation fails
instead with: 

$ /usr/local/bin/g++ -frepo -DCOMPILING_WITH_FREPO=1 -pipe -frepo
-DCOMPILING_WITH_FREPO=1 -D_REENTRANT -Wctor-dtor-privacy -Wall -DNDEBUG
-fstack-protector-all -O2 -ftree-loop-linear -fweb -march=core2 -mssse3
-fdiagnostics-show-option -fomit-frame-pointer -fPIC -rdynamic -std=gnu++98 -o
XmlImplementationFactory.exe XmlImplementationFactory.ii 2>&1
: warning: -frepo must be used with -c
util/impl/xml/XmlImplementationFactory.cpp:33:1: error: declaration of
‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) [with T =
dogs::util::xml::TSimpleTypes]’ has a different
exception specifier
In file included from util/impl/xml/XmlImplementationFactory.cpp:3:0:
util/impl/../include/XmlImplementationFactory.h:26:11: note: from previous
declaration ‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) throw
(dogs::util::xml::XmlException) [with T =
dogs::util::xml::TSimpleTypes]’
util/impl/xml/XmlImplementationFactory.cpp:49:1: error: declaration of
‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) [with T =
dogs::util::xml::TSimpleTypes]’ has a different
exception specifier
In file included from util/impl/xml/XmlImplementationFactory.cpp:3:0:
util/impl/../include/XmlImplementationFactory.h:26:11: note: from previous
declaration ‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) throw
(dogs::util::xml::XmlException) [with T =
dogs::util::xml::TSimpleTypes]’
$

Can you try again?

[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
The issue is that there is a maybe uninitialized use given we fail to optimize
the condition at -O0.  We're only warning for maybe-uninit uses before
optimization at -O0.

I don't see a good way out here but to enhance this by at least constant
propagating on the side.

[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
It's unclear what guarantees can be made here due to the pesky printf
formatting callbacks in glibc (maybe I misremember).  This is the reason we do
not handle
this family of builtins in tree-ssa-structalias.c.

fnspec would be ".WR" for sprintf

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
I was wrong, and that code path is used by std::sync_with_stdio(false) when we
reset cin, cout, cerr and clog to use stdio_filebuf stream buffers. So there's
no need for a testcase.

[Bug libstdc++/79820] std::ifstream sets errno to zero

[m-ou...@m-ou.se]

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

--- Comment #11 from Maurice Bos  ---
(In reply to Jonathan Wakely from comment #7)
> The bug title says std::ifstream sets errno to zero, but it should never run
> stdio_filebuf::sys_open. Do you have a testcase for this?
> 
> We should still fix it even if it only affects a non-standard extension, but
> it's probably not worth backporting if it doesn't affect std::ifstream.

I encountered it while using the Catch test framework. Found it with a
watchpoint with gdb. Didn't fully inspect the backtrace. It might use some
non-standard extensions. I'll check!

[Bug inline-asm/81845] asm memory constraints are difficult and not well documented

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug middle-end/81832] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2273

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
> I think this is a general and latent problem with the interaction between
> the copy-header pass, and the loop distribution pass. Tracing back further I
> see this start with r249994 .

Yes, sorry for not tracking precisely, r249994 is the first one ICEing.

[Bug tree-optimization/81848] Segmentation fault at gimple-ssa-strength-reduction.c:2356

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
(In reply to rguent...@suse.de from comment #2)
> 
> Isn't this a dup of PR81354 and thus fixed?

Well, yes, apparently it is fixed by today's trunk so it is most
probably a duplicate.

Sorry for the noise, but I tried searching bugzilla for
"gimple-ssa-strength-reduction.c" and found nothing yesterday.

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

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #12 from Martin Jambor  ---
*** Bug 81848 has been marked as a duplicate of this bug. ***

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #14 from Oleg Endo  ---
(In reply to jos...@codesourcery.com from comment #13)
> fp-bit != soft-fp.

Ugh, sorry.  I didn't realize that they are two distinct pieces.  I was really
just referring to fp-bit.  I have not tried soft-fp on RX.  But if it uses
bit-fields in the same way as fp-bit does at the moment, it will have issues on
RX as well.

Adding Ian to CC, who is listed as fp-bit maintainer.

> soft-fp always uses bit-fields (with the order 
> depending on the endianness).  It's possible that in some cases you need 
> to ensure the declared types of the bit-fields are such that no padding 
> gets inserted and so you have the right layout.

Since we're at it ... how to ensure bitfield layout and enclosing struct size? 
I think fp-bit already tries to do that with __attribute__((packed)) and yet it
fails...

[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Confirmed, there are various small issues and I've been testing a patch for
that. The patch will also include unit tests to prevent next issues related.

[Bug tree-optimization/81848] Segmentation fault at gimple-ssa-strength-reduction.c:2356

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Mon, 14 Aug 2017, jamborm at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81848
> 
> Martin Jambor  changed:
> 
>What|Removed |Added
> 
>  Target||x86_64-linux
>  CC||rguenth at gcc dot gnu.org,
>||wschmidt at gcc dot gnu.org
>   Known to work||7.1.0
>Host||x86_64-linux
>   Known to fail||8.0
> 
> --- Comment #1 from Martin Jambor  ---
> Apparently, a phi statement is not present in a hash_map where expect
> it is:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0190bdf4 in create_phi_basis (c=0x2921a80, from_phi=0x7666c800, 
> basis_name=, loc=2147483706, known_stride=false)
> at /home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:2356
> 2356  slsr_cand_t phi_cand = *stmt_cand_map->get (from_phi);
> (gdb) p stmt_cand_map->get (from_phi)
> $1 = (slsr_cand_d **) 0x0
> 
> 
> CCing Richi who committed the revision uncovering this and Bill who
> added the lookup last year.

Isn't this a dup of PR81354 and thus fixed?

[Bug tree-optimization/81848] Segmentation fault at gimple-ssa-strength-reduction.c:2356

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Target||x86_64-linux
 CC||rguenth at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
  Known to work||7.1.0
   Host||x86_64-linux
  Known to fail||8.0

--- Comment #1 from Martin Jambor  ---
Apparently, a phi statement is not present in a hash_map where expect
it is:

Program received signal SIGSEGV, Segmentation fault.
0x0190bdf4 in create_phi_basis (c=0x2921a80, from_phi=0x7666c800, 
basis_name=, loc=2147483706, known_stride=false)
at /home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:2356
2356  slsr_cand_t phi_cand = *stmt_cand_map->get (from_phi);
(gdb) p stmt_cand_map->get (from_phi)
$1 = (slsr_cand_d **) 0x0


CCing Richi who committed the revision uncovering this and Bill who
added the lookup last year.

[Bug tree-optimization/81848] New: Segmentation fault at gimple-ssa-strength-reduction.c:2356

[jamborm at gcc dot gnu.org]

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

Bug ID: 81848
   Summary: Segmentation fault at
gimple-ssa-strength-reduction.c:2356
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---

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

Starting with r250416, spec 2017 benchmark 521.wrf_r started to ICE at
-Ofast optimization level.  I have extracted the attached (slightly
minimized) function from it which reproduces the ICE:

$ /home/mjambor/gcc/bisect/inst/bin/gfortran -S -Ofast bug.f90
during GIMPLE pass: slsr
bug.f90:4:0:

   integer function ice_in_me( pcols , pver   , ncol   , fixed_ubc  , mw   
 , ubc_mmr , &

internal compiler error: Segmentation fault
0xf4c4fb crash_signal
/home/mjambor/gcc/bisect/src/gcc/toplev.c:338
0x190bdf4 create_phi_basis
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:2356
0x190bfa0 create_phi_basis
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:2386
0x190bfa0 create_phi_basis
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:2386
0x190bfa0 create_phi_basis
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:2386
0x190f7a5 replace_profitable_candidates
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:3670
0x190fa9e analyze_candidates_and_replace
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:3769
0x190fc82 execute
/home/mjambor/gcc/bisect/src/gcc/gimple-ssa-strength-reduction.c:3843
Please submit a full bug report,

[Bug c++/71570] [6 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:55

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #14 from Paolo Carlini  ---
Fixed for 6.5 too.

[Bug c++/71570] [6 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:55

[paolo at gcc dot gnu.org]

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

--- Comment #13 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Aug 14 12:23:03 2017
New Revision: 251091

URL: https://gcc.gnu.org/viewcvs?rev=251091=gcc=rev
Log:
/cp
2017-08-14  Paolo Carlini  

PR c++/71570
* lambda.c (add_capture): Early return if we cannot capture by
reference.

/testsuite
2017-08-14  Paolo Carlini  

PR c++/71570
* g++.dg/cpp0x/lambda/lambda-ice17.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice17.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/lambda.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||7.2.1, 8.0
   Target Milestone|8.0 |7.3
  Known to fail||5.4.0, 6.4.0, 7.2.0

[Bug libstdc++/81751] [5/6/7 Regression]__basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug 14 12:14:09 2017
New Revision: 251090

URL: https://gcc.gnu.org/viewcvs?rev=251090=gcc=rev
Log:
PR libstdc++/81751 don't call fflush(NULL)

Backport from mainline
2017-08-09  Jonathan Wakely  

PR libstdc++/79820
PR libstdc++/81751
* config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)):
Call fflush on the stream instead of calling sync() while _M_cfile is
null. Restore original value of errno.
* testsuite/ext/stdio_filebuf/char/79820.cc: New.
* testsuite/ext/stdio_filebuf/char/81751.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/config/io/basic_file_stdio.cc

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug 14 12:14:09 2017
New Revision: 251090

URL: https://gcc.gnu.org/viewcvs?rev=251090=gcc=rev
Log:
PR libstdc++/81751 don't call fflush(NULL)

Backport from mainline
2017-08-09  Jonathan Wakely  

PR libstdc++/79820
PR libstdc++/81751
* config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)):
Call fflush on the stream instead of calling sync() while _M_cfile is
null. Restore original value of errno.
* testsuite/ext/stdio_filebuf/char/79820.cc: New.
* testsuite/ext/stdio_filebuf/char/81751.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/config/io/basic_file_stdio.cc

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug 14 12:14:01 2017
New Revision: 251089

URL: https://gcc.gnu.org/viewcvs?rev=251089=gcc=rev
Log:
PR libstdc++/53984 handle exceptions in basic_istream::sentry

Backport from mainline
2017-07-25  Jonathan Wakely  

PR libstdc++/53984
* include/bits/basic_ios.h (basic_ios::_M_setstate): Adjust comment.
* include/bits/istream.tcc (basic_istream::sentry): Handle exceptions
during construction.
* include/std/istream: Adjust comments for formatted input functions
and unformatted input functions.
* testsuite/27_io/basic_fstream/53984.cc: New.
* testsuite/27_io/basic_istream/sentry/char/53984.cc: New.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_fstream/53984.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/53984.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/basic_ios.h
branches/gcc-7-branch/libstdc++-v3/include/bits/istream.tcc
branches/gcc-7-branch/libstdc++-v3/include/std/istream

[Bug target/78804] [RX] -m64bit-doubles does not work

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com  ---
fp-bit != soft-fp.  soft-fp always uses bit-fields (with the order 
depending on the endianness).  It's possible that in some cases you need 
to ensure the declared types of the bit-fields are such that no padding 
gets inserted and so you have the right layout.

[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #4 from H.J. Lu  ---
(In reply to Richard Biener from comment #3)
> 
> Adding -fno-reorder-blocks-and-partition to the test fixes things but I
> wonder
> what causes the debug info to degrade (or gdb to barf).  I think HJs pending
> patch in this area might fix things?

No, my patch doesn't fix it.

[Bug tree-optimization/81799] [8 Regression] ICE on valid code at -O3: verify_gimple failed

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Aug 14 11:46:03 2017
New Revision: 251088

URL: https://gcc.gnu.org/viewcvs?rev=251088=gcc=rev
Log:
PR tree-optimization/81799
* tree-loop-distribution.c (version_loop_by_alias_check): Force
cond_expr to simple gimple operand.

gcc/testsuite
* gcc.dg/tree-ssa/pr81799.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81799.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[niva at niisi dot msk.ru]

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

niva at niisi dot msk.ru changed:

   What|Removed |Added

 CC||niva at niisi dot msk.ru

--- Comment #15 from niva at niisi dot msk.ru ---
We are using MIPS target and we are extremely interested in the 
solution formulated in
https://gcc.gnu.org/ml/gcc/2015-04/msg00239.html:

"Ideally I'd like a guarantee
that FP registers will never be used unless a floating point type is
present in the source "

In fact we'd like to have an option which disables
use of FP registers and makes the compiler to issue an
error if any FP operation occurs in the program.

[Bug middle-end/81832] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2273

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from James Greenhalgh  ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r250619.

Interesting. That commit seems unlikely to have broken anything (if it does,
the bug would be latent and would have been possible to trigger using the
revision prior). My bisect points to r250959 , which seems much more likely,
given the backtrace.

What I imagine you've done with your bisect is continued back through the
revisions with -ftree-loop-distribute set, that does get you to r250619, but as
this is also really just a change to default "options", you should continue
going back with -ftree-vectorize to find the real culprit. For example, r250617
will also ICE with -O3 -ftree-loop-distribute -ftree-vectorize .

I think this is a general and latent problem with the interaction between the
copy-header pass, and the loop distribution pass. Tracing back further I see
this start with r249994 .

[Bug middle-end/46932] Inefficient code sequence to access local variable

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
Author: wilco
Date: Mon Aug 14 11:18:50 2017
New Revision: 251087

URL: https://gcc.gnu.org/viewcvs?rev=251087=gcc=rev
Log:
Add check_effective_target_autoincdec.

Add check_effective_target_autoincdec that returns true if a target
runs the auto_inc_dec optimization pass.

gcc/
* doc/sourcebuild.texi (autoincdec): Add autoincdec description.

gcc/testsuite/
PR middle-end/46932
* gcc.dg/pr46932.c: Use dg-require-effective-target autoincdec.
* lib/target-supports.exp: Add check_effective_target_autoincdec.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr46932.c
trunk/gcc/testsuite/lib/target-supports.exp