[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #13 from Jim Wilson ---
I see 5 broken patterns which matches the list already given. The four
testcases are all triggering on the same splitter, which is the first
define_split, lshrsi3_zero_extend_3+1. The second define_split,
lshrsi3_zero_extend_3+2, requires a mask which has at least 32 zeros in the low
bits. I don't think that this can occur with a paradoxical reg, because the
only valid input bits are all undefined bits in the upper half of the
paradoxical reg. We may as well fix it anyways though to be consistent, but
this means writing a testcase appears to be impossible. The other three are
post reload splitters, which will be hard to write a testcase for. So it looks
like we only have one useful testcase here, but that is better than nothing.
Kito and I can test RISC-V patches.
Using SUBREG_REG would require generating a new reg rtx with the wider mode.
May not be worth the trouble considering how uncommon that case will be.
For the second define_split, the existing testcases that trigger it are
unsigned long
sub1 (unsigned long i)
{
return (i >> 32) << 32;
}
unsigned long
sub2 (unsigned long i)
{
return (i >> 63) << 63;
}
Like I mentioned above, I don't see how that can be rewritten to use a
paradoxical reg.
[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474 Paul Hua changed: What|Removed |Added CC||paul.hua.gm at gmail dot com --- Comment #1 from Paul Hua --- The preprocessed file parallel_settings.ii of parallel_settings.cc should be provided. Look at this: https://gcc.gnu.org/bugs/ "the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below)."
[Bug regression/91654] New: Regressions of SPEC2017 rate caused by r274994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91654 Bug ID: 91654 Summary: Regressions of SPEC2017 rate caused by r274994 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com Target Milestone: --- compiled with -march=skylake-avx512 -Ofast -funroll-loops -flto 531.deepsjeng_r -7.18% 548.exchange_r -6.70% 557.xz_r -6.74% 508.namd_r -2.81% 527.cam4_r -6.48% 544.nab_r -3.99% Tested on skylake server. - Refer to https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02129.html
[Bug libstdc++/91653] New: ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91653
Bug ID: 91653
Summary: ostream::operator<<(streambuf*) should fail the
ostream when write output stream error but not
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: yhliang86 at hotmail dot com
Target Milestone: ---
bits/ostream.tcc
operator<<(__streambuf_type* __sbin):
if (!__copy_streambufs(__sbin, this->rdbuf()))
__err |= ios_base::failbit;
expect __copy_streambufs return zero on failure, but __copy_streambufs actually
return copied number, and will never be zero if sputc error after have written
some:
bits/streambuf.tcc
__copy_streambufs_eof(basic_streambuf<_CharT, _Traits>* __sbin,
basic_streambuf<_CharT, _Traits>* __sbout,
bool& __ineof)
{
streamsize __ret = 0;
__ineof = true;
typename _Traits::int_type __c = __sbin->sgetc();
while (!_Traits::eq_int_type(__c, _Traits::eof()))
{
__c = __sbout->sputc(_Traits::to_char_type(__c));
if (_Traits::eq_int_type(__c, _Traits::eof()))
{
__ineof = false;
break;
}
++__ret;
__c = __sbin->snextc();
}
return __ret;
}
__copy_streambufs(basic_streambuf<_CharT, _Traits>* __sbin,
basic_streambuf<_CharT, _Traits>* __sbout)
{
bool __ineof;
return __copy_streambufs_eof(__sbin, __sbout, __ineof);
}
only __ineof is false can indicate the failure, but it is ignored by
__copy_streambufs.
[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-04 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #3) > Jerry, I am away from my computer at the moment. > > Does zhis ring a bell? Does not specifically ring a bell, but I am very familair with the code and would be happy to fix it.
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 --- Comment #9 from Iain Sandoe --- does this problem still exist? Please can you give me the exact processor type? in terminal: sysctl -a |grep cpu and find the actual intel part number. === It looks to me like there could be a misinterpretation of clang's output... features can be removed (-) or added (+x).
[Bug fortran/91642] ICE: Bad IO basetype (transfer_expr, at fortran/trans-io.c:2507)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91642 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/91642] ICE: Bad IO basetype (transfer_expr, at fortran/trans-io.c:2507)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91642 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-03 Ever confirmed|0 |1
[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 Thomas Koenig changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Jerry, I am away from my computer at the moment. Does zhis ring a bell?
[Bug target/71453] Spills to vector registers are sub-optimal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71453 H.J. Lu changed: What|Removed |Added Status|SUSPENDED |NEW CC|izamyatin at gmail dot com |crazylht at gmail dot com, ||skpgkp2 at gmail dot com --- Comment #5 from H.J. Lu --- commit 0ccf1b9d72ec54742f14d0ded84fa34cb5a48e5b Author: uros Date: Wed Aug 28 15:09:51 2019 + diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index f3b3a9a326fd..d2d84eb11663 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -18617,9 +18617,9 @@ ix86_register_move_cost (machine_mode mode, reg_class_t class1_i, where integer modes in SSE registers are not tieable because of missing QImode and HImode moves to, from or between MMX/SSE registers. */ -return MAX (8, SSE_CLASS_P (class1) - ? ix86_cost->hard_register.sse_to_integer - : ix86_cost->hard_register.integer_to_sse); +return (SSE_CLASS_P (class1) + ? ix86_cost->hard_register.sse_to_integer + : ix86_cost->hard_register.integer_to_sse); if (MAYBE_FLOAT_CLASS_P (class1)) return ix86_cost->hard_register.fp_move; removed the cost floor on inter-unit moves. It results in spills to vector registers.
[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 --- Comment #15 from Segher Boessenkool --- (In reply to jos...@codesourcery.com from comment #13) > These functions have to be expanded inline, unconditionally; there are no > library functions they can reliably fall back on in general. Ugh, yes. There probably *should* be, but oh well.
[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 --- Comment #14 from Segher Boessenkool --- (In reply to Wilco from comment #12) > > but we should really handle this with some non-signaling insns, not punt > > it to libm to do. > > Well we should simply commit Tamar's patch again since it works fine on any > IEEE targets and showed performance gains across many targets. Any issues > with weird 128-bit FP formats can be addressed separately. Do you have a link to those problems? And no, please don't regress us for no reason at all, it's really easy to *not* regress this on double-double.
[Bug c++/91644] [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00161.html
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 --- Comment #4 from Bernd Edlinger --- Hi Christophe, many thanks for your invaluable help. I think except this one all regressions are fixed or at least understood. Unfortunately I have a bit of trouble to reproduce this could you please give the exact config options and RUNTESTFLAGS, so I can build a cross to debug this?
[Bug target/91652] -march=skylake-avx512 -mno-fma -O2 generates FMA instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91652 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- If you don't want fma matched for code that originally didn't have it, perhaps better use -ffp-contract=off ?
[Bug tree-optimization/91504] Inlining misses some logical operation folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91504 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- I've installed Kamlesh's patch on the trunk.
[Bug tree-optimization/91504] Inlining misses some logical operation folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91504 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Tue Sep 3 20:13:22 2019 New Revision: 275354 URL: https://gcc.gnu.org/viewcvs?rev=275354=gcc=rev Log: PR tree-optimization/91504 * match.pd: Add ((~a & b) ^a) --> (a | b). PR tree-optimization/91504 gcc.dg/tree-ssa/pr91504.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr91504.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug target/91652] -march=skylake-avx512 -mno-fma -O2 generates FMA instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91652 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- VEX FMA is enabled by -mfma and EVEX FMA is enabled by -mavx512f. -mno-fma disables VEX FMA, but not EVEX FMA. Adding -mno-avx512f disables EVEX FMA.
[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- And ideally once this is fixed we would reevaluate if -Wenum-conversion should be part of -Wall vs -Wextra.
[Bug target/91652] New: -march=skylake-avx512 -mno-fma -O2 generates FMA instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91652 Bug ID: 91652 Summary: -march=skylake-avx512 -mno-fma -O2 generates FMA instructions Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joseph.weening at gmail dot com Target Milestone: --- Created attachment 46807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46807=edit program to demonstrate generation of FMA instructions On x86_64, compiling C code with -march=skylake-avx512 -mno-fma -O2 generates FMA instructions. (-mno-fma works correctly with -march=skylake or -march=haswell.) The attached program demonstrates the problem. It prints "d is 0.00" when not using FMA, and "d is -1.00" when using FMA. % gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/var/tmp/gcc/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.2.0/configure --prefix=/var/tmp/gcc --disable-multilib --enable-languages=c --with-gmp=/usr/local/gmp/6.1.2 --with-mpfr=/usr/local/mpfr/4.0.1 --with-mpc=/usr/local/mpc/1.1.0 Thread model: posix gcc version 9.2.0 (GCC) Command to demonstrate the bug: % gcc -march=skylake-avx512 -mno-fma -O2 fmabug.i && a.out Compiler errors, warnings: (none)
[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 --- Comment #13 from joseph at codesourcery dot com --- These functions have to be expanded inline, unconditionally; there are no library functions they can reliably fall back on in general.
[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 --- Comment #12 from Wilco --- (In reply to Segher Boessenkool from comment #11) > I currently have > > === > diff --git a/gcc/builtins.c b/gcc/builtins.c > index ad5135c..bc3d318 100644 > --- a/gcc/builtins.c > +++ b/gcc/builtins.c > @@ -9050,6 +9050,12 @@ fold_builtin_interclass_mathfn (location_t loc, tree > fnde >if (interclass_mathfn_icode (arg, fndecl) != CODE_FOR_nothing) > return NULL_TREE; > > + /* None of these builtins are ever exceptional, not even for signaling > NaNs, > + so we cannot do any of these optimizations that involve a floating > point > + comparison. */ > + if (flag_signaling_nans) > +return NULL_TREE; > + >mode = TYPE_MODE (TREE_TYPE (arg)); > >bool is_ibm_extended = MODE_COMPOSITE_P (mode); > === > > but we should really handle this with some non-signaling insns, not punt > it to libm to do. Well we should simply commit Tamar's patch again since it works fine on any IEEE targets and showed performance gains across many targets. Any issues with weird 128-bit FP formats can be addressed separately.
[Bug fortran/91650] [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91650 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch. By default, an error is issued. If one uses the -fallow-invalid-boz option, the code compiles with warnings and yields the same results that older versions of gfortran emitted.
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #28 from Iain Sandoe --- Author: iains Date: Tue Sep 3 18:56:04 2019 New Revision: 275346 URL: https://gcc.gnu.org/viewcvs?rev=275346=gcc=rev Log: [c-family] Backport fix for PCH / PR61250. When we are parsing a source file, the very first token might be a PRAGMA_GCC_PCH_PREPROCESS. This indicates that we are going read in a PCH file (named as the value of the pragma). If we don't see this pragma, then we know that it's OK to release any resources that the host might have set aside for the PCH file. There is a thinko in the current implementation, in that the decision to release resources is happening unconditionally right after the first token is extracted but before it's been checked or acted upon. This leads to the pch bug on Darwin, because we actually do release resources - which are subsequently (reasonably) assumed to be available when reading a PCH file. We then get random crashes or hangs depending on the interaction between unmmap and malloc. The bug is present everywhere but doesn't show on (say) Linux, since the release of PCH resources is a NOP there. This effects all the c-family front ends, because they all use c_lex_with_flags () to implement this. The solution is to check for the PRAGMA_GCC_PCH_PREPROCESS and only call c_common_no_more_pch () when that is not the first token. A secondary effect of the collection is that the name of the PCH file can be collected during the ggc_pch_read() reset of state. Therefore we should issue any diagnostic that might name the file before the collections are triggered. gcc/ 2019-09-03 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe PR pch/61250 * ggc-page.c (ggc_pch_read): Read the ggc_pch_ondisk structure and issue any diagnostics needed before collecting the pre-PCH state. gcc/c-family/ 2019-09-03 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe PR pch/61250 * c-lex.c (c_lex_with_flags): Don't call c_common_no_more_pch () from here. gcc/c/ 2019-09-03 Iain Sandoe Backport from mainline. 2019-08-23 Iain Sandoe PR pch/61250 * c-parser.c (c_parse_file): Call c_common_no_more_pch () after determining that the first token is not PRAGMA_GCC_PCH_PREPROCESS. gcc/cp/ 2019-09-03 Iain Sandoe Backported from mainline 2019-08-23 Iain Sandoe PR pch/61250 * parser.c (cp_parser_initial_pragma): Call c_common_no_more_pch () after determining that the first token is not PRAGMA_GCC_PCH_PREPROCESS. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/c-family/ChangeLog branches/gcc-8-branch/gcc/c-family/c-lex.c branches/gcc-8-branch/gcc/c/ChangeLog branches/gcc-8-branch/gcc/c/c-parser.c branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/parser.c branches/gcc-8-branch/gcc/ggc-page.c
[Bug lto/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 David Kredba changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from David Kredba --- Problem is gone.
[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #11 from Segher Boessenkool --- I currently have === diff --git a/gcc/builtins.c b/gcc/builtins.c index ad5135c..bc3d318 100644 --- a/gcc/builtins.c +++ b/gcc/builtins.c @@ -9050,6 +9050,12 @@ fold_builtin_interclass_mathfn (location_t loc, tree fnde if (interclass_mathfn_icode (arg, fndecl) != CODE_FOR_nothing) return NULL_TREE; + /* None of these builtins are ever exceptional, not even for signaling NaNs, + so we cannot do any of these optimizations that involve a floating point + comparison. */ + if (flag_signaling_nans) +return NULL_TREE; + mode = TYPE_MODE (TREE_TYPE (arg)); bool is_ibm_extended = MODE_COMPOSITE_P (mode); === but we should really handle this with some non-signaling insns, not punt it to libm to do.
[Bug fortran/91650] [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91650 kargl at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-03 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Changed ice-on-valid-code to ice-on-invalid-code. A BOZ cannot appear as an IO list item.
[Bug fortran/91651] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91651
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from G. Steinmetz ---
Working variants :
$ cat z2.f90
program p
integer :: z(2)
z = index('100101', '10', [.false.,.true.])
print *, z
end
$ gfortran-10-20190901 z2.f90 && ./a.out
1 4
$ cat z3.f90 # scalar back
program p
integer :: z(2)
z = index('100101', '10', .false., kind=4)
print *, z
end
$ gfortran-10-20190901 z3.f90 && ./a.out
1 1
[Bug fortran/91651] New: ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91651
Bug ID: 91651
Summary: ICE in gfc_trans_assignment_1, at
fortran/trans-expr.c:11010
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 gfortran-5.
Together with an argument KIND= (1,2,4,8,16) :
$ cat z1.f90
program p
integer :: z(2)
z = index('100101', '10', [.false.,.true.], kind=4)
print *, z
end
$ gfortran-10-20190901 -c z1.f90
z1.f90:3:0:
3 |z = index('100101', '10', [.false.,.true.], kind=4)
|
internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:11010
0x705774 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11009
0x6c4a0f trans_code
../../gcc/fortran/trans.c:1852
0x6ed7a4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6779
0x6775be translate_all_program_units
../../gcc/fortran/parse.c:6253
0x6775be gfc_parse_file()
../../gcc/fortran/parse.c:6492
0x6c14bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
[Bug fortran/91650] New: [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91650 Bug ID: 91650 Summary: [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370 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: --- Follow-up of pr88227, since about 20190728 : $ cat z1.f90 program p print *, b'10110' print *, o'10110' print *, z'10110' end $ gfortran-10-20190901 -c z1.f90 z1.f90:2:0: 2 |print *, b'10110' | internal compiler error: in gfc_conv_constant_to_tree, at fortran/trans-const.c:370 0x6e0cb5 gfc_conv_constant_to_tree(gfc_expr*) ../../gcc/fortran/trans-const.c:370 0x6e0e17 gfc_conv_constant(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-const.c:422 0x6f47fa gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8591 0x6fb175 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool) ../../gcc/fortran/trans-expr.c:8732 0x723717 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2582 0x6c4cd7 trans_code ../../gcc/fortran/trans.c:2072 0x7211fe build_dt ../../gcc/fortran/trans-io.c:2026 0x6c4cb7 trans_code ../../gcc/fortran/trans.c:2044 0x6ed7a4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6779 0x6775be translate_all_program_units ../../gcc/fortran/parse.c:6253 0x6775be gfc_parse_file() ../../gcc/fortran/parse.c:6492 0x6c14bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 Thanks for working on these issues ...
[Bug fortran/91649] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91649 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Some more (e.g. accepts a non-conformant type value) : $ cat z4.f90 program p integer :: x(1) = findloc([1, 2, 1], '1', back=.true.) print *, x end $ cat z5.f90 program p type t end type integer :: x(1) = findloc([1, 2, 1], t(), back=.true.) print *, x end $ cat z6.f90 program p logical :: back = .true. integer :: x(1) = findloc([1, 2, 1], 2.0, back=back) print *, x end $ gfortran-10-20190901 -c z4.f90 $ gfortran-10-20190901 -c z5.f90 $ gfortran-10-20190901 -c z6.f90 z6.f90:3:50: 3 |integer :: x(1) = findloc([1, 2, 1], 2.0, back=back) | 1 Error: Parameter 'back' at (1) has not been declared or is a variable, which does not reduce to a constant expression
[Bug fortran/91649] New: ICE in gfc_resolve_findloc, at fortran/iresolve.c:1827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91649 Bug ID: 91649 Summary: ICE in gfc_resolve_findloc, at fortran/iresolve.c:1827 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: --- The ICE slipped in between 20181021 and 20181028 : $ cat z1.f90 program p logical :: back = .true. integer :: x(1) = findloc([1, 2, 1], '1', back=back) print *, x end $ cat z2.f90 program p type t end type logical :: back = .false. integer :: x(1) = findloc([1, 2, 1], t(), back=back) print *, x end $ cat z3.f90 program p character(4) :: c = '1234' integer :: x(1) = findloc([1, 2, 1], c, back=.true.) print *, x end $ gfortran-10-20190901 -c z1.f90 z1.f90:3:40: 3 |integer :: x(1) = findloc([1, 2, 1], '1', back=back) |1 internal compiler error: Cannot convert 'CHARACTER(1)' to 'INTEGER(4)' at (1) 0x61c001 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1363 0x63aa36 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int) ../../gcc/fortran/intrinsic.c:5241 0x64600a gfc_resolve_findloc(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/iresolve.c:1827 0x62f99d resolve_intrinsic ../../gcc/fortran/intrinsic.c:4477 0x62f99d do_simplify ../../gcc/fortran/intrinsic.c:4596 0x639fde gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4941 0x6916e1 resolve_unknown_f ../../gcc/fortran/resolve.c:2896 0x6916e1 resolve_function ../../gcc/fortran/resolve.c:3233 0x68db05 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6954 0x61fe84 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3037 0x623030 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3085 0x60f2a2 variable_decl ../../gcc/fortran/decl.c:2835 0x60f2a2 gfc_match_data_decl() ../../gcc/fortran/decl.c:6062 0x66f983 match_word ../../gcc/fortran/parse.c:65 0x66f983 decode_statement ../../gcc/fortran/parse.c:376 0x6713ca next_free ../../gcc/fortran/parse.c:1251 0x6713ca next_statement ../../gcc/fortran/parse.c:1483 0x6729eb parse_spec ../../gcc/fortran/parse.c:3881 0x6757dc parse_progunit ../../gcc/fortran/parse.c:5799 0x676ea9 gfc_parse_file() ../../gcc/fortran/parse.c:6339
[Bug fortran/91648] New: [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Bug ID: 91648 Summary: [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009 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: --- Behavior changed between 20180909 and 20180916 : $ cat z1.f90 module m type t contains final :: s end type contains subroutine s(x) type(t) :: x class(*), allocatable :: y y = x end end $ gfortran-9-20180909 -c z1.f90 $ $ gfortran-10-20190901 -c z1.f90 f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:2009 0x5fcc8f generate_finalization_wrapper ../../gcc/fortran/class.c:2009 0x5fcc8f gfc_find_derived_vtab(gfc_symbol*) ../../gcc/fortran/class.c:2484 0x5fe428 gfc_find_vtab(gfc_typespec*) ../../gcc/fortran/class.c:2862 0x64d3a2 gfc_match_assignment() ../../gcc/fortran/match.c:1375 0x66f8d0 match_word ../../gcc/fortran/parse.c:65 0x66f8d0 decode_statement ../../gcc/fortran/parse.c:361 0x6713ca next_free ../../gcc/fortran/parse.c:1251 0x6713ca next_statement ../../gcc/fortran/parse.c:1483 0x6729eb parse_spec ../../gcc/fortran/parse.c:3881 0x6757dc parse_progunit ../../gcc/fortran/parse.c:5799 0x675bc1 parse_contained ../../gcc/fortran/parse.c:5700 0x6769e7 parse_module ../../gcc/fortran/parse.c:6072 0x676d17 gfc_parse_file() ../../gcc/fortran/parse.c:6375 0x6c14bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug tree-optimization/91597] [9/10 Regression] GCC miscompiles a branch depending on a pointer tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91597 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/91597] [9/10 Regression] GCC miscompiles a branch depending on a pointer tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91597 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Sep 3 16:55:31 2019 New Revision: 275345 URL: https://gcc.gnu.org/viewcvs?rev=275345=gcc=rev Log: PR tree-optimization/91597 * tree-vrp.c (extract_range_from_binary_expr): Remove unsafe BIT_AND_EXPR optimization for pointers, even if both operand ranges don't include NULL, the result can be NULL. * gcc.c-torture/execute/pr91597.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91597.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-vrp.c
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/91647] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #4 from Iain Sandoe --- (In reply to Martin Sebor from comment #3) > I get the following error when running a cross-compiler for > x86_64-apple-darwin: > > xgcc: error: unrecognized command-line option > '-asm_macosx_version_min=10.5'; did you mean '-asm_macosx_version_min='? > > Is there a different target I should try or something else I can do to > configure it to get around it? what was the configuration line? you can't expect to build more than cc1/cc1plus, unless you go through the process of build a Mach-O 'binptils' - which would be unnecessary here. .. (if there's a problem - I can try something on gcc122 later)
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Sep 3 16:46:06 2019 New Revision: 275344 URL: https://gcc.gnu.org/viewcvs?rev=275344=gcc=rev Log: PR target/91604 * config/i386/i386-expand.c (split_double_mode): If there is more than one MEM operand and they are rtx_equal_p, reuse lo_half/hi_half from already split matching MEM operand instead of calling adjust_address again. * gcc.target/i386/pr91604.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr91604.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91647] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #3 from Martin Sebor --- I get the following error when running a cross-compiler for x86_64-apple-darwin: xgcc: error: unrecognized command-line option '-asm_macosx_version_min=10.5'; did you mean '-asm_macosx_version_min='? Is there a different target I should try or something else I can do to configure it to get around it?
[Bug tree-optimization/91647] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Iain Sandoe changed: What|Removed |Added Summary|[10 Regression] new FAILs |new FAILs for |for Warray-bounds-8 and |Warray-bounds-8 and |Wstringop-overflow-3.C |Wstringop-overflow-3.C --- Comment #2 from Iain Sandoe --- sorry, not a regression - I guess the tests never passed.
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Iain Sandoe changed: What|Removed |Added Target||*-*-apple-darwin* Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2019-09-03 CC||msebor at gcc dot gnu.org Host||*-*-apple-darwin* Ever confirmed|0 |1 Target Milestone|--- |10.0 Build||*-*-apple-darwin* --- Comment #1 from Iain Sandoe --- this is independent of arch, OS version or m64/m32 note that Darwin is fPIC by default. it's reproducible on a stage1, so should be possible on a cross (w/out needing 'binptils') it looks like the Warray-bounds-8 is always producing: "is above array bounds of" and Wstringop-overflow-3.C is producing: "writing 1 byte into a region of size 0"
[Bug tree-optimization/91647] New: [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Bug ID: 91647 Summary: [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- between 274983 and 275034 FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 335) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 337) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 351) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 353) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 365) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 367) FAIL: g++.dg/warn/Wstringop-overflow-3.C -std=gnu++14 (test for warnings, line 333) FAIL: g++.dg/warn/Wstringop-overflow-3.C -std=gnu++14 (test for warnings, line 349) FAIL: g++.dg/warn/Wstringop-overflow-3.C -std=gnu++14 (test for warnings, line 363)
[Bug fortran/91646] New: gfortran takes long time and consumes a lot of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91646 Bug ID: 91646 Summary: gfortran takes long time and consumes a lot of memory Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: luomo1138 at yahoo dot com Target Milestone: --- Created attachment 46806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46806=edit source file demonstrating issue Hello, I have an issue with gfortran taking a very long time and consuming a lot of memory to compile a file. The attached file compiles in about one second when using either gfortran 4.9.2 or the Intel Fortran compiler (ifort). However, when I use gfortran 9.1.0, that file takes a very long time to compile. When I compile the file with this command: ``` gfortran -Wall -c -pass-exit-codes -ffree-line-length-0 -g LVT_statsDataMod.F90 ``` it takes 10 minutes to compile and uses approximately 20GB of memory. Similarly for "-O0". When I use either "-O1" or "-O2", it takes over an hour to compile and uses at least 35GB of memory. (I do not know exactly how long because I killed it after one hour.) I have seen similar behaviour with gfortran 7.3 and 8.1 as well. I also compiled with "-Wextra" and "-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations", but nothing was reported. Do you have any suggestions? * Exact version, system type, and GCC build options: ``` $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/gpfsm/dulocal/sles11/other/SLES11.3/gcc/9.1/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /gpfsm/dnbsrc/other/GCC/SLES11/9.1/gcc-9.1.0/configure --prefix=/gpfsm/dulocal/sles11/other/SLES11.3/gcc/9.1 --enable-languages=all --enable-bootstrap Thread model: posix gcc version 9.1.0 (GCC) ``` * complete command line: ``` gfortran -Wall -c -pass-exit-codes -ffree-line-length-0 -g LVT_statsDataMod.F90 ``` * compiler output: None * preprocessed file: Attached file does not require any preprocessing. Here is the version of gfortran that performs as I expect: ``` $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/gpfsm/dulocal/sles11/other/SLES11.3/gcc/4.9.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /gpfsm/dnbsrc/other/GCC/SLES11/4.9.2/gcc-4.9.2/configure --prefix=/usr/local/other/SLES11.3/gcc/4.9.2 --enable-languages=all --enable-bootstrap Thread model: posix gcc version 4.9.2 (GCC) ``` Thanks, Jim
[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457 --- Comment #13 from Martin Sebor --- (In reply to Christophe Lyon from comment #10) Yes, the warning is intended and Glibc was just patched to avoid it: https://sourceware.org/ml/glibc-cvs/2019-q3/msg00459.html (In reply to Iain Sandoe from comment #11) I haven't gone back to understand why r273783 makes the difference on hppa2.0w-hp-hpux11.11 and answer my question in comment #6. The warnings in this area (-Warray-bounds and the new -Wstringop-overflow for [multi]character assignments) are sensitive to subtle differences in the IL, which in turn seems to change from target to target depending on what the folder decides to transform the assignments to. As each warning is implemented differently and runs at part of a different pass, getting them to trigger consistently across all targets is like herding cats. Figuring out what the folder does on each target and parameterizing the tests on the variables that influence its decisions is also not trivial. Anyway, since this bug is specific to Warray-bounds-4.C on hppa2.0w-hp-hpux11.11, opening a searate issue for the Warray-bounds-8.C failures on Darwin might be best.
[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457 --- Comment #12 from Iain Sandoe --- it looks like Wstringop-overflow-3.C also started failing at the same time as Warray-bounds-8, presumably these are all connected.
[Bug fortran/91643] [10 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91643 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457 --- Comment #11 from Iain Sandoe --- on Darwin, the Warray-bounds-4 is failing for c++98,14,17 Warray-bounds-8 has started failing between 274983 and 275034 with the same kind of pattern - I can file a new PR if you regard the second as distinct.
[Bug c++/91645] New: Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Bug ID: 91645
Summary: Missed optimization with sqrt(x*x)
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lisyarus at gmail dot com
Target Milestone: ---
Based on a discussion on stackoverflow:
https://stackoverflow.com/questions/57673825/how-to-force-gcc-to-assume-that-a-floating-point-expression-is-non-negative.
With gcc-trunk and '-std=c++17 -O3', the function
float test (float x)
{
return std::sqrt(x*x);
}
produces the following assembly:
test(float):
mulss xmm0, xmm0
pxorxmm2, xmm2
ucomiss xmm2, xmm0
movaps xmm1, xmm0
sqrtss xmm1, xmm1
ja .L8
movaps xmm0, xmm1
ret
.L8:
sub rsp, 24
movss DWORD PTR [rsp+12], xmm1
callsqrtf
movss xmm1, DWORD PTR [rsp+12]
add rsp, 24
movaps xmm0, xmm1
ret
As far as I can tell, it calls sqrtf, unless the argument to sqrt is >= 0, to
check for negatives/NaN's and set the appropriate errno. The behavior is
reasonable, as expected.
Adding '-fno-math-errno', '-ffast-math', or '-ffinite-math-only' removes all
the clutter and compiles the same code into the neat
test(float):
mulss xmm0, xmm0
sqrtss xmm0, xmm0
ret
Now, the problem is that GCC doesn't seem to optimize away the call to sqrtf
based on some surrounding code. As an example, it would be neat to have this
(or something similar) to get compiled into the same mulss-sqrtss-ret:
float test (float x)
{
float y = x*x;
if (y >= 0.f)
return std::sqrt(y);
__builtin_unreachable();
}
If I understand it correctly, the 'y >= 0.f' excludes 'y' being NaN and 'y'
being negative (though this is excluded by 'y = x*x'), so there is no need to
check if the argument to `std::sqrt` is any bad, enabling to just do 'sqrtss'
and return.
Furthemore, adding e.g. '#pragma GCC optimize ("no-math-errno")' before the
'test' function doesn't lead to optimizing it either, though I'm not sure
whether this is expected to work and/or requires a separate bugtracker issue.
[Bug middle-end/91613] [10 regression][arm] gcc.dg/pr83930.c ICE since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91613 --- Comment #1 from Bernd Edlinger --- Author: edlinger Date: Tue Sep 3 14:37:41 2019 New Revision: 275342 URL: https://gcc.gnu.org/viewcvs?rev=275342=gcc=rev Log: 2019-09-03 Bernd Edlinger PR middle-end/91603 PR middle-end/91612 PR middle-end/91613 * expr.c (expand_expr_real_1): Handle unaligned decl_rtl and SSA_NAME referring to CONSTANT_P correctly. testsuite: 2019-09-03 Bernd Edlinger PR middle-end/91603 * testsuite/gcc.target/arm/pr91603.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr91603.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/91603] Unaligned access in expand_assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91603 --- Comment #1 from Bernd Edlinger --- Author: edlinger Date: Tue Sep 3 14:37:41 2019 New Revision: 275342 URL: https://gcc.gnu.org/viewcvs?rev=275342=gcc=rev Log: 2019-09-03 Bernd Edlinger PR middle-end/91603 PR middle-end/91612 PR middle-end/91613 * expr.c (expand_expr_real_1): Handle unaligned decl_rtl and SSA_NAME referring to CONSTANT_P correctly. testsuite: 2019-09-03 Bernd Edlinger PR middle-end/91603 * testsuite/gcc.target/arm/pr91603.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr91603.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 --- Comment #5 from Bernd Edlinger --- Author: edlinger Date: Tue Sep 3 14:37:41 2019 New Revision: 275342 URL: https://gcc.gnu.org/viewcvs?rev=275342=gcc=rev Log: 2019-09-03 Bernd Edlinger PR middle-end/91603 PR middle-end/91612 PR middle-end/91613 * expr.c (expand_expr_real_1): Handle unaligned decl_rtl and SSA_NAME referring to CONSTANT_P correctly. testsuite: 2019-09-03 Bernd Edlinger PR middle-end/91603 * testsuite/gcc.target/arm/pr91603.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr91603.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-03 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug other/79543] Inappropriate "ld --version" checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79543 --- Comment #5 from Chung-Lin Tang --- Author: cltang Date: Tue Sep 3 14:10:26 2019 New Revision: 275341 URL: https://gcc.gnu.org/viewcvs?rev=275341=gcc=rev Log: 2019-09-03 Chung-Lin Tang libatomic/ PR other/79543 * acinclude.m4 (LIBAT_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libffi/ PR other/79543 * acinclude.m4 (LIBAT_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libgomp/ PR other/79543 * acinclude.m4 (LIBGOMP_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libitm/ PR other/79543 * acinclude.m4 (LIBITM_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libstdc++-v3/ PR other/79543 * acinclude.m4 (GLIBCXX_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. Modified: trunk/libatomic/ChangeLog trunk/libatomic/acinclude.m4 trunk/libatomic/configure trunk/libffi/ChangeLog trunk/libffi/acinclude.m4 trunk/libffi/configure trunk/libgomp/ChangeLog trunk/libgomp/acinclude.m4 trunk/libgomp/configure trunk/libitm/ChangeLog trunk/libitm/acinclude.m4 trunk/libitm/configure trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug c++/91618] template-id required to friend a function template, even for a qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
--- Comment #3 from Marek Polacek ---
So the problem is in set_decl_namespace. We are called with decl=f, scope=::,
friendp=true. It used to have
- /* Writing "int N::i" to declare a variable within "N" is invalid. */
- if (scope == current_namespace)
-{
- if (at_namespace_scope_p ())
- error ("explicit qualification in declaration of %qD",
- decl);
- return;
-}
so before r249385 we returned without an error but now we look "f" up, find a
TEMPLATE_DECL, which decls_match says doesn't match the FUNCTION_DECL "f", so
we issue the not_found error.
Nathan, any ideas?
[Bug c++/91644] [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644 --- Comment #2 from Marek Polacek --- I was afraid that that might happen. Mine.
[Bug c++/91644] [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug libstdc++/91308] [7 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 --- Comment #7 from Jonathan Wakely --- Fixed at r275296
[Bug middle-end/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 --- Comment #4 from Christophe Lyon --- > I don't know yet for pr91613 This patch fixes pr91613 too.
[Bug libstdc++/91308] [7 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- On gcc-8-branch, r275193 is causing FAIL: 20_util/unique_ptr/assign/48635_neg.cc (test for errors, line 307) FAIL: 20_util/unique_ptr/assign/48635_neg.cc (test for errors, line 566) FAIL: 20_util/unique_ptr/assign/48635_neg.cc (test for excess errors) FAIL: 20_util/unique_ptr/cons/cv_qual_neg.cc (test for errors, line 473) FAIL: 20_util/unique_ptr/cons/cv_qual_neg.cc (test for excess errors)
[Bug tree-optimization/90278] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90278 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Really.
[Bug preprocessor/91639] [10 Regression] FAIL: gcc.dg/plugin/location-overflow-test-pr83173.c -fplugin=./location_overflo w_plugin.so scan-file-not # (?!1 [^\r\n]+location-overflow-test-pr83173-1.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91639
Jakub Jelinek changed:
What|Removed |Added
Target|hppa-unknown-linux-gnu |
CC||jakub at gcc dot gnu.org,
||nathan at gcc dot gnu.org
Host|hppa-unknown-linux-gnu |
Build|hppa-unknown-linux-gnu |
--- Comment #1 from Jakub Jelinek ---
Broken by r275034 everywhere, not just hppa.
location-overflow-test-pr83173.i used to contain:
# 1 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c"
# 1 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h"
1
# 1
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h" 1
# 2 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h"
2
# 1
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-2.h" 1
# 3 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h"
2
# 7 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c"
2
int
main ()
{
return 0;
}
but after the change it is:
# 1 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c"
# 1 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h"
1
# 1
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h" 1
# 2 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h"
2
# 2
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h"
# 1
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-2.h" 1
# 3
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h" 2
# 2 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h"
2
int
main ()
{
return 0;
}
# 7 "/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c"
2
The difference:
--- location-overflow-test-pr83173.i.r2750332019-09-03 13:39:33.352482636
+0200
+++ location-overflow-test-pr83173.i.r2750342019-09-03 13:37:10.754649084
+0200
@@ -13,13 +13,15 @@
# 1
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h" 1
# 2
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h" 2
+# 2
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h"
# 1
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-2.h" 1
-# 3
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h" 2
-# 7
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c" 2
+# 3
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h" 2
+# 2
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h" 2
int
main ()
{
return 0;
}
+# 7
"/usr/src/gcc/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c" 2
[Bug target/87767] Missing AVX512 memory broadcast for constant vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So for #c3 you are essentially asking for a .rodata size optimization. The problem with that is especially that it works only for selected EVEX encoded instructions and with the multitude of AVX512XX ISAs, in many define_insns we have non-EVEX variants mixed with EVEX variants, e.g. for the case when something is only EVEX supported with VL, DQ, BW etc. and thus even if we add a machine reorg optimization that walks constant pool MEMs in a function and tries to transform those into broadcast, it is non-trivial to find out when it is safe and when not (plus, it is useful only if we manage to optimize all accesses to that constant pool constant).
[Bug target/91591] Arc: ICE in trunc_int_for_mode, at explow.c:60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91591 --- Comment #3 from Giulio Benetti --- Created attachment 46805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46805=edit Preprocessed file Here is .ii file obtained building with -save-temps.
[Bug c++/91644] [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- DECL_TEMPLATE_INFO is NULL for such VAR_DECLs, so: 7183 /* Handle `constinit' on variable templates. */ 7184 if (flags & LOOKUP_CONSTINIT) 7185TINFO_VAR_DECLARED_CONSTINIT (DECL_TEMPLATE_INFO (decl)) = true; segfaults.
[Bug c++/91644] [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Build|10.0.0 20190902 | |(experimental) |
[Bug fortran/91588] ICE in check_inquiry, at fortran/expr.c:2673
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91588 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-03 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Also an old issue, ICEs down to at least gfortran-5. down to at least gfortran-4.8.
[Bug fortran/91566] [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91566 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-03 Known to work||8.3.0 Ever confirmed|0 |1 Known to fail||10.0, 9.2.1 --- Comment #1 from Dominique d'Humieres --- > Changed between 20180624 and 20180708 : Reduced range 20180624 and 20180703
[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.3
--- Comment #1 from Richard Biener ---
Note gimplification fails because we are evaluating in an lvalue context but
got -_7 in the end. In the past we've hacked around Fortran oddities by
doing tem = -_7 and returning tem here, simply using a temporary as lvalue
which means the value assigned is lost (IIRC for things like assinging to
a literal constant which could happen in parameter context).
Full statement:
-_7 = MEM[(real(kind=4)[3] *)_4][_5]
and .original has
D.3938 = -1;
S.3 = 1;
while (1)
{
if (S.3 > 3) goto L.2;
-z[S.3 + -1] = (*(real(kind=4)[3] * restrict) atmp.0.data)[S.3 +
D.3938];
S.3 = S.3 + 1;
}
L.2:;
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #12 from Kito Cheng --- Hi Zdenek: I can reproduce for all new 3 testcases, it seems like cause by same issue, thanks you provide more testcase for that!
[Bug preprocessor/91639] [10 Regression] FAIL: gcc.dg/plugin/location-overflow-test-pr83173.c -fplugin=./location_overflo w_plugin.so scan-file-not # (?!1 [^\r\n]+location-overflow-test-pr83173-1.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91639 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/91644] New: [C++20] constinit segfaults inside templated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91644
Bug ID: 91644
Summary: [C++20] constinit segfaults inside templated functions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Created attachment 46804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46804=edit
constinit test cases
Hi.
Reading P1143R2 my understanding is that the constinit initialization should be
also possible inside a function scope. If I'm mistaken, it should be
diagnosted and rejected. Nonetheless, it currently segfaults the compiler, if
the function happens to be templated, so it needs some adjustment anyway:
template < typename T >
static void function() {
static __constinit auto value = 0;
}
Attached a few test cases.
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #11 from Zdenek Sojka --- Created attachment 46803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46803=edit another testcase
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #10 from Zdenek Sojka --- Created attachment 46802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46802=edit another testcase
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #9 from Zdenek Sojka --- Created attachment 46801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46801=edit another testcase
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #8 from Jakub Jelinek --- Certainly both register_operand predicate as well as the usual register constraints don't rule out subregs even after reload. can_create_pseudo_p () is false after reload of course. In theory, what you could do after reload if the operand is a paradoxical subreg would be just use SUBREG_REG in that case instead of the subreg itself.
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #7 from Kito Cheng --- Hi Jakub: > that doesn't mean paradoxical subregs can't appear there, just it will be > less likely. Does it mean paradoxical subregs will appear during intermediate result even after reload, so for such split pattern with smaller mode than word_mode we should check it's paradoxical subreg or not? Thanks
[Bug target/87767] Missing AVX512 memory broadcast for constant vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767
Matthias Kretz changed:
What|Removed |Added
CC||kretz at kde dot org
--- Comment #3 from Matthias Kretz ---
Here's a link to quickly survey the state of the optimization:
https://godbolt.org/z/P8FFSB
The broadcast contraction generally exists for 32 and 64 bit operands (i.e. 8
and 16 bit integers do not support memory broadcasts).
Note that I also added 8 Byte vectors of float and int into my test case. Those
should also use the {1to4} broadcast.
Test case (C++14):
auto f(float a [[gnu::vector_size(64)]]) {
return a OP 101;
}
auto f(float a [[gnu::vector_size(32)]]) {
return a OP 101;
}
auto f(float a [[gnu::vector_size(16)]]) {
return a OP 101;
}
auto f(float a [[gnu::vector_size(8)]]) {
return a OP 101;
}
auto f(double a [[gnu::vector_size(64)]]) {
return a OP 101;
}
auto f(double a [[gnu::vector_size(32)]]) {
return a OP 101;
}
auto f(double a [[gnu::vector_size(16)]]) {
return a OP 101;
}
auto f(int a [[gnu::vector_size(64)]]) {
return a OP 101;
}
auto f(int a [[gnu::vector_size(32)]]) {
return a OP 101;
}
auto f(int a [[gnu::vector_size(16)]]) {
return a OP 101;
}
auto f(int a [[gnu::vector_size(8)]]) {
return a OP 101;
}
auto f(long long a [[gnu::vector_size(64)]]) {
return a OP 101;
}
auto f(long long a [[gnu::vector_size(32)]]) {
return a OP 101;
}
auto f(long long a [[gnu::vector_size(16)]]) {
return a OP 101;
}
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #6 from Jakub Jelinek --- Other problematic splitters are zero_extendsidi2, zero_extendhi2, extend2, dunno if I haven't missed something else. While they are all post-reload splitters, that doesn't mean paradoxical subregs can't appear there, just it will be less likely.
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #5 from Kito Cheng --- Hi Zdenek: Could you share more testcase? I've a patch is based on Jakub's one. Thanks :)
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output (CVE-2019-15847)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 Richard Biener changed: What|Removed |Added Known to work||10.0, 6.5.0, 7.4.1, 8.3.1, ||9.2.1 Target Milestone|--- |7.5 Known to fail||7.1.0, 7.4.0, 8.3.0, 9.2.0 --- Comment #19 from Richard Biener --- DARN (or power9) is not supported in GCC 6 or older.
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635 --- Comment #4 from Zdenek Sojka --- (In reply to Jakub Jelinek from comment #3) > Looks like a backend bug to me. ... > fixes this, but I don't have a way to test riscv, plus the backend has > several similar problems elsewhere. I can provide several other testcases where code using shifts is miscompiled.
[Bug tree-optimization/91597] [9/10 Regression] GCC miscompiles a branch depending on a pointer tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91597 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Sep 3 07:50:46 2019 New Revision: 275330 URL: https://gcc.gnu.org/viewcvs?rev=275330=gcc=rev Log: PR tree-optimization/91597 * tree-vrp.c (extract_range_from_binary_expr): Remove unsafe BIT_AND_EXPR optimization for pointers, even if both operand ranges don't include NULL, the result can be NULL. * gcc.c-torture/execute/pr91597.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr91597.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/91433] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 --- Comment #7 from George Fan --- echo $CFLAGS ( -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=32 -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT -ftree-loop-distribute-patterns -Wl,-z -Wl,now -Wl,-z -Wl,relro -fno-semantic-interposition -ffat-lto-objects -fno-signed-zeros -fno-trapping-math -fassociative-math -Wl,-sort-common -Wl,--enable-new-dtags -mtune=skylake )
[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.2 Known to fail||8.1.0 --- Comment #8 from Richard Biener --- Fixed.
[Bug middle-end/91433] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 --- Comment #6 from George Fan --- Created attachment 46800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46800=edit botan regression
[Bug middle-end/91433] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 --- Comment #5 from George Fan --- The test case is as follows Environment, CPU, Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz * 12 cores with hyperthreading MEM, Dell Vostro 3670 8G DISK, nvme 256G OS, from clear linux 28950 to clear linux 29070 gcc, from 8.3.0-433 to 9.0-454 phoronix, v8.4.1 botan, 1.4.0 CMD, phoronix-test-suite install botan-1.4.0 ( tar -xf Botan-2.8.0.tgz cd Botan-2.8.0 python3 ./configure.py make -j $NUM_CPU_CORES ) phoronix-test-suite run botan-1.4.0 (choose Blowfish)
