[Bug target/93533] [10 Regression] ICE due to popcounthi2 expansion with -march=z196 since r10-3720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93533 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f626ae5478887b0cec886160dcfc4d59bf6fda07 commit r10-6400-gf626ae5478887b0cec886160dcfc4d59bf6fda07 Author: Jakub Jelinek Date: Mon Feb 3 09:00:19 2020 +0100 s390x: Fix popcounthi2_z196 expander [PR93533] The following testcase started to ICE when .POPCOUNT matching has been added to match.pd; we had __builtin_popcount*, but nothing would use the popcounthi2 expander before. The problem is that the popcounthi2_z196 expander doesn't emit valid RTL: error: unrecognizable insn: (insn 138 137 139 27 (set (reg:SI 190) (ashift:SI (reg:HI 95 [ _105 ]) (const_int 8 [0x8]))) -1 (nil)) during RTL pass: vregs The following patch is an attempt to fix that, furthermore I've tried to slightly simplify it as well, it makes no sense to me to perform (x + (x << 8)) >> 8 when we need to either zero extend or mask the result at the end in order to avoid bits from above HImode to affect it, when we can do (x + (x >> 8)) & 0xff (or zero extension). 2020-02-03 Jakub Jelinek PR target/93533 * config/s390/s390.md (popcounthi2_z196): Fix up expander to emit valid RTL to sum up the lowest and second lowest bytes of the popcnt result. * gcc.c-torture/compile/pr93533.c: New test. * gcc.target/s390/pr93533.c: New test.
[Bug analyzer/93547] ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93547 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-5950-g757bf1dff5e8cee3.
[Bug analyzer/93546] ICE: Segmentation fault (in ana::region_model::add_region_for_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93546 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-5950-g757bf1dff5e8cee3.
[Bug libgomp/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844 --- Comment #3 from Tobias Burnus --- Our nightly tests have: PASS on 2020-01-29 FAIL on 2020-01-30, 2020-01-31 PASS on 2020-02-01, 2020-02-02 (I couldn't find older data.) — Hence, it looks also like intermittent failures. Still, I think/hope Jakub's fix for PR 92305 is the only needed patch. Can you re-check whether you are still getting this?
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-5950-g757bf1dff5e8cee3.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-03 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Known to work||9.2.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-6294-g3d056cbfb3484f40.
[Bug analyzer/93543] [10 regression] bootstrap with clang 9.0.1 fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/93533] [10 Regression] ICE due to popcounthi2 expansion with -march=z196 since r10-3720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93533 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Ditto: __has_include (
[Bug fortran/93427] [10 Regression] Rejects valid with pointer result from recursive function since r10-5722-g4d124378848e82e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93427 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:ae86ede8e988d1863b92a19f35d5f7c6b998bf8c commit r10-6401-gae86ede8e988d1863b92a19f35d5f7c6b998bf8c Author: Tobias Burnus Date: Mon Feb 3 10:00:07 2020 +0100 [Fortran] Fix to strict associate check (PR93427) PR fortran/93427 * resolve.c (resolve_assoc_var): Remove too strict check. * gfortran.dg/associate_51.f90: Update test case. PR fortran/93427 * gfortran.dg/associate_52.f90: New.
[Bug fortran/93541] OpenMP module description incomplete in gcc/fortran/intrinsic.texi – missing PARAMETER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93541 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:7c8e1f920a7f85fcf7b69072926a7b6e0a7e49c5 commit r10-6402-g7c8e1f920a7f85fcf7b69072926a7b6e0a7e49c5 Author: Tobias Burnus Date: Mon Feb 3 10:02:47 2020 +0100 [OpenMP] Add missing parameters to omp_lib documentation (PR fortran/93541) PR fortran/93541 * intrinisic.texi (OpenMP Modules OMP_LIB and OMP_LIB_KINDS): Add undocumented parameters from omp_lib.f90.in.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545 --- Comment #3 from Arseny Solokha --- I forgot to mention that the testcase was reduced from test/Preprocessor/has_include.c from the clang 9.0.1 test suite. Maybe gcc needs something similar in terms of completeness? There's gcc/testsuite/c-c++-common/cpp/pr88974.c already.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545 --- Comment #4 from Jakub Jelinek --- __has_attribute doesn't ICE though. The difference is that it is using get_token_no_padding (c-family version), which first tries to use cpp_peek_token and doesn't swallow CPP_EOF.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|--- |10.0
--- Comment #5 from Jakub Jelinek ---
--- libcpp/macro.c.jj 2020-01-31 19:17:47.377126121 +0100
+++ libcpp/macro.c 2020-02-03 10:14:42.447621094 +0100
@@ -336,6 +336,22 @@ unsigned num_expanded_macros_counter = 0
from macro expansion. */
unsigned num_macro_tokens_counter = 0;
+/* Wrapper around cpp_get_token to skip CPP_PADDING tokens
+ and not consume CPP_EOF. */
+static const cpp_token *
+cpp_get_token_no_padding (cpp_reader *pfile)
+{
+ for (;;)
+{
+ const cpp_token *ret = cpp_peek_token (pfile, 0);
+ if (ret->type == CPP_EOF)
+ return ret;
+ ret = cpp_get_token (pfile);
+ if (ret->type != CPP_PADDING)
+ return ret;
+}
+}
+
/* Handle meeting "__has_include" builtin macro. */
static int
@@ -344,10 +360,10 @@ builtin_has_include (cpp_reader *pfile,
int result = 0;
pfile->state.angled_headers = true;
- const cpp_token *token = cpp_get_token (pfile);
+ const cpp_token *token = cpp_get_token_no_padding (pfile);
bool paren = token->type == CPP_OPEN_PAREN;
if (paren)
-token = cpp_get_token (pfile);
+token = cpp_get_token_no_padding (pfile);
else
cpp_error (pfile, CPP_DL_ERROR,
"missing '(' before \"%s\" operand", NODE_NAME (op));
@@ -379,7 +395,8 @@ builtin_has_include (cpp_reader *pfile,
XDELETEVEC (fname);
}
- if (paren && !SEEN_EOL () && cpp_get_token (pfile)->type != CPP_CLOSE_PAREN)
+ if (paren
+ && cpp_get_token_no_padding (pfile)->type != CPP_CLOSE_PAREN)
cpp_error (pfile, CPP_DL_ERROR,
"missing ')' after \"%s\" operand", NODE_NAME (op));
seems to work, will add some testsuite coverage.
[Bug fortran/93427] [10 Regression] Rejects valid with pointer result from recursive function since r10-5722-g4d124378848e82e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93427 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED for GCC 10. Thanks for the follow-up bug report and thanks for your recent patches and bugreports.
[Bug rtl-optimization/91333] [9/10 Regression] suboptimal register allocation for inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333 --- Comment #13 from Christophe Lyon --- (In reply to Vladimir Makarov from comment #12) > (In reply to Christophe Lyon from comment #10) > > (In reply to Jeffrey A. Law from comment #9) > > > Fixed by Vlad's patch on the trunk. > > > > This patch causes regressions: > > aarch64: > > > > I've committed one more patch which improves the PR test code (although one > move could be avoided is still present), does not worsen SPEC benchmark and > solves some aarch64 testsuite failures. > > Could you check aarch64 tests again. > > Thank you. Hi, So the patch from comment #c7 caused 169 regressions on aarch64 (a few of which I reported in #c10). The patch in #c11 fixes 169 cases, including the ones I reported, so I think it does fixes all the regressions from #c7. However, that new patch brings 651 new regressions on aarch64, including: gcc.target/aarch64/sve/acle/asm/abd_s32.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies abd_w0_s32_m_untied gcc.target/aarch64/sve/acle/asm/abd_s32.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies abd_w0_s32_m_untied gcc.target/aarch64/sve/acle/asm/abd_s64.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies abd_x0_s64_m_untied gcc.target/aarch64/sve/acle/asm/abd_s64.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies abd_x0_s64_m_untied gcc.target/aarch64/sve/acle/asm/abd_u32.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies abd_w0_u32_m_untied gcc.target/aarch64/sve/acle/asm/abd_u32.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies abd_w0_u32_m_untied gcc.target/aarch64/sve/acle/asm/abd_u64.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies abd_x0_u64_m_untied gcc.target/aarch64/sve/acle/asm/abd_u64.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies abd_x0_u64_m_untied gcc.target/aarch64/sve/acle/asm/add_s32.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies add_w0_s32_m_untied No need for aarch64 hw, these are compile-tests.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545 --- Comment #6 from Jakub Jelinek --- Created attachment 47766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47766&action=edit gcc10-pr93545.patch Full untested patch.
[Bug rtl-optimization/91333] [9/10 Regression] suboptimal register allocation for inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333 --- Comment #14 from Jakub Jelinek --- I think what matters is whether the new asm for those is the same or better than before. If the tests hardcode particular RA decisions, they'll obviously FAIL when something in the RA changes.
[Bug libgomp/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844 --- Comment #4 from Jakub Jelinek --- My patch certainly changed emitted code on that testcase: @@ -474,8 +474,8 @@ main: mflr 0 std 0,16(1) std 31,-8(1) - stdu 1,-192(1) - .cfi_def_cfa_offset 192 + stdu 1,-256(1) + .cfi_def_cfa_offset 256 .cfi_offset 65, 16 .cfi_offset 31, -8 bl _gfortran_set_args @@ -486,11 +486,11 @@ main: bl _gfortran_set_options nop li 31,0 + std 31,176(1) + std 31,144(1) std 31,112(1) - std 31,80(1) - std 31,48(1) - std 31,40(1) - std 31,32(1) + std 31,104(1) + std 31,96(1) li 10,0 li 9,0 li 8,0 @@ -500,30 +500,30 @@ main: li 4,0 li 3,0 bl foo.2306 - std 31,40(1) - std 31,32(1) + std 31,104(1) + std 31,96(1) li 10,0 li 9,0 li 8,0 li 7,0 li 6,0 - addi 5,1,112 + addi 5,1,176 li 4,0 li 3,0 bl foo.2306 - std 31,40(1) - std 31,32(1) + std 31,104(1) + std 31,96(1) li 10,0 li 9,0 li 8,0 li 7,0 li 6,0 - addi 5,1,48 + addi 5,1,112 li 4,0 li 3,0 bl foo.2306 li 3,0 - addi 1,1,192 + addi 1,1,256 .cfi_def_cfa_offset 0 ld 0,16(1) mtlr 0 so if it was random FAIL in between, we can just wait some time and look at gcc-testresults if it now consistently PASSes.
[Bug target/91816] [8/9/10 Regression] Arm generates out of range conditional branches in Thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816
--- Comment #3 from CVS Commits ---
The master branch has been updated by Stam Markianos-Wright
:
https://gcc.gnu.org/g:44f77a6dea2f312ee1743f3dde465c1b8453ee13
commit r10-6404-g44f77a6dea2f312ee1743f3dde465c1b8453ee13
Author: Stam Markianos-Wright
Date: Mon Feb 3 10:25:46 2020 +
This patch is for PR target/91816
This is a patch for an issue where the compiler was generating a
conditional
branch in Thumb2, which was too far for b{cond} to handle.
This was originally reported at binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=24991
And then raised for GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816
As can be seen here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Cihfddaf.html
the range of a 32-bit Thumb B{cond} is +/-1MB.
This is now checked for in arm.md and an unconditional branch is generated
if
the jump would be greater than 1MB.
gcc/ChangeLog
2020-02-03 Stam Markianos-Wright
PR target/91816
* config/arm/arm-protos.h: New function arm_gen_far_branch prototype.
* config/arm/arm.c (arm_gen_far_branch): New function
arm_gen_far_branch.
* config/arm/arm.md: Update b for Thumb2 range checks.
gcc/testsuite/ChangeLog
2020-02-03 Stam Markianos-Wright
PR target/91816
* gcc.target/arm/pr91816.c: New test.
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #13 from Jakub Jelinek --- So, if the clobbers (unlike sets) are there just for -fipa-ra purposes, can't we drop the clobbers from the pattern and only add them during output (i.e. replace "vzeroupper" with C code that first modifies the pattern if flag_ipa_ra and then returns "vzeroupper"?
[Bug fortran/93309] Wrong error about duplicate implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93309 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:5c80a1bd426a4aeccff0da54ab80d93d7973590e commit r9-8197-g5c80a1bd426a4aeccff0da54ab80d93d7973590e Author: Tobias Burnus Date: Mon Feb 3 11:48:17 2020 +0100 Fortran] PR93309 – permit repeated 'implicit none(external)' Backported from mainline 2020-01-21 Tobias Burnus PR fortran/93309 * interface.c (gfc_procedure_use): Also check parent namespace for 'implict none (external)'. * symbol.c (gfc_get_namespace): Don't set has_implicit_none_export to parent namespace's setting. Backported from mainline 2020-01-21 Tobias Burnus PR fortran/93309 * gfortran.dg/external_implicit_none_2.f90: New.
[Bug fortran/93462] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:e5446f2201d93fc9adc913ed320aa70437ff4235 commit r9-8198-ge5446f2201d93fc9adc913ed320aa70437ff4235 Author: Tobias Burnus Date: Mon Feb 3 12:09:46 2020 +0100 [Fortran] Disable front-end optimization for OpenACC atomic (PR93462) Backported from mainline 2020-01-31 Tobias Burnus PR fortran/93462 * frontend-passes.c (gfc_code_walker): For EXEC_OACC_ATOMIC, set in_omp_atomic to true prevent front-end optimization. PR fortran/93462 * gfortran.dg/goacc/atomic-1.f90: New.
[Bug fortran/93541] OpenMP module description incomplete in gcc/fortran/intrinsic.texi – missing PARAMETER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93541 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:41ef25ed059a187010c179c5ee304b2f5d66e141 commit r9-8199-g41ef25ed059a187010c179c5ee304b2f5d66e141 Author: Tobias Burnus Date: Mon Feb 3 12:14:58 2020 +0100 [OpenMP] Add missing parameters to omp_lib documentation (PR fortran/93541) Backported from mainline 2020-02-03 Tobias Burnus PR fortran/93541 * intrinisic.texi (OpenMP Modules OMP_LIB and OMP_LIB_KINDS): Add undocumented parameters from omp_lib.f90.in.
[Bug fortran/93541] OpenMP module description incomplete in gcc/fortran/intrinsic.texi – missing PARAMETER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93541 --- Comment #3 from CVS Commits --- The releases/gcc-8 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:a08dadf58ca64df5e7627399ddfdbfea037e5e19 commit r8-9966-ga08dadf58ca64df5e7627399ddfdbfea037e5e19 Author: Tobias Burnus Date: Mon Feb 3 12:15:40 2020 +0100 [OpenMP] Add missing parameters to omp_lib documentation (PR fortran/93541) Backported from mainline 2020-02-03 Tobias Burnus PR fortran/93541 * intrinisic.texi (OpenMP Modules OMP_LIB and OMP_LIB_KINDS): Add undocumented parameters from omp_lib.f90.in.
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190
--- Comment #14 from Jakub Jelinek ---
Like (completely untested):
--- gcc/config/i386/i386-features.c.jj 2020-01-27 13:20:40.421650866 +0100
+++ gcc/config/i386/i386-features.c 2020-02-03 12:13:23.639161823 +0100
@@ -1764,29 +1764,32 @@ convert_scalars_to_vector (bool timode_p
(set (reg:V2DF R) (reg:V2DF R))
- which preserves the low 128 bits but clobbers the upper bits.
- For a dead register we just use:
-
- (clobber (reg:V2DF R))
-
- which invalidates any previous contents of R and stops R from becoming
- live across the vzeroupper in future. */
+ which preserves the low 128 bits but clobbers the upper bits. */
static void
ix86_add_reg_usage_to_vzeroupper (rtx_insn *insn, bitmap live_regs)
{
rtx pattern = PATTERN (insn);
unsigned int nregs = TARGET_64BIT ? 16 : 8;
- rtvec vec = rtvec_alloc (nregs + 1);
- RTVEC_ELT (vec, 0) = XVECEXP (pattern, 0, 0);
+ unsigned int npats = nregs;
for (unsigned int i = 0; i < nregs; ++i)
{
unsigned int regno = GET_SSE_REGNO (i);
+ if (!bitmap_bit_p (live_regs, regno))
+ npats--;
+}
+ if (npats == 0)
+return;
+ rtvec vec = rtvec_alloc (npats + 1);
+ RTVEC_ELT (vec, 0) = XVECEXP (pattern, 0, 0);
+ for (unsigned int i = 0, j = 0; i < nregs; ++i)
+{
+ unsigned int regno = GET_SSE_REGNO (i);
+ if (!bitmap_bit_p (live_regs, regno))
+ continue;
rtx reg = gen_rtx_REG (V2DImode, regno);
- if (bitmap_bit_p (live_regs, regno))
- RTVEC_ELT (vec, i + 1) = gen_rtx_SET (reg, reg);
- else
- RTVEC_ELT (vec, i + 1) = gen_rtx_CLOBBER (VOIDmode, reg);
+ ++j;
+ RTVEC_ELT (vec, j) = gen_rtx_SET (reg, reg);
}
XVEC (pattern, 0) = vec;
df_insn_rescan (insn);
--- gcc/config/i386/sse.md.jj 2020-01-31 19:18:02.395904459 +0100
+++ gcc/config/i386/sse.md 2020-02-03 12:23:40.998100427 +0100
@@ -19819,7 +19819,32 @@ (define_insn "*avx_vzeroupper"
[(match_parallel 0 "vzeroupper_pattern"
[(unspec_volatile [(const_int 0)] UNSPECV_VZEROUPPER)])]
"TARGET_AVX"
- "vzeroupper"
+{
+ if (flag_ipa_ra && XVECLEN (operands[0], 0) != (TARGET_64BIT ? 16 : 8) + 1)
+{
+ unsigned int nregs = TARGET_64BIT ? 16 : 8;
+ unsigned int npats = XVECLEN (operands[0], 0);
+ rtvec vec = rtvec_alloc (nregs + 1);
+ RTVEC_ELT (vec, 0) = XVECEXP (operands[0], 0, 0);
+ for (unsigned int i = 0, j = 1; i < nregs; ++i)
+ {
+ unsigned int regno = GET_SSE_REGNO (i);
+ if (j < npats
+ && REGNO (SET_DEST (XVECEXP (operands[0], 0, j))) == regno)
+ {
+ RTVEC_ELT (vec, i + 1) = XVECEXP (operands[0], 0, j);
+ j++;
+ }
+ else
+ {
+ rtx reg = gen_rtx_REG (V2DImode, regno);
+ RTVEC_ELT (vec, i + 1) = gen_rtx_CLOBBER (VOIDmode, reg);
+ }
+ }
+ XVEC (operands[0], 0) = vec;
+}
+ return "vzeroupper";
+}
[(set_attr "type" "sse")
(set_attr "modrm" "0")
(set_attr "memory" "none")
which fixes the #c0 ICE.
[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 --- Comment #15 from Jakub Jelinek --- With or without the fix, the very unfortunate thing is that -fipa-ra then effectively can't preserve anything in the XMM* registers across calls when those callees use vzeroupper, even when it would be just fine to preserve a 128-bit low part in there. -fipa-ra only gathers a register set, not modes in which the particular registers are preserved or clobbered.
[Bug fortran/93541] OpenMP module description incomplete in gcc/fortran/intrinsic.texi – missing PARAMETER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93541 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- FIXED on trunk and GCC 8 (w/o pause) and GCC 9.
[Bug fortran/93309] Wrong error about duplicate implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93309 --- Comment #6 from Tobias Burnus --- (In reply to ripero84 from comment #4) > Thank you! Would it be possible to backport this fix to the other active > branches? Done so for GCC 9 – I did not check GCC 8 and I also do not think that it belongs there.
[Bug fortran/93462] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- FIXED for GCC 10/trunk and GCC 9.
[Bug bootstrap/93548] New: gcc build tries to modify source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 Bug ID: 93548 Summary: gcc build tries to modify source tree Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- I build gcc with read only source tree, this worked all the time, but now it does no longer: ../gcc-trunk-0/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=all --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard make Fails, because it attempts to modify the source code; HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../gcc-trunk-0/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT="\"arm10e\"" \ HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/dbxelf.h config/elfos.h config/gnu-user.h config/linux.h config/linux-android.h config/glibc-stdint.h config/arm/elf.h config/arm/linux-gas.h config/arm/linux-elf.h config/arm/bpabi.h config/arm/linux-eabi.h config/arm/aout.h config/arm/arm.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \ /bin/sh ../../gcc-trunk-0/gcc/mkconfig.sh tm.h TARGET_CPU_DEFAULT="" \ HEADERS="config/arm/arm-flags.h config/arm/arm-protos.h config/arm/aarch-common-protos.h config/linux-protos.h tm-preds.h" DEFINES="" \ /bin/sh ../../gcc-trunk-0/gcc/mkconfig.sh tm_p.h gawk -f ../../gcc-trunk-0/gcc/config/arm/parsecpu.awk -v cmd=md \ ../../gcc-trunk-0/gcc/config/arm/arm-cpus.in > arm-tune.new mv arm-tune.new ../../gcc-trunk-0/gcc/config/arm/arm-tune.md mv: can't rename 'arm-tune.new': Permission denied make[3]: *** [../../gcc-trunk-0/gcc/config/arm/arm-tune.md] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf' make: *** [all] Error 2
[Bug bootstrap/93548] gcc build tries to modify source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 --- Comment #1 from Bernd Edlinger --- git Revision c3ccce5b47f85d70127f5bb894bc5e83f8d2510e If absolutely necessary that should only be done in maintainer mode.
[Bug bootstrap/93548] gcc build tries to modify source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 --- Comment #2 from Jonathan Wakely --- Do you use contrib/gcc_update to update timestamps of generated files so they don't need to be regenerated?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #134 from dave.anglin at bell dot net --- On 2020-02-02 8:50 p.m., peter.bisroev at groundlabs dot com wrote: > The tests are from are binutils-2.32. > > - gas.log > FAIL: .file file names > FAIL: .file file names ordering > FAIL: .equ redefinitions (ELF) > FAIL: .set with expression > FAIL: good .bss / .struct data allocation directives > FAIL: gas/elf/missing-build-notes > FAIL: ia64 xdata (ilp32) > FAIL: ia64 unwind descriptors > > - binutils.log (they look like gas related failures) > FAIL: assembler generated build notes > FAIL: --localize-hidden test 1 > FAIL: readelf -S bintest I would suggest filing binutils bug reports for the above fails. Possibly, some just need xfails. Look at each test. > > Are any of these tests critical and would you want me to look at them in more > detail? The gas fails are more important than the binutils fails. The .equ, .set and .bss fails may be important. You are making progress.
[Bug c++/93549] New: [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549
Bug ID: 93549
Summary: [10 Regression] ICE / Segfault in constexpr expansion
involving vector_size(16) short COND_EXPR
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Test case (https://godbolt.org/z/_ErsXE):
struct simd {
using _Short8 [[gnu::vector_size(16)]] = short;
_Short8 _M_data;
constexpr simd(short x) : _M_data{x, x, x, x, x, x, x, x} {}
constexpr friend unsigned operator==(simd __lhs, simd __rhs) {
_Short8 __tmp = __lhs._M_data == __rhs._M_data;
using _UShort = unsigned short;
auto __bools = __tmp ? _UShort(1) : _UShort(0);
unsigned __bits = 0;
for (int i = 0; i < 8; ++i)
__bits |= __bools[i] << i;
return __bits;
}
};
auto f()
{
constexpr auto tmp = simd(1) == simd(2);
return tmp;
}
internal compiler error: Segmentation fault
21 | constexpr auto tmp = simd(1) == simd(2);
| ^
0xfeaf4f crash_signal
/home/mkretz/src/gcc/gcc/toplev.c:328
0x8da817 find_array_ctor_elt
/home/mkretz/src/gcc/gcc/cp/constexpr.c:2950
0x8e8e80 cxx_eval_array_reference
/home/mkretz/src/gcc/gcc/cp/constexpr.c:3202
0x8df51a cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5635
0x8de093 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5746
0x8dd872 cxx_eval_binary_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:2751
0x8dd872 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5612
0x8de093 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5746
0x8dd897 cxx_eval_binary_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:2757
0x8dd897 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5612
0x8e72be cxx_eval_store_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:4294
0x8de545 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5357
0x8de093 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5746
0x8ddb36 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:6002
0x8def29 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5424
0x8dde77 cxx_eval_loop_expr
/home/mkretz/src/gcc/gcc/cp/constexpr.c:4910
0x8dde77 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5972
0x8df45d cxx_eval_statement_list
/home/mkretz/src/gcc/gcc/cp/constexpr.c:4837
0x8df45d cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5873
0x8de969 cxx_eval_constant_expression
/home/mkretz/src/gcc/gcc/cp/constexpr.c:5877
[Bug bootstrap/93548] gcc build tries to modify source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 --- Comment #3 from Bernd Edlinger --- Ah, thanks I will do that. Apparently the git conversion is to blame :)
[Bug bootstrap/93548] gcc build tries to modify source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Bernd Edlinger --- thanks, seems to work now.
[Bug libbacktrace/90636] [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 Dr. Thomas Orgis changed: What|Removed |Added CC||thomas.or...@uni-hamburg.de --- Comment #3 from Dr. Thomas Orgis --- As I already mentioned in the mirrored bug on github (https://github.com/ianlancetaylor/libbacktrace/issues/30), I added those two noclone attributes to edtest and it changed nothing: user@host:/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/libbacktrace$ make edtest /dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/xgcc -B/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/lib/ -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/include -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/sys-include -L/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./ld -fchecking=1 -DHAVE_CONFIG_H -I. -I../../gcc-9.2.0/libbacktrace -I ../../gcc-9.2.0/libbacktrace/../include -I ../../gcc-9.2.0/libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=edtest.o -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -fchecking=1 -c -o edtest.o ../../gcc-9.2.0/libbacktrace/edtest.c /bin/bash ./libtool --tag=CC --mode=link /dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/xgcc -B/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/lib/ -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/include -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/sys-include -L/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./ld -fchecking=1 -funwind-tables -frandom-seed=edtest -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -fchecking=1 -static-libstdc++ -static-libgcc -o edtest edtest.o edtest2_build.o testlib.o libbacktrace.la libtool: link: /dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/xgcc -B/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/lib/ -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/include -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/sys-include -fchecking=1 -funwind-tables -frandom-seed=edtest -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -fchecking=1 -static-libstdc++ -static-libgcc -o edtest edtest.o edtest2_build.o testlib.o -L/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./ld ./.libs/libbacktrace.a user@host:/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/libbacktrace$ ./edtest test1: [1]: missing file name or function name FAIL: backtrace_full alloc stress So … is this something serious?
[Bug fortran/93309] Wrong error about duplicate implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93309 --- Comment #7 from ripero84 at gmail dot com --- Thank you! - FYI, this behaviour was present in all versions I tried since GCC 5.
[Bug bootstrap/93548] gcc build tries to modify source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 47767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47767&action=edit gcc10-pr93548.patch IMHO we should use move-if-change and be happy even if gcc_update has not be run, only require it is actually regenerated if something changed.
[Bug bootstrap/93548] arm-tune.md and arm-tables.opt should be updated with move-if-changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 Richard Earnshaw changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2020-02-03 Resolution|INVALID |--- Summary|gcc build tries to modify |arm-tune.md and |source tree |arm-tables.opt should be ||updated with ||move-if-changed Ever confirmed|0 |1 --- Comment #6 from Richard Earnshaw --- Re-opening since the makefile fragment in t-arm should be updated to use move-if-change.
[Bug bootstrap/93548] arm-tune.md and arm-tables.opt should be updated with move-if-changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 Richard Earnshaw changed: What|Removed |Added Status|REOPENED|NEW --- Comment #7 from Richard Earnshaw --- Confirmed
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544 --- Comment #2 from David Malcolm --- (In reply to Arseny Solokha from comment #0) [...snip...] Thanks for filing this, I'm investigating the ICE. > (BTW, w/o -O1 the analysis seems to be wrong in that double-free happens > following "false" branch, but that's a different issue.) I'm not sure what you mean by the above, though the output does have issues. With only -fanalyzer, I get the following, which is rather nonsensical: $ ./xgcc -B. -c -fanalyzer pr93544.c pr93544.c: In function ‘lk’: pr93544.c:14:3: warning: double-‘free’ of ‘bs’ [CWE-415] [-Wanalyzer-double-free] 14 | __builtin_free (bs); | ^~~ ‘lk’: events 1-4 | | 11 | bs = dx = !!ja ? qd () : 0; | |~~^~~ | | || | | | || (1) following ‘true’ branch... | | |(2) ...to here | | (3) first ‘free’ here |.. | 14 | __builtin_free (bs); | | ~~~ | | | | | (4) second ‘free’ here; first ‘free’ was at (3) | Adding -fanalyzer-fine-grained improves the output considerably: $ ./xgcc -B. -c -fanalyzer pr93544.c -fanalyzer-fine-grained pr93544.c: In function ‘lk’: pr93544.c:14:3: warning: double-‘free’ of ‘bs’ [CWE-415] [-Wanalyzer-double-free] 14 | __builtin_free (bs); | ^~~ ‘lk’: events 1-4 | | 11 | bs = dx = !!ja ? qd () : 0; | | ~^~~ | || | | || (1) following ‘true’ branch... | |(2) ...to here | 12 | | 13 | __builtin_free (dx); | | ~~~ | | | | | (3) first ‘free’ here | 14 | __builtin_free (bs); | | ~~~ | | | | | (4) second ‘free’ here; first ‘free’ was at (3) |
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-03 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 --- Comment #2 from Marek Polacek --- Started with r10-3661-g8e007055dd1374ca4c44406a4ead172be0dfa3a8
[Bug c++/88256] [8/9/10 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #13 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3539fc1317267b30eb7c4ad48d52f4e46b3a198a commit r10-6405-g3539fc1317267b30eb7c4ad48d52f4e46b3a198a Author: Jason Merrill Date: Fri Jan 31 21:59:48 2020 -0500 c++: Fix cast to pointer to VLA. The C front-end fixed this issue in r257620 by adding a DECL_EXPR from grokdeclarator. We don't have an easy way to do that in the C++ front-end, but it works fine to create and prepend a DECL_EXPR when we are genericizing the NOP_EXPR for the cast. The C patch wraps the DECL_EXPR in a BIND_EXPR, but that seems unnecessary in C++; this is just a hook to run gimplify_type_sizes, we aren't actually declaring anything that we need to worry about scoping for. PR c++/88256 * cp-gimplify.c (predeclare_vla): New. (cp_genericize_r) [NOP_EXPR]: Call it.
[Bug c++/88256] [8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|[8/9/10 Regression] ICE:|[8/9 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |make_ssa_name_fn) with VLA |make_ssa_name_fn) with VLA |cast, C++ FE missing|cast, C++ FE missing |DECL_EXPRs |DECL_EXPRs --- Comment #14 from Jason Merrill --- Fixed for GCC 10 so far.
[Bug preprocessor/93545] [10 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93545 --- Comment #7 from Jakub Jelinek --- Created attachment 47768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47768&action=edit gcc10-pr93545-2.patch As discussed on IRC, here is incremental patch to reject __has_include outside of preprocessing directives (which we in 9 and earlier didn't allow and aren't valid in C++).
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 --- Comment #3 from Marek Polacek --- Looking into why the above commit caused this.
[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
Kewen Lin changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #12 from Kewen Lin ---
The insn 59 is deleted and new insn 219 is generated by function
combine_and_move_insns, the failure is due to that:
Originally insn 59 has the note that the updated reg r121 is REG_UNUSED.
Later insn 219 inserted before r184's use, with note directly copied from
insn 59, r121 is still REG_UNUSED.
So function setup_reg_equiv doesn't filter it out since it's taken as
single_set due to REG_UNUSED existence.
But the r121 in insn 219 isn't actually REG_UNUSED and gets fixed after live
info recalculation as below:
67: NOTE_INSN_BASIC_BLOCK 8
...
103: NOTE_INSN_DELETED
77: {r191:SF=[sfp:SI-0x18c];r121:SI=sfp:SI-0x18c;}
REG_UNUSED r121:SI
60: r122:SI=r127:SI
REG_DEAD r127:SI
219: {r184:SF=[sfp:SI-0x190];r121:SI=sfp:SI-0x190;}
61: [r122:SI]=r184:SF
REG_DEAD r184:SF
79: [++r122:SI]=r191:SF
REG_DEAD r191:SF
REG_INC r122:SI
Then fix_reg_equiv_init find the insn isn't single_set and assertion fail.
The newly generated doesn't look incorrect since some semantic changes as
below.
* Before combine_and_move_insns, we have:
67: NOTE_INSN_BASIC_BLOCK 8
58: NOTE_INSN_DELETED
63: NOTE_INSN_DELETED
110: NOTE_INSN_DELETED
88: NOTE_INSN_DELETED
76: NOTE_INSN_DELETED
103: NOTE_INSN_DELETED
59: {r184:SF=[sfp:SI-0x190];r121:SI=sfp:SI-0x190;}
REG_UNUSED r121:SI
77: {r191:SF=[sfp:SI-0x18c];r121:SI=sfp:SI-0x18c;}
60: r122:SI=r127:SI
REG_DEAD r127:SI
61: [r122:SI]=r184:SF
REG_DEAD r184:SF
79: [++r122:SI]=r191:SF
REG_DEAD r191:SF
REG_INC r122:SI
64: r187:SF=[r137:SI+low(`*.LC0')]
99: r198:SF=[++r121:SI] => with sp-0x18c+4;
REG_INC r121:SI
104: r201:SF=[r137:SI+low(`*.LC0')]
65: [r126:SI]=r187:SF
REG_DEAD r187:SF
105: [r126:SI]=r201:SF
REG_DEAD r201:SF
101: [++r122:SI]=r198:SF
REG_DEAD r198:SF
REG_INC r122:SI
114: L114:
113: NOTE_INSN_BASIC_BLOCK 9
* After combine_and_move_insns, we have:
67: NOTE_INSN_BASIC_BLOCK 8
58: NOTE_INSN_DELETED
63: NOTE_INSN_DELETED
110: NOTE_INSN_DELETED
88: NOTE_INSN_DELETED
76: NOTE_INSN_DELETED
103: NOTE_INSN_DELETED
77: {r191:SF=[sfp:SI-0x18c];r121:SI=sfp:SI-0x18c;}
REG_UNUSED r121:SI
60: r122:SI=r127:SI
REG_DEAD r127:SI
219: {r184:SF=[sfp:SI-0x190];r121:SI=sfp:SI-0x190;}
61: [r122:SI]=r184:SF
REG_DEAD r184:SF
79: [++r122:SI]=r191:SF
REG_DEAD r191:SF
REG_INC r122:SI
64: r187:SF=[r137:SI+low(`*.LC0')]
REG_EQUIV [r137:SI+low(`*.LC0')]
99: r198:SF=[++r121:SI]=> still with sp-0x18c;
REG_INC r121:SI
104: r201:SF=[r137:SI+low(`*.LC0')]
REG_EQUIV [r137:SI+low(`*.LC0')]
65: [r126:SI]=r187:SF
REG_DEAD r187:SF
105: [r126:SI]=r201:SF
REG_DEAD r201:SF
101: [++r122:SI]=r198:SF
REG_DEAD r198:SF
REG_INC r122:SI
114: L114:
113: NOTE_INSN_BASIC_BLOCK 9
As above, I guess we can guard the strict single_set condition for function
combine_and_move_insns.
@@ -3827,7 +3874,7 @@ combine_and_move_insns (void)
/* Move the initialization of the register to just before
USE_INSN. Update the flow information. */
- else if (prev_nondebug_insn (use_insn) != def_insn)
+ else if (prev_nondebug_insn (use_insn) != def_insn && !multiple_sets
(def_insn))
{
rtx_insn *new_insn;
Or any alternative to ensure multiple sets movement doesn't kill usused reg's
live range and notes gets updated.
-
Hi @Alan/@Vladimir,
What do you think of the issue? Thanks!
[Bug middle-end/93505] [8/9 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 --- Comment #18 from Segher Boessenkool --- PR93512 is marked as enhancement, but if we don't fix this it is a regression.
[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052 --- Comment #13 from Kewen Lin --- > “The newly generated doesn't look incorrect since some semantic changes as > below.” Sorry, typo, it should be "The newly generated insn doesn't look correct since some semantic changes as below."
[Bug c++/91953] [8/9/10 Regression] G++ rejects lambda with constexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libfortran/93550] New: Implement control of leading zero in formatted numeric output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550 Bug ID: 93550 Summary: Implement control of leading zero in formatted numeric output Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- In 2018, J3 Fortran Standards Committee agreed to add "leading zero format control" to its work list for Fortran 202x. While not (yet) part of the Fortran standard, it might make sense to implement (as an experimental GNU extension) or at least prepare for this upcoming change in order to clean up the library code, thus removing all hard-coded assumptions regarding leading zero. https://j3-fortran.org/doc/year/18/18-268.txt: When using F format to output a value less than 1, the standard allows the implementation to choose whether to include a zero before the decimal symbol. 13.7.2.3.2 (F format) paragraph 11 says (in part): "Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one. The optional zero shall appear if there would otherwise be no digits in the output field." Similarly for E and D formats, when the scale factor is zero, 13.7.2.3.2p11 says: "Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one. The optional zero shall appear if there would otherwise be no digits in the output field." EN, ES and EX formats do not have this option. Some implementations always provide the leading zeros, some do not, and this inconsistency results in user complaints, especially when test programs produce different results across different implementations. The inconsistency also occurs for G format when the value is in a certain range, since E and F formatting is used. Unlike the optional sign before a positive value, there is no user control over the optional zero. Use Cases - Many users have complained over the years that this inconsistency makes it difficult to automatically validate results across different implementations and, in some cases where the leading zero is omitted, makes the output from a Fortran application unusable by applications written in other languages. Requirements - Add control edit descriptors, analogous to the SS, SP and S edit descriptors, allowing the programmer to specify whether a leading zero is to appear in output for the F, E, D and G formats in the cases where it is currently optional. The requirement of the leading zero when otherwise no digits would appear is to remain. As with the existing S control descriptor, one of the new descriptors selects the implementation-defined behavior, which remains the default. - Continuing the analogy with SS, SP and S, and the SIGN= OPEN/INQUIRE specifier, add a new specifier to OPEN and INQUIRE to allow specification or inquiry of the current mode. Like SIGN=, this is to be a "changeable mode" (12.5.2p1). List-directed and namelist- directed output are to use the current "leading zero" mode. https://j3-fortran.org/doc/year/19/19-156r1.txt: Requirements - Add control edit descriptors, analogous to the SS, SP and S edit descriptors, allowing the programmer to specify whether a leading zero is to appear in output for the F, E, D and G formats in the cases where it is currently optional. The requirement of the leading zero when otherwise no digits would appear is to remain. As with the existing S control descriptor, one of the new descriptors selects the implementation-defined behavior, which remains the default. - Continuing the analogy with SS, SP and S, and the SIGN= OPEN/INQUIRE specifier, add a new specifier to OPEN and INQUIRE to allow specification or inquiry of the current mode. Like SIGN=, this is to be a "changeable mode" (12.5.2p1). List-directed and namelist- directed output are to use the current "leading zero" mode. Specification - 1. Add the following control edit descriptors: LZS, LZP, LZ. The LZS, LZP, and LZ edit descriptors temporarily change (12.5.2) the leading zero mode for the connection. The edit descriptors LZS, LZP, and LZ set the leading zero mode corresponding to the LEADING_ZERO= specifier values SUPPRESS, PRINT, and PROCESSOR_DEFINED, respectively. The leading zero mode controls optional leading zero characters in numeric output fields. When the leading zero mode is PRINT, the processor shall produce a leading zero in any position that normally contains an optional leading zero. When the leading zero mode is SUPPRESS, the processor shall not produce a leading zero in such positions. When
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544 --- Comment #3 from Arseny Solokha --- (In reply to David Malcolm from comment #2) > (In reply to Arseny Solokha from comment #0) > > (BTW, w/o -O1 the analysis seems to be wrong in that double-free happens > > following "false" branch, but that's a different issue.) > > I'm not sure what you mean by the above I'm not sure either now. I bet I've seen | 11 | bs = dx = !!ja ? qd () : 0; | |~~^~~ | | || | | | || (1) following 'false' branch... (maybe at some point during testcase reduction?) but I cannot reproduce it now. Will try tomorrow on the machine that yielded the testcase and file a separate PR if it'll turn to be real. Meanwhile, passing -xc++ along w/ -fanalyzer-fine-grained, yet unsupported, makes the output fully correct.
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544
--- Comment #4 from David Malcolm ---
(In reply to Arseny Solokha from comment #3)
[...]
> I'm not sure either now. I bet I've seen
>
> | 11 | bs = dx = !!ja ? qd () : 0;
> | |~~^~~
> | | || |
> | | || (1) following 'false' branch...
>
> (maybe at some point during testcase reduction?) but I cannot reproduce it
> now. Will try tomorrow on the machine that yielded the testcase and file a
> separate PR if it'll turn to be real.
>
> Meanwhile, passing -xc++ along w/ -fanalyzer-fine-grained, yet unsupported,
> makes the output fully correct.
Thanks; you're right; the ICE involves it erroneously picking the "false" path,
which I see when bulletproofing the crashing code, getting this at -O1:
pr93544.c: In function ‘lk’:
pr93544.c:16:3: warning: double-‘free’ of ‘’ [CWE-415]
[-Wanalyzer-double-free]
16 | __builtin_free (bs); /* { dg-warning "double-'free'" } */
| ^~~
‘lk’: events 1-4
|
| 13 | bs = dx = !!ja ? qd () : 0;
| | ~^~~
| | |
| | (1) following ‘false’ branch...
| 14 |
| 15 | __builtin_free (dx);
| | ~~~
| | |
| | (2) ...to here
| | (3) first ‘free’ here
| 16 | __builtin_free (bs);
| | ~~~
| | |
| | (4) second ‘free’ here; first ‘free’ was at (3)
|
If I use -fno-analyzer-state-merge it still misreports it (albeit with "note: 1
duplicate") - with that, I think it's picking the dedupe candidate with the
wrong path.
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I guess that is not that important, what matters is that the middle-end created CONSTRUCTORs can make it into the constexpr evaluation, and there is no guarantee that in such CONSTRUCTORs the indexes will be present. Trying to teach it now to handle missing indexes (the case where they are missing completely is easy, the problem can be mixed case where some elts have indexes and others don't).
Price
Hi, Hope you are doing good. I found your email on the web. I would like to discuss business oppurtunity with you. Are you looking for more customers? I would really like to help your business raise through 1st page og Google. Send me an email if you would like to increase your online profile with more traffic and customers. Regards, Shikha SEO Co-ordinate
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #4 from Giulio Benetti --- Created attachment 47769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47769&action=edit .ii of file where gcc hangs on building This is the .ii of file where gcc hangs on building.
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 --- Comment #5 from Jakub Jelinek --- Created attachment 47770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47770&action=edit gcc10-pr93549.patch Untested fix.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #5 from Giulio Benetti --- Here is the specific command line which compiles .cpp file: /home/giuliobenetti/br_reproduce/9a405ec6fabfa306c14a671a5e09359ac623c25b/output/host/bin/riscv32-linux-g++ --sysroot=/home/giuliobenetti/br_reproduce/9a405ec6fabfa306c14a671a5e09359ac623c25b/output/host/riscv32-buildroot-linux-gnu/sysroot -DBT_USE_EGL -DBulletCollision_EXPORTS -DNO_OPENGL3 -DUSE_GRAPHICAL_BENCHMARK -I/home/giuliobenetti/br_reproduce/9a405ec6fabfa306c14a671a5e09359ac623c25b/output/build/bullet-2.89/src -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -save-temps -DNDEBUG -fPIC -o CMakeFiles/BulletCollision.dir/NarrowPhaseCollision/btPolyhedralContactClipping.o -c /home/giuliobenetti/br_reproduce/9a405ec6fabfa306c14a671a5e09359ac623c25b/output/build/bullet-2.89/src/BulletCollision/NarrowPhaseCollision/btPolyhedralContactClipping.cpp then it sits there forever.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #6 from Giulio Benetti --- And this is how riscv32 gcc has been configured: Using built-in specs. COLLECT_GCC=/home/giuliobenetti/br_reproduce/9a405ec6fabfa306c14a671a5e09359ac623c25b/output/host/opt/ext-toolchain/bin/riscv32-buildroot-linux-gnu-gcc.br_real COLLECT_LTO_WRAPPER=/home/giuliobenetti/br_reproduce/9a405ec6fabfa306c14a671a5e09359ac623c25b/output/host/opt/ext-toolchain/bin/../libexec/gcc/riscv32-buildroot-linux-gnu/8.3.0/lto-wrapper Target: riscv32-buildroot-linux-gnu Configured with: ./configure --prefix=/opt/br-riscv32-glibc-2019.11 --sysconfdir=/opt/br-riscv32-glibc-2019.11/etc --enable-static --target=riscv32-buildroot-linux-gnu --with-sysroot=/opt/br-riscv32-glibc-2019.11/riscv32-buildroot-linux-gnu/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/opt/br-riscv32-glibc-2019.11 --with-mpc=/opt/br-riscv32-glibc-2019.11 --with-mpfr=/opt/br-riscv32-glibc-2019.11 --with-pkgversion='Buildroot 2019.11' --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath --enable-tls --enable-threads --without-isl --without-cloog --with-arch=rv32imafd --with-abi=ilp32d --enable-languages=c,c++ --with-build-time-tools=/opt/br-riscv32-glibc-2019.11/riscv32-buildroot-linux-gnu/bin --enable-shared --disable-libgomp Thread model: posix gcc version 8.3.0 (Buildroot 2019.11)
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 --- Comment #6 from Jakub Jelinek --- It was the typeck2.c (store_init_value): Don't call cp_fully_fold_init on initializers of automatic non-constexpr variables in constexpr functions. part of the above change btw, with that reverted the folding folds the CONSTRUCTOR into VECTOR_CST and so we don't trigger that. The problematic CONSTRUCTORs are created by build_vector_from_val, and the reason we don't get a VECTOR_CST out of it immediately is that we don't call it with an INTEGER_CST, but NON_LVALUE_EXPR wrapping the INTEGER_CST, aka location wrapper. So, another way out of this for this particular testcase might be e.g. strip the location wrapper out from the arg before calling build_vector_from_val and wrap the resulting VECTOR_CST into a location wrapper instead.
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 --- Comment #5 from Jakub Jelinek --- Well, at least PR80005 has been fixed...
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Can't reproduce, neither with 8.3.1 20200111 nor current trunk, it compiles pretty much instantly (cross-compiler from x86_64-linux to riscv32-linux).
[Bug c++/93551] New: Call from templated function to constrained constructor segfaults when attempting to narrow to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551
Bug ID: 93551
Summary: Call from templated function to constrained
constructor segfaults when attempting to narrow to
bool
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pacoarjonilla at yahoo dot es
Target Milestone: ---
Minimum code:
>
#include
class Bar { };
struct Foo {
template requires std::is_base_of_v
Foo(P const&);
};
template
Foo fun(P const& arg) {
(bool)arg;
return Foo {arg};
}
int main() {
fun(Bar{});
return 0;
}
>
On GCC10 git commit 3539fc13172 (2020/02/03)
runnning on intel i7-8700K on OpenSUSE Tumbleweed.
Also confirmed in compiler explorer GCC trunk (godbolt.org, just copy and
paste)
g++10git --std=c++2a namidevel.cc
namidevel.cc: In instantiation of ‘Foo fun(const P&) [with P = Bar]’:
namidevel.cc:13:14: required from here
namidevel.cc:9:5: error: invalid cast from type ‘const Bar’ to type ‘bool’
9 | (bool)arg;
| ^
namidevel.cc:11:1: internal compiler error: Segmentation fault
11 | }
| ^
0xfd70bf crash_signal
../../gcc/gcc/toplev.c:328
0x9e29a7 pop_tinst_level()
../../gcc/gcc/cp/pt.c:10757
0x9fa98f instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:25591
0xa2becb instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:25665
0x936033 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4875
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 --- Comment #6 from Andreas Schwab --- PR80005 is not relevant here.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #8 from Giulio Benetti --- Do you mind to use official Buildroot script to reproduce? Here is the procedure: # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build 9a405ec6fabfa306c14a671a5e09359ac623c25b and wait until it hangs, otherwise I see it difficult to reproduce it. Is it ok for you?
[Bug fortran/93552] New: [8/9/10 Regression] ICE in gfc_trans_exit, at fortran/trans-stmt.c:6110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93552 Bug ID: 93552 Summary: [8/9/10 Regression] ICE in gfc_trans_exit, at fortran/trans-stmt.c:6110 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with early r7 : $ cat z1.f90 program p integer :: i, j !$acc parallel loop tile(2,2) do i = 1, 8 do j = 1, 8 exit end do end do end $ gfortran-6 -c z1.f90 -fopenacc $ $ gfortran-10-20200202 -c z1.f90 -fopenacc z1.f90:6:0: 6 | exit | internal compiler error: in gfc_trans_exit, at fortran/trans-stmt.c:6110 0x76b975 gfc_trans_exit(gfc_code*) ../../gcc/fortran/trans-stmt.c:6110 0x6f6077 trans_code ../../gcc/fortran/trans.c:1895 0x756487 gfc_trans_omp_code ../../gcc/fortran/trans-openmp.c:3620 0x75f087 gfc_trans_omp_do ../../gcc/fortran/trans-openmp.c:4426 0x75fbb3 gfc_trans_oacc_combined_directive ../../gcc/fortran/trans-openmp.c:4537 0x75fce4 gfc_trans_oacc_directive(gfc_code*) ../../gcc/fortran/trans-openmp.c:5725 0x6f5e07 trans_code ../../gcc/fortran/trans.c:2158 0x71f504 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6835 0x6a83a6 translate_all_program_units ../../gcc/fortran/parse.c:6306 0x6a83a6 gfc_parse_file() ../../gcc/fortran/parse.c:6545 0x6f295f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug bootstrap/93548] arm-tune.md and arm-tables.opt should be updated with move-if-changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:492c63e5b72c3497160e2c2e113fb91644b3570e commit r10-6407-g492c63e5b72c3497160e2c2e113fb91644b3570e Author: Richard Earnshaw Date: Mon Feb 3 17:40:55 2020 + arm: Use move-if-change for updating regenerated files [PR93548] The t-arm make fragment currently uses 'mv' to update some files that are automatically regenerated, but this causes problems on read-only filesystems if the date stamps are incorrect and the files have not really changed. So use move-if-change instead. PR target/93548 * config/arm/t-arm: ($(srcdir)/config/arm/arm-tune.md, $(srcdir)/config/arm/arm-tables.opt): Use move-if-change.
[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 David Sagan changed: What|Removed |Added CC||david.sagan at gmail dot com --- Comment #12 from David Sagan --- Still failing in 9.2.0
[Bug bootstrap/93548] arm-tune.md and arm-tables.opt should be updated with move-if-changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Earnshaw --- Fixed on trunk. Not planning a backport, but wouldn't be hard.
[Bug fortran/93553] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:964
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Compiles these slightly modified variants : $ cat z2.f90 program p integer :: x(8) = 0 call sub(x) end subroutine sub(x) integer :: x(8) integer :: c(8) = 1 integer :: i !$omp parallel do reduction(+:x) do i = 1, 8 x(i) = c(i) end do print *, x end $ cat z3.f90 program p integer :: x(8) = 0 integer :: c(8) = 1 call s contains subroutine s integer :: i !$omp parallel do reduction(+:x) do i = 1, 8 x(i) = c(i) end do print *, x end end
[Bug fortran/93553] New: ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:964
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553 Bug ID: 93553 Summary: ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:964 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p integer :: x(8) = 0 call sub(x) end subroutine sub(x) integer :: x(8) integer :: c(8) = 1 call s contains subroutine s integer :: i !$omp parallel do reduction(+:x) do i = 1, 8 x(i) = c(i) end do print *, x end end $ gfortran-10-20200202 -c z1.f90 -fopenmp -O0 $ $ gfortran-10-20200202 -c z1.f90 -fopenmp -O2 during GIMPLE pass: fre z1.f90:4:0: 4 | end | internal compiler error: in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:964 0xd1d827 copy_reference_ops_from_ref ../../gcc/tree-ssa-sccvn.c:964 0xd20ab5 valueize_shared_reference_ops_from_ref ../../gcc/tree-ssa-sccvn.c:1624 0xd210b9 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool, tree_node**) ../../gcc/tree-ssa-sccvn.c:3179 0xd2b489 visit_reference_op_store ../../gcc/tree-ssa-sccvn.c:4588 0xd2b489 visit_stmt ../../gcc/tree-ssa-sccvn.c:4917 0xd2c39b process_bb ../../gcc/tree-ssa-sccvn.c:6608 0xd2e1d7 do_rpo_vn ../../gcc/tree-ssa-sccvn.c:7127 0xd2e89f execute ../../gcc/tree-ssa-sccvn.c:7395
[Bug bootstrap/93548] arm-tune.md and arm-tables.opt should be updated with move-if-changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 --- Comment #10 from Jakub Jelinek --- Won't this invoke it all the time if the timestamp of the generated files is older than timestamp of the sources from which it is generated? Which was the reason I've used stamp files in the #c5 patch similarly how we use it almost everywhere else when using move-if-change?
[Bug fortran/93554] New: [8/9/10 Regression] ICE in expand_oacc_for, at omp-expand.c:6035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93554 Bug ID: 93554 Summary: [8/9/10 Regression] ICE in expand_oacc_for, at omp-expand.c:6035 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With an unused allocatable array b, down to r6 : $ cat z1.f90 program p type t integer :: a integer, allocatable :: b(:) end type type(t) :: x integer :: i !$acc kernels !$acc loop private(x) do i = 0, 31 x%a = 1 end do !$acc end kernels end $ gfortran-5 -c z1.f90 -fopenacc $ $ gfortran-10-20200202 -c z1.f90 -fopenacc during GIMPLE pass: ompexp z1.f90:9:0: 9 |!$acc loop private(x) | internal compiler error: in expand_oacc_for, at omp-expand.c:6035 0xbc7e0b expand_oacc_for ../../gcc/omp-expand.c:6034 0xbdaa27 expand_omp_for ../../gcc/omp-expand.c:6539 0xbdb5ea expand_omp ../../gcc/omp-expand.c:8817 0xbdb8de expand_omp ../../gcc/omp-expand.c:8803 0xbdd4ad execute_expand_omp ../../gcc/omp-expand.c:9046
[Bug fortran/93555] New: ICE in simd_clone_struct_copy, at omp-simd-clone.c:84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93555 Bug ID: 93555 Summary: ICE in simd_clone_struct_copy, at omp-simd-clone.c:84 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5; compiles z0.f90 : $ cat z0.f90 subroutine s !$omp declare simd(s) inbranch !$omp declare simd(s) end $ cat z1.f90 subroutine s !$omp declare simd(s) !$omp declare simd(s) inbranch end $ cat z2.f90 subroutine s !$omp declare simd(s) inbranch !$omp declare simd(s) inbranch end $ gfortran-10-20200202 -c z0.f90 -fopenmp $ $ gfortran-10-20200202 -c z1.f90 -fopenmp during IPA pass: simdclone z1.f90:4:0: 4 | end | internal compiler error: Segmentation fault 0xbac59f crash_signal ../../gcc/toplev.c:328 0x1438792 simd_clone_struct_copy ../../gcc/omp-simd-clone.c:84 0x1438792 expand_simd_clones(cgraph_node*) ../../gcc/omp-simd-clone.c:1698 0x1439237 ipa_omp_simd_clone ../../gcc/omp-simd-clone.c:1764 0x1439237 execute ../../gcc/omp-simd-clone.c:1792
[Bug c++/93551] [10 Regression] Call from templated function to constrained constructor segfaults when attempting to narrow to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-03
CC||jakub at gcc dot gnu.org
Target Milestone|--- |10.0
Summary|Call from templated |[10 Regression] Call from
|function to constrained |templated function to
|constructor segfaults when |constrained constructor
|attempting to narrow to |segfaults when attempting
|bool|to narrow to bool
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started to ICE with r10-5012-g72479e324313e8a68a534527f79e741f9a7df6fa.
Testcase that doesn't need any includes:
namespace std {
template
struct integral_constant
{
static constexpr _Tp value = __v;
typedef _Tp value_type;
typedef integral_constant<_Tp, __v> type;
constexpr operator value_type() const noexcept { return value; }
};
template
struct is_base_of
: public integral_constant
{ };
template
inline constexpr bool is_base_of_v = is_base_of<_Base, _Derived>::value;
}
class Bar { };
struct Foo {
template requires std::is_base_of_v
Foo(P const&);
};
template
Foo fun(P const& arg) {
(bool)arg;
return Foo {arg};
}
int main() {
fun(Bar{});
return 0;
}
[Bug bootstrap/93548] arm-tune.md and arm-tables.opt should be updated with move-if-changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548 --- Comment #11 from Richard Earnshaw --- I don't think so, since the write back will update the timestamp. It would only rerun it once per make anyway. Also, the timestamp approach is really designed for files in the build area, not those in the source tree. While I'd prefer these files to live in the build area, neither can at present because the build system won't look for .opt or .md files there.
[Bug libbacktrace/90636] [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 --- Comment #4 from Ian Lance Taylor --- It's odd, in that we're not seeing the same problem. It's serious if you absolutely rely on getting good information from libbacktrace in all circumstances. It doesn't indicate a problem deeper than an inability to find the function name in some cases.
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 H.J. Lu changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2020-02/msg00107.ht ||ml Target Milestone|--- |10.0 --- Comment #12 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00107.html
[Bug tree-optimization/93556] New: lower mempcpy to memcpy when result is unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93556
Bug ID: 93556
Summary: lower mempcpy to memcpy when result is unused
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC lowers calls to strpcpy whose result isn't used to strcpy, presumably
because the latter tends to be more efficient. With pr90263 resolved, GCC also
expands some calls to mempcpy to memcpy on most targets, again because the
latter is almost always more efficient. But when the result of the mempcpy
call is not used, the call could be transformed to memcpy unconditionally, on
all targets, including those like x86 where targetm.libc_has_fast_function
(BUILT_IN_MEMPCPY) returns true.
$ cat a.c && gcc -S -Wall -fdump-tree-lower=/dev/stdout a.c
void f0 (char *d, const char *s)
{
__builtin_stpcpy (d, s); // lowered to strcpy
}
void f1 (void *d, const void *s, __SIZE_TYPE__ n)
{
__builtin_mempcpy (d, s, n); // should be lowered to memcpy
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)
f0 (char * d, const char * s)
{
__builtin_strcpy (d, s);
return;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1936, cgraph_uid=2, symbol_order=1)
f1 (void * d, const void * s, long unsigned int n)
{
__builtin_mempcpy (d, s, n);
return;
}
[Bug middle-end/93197] -fpatchable-function-entries : __patchable_function_entries does not survive under --gc-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93197 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2020-02-03 Resolution|MOVED |--- Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- A patch to support the section flag 'o' in .section directive is posted at https://sourceware.org/ml/binutils/2020-02/msg00038.html
[Bug c++/93557] New: __builtin_convertvector doesn't mak input as used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93557
Bug ID: 93557
Summary: __builtin_convertvector doesn't mak input as used
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 47771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47771&action=edit
test case (pass -Wextra to enable the warnings)
I'm getting some false positives with -Wunused-but-set-parameter and
-Wunused-but-variable which I've narrowed down to __builtin_convertvector.
There is a quick test case attached, or ot godbolt at
https://godbolt.org/z/RSFLGB
It works as expected with gcc, but with g++ I get:
cv.cc: In function ‘vecf conv(veci)’:
cv.cc:4:16: warning: parameter ‘a’ set but not used
[-Wunused-but-set-parameter]
4 | vecf conv(veci a) {
| ~^
cv.cc: In function ‘vecf conv2(veci)’:
cv.cc:11:8: warning: variable ‘tmp’ set but not used
[-Wunused-but-set-variable]
11 | veci tmp = a;
|^~~
In case anyone else finds this, as a (hopefully temporary) workaround I'm
planning to modify my macro wrapper to use a statement expr to create a
temporary variable which I mark as used using the ((void) foo) trick:
#define SIMDE__CONVERT_VECTOR(to, from) ((to) = (__extension__({ \
__typeof__(from) from_ = (from); \
((void) from_); \
__builtin_convertvector(from_, __typeof__(to)); \
})))
[Bug analyzer/93547] ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93547 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:287ccd3bd6b92f11ec90c52ffccb764aacfadb89 commit r10-6409-g287ccd3bd6b92f11ec90c52ffccb764aacfadb89 Author: David Malcolm Date: Mon Feb 3 06:34:20 2020 -0500 analyzer: fix ICE due to comparing int and real constants (PR 93547) gcc/analyzer/ChangeLog: PR analyzer/93547 * constraint-manager.cc (constraint_manager::get_or_add_equiv_class): Ensure types are compatible before comparing constants. gcc/testsuite/ChangeLog: PR analyzer/93547 * gcc.dg/analyzer/pr93547.c: New test.
[Bug analyzer/93546] ICE: Segmentation fault (in ana::region_model::add_region_for_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93546 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5e10b9a28be9061b9b0c4aa3cfabe6d478e444e0 commit r10-6410-g5e10b9a28be9061b9b0c4aa3cfabe6d478e444e0 Author: David Malcolm Date: Mon Feb 3 08:30:54 2020 -0500 analyzer: fix ICE merging models containing label pointers (PR 93546) PR analyzer/93546 reports an ICE within region_model::add_region_for_type when merging two region_models each containing a label pointer. The two labels are stored as pointers to symbolic_regions, but these regions were created with NULL type, leading to an assertion failure when a merged copy is created. The labels themselves have void (but not NULL) type. This patch updates make_region_for_type to use the type of the decl when creating such regions, rather than implicitly setting the region's type to NULL, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/93546 * region-model.cc (region_model::on_call_pre): Update for new param of symbolic_region ctor. (region_model::deref_rvalue): Likewise. (region_model::add_new_malloc_region): Likewise. (make_region_for_type): Likewise, preserving type. * region-model.h (symbolic_region::symbolic_region): Add "type" param and pass it to base class ctor. gcc/testsuite/ChangeLog: PR analyzer/93546 * gcc.dg/analyzer/pr93546.c: New test.
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:8525d1f5f57b11fe04a97674cc2fc2b7727621d0 commit r10-6412-g8525d1f5f57b11fe04a97674cc2fc2b7727621d0 Author: David Malcolm Date: Mon Feb 3 11:23:09 2020 -0500 analyzer: detect zero-assignment in phis (PR 93544) PR analyzer/93544 reports an ICE when attempting to report a double-free within diagnostic_manager::prune_for_sm_diagnostic, in which the variable of interest has become an INTEGER_CST. Additionally, it picks a nonsensical path through the function in which the pointer being double-freed is known to be NULL, which we shouldn't complain about. The dump shows that it picks the INTEGER_CST when updating var at a phi node: considering event 4, with var: ‘iftmp.0_2’, state: ‘start’ updating from ‘iftmp.0_2’ to ‘0B’ based on phi node phi: iftmp.0_2 = PHI considering event 3, with var: ‘0B’, state: ‘start’ and that it has picked the shortest path through the exploded graph, and on this path the pointer has been assigned NULL. The root cause is that the state machine's on_stmt isn't called for phi nodes (and wouldn't make much sense, as we wouldn't know which arg to choose). malloc state machine::on_stmt "sees" a GIMPLE_ASSIGN to NULL and handles it by transitioning the lhs to the "null" state, but never "sees" GIMPLE_PHI nodes. This patch fixes the ICE by wiring up phi-handling with state machines, so that state machines have an on_phi vfunc. It updates the only current user of "is_zero_assignment" (the malloc sm) to implement equivalent logic for phi nodes. Doing so ensures that the pointer is in a separate sm-state for the NULL vs non-NULL cases, and so gets separate exploded nodes, and hence the path-finding logic chooses the correct path, and the correct non-NULL phi argument. The patch also adds some bulletproofing to prune_for_sm_diagnostic to avoid crashing in the event of a bad path. gcc/analyzer/ChangeLog: PR analyzer/93544 * diagnostic-manager.cc (diagnostic_manager::prune_for_sm_diagnostic): Bulletproof against bad choices due to bad paths. * engine.cc (impl_region_model_context::on_phi): New. * exploded-graph.h (impl_region_model_context::on_phi): New decl. * region-model.cc (region_model::on_longjmp): Likewise. (region_model::handle_phi): Add phi param. Call the ctxt's on_phi vfunc. (region_model::update_for_phis): Pass phi to handle_phi. * region-model.h (region_model::handle_phi): Add phi param. (region_model_context::on_phi): New vfunc. (test_region_model_context::on_phi): New. * sm-malloc.cc (malloc_state_machine::on_phi): New. (malloc_state_machine::on_zero_assignment): New. * sm.h (state_machine::on_phi): New vfunc. gcc/testsuite/ChangeLog: PR analyzer/93544 * gcc.dg/analyzer/torture/pr93544.c: New test.
[Bug analyzer/93547] ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93547 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by above commit.
[Bug analyzer/93546] ICE: Segmentation fault (in ana::region_model::add_region_for_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93546 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Should be fixed by the above commit.
[Bug libgomp/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844 seurer at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from seurer at gcc dot gnu.org --- I see no failures after 2010-02-01.
[Bug libgomp/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844 --- Comment #6 from seurer at gcc dot gnu.org --- Make that... I see no failures after 2020-02-01.
[Bug tree-optimization/93558] New: missing mempcpy folding defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93558
Bug ID: 93558
Summary: missing mempcpy folding defeats strlen optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The two functions below create the same string but f1() is micro-optimized to
avoid copying the terminating nul in "1234" before immediately appending "5678"
(whether or not such micro-optimization ever makes sense is a separate issue).
Yet GCC ultimately optimizes f0() better because in f1() it doesn't exploit the
basic property of mempcpy(d, ..., 4): that it returns d + 4.
It seems that if it's profitable to (as far as I can see) unconditionally
transform stpcpy(D, S) to strcpy(D, S)/memcpy(D, S, N) + N (when N is the known
length of S), it should likewise be profitable to transform mempcpy to memcpy +
N. Either way, GCC should emit equivalently efficient code for both functions
below.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
void f0 (char *d, const char *s)
{
char *t = __builtin_stpcpy (d, "1234");
__builtin_strcpy (t, "5678");
if (__builtin_strlen (d) != 8) // folded to false
__builtin_abort ();
}
void f1 (char *d, const char *s)
{
char *t = __builtin_mempcpy (d, "1234", 4);
__builtin_strcpy (t, "5678");
if (__builtin_strlen (d) != 8) // not folded
__builtin_abort ();
}
;; Function f0 (f0, funcdef_no=0, decl_uid=3479, cgraph_uid=1, symbol_order=0)
f0 (char * d, const char * s)
{
char * t;
[local count: 1073741824]:
__builtin_memcpy (d_3(D), "1234", 4);
t_5 = d_3(D) + 4;
__builtin_memcpy (t_5, "5678", 5); [tail call]
return;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=3484, cgraph_uid=2, symbol_order=1)
f1 (char * d, const char * s)
{
char * t;
long unsigned int _1;
[local count: 1073741824]:
t_5 = __builtin_mempcpy (d_3(D), "1234", 4);
__builtin_memcpy (t_5, "5678", 5);
_1 = __builtin_strlen (d_3(D));
if (_1 != 8)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #10 from Jeffrey A. Law --- So the failure here is definitely related to the nop-moves in the IL. In simplest terms cse_insn will invalidate the destination of the nop-set. That sets is REG_QTY to a magic value that indicates its no longer valid. Then we call insert_regs which is going to walk the value chain. When that walk encounters the same reg in the value chain, but with an invalid REG_QTY we ICE. The simplest solution here is to handle nop register moves in a manner similar to nop memory moves. The only complication in a hunk of code that changes the source of a nop set to reference a different register from the value chain. The idea here is to have their lifetimes abut rather than overlap. I think we can just put the nop register handling right after that code which will resolve all these issues.
[Bug c++/93458] ICE using coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Sandoe --- bah, I messed up the commit message, should be fixed by: https://gcc.gnu.org/ml/gcc-cvs/2020-02/msg00063.html
[Bug c++/93557] __builtin_convertvector doesn't mark input as used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93557 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-03 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I'll take this.
[Bug analyzer/93543] [10 regression] bootstrap with clang 9.0.1 fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543
--- Comment #1 from David Malcolm ---
Here's a simpler patch; does it fix the build with clang?
gcc/analyzer/ChangeLog:
PR analyzer/93543
* engine.cc (pod_hash_traits::mark_empty):
Eliminate reinterpret_cast.
(pod_hash_traits::is_empty): Likewise.
---
gcc/analyzer/engine.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 90f7067dec1..81b8a76c5eb 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -2962,7 +2962,7 @@ template <>
inline void
pod_hash_traits::mark_empty (value_type &v)
{
- v.m_fun = reinterpret_cast (NULL);
+ v.m_fun = NULL;
}
template <>
inline bool
@@ -2974,7 +2974,7 @@ template <>
inline bool
pod_hash_traits::is_empty (value_type v)
{
- return v.m_fun == reinterpret_cast (NULL);
+ return v.m_fun == NULL;
}
namespace ana {
--
2.21.0
[Bug analyzer/93511] ICE in make_region_for_type analyzing zlib/gzwrite.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93511 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from David Malcolm --- (In reply to Arseny Solokha from comment #1) > I cannot reproduce it on master (as of > g:b817be038d94c987e02c26ed2d81b6f2ebb5f97a). I believe it was fixed by > g:6775172431a8e6f0d20ac0c4946d6b5db2f46450. Thanks - yes, it turns out to have been another void vs const void issue. *** This bug has been marked as a duplicate of bug 93457 ***
[Bug analyzer/93457] ICE in make_region_for_type, at analyzer/region-model.cc:5983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93457 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #5 from David Malcolm --- *** Bug 93511 has been marked as a duplicate of this bug. ***
[Bug analyzer/93388] ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 Bug 93388 depends on bug 93511, which changed state. Bug 93511 Summary: ICE in make_region_for_type analyzing zlib/gzwrite.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93511 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
