Getting Wales Moving 2019
GETTING WALES MOVING DELIVERING ON THE WELL-BEING OF WALES 27TH JUNE 2019 RADISSON BLU HOTEL - CARDIFF Following on from the hugely successful Getting Wales Moving 2018 Conference, we are delighted to announce that we will deliver the second conference in this series on the 27th of June 2019 at the Radisson Blu Hotel, Cardiff. Once again, we have set the bar high, both in terms of quality and expectation of stimulating real change. The 2019 conference will feature influential and well-respected speakers with detailed insight from the Welsh Government, Sport Wales, The Welsh Rugby Union and leading figures involved in improving population health and tackling inactivity and skills shortages across Welsh communities. [1]CLICK FOR CONFERENCE WEBSITE Ken Skates Cabinet Secretary for Economy and Infrastructure Welsh Government Gareth Davies Chairman Welsh Rugby Union Geoff Thompson Executive Chair, MBE, FRSA, FL The Youth Charter Kate Evans Head of Communication and Policy Welsh Sports Association The ambition for this series of "Getting Wales Moving" conferences is to create a long term framework of communication and knowledge transfer to ensure all available measures are being taken to deliver on the the Well - Being of Future Generations Act. To register for the conference, simply click the button below. [2]REGISTER NOW The Why Sports Getting Wales Moving conference - "Delivering on the Well - being of Wales" will be open to professionals, decision makers and influencers from across the sector whom are responsible and accountable for delivering strong outcomes and increasing physical activity across the country. The conference will cover the following topics: * Update on The Wellbeing of Future Generations Act * What needs to change from both a policy and organisational perspective to make the act a success. * Developing a 6-36 month approach to delivery * How do we drive improvements in our communities to deliver on the act * What skills do we need that are not currently in place to ensure the act is a success * How can we work collaboratively? A unified approach to delivering the act DELEGATE TICKET PRICING PUBLIC & 3RD SECTOR TICKETS £175 PRIVATE SECTOR £295 Register online or call our conference team for more information on - +44 (0)161 246 6265 [3]CASE STUDY PRESENTATIONS [4] We are a social research and technology company helping organisations that do good, think smarter. Using both research and technology, we are able to give organisations the knowledge and insight that then need to do what they do, better. We work alongside individuals, organisations and police makers alike to embed key research findings into future practice and strategic development and use a range of technologies to ensure our projects are relevant, scalable and sustainable. Our own Views project management and evaluation programme was designed to help organisations improve and demonstrate their impact and value. Now incorporated into over 600 organisation's day to day activities, we know Views delivers the ideal means to record and monitor the inspirational work of organisations across the world. [5] 4global is an international sports consultancy and sport intelligence agency, which provides a range of services to government, local authorities, organising committees and sports governing bodies. Established in 2002, 4global Consultancy is involved in events, planning and strategic services, while the intelligence arm of the business offers unparalleled data services to clients. 4global provides its clients with accurate and actionable insight and information management solutions across two sector-leading platforms: DataHub and SportsHub. 4global helps its clients get more people active and shape the future of sport. We use our experience, evidence-based advice, new technologies and insight to empower our clients. [6] Management consultants specialising in Sport, Leisure and Physical Activity Strategic Leisure is one of the most established and successful specialist sport, physical activity and leisure consultancy practices in the UK specialising in the planning, development, management and evaluation of sport, leisure and physical activity facilities, services and events. Our experience spans well over 30 years' of working in the UK leisure industry in the voluntary, public and commercial sectors, and internationally, across a significant range of projects. Strategic Leisure's consultant team is known for providing innovative solutions and excellent standards of service. Our reputation is founded on our people focus – our clients and our team. [7]TAKE ME TO THE WEBSITE Follow us on social media for more info & updates [8]Twitter [9]LinkedIn [10]YouTube References 1. http://wales2019.whysports.co.uk/index.php?alias=creating-active-communities-2018-conference-2&option=com_content&view=article&id=57&Itemid=134 2. http://wales2019.whysports.co.uk/index.php?option=com_reg&refcode=NOV2018 3. h
"const"-related gcc warnings with pointers around, annoying
"foo" is a type that is a struct containing a uint64_t field x[4]
(among other things).
bool Proc( const foo *dog ){
uint64_t *a, *b;
a = dog->x; // pointer a now points to dog->x[0]
b = something else;
if( *a == *b ) return(TRUE);
return(FALSE);
}
Now gcc complains
warning: assigning to 'uint64_t *' (aka 'unsigned long long *') from
'uint64_t const[4]' discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
but the thing is, those pointers a and b, never got used to alter
anything. They merely
were used to read harmlessly from memory. So dog still clearly was never
altered, and hence genuinely was const.
The problem here seems to me to be a lack of intelligence inside gcc's
thinking on the subject of "const"s.Sure assigning to a pointer
could be harmful to const-hood because
that pointer could get used someplace else to write to the "const" part of
memory. BUT, if we know that pointer never can be used to write
to memory anywhere, because it lives only inside the restricted scope of
Proc(){}, and never is used to write to memory anywhere, and never is
copied to any
other variable (because we examine the code inside Proc to verify
this), then it was
ok and gcc should not warn.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
Re: "const"-related gcc warnings with pointers around, annoying
On Fri, 25 Jan 2019 at 13:48, Warren D Smith wrote:
>
> "foo" is a type that is a struct containing a uint64_t field x[4]
> (among other things).
>
> bool Proc( const foo *dog ){
>uint64_t *a, *b;
>a = dog->x; // pointer a now points to dog->x[0]
>b = something else;
>if( *a == *b ) return(TRUE);
>return(FALSE);
> }
>
> Now gcc complains
> warning: assigning to 'uint64_t *' (aka 'unsigned long long *') from
> 'uint64_t const[4]' discards qualifiers
> [-Wincompatible-pointer-types-discards-qualifiers]
>
> but the thing is, those pointers a and b, never got used to alter
> anything. They merely
> were used to read harmlessly from memory. So dog still clearly was never
> altered, and hence genuinely was const.
>
> The problem here seems to me to be a lack of intelligence inside gcc's
> thinking on the subject of "const"s.Sure assigning to a pointer
> could be harmful to const-hood because
> that pointer could get used someplace else to write to the "const" part of
> memory. BUT, if we know that pointer never can be used to write
> to memory anywhere, because it lives only inside the restricted scope of
> Proc(){}, and never is used to write to memory anywhere, and never is
> copied to any
> other variable (because we examine the code inside Proc to verify
> this), then it was
> ok and gcc should not warn.
This belongs on the gcc-help list, not here. If you want changes to
GCC's diagnostics please file a bug report in Bugzilla.
Basically you're asking for GCC to do escape analysis on the converted
pointer, and suppress the warnings if it doesn't escape and no stores
are done through the pointer.
I think it would have to be an optional behaviour for the warning,
because some people *do* want that warning. Maybe the pointer doesn't
escape today, but the code could change tomorrow, and they'd want to
be warned about the discarded qualifiers today.
Also, if the pointer's scope is strictly limited to that function, and
you never write through it, why not just make it const? What is the
advantage of writing your code that way, and requiring changes to the
compiler to deal with your desire to ignore the const qualifiers?
Re: "const"-related gcc warnings with pointers around, annoying
On 1/25/19, Jonathan Wakely wrote:
> On Fri, 25 Jan 2019 at 13:48, Warren D Smith wrote:
>>
>> "foo" is a type that is a struct containing a uint64_t field x[4]
>> (among other things).
>>
>> bool Proc( const foo *dog ){
>>uint64_t *a, *b;
>>a = dog->x; // pointer a now points to dog->x[0]
>>b = something else;
>>if( *a == *b ) return(TRUE);
>>return(FALSE);
>> }
>>
>> Now gcc complains
>> warning: assigning to 'uint64_t *' (aka 'unsigned long long *') from
>> 'uint64_t const[4]' discards qualifiers
>> [-Wincompatible-pointer-types-discards-qualifiers]
>>
>> but the thing is, those pointers a and b, never got used to alter
>> anything. They merely
>> were used to read harmlessly from memory. So dog still clearly was never
>> altered, and hence genuinely was const.
>>
>> The problem here seems to me to be a lack of intelligence inside gcc's
>> thinking on the subject of "const"s.Sure assigning to a pointer
>> could be harmful to const-hood because
>> that pointer could get used someplace else to write to the "const" part
>> of
>> memory. BUT, if we know that pointer never can be used to write
>> to memory anywhere, because it lives only inside the restricted scope of
>> Proc(){}, and never is used to write to memory anywhere, and never is
>> copied to any
>> other variable (because we examine the code inside Proc to verify
>> this), then it was
>> ok and gcc should not warn.
>
> This belongs on the gcc-help list, not here. If you want changes to
> GCC's diagnostics please file a bug report in Bugzilla.
>
> Basically you're asking for GCC to do escape analysis on the converted
> pointer, and suppress the warnings if it doesn't escape and no stores
> are done through the pointer.
>
> I think it would have to be an optional behaviour for the warning,
> because some people *do* want that warning. Maybe the pointer doesn't
> escape today, but the code could change tomorrow, and they'd want to
> be warned about the discarded qualifiers today.
>
> Also, if the pointer's scope is strictly limited to that function, and
> you never write through it, why not just make it const?
--good idea. I thought I wasn't allowed to do that... but tried it
and I am allowed
and it worked. Thanks.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On January 25, 2019 7:22:36 AM GMT+01:00, Nikhil Benesch wrote: >I am attempting to convince GCC to build target libraries with >link-time >optimizations enabled. I am primarily interested in libgo, but this >discussion >seems like it would be applicable to libstdc++, libgfortran, etc. The >benchmarking I've done suggests that LTOing libgo yields a 5-20% >speedup on >various Go programs, which is quite substantial. > >The trouble is convincing GCC's build system to apply the various LTO >flags to >the correct places. Ian Taylor suggested the following to plumb -flto >into >libgo compilation: > >$ make GOCFLAGS_FOR_TARGET="-g -O3 -flto" > >This nearly works, and I believe there are analogous options that would >apply to >the other target libraries that GCC builds. > >The trouble is that while building libgo, the build system uses ar and >ranlib >directly from binutils, without providing them with the LTO plugin that >was >built earlier. This means that the LTO information is dropped on the >floor, and >attempting to link with the built libgo archive will fail. > >I have a simple patch to the top-level configure.ac that resolves the >issue by >teaching the build system to use the gcc-ar and gcc-ranlib wrappers >which were >built earlier and know how to pass the linker plugin to the underlying >ar/ranlib >commands. The patch is small enough that I've included it at the end of >this >email. > >My question is whether this is a reasonable thing to do. It seems like >using >the gcc-ar and gcc-ranlib wrappers strictly improves the situation, and >won't >impact compilations that don't specify -flto. But I'm not familiar >enough with >the build system to say for sure. > >Does anyone have advice to offer? Has anyone tried convincing the build >system >to compile some of the other target libraries (like libstdc++ or >libgfortran) >with -flto? Using the built gcc-ar and ranlib sounds good but the patch looks not Form a quick look. I think we want to change the top level makefile to pass down the appropriate ar/ranlib_FOR_TARGET similar to how we pass CC_FOR_tARGET. Richard. >diff --git a/configure.ac b/configure.ac >index 87f2aee05008..1c38ac5979ff 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -3400,7 +3400,8 @@ >ACX_CHECK_INSTALLED_TARGET_TOOL(WINDMC_FOR_TARGET, windmc) > > RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET" > >-GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, [binutils/ar]) >+GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, >+ [gcc/gcc-ar -B$$r/$(HOST_SUBDIR)/gcc/]) > GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [gas/as-new]) >GCC_TARGET_TOOL(cc, CC_FOR_TARGET, CC, [gcc/xgcc >-B$$r/$(HOST_SUBDIR)/gcc/]) > dnl see comments for CXX_FOR_TARGET_FLAG_TO_PASS >@@ -3424,7 +3425,8 @@ GCC_TARGET_TOOL(nm, NM_FOR_TARGET, NM, >[binutils/nm-new]) >GCC_TARGET_TOOL(objcopy, OBJCOPY_FOR_TARGET, OBJCOPY, >[binutils/objcopy]) >GCC_TARGET_TOOL(objdump, OBJDUMP_FOR_TARGET, OBJDUMP, >[binutils/objdump]) > GCC_TARGET_TOOL(otool, OTOOL_FOR_TARGET, OTOOL) >-GCC_TARGET_TOOL(ranlib, RANLIB_FOR_TARGET, RANLIB, [binutils/ranlib]) >+GCC_TARGET_TOOL(ranlib, RANLIB_FOR_TARGET, RANLIB, >+ [gcc/gcc-ranlib -B$$r/$(HOST_SUBDIR)/gcc/]) >GCC_TARGET_TOOL(readelf, READELF_FOR_TARGET, READELF, >[binutils/readelf]) > GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET, STRIP, [binutils/strip-new]) >GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, >[binutils/windres])
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On Fri, 25 Jan 2019, Nikhil Benesch wrote: > I am attempting to convince GCC to build target libraries with link-time > optimizations enabled. I am primarily interested in libgo, but this discussion Note that as far as I know issues with host-dependencies of LTO bytecode (bug 41526) may still exist, so this wouldn't work with Canadian cross compilers. > I have a simple patch to the top-level configure.ac that resolves the issue by > teaching the build system to use the gcc-ar and gcc-ranlib wrappers which were > built earlier and know how to pass the linker plugin to the underlying > ar/ranlib > commands. The patch is small enough that I've included it at the end of this > email. Will those wrappers properly wrap round tools for the target that were configured using --with-build-time-tools? -- Joseph S. Myers jos...@codesourcery.com
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers wrote: >On Fri, 25 Jan 2019, Nikhil Benesch wrote: > >> I am attempting to convince GCC to build target libraries with >link-time >> optimizations enabled. I am primarily interested in libgo, but this >discussion > >Note that as far as I know issues with host-dependencies of LTO >bytecode >(bug 41526) may still exist, so this wouldn't work with Canadian cross >compilers. I was expecting the LTO byte code not to be retained in the built libraries. >> I have a simple patch to the top-level configure.ac that resolves the >issue by >> teaching the build system to use the gcc-ar and gcc-ranlib wrappers >which were >> built earlier and know how to pass the linker plugin to the >underlying ar/ranlib >> commands. The patch is small enough that I've included it at the end >of this >> email. > >Will those wrappers properly wrap round tools for the target that were >configured using --with-build-time-tools?
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
Richard, regarding your first mail, I'm afraid I'm not sure what you mean. Isn't this exactly the section of configure.ac that handles CC_FOR_TARGET? The Makefile is dumb and just passes the autoconf-substituted value for CC_FOR_TARGET directly through. (I agree the patch will need some tweaks to work for all the build/host/target combination possibilities.) On Fri, Jan 25, 2019 at 12:18 PM Joseph Myers wrote: > > On Fri, 25 Jan 2019, Nikhil Benesch wrote: > > > I am attempting to convince GCC to build target libraries with link-time > > optimizations enabled. I am primarily interested in libgo, but this > > discussion > > Note that as far as I know issues with host-dependencies of LTO bytecode > (bug 41526) may still exist, so this wouldn't work with Canadian cross > compilers. Ack, thanks for the heads up. For now I'm only interested in turning on LTO during native builds. > > I have a simple patch to the top-level configure.ac that resolves the issue > > by > > teaching the build system to use the gcc-ar and gcc-ranlib wrappers which > > were > > built earlier and know how to pass the linker plugin to the underlying > > ar/ranlib > > commands. The patch is small enough that I've included it at the end of this > > email. > > Will those wrappers properly wrap round tools for the target that were > configured using --with-build-time-tools? That's a good question. I think the answer is no. I'll investigate further. On Fri, Jan 25, 2019 at 12:39 PM Richard Biener wrote: > > On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers > wrote: > >On Fri, 25 Jan 2019, Nikhil Benesch wrote: > > > >> I am attempting to convince GCC to build target libraries with > >link-time > >> optimizations enabled. I am primarily interested in libgo, but this > >discussion > > > >Note that as far as I know issues with host-dependencies of LTO > >bytecode > >(bug 41526) may still exist, so this wouldn't work with Canadian cross > >compilers. > > I was expecting the LTO byte code not to be retained in the built libraries. > > >> I have a simple patch to the top-level configure.ac that resolves the > >issue by > >> teaching the build system to use the gcc-ar and gcc-ranlib wrappers > >which were > >> built earlier and know how to pass the linker plugin to the > >underlying ar/ranlib > >> commands. The patch is small enough that I've included it at the end > >of this > >> email. > > > >Will those wrappers properly wrap round tools for the target that were > >configured using --with-build-time-tools? >
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On Freitag, 25. Januar 2019 07:22:36 CET Nikhil Benesch wrote: > Does anyone have advice to offer? Has anyone tried convincing the build > system to compile some of the other target libraries (like libstdc++ or > libgfortran) with -flto? > Make sure the static versions of the libraries are partially linked before being archived so they do not have LTO code in the final libraries. gcc -r -o libname.o ar x libname.a libname.o Never done it with gcc libraries though. 'Allan
Re: About GSOC.
It took some time to get know using GDB, but upto some end I got it to work. The enum real_value_class is used to classify the number into zero, normal, infinity and NaN. This class is represented by r->cl in real_value and values in struct real_value are used as flags or representations while string to real conversion (real_from_string) in real.c and other functions. The decimal/hex string value is converted into real in real_from_string function with byte-byte comparison which also include mpfr. (Correct me if I am wrong.) What is the significance of mpfr related to these internal representations? Thanks. -Tejas On Wed, 23 Jan 2019 at 23:06, Joseph Myers wrote: > > On Wed, 23 Jan 2019, Tejas Joshi wrote: > > > But I really dont know how to inspect a file like real.h > > (real_value)/real.c? > > Use cc1 to build a test program with selected floating-point constants in > it. Set breakpoints on appropriate functions in real.c (e.g. related to > converting strings for real constants into the internal representation). > Look at the representation produced for those constants to determine the > particular conventions being used. > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: About GSOC.
On Sat, 26 Jan 2019, Tejas Joshi wrote: > function with byte-byte comparison which also include mpfr. (Correct > me if I am wrong.) What is the significance of mpfr related to these > internal representations? real.c provides a fixed-size representation of floating-point numbers that allows for various non-IEEE formats supported by GCC, and also allows functions from dfp.c to be used for decimal floating-point formats. MPFR is used in GCC to provide operations that are nontrivial to implement, especially those that are nontrivial to implement in such a fixed-size context. real.c operations wrap around MPFR ones where appropriate, doing whatever's needed in cases where there are non-IEEE semantics or sets of values. -- Joseph S. Myers jos...@codesourcery.com
gcc-8-20190125 is now available
Snapshot gcc-8-20190125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 268281 You'll find: gcc-8-20190125.tar.xzComplete GCC SHA256=c0dd87a33a7af607bf139bf5396696c21dc8252e9433d2c4a567097c398b87ab SHA1=8e3d5c24cae5ab33ef971f8e42818ac20be910d0 Diffs from 8-20190118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
