[PATCH] Fix UB in hash-map.h
bootstrap-ubsan shows:
gcc/hash-map.h:277:19: runtime error: member access within null pointer of
type 'struct hash_map'
Fix the issue by returning early.
bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le.
OK for trunk?
gcc/
* hash-map.h (gt_cleare_cache): Avoid UB.
diff --git a/gcc/hash-map.h b/gcc/hash-map.h
index 6b8365a9d0a6..e5630338491a 100644
--- a/gcc/hash-map.h
+++ b/gcc/hash-map.h
@@ -274,6 +274,8 @@ template
static inline void
gt_cleare_cache (hash_map *h)
{
+ if (!h)
+return;
gt_cleare_cache (&h->m_table);
}
--
Markus
[PATCH] Fix PR82488 - signed integer overflow in expr.c
bootstrap-ubsan shows: gcc/expr.c:4103:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int' Fix by handling the saw_unknown case earlier. bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le. OK for trunk? PR rtl-optimization/82488 * expr.c (fixup_args_size_notes): Avoid signed integer overflow. diff --git a/gcc/expr.c b/gcc/expr.c index ee07de5aaa44..e9d8555c9452 100644 --- a/gcc/expr.c +++ b/gcc/expr.c @@ -4100,10 +4100,13 @@ fixup_args_size_notes (rtx_insn *prev, rtx_insn *last, int end_args_size) if (STACK_GROWS_DOWNWARD) this_delta = -(unsigned HOST_WIDE_INT) this_delta; - args_size -= this_delta; + if (saw_unknown) + args_size = INT_MIN; + else + args_size -= this_delta; } - return saw_unknown ? INT_MIN : args_size; + return args_size; } #ifdef PUSH_ROUNDING -- Markus
[wwwdocs] bugs/management.html: add a link, streamline a bit
Looking for something Jonathan pointed out, I noticed (again) that our language is a bit verbose around our bug reporting / management instructions. Applied Gerald Add a link to our bug reporting instructions. Trim some language. Index: management.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v retrieving revision 1.32 diff -u -r1.32 management.html --- management.html 3 Mar 2017 16:20:01 - 1.32 +++ management.html 26 Nov 2017 10:03:03 - @@ -14,9 +14,8 @@ If you find a bug, but you are not fixing it (yet): -Create a (minimal) testcase and file a bug report including it to -our bug tracker. -Enter the version number of the compiler in the Known To +Create a (minimal) testcase and file a bug report. +Enter the version number of GCC in the Known To Fail field. If you are reporting the bug against a release branch, or the trunk, enter the version number of the next planned release from that branch.
Re: [PATCH][GCC][ARM] Dot Product NEON intrinsics [Patch (3/8)]
On 24 November 2017 at 20:38, Christophe Lyon wrote: > On 24 November 2017 at 19:05, Tamar Christina wrote: >> Hi Christophe, >> >>> >>> After your commit, I have these reports: >>> http://people.linaro.org/~christophe.lyon/cross- >>> validation/gcc/trunk/255064/report-build-info.html >>> >>> After my commit, I have these reports: >>> http://people.linaro.org/~christophe.lyon/cross- >>> validation/gcc/trunk/255126/report-build-info.html >>> >>> I haven't fully checked that my patch fixes all the regressions reported at >>> r255064, but I don't see why my patch would introduce regressions So I >>> think your patch is causing problems: >>> * on armeb --with-fpu=neon-fp16: (the 2 "REGRESSED" entries): >>> gcc.target/arm/attr-neon3.c scan-assembler-times vld1 1 (found 2 times) >>> gcc.target/arm/neon-vfma-1.c scan-assembler vfma\\.f32[\t]+[dDqQ] >>> gcc.target/arm/neon-vfms-1.c scan-assembler vfms\\.f32[\t]+[dDqQ] >>> >>> * on arm-none-linux-gnueabihf --with-cpu cortex-a5 --with-fpu vfpv3-d16- >>> fp16 and armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu vfpv3- >>> d16-fp16 (the 2 "BIG-REGR" entries) >> >> This patch only introduced a few neon instrinsics in arm_neon.h, and most of >> these files don't use the header. >> >> gcc.dg/vect/pr65947-14.c doesn't exist in my tree so it's a relatively new >> test. >> >> I will run some regressions over the weekend on an updated tree, but I can't >> understand how a not included header it can cause execution failures 😊 >> However most of those are vectorizer tests. It seems much more likely to me >> that vectorization is broken rather. > > Agreed. But note that many regressions are reported for the > configurations --with-fpu vfpv3-d16-fp16 > at: > http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/255064/report-build-info.html > Maybe that's just a matter of arm_neon.h being included by some > effective-target tests? > > Hi Tamar, Good news, I have confirmed your obvious thoughts: I have run validations of r255063+your patch fixed, and the results are clean: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/255063-r255064-fixed.patch/report-build-info.html I have also compared r255063 to r255216 (that is I applied all patches between yours and mine): http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/255063-r255063-255126.patch/report-build-info.html which confirms some regressions have been introduced in-between, hidden by the problem in your patch. Some may be obvious to bisect, some less. Christophe >> >> Thanks, >> Tamar >> >>> where a few tests fail: >>> (arm-none-linux-gnueabihf cortex-a5 vfpv3-d16-fp16): >>> gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/pr65947-14.c execution test >>> >>> (armeb-none-linux-gnueabihf cortex-a9 vfpv3-d16-fp16): >>> Executed from: gcc.dg/vect/vect.exp >>> gcc.dg/vect/pr51074.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/pr51074.c execution test >>> gcc.dg/vect/pr64252.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/pr65947-14.c execution test >>> gcc.dg/vect/vect-cond-4.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/vect-nb-iter-ub-2.c execution test >>> gcc.dg/vect/vect-nb-iter-ub-3.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/vect-nb-iter-ub-3.c execution test >>> gcc.dg/vect/vect-strided-shift-1.c -flto -ffat-lto-objects execution >>> test >>> gcc.dg/vect/vect-strided-shift-1.c execution test >>> gcc.dg/vect/vect-strided-u16-i3.c -flto -ffat-lto-objects execution test >>> gcc.dg/vect/vect-strided-u16-i3.c execution test >>> Executed from: gcc.target/arm/arm.exp >>> gcc.target/arm/attr-neon3.c scan-assembler-times vld1 1 (found 2 times) >>> gcc.target/arm/neon-vfma-1.c scan-assembler vfma\\.f32[\t]+[dDqQ] >>> gcc.target/arm/neon-vfms-1.c scan-assembler vfms\\.f32[\t]+[dDqQ] >>> gcc.target/arm/neon-vmla-1.c scan-assembler vmla\\.i32 >>> gcc.target/arm/neon-vmls-1.c scan-assembler vmls\\.i32 >>> gcc.target/arm/vect-copysignf.c scan-tree-dump-times vect "vectorized 1 >>> loops" 1 (found 0 times) >>> >>> I haven't checked whether this tests were already failing before your patch, >>> and are just reported as new failures because they failed to compile in the >>> mean time. >>> >>> Not sure I am clear :-) >>> >>> Sorry for the delay and potentially hard to parse reports, I'm struggling >>> with >>> infrastructure problems. >>> >>> Thanks, >>> >>> Christophe >>> >>> > Tamar >>> > >>> >> >>> >> Fixed as obvious (r255126). >>> >> >>> >> Christophe >>> >> >>> >> > diff --git a/gcc/testsuite/gcc.target/arm/simd/vect-dot-qi.h >>> >> > b/gcc/testsuite/gcc.target/arm/simd/vect-dot-qi.h >>> >> > new file mode 100644 >>> >> > index >>> >> > >>> >> >>> ..90b00aff95cfef96
Re: [PING] Plugin support on Windows/MinGW
On 11/23/2017 11:34 AM, JonY wrote: > On 11/22/2017 11:14 AM, Boris Kolpackov wrote: >> JonY <10wa...@gmail.com> writes: >> >>> Is there a problem with using .so for internal libraries instead of >>> "dll"... >> >> I think not but I haven't tested it. The problem with using .so instead >> of .dll is that producing this non-standard extension may not be easy >> or possible depending on the build system/tool (e.g., libtool). Also, >> you never know how other pieces of the system (like antivirus) will >> react to a file that looks like a DLL but is called something else. >> >> > > Libtool shouldn't matter since it is not used to build those, and I > doubt AVs would care what the filename is called. Apache on Windows uses > .so plugins too. > >>> ... if it simplifies the code? >> >> I don't think it simplifies that much and the potential (and unknown) >> downside is significant. >> >> Thanks for the review, >> Boris >> > > I'll commit in a few days if there are no more inputs. > Applied to trunk r255154. signature.asc Description: OpenPGP digital signature
(patch, fortran] PR83021 - [7/8 Regression] gfortran segfault in polymorphic assignment
Dear All, This regression was caused by the patch for PR81447. The chunk that has been modified came about because use association of derived types in block data, in the presence of a vtable, was trying to add vtable procedures, which is not allowed. The original patch did not explicitly target block data and this is fixed here. I decided that a testcase was not necessary but this could be done if desired. Bootstrapped and regtested on FC23/x86_64 - OK for both branches? I will commit tomorrow morning if there are no complaints. Best regards Paul 2017-11-26 Paul Thomas PR fortran/83021 * resolve.c (resolve_component): Only escape for use assciated vtypes if the current namespace has no proc_name and is most particularly block data. Index: gcc/fortran/resolve.c === *** gcc/fortran/resolve.c (revision 255093) --- gcc/fortran/resolve.c (working copy) *** resolve_component (gfc_component *c, gfc *** 13502,13508 if (c->attr.artificial) return true; ! if (sym->attr.vtype && sym->attr.use_assoc) return true; /* F2008, C442. */ --- 13502,13512 if (c->attr.artificial) return true; ! /* Do not allow vtype components to be resolved in nameless namespaces ! such as block data because the procedure pointers will cause ICEs ! and vtables are not needed in these contexts. */ ! if (sym->attr.vtype && sym->attr.use_assoc ! && sym->ns->proc_name == NULL) return true; /* F2008, C442. */
Re: [PATCH][GCC][ARM] Dot Product NEON intrinsics [Patch (3/8)]
On 26 November 2017 at 13:56, Christophe Lyon wrote: > On 24 November 2017 at 20:38, Christophe Lyon > wrote: >> On 24 November 2017 at 19:05, Tamar Christina >> wrote: >>> Hi Christophe, >>> After your commit, I have these reports: http://people.linaro.org/~christophe.lyon/cross- validation/gcc/trunk/255064/report-build-info.html After my commit, I have these reports: http://people.linaro.org/~christophe.lyon/cross- validation/gcc/trunk/255126/report-build-info.html I haven't fully checked that my patch fixes all the regressions reported at r255064, but I don't see why my patch would introduce regressions So I think your patch is causing problems: * on armeb --with-fpu=neon-fp16: (the 2 "REGRESSED" entries): gcc.target/arm/attr-neon3.c scan-assembler-times vld1 1 (found 2 times) gcc.target/arm/neon-vfma-1.c scan-assembler vfma\\.f32[\t]+[dDqQ] gcc.target/arm/neon-vfms-1.c scan-assembler vfms\\.f32[\t]+[dDqQ] * on arm-none-linux-gnueabihf --with-cpu cortex-a5 --with-fpu vfpv3-d16- fp16 and armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu vfpv3- d16-fp16 (the 2 "BIG-REGR" entries) >>> >>> This patch only introduced a few neon instrinsics in arm_neon.h, and most >>> of these files don't use the header. >>> >>> gcc.dg/vect/pr65947-14.c doesn't exist in my tree so it's a relatively new >>> test. >>> >>> I will run some regressions over the weekend on an updated tree, but I >>> can't understand how a not included header it can cause execution failures 😊 >>> However most of those are vectorizer tests. It seems much more likely to me >>> that vectorization is broken rather. >> >> Agreed. But note that many regressions are reported for the >> configurations --with-fpu vfpv3-d16-fp16 >> at: >> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/255064/report-build-info.html >> Maybe that's just a matter of arm_neon.h being included by some >> effective-target tests? >> >> > Hi Tamar, > > Good news, I have confirmed your obvious thoughts: I have run > validations of r255063+your patch fixed, and the results are clean: > http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/255063-r255064-fixed.patch/report-build-info.html > > I have also compared r255063 to r255216 (that is I applied all patches > between yours and mine): > http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/255063-r255063-255126.patch/report-build-info.html > which confirms some regressions have been introduced in-between, > hidden by the problem in your patch. > > Some may be obvious to bisect, some less. > OK, so for gcc: FAIL: gcc.dg/ipa/inline-1.c scan-ipa-dump inline "op2 change 9.99. of time" after r255103, which updated the test several failures for gcc.target/arm/addr-modes-float.c which was introduced at r255111 (Charles is aware of that, probably just a matter of adding the right effective-target) I'm still trying to reproduce the regression: FAIL: gcc.dg/vect/vect-nb-iter-ub-2.c execution test on armeb and for g++: g++.dg/ipa/devirt-22.C -std=gnu++11 scan-ipa-dump-times cp "Discovered a virtual call to a known target" 1 (found 2 times) g++.dg/ipa/devirt-22.C -std=gnu++14 scan-ipa-dump-times cp "Discovered a virtual call to a known target" 1 (found 2 times) g++.dg/ipa/devirt-22.C -std=gnu++98 scan-ipa-dump-times cp "Discovered a virtual call to a known target" 1 (found 2 times) g++.dg/pr79095-4.C -std=gnu++98 scan-tree-dump-times vrp2 "__builtin_memset \\(_[0-9]+, 0, [0-9]+\\)" 1 (found 0 times) g++.dg/pr79095-4.C -std=gnu++98 (test for warnings, line ) Christophe > Christophe > >>> >>> Thanks, >>> Tamar >>> where a few tests fail: (arm-none-linux-gnueabihf cortex-a5 vfpv3-d16-fp16): gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects execution test gcc.dg/vect/pr65947-14.c execution test (armeb-none-linux-gnueabihf cortex-a9 vfpv3-d16-fp16): Executed from: gcc.dg/vect/vect.exp gcc.dg/vect/pr51074.c -flto -ffat-lto-objects execution test gcc.dg/vect/pr51074.c execution test gcc.dg/vect/pr64252.c -flto -ffat-lto-objects execution test gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects execution test gcc.dg/vect/pr65947-14.c execution test gcc.dg/vect/vect-cond-4.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-nb-iter-ub-2.c execution test gcc.dg/vect/vect-nb-iter-ub-3.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-nb-iter-ub-3.c execution test gcc.dg/vect/vect-strided-shift-1.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-strided-shift-1.c execution test gcc.dg/vect/vect-strided-u16-i3.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-strided-u16-i3.c execution test Executed from: gcc.target/arm/arm.exp g
[i386] PR83109 [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet
According to the description of inssp instruction from Intel CET it adusts the
shadow stack pointer (ssp) only by value in the range of [0..255]. As a number
of adjustment could be greater than 255 there should be a loop generated to
adjust ssp.
gcc/
* config/i386/i386.md: Add a loop with incssp.
* testsuite/gcc.target/i386/cet-sjlj-1.c: Fix test.
* testsuite/gcc.target/i386/cet-sjlj-4.c: Likewise.
---
gcc/config/i386/i386.md| 81 +++---
gcc/testsuite/gcc.target/i386/cet-sjlj-1.c | 2 +-
gcc/testsuite/gcc.target/i386/cet-sjlj-4.c | 2 +-
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b871590..a14efc8 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -18394,15 +18394,16 @@
"TARGET_SHSTK"
{
rtx fp, lab, stack;
- rtx jump, label, reg_adj, reg_ssp, reg_minus, mem_buf, tmp, clob;
+ rtx flags, jump, noadj_label, inc_label, loop_label;
+ rtx reg_adj, reg_ssp, mem_buf, tmp, clob;
machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
/* Adjust the shadow stack pointer (ssp) to the value saved in the
jmp_buf. The saving was done in the builtin_setjmp_setup. */
if (flag_cf_protection & CF_RETURN)
{
- /* Get current shadow stack pointer. The code below will check if
- SHSTK feature is enabled. If it's not enabled RDSSP instruction
+ /* Get the current shadow stack pointer. The code below will check if
+ SHSTK feature is enabled. If it is not enabled the RDSSP
instruction
is a NOP. */
reg_ssp = gen_reg_rtx (Pmode);
emit_insn (gen_rtx_SET (reg_ssp, const0_rtx));
@@ -18410,40 +18411,84 @@
? gen_rdsspsi (reg_ssp, reg_ssp)
: gen_rdsspdi (reg_ssp, reg_ssp));
mem_buf = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0],
-
3 * GET_MODE_SIZE (Pmode))),
+
3 * GET_MODE_SIZE (Pmode)));
/* Compare through substraction the saved and the current ssp to decide
if ssp has to be adjusted. */
- reg_minus = gen_reg_rtx (Pmode);
- tmp = gen_rtx_SET (reg_minus, gen_rtx_MINUS (Pmode, reg_ssp, mem_buf));
+ reg_adj = gen_reg_rtx (Pmode);
+ tmp = gen_rtx_SET (reg_adj, gen_rtx_MINUS (Pmode, reg_ssp, mem_buf));
clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
emit_insn (tmp);
- /* Jump over adjustment code. */
- label = gen_label_rtx ();
- tmp = gen_rtx_REG (CCmode, FLAGS_REG);
- tmp = gen_rtx_EQ (VOIDmode, tmp, const0_rtx);
+ /* Compare and jump over adjustment code. */
+ noadj_label = gen_label_rtx ();
+ flags = gen_rtx_REG (CCZmode, FLAGS_REG);
+ tmp = gen_rtx_EQ (VOIDmode, flags, const0_rtx);
tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
-
gen_rtx_LABEL_REF (VOIDmode, label),
+
gen_rtx_LABEL_REF (VOIDmode, noadj_label),
pc_rtx);
jump = emit_jump_insn (gen_rtx_SET (pc_rtx, tmp));
- JUMP_LABEL (jump) = label;
+ JUMP_LABEL (jump) = noadj_label;
- /* Adjust the ssp. */
- reg_adj = gen_reg_rtx (Pmode);
+ /* Compute the numebr of frames to adjust. */
tmp = gen_rtx_SET (reg_adj,
- gen_rtx_LSHIFTRT (Pmode,
negate_rtx (Pmode, reg_minus),
-
GEN_INT (3)));
+ gen_rtx_LSHIFTRT (Pmode,
negate_rtx (Pmode, reg_adj),
+
GEN_INT ((Pmode == SImode)
+
? 2
+
: 3)));
clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
emit_insn (tmp);
+
+ /* Check if number of frames <= 255 so no loop is needed. */
+ tmp = gen_rtx_COMPARE (CCmode, reg_adj, GEN_INT (255));
+ flags = gen_rtx_REG (CCmode, FLAGS_REG);
+ emit_insn (gen_rtx_SET (flags, tmp));
+
+ inc_label = gen_label_rtx ();
+ tmp = gen_rtx_LEU (VOIDmode, flags, const0_rtx);
+ tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
+
gen_rtx_LABEL_REF (VOIDmode, inc_label),
+
Re: [PATCH] Fix hot/cold partitioning with -gstabs{,+} (PR debug/81307)
On 11/24/2017 02:53 PM, Jakub Jelinek wrote:
> Hi!
>
> On most targets, N_SLINE has addresses relative to the start of
> the function, which means -gstabs{,+} is completely broken with
> hot/cold partitioning (fails to assemble almost anything that
> has both partitions). This used to be bearable when it wasn't
> the default, but now that we hot/cold partition by default it means
> STABS is completely unusable.
>
> Because STABS should die soon, I'm not trying to propose any extension,
> just emit something that assemble and be tolerable for debugging purposes
> (after all, debugging optimized code with stabs isn't really a good idea
> because it doesn't handle block fragments anyway).
>
> What the patch does is that it treats hot/cold partitioned functions
> basically as two functions, say main and main.cold.1, in the hot partition
> everything should be normal, except that lexical scopes that only appear in
> cold partition are not emitted in the [lr]brac tree for the hot partition.
> Then the cold partition is yet another N_FUN, set of N_SLINE relative to
> the start of the cold partition, and finally another [lr]brac block tree.
> This one doesn't include any lexical scopes that are solely in the hot
> partition, but we can have scopes that are in both, those are duplicated,
> sometimes with merged vars from multiple scopes.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Could anybody from the debugger folks test it a little bit (say gdb
> testsuite if it has any -O2 -gstabs/-O2 -gstabs+ tests)?
>
> 2017-11-24 Jakub Jelinek
>
> PR debug/81307
> * dbxout.c (lastlineno): New variable.
> (dbx_debug_hooks): Use dbxout_switch_text_section as
> switch_text_section debug hook.
> (dbxout_function_end): Switch to current_function_section
> rather than function_section. If crtl->has_bb_partition,
> output just one N_FUN, depending on in_cold_section_p.
> (dbxout_source_line): Remember last lineno in lastlineno.
> (dbxout_switch_text_section): New function.
> (dbxout_function_decl): Adjust dbxout_block caller.
> (dbx_block_with_cold_children): New function.
> (dbxout_block): Return true if any LBRAC/RBRAC have been
> emitted. Use dbx_block_with_cold_children at depth == 0
> in second partition. Add PARENT_BLOCKNUM argument, pass
> it optionally adjusted to children. Output LBRAC/RBRAC
> around recursive call only if the block is in the current
> partition, if not and anything was output, emit empty
> range LBRAC/RBRAC.
> * final.c (final_scan_insn): Compute cold_function_name
> before calling switch_text_section debug hook. Call
> that hook even if dwarf2out_do_frame if not emitting
> dwarf debug info.
Alternately, just issue a warning that -gstabs isn't supported when
hot/cold partitioning is enabled. I'm just not sure it's worth the
headache to bother making this even limp along.
No objection if you want to go ahead with your patch, you've already
done the work, but fixing bugs in stabs support, e.
Jeff
Re: [PATCH, Makefile.in] refine selftest recipes to restore mingw bootstrap
On 11/24/2017 11:18 AM, Olivier Hainque wrote: > Hello, > > Bootstrap for mingw target configurations is failing today, with complaints > about an inexistant /dev/null. > > The failing commands are issued by the selftest recipes in gcc/Makefile, > using: > > SELFTEST_FLAGS = -nostdinc /dev/null -S -o /dev/null \ > -fself-test=$(srcdir)/testsuite/selftests > > The attached patch is a proposal to fix this by resorting to "nul" instead of > "/dev/null" when the build machine name indicates a mingw setup. > > It fixes the gcc-7 bootstrap in our Windows setup (i686-pc-mingw32), and > passes > bootstrap and regression tests on x86_64-linux. > > OK to commit ? > > Thanks much in advance, > > With Kind Regards, > > Olivier > > 2017-11-24 Olivier Hainque > > * Makefile.in (SELFTEST_FLAGS): Use nul instead of /dev/null > on mingw build hosts. Would it make more sense to set the output file to HOST_BIT_BUCKET when -fselftest is active? Jeff
Re: [PATCH] Fix PR82488 - signed integer overflow in expr.c
On 11/26/2017 02:12 AM, Markus Trippelsdorf wrote: > bootstrap-ubsan shows: > gcc/expr.c:4103:17: runtime error: signed integer overflow: 0 - > -9223372036854775808 cannot be represented in type 'long int' > > Fix by handling the saw_unknown case earlier. > > bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le. > > OK for trunk? > > PR rtl-optimization/82488 > * expr.c (fixup_args_size_notes): Avoid signed integer overflow. OK. jeff
