Successful bootstrap and install of gcc (GCC) 7.2.0 on sparc64-unknown-linux-gnu
Hi, Here's a report of a successful build and install of GCC: $ gcc-7.2.0/config.guess sparc64-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/sparc-unknown-linux-gnu/7.2.0/lto-wrapper Target: sparc-unknown-linux-gnu Configured with: ../gcc-7.2.0/configure --with-cpu=ultrasparc --enable-targets=all --disable-libsanitizer --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu --target=sparc-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 7.2.0 (GCC) -- Build environment -- host: sun-ultra-10 distro: los.git rootfs=5b2961 native=5b2961 kernel: Linux 4.12.0-ultra-los_f834d binutils: GNU binutils 2.29 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.26 zlib: 1.2.11 mpfr: 3.1.3 gmp: 60102 -- Time consumed -- configure: real0m 28.79s user0m 24.78s sys 0m 3.40s bootstrap: real44h 24m 24s user43h 27m 07s sys 41m 44.07s install:real2m 52.97s user1m 6.11s sys 0m 37.17s -- Hardware details --- MemTotal: 507728 kB cpu : TI UltraSparc IIi (Sabre) fpu : UltraSparc IIi integrated FPU pmu : ultra12 prom: OBP 3.31.0 2001/07/25 20:36 type: sun4u ncpus probed: 1 ncpus active: 1 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 1a39de00 cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis MMU Type: Spitfire MMU PGSZs : 8K,64K,512K,4MB A.
gcc-8-20170903 is now available
Snapshot gcc-8-20170903 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20170903/ 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/trunk revision 251628 You'll find: gcc-8-20170903.tar.xzComplete GCC SHA256=9663e81239e6d2ccedcf0d77040a9fbc14e6f5e6f971a67cb24ae1448d4f00d3 SHA1=f262ceb25d5f0c0086ff7d70482bd8b7ee0e9221 Diffs from 8-20170827 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.
Re: assuming signed overflow does not occur
Hi,
On Sun, Sep 3, 2017 at 1:48 PM, Florian Weimer wrote:
> * Bruce Korb:
>
>> I know about all these theoretical possibilities of numbers behaving
>> in strange ways when arithmetic optimizations assume that signed
>> overflow won't occur when they actually might. Yep, it creates subtle
>> bugs. The warning is worthwhile. Still and all:
>>
>> 485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
>> 486 if (tvdiff.tv_sec != 0) {
>>
>> systime.c: In function 'step_systime':
>> systime.c:486:5: warning: assuming signed overflow does not occur when
>> simplifying conditional to constant [-Wstrict-overflow]
>>
>> What possible optimization might be going on to cause an overflow
>> problem when I simply want to know if the "tv_sec" field is zero or
>> not? (BTW, in current source, "tvdiff" is a structure that is returned
>> by abs_tval())
>
> This usually happens after inlining and other optimizations. You'll
> have to look at GIMPLE dumps to figure out what is going on.
RFE's are for this list: please improve the message.
The message does not have to be a dissertation, but messages
nowadays can certainly include URL's to direct people to
reasonable places. I'd suggest something like:
gcc.gnu.org/gcc-messages/xxx
WRT looking at a GIMPLE dump, I'd first have to learn what GIMPLE is,
then learn how to decipher one, then figure out how to get it out of
the compiler and
finally plod through it. Guess what? I won't be doing that. I'll
squish the warning first. :( Effective messages are very important.
Re: assuming signed overflow does not occur
* Bruce Korb:
> I know about all these theoretical possibilities of numbers behaving
> in strange ways when arithmetic optimizations assume that signed
> overflow won't occur when they actually might. Yep, it creates subtle
> bugs. The warning is worthwhile. Still and all:
>
> 485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
> 486 if (tvdiff.tv_sec != 0) {
>
> systime.c: In function 'step_systime':
> systime.c:486:5: warning: assuming signed overflow does not occur when
> simplifying conditional to constant [-Wstrict-overflow]
>
> What possible optimization might be going on to cause an overflow
> problem when I simply want to know if the "tv_sec" field is zero or
> not? (BTW, in current source, "tvdiff" is a structure that is returned
> by abs_tval())
This usually happens after inlining and other optimizations. You'll
have to look at GIMPLE dumps to figure out what is going on.
(This is more a question for the gcc-help list.)
Re: Add support to trace comparison instructions and switch statements
On Sun, Sep 3, 2017 at 12:38 PM, 吴潍浠(此彼) wrote: > Hi > I will update the patch according to your requirements, and with some my > suggestions. > It will take me one or two days. Thanks! No hurry, just wanted to make sure you still want to pursue this. > Wish Wu > > -- > From:Dmitry Vyukov > Time:2017 Sep 3 (Sun) 18:21 > To:Jakub Jelinek > Cc:Wish Wu ; gcc ; gcc-patches > ; Jeff Law ; wishwu007 > > Subject:Re: Add support to trace comparison instructions and switch statements > > > On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote: >> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: >>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: What we instrument in LLVM is _comparisons_ rather than control structures. So that would be: _4 = x_8(D) == 98; For example, result of the comparison can be stored into a bool struct field, and then used in branching long time after. We still want to intercept this comparison. >>> >>> Then we need to instrument not just GIMPLE_COND, which is the stmt >>> where the comparison decides to which of the two basic block successors to >>> jump, but also GIMPLE_ASSIGN with tcc_comparison class >>> gimple_assign_rhs_code (the comparison above), and maybe also >>> GIMPLE_ASSIGN with COND_EXPR comparison code (that is say >>> _4 = x_1 == y_2 ? 23 : _3; >>> ). >>> > Perhaps for -fsanitize-coverage= it might be a good idea to force > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE > decisions mentioned above so that the IL is closer to what the user > wrote. If we recurse down to comparison operations and instrument them, this will not be so important, right? >>> >>> Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_COND, >>> then you don't handle many comparisons from the source code. And if you >>> handle both, some of the GIMPLE_CONDs might be just artificial comparisons. >>> By pretending small branch cost for the tracing case you get fewer >>> artificial comparisons. >> >> >> Are these artificial comparisons on BOOLEAN_TYPE? I think BOOLEAN_TYPE >> needs to be ignored entirely, there is just like 2 combinations of >> possible values. >> If not, then what it is? Is it a dup of previous comparisons? >> >> I am not saying these modes should not be enabled. You know much >> better. I just wanted to point that that integer comparisons is what >> we should be handling. >> >> Your example: >> >> _1 = x_8(D) == 21; >> _2 = x_8(D) == 64; >> _3 = _1 | _2; >> if (_3 != 0) >> >> raises another point. Most likely we don't want to see speculative >> comparisons. At least not yet (we will see them once we get through >> the first comparison). So that may be another reason to enable these >> modes (make compiler stick closer to original code). > > Wait, it is not speculative in this case as branch is on _1 | _2. But > still, it just makes it harder for fuzzer to get through as it needs > to guess both values at the same time rather then doing incremental > progress.
Re: Add support to trace comparison instructions and switch statements
Hi I will update the patch according to your requirements, and with some my suggestions. It will take me one or two days. Wish Wu -- From:Dmitry Vyukov Time:2017 Sep 3 (Sun) 18:21 To:Jakub Jelinek Cc:Wish Wu ; gcc ; gcc-patches ; Jeff Law ; wishwu007 Subject:Re: Add support to trace comparison instructions and switch statements On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote: > On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: >> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >>> What we instrument in LLVM is _comparisons_ rather than control >>> structures. So that would be: >>> _4 = x_8(D) == 98; >>> For example, result of the comparison can be stored into a bool struct >>> field, and then used in branching long time after. We still want to >>> intercept this comparison. >> >> Then we need to instrument not just GIMPLE_COND, which is the stmt >> where the comparison decides to which of the two basic block successors to >> jump, but also GIMPLE_ASSIGN with tcc_comparison class >> gimple_assign_rhs_code (the comparison above), and maybe also >> GIMPLE_ASSIGN with COND_EXPR comparison code (that is say >> _4 = x_1 == y_2 ? 23 : _3; >> ). >> >>> > Perhaps for -fsanitize-coverage= it might be a good idea to force >>> > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE >>> > decisions mentioned above so that the IL is closer to what the user wrote. >>> >>> If we recurse down to comparison operations and instrument them, this >>> will not be so important, right? >> >> Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_COND, >> then you don't handle many comparisons from the source code. And if you >> handle both, some of the GIMPLE_CONDs might be just artificial comparisons. >> By pretending small branch cost for the tracing case you get fewer >> artificial comparisons. > > > Are these artificial comparisons on BOOLEAN_TYPE? I think BOOLEAN_TYPE > needs to be ignored entirely, there is just like 2 combinations of > possible values. > If not, then what it is? Is it a dup of previous comparisons? > > I am not saying these modes should not be enabled. You know much > better. I just wanted to point that that integer comparisons is what > we should be handling. > > Your example: > > _1 = x_8(D) == 21; > _2 = x_8(D) == 64; > _3 = _1 | _2; > if (_3 != 0) > > raises another point. Most likely we don't want to see speculative > comparisons. At least not yet (we will see them once we get through > the first comparison). So that may be another reason to enable these > modes (make compiler stick closer to original code). Wait, it is not speculative in this case as branch is on _1 | _2. But still, it just makes it harder for fuzzer to get through as it needs to guess both values at the same time rather then doing incremental progress.
Re: Add support to trace comparison instructions and switch statements
On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote: > On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: >> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >>> What we instrument in LLVM is _comparisons_ rather than control >>> structures. So that would be: >>> _4 = x_8(D) == 98; >>> For example, result of the comparison can be stored into a bool struct >>> field, and then used in branching long time after. We still want to >>> intercept this comparison. >> >> Then we need to instrument not just GIMPLE_COND, which is the stmt >> where the comparison decides to which of the two basic block successors to >> jump, but also GIMPLE_ASSIGN with tcc_comparison class >> gimple_assign_rhs_code (the comparison above), and maybe also >> GIMPLE_ASSIGN with COND_EXPR comparison code (that is say >> _4 = x_1 == y_2 ? 23 : _3; >> ). >> >>> > Perhaps for -fsanitize-coverage= it might be a good idea to force >>> > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE >>> > decisions mentioned above so that the IL is closer to what the user wrote. >>> >>> If we recurse down to comparison operations and instrument them, this >>> will not be so important, right? >> >> Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_COND, >> then you don't handle many comparisons from the source code. And if you >> handle both, some of the GIMPLE_CONDs might be just artificial comparisons. >> By pretending small branch cost for the tracing case you get fewer >> artificial comparisons. > > > Are these artificial comparisons on BOOLEAN_TYPE? I think BOOLEAN_TYPE > needs to be ignored entirely, there is just like 2 combinations of > possible values. > If not, then what it is? Is it a dup of previous comparisons? > > I am not saying these modes should not be enabled. You know much > better. I just wanted to point that that integer comparisons is what > we should be handling. > > Your example: > > _1 = x_8(D) == 21; > _2 = x_8(D) == 64; > _3 = _1 | _2; > if (_3 != 0) > > raises another point. Most likely we don't want to see speculative > comparisons. At least not yet (we will see them once we get through > the first comparison). So that may be another reason to enable these > modes (make compiler stick closer to original code). Wait, it is not speculative in this case as branch is on _1 | _2. But still, it just makes it harder for fuzzer to get through as it needs to guess both values at the same time rather then doing incremental progress.
Re: Add support to trace comparison instructions and switch statements
On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: > On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >> What we instrument in LLVM is _comparisons_ rather than control >> structures. So that would be: >> _4 = x_8(D) == 98; >> For example, result of the comparison can be stored into a bool struct >> field, and then used in branching long time after. We still want to >> intercept this comparison. > > Then we need to instrument not just GIMPLE_COND, which is the stmt > where the comparison decides to which of the two basic block successors to > jump, but also GIMPLE_ASSIGN with tcc_comparison class > gimple_assign_rhs_code (the comparison above), and maybe also > GIMPLE_ASSIGN with COND_EXPR comparison code (that is say > _4 = x_1 == y_2 ? 23 : _3; > ). > >> > Perhaps for -fsanitize-coverage= it might be a good idea to force >> > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE >> > decisions mentioned above so that the IL is closer to what the user wrote. >> >> If we recurse down to comparison operations and instrument them, this >> will not be so important, right? > > Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_COND, > then you don't handle many comparisons from the source code. And if you > handle both, some of the GIMPLE_CONDs might be just artificial comparisons. > By pretending small branch cost for the tracing case you get fewer > artificial comparisons. Are these artificial comparisons on BOOLEAN_TYPE? I think BOOLEAN_TYPE needs to be ignored entirely, there is just like 2 combinations of possible values. If not, then what it is? Is it a dup of previous comparisons? I am not saying these modes should not be enabled. You know much better. I just wanted to point that that integer comparisons is what we should be handling. Your example: _1 = x_8(D) == 21; _2 = x_8(D) == 64; _3 = _1 | _2; if (_3 != 0) raises another point. Most likely we don't want to see speculative comparisons. At least not yet (we will see them once we get through the first comparison). So that may be another reason to enable these modes (make compiler stick closer to original code).
Re: Add support to trace comparison instructions and switch statements
On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: > What we instrument in LLVM is _comparisons_ rather than control > structures. So that would be: > _4 = x_8(D) == 98; > For example, result of the comparison can be stored into a bool struct > field, and then used in branching long time after. We still want to > intercept this comparison. Then we need to instrument not just GIMPLE_COND, which is the stmt where the comparison decides to which of the two basic block successors to jump, but also GIMPLE_ASSIGN with tcc_comparison class gimple_assign_rhs_code (the comparison above), and maybe also GIMPLE_ASSIGN with COND_EXPR comparison code (that is say _4 = x_1 == y_2 ? 23 : _3; ). > > Perhaps for -fsanitize-coverage= it might be a good idea to force > > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE > > decisions mentioned above so that the IL is closer to what the user wrote. > > If we recurse down to comparison operations and instrument them, this > will not be so important, right? Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_COND, then you don't handle many comparisons from the source code. And if you handle both, some of the GIMPLE_CONDs might be just artificial comparisons. By pretending small branch cost for the tracing case you get fewer artificial comparisons. Jakub
Re: Add support to trace comparison instructions and switch statements
On Fri, Sep 1, 2017 at 6:23 PM, Jakub Jelinek wrote:
> On Fri, Jul 21, 2017 at 01:38:17PM +0800, 吴潍浠(此彼) wrote:
>> Hi Jeff
>>
>> I have signed the copyright assignment, and used the name 'Wish Wu' .
>> Should I send you a copy of my assignment ?
>>
>> The attachment is my new patch with small changes.
>> Codes are checked by ./contrib/check_GNU_style.sh, except some special files.
>
> Please provide a ChangeLog entry, you can use ./contrib/mklog as a start.
>
> @@ -975,6 +974,10 @@ fsanitize=
> Common Driver Report Joined
> Select what to sanitize.
>
> +fsanitize-coverage=
> +Common Driver Report Joined
> +Select what to coverage sanitize.
> +
>
> Why Driver? The reason fsanitize= needs it is that say for
> -fsanitize=address we add libraries in the driver, etc., but that
> isn't the case for the coverage, right?
Yes, there is no compiler-provided library that provides
implementation of the emitted instrumentation. User is meant to
provide them (or, use a third-party fuzzer that provides them).
> --- gcc/flag-types.h(revision 250199)
> +++ gcc/flag-types.h(working copy)
> @@ -250,6 +250,14 @@ enum sanitize_code {
> | SANITIZE_BOUNDS_STRICT
> };
>
> +/* Different trace modes. */
> +enum sanitize_coverage_code {
> + /* Trace PC. */
> + SANITIZE_COV_TRACE_PC = 1UL << 0,
> + /* Trace Compare. */
> + SANITIZE_COV_TRACE_CMP = 1UL << 1
> +};
>
> No need for UL suffixes, the reason sanitize_code uses them is
> that it includes 1 << 16 and above and might be included even in target code
> (for host we require 32-bit integers, for target code it might be just
> 16-bit).
>
> --- gcc/opts.c (revision 250199)
> +++ gcc/opts.c (working copy)
> @@ -1519,6 +1519,17 @@ const struct sanitizer_opts_s sanitizer_opts[] =
>{ NULL, 0U, 0UL, false }
> };
>
> +/* -f{,no-}sanitize-coverage= suboptions. */
> +const struct sanitizer_opts_s coverage_sanitizer_opts[] =
> +{
> +#define SANITIZER_OPT(name, flags, recover) \
> +{ #name, flags, sizeof #name - 1, recover }
> + SANITIZER_OPT (trace-pc, SANITIZE_COV_TRACE_PC, false),
> + SANITIZER_OPT (trace-cmp, SANITIZE_COV_TRACE_CMP, false),
> +#undef SANITIZER_OPT
> + { NULL, 0U, 0UL, false }
>
> No need to have the recover argument for the macro, just add false to it
> (unless you want to use a different struct type that wouldn't even include
> that member).
>
> +/* Given ARG, an unrecognized coverage sanitizer option, return the best
> + matching coverage sanitizer option, or NULL if there isn't one. */
> +
> +static const char *
> +get_closest_coverage_sanitizer_option (const string_fragment &arg)
> +{
> + best_match bm (arg);
> + for (int i = 0; coverage_sanitizer_opts[i].name != NULL; ++i)
> +{
> + bm.consider (coverage_sanitizer_opts[i].name);
> +}
>
> Body which contains just one line shouldn't be wrapped in {}s, just use
> for (int i = 0; coverage_sanitizer_opts[i].name != NULL; ++i)
> bm.consider (coverage_sanitizer_opts[i].name);
>
> +unsigned int
> +parse_coverage_sanitizer_options (const char *p, location_t loc,
> +unsigned int flags, int value, bool complain)
>
> Wrong formatting, unsigned int should go below const char *, like:
>
> parse_coverage_sanitizer_options (const char *p, location_t loc,
> unsigned int flags, int value, bool
> complain)
>
> +{
> + while (*p != 0)
> +{
> + size_t len, i;
> + bool found = false;
> + const char *comma = strchr (p, ',');
> +
> + if (comma == NULL)
> + len = strlen (p);
> + else
> + len = comma - p;
> + if (len == 0)
> + {
> + p = comma + 1;
> + continue;
> + }
> +
> + /* Check to see if the string matches an option class name. */
> + for (i = 0; coverage_sanitizer_opts[i].name != NULL; ++i)
> + if (len == coverage_sanitizer_opts[i].len
> + && memcmp (p, coverage_sanitizer_opts[i].name, len) == 0)
> + {
> + if (value)
> + flags |= coverage_sanitizer_opts[i].flag;
> + else
> + flags &= ~coverage_sanitizer_opts[i].flag;
> + found = true;
> + break;
> + }
> +
> + if (! found && complain)
> + {
> + const char *hint
> + = get_closest_coverage_sanitizer_option (string_fragment (p,
> len));
> +
> + if (hint)
> + error_at (loc,
> + "unrecognized argument to "
> + "-f%ssanitize-coverage= option: %q.*s;"
> + " did you mean %qs?",
> + value ? "" : "no-",
> + (int) len, p, hint);
> + else
> + error_at (loc,
> + "unrecognized argument to "
> + "-f%ssanitize-coverage= option: %q.*s",
> + value ? "" : "no-",
> + (int) len, p);
> + }
> +
> + if (comma == NULL)
> +
