Getting Wales Moving 2019
GETTING WALES MOVING DELIVERING ON THE WELL-BEING OF WALES 27TH FEBRUARY 2019 HILTON HOTEL - CARDIFF Following on from the hugely successful inaugural Getting Wales Moving Conference - Delivering on the Well-being for Future Generations Act, we are delighted to announce the second conference in the series on the 27th of February 2019 at the Hilton 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 again feature influential and well-respected speakers with detailed insight from the Welsh Government, Sport Wales, and leading figures involved in improving population health and tackling inactivity and skills shortages across the sector workforce and Welsh communities. [1]CLICK FOR CONFERENCE WEBSITE [2] [3] [4] [5] John McAvoy Triathlon England Gareth Davies Welsh Rugby Union Yvonne Harrison Project '92 Ryan Jones Welsh Rugby Union 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. To register for the conference, simply click the button below. [6]REGISTER NOW The conference will cover the following topics: * Update on the Future of Well - Being 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 [7] Getting Wales Moving 2019 In association with ICON TRAINING Over the last 20 years, Icon has consistently proven to be a high quality and visionary training provider. In recent years, the company was graded 1 'Outstanding' from Ofsted, and won Training Provider of the Year two years running against high competition within the industry. 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 [8] Click here to access speaker presentations and slides from the Getting Wales Moving Conference held at the Hilton Hotel in Cardiff, February 2018 [9]WHAT WILL THE WELLBEING OF FUTURE GENERATIONS ACT MEAN TO ME? [10] [11] [12] [13] [14]TAKE ME TO THE WEBSITE F I N D O U T M O R E Follow us on social media for more info & updates [15]Twitter [16]LinkedIn [17]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://sport.wales/ 3. http://www.collegeswales.ac.uk/ 4. http://www.wru.co.uk/ 5. http://icon-training.com/ 6. http://wales2019.whysports.co.uk/index.php?option=com_reg 7. http://icon-training.com/ 8. http://wke.lt/w/s/MDHDl 9. http://thewaleswewant.co.uk/sites/default/files/Guide to the WFGAct.pdf 10. http://sport.wales/ 11. http://www.collegeswales.ac.uk/ 12. http://www.wru.co.uk/ 13. http://icon-training.com/ 14. http://wales2019.whysports.co.uk/index.php?alias=our-mission-skills-communities-2018&option=com_content&view=article&id=58&Itemid=196 15. https://www.twitter.com/whysportsmedia 16. https://www.linkedin.com/company/why-sports-media-group-limited 17. https://www.youtube.com/channel/UCvQMHl9pPd6GzA5MWCikjWw Unsubscribe: http://app.icontact.com/icp/mmail-mprofile.php?r=45048210&l=2500&s=9MBV&m=65759&c=1721525 This message was sent to gcc@gcc.gnu.org from wa...@whysports-events.co.uk Getting Wales Moving Conference Richard Stott 5300 Lakeside Cheadle, Stockport SK8 3GP, United Kingdom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - iContact - Try it for FREE: https://www.icontact.com/signup-trial?utm_medium=poweredby&utm_source=footerlink&utm_campaign=iC%20Footer&afid=144186
Re: Why did Intel change his static branch prediction mechanism over these years?
On 08/14/2018 03:36 PM, 2016 quekong wrote: And Intel seems don't want to talk about it any more, because the latest material I found within Intel Document was written about ten years ago. Since branch prediction is nowadays a security feature, I doubt you will see detailed public documentation from any processor manufacturer. I know static branch prediction is (far?) less important than dynamic, but in quite a few situations, CPU will be completely lost and programmers(with compiler) are usually the best guide. Of course these situations are usually not performance bottleneck, because once a branch is frequently executed, the dynamic predictor will capture it. There is a movement to replace table-driven stack unwinding with a conditional branch after most function calls, and those branches should predict really well statically. (And so would return value checks for almost all POSIX functions.) Statically predicting those branches as not taken may free up branch prediction resources for other uses. On the other hand, programmers tend to misuse __builtin_expect to say that something is unlikely to happen, while it can happen quite regularly during certain executions of the program. So if __builtin_expect results in static hints from the compiler, the CPU will be better off ignoring those hints in most cases. Thanks, Florian
Re: Why did Intel change his static branch prediction mechanism over these years?
Hi, Florian. >>>There is a movement to replace table-driven stack unwinding with a >>>conditional branch after most function calls... I am sorry I don't understand its meaning, forgive my poor knowledge of dynamic prediction, I am reading relative materials these days, could you explain a little more for this sentence, or give me some keywords for google ? >>> programmers tend to misuse __builtin_expect .. I believe you must have strong factual basis saying such words, I can quite accept the CPU manufacturer's ignoring branch prediction hints for some reasons, but not this, One somewhat contrived example: if most people of a country are blind, then the government forbid the car to provide a safe road, may a better choice is asking the blind people go to hospital to cure the eye. Thanks again. 2018-08-15 17:26 GMT+08:00, Florian Weimer : > On 08/14/2018 03:36 PM, 2016 quekong wrote: > >> And Intel seems don't want to talk about it any more, because the latest >> material I found within Intel Document was written about ten years ago. > > Since branch prediction is nowadays a security feature, I doubt you will > see detailed public documentation from any processor manufacturer. > >> I know static branch prediction is (far?) less important than dynamic, >> but >> in quite a few situations, CPU will be completely lost and >> programmers(with >> compiler) are usually the best guide. Of course these situations are >> usually not performance bottleneck, because once a branch is frequently >> executed, the dynamic predictor will capture it. > > There is a movement to replace table-driven stack unwinding with a > conditional branch after most function calls, and those branches should > predict really well statically. (And so would return value checks for > almost all POSIX functions.) Statically predicting those branches as > not taken may free up branch prediction resources for other uses. > > On the other hand, programmers tend to misuse __builtin_expect to say > that something is unlikely to happen, while it can happen quite > regularly during certain executions of the program. So if > __builtin_expect results in static hints from the compiler, the CPU will > be better off ignoring those hints in most cases. > > Thanks, > Florian >
Re: [GSOC] LTO dump tool project - feedback
Hi. After last update of the branch, there's a feedback that will be needed before we can adept to have it merged into trunk: 1) there's patch for lto-dump proper install: diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in index e474f85ebc6..e9d2659025c 100644 --- a/gcc/lto/Make-lang.in +++ b/gcc/lto/Make-lang.in @@ -46,7 +46,10 @@ lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE) lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE) lto.rest.encap: lto.tags: -lto.install-common: +lto.install-common: installdirs + $(INSTALL_PROGRAM) $(LTO_DUMP_EXE) \ + $(DESTDIR)/$(bindir)/$(LTO_DUMP_EXE) + lto.install-man: lto.install-info: lto.dvi: 2) If I build bzip2 (just add -flto into Makefile) with your branch I see an ICE: $ cd bzip2-1.0.6 $ make [...] gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 -flto=9 -o bzip2 bzip2.o -L. -lbz2 lto1: internal compiler error: unexpected offset 0x767bfc lto_resolution_read ../../gcc/lto/lto-common.c:1951 0x767bfc lto_file_read ../../gcc/lto/lto-common.c:2169 0x767bfc read_cgraph_and_symbols(unsigned int, char const**) ../../gcc/lto/lto-common.c:2631 0x74f042 lto_main() ../../gcc/lto/lto.c:580 3) I still see an extra info that is not needed: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 2029 kB ( 52%) phase parsing : 0.01 (100%) 0.00 ( 0%) 0.02 (100%) 1887 kB ( 48%) ipa cp : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 50%) 119 kB ( 3%) ipa lto gimple in : 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1136 kB ( 29%) tree operand scan : 0.01 (100%) 0.00 ( 0%) 0.01 ( 50%) 158 kB ( 4%) TOTAL : 0.01 0.00 0.02 3917 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --enable-checking=release to disable checks. 4) -list: a) please add header, it was useful b) -no-sort makes no sense to me, it's default isn't it? 5) -symbol= a) if symbol is not found, we should print an error 6) -objects= - why '=' ? 7) -type-stats - you have extra empty lines at the beginning - please align header with values 8) -tree-stats - probably also --enable-gather-.. is needed? 9) -dump-body - again, if does not exist, error should be printed 10) -dump-level - again error if wrong value, document possible values if possible 11) please fix formatting of lto-dump so that it explains which suboptions are possible: $ gcov-tool --help Usage: gcov-tool [OPTION]... SUB_COMMAND [OPTION]... Offline tool to handle gcda counts -h, --helpPrint this help, then exit -v, --version Print version number, then exit merge [options] Merge coverage file contents -o, --output Output directory -v, --verbose Verbose mode -w, --weight Set weights (float point values) rewrite [options]Rewrite coverage file contents -n, --normalizeNormalize the profile -o, --output Output directory -s, --scale Scale the profile counters -v, --verbose Verbose mode overlap [options] Compute the overlap of two profiles -f, --function Print function level info -F, --fullname Print full filename -h, --hotonly Only print info for hot objects/functions -o, --objectPrint object level info -t , --hot_threshold Set the threshold for hotness -v, --verbose Verbose mode 12) Do not name it in documentation 'lto-dump-tool', use simply 'lto-dump'. 13) make sure man page is generated for lto-dump 14) I noticed that you smashed some whitespaces for files where you didn't do any changes: gcc/tree.c, lto.c(do_whole_program_analysis) and other places 15) test the tool on a bigger program built with LTO, ideally for both LGEN and also LTRANS files 16) The last bigger challenge is the option handling, we currently participate in lto/lang.opt. Ideally I would prefer using standard mechanism getopt_long, take a look at gcov-dump.c. Can you please investigate that. Anyway, thank you for working on that. I hope we can send a patch submission into GCC's trunk soon. Martin
Re: Why did Intel change his static branch prediction mechanism over these years?
On 08/15/2018 01:16 PM, 2016 quekong wrote: Hi, Florian. There is a movement to replace table-driven stack unwinding with a conditional branch after most function calls... I am sorry I don't understand its meaning, forgive my poor knowledge of dynamic prediction, I am reading relative materials these days, could you explain a little more for this sentence, or give me some keywords for google ? See Herb Sutter, “Zero-overhead deterministic exceptions: Throwing values”. (The “Zero-overhead” is misleading.) programmers tend to misuse __builtin_expect .. I believe you must have strong factual basis saying such words, I can quite accept the CPU manufacturer's ignoring branch prediction hints for some reasons, but not this, We just removed a __builtin_except from the dynamic linker that indicated the wrong way for more than a decade, maybe even two decades. We have anymore that strongly suggest that you run in the C locale or in a single-byte locale, neither of which are generally true these days. Thanks, Florian
Re: Trying to convert to LRA, running into an ICE (infinite reload loop)
> On Aug 15, 2018, at 1:01 AM, Jeff Law wrote:
>
> On 08/14/2018 01:32 PM, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files fails in a way
>> that I can't figure out at all. I'm hoping for some help or hints to track
>> down the cause and come up with a fix.
>>
>> The failing program is testsuite/gcc.c-torture/compile/ifreg.c:
>>
>> union foo
>> {
>> float f;
>> int i;
>> };
>>
>> foo (int a, float c)
>> {
>> union foo b;
>> b.i = a;
>> return b.f + c;
>> }
>>
>> When compiled in LRA mode, I get this:
>>
>> during RTL pass: reload
>> dump file: ifreg.c.274r.reload
>> ../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c: In function ‘foo’:
>> ../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c:12:1: internal
>> compiler error: Max. number of generated reload insns per insn is achieved
>> (90)
>>
>> I fiddled a bit with the mov patterns, for example disabling the
>> patterns that work on multi-word values (SI and DI mode, since pdp11 word is
>> HImode). That doesn't fix (or create) the failure, though the specific
>> insns change as a result.
>>
>> What I see going in to reload (from the "ira" dump file) is:
>>
>> (note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
>> (note 2 5 4 2 NOTE_INSN_DELETED)
>> (note 4 2 22 2 NOTE_INSN_FUNCTION_BEG)
>> (insn 22 4 18 2 (clobber (reg/v:DI 26 [ b ]))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 -1
>> (nil))
>> (insn 18 22 19 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 0)
>>(const_int 0 [0]))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>> (nil))
>> (insn 19 18 20 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 2)
>>(const_int 0 [0]))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>> (nil))
>> ...
>>
>> Reload shows this:
>>
>> (note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
>> (note 2 5 4 2 NOTE_INSN_DELETED)
>> (note 4 2 22 2 NOTE_INSN_FUNCTION_BEG)
>> (insn 22 4 18 2 (clobber (reg/v:DI 26 [ b ]))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 -1
>> (nil))
>> (insn 18 22 25 2 (set (reg:HI 32)
>>(const_int 0 [0]))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>> (nil))
>> (insn 25 18 26 2 (set (reg:HI 33)
>>(reg:HI 32))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>> (nil))
>> (insn 26 25 27 2 (set (reg:HI 34)
>>(reg:HI 33))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>> (nil))
>> (insn 27 26 28 2 (set (reg:HI 35)
>>(reg:HI 34))
>> "../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
>> (nil))
>> ... with insns that do nothing, like the one above, repeating until it gives
>> up.
>>
>> At the top of the dump file where LRA is reporting what it's doing, I see
>> this:
>>
>> ** Local #1: **
>>
>> Spilling non-eliminable hard regs: 6
>> New elimination table:
>> Can eliminate 15 to 6 (offset=10, prev_offset=0)
>> Can eliminate 15 to 5 (offset=4, prev_offset=0)
>> Can eliminate 14 to 6 (offset=8, prev_offset=0)
>> Can eliminate 14 to 5 (offset=0, prev_offset=0)
>>0 Non input pseudo reload: reject++
>> alt=0,overall=7,losers=1,rld_nregs=1
>>0 Non input pseudo reload: reject++
>> alt=1,overall=7,losers=1,rld_nregs=1
>>alt=2: Bad operand -- refuse
>>alt=3: Bad operand -- refuse
>> Choosing alt 0 in insn 18: (0) =rR (1) rRN {movhi}
> We've selected alternative 0 for insn 18. I believe that's the rRN ->
> =rR alternative.
Yes, specifically it matches the "N" source constraint (literal zero operand).
>> Creating newreg=32, assigning class GENERAL_REGS to r32
> The insn did not match its constraints. So some kind of reload is
> needed. We allocate a new reload register r32.
>
>> 18: r32:HI=0
>>Inserting insn reload after:
> And we try to initialize r32 to 0. Which of course needs another reload.
>
> I suspect LRA is somehow missing that the operand could live in memory.
Not exactly memory, the source operand is constant 0 and the resulting machine
instruction will be a "clr". The puzzle is why it doesn't see it as matching
when (a) it clearly does and (b) LRA knew that because it told us so in that
first match (it chose alternative zero).
What should I look at next to try to figure out why LRA is getting confused?
paul
Help with fixinclude fix for PR86599
Hi. I've come up with a fixincl fix for PR86599 but "make check" in
the fixincludes directory does not work and I do not know why. I know
just enough fixincl-fu to produce a patch for this issue. I am trying
to convert a chunk of code in stdlib on HP-UX 11.31/PA:
# ifndef _LONG_DOUBLE
#define _LONG_DOUBLE
# if !defined(__ia64) || !defined(_PROTOTYPES) || defined(_LONG_DOUBLE_STRUCT)
typedef struct {
uint32_t word1, word2, word3, word4;
} long_double;
extern long_double strtold __((const char * __restrict, char ** __restrict));
# else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
#ifdef _INCLUDE_HPUX_SOURCE
typedef long double long_double;
#endif /* _INCLUDE_HPUX_SOURCE */
extern long double strtold __((const char * __restrict, char ** __restrict));
# endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
#endif /* _LONG_DOUBLE */
to:
extern long double strtold(const char *, char **);
I am doing this by fixing hpux_long_double_2 so it now looks like:
fix = {
hackname = hpux_long_double_2;
mach = "hppa*-*-hpux11.3*";
files = stdlib.h;
select= "extern[ \t]long_double[ \t]strtold";
bypass= "long_double_t";
sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,"
"/\\/\\* _LONG_DOUBLE \\*\\//c\\\n"
"extern long double strtold(const char *, char **);\n";
sed = "s/long_double/long double/g";
test_text = "# ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
" unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"extern long_double strtold(const char *, char **);\n"
"# endif /* _LONG_DOUBLE */\n";
};
This works but "make check" returns:
stdlib.h /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.h differ: char
1475, line 59
*** stdlib.hWed Aug 15 19:38:37 2018
--- /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.hThu Feb 22
16:12:26 2018
***
*** 56,61
--- 56,62
#if defined( HPUX_LONG_DOUBLE_2_CHECK )
+ # if !defined(__ia64) || !defined(_PROTOTYPES) ||
defined(_LONG_DOUBLE_STRUCT)
#endif /* HPUX_LONG_DOUBLE_2_CHECK */
There were fixinclude test FAILURES
Any ideas?
--
albert chin (ch...@thewrittenword.com)
Re: Help with fixinclude fix for PR86599
You must manually insert the additional test lines into the appropriate
file in fixincludes/tests/base and then retest.
Please see step (6) in fixincludes/README
Thanks, David
On Wed, Aug 15, 2018 at 3:46 PM Albert Chin
wrote:
> Hi. I've come up with a fixincl fix for PR86599 but "make check" in
> the fixincludes directory does not work and I do not know why. I know
> just enough fixincl-fu to produce a patch for this issue. I am trying
> to convert a chunk of code in stdlib on HP-UX 11.31/PA:
>
> # ifndef _LONG_DOUBLE
> #define _LONG_DOUBLE
> # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> defined(_LONG_DOUBLE_STRUCT)
> typedef struct {
> uint32_t word1, word2, word3, word4;
> } long_double;
> extern long_double strtold __((const char * __restrict, char **
> __restrict));
> # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> #ifdef _INCLUDE_HPUX_SOURCE
> typedef long double long_double;
> #endif /* _INCLUDE_HPUX_SOURCE */
> extern long double strtold __((const char * __restrict, char **
> __restrict));
> # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> #endif /* _LONG_DOUBLE */
>
> to:
>
> extern long double strtold(const char *, char **);
>
> I am doing this by fixing hpux_long_double_2 so it now looks like:
> fix = {
> hackname = hpux_long_double_2;
> mach = "hppa*-*-hpux11.3*";
> files = stdlib.h;
> select= "extern[ \t]long_double[ \t]strtold";
> bypass= "long_double_t";
> sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,"
> "/\\/\\* _LONG_DOUBLE \\*\\//c\\\n"
> "extern long double strtold(const char *, char **);\n";
> sed = "s/long_double/long double/g";
>
> test_text = "# ifndef _LONG_DOUBLE\n"
> "#define _LONG_DOUBLE\n"
> " typedef struct {\n"
> " unsigned int word1, word2, word3, word4;\n"
> " } long_double;\n"
> "extern long_double strtold(const char *, char **);\n"
> "# endif /* _LONG_DOUBLE */\n";
> };
>
> This works but "make check" returns:
>
> stdlib.h /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.h differ: char
> 1475, line 59
> *** stdlib.hWed Aug 15 19:38:37 2018
> --- /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.hThu Feb 22
> 16:12:26 2018
> ***
> *** 56,61
> --- 56,62
>
>
> #if defined( HPUX_LONG_DOUBLE_2_CHECK )
> + # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> defined(_LONG_DOUBLE_STRUCT)
>
> #endif /* HPUX_LONG_DOUBLE_2_CHECK */
>
> There were fixinclude test FAILURES
>
> Any ideas?
>
> --
> albert chin (ch...@thewrittenword.com)
>
Re: Help with fixinclude fix for PR86599
On Wed, Aug 15, 2018 at 03:52:33PM -0400, David Edelsohn wrote:
> You must manually insert the additional test lines into the appropriate
> file in fixincludes/tests/base and then retest.
>
> Please see step (6) in fixincludes/README
Ok, thanks. fixincludes/tests/res/stdlib.h has:
#if defined( HPUX_LONG_DOUBLE_CHECK )
extern long double strtold(const char *, char **);
#endif /* HPUX_LONG_DOUBLE_CHECK */
#if defined( HPUX_LONG_DOUBLE_2_CHECK )
# if !defined(__ia64) || !defined(_PROTOTYPES) ||
defined(_LONG_DOUBLE_STRUCT)
#endif /* HPUX_LONG_DOUBLE_2_CHECK */
The body of HPUX_LONG_DOUBLE_2_CHECK is no longer valid with my fix.
I'm thinking it should look like HPUX_LONG_DOUBLE_CHECK so I modified
HPUX_LONG_DOUBLE_2_CHECK to look like HPUX_LONG_DOUBLE_CHECK.
However, when I run "make check", fixincludes/tests/res/stdlib.h has:
#if defined( HPUX_LONG_DOUBLE_2_CHECK )
#endif /* HPUX_LONG_DOUBLE_2_CHECK */
So, I modified test_text to the following:
test_text = "# ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
" unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"# endif /* _LONG_DOUBLE */\n"
"extern long_double strtold(const char *, char **);\n";
rather than:
test_text = "# ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
" unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"extern long_double strtold(const char *, char **);\n"
"# endif /* _LONG_DOUBLE */\n";
and modified fixincludes/tests/base/stdlib.h to:
#if defined( HPUX_LONG_DOUBLE_CHECK )
extern long double strtold(const char *, char **);
#endif /* HPUX_LONG_DOUBLE_CHECK */
#if defined( HPUX_LONG_DOUBLE_2_CHECK )
extern long double strtold(const char *, char **);
#endif /* HPUX_LONG_DOUBLE_2_CHECK */
I don't know why the change to test_text causes "make check" to
succeed though.
> Thanks, David
>
>
>
>
> On Wed, Aug 15, 2018 at 3:46 PM Albert Chin
> wrote:
>
> > Hi. I've come up with a fixincl fix for PR86599 but "make check" in
> > the fixincludes directory does not work and I do not know why. I know
> > just enough fixincl-fu to produce a patch for this issue. I am trying
> > to convert a chunk of code in stdlib on HP-UX 11.31/PA:
> >
> > # ifndef _LONG_DOUBLE
> > #define _LONG_DOUBLE
> > # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > defined(_LONG_DOUBLE_STRUCT)
> > typedef struct {
> > uint32_t word1, word2, word3, word4;
> > } long_double;
> > extern long_double strtold __((const char * __restrict, char **
> > __restrict));
> > # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> > #ifdef _INCLUDE_HPUX_SOURCE
> > typedef long double long_double;
> > #endif /* _INCLUDE_HPUX_SOURCE */
> > extern long double strtold __((const char * __restrict, char **
> > __restrict));
> > # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> > #endif /* _LONG_DOUBLE */
> >
> > to:
> >
> > extern long double strtold(const char *, char **);
> >
> > I am doing this by fixing hpux_long_double_2 so it now looks like:
> > fix = {
> > hackname = hpux_long_double_2;
> > mach = "hppa*-*-hpux11.3*";
> > files = stdlib.h;
> > select= "extern[ \t]long_double[ \t]strtold";
> > bypass= "long_double_t";
> > sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,"
> > "/\\/\\* _LONG_DOUBLE \\*\\//c\\\n"
> > "extern long double strtold(const char *, char **);\n";
> > sed = "s/long_double/long double/g";
> >
> > test_text = "# ifndef _LONG_DOUBLE\n"
> > "#define _LONG_DOUBLE\n"
> > " typedef struct {\n"
> > " unsigned int word1, word2, word3, word4;\n"
> > " } long_double;\n"
> > "extern long_double strtold(const char *, char **);\n"
> > "# endif /* _LONG_DOUBLE */\n";
> > };
> >
> > This works but "make check" returns:
> >
> > stdlib.h /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.h differ: char
> > 1475, line 59
> > *** stdlib.hWed Aug 15 19:38:37 2018
> > --- /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.hThu Feb 22
> > 16:12:26 2018
> > ***
> > *** 56,61
> > --- 56,62
> >
> >
> > #if defined( HPUX_LONG_DOUBLE_2_CHECK )
> > + # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > defined(_LONG_DOUBLE_STRUCT)
> >
> > #endif /* HPUX_LONG_DOUBLE_2_CHECK */
> >
> > There were fixinclude test FAILURES
> >
> > Any ideas?
> >
> > --
> > albert chin (ch...@thewrittenword.com)
> >
--
albert chin (ch...@thewrittenword.com)
Re: Help with fixinclude fix for PR86599
The change should not unintentionally affect existing tests.
The new test should be exactly the text that "make check" produces, not
what you think it should look like and not like another, neighboring test.
If the test doesn't look as you expect, you need to examine your test text.
You also can try to ask Bruce Korb for some advice. Few modern targets
require fixincludes.
Thanks, David
On Wed, Aug 15, 2018 at 4:38 PM Albert Chin
wrote:
> On Wed, Aug 15, 2018 at 03:52:33PM -0400, David Edelsohn wrote:
> > You must manually insert the additional test lines into the appropriate
> > file in fixincludes/tests/base and then retest.
> >
> > Please see step (6) in fixincludes/README
>
> Ok, thanks. fixincludes/tests/res/stdlib.h has:
> #if defined( HPUX_LONG_DOUBLE_CHECK )
> extern long double strtold(const char *, char **);
>
> #endif /* HPUX_LONG_DOUBLE_CHECK */
>
> #if defined( HPUX_LONG_DOUBLE_2_CHECK )
> # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> defined(_LONG_DOUBLE_STRUCT)
>
> #endif /* HPUX_LONG_DOUBLE_2_CHECK */
>
> The body of HPUX_LONG_DOUBLE_2_CHECK is no longer valid with my fix.
> I'm thinking it should look like HPUX_LONG_DOUBLE_CHECK so I modified
> HPUX_LONG_DOUBLE_2_CHECK to look like HPUX_LONG_DOUBLE_CHECK.
>
> However, when I run "make check", fixincludes/tests/res/stdlib.h has:
> #if defined( HPUX_LONG_DOUBLE_2_CHECK )
>
> #endif /* HPUX_LONG_DOUBLE_2_CHECK */
>
> So, I modified test_text to the following:
> test_text = "# ifndef _LONG_DOUBLE\n"
> "#define _LONG_DOUBLE\n"
> " typedef struct {\n"
> " unsigned int word1, word2, word3, word4;\n"
> " } long_double;\n"
> "# endif /* _LONG_DOUBLE */\n"
> "extern long_double strtold(const char *, char **);\n";
> rather than:
> test_text = "# ifndef _LONG_DOUBLE\n"
> "#define _LONG_DOUBLE\n"
> " typedef struct {\n"
> " unsigned int word1, word2, word3, word4;\n"
> " } long_double;\n"
> "extern long_double strtold(const char *, char **);\n"
> "# endif /* _LONG_DOUBLE */\n";
>
> and modified fixincludes/tests/base/stdlib.h to:
> #if defined( HPUX_LONG_DOUBLE_CHECK )
> extern long double strtold(const char *, char **);
>
> #endif /* HPUX_LONG_DOUBLE_CHECK */
>
>
> #if defined( HPUX_LONG_DOUBLE_2_CHECK )
> extern long double strtold(const char *, char **);
>
> #endif /* HPUX_LONG_DOUBLE_2_CHECK */
>
> I don't know why the change to test_text causes "make check" to
> succeed though.
>
> > Thanks, David
> >
> >
> >
> >
> > On Wed, Aug 15, 2018 at 3:46 PM Albert Chin <
> g...@mlists.thewrittenword.com>
> > wrote:
> >
> > > Hi. I've come up with a fixincl fix for PR86599 but "make check" in
> > > the fixincludes directory does not work and I do not know why. I know
> > > just enough fixincl-fu to produce a patch for this issue. I am trying
> > > to convert a chunk of code in stdlib on HP-UX 11.31/PA:
> > >
> > > # ifndef _LONG_DOUBLE
> > > #define _LONG_DOUBLE
> > > # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > > defined(_LONG_DOUBLE_STRUCT)
> > > typedef struct {
> > > uint32_t word1, word2, word3, word4;
> > > } long_double;
> > > extern long_double strtold __((const char * __restrict, char **
> > > __restrict));
> > > # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> > > #ifdef _INCLUDE_HPUX_SOURCE
> > > typedef long double long_double;
> > > #endif /* _INCLUDE_HPUX_SOURCE */
> > > extern long double strtold __((const char * __restrict, char **
> > > __restrict));
> > > # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> > > #endif /* _LONG_DOUBLE */
> > >
> > > to:
> > >
> > > extern long double strtold(const char *, char **);
> > >
> > > I am doing this by fixing hpux_long_double_2 so it now looks like:
> > > fix = {
> > > hackname = hpux_long_double_2;
> > > mach = "hppa*-*-hpux11.3*";
> > > files = stdlib.h;
> > > select= "extern[ \t]long_double[ \t]strtold";
> > > bypass= "long_double_t";
> > > sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,"
> > > "/\\/\\* _LONG_DOUBLE \\*\\//c\\\n"
> > > "extern long double strtold(const char *, char **);\n";
> > > sed = "s/long_double/long double/g";
> > >
> > > test_text = "# ifndef _LONG_DOUBLE\n"
> > > "#define _LONG_DOUBLE\n"
> > > " typedef struct {\n"
> > > " unsigned int word1, word2, word3, word4;\n"
> > > " } long_double;\n"
> > > "extern long_double strtold(const char *, char **);\n"
> > > "# endif /* _LONG_DOUBLE */\n";
> > > };
> > >
> > > This works but "make check" returns:
> > >
> > > stdlib.h /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.h differ:
> char
gcc-6-20180815 is now available
Snapshot gcc-6-20180815 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180815/ 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 263572 You'll find: gcc-6-20180815.tar.xzComplete GCC SHA256=ba3abe07f23ef0c86fbc3471943b0e30af57161cc2468a230f30661372935bfc SHA1=0d4350008b804a5ba5020d667b7c8ad4b8d6d214 Diffs from 6-20180808 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.
