C provenance semantics proposal
Dear all, continuing the discussion from the 2018 GNU Tools Cauldron, we (the WG14 C memory object model study group) now have a detailed proposal for pointer provenance semantics, refining the "provenance not via integers (PNVI)" model presented there. This will be discussed at the ISO WG14 C standards committee at the end of April, and comments from the GCC community before then would be very welcome. The proposal reconciles the needs of existing code and the behaviour of existing compilers as well as we can, but it doesn't exactly match any of the latter, so we'd especially like to know whether it would be feasible to implement - our hope is that it would only require minor changes. It's presented in three documents: N2362 Moving to a provenance-aware memory model for C: proposal for C2x by the memory object model study group. Jens Gustedt, Peter Sewell, Kayvan Memarian, Victor B. F. Gomes, Martin Uecker. This introduces the proposal and gives the proposed change to the standard text, presented as change-highlighted pages of the standard (though one might want to read the N2363 examples before going into that). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2362.pdf N2363 C provenance semantics: examples. Peter Sewell, Kayvan Memarian, Victor B. F. Gomes, Jens Gustedt, Martin Uecker. This explains the proposal and its design choices with discussion of a series of examples. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2363.pdf N2364 C provenance semantics: detailed semantics. Peter Sewell, Kayvan Memarian, Victor B. F. Gomes. This gives a detailed mathematical semantics for the proposal http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2364.pdf In addition, at http://cerberus.cl.cam.ac.uk/cerberus we provide an executable version of the semantics, with a web interface that allows one to explore and visualise the behaviour of small test programs, stepping through and seeing the abstract-machine memory state including provenance information. N2363 compares the results of this for the example programs with gcc, clang, and icc results, though the tests are really intended as tests of the semantics rather than compiler tests, so one has to interpret this with care. best, Peter (for the study group)
[RFC/RFA] Obsolete Cell Broadband Engine SPU targets
Hello,
the spu-elf target in GCC supports generating code for the SPU processors
of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
However, at this point I believe this target is no longer in use:
- There is no supported Cell/B.E. hardware any more.
- There is no supported operating system supporting Cell/B.E. any more.
I've still been running daily regression tests until now, but I'll be
unable to continue to do so much longer since the systems I've been
using for this will go away.
Rather than leave SPU support untested/maintained, I'd therefore
propose to declare all SPU targets obsolete in GCC 9 and remove
the code with GCC 10.
Any objections to this approach?
Bye,
Ulrich
gcc/ChangeLog:
* config.gcc: Mark spu* targets as deprecated/obsolete.
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 270076)
+++ gcc/config.gcc (working copy)
@@ -248,6 +248,7 @@ md_file=
# Obsolete configurations.
case ${target} in
*-*-solaris2.10* \
+ | spu*-*-* \
| tile*-*-* \
)
if test "x$enable_obsolete" != xyes; then
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
On April 2, 2019 11:46:14 AM GMT+02:00, Ulrich Weigand
wrote:
>Hello,
>
>the spu-elf target in GCC supports generating code for the SPU
>processors
>of the Cell Broadband Engine; it has been part of upstream GCC since
>2008.
>
>However, at this point I believe this target is no longer in use:
>- There is no supported Cell/B.E. hardware any more.
>- There is no supported operating system supporting Cell/B.E. any more.
>
>I've still been running daily regression tests until now, but I'll be
>unable to continue to do so much longer since the systems I've been
>using for this will go away.
>
>Rather than leave SPU support untested/maintained, I'd therefore
>propose to declare all SPU targets obsolete in GCC 9 and remove
>the code with GCC 10.
>
>Any objections to this approach?
Works for me.
Richard.
>Bye,
>Ulrich
>
>
>gcc/ChangeLog:
>
> * config.gcc: Mark spu* targets as deprecated/obsolete.
>
>Index: gcc/config.gcc
>===
>--- gcc/config.gcc (revision 270076)
>+++ gcc/config.gcc (working copy)
>@@ -248,6 +248,7 @@ md_file=
> # Obsolete configurations.
> case ${target} in
> *-*-solaris2.10*\
>+ | spu*-*-* \
> | tile*-*-* \
> )
> if test "x$enable_obsolete" != xyes; then
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
On 4/2/19 3:46 AM, Ulrich Weigand wrote: > Hello, > > the spu-elf target in GCC supports generating code for the SPU processors > of the Cell Broadband Engine; it has been part of upstream GCC since 2008. > > However, at this point I believe this target is no longer in use: > - There is no supported Cell/B.E. hardware any more. > - There is no supported operating system supporting Cell/B.E. any more. > > I've still been running daily regression tests until now, but I'll be > unable to continue to do so much longer since the systems I've been > using for this will go away. > > Rather than leave SPU support untested/maintained, I'd therefore > propose to declare all SPU targets obsolete in GCC 9 and remove > the code with GCC 10. > > Any objections to this approach? > > Bye, > Ulrich > > > gcc/ChangeLog: > > * config.gcc: Mark spu* targets as deprecated/obsolete. WOrks for me as well. jeff
Re: FIXME in gcc/gimplify.c
On 4/1/19 5:17 PM, nick wrote: On 2019-04-01 1:54 p.m., Andrew MacLeod wrote: #include "tree-flow.h" #include "cgraph.h" #include "timevar.h" #include "hashtab.h" #include "flags.h" #include "function.h" #include "ggc.h" #include "diagnostic-core.h" #include "target.h" #include "pointer-set.h" #include "splay-tree.h" #include "vec.h" #include "gimple.h" #include "langhooks-def.h" /* FIXME: for lhd_set_decl_assembler_name */ #include "tree-pass.h" /* FIXME: only for PROP_gimple_any */ so that comment predates anything I did to it. I specifically left any comments that existed as I refactored the core bits. Andrew Andrew, I assumed so but it was the last commit and have your names. I will leave this thread open for discussion if anyone knows what the outstanding issues with header refactoring as required for fixing those comments. If someone comments and is able to give me a heads up about what needs refactoring I will be glad to do it in a patch or probably patch series. Nick Once upon a time someone went thru the compiler and added comments to a few of thesecomments to #include's when there were only one or two dependencies. I'm not sure what the original intention was, or why it was tagged as "FIXME". The problem with this approach is it can rapidly get out of date.. as can be seen by the other undefined messages that caused the compilation issue when the #Include is removed. There is actually half a dozen things required from this include file. We almost removed all those comments when the re-factoring was being performed, but it was automated and there were other comments that were relevant, so we elected to just preserve all comments. I don't see any particular reason or need to fix these includes. I think the comments are out of date and unnecessary, but won't lose any sleep over them. tree-pass.h is required to compile this file. It is not included by any other include file, so there is no ordering issue I can see, nor any need to remove the #include. Andrew
Re: Applying patch to longlong.h
Thanks! Claudiu On Mon, Apr 1, 2019 at 6:40 PM Jeff Law wrote: > > On 4/1/19 12:57 AM, claz...@gmail.com wrote: > > Hi, > > > > I would like to apply the ARC specific fix for bugzilla 89877 to > > include/longlong.h file, but I don't know for sure if I am allowed or > > not. I mention that I am the ARC reviewer. > If it's in ARC specific bits within longlong.h, then yes, you can just > go ahead and apply your fix. > > Jeff
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
Thanks, Richi and Jeff! > * config.gcc: Mark spu* targets as deprecated/obsolete. I've now checked this in. I've also checked in the following patch to announce the change in htdocs. Bye, Ulrich Index: htdocs/gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.56 diff -u -r1.56 changes.html --- htdocs/gcc-9/changes.html 1 Apr 2019 14:55:53 - 1.56 +++ htdocs/gcc-9/changes.html 2 Apr 2019 13:45:27 - @@ -54,6 +54,11 @@ in the https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html";> announcement. + + Cell Broadband Engine SPU (spu*-*-*). Details can be found + in the https://gcc.gnu.org/ml/gcc/2019-04/msg00023.html";> + announcement. + -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
On Tue, Apr 2, 2019 at 2:46 AM Ulrich Weigand wrote:
>
> Hello,
>
> the spu-elf target in GCC supports generating code for the SPU processors
> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
>
> However, at this point I believe this target is no longer in use:
> - There is no supported Cell/B.E. hardware any more.
> - There is no supported operating system supporting Cell/B.E. any more.
>
> I've still been running daily regression tests until now, but I'll be
> unable to continue to do so much longer since the systems I've been
> using for this will go away.
>
> Rather than leave SPU support untested/maintained, I'd therefore
> propose to declare all SPU targets obsolete in GCC 9 and remove
> the code with GCC 10.
>
> Any objections to this approach?
This is ok with me too. Though I have been out of Cell development
for a while now.
Thanks,
Andrew
>
> Bye,
> Ulrich
>
>
> gcc/ChangeLog:
>
> * config.gcc: Mark spu* targets as deprecated/obsolete.
>
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc (revision 270076)
> +++ gcc/config.gcc (working copy)
> @@ -248,6 +248,7 @@ md_file=
> # Obsolete configurations.
> case ${target} in
>*-*-solaris2.10* \
> + | spu*-*-* \
>| tile*-*-* \
> )
> if test "x$enable_obsolete" != xyes; then
> --
> Dr. Ulrich Weigand
> GNU/Linux compilers and toolchain
> ulrich.weig...@de.ibm.com
>
vector alignment
GCC tries to align a vector on its natural boundary, i.e., that given by its size, up to MAX_OBJECT_ALIGNMENT. Vectors that are bigger than that are either silently [mis]aligned on that same maximum boundary (PR 89798), silently truncated (and misaligned), or cause an ICE (PR 89797). Compiling the following: __attribute__ ((vector_size (N))) char v; _Static_assert (sizeof (v) == N, "size"); _Static_assert (__alignof__ (v) == N, "alignment"); with N set to 1LLU << I shows these failures: I < 29 succeeds I < 31 fails alignment I < 32 ICE I >= 32 fails alignment and size Attribute aligned doesn't seem to have any effect on types or variables declared with attribute vector_size. The alignment set by the latter prevails. This happens no matter what scope the vector is defined in (i.e., file or local). I have some questions: 1) Is there some reason to align vectors on the same boundary as their size no matter how big it is? I can't find such a requirement in the ABIs I looked at. Or would it be more appropriate to align the big ones on the preferred boundary for the target? For instance, does it make more sense to align a 64KB vector on a 64KB boundary than on, say, a 64-byte boundary (or some other boundary less than 64K?) 2) If not, is it then appropriate to underalign very large vectors on a boundary less than their size? 3) Should the aligned attribute not override the default vector alignment? I would like to think the answer to (1) is that vectors should be aligned on the preferred boundary for the target/ABI. If that's feasible, it should also obviate question (2). I believe the answer to (3) is yes. If not, GCC should issue a warning that it doesn't honor the aligned attribute. Thanks Martin
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
On 4/2/19, Ulrich Weigand wrote:
> Hello,
>
> the spu-elf target in GCC supports generating code for the SPU processors
> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
>
> However, at this point I believe this target is no longer in use:
> - There is no supported Cell/B.E. hardware any more.
Wait, SPU includes the Playstation 3, right? I'm pretty sure there are
still plenty of PS3s in use out there... AFAIK my university (GWU) is
still running its PS3 supercomputer cluster... (I'd have to check to
make sure...)
> - There is no supported operating system supporting Cell/B.E. any more.
>
> I've still been running daily regression tests until now, but I'll be
> unable to continue to do so much longer since the systems I've been
> using for this will go away.
>
> Rather than leave SPU support untested/maintained, I'd therefore
> propose to declare all SPU targets obsolete in GCC 9 and remove
> the code with GCC 10.
>
> Any objections to this approach?
>
> Bye,
> Ulrich
>
>
> gcc/ChangeLog:
>
> * config.gcc: Mark spu* targets as deprecated/obsolete.
>
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc(revision 270076)
> +++ gcc/config.gcc(working copy)
> @@ -248,6 +248,7 @@ md_file=
> # Obsolete configurations.
> case ${target} in
>*-*-solaris2.10* \
> + | spu*-*-* \
>| tile*-*-*\
> )
> if test "x$enable_obsolete" != xyes; then
> --
> Dr. Ulrich Weigand
> GNU/Linux compilers and toolchain
> ulrich.weig...@de.ibm.com
>
>
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
Eric Gallagher wrote: > On 4/2/19, Ulrich Weigand wrote: > > Hello, > > > > the spu-elf target in GCC supports generating code for the SPU processors > > of the Cell Broadband Engine; it has been part of upstream GCC since 2008. > > > > However, at this point I believe this target is no longer in use: > > - There is no supported Cell/B.E. hardware any more. > > Wait, SPU includes the Playstation 3, right? I'm pretty sure there are > still plenty of PS3s in use out there... AFAIK my university (GWU) is > still running its PS3 supercomputer cluster... (I'd have to check to > make sure...) GCC has only ever supported Linux targets on Cell/B.E. I understand Sony has removed Linux support for PS3 a long time ago. (And in fact, I believe support for PS3 in general has run out this year.) Of course, there may be some people out there still running PS3 with old firmware that runs Linux. But they will then have to also use older GCC versions, sorry. (Unless, of course, somebody steps up and volunteers to take over the maintainance of the target.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
On 4/2/19 10:49 AM, Eric Gallager wrote: > On 4/2/19, Ulrich Weigand wrote: >> Hello, >> >> the spu-elf target in GCC supports generating code for the SPU processors >> of the Cell Broadband Engine; it has been part of upstream GCC since 2008. >> >> However, at this point I believe this target is no longer in use: >> - There is no supported Cell/B.E. hardware any more. > > Wait, SPU includes the Playstation 3, right? I'm pretty sure there are > still plenty of PS3s in use out there... AFAIK my university (GWU) is > still running its PS3 supercomputer cluster... (I'd have to check to > make sure...) Even if there's potentially still users out there, if there's no maintainer to support the target, then it should be deprecated. Of course, you could always step into that role. I'm sure Ulrich could fill you in on the responsibilities. jeff
Putting an all-zero variable into BSS
Hi, There is a large increase in rodata size for derived types in gfortran starting with gcc 8 due to the presence of large initializers for derived types. Among other things, this affects SPEC tonto (PR 84487), but there are also other bug reports which mention this behavior. The large default initializers are all filled with zeros which end up in the rodata section, like this: .text .globl __types_module_MOD___def_init_types_module_Archive_type .section.rodata .align 32 .type __types_module_MOD___def_init_types_module_Archive_type, @object .size __types_module_MOD___def_init_types_module_Archive_type, 262144 __types_module_MOD___def_init_types_module_Archive_type: .zero 262144 ... and so on. To reduce the size of the executable, it would make more sense to put this into the BSS section. Question: How? It would be possible to determine from the Fortran front end which variables would end up all zeros, and mark them in some way. Alternatively, the middle or back end could do this, maybe unter the control of a specal option we can then set from gfortran (-fzero-initialized-in-bss does not do the trick). What could be the best path forward? Regards Thomas
Re: Putting an all-zero variable into BSS
On Apr 03 2019, Thomas Koenig wrote: > The large default initializers are all filled with zeros which end up in > the rodata section, like this: > > .text > .globl __types_module_MOD___def_init_types_module_Archive_type > .section.rodata > .align 32 > .type __types_module_MOD___def_init_types_module_Archive_type, > @object > .size __types_module_MOD___def_init_types_module_Archive_type, > 262144 > __types_module_MOD___def_init_types_module_Archive_type: > .zero 262144 > > ... and so on. To reduce the size of the executable, it would make more > sense to put this into the BSS section. Note that .bss is writable. There is no read-only bss section. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
