Re: Test with an lto-build of libgfortran.
Hi all, the following works for me. I have only tried a normal build (where it does silence the same warning) and not an LTO build and I just believed the comment - see attached patch. Comments? On 28.09.23 08:25, Richard Biener via Fortran wrote: This particular place in libgfortran has /* write_z, which calls xtoa_big, is called from transfer.c, formatted_transfer_scalar_write. There it is passed the kind as argument, which means a maximum of 16. The buffer is large enough, but the compiler does not know that, so shut up the warning here. */ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wstringop-overflow" *q = '\0'; #pragma GCC diagnostic pop so obviously the #pragma doesn't survive through LTO. Somehow I think this is a known bug, but maybe I misremember (I think we are not streaming any of the ad-hoc location parts). I have replaced it now by the assert that "len <= 16", i.e. + if (len > 16) +__builtin_unreachable (); Build + tested on x86-64-gnu-linux Comment? OK for mainline? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 libgfortran: Use __builtin_unreachable() not -Wno-stringop-overflow to silence warning libgfortran/ * io/write.c (xtoa_big): Change a 'GCC diagnostic ignored "-Wstringop-overflow"' to an assumption (via __builtin_unreachable). libgfortran/io/write.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c index 5d47a6d25f7..00c8fd2e288 100644 --- a/libgfortran/io/write.c +++ b/libgfortran/io/write.c @@ -1179,6 +1179,15 @@ xtoa_big (const char *s, char *buffer, int len, GFC_UINTEGER_LARGEST *n) uint8_t h, l; int i; + /* write_z, which calls xtoa_big, is called from transfer.c, + formatted_transfer_scalar_write. There it is passed the kind as + 'len' argument, which means a maximum of 16. The buffer is large + enough, but the compiler does not know that, so shut up the + warning here. */ + + if (len > 16) +__builtin_unreachable (); + q = buffer; if (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) @@ -1212,15 +1221,7 @@ xtoa_big (const char *s, char *buffer, int len, GFC_UINTEGER_LARGEST *n) } } - /* write_z, which calls xtoa_big, is called from transfer.c, - formatted_transfer_scalar_write. There it is passed the kind as - argument, which means a maximum of 16. The buffer is large - enough, but the compiler does not know that, so shut up the - warning here. */ -#pragma GCC diagnostic push -#pragma GCC diagnostic ignored "-Wstringop-overflow" *q = '\0'; -#pragma GCC diagnostic pop if (*n == 0) return "0";
Re: Test with an lto-build of libgfortran.
On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote: > the following works for me. I have only tried a normal build (where it > does silence the same warning) and not an LTO build and I just believed > the comment - see attached patch. Comments? > > On 28.09.23 08:25, Richard Biener via Fortran wrote: > > > This particular place in libgfortran has > > > >/* write_z, which calls xtoa_big, is called from transfer.c, > > formatted_transfer_scalar_write. There it is passed the kind as > > argument, which means a maximum of 16. The buffer is large > > enough, but the compiler does not know that, so shut up the > > warning here. */ > > #pragma GCC diagnostic push > > #pragma GCC diagnostic ignored "-Wstringop-overflow" > >*q = '\0'; > > #pragma GCC diagnostic pop > > > > so obviously the #pragma doesn't survive through LTO. Somehow I think > > this is a known bug, but maybe I misremember (I think we are not streaming > > any of the ad-hoc location parts). > > I have replaced it now by the assert that "len <= 16", i.e. > > + if (len > 16) > +__builtin_unreachable (); > > Build + tested on x86-64-gnu-linux > Comment? OK for mainline? Is it just that in correct programs len can't be > 16, or that it is really impossible for it being > 16? I mean, we have that artificial kind 17 for powerpc which better should be turned into length of 16, but isn't e.g. _gfortran_transfer_integer etc. just called with a kind argument? Does anything error earlier if it is larger? I mean, say user calling _gfortan_transfer_integer by hand with kind 1024? Sure, we could still say it is UB to do that kind of thing and __builtin_unreachable () would be a way to turn that UB into manifestly reproducable UB. Jakub
MIPS Built-ins
Hello!
You may call me Ilvir. I got an issue while building U-Boot for MIPS
platform, because of __builtin_mips_cache needs optimization flags (like
-O2) while non-literal int passed in it ("int op" at example below).
Example code:
static inline void mips_cache(int op, const volatile void *addr) {
#if __GCC_HAVE_BUILTIN_MIPS_CACHE
__builtin_mips_cache(op, addr);
#endif
}
void f() {
const void *addr = (const void*)0xB800200;
mips_cache(op, addr);
}
Running compilation without optimization flag:
ilvir:~/test/mips_cache$ mips-linux-gnu-gcc -S -march=mips32r2 mips_cache.c
mips_cache.c: In function ‘mips_cache’:
mips_cache.c:3:9: error: invalid argument to built-in function
3 | __builtin_mips_cache(op, addr);
| ^~
And with:
ilvir:~/test/mips_cache$ mips-linux-gnu-gcc -O2 -S -march=mips32r2
mips_cache.c
compiles well.
Well passed compilation output:
ilvir:~/test/mips_cache$ cat mips_cache.s
.file 1 "mips_cache.c"
.section .mdebug.abi32
.previous
.nan legacy
.module fp=xx
.module nooddspreg
.module arch=mips32r2
.abicalls
.text
.align 2
.globl f
.set nomips16
.set nomicromips
.ent f
.type f, @function
f:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.set noreorder
.set nomacro
li $2,192937984 # 0xb80
jr $31
cache 0x4,512($2)
.set macro
.set reorder
.end f
.size f, .-f
.ident "GCC: (Debian 12.2.0-14) 12.2.0"
.section .note.GNU-stack,"",@progbits
Preprocessor output:
ilvir:~/test/mips_cache$ mips-linux-gnu-gcc -E -march=mips32r2 mips_cache.c
# 0 "mips_cache.c"
# 0 ""
# 0 ""
# 1 "/usr/mips-linux-gnu/include/stdc-predef.h" 1 3
# 0 "" 2
# 1 "mips_cache.c"
static inline void mips_cache(int op, const volatile void *addr) {
__builtin_mips_cache(op, addr);
}
void f() {
unsigned int op = 0x04;
const void *addr = (const void*)0xB800200;
mips_cache(op, addr);
}
Compiler:
ilvir:~/test/mips_cache$ mips-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=mips-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mips-linux-gnu/12/lto-wrapper
Target: mips-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libitm --disable-libsanitizer --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--without-target-system-zlib --enable-multiarch --disable-werror
--enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx
--with-lxc1-sxc1=no --enable-targets=all --with-arch-64=mips64r2
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=mips-linux-gnu --program-prefix=mips-linux-gnu-
--includedir=/usr/mips-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)
It will be very helpful if you tell me the importance of using optimization
flags when compiling the built-in given above. Is it really necessary to
use optimization flags there? Does the compiler operate right?
Thank you!
Re: Test with an lto-build of libgfortran.
On 9/28/23 07:33, Thomas Koenig wrote: Hi Toon, [ I wrote: ] The full question of "lto-ing" run time libraries is more complicated than just "whether it works" as those who attended the BoF will recall. I didn't attend the Cauldron (but that discussion would have been very interesting). I think for libgfortran, a first step would be additional work to get declarations on both sides to agree (which is worth doing anyway). Best regards Thomas The big problem in *distributing* GCC (i.e., the collection) with lto'd run-time libraries is that the format of the lto structure changes with releases. If a compiler (by accident) picks up a run time library with non-matching lto objects, it might crash (or "introduce subtle errors in a once working program"). I.e., like the problem the gfortran community had with the changing format of our .mod files. But it would be a big win for Fortran ... Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: GCC workshop at university
On Wed, 2023-09-27 at 22:20 +0200, Benjamin Priour wrote: > Hi everyone, > > I'm in my final MSc year and figured after this weekend's Q&A > that I could replicate David's workshop on a smaller scale within my > university. > > Would that be doable/acceptable ? That sounds like a great idea. > Is there any need for special licensing ? Feel free to use the materials from my workshop. > What about uploading the > session's recording afterwards ? That would be good, but you should seek the permission of the participants if they're going to be in the recording. > > To Dave: > If the above is alright could I reuse some of your slides ? Yes, though the slides (as such) were Red Hat-branded, so please change that if you reuse them. I've uploaded the slides to the wiki. > I won't necessarily follow what you did, but some of them would be > useful. > > Cheers to you all, > Benjamin. Thanks Dave
Re: Test with an lto-build of libgfortran.
On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote:
> > > The full question of "lto-ing" run time libraries is more
> > > complicated than just "whether it works" as those who attended the
> > > BoF will recall.
> >
> > I didn't attend the Cauldron (but that discussion would have been
> > very interesting). I think for libgfortran, a first step would be
> > additional work to get declarations on both sides to agree (which is
> > worth doing anyway).
> >
> > Best regards
> >
> > Thomas
>
> The big problem in *distributing* GCC (i.e., the collection) with lto'd
> run-time libraries is that the format of the lto structure changes with
> releases. If a compiler (by accident) picks up a run time library with
> non-matching lto objects, it might crash (or "introduce subtle errors in a
> once working program").
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO in lib*.a libraries, at least in some packagings (if the static
libraries are in gcc specific subdirectories rather than say /usr/lib{,64}
or similar and if the packaging of gcc updates both the compiler and
corresponding static libraries in a lock-step. Because in that case LTO
in there will be always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.
Jakub
Re: Test with an lto-build of libgfortran.
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO in lib*.a libraries, at least in some packagings (if the static
libraries are in gcc specific subdirectories rather than say /usr/lib{,64}
or similar and if the packaging of gcc updates both the compiler and
corresponding static libraries in a lock-step. Because in that case LTO
in there will be always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.
This might be an argument to make it a configure option, e.g.
--enable-lto-runtime.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Test with an lto-build of libgfortran.
On Thu, Sep 28, 2023 at 4:00 PM Toon Moene wrote:
> On 9/28/23 21:26, Jakub Jelinek wrote:
>
> > It is worse than that, usually the LTO format changes e.g. any time any
> > option or parameter is added on a release branch (several times a year)
> and
> > at other times as well.
> > Though, admittedly GCC is the single package that actually could get away
> > with LTO in lib*.a libraries, at least in some packagings (if the static
> > libraries are in gcc specific subdirectories rather than say
> /usr/lib{,64}
> > or similar and if the packaging of gcc updates both the compiler and
> > corresponding static libraries in a lock-step. Because in that case LTO
> > in there will be always used only by the same snapshot from the release
> > branch and so should be compatible with the LTO in it.
> This might be an argument to make it a configure option, e.g.
> --enable-lto-runtime.
>
> Note that not all targets support LTO, so the option cannot be added
unilaterally.
David
gcc-11-20230928 is now available
Snapshot gcc-11-20230928 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230928/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision ca30697fb6000ea98ad18e01155d0ccfc6f1a5e7 You'll find: gcc-11-20230928.tar.xz Complete GCC SHA256=9d63a2be19d6c02a00ede3639dfcf974b6474724b9e39ad4357c571d4c620f7d SHA1=cbcd6ee1c3d83204de6b754fe7cc9e3f2113 Diffs from 11-20230921 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
Re: Test with an lto-build of libgfortran.
Hi Jakub,
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Hm, that makes LTO not very well suited for libraries...
Though, admittedly GCC is the single package that actually could get away
with LTO in lib*.a libraries, at least in some packagings (if the static
libraries are in gcc specific subdirectories rather than say /usr/lib{,64}
or similar and if the packaging of gcc updates both the compiler and
corresponding static libraries in a lock-step. Because in that case LTO
in there will be always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.
Maybe another approach: Instead of storing version-dependent LTO code in
the *.a files, we could just store preprocessed C code there, somewhat
shortened by removing whitespace, comments and unused declarations
(and/or store them in compressed format).
This would also allow the something like sanitizers to look into the
runtime libraries, and other instrumentation.
It would also be a much more extensive project, also involving
modifications to the linker. Not sure how realistic that would be.
Best regards
Thomas
