Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”
On Sun, Apr 30, 2017 at 11:56 PM, Freddie Chopin wrote:
> Hello!
>
> A code that I wrote was warning-free in GCC 4.9, GCC 5 and GCC 6. It
> was also warning-free with some older GCC 7 experimental snapshots (for
> example 7-20170409). But in the most recent snapshot (including the
> first RC), it started to produce a warning about aliasing. The code
> basically boils down to this:
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> #include
>
> std::aligned_storage::type storage;
>
> int main()
> {
> *reinterpret_cast(&storage) = 42;
> }
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> Compilation with latest GCC 7 RC:
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> $ g++ -Wall -O2 -c main.cpp
> main.cpp: In function 'int main()':
> main.cpp:7:34: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
> *reinterpret_cast(&storage) = 42;
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> (interesting observation is that the warning is not produced when
> optimizations are disabled)
>
> Compilation with GCC 6 gives no warnings at all.
>
> Now I'm wondering, the code above definitely HAS type-punning, no
> question about that, but isn't std::aligned_storage meant to be used
> that way?
>
> For instance the example code given here on cppreference generally
> produces no warning with GCC 7 but only because:
> - std::string somehow is not affected,
> - std::aligned_storage is accessed with an offset.
>
> http://en.cppreference.com/w/cpp/types/aligned_storage
>
> By changing std::string into int, removing offset access to
> std::aligned_storage and removing irrelevant parts you get this:
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> #include
> #include
> #include
>
> template
> class static_vector
> {
> // properly aligned uninitialized storage for N T's
> typename std::aligned_storage::type data[N];
> std::size_t m_size = 0;
>
> public:
>
> // Access an object in aligned storage
> const T& operator[](std::size_t pos) const
> {
> return *reinterpret_cast(data/*+pos*/); // <- note
> here, offset access disabled
> }
> };
>
> int main()
> {
> static_vector v1;
> std::cout << v1[0] << '\n' << v1[1] << '\n';
> }
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> And this produces exactly the same warning:
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> main.cpp: In instantiation of 'const T& static_vector N>::operator[](std::size_t) const [with T = int; unsigned int N = 10;
> std::size_t = unsigned int]':
> main.cpp:24:22: required from here
> main.cpp:17:16: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
> return *reinterpret_cast(data/*+pos*/);
> ^
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> So my question is - is this a bug or a feature?
First of all the -Wstrict-aliasing warning is not very accurate. But this shows
an issue with GCC 7 so please open a bugreport. Testcase without libstd++
headers:
template
struct aligned_storage
{
union type
{
unsigned char __data[_Len];
struct __attribute__((__aligned__((_Align { } __align;
};
};
aligned_storage::type storage;
int main()
{
*reinterpret_cast(&storage) = 42;
}
and we warn from
525 && (set1 == 0
526 || (!alias_set_subset_of (set2, set1)
527 && !alias_sets_conflict_p (set1, set2
528 {
529 warning (OPT_Wstrict_aliasing, "dereferencing
type-punned "
530"pointer will break strict-aliasing rules");
531 return true;
where set1 == 0 (of 'storage') and set2 == 1 (of 'int'). Not sure why we warn
if set1 == 0 ...
Richard.
> Thanks in advance!
>
> Regards,
> FCh
>
> BTW - I've also posted this question on stackoverflow
> http://stackoverflow.com/questions/43711567/gcc-7-aligned-storage-and-dereferencing-type-punned-pointer-will-break-strict
Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”
On Tue, 2017-05-02 at 12:17 +0200, Richard Biener wrote: > But this shows > an issue with GCC 7 so please open a bugreport. Here it is - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 Regards, FCh
Contributor legal forms
Hello GCC maintainers – I am writing to request the legal forms necessary to contribute to the GCC code base (assignment for changes and employer disclaimer) . I’ll be working with Johnathan Wakely on the implementation of the C++ extensions for networking: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf Best Regards, --David King This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature. For additional important disclaimers and disclosures regarding KCG’s products and services, please click on the following link: http://www.kcg.com/legal/global-disclosures
Re: Contributor legal forms
Hi David, I'll send you the forms to complete. On 2 May 2017 at 12:35, David King wrote: > Hello GCC maintainers – > > I am writing to request the legal forms necessary to contribute to the GCC > code base (assignment for changes and employer disclaimer) . I’ll be working > with Johnathan Wakely on the implementation of the C++ extensions for > networking: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf > > > Best Regards, > --David King > > This e-mail and its attachments are intended only for the individual or > entity to whom it is addressed and may contain information that is > confidential, privileged, inside information, or subject to other > restrictions on use or disclosure. Any unauthorized use, dissemination or > copying of this transmission or the information in it is prohibited and may > be unlawful. If you have received this transmission in error, please notify > the sender immediately by return e-mail, and permanently delete or destroy > this e-mail, any attachments, and all copies (digital or paper). Unless > expressly stated in this e-mail, nothing in this message should be construed > as a digital or electronic signature. For additional important disclaimers > and disclosures regarding KCG’s products and services, please click on the > following link: > > http://www.kcg.com/legal/global-disclosures
GCC 7.1 Released
We are proud to announce the next, major release of the GNU Compiler Collection, 7.1. This year we celebrated the 30th anniversary of the first GCC beta release and this month we will celebrate 30 years since the GCC 1.0 release. GCC 7.1 is a major release containing substantial new functionality not available in GCC 6.x or previous GCC releases. The C++ frontend now has experimental support for all of the current C++17 draft, with the -std=c++1z and -std=gnu++1z options, and the libstdc++ library has most of the C++17 draft library features implemented too. This releases features various improvements in the emitted diagnostics, including improved locations, location ranges, suggestions for misspelled identifiers, option names, fix-it hints and various new warnings have been added. The optimizers have been improved, with improvements appearing in all of intra- and inter-procedural optimizations, link time optimizations and various target backends, including, but not limited to, additions of store merging pass, code hoisting optimization, loop splitting, and shrink wrapping improvements. The Address Sanitizer can now report uses of variables after leaving their scope. GCC now can be configured for OpenMP 4.5 offloading to NVidia PTX GPGPUs. Some code that compiled successfully with older GCC versions might require some code adjustments, see http://gcc.gnu.org/gcc-7/porting_to.html for details. See https://gcc.gnu.org/gcc-7/changes.html for more information about changes in GCC 7.1. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-7.1.0/ subdirectory. If you encounter difficulties using GCC 7.1, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GNU Compiler Collection would not be possible without support from its many contributors. Not to only mention its developers but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually! Please consider a donation to the GNU Toolchain Fund to support the continued development of GCC!
Web page for binaries
Hi, I’m suggesting we apply the following patch to provide links to macOS package managers, where users can download binaries for GCC on macOS. I have included the two major ones, Homebrew and MacPorts. FX macos.diff Description: Binary data
Re: Web page for binaries
Hi FX, On Tue, 2 May 2017, FX wrote: > I’m suggesting we apply the following patch to provide links to macOS > package managers, where users can download binaries for GCC on macOS. I > have included the two major ones, Homebrew and MacPorts. did you mean to send this to gcc-patches@ ? The change looks fine to me, but note that this page (like all of our installation instructions) is generated from gcc/doc/install.texi. Gerald
Question about -fopt-info output (-fopt-info vs. -fopt-info-all)
I have a question about -fopt-info. According to the GCC documentation at:
https://gcc.gnu.org/onlinedocs/gccint/Dump-examples.html
| If options is omitted, it defaults to all-all, which means dump all
| available optimization info from all the passes. In the following example,
| all optimization info is output on to stderr.
|
| gcc -O3 -fopt-info
But when I use the '-fopt-info' flag, I get less output about vectorization
than when I use '-fopt-info-all' or '-fopt-info-all-all'.
For example if I compile:
int foo(int *a, int *b, int *c, int n) {
int i;
for (i = 0; i < n; i++)
a[i] = b[i] + c[i];
}
with '-O3 -fopt-info' I get 6 lines of output. '-O3 -fopt-info-all'
or '-O3 -fopt-info-all-all' gives me 453 lines of output.
Is the documentation wrong, the implementation wrong, or my understanding
of what the documentation is saying wrong?
Steve Ellcey
sell...@cavium.com
gcc-5-20170502 is now available
Snapshot gcc-5-20170502 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170502/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 247527 You'll find: gcc-5-20170502.tar.bz2 Complete GCC SHA256=ce8cfd3eb78fe7dcde1cef94f7430a0d8abf01b9f48890c03a2fd730212880b9 SHA1=631238fb5421ed0181a75f4a9e780edff5a595aa Diffs from 5-20170425 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Support Library Requirements for GCC 7.1
Hi I am trying to update the gcc version for rtems to 7.1 and running into trouble finding the correct versions of mpc, mpfr, and gmp. We build those as part of building gcc so we have configuration control over the set. With gcc 6.3.0, we have this in our build recipe: %define mpfr_version 2.4.2 %define mpc_version0.8.1 %define gmp_version4.3.2 I tried that with gcc 7.1.0 but the build failed complaining mpfr was too old. I upgraded mpfr and them got a compiler error which appeared to be GMP related so I bumped GMP. The same error remained: ../../../gcc-7.1.0/mpc/src/acos.c: In function 'mpc_acos': ../../../gcc-7.1.0/mpc/src/acos.c:192:19: error: 'GMP_RNDA' undeclared (first use in this function) : rnd_im == GMP_RNDA ? GMP_RNDZ I bumped MPC to 1.0.3 which worked. Now we are using this in the build recipe. %define mpfr_version 3.1.5 %define mpc_version1.0.3 %define gmp_version6.1.2 The gcc-7.1.0/INSTALL/prerequisites.html seem to be out of date. I am sure the minimum is lower than what I ended up using. What are the correct minimums for gcc 7.1? Thanks. -joel
RE: [Non-DoD Source] Support Library Requirements for GCC 7.1
Joel,
Normally I try building the latest gcc snapshots using the latest versions of
prerequisite codes. Some codes are required to build GCC itself while others
are needed for the "make check" phase. Below is what I use for the whole
build and test process:
#
# ActiveTcl-8.6.6.8606-x86_64-linux-glibc-2.5-401948.tar.gz
#
http://www.activestate.com/activetcl/downloads
# autoconf-2.69.tar.gz ftp://ftp.gnu.org/gnu/autoconf/
# autogen-5.18.12.tar.gz
ftp://ftp.gnu.org/gnu/autogen/rel5.18.12/
# binutils-2.28.tar.gz ftp://ftp.gnu.org/gnu/binutils/
# bison-3.0.4.tar.gzftp://ftp.gnu.org/gnu/bison/
# dejagnu-1.6.tar.gzftp://ftp.gnu.org/gnu/dejagnu/
# expect5.45.tar.gz http://expect.sourceforge.net/#unix
# flex-2.6.0.tar.gz
https://sourceforge.net/projects/flex/files/
# gawk-4.1.4.tar.gz ftp://ftp.gnu.org/gnu/gawk/
# gc-7.6.0.tar.gz http://www.hboehm.info/gc/gc_source/
# gcc-${ver}.tar.bz2
http://mirrors.concertpass.com/gcc/snapshots/${ver}/
# or
http://mirrors.concertpass.com/gcc/releases/gcc-${ver}/
# gdb-7.12.1.tar.gz ftp://ftp.gnu.org/gnu/gdb/
# gettext-0.19.8.1.tar.gz ftp://ftp.gnu.org/gnu/gettext/
# gmp-6.1.2.tar.bz2 ftp://ftp.gnu.org/gnu/gmp/
# guile-2.0.14.tar.gz ftp://ftp.gnu.org/gnu/guile/
# isl-0.18.tar.gz http://isl.gforge.inria.fr/
# libatomic_ops-7.4.4.tar.gz
https://github.com/ivmai/libatomic_ops/wiki/Download
# libffi-3.2.1.tar.gz https://sourceware.org/libffi/
# libtool-2.4.6.tar.gz ftp://ftp.gnu.org/gnu/libtool/
# libunistring-0.9.7.tar.gz ftp://ftp.gnu.org/gnu/libunistring/
# m4-1.4.18.tar.gz ftp://ftp.gnu.org/gnu/m4/
# mpc-1.0.3.tar.gz ftp://ftp.gnu.org/gnu/mpc/
# mpfr-3.1.5.tar.gz ftp://ftp.gnu.org/gnu/mpfr/
# perl-5.24.1.tar.gzhttps://www.perl.org/get.html
# readline-7.0.tar.gz ftp://ftp.gnu.org/gnu/readline/
# texinfo-6.3.tar.gzftp://ftp.gnu.org/gnu/texinfo/
#
The exception I find to using the latest codes is guile. With guile, the
latest version I can use is 2.0.14. There are more recent versions of guile
(2.2.0, 2.2.1, 2.2.2), but they seem to be incompatible with the GCC testing
phase. Unfortunately, clicking on the "documentation" link on the 7.1
announcement page https://gcc.gnu.org/gcc-7/ gives me
Forbidden
You don't have permission to access /onlinedocs/7.1.0/ on this server.
Apache Server at gcc.gnu.org Port 443
Tom Oppe
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joel
Sherrill
Sent: Tuesday, May 02, 2017 6:18 PM
To: GCC Mailing List
Subject: [Non-DoD Source] Support Library Requirements for GCC 7.1
Hi
I am trying to update the gcc version for rtems to 7.1 and running into
trouble finding the correct versions of mpc, mpfr, and gmp. We build those as
part of building gcc so we have configuration control over the set.
With gcc 6.3.0, we have this in our build recipe:
%define mpfr_version 2.4.2
%define mpc_version0.8.1
%define gmp_version4.3.2
I tried that with gcc 7.1.0 but the build failed complaining mpfr was too old.
I upgraded mpfr and them got a compiler error which appeared to be GMP related
so I bumped GMP. The same error remained:
../../../gcc-7.1.0/mpc/src/acos.c: In function 'mpc_acos':
../../../gcc-7.1.0/mpc/src/acos.c:192:19: error: 'GMP_RNDA' undeclared (first
use in this function)
: rnd_im == GMP_RNDA ? GMP_RNDZ
I bumped MPC to 1.0.3 which worked. Now we are using this in the build recipe.
%define mpfr_version 3.1.5
%define mpc_version1.0.3
%define gmp_version6.1.2
The gcc-7.1.0/INSTALL/prerequisites.html seem to be out of date. I am sure the
minimum is lower than what I ended up using.
What are the correct minimums for gcc 7.1?
Thanks.
-joel
smime.p7s
Description: S/MIME cryptographic signature
Re: Support Library Requirements for GCC 7.1
On Tue, 2017-05-02 at 18:17 -0500, Joel Sherrill wrote: > With gcc 6.3.0, we have this in our build recipe: > > %define mpfr_version 2.4.2 > %define mpc_version 0.8.1 > %define gmp_version 4.3.2 Best thing to do is look at the contrib/download_prerequisites script that comes with the GCC source code. The 7.1 version says: gmp='gmp-6.1.0.tar.bz2' mpfr='mpfr-3.1.4.tar.bz2' mpc='mpc-1.0.3.tar.gz' isl='isl-0.16.1.tar.bz2' In general, it's better to just run that script, if possible.
Re: Support Library Requirements for GCC 7.1
On Tue, May 2, 2017 at 5:02 PM, Paul Smith wrote: > On Tue, 2017-05-02 at 18:17 -0500, Joel Sherrill wrote: >> With gcc 6.3.0, we have this in our build recipe: >> >> %define mpfr_version 2.4.2 >> %define mpc_version0.8.1 >> %define gmp_version4.3.2 > > Best thing to do is look at the contrib/download_prerequisites script > that comes with the GCC source code. > > The 7.1 version says: > > gmp='gmp-6.1.0.tar.bz2' > mpfr='mpfr-3.1.4.tar.bz2' > mpc='mpc-1.0.3.tar.gz' > isl='isl-0.16.1.tar.bz2' > > In general, it's better to just run that script, if possible. "it's better to just run that script" One would think. But 7.1 is outdated. latest gmp is 6.1.2 latest mpfr os 3.1.5 latest isl is 0.18
Re: Support Library Requirements for GCC 7.1
On Tue, 2 May 2017, Joel Sherrill wrote: I am trying to update the gcc version for rtems to 7.1 and running into trouble finding the correct versions of mpc, mpfr, and gmp. We build those as part of building gcc so we have configuration control over the set. With gcc 6.3.0, we have this in our build recipe: %define mpfr_version 2.4.2 %define mpc_version0.8.1 %define gmp_version4.3.2 I tried that with gcc 7.1.0 but the build failed complaining mpfr was too old. Could you be more precise about how the build failed? AFAIK mpfr-2.4.2 is still supposed to work. -- Marc Glisse
