Re: Name of libgcc.so.1 with suffix?
On Wed, Aug 17, 2016 at 11:10 PM, Steve Kargl wrote: > Hi, > > If I run configure with "--program-suffix=6", I get gcc6, gfortran6, etc. > When ldd looks for libgcc.so.1 on FreeBSD, she finds the wrong one. > > % cat foo.f90 > program foo >print *, 'Hello' > end program > % gfortran6 -o z foo.f90 && ./z > /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ > /usr/local/lib/gcc6/libgfortran.so.3 not found > > % ldconfig -r | grep libgcc > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > > Is it possible to add a suffix to libgcc.so, e.g., libgcc6.so.1? No, but you can try --enable-version-specific-runtime-libs Richard. > -- > Steve
Re: Name of libgcc.so.1 with suffix?
On 18 August 2016 at 08:59, Richard Biener wrote: > No, but you can try --enable-version-specific-runtime-libs But be aware that for multilib targets that's been broken for years, PR32415
Re: Possible missed optimization opportunity with const?
On 18/08/16 00:44, Toshi Morita wrote: > David Brown wrote: > >> No, it would not be valid. Declaring pfoo as a "const int*" tells the >> compiler "I will not change anything via this pointer - and you can >> optimise based on that promise". It does /not/ tell the compiler "the >> thing that this points to will not change". >> >> So the compiler is correct in reading *pfoo twice. > > The revised example posted by Kei uses "const int const *pfoo" and GCC > is able to remove the second read, so this interpretation of const seems > incorrect? > > Toshi > I didn't see the post you are referring to - was it sent to the mailing list, or only your email address? But if I can make a guess here, the difference here is that now the pointer object "pfoo" itself is const, and therefore cannot be modified (without causing undefined behaviour). So the compiler knows that it will definitely point to "foo", and can use that information to optimise better. When "pfoo" was not "const", the compiler does not know that pfoo points to foo in main - it could point somewhere else. (In particular, a file-scope constructor in another module might change it, since pfoo has external linkage.) Thus it does not know if bar() changes *pfoo, and it has to read *pfoo twice. You would get the same effect by making pfoo "static", since the compiler then knows that it's value is &foo at the start of main().
Re: Name of libgcc.so.1 with suffix?
On Thu, Aug 18, 2016 at 09:25:41AM +0100, Jonathan Wakely wrote: > On 18 August 2016 at 08:59, Richard Biener wrote: > > No, but you can try --enable-version-specific-runtime-libs > > But be aware that for multilib targets that's been broken for years, PR32415 Richi, Thanks for the pointer to the --enable-*. Jonathan, Thanks for the heads-up. It seems the FreeBSD ports developer will need to ensure that -Wl,-rpath appears in the command line to find the right library. -- Steve http://troutmask.apl.washington.edu/~kargl/
gcc-6-20160818 is now available
Snapshot gcc-6-20160818 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160818/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 239599 You'll find: gcc-6-20160818.tar.bz2 Complete GCC MD5=bceec7af95048b70669dd24f9d98993c SHA1=fb7e4ce360a028a7f83b9c1fa5ddd48043c361a4 Diffs from 6-20160811 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 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.
fxsrintrin.h
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.' Given that, does this
code (from gcc/config/i386/fxsrintrin.h) make sense?
_fxsave (void *__P)
{
return __builtin_ia32_fxsave (__P);
}
Returning a void? Is that a thing? Similar question for _fxrstor,
_fxsave64, and _fxrstor64.
And again in xsaveintrin.h for _xsave, _xrstor, _xsave64 and _xrstor64?
dw
Re: fxsrintrin.h
Given the `_fxsave()` function returning `void`, it is invalid C but valid C++:
# WG14 N1256 (C99) / N1570 (C11)
6.8.6.4 The return statement
Constraints
1 A return statement with an expression shall not appear in a function
whose return type is void. ...
# WG21 N1804 (C++03)
6.6.3 The return statement [stmt.return]
3 A return statement with an expression of type “cv void” can be used
only in functions with a return type of cv void; the expression
is evaluated just before the function returns to its caller.
# WG21 N4582 (C++1z)
6.6.3 The return statement [stmt.return]
2 ... A return statement with an operand of type void shall be used
only in a function whose return type is cv void. ...
--
Best regards,
lh_mouse
2016-08-19
-
发件人：David Wohlferd
发送日期：2016-08-19 11:51
收件人：gcc@gcc.gnu.org
抄送：
主题：fxsrintrin.h
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.' Given that, does this
code (from gcc/config/i386/fxsrintrin.h) make sense?
_fxsave (void *__P)
{
return __builtin_ia32_fxsave (__P);
}
Returning a void? Is that a thing? Similar question for _fxrstor,
_fxsave64, and _fxrstor64.
And again in xsaveintrin.h for _xsave, _xrstor, _xsave64 and _xrstor64?
dw
Re: fxsrintrin.h
Interesting. Seems slightly strange, but I've seen stranger. I guess
it's seen as "cleaner" than forcing this into 2 statements.
IAC, it seems wrong for headers, since they can be used from either C or
C++. Also, seems unnecessary here, since 'return' is implied by the
fact that the 'next' statement is the end of the routine.
dw
On 8/18/2016 10:50 PM, lhmouse wrote:
Given the `_fxsave()` function returning `void`, it is invalid C but valid C++:
# WG14 N1256 (C99) / N1570 (C11)
6.8.6.4 The return statement
Constraints
1 A return statement with an expression shall not appear in a function
whose return type is void. ...
# WG21 N1804 (C++03)
6.6.3 The return statement [stmt.return]
3 A return statement with an expression of type “cv void” can be used
only in functions with a return type of cv void; the expression
is evaluated just before the function returns to its caller.
# WG21 N4582 (C++1z)
6.6.3 The return statement [stmt.return]
2 ... A return statement with an operand of type void shall be used
only in a function whose return type is cv void. ...
--
Best regards,
lh_mouse
2016-08-19
-
发件人：David Wohlferd
发送日期：2016-08-19 11:51
收件人：gcc@gcc.gnu.org
抄送：
主题：fxsrintrin.h
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.' Given that, does this
code (from gcc/config/i386/fxsrintrin.h) make sense?
_fxsave (void *__P)
{
return __builtin_ia32_fxsave (__P);
}
Returning a void? Is that a thing? Similar question for _fxrstor,
_fxsave64, and _fxrstor64.
And again in xsaveintrin.h for _xsave, _xrstor, _xsave64 and _xrstor64?
dw
Re: fxsrintrin.h
On Fri, Aug 19, 2016 at 01:50:52PM +0800, lhmouse wrote: > Given the `_fxsave()` function returning `void`, it is invalid C but valid > C++: It is also a GNU C extension. Jakub
