[doc] install.texi: Simplify binutils requirement note for powerpc-*-*
binutils is another GNU project (and well known and easy to obtain),
so linking to ftp.kernel.org feels a little surprising.
I simplified this and generally streamlined this note - which luckily
is a lot less necessary now then when it was added many moons ago.
In fact, do you think we can even remove this altogether? binutils
2.15 was released in May 2004, more than 12 years ago. ;-)
Gerald
PS: Applied for now...
2017-03-12 Gerald Pfeifer
* doc/install.texi (Specific) : Remove link to
ftp.kernel.org and simplify binutils requirement.
Index: doc/install.texi
===
--- doc/install.texi(revision 246071)
+++ doc/install.texi(working copy)
@@ -4207,9 +4207,7 @@
You can specify a default version for the @option{-mcpu=@var{cpu_type}}
switch by using the configure option @option{--with-cpu-@var{cpu_type}}.
-You will need
-@uref{ftp://ftp.kernel.org/pub/linux/devel/binutils,,binutils 2.15}
-or newer for a working GCC@.
+You will need GNU binutils 2.15 or newer.
@html
install.texi and alpha (was: Target maintainers: doc/install.texi love and care)
On Sun, 12 Mar 2017, Gerald Pfeifer wrote: > Also, I'm offering help around one particular aspect I noticed: > > References to dependencies on really, really old versions of > binutils (talking 10+ years here) which I think we can remove. > Let me follow-up with some of you with concrete suggestions > around that. The alpha*-*-* section currently has this: We require binutils 2.11.2 or newer. Previous binutils releases had a number of problems with DWARF 2 debugging information, not the least of which is incorrect linking of shared libraries. Okay to yank this? Gerald
install.texi and arm (was: Target maintainers: doc/install.texi love and care)
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> Also, I'm offering help around one particular aspect I noticed:
>
> References to dependencies on really, really old versions of
> binutils (talking 10+ years here) which I think we can remove.
> Let me follow-up with some of you with concrete suggestions
> around that.
The arm-*-eabi section currently has this:
ARM-family processors. Subtargets that use the ELF object format
require GNU binutils 2.13 or newer. Such subtargets include:
@code{arm-*-netbsdelf}, @code{arm-*-*linux-*}
and @code{arm-*-rtemseabi}.
Okay to yank this?
Gerald
install.texi and avr (was: Target maintainers: doc/install.texi love and care)
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> Also, I'm offering help around one particular aspect I noticed:
>
> References to dependencies on really, really old versions of
> binutils (talking 10+ years here) which I think we can remove.
> Let me follow-up with some of you with concrete suggestions
> around that.
The avr section currently has this:
We @emph{strongly} recommend using binutils 2.13 or newer.
Okay to yank it?
Gerald
Re: Target maintainers: doc/install.texi love and care
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> References to dependencies on really, really old versions of
> binutils (talking 10+ years here) which I think we can remove.
> Let me follow-up with some of you with concrete suggestions
> around that.
The cris-axis-elf / cris-axis-linux-gnu section currently has this:
For @code{cris-axis-elf} you need binutils 2.11
or newer. For @code{cris-axis-linux-gnu} you need binutils 2.12 or newer.
Okay to yank it?
Gerald
install.texi and i?86-*-linux* (was: Target maintainers: doc/install.texi love and care)
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> References to dependencies on really, really old versions of
> binutils (talking 10+ years here) which I think we can remove.
> Let me follow-up with some of you with concrete suggestions
> around that.
The i?86-*-linux* section currently has this:
As of GCC 3.3, binutils 2.13.1 or later is required for this platform.
See @uref{http://gcc.gnu.org/PR10877,,bug 10877} for more information.
Okay to yank it?
Gerald
install.texi and mips-*-* (was: Target maintainers: doc/install.texi love and care)
On Sun, 12 Mar 2017, Gerald Pfeifer wrote: > References to dependencies on really, really old versions of > binutils (talking 10+ years here) which I think we can remove. > Let me follow-up with some of you with concrete suggestions > around that. The mips-*-* currently has this: The assembler from GNU binutils 2.17 and earlier has a bug in the way it sorts relocations for REL targets (o32, o64, EABI). This can cause bad code to be generated for simple C++ programs. Also the linker from GNU binutils versions prior to 2.17 has a bug which causes the runtime linker stubs in very large programs to be incorrectly generated. GNU Binutils 2.18 and later (and snapshots made after Nov. 9, 2006) should be free from both of these problems. (Even that goes back more than 10 years.) Okay to yank it?
install.texi and sparc-*-linux* (was: Target maintainers: doc/install.texi love and care)
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> References to dependencies on really, really old versions of
> binutils (talking 10+ years here) which I think we can remove.
> Let me follow-up with some of you with concrete suggestions
> around that.
The section on sparc-*-linux* currently has this:
GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
or newer on this platform. All earlier binutils and glibc
releases mishandled unaligned relocations on @code{sparc-*-*} targets.
Okay to yank it?
Gerald
[v3 PATCH] Implement LWG 2806, Base class of bad_optional_access.
Tested on Linux-x64.
2017-03-12 Ville Voutilainen
Implement LWG 2806, Base class of bad_optional_access.
* include/std/optional (bad_optional_access):
Derive from std::exception.
(bad_optional_access::bad_optional_access): Adjust.
(bad_optional_access::what): New.
(__throw_bad_optional_access(const char*)):
Remove the parameter and adjust calls.
* testsuite/20_util/optional/cons/value_neg.cc: Adjust.
* testsuite/20_util/optional/typedefs.cc: Likewise.
diff --git a/libstdc++-v3/include/std/optional
b/libstdc++-v3/include/std/optional
index c700515..5e796ac 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -76,25 +76,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* dereferenced.
* @ingroup exceptions
*/
- class bad_optional_access : public logic_error
+ class bad_optional_access : public exception
{
-// XXX See LEWG 72, https://issues.isocpp.org/show_bug.cgi?id=72
public:
-bad_optional_access() : logic_error("bad optional access") { }
-// XXX This constructor is non-standard. Should not be inline
-explicit bad_optional_access(const char* __arg) : logic_error(__arg) { }
+bad_optional_access() { }
+virtual const char* what() const noexcept override
+{return "bad optional access";}
virtual ~bad_optional_access() noexcept = default;
};
void
- __throw_bad_optional_access(const char*)
+ __throw_bad_optional_access()
__attribute__((__noreturn__));
// XXX Does not belong here.
inline void
- __throw_bad_optional_access(const char* __s)
- { _GLIBCXX_THROW_OR_ABORT(bad_optional_access(__s)); }
+ __throw_bad_optional_access()
+ { _GLIBCXX_THROW_OR_ABORT(bad_optional_access()); }
/**
* @brief Class template that holds the necessary state for @ref optional
@@ -669,8 +668,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
return this->_M_is_engaged()
? this->_M_get()
- : (__throw_bad_optional_access("Attempt to access value of a "
-"disengaged optional object"),
+ : (__throw_bad_optional_access(),
this->_M_get());
}
@@ -679,8 +677,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
return this->_M_is_engaged()
? this->_M_get()
- : (__throw_bad_optional_access("Attempt to access value of a "
-"disengaged optional object"),
+ : (__throw_bad_optional_access(),
this->_M_get());
}
@@ -689,8 +686,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
return this->_M_is_engaged()
? std::move(this->_M_get())
- : (__throw_bad_optional_access("Attempt to access value of a "
-"disengaged optional object"),
+ : (__throw_bad_optional_access(),
std::move(this->_M_get()));
}
@@ -699,8 +695,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
return this->_M_is_engaged()
? std::move(this->_M_get())
- : (__throw_bad_optional_access("Attempt to access value of a "
-"disengaged optional object"),
+ : (__throw_bad_optional_access(),
std::move(this->_M_get()));
}
diff --git a/libstdc++-v3/testsuite/20_util/optional/cons/value_neg.cc
b/libstdc++-v3/testsuite/20_util/optional/cons/value_neg.cc
index c1d652f..249f622 100644
--- a/libstdc++-v3/testsuite/20_util/optional/cons/value_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/optional/cons/value_neg.cc
@@ -37,8 +37,8 @@ int main()
std::optional> oup2 = new int; // { dg-error
"conversion" }
struct U { explicit U(std::in_place_t); };
std::optional ou(std::in_place); // { dg-error "no matching" }
-// { dg-error "no type" "" { target { *-*-* } } 438 }
-// { dg-error "no type" "" { target { *-*-* } } 448 }
-// { dg-error "no type" "" { target { *-*-* } } 505 }
+// { dg-error "no type" "" { target { *-*-* } } 437 }
+// { dg-error "no type" "" { target { *-*-* } } 447 }
+// { dg-error "no type" "" { target { *-*-* } } 504 }
}
}
diff --git a/libstdc++-v3/testsuite/20_util/optional/typedefs.cc
b/libstdc++-v3/testsuite/20_util/optional/typedefs.cc
index 01b76e8..8d3f997 100644
--- a/libstdc++-v3/testsuite/20_util/optional/typedefs.cc
+++ b/libstdc++-v3/testsuite/20_util/optional/typedefs.cc
@@ -29,5 +29,7 @@ using check2_t = std::in_place_t;
using check3_t = std::nullopt_t;
using check4_t = std::bad_optional_access;
-static_assert(std::is_base_of::value,
- "bad_optional_access must derive from logic_error");
+static_assert(!std::is_base_of::value,
+ "bad_optional_access must derive from exception");
+static_assert(std::is_base_of::value,
+ "bad_optional_access must derive from exception");
[PATCH] Implement LWG 2686, hash
The following is an *untested* patch suggestion, please verify. Notes: My interpretation is that hash should be defined outside of the _GLIBCXX_COMPATIBILITY_CXX0X block, please double-check that course of action. I noticed that the preexisting hash did directly refer to the private members of error_code albeit those have public access functions. For consistency I mimicked that existing style when implementing hash. - Daniel lwg2686.patch Description: Binary data ChangeLog_lwg2686.patch Description: Binary data
Re: [PATCH] Don't ICE if the Fortran FE calls some stor-layout.c etc. function that emits warning, -Wpadded fixes (PR fortran/79886)
Hi Jakub, The Fortran FE registers its own format decoder, overriding the default one that handles what the middle-end can emit, e.g. warning (OPT_Wpadded, "padding struct to align %q+D", field); The C/C++ FEs are the only other ones that override the decoder, but they do handle all the specs the generic decoder handles. This patch chains the default decoder if the spec is not Fortran specific. Another fix is to avoid -Wpadded warnings on every single TU when building the IO artificial data structures. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Thanks for the patch! Thomas
Re: Target maintainers: doc/install.texi love and care
> Date: Sun, 12 Mar 2017 12:34:25 +0100 (CET)
> From: Gerald Pfeifer
> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> > References to dependencies on really, really old versions of
> > binutils (talking 10+ years here) which I think we can remove.
> > Let me follow-up with some of you with concrete suggestions
> > around that.
>
> The cris-axis-elf / cris-axis-linux-gnu section currently has this:
>
> For @code{cris-axis-elf} you need binutils 2.11
> or newer. For @code{cris-axis-linux-gnu} you need binutils 2.12 or newer.
>
> Okay to yank it?
Certainly! Thanks.
brgds, H-P
Re: Target maintainers: doc/install.texi love and care
On Sun, 12 Mar 2017, Hans-Peter Nilsson wrote:
> Certainly! Thanks.
Done thusly; thanks for the quick response, H-P.
(May there be further changes to consider for cris-*?)
Gerald
2017-03-12 Gerald Pfeifer
* doc/install.texi (Specific) : No longer
refer to binutils 2.11/2.12 minimum.
Index: doc/install.texi
===
--- doc/install.texi(revision 246077)
+++ doc/install.texi(working copy)
@@ -3472,9 +3472,6 @@
@samp{ETRAX 100 LX} by default.
@end table
-For @code{cris-axis-elf} you need binutils 2.11
-or newer. For @code{cris-axis-linux-gnu} you need binutils 2.12 or newer.
-
Pre-packaged tools can be obtained from
@uref{ftp://ftp.axis.com/@/pub/@/axis/@/tools/@/cris/@/compiler-kit/}. More
information about this platform is available at
Re: [RFC PATCH libiberty] Fix infinite recursion in demangler
On Wed, 2017-03-08 at 09:05 -0500, Nathan Sidwell wrote:
> thanks. in case you'd not noticed Ian T's okayed my review. so this is
> good to go
Thanks. Markus pushed it including the testcases.
But there are still two testcase (not added, but attached below) that
are still failing (but now just don't demangle, not crash, so that is
progress). You might want to take a look at those since they seem
related to lambda functions: https://gcc.gnu.org/PR68700 and
https://gcc.gnu.org/PR70517
For both of these you can get a demangled symbol if you change the
recursion guard to be dc->d_printing > 2 (instead of 1). We aren't sure
these are valid mangled symbols though. They might represent bugs in the
mangler, not demangler.
Also Markus used Pedro's mangler/demangler dogfooding patch to generate
a list of mangled symbols gcc produces that the demangler cannot
demangle. None of these crash, but they do indicate a bug in either the
mangler or demangler code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79976
Cheers,
Mark
#
# Test for allowing recursion when is_lambda_arg PR68700
_ZN8futurizeI13frozen_schemaE5applyIRZN7seastar7shardedIN7service13storage_proxyEE9invoke_onIZZNS6_22init_messaging_serviceEvENKUljN5utils4UUIDEE8_clEjSA_EUlOT_E_6futureIJS0_T0_jSD_EUlvE_JEEESG_SD_DpOT0_
service::storage_proxy::init_messaging_service()::{lambda(unsigned int,
utils::UUID)#10}::operator()(unsigned int, utils::UUID)
const::{lambda(auto:1&&)#1}
futurize::apply
seastar::sharded::invoke_on >(unsigned int,
service::storage_proxy::init_messaging_service()::{lambda(unsigned int,
utils::UUID)#10}::operator()(unsigned int, utils::UUID)
const::{lambda(auto:1&&)#1})::{lambda()#1}&>(future
seastar::sharded::invoke_on >(unsigned int,
service::storage_proxy::init_messaging_service()::{lambda(unsigned int,
utils::UUID)#10}::operator()(unsigned int, utils::UUID)
const::{lambda(auto:1&&)#1})::{lambda()#1}&)
#
# Test for allowing recursion when is_lambda_arg PR70517
_ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_
std::remove_reference::type> tconcurrent::future::then
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}>(auto
await
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}&&
const)::{lambda()#1}&>::type&&
std::move::type>
tconcurrent::future::then
>(tconcurrent::future::type>
tconcurrent::future::then
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}>(auto
await
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}&&
const)::{lambda()#1}&)::{lambda(auto:1&&
const&)#1}>(tconcurrent::future::type>
tconcurrent::future::then
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}>(auto
await
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}&&
const)::{lambda()#1}&
const)::{lambda()#1}&>(tconcurrent::future::type> tconcurrent::future::then
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}>(auto
await
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}&&
const)::{lambda()#1}& const)
Re: [wwwdocs] gcc-8/porting_to.html
On Thu, 9 Mar 2017, Thomas Preudhomme wrote: JonY: what about the attached patch to document the change of behavior of GCC on Windows depending on the configure option used? +MinGW issues + +GCC on Microsoft Windows can now be configured via +--enable-mingw-wildcard or --disable-mingw-wildcard +to force a specific behavior for GCC itself with regards to supporting or +not the wildcard character. Prior versions of GCC would follow the Perhaps put "(or not)" in parentheses? +configuration of MinGW runtime. This behavior can still be obtained by not +using the above options or by using +--enable-mingw-wildcard=platform. Is this really going to be a question for the Porting Guide, or more something you'd put into the release notes (aka changes.html)? I am thinking more the latter. This patch is approved for gcc-8/changes.html once GCC 7 has branched and gcc-8/changes.html be put in place (though I may be doing that pro- actively later today ;-). Gerald
[wwwdocs] Add release notes template gcc-8/changes.html
Committed, based on gcc-7/changes.html before that one is trimmed down, with some changes to the intro, formatting (simpler),... Gerald PS: In a follow up commmit I added in the empty environments. Index: gcc-8/changes.html === RCS file: gcc-8/changes.html diff -N gcc-8/changes.html --- /dev/null 1 Jan 1970 00:00:00 - +++ gcc-8/changes.html 12 Mar 2017 14:16:47 - @@ -0,0 +1,152 @@ + + + +GCC 8 Release Series — Changes, New Features, and Fixes + + + + + +GCC 8 Release SeriesChanges, New Features, and Fixes + + +This page is a "brief" summary of some of the huge number of improvements +in GCC 8. +You may also want to check out our +Porting to GCC 8 page and the +full GCC documentation. + + + +Disclaimer: GCC 8 has not been released yet, so this document is +a work-in-progress. + + + +Caveats + + + + + +General Improvements + + + + + +New Languages and Language specific improvements + +Ada + + + +BRIG (HSAIL) + +C family + + + +C++ + + + +Go + + + + + +libgccjit + + + +New Targets and Target Specific Improvements + +AArch64 + + + +ARM + + + + + + + +IA-32/x86-64 + + + + + + + + + + + + + +PowerPC / PowerPC64 / RS6000 + + + + + + + + + + + + + + + +Operating Systems + + + + + + + + + + + + + + + + + + + + + + + + + +Other significant improvements + + + + + + + + +
RE: install.texi and mips-*-* (was: Target maintainers: doc/install.texi love and care)
> -Original Message- > From: Gerald Pfeifer [mailto:ger...@pfeifer.com] > Sent: Sunday, March 12, 2017 7:38 AM > To: gcc-patches@gcc.gnu.org; Moore, Catherine > ; Matthew Fortune > > Subject: install.texi and mips-*-* (was: Target maintainers: doc/install.texi > love and care) > > On Sun, 12 Mar 2017, Gerald Pfeifer wrote: > > References to dependencies on really, really old versions of > > binutils (talking 10+ years here) which I think we can remove. > > Let me follow-up with some of you with concrete suggestions > > around that. > > The mips-*-* currently has this: > > The assembler from GNU binutils 2.17 and earlier has a bug in the way > it sorts relocations for REL targets (o32, o64, EABI). This can cause > bad code to be generated for simple C++ programs. Also the linker > from GNU binutils versions prior to 2.17 has a bug which causes the > runtime linker stubs in very large programs to > be incorrectly generated. GNU Binutils 2.18 and later (and snapshots > made after Nov. 9, 2006) should be free from both of these problems. > > (Even that goes back more than 10 years.) > > Okay to yank it? Yes, thank you. I will review the rest of the MIPS doc in install.texi this week. Catherine
Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN
On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
wrote:
> Don't try to use rand_s on CYGWIN
>
> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
> defined even though rand_s is not available. Thus add an extra check
> for __CYGWIN__.
>
> Thanks to Tim Prince and Nightstrike for bringing this issue to my attention.
>
> Committed as r245755.
>
> 2017-02-27 Janne Blomqvist
>
> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
> CYGWIN.
1) There was no patch attached to the email.
2) As mentioned on IRC, I don't think this is the right fix. The real
problem is that time_1.h includes windows.h on CYGWIN, which it
shouldn't be doing. This then pollutes the translation unit with all
sorts of MINGW-isms that aren't exactly appropriate for cygwin.
Removing the include in time_1.h and then adjusting a few ifdefs in
system_clock.c that also had the same bug fixes the problem. The
testsuite is running right now on this.
See the following diff for reference:
Index: ../gccsvn/libgfortran/intrinsics/random.c
===
--- ../gccsvn/libgfortran/intrinsics/random.c (revision 246075)
+++ ../gccsvn/libgfortran/intrinsics/random.c (working copy)
@@ -304,7 +304,7 @@
getosrandom (void *buf, size_t buflen)
{
/* rand_s is available in MinGW-w64 but not plain MinGW. */
-#if defined(__MINGW64_VERSION_MAJOR) && !defined(__CYGWIN__)
+#ifdef __MINGW64_VERSION_MAJOR
unsigned int* b = buf;
for (unsigned i = 0; i < buflen / sizeof (unsigned int); i++)
rand_s (&b[i]);
Index: ../gccsvn/libgfortran/intrinsics/system_clock.c
===
--- ../gccsvn/libgfortran/intrinsics/system_clock.c (revision 246075)
+++ ../gccsvn/libgfortran/intrinsics/system_clock.c (working copy)
@@ -29,7 +29,7 @@
#include "time_1.h"
-#if !defined(__MINGW32__) && !defined(__CYGWIN__)
+#if !defined(__MINGW32__)
/* POSIX states that CLOCK_REALTIME must be present if clock_gettime
is available, others are optional. */
@@ -121,7 +121,7 @@
system_clock_4 (GFC_INTEGER_4 *count, GFC_INTEGER_4 *count_rate,
GFC_INTEGER_4 *count_max)
{
-#if defined(__MINGW32__) || defined(__CYGWIN__)
+#if defined(__MINGW32__)
if (count)
{
/* Use GetTickCount here as the resolution and range is
@@ -174,7 +174,7 @@
system_clock_8 (GFC_INTEGER_8 *count, GFC_INTEGER_8 *count_rate,
GFC_INTEGER_8 *count_max)
{
-#if defined(__MINGW32__) || defined(__CYGWIN__)
+#if defined(__MINGW32__)
LARGE_INTEGER cnt;
LARGE_INTEGER freq;
bool fail = false;
Index: ../gccsvn/libgfortran/intrinsics/time_1.h
===
--- ../gccsvn/libgfortran/intrinsics/time_1.h (revision 246075)
+++ ../gccsvn/libgfortran/intrinsics/time_1.h (working copy)
@@ -101,7 +101,7 @@
CPU_TIME intrinsics. Returns 0 for success or -1 if no
CPU time could be computed. */
-#if defined(__MINGW32__) || defined(__CYGWIN__)
+#if defined(__MINGW32__)
#define WIN32_LEAN_AND_MEAN
#include
RE: install.texi and mips-*-*
On Sun, 12 Mar 2017, Moore, Catherine wrote:
>> Okay to yank it?
> Yes, thank you.
Done per the patch below (committed).
> I will review the rest of the MIPS doc in install.texi this week.
Thank you!
Gerald
2017-03-12 Gerald Pfeifer
* doc/install.texi (Specific) : Remove description of
issue that only occurred with binutils below 2.18.
Index: doc/install.texi
===
--- doc/install.texi(revision 246078)
+++ doc/install.texi(working copy)
@@ -4122,14 +4122,6 @@
@command{configure} option when configuring GCC@. The default is to
use traps on systems that support them.
-The assembler from GNU binutils 2.17 and earlier has a bug in the way
-it sorts relocations for REL targets (o32, o64, EABI). This can cause
-bad code to be generated for simple C++ programs. Also the linker
-from GNU binutils versions prior to 2.17 has a bug which causes the
-runtime linker stubs in very large programs to
-be incorrectly generated. GNU Binutils 2.18 and later (and snapshots
-made after Nov. 9, 2006) should be free from both of these problems.
-
@html
@end html
[patch, fortran] PR39239 reject BIND(C) in EQUIVALENCE
Hello everyone,
this is my first attempt at a patch. The necessary paperwork for me to
contribute is all said & done. I'm looking forward to some more compiler
hacking :)
Nicolas
Here is the changelog:
2017-03-12 Nicolas Koenig
PR fortran/39239
* resolve.c (resolve_equivalence): report an error if
an equivalence variable is BIND(C).
2017-03-12 Nicolas Koenig
PR fortran/39239
* gfortran.dg/equiv_constraint_bind_c.f90: New test.
Index: resolve.c
===
--- resolve.c (revision 246070)
+++ resolve.c (working copy)
@@ -15675,6 +15675,13 @@ resolve_equivalence (gfc_equiv *eq)
&& !resolve_equivalence_derived (e->ts.u.derived, sym, e))
continue;
+ if (sym->attr.is_bind_c)
+ {
+ gfc_error ("EQUIVALENCE object %qs at %L cannot be C interop",
+ sym->name, &e->where);
+ continue;
+ }
+
/* Check that the types correspond correctly:
Note 5.28:
A numeric sequence structure may be equivalenced to another sequence
! Testcase for using EQUIVALENCE with BIND(C)
! See PR fortran/39239
! { dg-do compile }
module m
use iso_c_binding
implicit none
integer(c_int) :: i1, i2
bind(C) :: i2
equivalence(i1,i2) ! { dg-error "cannot be C interop" }
end module m
Re: [patch, fortran] PR39239 reject BIND(C) in EQUIVALENCE
On 03/12/2017 12:29 PM, Nicolas Koenig wrote: Hello everyone, this is my first attempt at a patch. The necessary paperwork for me to contribute is all said & done. I'm looking forward to some more compiler hacking :) Nicolas Here is the changelog: 2017-03-12 Nicolas Koenig PR fortran/39239 * resolve.c (resolve_equivalence): report an error if an equivalence variable is BIND(C). 2017-03-12 Nicolas Koenig PR fortran/39239 * gfortran.dg/equiv_constraint_bind_c.f90: New test. Thanks for joining the effort. I can not say enough about how badly we need help. Best regards! Jerry
Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN
On Sun, Mar 12, 2017 at 1:26 PM, NightStrike wrote: > On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist > wrote: >> Don't try to use rand_s on CYGWIN >> >> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is >> defined even though rand_s is not available. Thus add an extra check >> for __CYGWIN__. >> >> Thanks to Tim Prince and Nightstrike for bringing this issue to my attention. >> >> Committed as r245755. >> >> 2017-02-27 Janne Blomqvist >> >> * intrinsics/random.c (getosrandom): Don't try to use rand_s on >> CYGWIN. > > 1) There was no patch attached to the email. > > 2) As mentioned on IRC, I don't think this is the right fix. The real > problem is that time_1.h includes windows.h on CYGWIN, which it > shouldn't be doing. This then pollutes the translation unit with all > sorts of MINGW-isms that aren't exactly appropriate for cygwin. > Removing the include in time_1.h and then adjusting a few ifdefs in > system_clock.c that also had the same bug fixes the problem. The > testsuite is running right now on this. Testsuite run completed with no change in results: === gfortran Summary === # of expected passes44633 # of unexpected failures55 # of unexpected successes 6 # of expected failures 85 # of unsupported tests 187 /tmp/build/gcc/testsuite/gfortran/../../gfortran version 7.0.1 20170312 (experimental) (GCC) make[1]: Leaving directory '/tmp/build/gcc' Those 55 unexpected failures are unrelated to this change, and occur before and after.
Re: Target maintainers: doc/install.texi love and care
> Date: Sun, 12 Mar 2017 14:47:42 +0100 > From: Gerald Pfeifer > (May there be further changes to consider for cris-*?) Nothing actively pursued and no news on related issues. brgds, H-P
Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN
On Sun, Mar 12, 2017 at 7:26 PM, NightStrike wrote: > On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist > wrote: >> Don't try to use rand_s on CYGWIN >> >> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is >> defined even though rand_s is not available. Thus add an extra check >> for __CYGWIN__. >> >> Thanks to Tim Prince and Nightstrike for bringing this issue to my attention. >> >> Committed as r245755. >> >> 2017-02-27 Janne Blomqvist >> >> * intrinsics/random.c (getosrandom): Don't try to use rand_s on >> CYGWIN. > > 1) There was no patch attached to the email. Oh, sorry. Well, you can see it at https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=245755 > 2) As mentioned on IRC, I don't think this is the right fix. The real > problem is that time_1.h includes windows.h on CYGWIN, which it > shouldn't be doing. This then pollutes the translation unit with all > sorts of MINGW-isms that aren't exactly appropriate for cygwin. > Removing the include in time_1.h and then adjusting a few ifdefs in > system_clock.c that also had the same bug fixes the problem. The > testsuite is running right now on this. It used to be something like that, but IIRC there were some complaints about SYSTEM_CLOCK on cygwin that were due to the cygwin clock_gettime() or something like that, and after some discussion with someone who knows something about cygwin/mingw (since you apparently have no memory of it, I guess it was Kai), it was decided to use GetTickCount & QPC also on cygwin. -- Janne Blomqvist
[patch, fortran] Fix PR 79956, part two
Hello world,
the attached patch fixes another occurence of PR 79956.
In this case, we did
sdim = GFC_DESCRIPTOR_RANK (source);
..
for (n = 0; n < sdim; n++)
{
sstride[n] = GFC_DESCRIPTOR_STRIDE(source,n)
}
Now, we know that sdim can never be zero or lower, but
the compiler doesn't, so it warned. (Why that didn't
happen on x86_64 is an unsolved mystery so far).
So, the attached patch inserts a call to internal_error
when sdim is lower than one.
Regression-tested. OK for trunk?
Thomas
2017-03-12 Thomas Koenig
PR libfortran/79956
* m4/reshape.m4 (reshape_'rtype_ccode`): Add check for sdim < 1 so
that later assignment from sstride[0] does not cause problems.
* intrinsic/reshape_generic.c (reshape_internal): Likweise.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_r8.c: Regenerated.
Index: generated/reshape_c10.c
===
--- generated/reshape_c10.c (Revision 245760)
+++ generated/reshape_c10.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_c10 (gfc_array_c10 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (source);
+
+ /* This is needed so that gcc knows that n is at least one,
+ and that sstride[0] is always initialized. */
+ if (sdim < 1)
+internal_error (NULL, "Source array cannot be scalar");
+
ssize = 1;
sempty = 0;
for (n = 0; n < sdim; n++)
Index: generated/reshape_c16.c
===
--- generated/reshape_c16.c (Revision 245760)
+++ generated/reshape_c16.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_c16 (gfc_array_c16 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (source);
+
+ /* This is needed so that gcc knows that n is at least one,
+ and that sstride[0] is always initialized. */
+ if (sdim < 1)
+internal_error (NULL, "Source array cannot be scalar");
+
ssize = 1;
sempty = 0;
for (n = 0; n < sdim; n++)
Index: generated/reshape_c4.c
===
--- generated/reshape_c4.c (Revision 245760)
+++ generated/reshape_c4.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_c4 (gfc_array_c4 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (source);
+
+ /* This is needed so that gcc knows that n is at least one,
+ and that sstride[0] is always initialized. */
+ if (sdim < 1)
+internal_error (NULL, "Source array cannot be scalar");
+
ssize = 1;
sempty = 0;
for (n = 0; n < sdim; n++)
Index: generated/reshape_c8.c
===
--- generated/reshape_c8.c (Revision 245760)
+++ generated/reshape_c8.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_c8 (gfc_array_c8 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (source);
+
+ /* This is needed so that gcc knows that n is at least one,
+ and that sstride[0] is always initialized. */
+ if (sdim < 1)
+internal_error (NULL, "Source array cannot be scalar");
+
ssize = 1;
sempty = 0;
for (n = 0; n < sdim; n++)
Index: generated/reshape_i16.c
===
--- generated/reshape_i16.c (Revision 245760)
+++ generated/reshape_i16.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_16 (gfc_array_i16 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (source);
+
+ /* This is needed so that gcc knows that n is at least one,
+ and that sstride[0] is always initialized. */
+ if (sdim < 1)
+internal_error (NULL, "Source array cannot be scalar");
+
ssize = 1;
sempty = 0;
for (n = 0; n < sdim; n++)
Index: generated/reshape_i4.c
===
--- generated/reshape_i4.c (Revision 245760)
+++ generated/reshape_i4.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_4 (gfc_array_i4 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (source);
+
+ /* This is needed so that gcc knows that n is at least one,
+ and that sstride[0] is always initialized. */
+ if (sdim < 1)
+internal_error (NULL, "Source array cannot be scalar");
+
ssize = 1;
sempty = 0;
for (n = 0; n < sdim; n++)
Index: generated/reshape_i8.c
===
--- generated/reshape_i8.c (Revision 245760)
+++ generated/reshape_i8.c (Arbeitskopie)
@@ -232,6 +232,12 @@ reshape_8 (gfc_array_i8 * const restrict ret,
}
sdim = GFC_DESCRIPTOR_RANK (so
Re: terminology: zero character vs. null character
On Fri, 10 Mar 2017, Manuel López-Ibáñez wrote: >> I am currently translating GCC into German. During that, I noticed that >> in some places the term "zero character" means '\0'. The official term >> though is "null character", as per the C standard. > I don't see anything explicit here: https://gcc.gnu.org/codingconventions.html > But I believe we follow standards' language and it should always be "null > character". Agreed. Joseph, do you also agree (and with the patch below to document this)? Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.79 diff -u -r1.79 codingconventions.html --- codingconventions.html 1 Mar 2017 12:53:57 - 1.79 +++ codingconventions.html 12 Mar 2017 21:26:56 - @@ -439,6 +439,11 @@ +"null character" +"zero character" + + + "Objective-C" "Objective C"
Re: install.texi and sparc-*-linux*
From: Gerald Pfeifer
Date: Sun, 12 Mar 2017 12:39:56 +0100 (CET)
> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
>> References to dependencies on really, really old versions of
>> binutils (talking 10+ years here) which I think we can remove.
>> Let me follow-up with some of you with concrete suggestions
>> around that.
>
> The section on sparc-*-linux* currently has this:
>
> GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
> or newer on this platform. All earlier binutils and glibc
> releases mishandled unaligned relocations on @code{sparc-*-*} targets.
>
> Okay to yank it?
No objections from me.
[PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.
While integrating the d_printing recursion guard change into gdb I
noticed we forgot to initialize the demangle_component d_printing
field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}.
As is done in cplus_demangle_fill_{component,builtin_type,operator}.
It happened to work because in gcc all demangle_components were
allocated through d_make_empty. But gdb has its own allocation
mechanism (as might other users).
libiberty/ChangeLog:
* cp-demangle.c (cplus_demangle_fill_name): Initialize
demangle_component d_printing.
(cplus_demangle_fill_extended_operator): Likewise.
(cplus_demangle_fill_ctor): Likewise.
(cplus_demangle_fill_dtor): Likewise.
---
libiberty/ChangeLog | 8
libiberty/cp-demangle.c | 4
2 files changed, 12 insertions(+)
diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
index e93e327..b513fce 100644
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,11 @@
+2017-03-12 Mark Wielaard
+
+ * cp-demangle.c (cplus_demangle_fill_name): Initialize
+ demangle_component d_printing.
+ (cplus_demangle_fill_extended_operator): Likewise.
+ (cplus_demangle_fill_ctor): Likewise.
+ (cplus_demangle_fill_dtor): Likewise.
+
2017-03-08 Mark Wielaard
PR demangler/70909
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 341a418..04832ff 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -854,6 +854,7 @@ cplus_demangle_fill_name (struct demangle_component *p,
const char *s, int len)
{
if (p == NULL || s == NULL || len == 0)
return 0;
+ p->d_printing = 0;
p->type = DEMANGLE_COMPONENT_NAME;
p->u.s_name.s = s;
p->u.s_name.len = len;
@@ -869,6 +870,7 @@ cplus_demangle_fill_extended_operator (struct
demangle_component *p, int args,
{
if (p == NULL || args < 0 || name == NULL)
return 0;
+ p->d_printing = 0;
p->type = DEMANGLE_COMPONENT_EXTENDED_OPERATOR;
p->u.s_extended_operator.args = args;
p->u.s_extended_operator.name = name;
@@ -888,6 +890,7 @@ cplus_demangle_fill_ctor (struct demangle_component *p,
|| (int) kind < gnu_v3_complete_object_ctor
|| (int) kind > gnu_v3_object_ctor_group)
return 0;
+ p->d_printing = 0;
p->type = DEMANGLE_COMPONENT_CTOR;
p->u.s_ctor.kind = kind;
p->u.s_ctor.name = name;
@@ -907,6 +910,7 @@ cplus_demangle_fill_dtor (struct demangle_component *p,
|| (int) kind < gnu_v3_deleting_dtor
|| (int) kind > gnu_v3_object_dtor_group)
return 0;
+ p->d_printing = 0;
p->type = DEMANGLE_COMPONENT_DTOR;
p->u.s_dtor.kind = kind;
p->u.s_dtor.name = name;
--
1.8.3.1
PATCH for Re: Release notes for GCC 7?
On Wed, 24 Aug 2016, Richard Biener wrote: > We've been creating those lazily over the last decade. We can change > that, an entry for releasing.html is appreciated then so we don't forget. And here we go, in time for the release of GCC 7 / branching of GCC 8. (Except, this time I went ahead and already created gcc-8/changes.html so that you guys don't have to worry about that. ;-) Note, I added this to branching.html, not releasing.html, not the least since branching.html already had the creation of other web pages for the new release series and that also seems the more appropriate point time- wise. Agreed? Gerald Index: branching.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v retrieving revision 1.32 diff -u -r1.32 branching.html --- branching.html 28 Jun 2014 10:34:16 - 1.32 +++ branching.html 12 Mar 2017 22:37:59 - @@ -7,6 +7,8 @@ This page documents the procedure for making a new release branch. +Preparations + Execute the following commands, substituting appropriate version numbers: @@ -38,15 +40,25 @@ for the next major release in the wwwdocs repository and populate it with initial copies of changes.html and criteria.html. + -Add index.html and buildstat.html pages -to the directory corresponding to the newly created release branch. -Update the toplevel buildstat.html accordingly. +Web Site Updates + + +Add index.html and changes.html pages +based on the previous release branch to the directory corresponding to +the newly created release branch. + +Add buildstat.html and update the toplevel +buildstat.html accordingly. Update the toplevel index.html page to show the new active release branch, the current release series, and active development (mainline). Update the version and development stage for mainline. + + Update maintainer-scripts/crontab on the mainline by adding an entry to make snapshots of the new branch and adjusting the version number of the mainline snapshots. @@ -67,7 +79,11 @@ Send them to the translation project if no snapshot of this version was sent during development stage 3 or 4. + +Bugzilla Updates + + Create new versions in Bugzilla corresponding to the new mainline version. This can be accomplished by choosing "products", choosing "gcc", and editing the versions. Please do not delete old @@ -85,7 +101,6 @@ Ask Daniel Berlin to adjust all PRs with the just-branched version in their summary to also contain the new version corresponding to mainline. -
Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
Hi Martin,
On Mon, 27 Feb 2017, Martin Sebor wrote:
> Sorry to be jumping in so late. I only noticed this bit now.
>
> I would suggest to say that these new built-ins evaluate to integer
> constant expressions when their arguments do. Not all C programmers
> are familiar with C++ constexpr so they may not understand the use
> use case. The request for these built-ins also came from a C user
> and was specifically motivated by avoiding -Woverflow warnings so
> adding an example demonstrating that might be helpful as well.
> Something like this:
>
> ... Calls to these built-ins with integer constant arguments
> evaluate to integer constants expressions.
> For example, in the following, c is assigned
> the result of a * b only if the multiplication
> does not overflow, otherwise it is assigned the value zero.
> The multiplication is performed at compile-time and without
> triggering a -Woverflow warning.
>
> enum {
> a = 12345678,
> b = 87654321,
> c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
> };
>
this works for me, modulo the closing which I believe will be
necessary. Were you seeing approval for this from someone? (If so,
that may not have been me. ;-)
Gerald
Re: [wwwdocs] gcc-8/porting_to.html
On 03/12/2017 02:07 PM, Gerald Pfeifer wrote: > On Thu, 9 Mar 2017, Thomas Preudhomme wrote: >> JonY: what about the attached patch to document the change of behavior >> of GCC on Windows depending on the configure option used? > > +MinGW issues > + > +GCC on Microsoft Windows can now be configured via > +--enable-mingw-wildcard or > --disable-mingw-wildcard > +to force a specific behavior for GCC itself with regards to supporting or > +not the wildcard character. Prior versions of GCC would follow the > > Perhaps put "(or not)" in parentheses? > > +configuration of MinGW runtime. This behavior can still be obtained by not > +using the above options or by using > +--enable-mingw-wildcard=platform. > > Is this really going to be a question for the Porting Guide, or more > something you'd put into the release notes (aka changes.html)? I am > thinking more the latter. > > This patch is approved for gcc-8/changes.html once GCC 7 has branched > and gcc-8/changes.html be put in place (though I may be doing that pro- > actively later today ;-). > > Gerald > It should be part of the release notes since it only affects GCC itself, not the actual generated output. signature.asc Description: OpenPGP digital signature
New German PO file for 'gcc' (version 7.1-b20170226)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-7.1-b20170226.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[PATCH] correct aligned_alloc argument order (PR 80020)
r243470 decorates standard allocation functions like alloca
and malloc with attribute alloc_size. However, in applying
the attribute to aligned_alloc I had overlooked that the size
argument is the second one and not the first. That oversight
has led to __builtin_object_size() reporting the wrong size
for aligned_alloc-allocated objects and, consequently, to
checking functions like __memset_chk calling abort for buffer
bogus overflows.
The attached patch corrects this mistake by decorating the
function with the correct alloc_size attribute.
Martin
PR middle-end/80020 - gcc confused about aligned_alloc argument order
gcc/testsuite/ChangeLog:
PR middle-end/80020
* gcc.dg/attr-alloc_size-6.c: Correct aligned_alloc argument order.
* gcc.dg/attr-alloc_size-7.c: Same.
* gcc.dg/attr-alloc_size-9.c: Same.
* gcc.dg/builtin-alloc-size.c: Same.
* gcc.dg/pr80020.c: New test.
gcc/ChangeLog:
PR middle-end/80020
* builtin-attrs.def (ATTR_ALLOC_SIZE_2_NOTHROW_LIST): New macro.
* builtins.def (aligned_alloc): Use it.
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 2753288..2396f00 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -156,9 +156,12 @@ DEF_ATTR_TREE_LIST (ATTR_COLD_CONST_NORETURN_NOTHROW_LEAF_LIST, ATTR_CONST,\
ATTR_NULL, ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
/* Allocation functions like malloc and realloc whose first argument
- specifies the size of the allocated object. */
+ with _SIZE_1, or second argument with _SIZE_2, specifies the size
+ of the allocated object. */
DEF_ATTR_TREE_LIST (ATTR_MALLOC_SIZE_1_NOTHROW_LIST, ATTR_ALLOC_SIZE, \
ATTR_LIST_1, ATTR_MALLOC_NOTHROW_LIST)
+DEF_ATTR_TREE_LIST (ATTR_ALLOC_SIZE_2_NOTHROW_LIST, ATTR_ALLOC_SIZE, \
+ ATTR_LIST_2, ATTR_MALLOC_NOTHROW_LIST)
DEF_ATTR_TREE_LIST (ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST, ATTR_ALLOC_SIZE, \
ATTR_LIST_1, ATTR_MALLOC_NOTHROW_LEAF_LIST)
/* Alloca is just like malloc except that it never returns null. */
diff --git a/gcc/builtins.def b/gcc/builtins.def
index d7f80e6..197c8ac 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -297,7 +297,7 @@ DEF_C99_BUILTIN(BUILT_IN_ACOSH, "acosh", BT_FN_DOUBLE_DOUBLE, ATTR_MATHF
DEF_C99_BUILTIN(BUILT_IN_ACOSHF, "acoshf", BT_FN_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_C99_BUILTIN(BUILT_IN_ACOSHL, "acoshl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_C99_C90RES_BUILTIN (BUILT_IN_ACOSL, "acosl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
-DEF_C11_BUILTIN(BUILT_IN_ALIGNED_ALLOC, "aligned_alloc", BT_FN_PTR_SIZE_SIZE, ATTR_MALLOC_SIZE_1_NOTHROW_LIST)
+DEF_C11_BUILTIN(BUILT_IN_ALIGNED_ALLOC, "aligned_alloc", BT_FN_PTR_SIZE_SIZE, ATTR_ALLOC_SIZE_2_NOTHROW_LIST)
DEF_LIB_BUILTIN(BUILT_IN_ASIN, "asin", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_C99_C90RES_BUILTIN (BUILT_IN_ASINF, "asinf", BT_FN_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
DEF_C99_BUILTIN(BUILT_IN_ASINH, "asinh", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING)
diff --git a/gcc/testsuite/gcc.dg/attr-alloc_size-6.c b/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
index 38890b6..fc3e22c 100644
--- a/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
+++ b/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
@@ -15,8 +15,8 @@ void sink (void*);
void test_lit (char *p, char *q)
{
- sink (__builtin_aligned_alloc (MAXOBJSZ, 1));
- sink (__builtin_aligned_alloc (MAXOBJSZ + 1, 1)); /* { dg-warning "argument 1 value .12346\[lu\]*. exceeds maximum object size 12345" } */
+ sink (__builtin_aligned_alloc (1, MAXOBJSZ));
+ sink (__builtin_aligned_alloc (1, MAXOBJSZ + 1)); /* { dg-warning "argument 2 value .12346\[lu\]*. exceeds maximum object size 12345" } */
sink (__builtin_alloca (MAXOBJSZ));
sink (__builtin_alloca (MAXOBJSZ + 2)); /* { dg-warning "argument 1 value .12347\[lu\]*. exceeds maximum object size 12345" } */
@@ -46,8 +46,8 @@ enum { max = MAXOBJSZ };
void test_cst (char *p, char *q)
{
- sink (__builtin_aligned_alloc (max, 1));
- sink (__builtin_aligned_alloc (max + 1, 1)); /* { dg-warning "argument 1 value .12346\[lu\]*. exceeds maximum object size 12345" } */
+ sink (__builtin_aligned_alloc (1, max));
+ sink (__builtin_aligned_alloc (1, max + 1)); /* { dg-warning "argument 2 value .12346\[lu\]*. exceeds maximum object size 12345" } */
sink (__builtin_alloca (max));
sink (__builtin_alloca (max + 2)); /* { dg-warning "argument 1 value .12347\[lu\]*. exceeds maximum object size 12345" } */
diff --git a/gcc/testsuite/gcc.dg/attr-alloc_size-7.c b/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
index d6e618d..a3b2a6b 100644
--- a/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
+++ b/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
@@ -22,8 +22,8 @@ void test_var (void *p)
{
size_t max = maxobjsize ();
- sink (__builtin_aligned_alloc (max, 1));
- sink (__builtin_aligned_alloc (max + 1, 1)); /* { dg-warning "argument 1 value .12346\[lu\]*. exceeds maximum
Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)
On 03/10/2017 10:51 PM, Jeff Law wrote:
On 03/10/2017 09:20 AM, Martin Sebor wrote:
On 03/10/2017 05:57 AM, Rainer Orth wrote:
Hi Segher,
On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote:
Segher Boessenkool writes:
As stated in the PR, this test now passes on aarch64, ia64, powerpc,
and s390x. This patch disables the xfails for those targets.
As I'd mentioned in PR tree-optimization/78775, the test XPASSes on
SPARC, too.
Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
[...]
2017-02-09 Segher Boessenkool
gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64,
powerpc,
or s390x.
TBH, I'd strongly prefer to have a proper analysis instead of just
un-xfail-ing the test on an ever growing apparently random list of
targets.
Yeah, I agree. I thought it was just another test that stopped
failing,
but it seems to fail in two ways now, making the testcase succeed?
Lovely. Please consider this patch withdrawn.
I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.
So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.
I'd still be very grateful if Martin could have a look what's really
going on here, though.
Sorry, I haven't had a chance to look more deeply into why these
assertions pass on some targets and fail on others. There is at
least one bug that tracks a VRP problem that manifests only on
some targets and not others (79054). I don't know if this is
a symptom of the same bug or something different. I'll see if
I can find some time to isolate it.
It could well be a BRANCH_COST effect. BRANCH_COST is probably the most
annoying target property that bleeds into the tree/gimple world. From
looking at the gimple in the BZ that could well be the case.
See logical_op_short_circuit for how this is often dealt with in the
testsuite.
Thanks for the hint. I extracted the test case from
attr-alloc_size-11.c and reproduced the discrepancy on powerpc64le
and x86_64. It looks to me like two bugs(?) conspire to trigger
it. I opened pr80006 with the details and I'm working on a patch.
Here's some more detail. First, on x86_64 (but not on powerpc64le
and I suspect the other targets where this assertion passes), GCC
very early on introduces a spurious conversion from signed char to
int. For instance, given:
void* f (signed char x)
{
extern void* ff (signed char) __attribute__ ((alloc_size (1)));
if (-3 <= x && x <= 7)
x = -4;
return ff (x);
}
the tree-original dump on x86_64 is as follows (note the (int)x
cast):
;; Function f (null)
;; enabled by -tree-original
{
extern void * ff (signed char);
if ((unsigned char) x + 3 <= 10)
{
x = -4;
}
return ff ((int) x); <<< spurious cast
}
while the following the same dump on powerpc64le (no cast):
;; Function f (null)
;; enabled by -tree-original
{
extern void * ff (signed char);
if ((unsigned char) x + 3 <= 10)
{
x = -4;
}
return ff (x); <<< no cast
}
The cast makes its way to VRP where it causes the range on x
to be lost in the conversion to the temporary it introduces:
Found new range for x_4: ~[-3, 7]
marking stmt to be not simulated again
Visiting statement:
_9 = (int) x_4;
Meeting
[-128, -4]
and
[8, 127]
to
[-128, 127]
Found new range for _9: [-128, 127] <<< anti-range lost
...
Visiting PHI node: prephitmp_10 = PHI <_9(3), -4(2)>
...
Meeting
[-128, 127]
and
[-4, -4]
to
[-128, 127]
Intersecting
[-128, 127]
and
[-128, 127]
to
[-128, 127]
Found new range for prephitmp_10: [-128, 127]
...
Visiting statement:
_8 = ff (prephitmp_10);
Debugging tree-vrp.c suggests that this is a deficiency in
the extract_range_from_unary_expr function the computes the
range of the result of the NOP_EXPR (the cast) of an SSA_NAME
with an anti-range ~[A, B] as a union of [TYPE_MIN, A - 1] and
[B + 1, TYPE_MAX], which for ~[-3, 7] and the signed char x in
the test case results in [SCHAR_MIN, -4] U [8, SCHAR_MAX], or
[SCHAR_MIN, SCHAR_MAX]. There's a comment in the function
that reads:
/* Now canonicalize anti-ranges to ranges when they are not
symbolic and express op ~[] as (op []') U (op []''). */
indicating this is deliberate but I have no idea why or if
it's important.
After adding code to handle this case none of the VRP tests
broke so maybe it's just an oversight. But even with this
case handled and the anti-range propagated to the result of
the cast, there's still a problem. The vrp_visit_phi_node
function that updates the range of the result of a PHI node
merges the existing range of the LHS with the range of the
PHI. This again results in the anti-range being lost and
replaced with that of the type of the RHS (signed char
