[Bug libfortran/97017] New: The function determine_precision is called twice for each formatted real write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97017 Bug ID: 97017 Summary: The function determine_precision is called twice for each formatted real write Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at charter dot net Target Milestone: --- I discovered this while working on the EX formattting feature. The determine_precision function is called by both get_precision and inside the macro FORMAT_FLOAT used by get_float_string. To me this implies we have something factored wrong as we should not have to call it twice to get things done. (a small performance issue as well as obscure) A simple test case will show the issue in a debugger: ! pr93727 EX Format Specifiers program main implicit none real(4) :: r4 real(8) :: r8 r4 = 3.14158_4 r8 = 12.3456789_8 print *, r4, r8 end program main
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #10 from acsawdey at gcc dot gnu.org --- For now, disabling use of POImode for expansion of memcpy/memmove to avoid this problem while we figure out the real fix: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553672.html
[Bug target/97016] New: [i386] _MM_CMPINT_ENUM type is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97016
Bug ID: 97016
Summary: [i386] _MM_CMPINT_ENUM type is missing
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
The _mm{,256,512}_cmp_epi{8,16,32,64}_mask functions take a _MM_CMPINT_ENUM
according to the Intel Intrinsics Guide (e.g.,
),
but in GCC they take an int.
FWIW ICC and clang both define an enum. I haven't checked MSVC.
Using an int is more consistent with other Intel SIMD APIs, but it seems Intel
has chosen to break tradition here and use an enum.
[Bug analyzer/96798] Analyzer failures on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from David Malcolm --- Hopefully the above commits fix this for you; marking as resolved. Please reopen if I've messed up.
[Bug analyzer/96798] Analyzer failures on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798 --- Comment #13 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:b7028f060c6760b336b416897412e327ded12ab5 commit r11-3130-gb7028f060c6760b336b416897412e327ded12ab5 Author: David Malcolm Date: Mon Aug 31 15:55:45 2020 -0400 analyzer: stricter handling of non-pure builtins [PR96798] Amongst other things PR analyzer/96798 notes that region_model::on_call_pre treats any builtin that hasn't been coded yet as a no-op (albeit with an unknown return value), which is wrong for non-pure builtins. This patch updates that function's handling of such builtins so that it instead conservatively assumes that any escaped/reachable regions can be affected by the call, and implements enough handling of specific builtins to avoid regressing the testsuite (I hope). gcc/analyzer/ChangeLog: PR analyzer/96798 * region-model-impl-calls.cc (region_model::impl_call_memcpy): New. (region_model::impl_call_strcpy): New. * region-model.cc (region_model::on_call_pre): Flag unhandled builtins that are non-pure as having unknown side-effects. Implement BUILT_IN_MEMCPY, BUILT_IN_MEMCPY_CHK, BUILT_IN_STRCPY, BUILT_IN_STRCPY_CHK, BUILT_IN_FPRINTF, BUILT_IN_FPRINTF_UNLOCKED, BUILT_IN_PUTC, BUILT_IN_PUTC_UNLOCKED, BUILT_IN_FPUTC, BUILT_IN_FPUTC_UNLOCKED, BUILT_IN_FPUTS, BUILT_IN_FPUTS_UNLOCKED, BUILT_IN_FWRITE, BUILT_IN_FWRITE_UNLOCKED, BUILT_IN_PRINTF, BUILT_IN_PRINTF_UNLOCKED, BUILT_IN_PUTCHAR, BUILT_IN_PUTCHAR_UNLOCKED, BUILT_IN_PUTS, BUILT_IN_PUTS_UNLOCKED, BUILT_IN_VFPRINTF, BUILT_IN_VPRINTF. * region-model.h (region_model::impl_call_memcpy): New decl. (region_model::impl_call_strcpy): New decl. gcc/testsuite/ChangeLog: PR analyzer/96798 * gcc.dg/analyzer/memcpy-1.c: New test. * gcc.dg/analyzer/strcpy-1.c: New test.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #18 from Peter Bergner ---
(In reply to Peter Bergner from comment #17)
> const poly_uint16_pod mode_precision[NUM_MACHINE_MODES] =
> {
> ...
> { 4 * BITS_PER_UNIT }, /* SF */
> { 8 * BITS_PER_UNIT }, /* DF */
> { 126 }, /* KF */
> { 127 }, /* TF */
> { 128 }, /* IF */
> ...
>
> Why aren't KFmode, IFmode and TFmode all 128??? Mike?
This comes from rs6000-modes.h:
/* We order the 3 128-bit floating point types so that IFmode (IBM 128-bit
floating point) is the 128-bit floating point type with the highest
precision (128 bits). This so that machine independent parts of the
compiler do not try to widen IFmode to TFmode on ISA 3.0 (power9) that has
hardware support for IEEE 128-bit. We set TFmode (long double mode) in
between, and KFmode (explicit __float128) below it.
We won't encounter conversion from IEEE 128-bit to IBM 128-bit because we
don't have insns to support the IBM 128-bit aritmetic operations. */
#ifndef RS6000_MODES_H
#define RS6000_MODES_H 1
#define FLOAT_PRECISION_IFmode 128
#define FLOAT_PRECISION_TFmode 127
#define FLOAT_PRECISION_KFmode 126
[Bug objc++/97015] New: [11 regression] ICE in set_decl_context_in_fn, at cp/name-lookup.c:2862 after r11-3100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97015 Bug ID: 97015 Summary: [11 regression] ICE in set_decl_context_in_fn, at cp/name-lookup.c:2862 after r11-3100 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:f40866967d69079fdde293feb32d2eb52cb93cc8, r11-3100 make -k check-gcc RUNTESTFLAGS=dg.exp=obj-c++.dg/syntax-error-9.mm FAIL: obj-c++.dg/syntax-error-9.mm -fgnu-runtime (internal compiler error) FAIL: obj-c++.dg/syntax-error-9.mm -fgnu-runtime (test for excess errors) # of expected passes3 # of unexpected failures2 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/obj-c++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/obj-c++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/obj-c++.dg/syntax-error-9.mm -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -fgnu-runtime -ansi -pedantic-errors -Wno-long-long -I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../libobjc -S -o syntax-error-9.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/obj-c++.dg/syntax-error-9.mm:1:17: warning: cannot find interface declaration for 'SaturnDoc' /home/seurer/gcc/git/gcc-test/gcc/testsuite/obj-c++.dg/syntax-error-9.mm:2:27: error: expected ':' at end of input /home/seurer/gcc/git/gcc-test/gcc/testsuite/obj-c++.dg/syntax-error-9.mm: In function '-[SaturnDoc read:]': /home/seurer/gcc/git/gcc-test/gcc/testsuite/obj-c++.dg/syntax-error-9.mm:4: error: expected '@end' at end of input : internal compiler error: in set_decl_context_in_fn, at cp/name-lookup.c:2862 0x1046907b set_decl_context_in_fn /home/seurer/gcc/git/gcc-test/gcc/cp/name-lookup.c:2861 0x1046907b do_pushdecl /home/seurer/gcc/git/gcc-test/gcc/cp/name-lookup.c:2995 0x1046907b pushdecl(tree_node*, bool) /home/seurer/gcc/git/gcc-test/gcc/cp/name-lookup.c:3173 0x10376bdb start_preparsed_function(tree_node*, tree_node*, int) /home/seurer/gcc/git/gcc-test/gcc/cp/decl.c:16311 0x10221b0b objc_start_function(tree_node*, tree_node*, tree_node*, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/objc/objc-act.c:8623 0x1023ee37 build_module_initializer_routine /home/seurer/gcc/git/gcc-test/gcc/objc/objc-gnu-runtime-abi-01.c:948 0x1023ee37 objc_generate_v1_gnu_metadata /home/seurer/gcc/git/gcc-test/gcc/objc/objc-gnu-runtime-abi-01.c:2118 0x1022cca3 objc_write_global_declarations() /home/seurer/gcc/git/gcc-test/gcc/objc/objc-act.c:477 0x103cdedb c_parse_final_cleanups() /home/seurer/gcc/git/gcc-test/gcc/cp/decl2.c:5165 0x106c84cf c_common_parse_file() /home/seurer/gcc/git/gcc-test/gcc/c-family/c-opts.c:1210 This was on a powerpc64 BE system.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> I don't know why gfc_real_kinds[2].mode_precision is 127, but I guess that
> is what is causing us to trigger the assert.
>
> When I tried adding -mfloat128 -mabi=ieeelongdouble to switch us to using
> IEEE128 as our long double type, I get the same
> gfc_real_kinds[2].mode_precision equal to 127. I'm not sure why. I don't
> know this code.
genmodes seems to create:
const poly_uint16_pod mode_precision[NUM_MACHINE_MODES] =
{
...
{ 4 * BITS_PER_UNIT }, /* SF */
{ 8 * BITS_PER_UNIT }, /* DF */
{ 126 }, /* KF */
{ 127 }, /* TF */
{ 128 }, /* IF */
...
Why aren't KFmode, IFmode and TFmode all 128??? Mike?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #16 from Peter Bergner --- I don't know why gfc_real_kinds[2].mode_precision is 127, but I guess that is what is causing us to trigger the assert. When I tried adding -mfloat128 -mabi=ieeelongdouble to switch us to using IEEE128 as our long double type, I get the same gfc_real_kinds[2].mode_precision equal to 127. I'm not sure why. I don't know this code.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #15 from Peter Bergner ---
On POWER, we see with an unpatched compiler, where long double == IBM double
double format:
(gdb) p gfc_float128_type_node
$16 = (tree) 0x0
(gdb) p gfc_real_kinds[0]
$17 = {epsilon = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = -22, _mpfr_d =
0x134f99d8}}, huge = {{_mpfr_prec = 24, _mpfr_sign = 1,
_mpfr_exp = 128, _mpfr_d = 0x134f9978}}, tiny = {{_mpfr_prec = 24,
_mpfr_sign = 1, _mpfr_exp = -125, _mpfr_d = 0x134f9998}},
subnormal = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = -148, _mpfr_d =
0x134f99b8}}, kind = 4, radix = 2, digits = 24,
min_exponent = -125, max_exponent = 128, range = 37, precision = 6,
mode_precision = 32, c_float = 1, c_double = 0,
c_long_double = 0, c_float128 = 0}
(gdb) p gfc_real_kinds[1]
$18 = {epsilon = {{_mpfr_prec = 53, _mpfr_sign = 1, _mpfr_exp = -51, _mpfr_d =
0x134f9a58}}, huge = {{_mpfr_prec = 53, _mpfr_sign = 1,
_mpfr_exp = 1024, _mpfr_d = 0x134f9a18}}, tiny = {{_mpfr_prec = 53,
_mpfr_sign = 1, _mpfr_exp = -1021, _mpfr_d = 0x134f99f8}},
subnormal = {{_mpfr_prec = 53, _mpfr_sign = 1, _mpfr_exp = -1073, _mpfr_d =
0x134f9a38}}, kind = 8, radix = 2, digits = 53,
min_exponent = -1021, max_exponent = 1024, range = 307, precision = 15,
mode_precision = 64, c_float = 0, c_double = 1,
c_long_double = 0, c_float128 = 0}
(gdb) p gfc_real_kinds[2]
$19 = {epsilon = {{_mpfr_prec = 106, _mpfr_sign = 1, _mpfr_exp = -104, _mpfr_d
= 0x134f9ad8}}, huge = {{_mpfr_prec = 106,
_mpfr_sign = 1, _mpfr_exp = 1023, _mpfr_d = 0x134f9a98}}, tiny =
{{_mpfr_prec = 106, _mpfr_sign = 1, _mpfr_exp = -968,
_mpfr_d = 0x134f9a78}}, subnormal = {{_mpfr_prec = 106, _mpfr_sign = 1,
_mpfr_exp = -1073, _mpfr_d = 0x134f9ab8}}, kind = 16,
radix = 2, digits = 106, min_exponent = -968, max_exponent = 1023, range =
291, precision = 31, mode_precision = 127, c_float = 0,
c_double = 0, c_long_double = 1, c_float128 = 0}
[Bug c/96907] [docs] document builtins for fputc and putc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907 --- Comment #5 from Nick Desaulniers --- No preferences either way. I was just comparing differences between compilers for __has_builtin and noticed GCC returns true for those two. Is that ok?
[Bug c++/97014] New: Class NTTPs not demangled in the compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97014
Bug ID: 97014
Summary: Class NTTPs not demangled in the compilation error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
The following code:
```
struct ratio {
int num;
int den;
};
template
struct X {
static constexpr auto ratio = R;
};
template
concept positive = R.num > 0 && R.den > 0;
template
concept ratio_positive = positive;
void foo(ratio_positive auto x) {}
void boo()
{
foo(X());
}
```
produces the following error with `::_ZTAXtl5ratioLin1ELi2EEE` not demangled to
`ratio{-1, 2}` in many places:
```
: In function 'void boo()':
:21:24: error: no matching function for call to 'foo(X)'
21 | foo(X());
|^
:17:6: note: candidate: 'template requires
ratio_positive void foo(auto:1)'
17 | void foo(ratio_positive auto x) {}
| ^~~
:17:6: note: template argument deduction/substitution failed:
:17:6: note: constraints not satisfied
: In substitution of 'template requires
ratio_positive void foo(auto:1) [with auto:1 = X]':
:21:24: required from here
:12:9: required for the satisfaction of 'positive' [with T
= X<::_ZTAXtl5ratioLin1ELi2EEE>]
:15:9: required for the satisfaction of 'ratio_positive'
[with auto:1 = X<::_ZTAXtl5ratioLin1ELi2EEE>]
:12:26: note: the expression '((const ratio)R).num > 0 [with R =
X<::_ZTAXtl5ratioLin1ELi2EEE>::ratio]' evaluated to 'false'
12 | concept positive = R.num > 0 && R.den > 0;
|~~^~~
Compiler returned: 1
```
[Bug c++/97010] C++20 ADL and function templates that are not visible (P0846R0) fails on call with templated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553664.html
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from anlauf at gcc dot gnu.org --- > This may lead to a total mess, and I am unable to test it, but can you try: I just ran bootstraps on both sparc-sun-solaris2.11 and i386-pc-solaris2.11. x86 results are unchanged, but sparc is completely miserable: === gfortran Summary for unix === # of expected passes18878 # of unexpected failures16537 # of expected failures 177 # of untested testcases 1752 # of unresolved testcases 14688 # of unsupported tests 706 likewise with -m64. Most (all?) tests fail to link now, failing to find one or more of cabsq copysignq fmodq roundq sqrtq truncq e.g. FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 (test for excess errors) Excess errors: Undefined first referenced symbol in file cabsq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so fmodq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so sqrtq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so roundq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so truncq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so copysignq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so ld: fatal: symbol referencing errors
[Bug c/96907] [docs] document builtins for fputc and putc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- For various builtins it isn't merely about default attached attributes, but also about the compiler understanding what the function does in more detail and perhaps performing some optimizations on them, transform one function call into another one, or understand some aliasing etc. behavior of it. I'm not really sure it is a good idea to document it all.
[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Septemb ||er/553661.html Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org CC||bergner at gcc dot gnu.org --- Comment #3 from Peter Bergner --- (In reply to Segher Boessenkool from comment #2) > When you want the bits from bit MB to ME (inclusive) set, you can just do > > li t,-1 > rldic d,T,MB,63-ME > > (bit # 0 is the high bit; can also do wrap-around masks this way). I submitted a patch that implements this idea.
[Bug c/96907] [docs] document builtins for fputc and putc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- Many other "builtins" documented there are only ever implemented with libcalls as well?
[Bug fortran/97003] Error: gfortran: No such file or directory and GNU gortran is nor working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97003 Seager Du changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Seager Du --- (In reply to kargl from comment #1) > (In reply to Seager Du from comment #0) > > Created attachment 49205 [details] > > The configure log with the error information > > > > Compiled the Gcc as the following on the ubuntu 18.04. > > 1) sudo apt update > > 2) sudo apt upgrade > > 3) contrib/download_prerequisites > > 4) ./configure --prefix=/usr/local/gcc63 --program-suffix=63 > > --enable-languages=c,c++,fortran --disable-multilib > > Please the instruction for installing GCC at https://gcc.gnu.org/install/ > > Your step 4) is invalidate. Thank you for your comment. I congifure and build the Gcc in a separate directory out of the GCC. It works awesome. Thank you
[Bug tree-optimization/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |tree-optimization --- Comment #3 from anlauf at gcc dot gnu.org --- OK: gfc-11 pr97009.f90 -O2 -finline -fno-tree-vrp Not OK: gfc-11 pr97009.f90 -O2 -finline -ftree-vrp Reassigning to tree-optimization.
[Bug tree-optimization/97013] [11 regression] gcc.target/powerpc/pr80695-p8.c fails after r11-3095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97013 --- Comment #2 from rguenther at suse dot de --- On September 10, 2020 9:50:51 PM GMT+02:00, "bergner at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97013 > >--- Comment #1 from Peter Bergner --- >Are you saying we now vectorize the pr80695-p8.c test case when we >expected not >to? What asm code are we generating now with richi's patch? No, we're just dumping it twice now, once for each opportunity. Oh, and maybe once overall. I'll check whether to adjust the dumping code tomorrow.
[Bug tree-optimization/97013] [11 regression] gcc.target/powerpc/pr80695-p8.c fails after r11-3095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97013 --- Comment #1 from Peter Bergner --- Are you saying we now vectorize the pr80695-p8.c test case when we expected not to? What asm code are we generating now with richi's patch?
[Bug target/97004] [nvptx] __int128 initializer incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97004
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
Target Milestone|--- |11.0
--- Comment #4 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #2)
> (In reply to Tom de Vries from comment #1)
> > Tentative patch:
> > ...
> > diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> > index 0376ad6ce9f..26868590322 100644
> > --- a/gcc/config/nvptx/nvptx.c
> > +++ b/gcc/config/nvptx/nvptx.c
> > @@ -2054,7 +2054,11 @@ nvptx_assemble_value (unsigned HOST_WIDE_INT val,
> > unsigned size)
> >
> >for (unsigned part = 0; size; size -= part)
> > {
> > - val >>= part * BITS_PER_UNIT;
> > + if (part == sizeof (val))
>
> That assumes that CHAR_BIT == BITS_PER_UNIT, which is mostly the case, but
> shouldn't be relied on.
> Perhaps just use
> val >>= (part * BITS_PER_UNIT / 2);
> val >>= (part * BITS_PER_UNIT / 2);
> or if (part * BITS_PER_UNIT == sizeof (val) * CHAR_BIT)
> Though, as val is unsigned HOST_WIDE_INT, we already have a macro for that,
> so if (part * BITS_PER_UNIT == HOST_BITS_PER_WIDE_INT) ?
I went with the last suggestion, thanks for the review.
Patch committed to trunk, no test-case required.
Marking resolved-fixed.
[Bug target/97004] [nvptx] __int128 initializer incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97004
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:af47a2035a4882e6d4506e3d00b5a42414e3ee2b
commit r11-3127-gaf47a2035a4882e6d4506e3d00b5a42414e3ee2b
Author: Tom de Vries
Date: Thu Sep 10 15:54:14 2020 +0200
[nvptx] Fix printing of 128-bit constant
Currently, for this code from c-c++-common/spec-barrier-1.c:
...
__int128 g = 9;
...
we generate:
...
// BEGIN GLOBAL VAR DEF: g
.visible .global .align 8 .u64 g[2] = { 9, 9 };
...
and consequently the test-case fails in execution.
The problem is caused by a shift in nvptx_assemble_value:
...
val >>= part * BITS_PER_UNIT;
...
where the shift amount is equal to the number of bits in val, which is
undefined behaviour.
Fix this by detecting the situation and setting val to 0.
Tested on nvptx.
gcc/ChangeLog:
PR target/97004
* config/nvptx/nvptx.c (nvptx_assemble_value): Handle shift by
number of bits in shift operand.
[Bug tree-optimization/97013] New: [11 regression] gcc.target/powerpc/pr80695-p8.c fails after r11-3095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97013 Bug ID: 97013 Summary: [11 regression] gcc.target/powerpc/pr80695-p8.c fails after r11-3095 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:47ddf4c7b1d4471cb9534f27844ab5e4279c2168, r11-3095 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr80695-p8.c" FAIL: gcc.target/powerpc/pr80695-p8.c scan-tree-dump-times slp2 "vectorization is not profitable" 1 # of expected passes1 # of unexpected failures1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ -fdiagnostics-plain-output -mpower8-vector -c -o powerpc_p8vector_ok3656799.o powerpc_p8vector_ok3656799.c Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr80695-p8.c -fdiagnostics-plain-output -mdejagnu-cpu=power8 -O3 -fdump-tree-slp-details -S -o pr80695-p8.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr80695-p8.c -fdiagnostics-plain-output -mdejagnu-cpu=power8 -O3 -fdump-tree-slp-details -S -o pr80695-p8.s PASS: gcc.target/powerpc/pr80695-p8.c (test for excess errors) gcc.target/powerpc/pr80695-p8.c: pattern found 2 times FAIL: gcc.target/powerpc/pr80695-p8.c scan-tree-dump-times slp2 "vectorization is not profitable" 1
[Bug fortran/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.4 Ever confirmed|0 |1 Known to fail||11.0 Summary|Inlining with non-standard |[9/10/11 Regression] |selected_int_kind leads to |Inlining with non-standard |errors |selected_int_kind leads to ||errors Keywords||wrong-code Last reconfirmed||2020-09-10 Status|UNCONFIRMED |NEW Known to work||8.4.1 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- It appears to be a combination of inlining and optimizations that are present at -O2 but not at -O1. OK: gfc-11 pr97009.f90 -O1 -finline gfc-11 pr97009.f90 -O2 -fno-inline Not OK: gfc-11 pr97009.f90 -O2 -finline The output in the latter case appears to be random junk. But valgrind does not show anything for me, nor does ASAN. Could also be some ME issue.
[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942 --- Comment #43 from Jonathan Wakely --- (In reply to Dmitriy Ovdienko from comment #41) > Did you have chance to review why default-constructed M-B-R works faster > than another one constructed with the initial buffer size? Is that explained by the kernel pre-faulting the extra pages that are over-allocated, as amonakov said in comment 9? I haven't actually looked into it. (In reply to Dmitriy Ovdienko from comment #42) > Very good commit and comment. I hope this change, made for synthetic > benchmark, wont affect real production applications. Well if you need a larger initial size you can get it by asking for it, instead of getting it by accident :-)
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994 --- Comment #6 from Jakub Jelinek --- Though, when the ctor is constexpr, it is constant initialized even without it, so probably the bug is somewhere else.
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994
--- Comment #5 from Jakub Jelinek ---
More complete testcase:
struct A { consteval A () { i = 1; } consteval A (int x) : i (x) {} int i = 0;
};
struct B { constexpr B () { i = 1; } constexpr B (int x) : i (x) {} int i = 0;
};
A const a;
constexpr A b;
B const c;
A const constinit d;
A const e = 2;
constexpr A f = 3;
B const g = 4;
A const constinit h = 5;
A i;
B j;
A k = 6;
B l = 7;
static_assert (b.i == 1 && f.i == 3);
int
main()
{
if (a.i != 1 || c.i != 1 || d.i != 1 || e.i != 2 || g.i != 4 || h.i != 5
|| i.i != 1 || j.i != 1 || k.i != 6 || l.i != 7)
__builtin_abort ();
}
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994
--- Comment #4 from Marek Polacek ---
Yes, a way to fix this would be to do the build_functional_cast in
check_initializer:
6892 else if (DECL_DECLARED_CONSTEXPR_P (decl)
6893|| (flags & LOOKUP_CONSTINIT))
6894 {
6895 /* Declared constexpr or constinit, but no suitable
initializer;
6896 massage init appropriately so we can pass it into
6897 store_init_value for the error. */
6898 if (CLASS_TYPE_P (type)
6899 && (!init || TREE_CODE (init) == TREE_LIST))
6900 {
6901 init = build_functional_cast (input_location, type,
6902 init, tf_none);
[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942 --- Comment #42 from Dmitriy Ovdienko --- > The master branch has been updated by Jonathan Wakely : Very good commit and comment. I hope this change, made for synthetic benchmark, wont affect real production applications.
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994
--- Comment #3 from Jakub Jelinek ---
Though:
struct A { consteval A (int x) { i = x; } int i = 0; };
struct B { constexpr B (int x) { i = x; } int i = 0; };
A const a = 1;
constexpr A b = 2;
B const c = 3;
A constinit d = 4;
static_assert (b.i == 2);
int
main()
{
if (a.i != 1 || c.i != 3 || d.i != 4)
__builtin_abort ();
}
works fine, so the problem is maybe just with default construction for
consteval ctor.
[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942 --- Comment #41 from Dmitriy Ovdienko --- @Jonathan Did you have chance to review why default-constructed M-B-R works faster than another one constructed with the initial buffer size?
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Testcase without includes:
struct A { consteval A () { i = 1; } int i = 0; };
struct B { constexpr B () { i = 1; } int i = 0; };
A const a;
constexpr A b;
B const c;
A constinit d;
static_assert (b.i == 1);
int
main()
{
if (a.i != 1 || c.i != 1 || d.i != 1)
__builtin_abort ();
}
I wonder if we shouldn't treat variables with consteval ctors like if
constinit, which as the testcase shows works fine.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #12)
> Here's how the types align:
>
> kindmode_precision c_long_double c_float128
> x86 long double 10 80 1 0
> x86 __float128 16 128 0 1
> sparc long double 16 128 1 0
This may lead to a total mess, and I am unable to test it, but can you try:
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 26fdb2803a7..4d5de9066af 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -844,7 +844,14 @@ gfc_build_real_type (gfc_real_info *info)
if (mode_precision == DOUBLE_TYPE_SIZE)
info->c_double = 1;
if (mode_precision == LONG_DOUBLE_TYPE_SIZE)
-info->c_long_double = 1;
+{
+ info->c_long_double = 1;
+ if (mode_precision == 128)
+ {
+ info->c_float128 = 1;
+ gfc_real16_is_float128 = true;
+ }
+}
if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
{
info->c_float128 = 1;
It's likely to screw up power completely, but I don't have any feedback from
them.
[Bug target/97012] New: [SVE] Extend PR96357 to other aarch64-sve.md patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97012 Bug ID: 97012 Summary: [SVE] Extend PR96357 to other aarch64-sve.md patterns Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- Target: aarch64*-*-* The other patterns in aarch64-sve.md that use aarch64_sve_pred_dominates_p need to be fixed in the same way as Przemek's fix for PR96357, since the same bug could in principle affect any pattern that uses the same approach.
[Bug target/97012] [SVE] Extend PR96357 to other aarch64-sve.md patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97012 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-09-10 Status|UNCONFIRMED |NEW
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #13 from rsandifo at gcc dot gnu.org --- *** Bug 96990 has been marked as a duplicate of this bug. ***
[Bug target/96990] Regression in aarch64 struct vector member initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96990 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from rsandifo at gcc dot gnu.org --- Yeah, this was fixed by https://gcc.gnu.org/g:7d599ad27b9bcf5165f87710f1abc64bbabd06ae, which will be included in GCC 10.3. Sorry for the inconvenience. (PR96377 is still open because there's a related unfixed bug on trunk, but the current GCC 10 branch is unaffected.) *** This bug has been marked as a duplicate of bug 96377 ***
[Bug d/95680] libdruntime doesn't support shadow stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95680 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Iain Buclaw --- Done.
[Bug d/97007] [11 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97007 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- First raised with i386-solaris, patch has been tested and confirmed to work.
[Bug d/97007] [11 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97007 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0ed757604f4e232324ca798e46f3d8bf7e35b009 commit r11-3112-g0ed757604f4e232324ca798e46f3d8bf7e35b009 Author: Iain Buclaw Date: Thu Sep 10 01:30:20 2020 +0200 libphobos: libdruntime doesn't support shadow stack (PR95680) The first implementation hit a front-end implementation bug where version conditions are resolved ahead of static if confitions. The logic for whether to use asm implemented fiber_switchContext or libc's swapcontext has been moved from GNU_Enable_CET to version CET. libphobos/ChangeLog: PR d/95680 PR d/97007 * Makefile.am (AM_MAKEFLAGS): Remove $(CET_FLAGS). * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac (DCFG_ENABLE_CET): Remove substitution. (CET_DFLAGS): Substitute. * libdruntime/Makefile.am (AM_DFLAGS): Add $(CET_DFLAGS). (AM_CFLAGS): Add $(CET_FLAGS). (AM_CCASFLAGS): Likewise. * libdruntime/Makefile.in: Regenerate. * libdruntime/core/thread.d: Replace static if GNU_Enable_CET condition with `version (CET)'. * libdruntime/gcc/config.d.in (GNU_Enable_CET): Remove. * src/Makefile.am (AM_DFLAGS): Add $(CET_DFLAGS). (AM_CFLAGS): Add $(CET_FLAGS). * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * testsuite/testsuite_flags.in: Add $(CET_DFLAGS) to --gdcflags.
[Bug d/95680] libdruntime doesn't support shadow stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95680 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0ed757604f4e232324ca798e46f3d8bf7e35b009 commit r11-3112-g0ed757604f4e232324ca798e46f3d8bf7e35b009 Author: Iain Buclaw Date: Thu Sep 10 01:30:20 2020 +0200 libphobos: libdruntime doesn't support shadow stack (PR95680) The first implementation hit a front-end implementation bug where version conditions are resolved ahead of static if confitions. The logic for whether to use asm implemented fiber_switchContext or libc's swapcontext has been moved from GNU_Enable_CET to version CET. libphobos/ChangeLog: PR d/95680 PR d/97007 * Makefile.am (AM_MAKEFLAGS): Remove $(CET_FLAGS). * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac (DCFG_ENABLE_CET): Remove substitution. (CET_DFLAGS): Substitute. * libdruntime/Makefile.am (AM_DFLAGS): Add $(CET_DFLAGS). (AM_CFLAGS): Add $(CET_FLAGS). (AM_CCASFLAGS): Likewise. * libdruntime/Makefile.in: Regenerate. * libdruntime/core/thread.d: Replace static if GNU_Enable_CET condition with `version (CET)'. * libdruntime/gcc/config.d.in (GNU_Enable_CET): Remove. * src/Makefile.am (AM_DFLAGS): Add $(CET_DFLAGS). (AM_CFLAGS): Add $(CET_FLAGS). * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * testsuite/testsuite_flags.in: Add $(CET_DFLAGS) to --gdcflags.
[Bug target/96939] LTO vs. different arm arch options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:57e113cf7c94a682c29566cb3e0e85955904fd35
commit r11-3104-g57e113cf7c94a682c29566cb3e0e85955904fd35
Author: Jakub Jelinek
Date: Thu Sep 10 17:39:00 2020 +0200
arm: Fix up arm_override_options_after_change [PR96939]
As mentioned in the PR, the testcase fails to link, because when set_cfun
is
being called on the crc function, arm_override_options_after_change is
called from set_cfun -> invoke_set_current_function_hook:
/* Change optimization options if needed. */
if (optimization_current_node != opts)
{
optimization_current_node = opts;
cl_optimization_restore (_options, TREE_OPTIMIZATION
(opts));
}
and at that point target_option_default_node actually matches even the
current state of options, so this means armv7 (or whatever) arch is set as
arm_active_target, then
targetm.set_current_function (fndecl);
is called later in that function, which because the crc function's
DECL_FUNCTION_SPECIFIC_TARGET is different from the current one will do:
cl_target_option_restore (_options, TREE_TARGET_OPTION
(new_tree));
which calls arm_option_restore and sets arm_active_target to armv8-a+crc
(so far so good).
Later arm_set_current_function calls:
save_restore_target_globals (new_tree);
which in this case calls:
/* Call target_reinit and save the state for TARGET_GLOBALS. */
TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
which because optimization_current_node != optimization_default_node
(the testcase is LTO, so all functions have their
DECL_FUNCTION_SPECIFIC_TARGET and TREE_OPTIMIZATION nodes) will call:
cl_optimization_restore
(_options,
TREE_OPTIMIZATION (optimization_default_node));
and
cl_optimization_restore (_options,
TREE_OPTIMIZATION (opts));
The problem is that these call arm_override_options_after_change again,
and that one uses the target_option_default_node as what to set the
arm_active_target to (i.e. back to armv7 or whatever, but not to the
armv8-a+crc that should be the active target for the crc function).
That means we then error on the builtin call in that function.
Now, the targetm.override_options_after_change hook is called always at the
end of cl_optimization_restore, i.e. when we change the Optimization marked
generic options. So it seems unnecessary to call
arm_configure_build_target
at that point (nothing it depends on changed), and additionally incorrect
(because it uses the target_option_default_node, rather than the current
set of options; we'd need to revert
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01390.html
otherwise so that it works again with global_options otherwise).
The options that arm_configure_build_target cares about will change only
during option parsing (which is where it is called already), or during
arm_set_current_function, where it is done during the
cl_target_option_restore.
Now, arm_override_options_after_change_1 wants to adjust the
str_align_functions, which depends on the current Optimization options
(e.g.
optimize_size and flag_align_options and str_align_functions) as well as
the target options target_flags, so IMHO needs to be called both
when the Optimization options (possibly) change, i.e. from
the targetm.override_options_after_change hook, and from when the target
options change (set_current_function hook).
2020-09-10 Jakub Jelinek
PR target/96939
* config/arm/arm.c (arm_override_options_after_change): Don't call
arm_configure_build_target here.
(arm_set_current_function): Call
arm_override_options_after_change_1
at the end.
* gcc.target/arm/lto/pr96939_0.c: New test.
* gcc.target/arm/lto/pr96939_1.c: New file.
[Bug c++/97011] New: ICE on C++ 20 code: gcc_assert failure in DWARF generation (tree_add_const_value_attribute, at dwarf2out.c:20283)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97011
Bug ID: 97011
Summary: ICE on C++ 20 code: gcc_assert failure in DWARF
generation (tree_add_const_value_attribute, at
dwarf2out.c:20283)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
a) This code:
template struct posit {};
template concept Posit = true;
template concept Posit_Term = true;
template struct s
{
template struct ss {};
constexpr auto at (Posit pos) const { return ss {}; };
};
constexpr auto t = s <> {}.at (posit <0> {});
when compiled as follows:
g++ -c -std=c++2a -fconcepts-ts -g3 bug-1.cpp -DBUG=1
provokes the internal compiler error:
bug-1.cpp:15:45: internal compiler error: in tree_add_const_value_attribute, at
dwarf2out.c:20283
15 | constexpr auto t = s <> {}.at (posit <0> {});
| ^
0x701df1 tree_add_const_value_attribute
../../src/gcc/dwarf2out.c:20283
0xc5fbc1 gen_remaining_tmpl_value_param_die_attribute
../../src/gcc/dwarf2out.c:27130
0xc6ec58 gen_remaining_tmpl_value_param_die_attribute
../../src/gcc/dwarf2out.c:27116
0xc6ec58 dwarf2out_early_finish
../../src/gcc/dwarf2out.c:32076
0xbce88a symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:3012
Please submit a full bug report,
Defining 'BUG' and compiling with '-g3' are necessary conditions for
reproduction.
B) Indently (BUG undefined), the same code, compiled with '-W -Wall -Wextra'
added, gives the warning
bug-1.cpp: In instantiation of ‘constexpr auto s::at(auto:1) const [with
auto:1 = posit<0>; auto ...elts = {}]’:
bug-1.cpp:15:44: required from here
bug-1.cpp:12:34: warning: parameter ‘pos’ set but not used
[-Wunused-but-set-parameter]
12 | constexpr auto at (Posit pos) const { return ss {}; };
|~~^~~
which doesn't seem correct.
gcc version:
g++ (GCC) 11.0.0 20200910 (experimental)
[Bug target/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96998 --- Comment #7 from Alex Coplan --- Patch up for review: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553605.html
[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942 --- Comment #40 from Jonathan Wakely --- (In reply to Dmitriy Ovdienko from comment #38) > Wohoo! Accepted: > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/ > binarytrees.html Nice. I've added some __builtin_expect hints and also changed the buffer resource to allocate multiples of 64 instead of powers of two. I don't think there's much more that be done here right now.
[Bug libstdc++/94160] std::pmr::pool_options::max_blocks_per_chunk=1 causes pool resources to return null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94160 --- Comment #3 from Jonathan Wakely --- Fixed on trunk so far, but I plan to backport it.
[Bug libstdc++/94160] std::pmr::pool_options::max_blocks_per_chunk=1 causes pool resources to return null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94160 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:30b41cfbb2dade63e52465234a725d1d02fe70aa commit r11-3102-g30b41cfbb2dade63e52465234a725d1d02fe70aa Author: Jonathan Wakely Date: Thu Sep 10 15:39:15 2020 +0100 libstdc++: handle small max_blocks_per_chunk in pool resources [PR 94160] When a pool resource is constructed with max_blocks_per_chunk=1 it ends up creating a pool with blocks_per_chunk=0 which means it never allocates anything. Instead it returns null pointers, which should be impossible. To avoid this problem, round the max_blocks_per_chunk value to a multiple of four, so it's never smaller than four. libstdc++-v3/ChangeLog: PR libstdc++/94160 * src/c++17/memory_resource.cc (munge_options): Round max_blocks_per_chunk to a multiple of four. (__pool_resource::_M_alloc_pools()): Simplify slightly. * testsuite/20_util/unsynchronized_pool_resource/allocate.cc: Check that valid pointers are returned when small values are used for max_blocks_per_chunk.
[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942 --- Comment #39 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e718ec51a223d65a09757b999202390871b778d commit r11-3101-g1e718ec51a223d65a09757b999202390871b778d Author: Jonathan Wakely Date: Thu Sep 10 15:39:15 2020 +0100 libstdc++: Reduce monotonic_buffer_resource overallocation [PR 96942] The primary reason for this change is to reduce the size of buffers allocated by std::pmr::monotonic_buffer_resource. Previously, a new buffer would always add the size of the linked list node (11 bytes) and then round up to the next power of two. This results in a huge increase if the expected size of the next buffer is already a power of two. For example, if the resource is constructed with a desired initial size of 4096 the first buffer it allocates will be std::bit_ceil(4096+11) which is 8192. If the user has carefully selected the initial size to match their expected memory requirements then allocating double that amount wastes a lot of memory. After this patch the allocated size will be rounded up to a 64-byte boundary, instead of to a power of two. This means for an initial size of 4096 only 4160 bytes get allocated. Previously only the base-2 logarithm of the size was stored, which could be stored in a single 8-bit integer. Now that the size isn't always a power of two we need to use more bits to store it. As the size is always a multiple of 64 the low six bits are not needed, and so we can use the same approach that the pool resources already use of storing the base-2 logarithm of the alignment in the low bits that are not used for the size. To avoid code duplication, a new aligned_size helper class is introduced by this patch, which is then used by both the pool resources' big_block type and the monotonic_buffer_resource::_Chunk type. Originally the big_block type used two bit-fields to store the size and alignment in the space of a single size_t member. The aligned_size type uses a single size_t member and uses masks and bitwise operations to manipulate the size and alignment values. This results in better code than the old version, because the bit-fields weren't optimally ordered for little endian architectures, so the alignment was actually stored in the high bits, not the unused low bits, requiring additional shifts to calculate the values. Using bitwise operations directly avoids needing to reorder the bit-fields depending on the endianness. While adapting the _Chunk and big_block types to use aligned_size I also added checks for size overflows (technically, unsigned wraparound). The memory resources now ensure that when they require an allocation that is too large to represent in size_t they will request SIZE_MAX bytes from the upstream resource, rather than requesting a small value that results from wrapround. The testsuite is enhanced to verify this. libstdc++-v3/ChangeLog: PR libstdc++/96942 * include/std/memory_resource (monotonic_buffer_resource::do_allocate): Use __builtin_expect when checking if a new buffer needs to be allocated from the upstream resource, and for checks for edge cases like zero sized buffers and allocations. * src/c++17/memory_resource.cc (aligned_size): New class template. (aligned_ceil): New helper function to round up to a given alignment. (monotonic_buffer_resource::chunk): Replace _M_size and _M_align with an aligned_size member. Remove _M_canary member. Change _M_next to pointer instead of unaligned buffer. (monotonic_buffer_resource::chunk::allocate): Round up to multiple of 64 instead of to power of two. Check for size overflow. Remove redundant check for minimum required alignment. (monotonic_buffer_resource::chunk::release): Adjust for changes to data members. (monotonic_buffer_resource::_M_new_buffer): Use aligned_ceil. (big_block): Replace _M_size and _M_align with aligned_size member. (big_block::big_block): Check for size overflow. (big_block::size, big_block::align): Adjust to use aligned_size. (big_block::alloc_size): Use aligned_ceil. (munge_options): Use aligned_ceil. (__pool_resource::allocate): Use big_block::align for alignment. * testsuite/20_util/monotonic_buffer_resource/allocate.cc: Check upstream resource gets expected values for impossible sizes. * testsuite/20_util/unsynchronized_pool_resource/allocate.cc: Likewise. Adjust checks for expected alignment in existing test.
[Bug c++/97010] C++20 ADL and function templates that are not visible (P0846R0) fails on call with templated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Keywords||rejects-valid Ever confirmed|0 |1 Last reconfirmed||2020-09-10 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Marek Polacek --- Mine.
[Bug c++/96444] Incorrect satisfaction value of placeholder type constraint on variable with non-dependent initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96444 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-09-10 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug c++/97010] New: C++20 ADL and function templates that are not visible (P0846R0) fails on call with templated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
Bug ID: 97010
Summary: C++20 ADL and function templates that are not visible
(P0846R0) fails on call with templated type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kirshamir at gmail dot com
Target Milestone: ---
#include
#include
template
void print(const Tuple& tup) {
// P0846R0: ADL should work here correctly
std::cout << get<0>(tup) << std::endl; // fails with gcc
}
int main() {
auto two_ints = std::make_tuple(1, 2);
std::cout << get<0>(two_ints) << std::endl; // ok
print(two_ints);
}
Code: https://godbolt.org/z/YGGaEo
[Bug target/97004] [nvptx] __int128 initializer incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97004
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
(In reply to Tom de Vries from comment #1)
> Tentative patch:
> ...
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index 0376ad6ce9f..26868590322 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -2054,7 +2054,11 @@ nvptx_assemble_value (unsigned HOST_WIDE_INT val,
> unsigned size)
>
>for (unsigned part = 0; size; size -= part)
> {
> - val >>= part * BITS_PER_UNIT;
> + if (part == sizeof (val))
That assumes that CHAR_BIT == BITS_PER_UNIT, which is mostly the case, but
shouldn't be relied on.
Perhaps just use
val >>= (part * BITS_PER_UNIT / 2);
val >>= (part * BITS_PER_UNIT / 2);
or if (part * BITS_PER_UNIT == sizeof (val) * CHAR_BIT)
Though, as val is unsigned HOST_WIDE_INT, we already have a macro for that,
so if (part * BITS_PER_UNIT == HOST_BITS_PER_WIDE_INT) ?
[Bug target/97004] [nvptx] __int128 initializer incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97004
--- Comment #1 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 0376ad6ce9f..26868590322 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -2054,7 +2054,11 @@ nvptx_assemble_value (unsigned HOST_WIDE_INT val,
unsigned size)
for (unsigned part = 0; size; size -= part)
{
- val >>= part * BITS_PER_UNIT;
+ if (part == sizeof (val))
+ /* Avoid undefined behaviour. */
+ val = 0;
+ else
+ val >>= (part * BITS_PER_UNIT);
part = init_frag.size - init_frag.offset;
part = MIN (part, size);
...
And we have:
...
// BEGIN GLOBAL VAR DEF: g
.visible .global .align 8 .u64 g[2] = { 9, 0 };
...
[Bug libstdc++/94160] std::pmr::pool_options::max_blocks_per_chunk=1 causes pool resources to return null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94160
--- Comment #1 from Jonathan Wakely ---
Testcase:
#include
int main()
{
std::pmr::unsynchronized_pool_resource upr({ 1, 32 });
auto* p = (int*)upr.allocate(4);
*p = 0;
return *p;
}
The returned pointer is null, leading to a segfault.
If libstdc++ is built with assertions enabled, the allocation aborts with:
../../../../../libstdc++-v3/src/c++17/memory_resource.cc:294:
std::pmr::{anonymous}::bitset::bitset(void*,
std::pmr::{anonymous}::bitset::size_type): Assertion 'empty()' failed.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
>> >> 0x67606b build_round_expr
>> >> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
>> >
>> > That's:
>> >
>> > arg = fold_convert (gfc_float128_type_node, arg);
>> >
>> > Can you find out what gfc_float128_type_node is on SPARC,
>
>> 408arg = fold_convert (gfc_float128_type_node, arg);
>> (gdb) p gfc_float128_type_node
>> $2 =
>
> OK. Can you print kind which was determined a few lines before?
(gdb) p kind
$30 = 16
> Also, to find out why gfc_float128_type_node is NULL_TREE,
> can you investigate the array gfc_real_kinds?
>
> On x86, the supported kind values are 4,8,10,16, and
4, 8, 16 on sparc
> (gdb) p gfc_real_kinds[3]
> $9 = {epsilon = {{_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -111,
> _mpfr_d = 0x27ee628}}, huge = {{_mpfr_prec = 113, _mpfr_sign = 1,
> _mpfr_exp = 16384,
> _mpfr_d = 0x27ee5e8}}, tiny = {{_mpfr_prec = 113, _mpfr_sign = 1,
> _mpfr_exp = -16381, _mpfr_d = 0x27ee5c8}}, subnormal = {{_mpfr_prec =
> 113,
> _mpfr_sign = 1, _mpfr_exp = -16493, _mpfr_d = 0x27ee608}}, kind = 16,
> radix = 2,
> digits = 113, min_exponent = -16381, max_exponent = 16384, range = 4931,
> precision = 33,
> mode_precision = 128, c_float = 0, c_double = 0, c_long_double = 0,
> c_float128 = 1}
(gdb) p gfc_real_kinds[2]
$37 = {epsilon = {{_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -111,
_mpfr_d = 0x1baf2bc}}, huge = {{_mpfr_prec = 113, _mpfr_sign = 1,
_mpfr_exp = 16384, _mpfr_d = 0x1b9b31c}}, tiny = {{_mpfr_prec = 113,
_mpfr_sign = 1, _mpfr_exp = -16381, _mpfr_d = 0x1baf27c}}, subnormal = {{
_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -16493,
_mpfr_d = 0x1baf29c}}, kind = 16, radix = 2, digits = 113,
min_exponent = -16381, max_exponent = 16384, range = 4931, precision = 33,
mode_precision = 128, c_float = 0, c_double = 0, c_long_double = 1,
c_float128 = 0}
> In trans-types.c we have:
>
> if (gfc_real_kinds[index].c_float128)
> gfc_float128_type_node = type;
>
> Look in particular at the value of c_float128.
Not set for any of the 3 supported kinds.
>> I'd expect that's long double, which is IEEE128 on SPARC.
>
> So if it is IEEE128, where does the difference from x86 come from?
Here's how the types align:
kindmode_precision c_long_double c_float128
x86 long double 10 80 1 0
x86 __float128 16 128 0 1
sparc long double 16 128 1 0
[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008 --- Comment #3 from Richard Biener --- I see. Wonder if it that shouldn't be in can_duplicate_block_p though (where the GIMPLE variant doesn't do anything, so a full stmt walk would be expensive).
[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008 --- Comment #2 from Tom de Vries --- (In reply to Richard Biener from comment #1) > Where's this property used? grepping finds searches in omp-offload but those > all(?) search the whole instruction stream. In ignore_bb_p in gcc/tracer.c, see PR97000 comment 2.
[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008 --- Comment #1 from Richard Biener --- Where's this property used? grepping finds searches in omp-offload but those all(?) search the whole instruction stream.
[Bug fortran/97009] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 --- Comment #1 from Peter Vitt --- I forgot to mention that we were able to reproduce this also with 10.1.0 and 9.3.0. In case this is of any help...
[Bug fortran/97009] New: Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 Bug ID: 97009 Summary: Inlining with non-standard selected_int_kind leads to errors Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pvitt at posteo dot de Target Milestone: --- Created attachment 49207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49207=edit Minimum working example to reproduce the problem. We ran into a problem that I stripped down to a minimal working example (see attachment). When the MWE is compiled with `gfortran -O1 2269_mwe.f90`, it produces the expected output Level3 treeID 0 Level2 treeID 1 Level1 treeID 9 When it is compiled with O2, it fails: Level3 treeID 140732851705864 Level2 treeID 140732851705352 Level1 treeID4545064992 When the line integer, parameter :: long_k = selected_int_kind(15) is changed to integer, parameter :: long_k = selected_int_kind(9) it works with O1 and O2. We stumbled over this when some unit tests failed after we activated LTO. Our first guess was that LTO stumbles over the elemental function (which tem_pathOf was before I stripped it down). However, while creating the MWE, we ended up reproducing the behavior also without LTO, but the called function in the same file. And as it disappears with O1, it seems to be related to inlining in general.
[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006
--- Comment #1 from Tom de Vries ---
Minimal example:
...
void __attribute__ ((noclone, noinline))
checkv (char *dst, const char *fmt, __builtin_va_list va)
{
int n = __builtin_vsprintf (dst, fmt, va);
if (n != 3)
__builtin_abort ();
}
void __attribute__ ((noclone, noinline))
check (char *dst, const char *fmt, ...)
{
__builtin_va_list va;
__builtin_va_start (va, fmt);
checkv (dst, fmt, va);
__builtin_va_end (va);
}
char buffer[4100];
int
main (void)
{
int i = 0xdeadbeef;
check (buffer, "%hhi", i);
return 0;
}
...
[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Keywords||openacc --- Comment #11 from Tom de Vries --- Patch committed ( https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f96b6328fa7162111e4440c5901ef313ed3e6c9a ), no test-case required. Marking resolved-fixed.
[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000 --- Comment #10 from Tom de Vries --- (In reply to Richard Biener from comment #9) > Meh, this way of forcing UNIQUE last to speedup lookup is a hack ... but > yes, your patch from comment#7 looks OK if you add > > /* IFN_UNIQUE should be the last insn, to make checking for it > as cheap as possible. */ > > before the new check to say what this is about. Note this will re-introduce > the issue that passes cannot insert on loop entry edge without creating new > BBs > even if we forced preheaders to be created. For some very special case, when > UNIQUE is involved. Thus we'll likely have even more hard to trigger latent > bugs (before it was also former setjmp calls). Filed PR97008 - "[openacc] Remove invariant that IFN_UNIQUE is last stmt in bb"
[Bug tree-optimization/97008] New: [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008 Bug ID: 97008 Summary: [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- [ spin-off of PR97000 comment 9. ] There's an invariant that says IFN_UNIQUE needs to be the last stmt in a bb. The rationale given is that it speeds up lookup. This is somewhat of a hack, and potentially inhibits various optimizations/cleanups. So, can we drop this invariant? This patch (PR97000 comment 2) is probably needed, possibly more.
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #15 from Alex Coplan --- > there are similar ICEs while running the GCC testsuite for aarch64-elf Confirmed, seeing these ICEs when running the testsuite on aarch64-none-linux-gnu.
[Bug lto/96969] ODR violations do not list the translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96969
--- Comment #1 from Jonathan Wakely ---
First file:
# 1 "one.cc"
# 1 "/tmp//"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "one.cc"
# 1 "header.h" 1
struct X
{
int member;
};
# 3 "one.cc" 2
long f(X*);
int main()
{
X x = { 0 };
return f();
}
Second file:
# 1 "two.cc"
# 1 "/tmp//"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "two.cc"
# 1 "header.h" 1
struct X
{
int field;
};
# 3 "two.cc" 2
long f(X* x) { return x->field; }
$ g++ -g -flto one.ii two.ii -Wall
header.h:1:8: warning: type ‘struct X’ violates the C++ One Definition Rule
[-Wodr]
1 | struct X
|^
header.h:1:8: note: a different type is defined in another translation unit
1 | struct X
|^
header.h:3:7: note: the first difference of corresponding definitions is field
‘member’
3 | int NAME;
| ^
header.h:3:7: note: a field with different name is defined in another
translation unit
3 | int NAME;
| ^
The only locations are from header.h, but the tokens in that header are
identical before preprocessing. The problems are due to how that header is
included by one.cc and two.cc so those names should be included in the
diagnostics.
[Bug lto/96969] ODR violations do not list the translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96969 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-09-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug d/97007] New: [11 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97007 Bug ID: 97007 Summary: [11 Regression] Bootstrap failure on i686-linux Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Bootstrap failed for me last night on the trunk on i686-linux (x86_64-linux worked fine): ../../../../libphobos/libdruntime/core/thread.d:3595:23: error: version AsmExternal defined after use 3595 | version = AsmExternal; | ^ ../../../../libphobos/libdruntime/core/thread.d:3603:27: error: version AsmX86_Posix defined after use 3603 | version = AsmX86_Posix; | ^
[Bug d/97007] [11 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97007 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.0
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997 --- Comment #6 from Jonathan Wakely --- It wouldn't solve the general problem, but I REALLY REALLY wish I could mark the std::allocator constructors and destructors with something like __attribute__((always_inline,artificial)) so they NEVER show up in the debugger, but it doesn't work. They're completely uninteresting when debugging.
[Bug target/97006] New: [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006 Bug ID: 97006 Summary: [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- First sign of trouble: ... FAIL: test_d_i:291: "%hhi" expected result for "-16657" doesn't match function call return value: 6 not in [1, 4]^M ...
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #14 from Christophe Lyon --- I that's easier for you, there are similar ICEs while running the GCC testsuite for aarch64-elf (newlib build works): Executed from: gcc.c-torture/compile/compile.exp gcc.c-torture/compile/950613-1.c -O2 (internal compiler error) gcc.c-torture/compile/950613-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/compile/950613-1.c -O3 -g (internal compiler error) gcc.c-torture/compile/pr25224.c -O2 (internal compiler error) gcc.c-torture/compile/pr25224.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/compile/pr25224.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) gcc.c-torture/compile/pr25224.c -O3 -g (internal compiler error) gcc.c-torture/compile/pr27863.c -O2 (internal compiler error) gcc.c-torture/compile/pr27863.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/compile/pr27863.c -O3 -g (internal compiler error) gcc.c-torture/compile/pr28489.c -O2 (internal compiler error) gcc.c-torture/compile/pr28489.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/compile/pr28489.c -O3 -g (internal compiler error) gcc.c-torture/compile/pr29128.c -O2 (internal compiler error) gcc.c-torture/compile/pr29128.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/compile/pr29128.c -O3 -g (internal compiler error) gcc.c-torture/compile/pr46107.c -O2 (internal compiler error) gcc.c-torture/compile/pr46107.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/compile/pr46107.c -O3 -g (internal compiler error) Executed from: gcc.c-torture/execute/execute.exp gcc.c-torture/execute/20040302-1.c -O2 (internal compiler error) gcc.c-torture/execute/20040302-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/execute/20040302-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) gcc.c-torture/execute/20040302-1.c -O3 -g (internal compiler error) gcc.c-torture/execute/20071210-1.c -O2 (internal compiler error) gcc.c-torture/execute/20071210-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/execute/20071210-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) gcc.c-torture/execute/20071210-1.c -O3 -g (internal compiler error) gcc.c-torture/execute/920302-1.c -O2 (internal compiler error) gcc.c-torture/execute/920302-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/execute/920302-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) gcc.c-torture/execute/920302-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) gcc.c-torture/execute/920302-1.c -O3 -g (internal compiler error) gcc.c-torture/execute/comp-goto-1.c -O2 (internal compiler error) gcc.c-torture/execute/comp-goto-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/execute/comp-goto-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) gcc.c-torture/execute/comp-goto-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) gcc.c-torture/execute/comp-goto-1.c -O3 -g (internal compiler error) Executed from: gcc.dg/torture/dg-torture.exp gcc.dg/torture/pr53695.c -O2 (internal compiler error) gcc.dg/torture/pr53695.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.dg/torture/pr53695.c -O3 -g (internal compiler error)
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #5 from Richard Biener ---
Now the question is whether/why we don't see any DW_TAG_inlined_subroutine
and why we inline anything at -O0 at all. That said, the middle-end does not
perform any inlining but the C++ FE inserts
finally
{
[/usr/include/c++/10/bits/basic_string.h:525:59]
std::allocator::~allocator
([/usr/include/c++/10/bits/basic_string.h:525:59] );
}
}
finally
{
[/usr/include/c++/10/bits/basic_string.h:525:59] D.37009 = {CLOBBER};
}
so somehow we leak the location of the dtor declaration to the GIMPLE stmt
created by the gimplifier.
Bisection is probably what is easiest to get us forward.
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3d0af0c997fe42a7f0963d970a9c495b81041206 commit r11-3096-g3d0af0c997fe42a7f0963d970a9c495b81041206 Author: Jakub Jelinek Date: Thu Sep 10 11:25:02 2020 +0200 lto: Stream current working directory for first streamed relative filename and adjust relative paths [PR93865] If the gcc -c -flto ... commands to compile some or all objects are run in a different directory (or in different directories) from the directory in which the gcc -flto link line is invoked, then the .debug_line will be incorrect if there are any relative filenames, it will use those relative filenames while .debug_info will contain a different DW_AT_comp_dir. The following patch streams (at most once after each clear_line_info) the current working directory (what we record in DW_AT_comp_dir) when encountering the first relative pathname, and when reading the location info reads it back and if the current working directory at that point is different from the saved one, adjusts relative paths by adding a relative prefix how to go from the current working directory to the previously saved path (with a fallback e.g. for DOS e:\\foo vs. d:\\bar change to use absolute directory). 2020-09-10 Jakub Jelinek PR debug/93865 * lto-streamer.h (struct output_block): Add emit_pwd member. * lto-streamer-out.c: Include toplev.h. (clear_line_info): Set emit_pwd. (lto_output_location_1): Encode the ob->current_file != xloc.file bit directly into the location number. If changing file, emit additionally a bit whether pwd is emitted and emit it before the first relative pathname since clear_line_info. (output_function, output_constructor): Don't call clear_line_info here. * lto-streamer-in.c (struct string_pair_map): New type. (struct string_pair_map_hasher): New type. (string_pair_map_hasher::hash): New method. (string_pair_map_hasher::equal): New method. (path_name_pair_hash_table, string_pair_map_allocator): New variables. (relative_path_prefix, canon_relative_path_prefix, canon_relative_file_name): New functions. (canon_file_name): Add relative_prefix argument, if non-NULL and string is a relative path, return canon_relative_file_name. (lto_location_cache::input_location_and_block): Decode file change bit from the location number. If changing file, unpack bit whether pwd is streamed and stream in pwd. Adjust canon_file_name caller. (lto_free_file_name_hash): Delete path_name_pair_hash_table and string_pair_map_allocator.
[Bug target/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96998 --- Comment #6 from Alex Coplan --- I have a patch, just testing it now.
[Bug tree-optimization/96043] BB vectorizer costing lumps everything together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96043 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/96043] BB vectorizer costing lumps everything together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96043 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:47ddf4c7b1d4471cb9534f27844ab5e4279c2168 commit r11-3095-g47ddf4c7b1d4471cb9534f27844ab5e4279c2168 Author: Richard Biener Date: Tue Sep 8 14:49:59 2020 +0200 tree-optimization/96043 - BB vectorization costing improvement This makes the BB vectorizer cost independent SLP subgraphs separately. While on pristine trunk and for x86_64 I failed to distill a testcase where the vectorizer would think _any_ basic-block vectorization opportunity is not profitable I do have pending work that would make the cost savings of a profitable opportunity make another independently not profitable opportunity vectorized. 2020-09-08 Richard Biener PR tree-optimization/96043 * tree-vectorizer.h (_slp_instance::cost_vec): New. (_slp_instance::subgraph_entries): Likewise. (BB_VINFO_TARGET_COST_DATA): Remove. * tree-vect-slp.c (vect_free_slp_instance): Free cost_vec and subgraph_entries. (vect_analyze_slp_instance): Initialize them. (vect_slp_analyze_operations): Defer passing costs to the target, instead record them in the SLP graph entry. (get_ultimate_leader): New helper for graph partitioning. (vect_bb_partition_graph_r): Likewise. (vect_bb_partition_graph): New function to partition the SLP graph into independently costable parts. (vect_bb_vectorization_profitable_p): Adjust to work on a subgraph. (vect_bb_vectorization_profitable_p): New wrapper, discarding non-profitable vectorization of subgraphs. (vect_slp_analyze_bb_1): Call vect_bb_partition_graph before costing. * gcc.dg/vect/costmodel/x86_64/costmodel-pr69297.c: Adjust.
[Bug tree-optimization/96993] [10/11 Regression] invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96993 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jakub Jelinek --- offsetof existed since forever and is portable. Anyway, I think Richard's change is completely fine and the testcase is broken in many ways, most importantly in what the commit talks about, that a difference of pointers should never produce a valid pointer. So, instead of (tUint8 *)(address_) - (tUint8 *)(&((struct tmm_blk_free_head_t *)0)->ql.column_list) you should use (tUint8 *)(address_) - offsetof (struct tmm_blk_free_head_t, ql.column_list) or worst case (tUint8 *)(address_) - ((tUint8 *)(&((struct tmm_blk_free_head_t *)0)->ql.column_list) - (tUint8 *)0), i.e. subtract from a pointer some integer, rather than pretending that from the difference of two pointers you get something that is a valid address and can be dereferenced.
[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233 SRINATH PARVATHANENI changed: What|Removed |Added CC||sripar01 at gcc dot gnu.org --- Comment #28 from SRINATH PARVATHANENI --- (In reply to Christophe Lyon from comment #24) > Created attachment 49169 [details] > a32/a64 intrinsics not supported by the aarch64 target The __crc* intrinsic are already supported (but defined in arm_acle.h instead). arm_acle.h:__crc32b (uint32_t __a, uint8_t __b) arm_acle.h:__crc32cb (uint32_t __a, uint8_t __b) arm_acle.h:__crc32cd (uint32_t __a, uint64_t __b) arm_acle.h:__crc32ch (uint32_t __a, uint16_t __b) arm_acle.h:__crc32cw (uint32_t __a, uint32_t __b) arm_acle.h:__crc32d (uint32_t __a, uint64_t __b) arm_acle.h:__crc32h (uint32_t __a, uint16_t __b) arm_acle.h:__crc32w (uint32_t __a, uint32_t __b)
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #13 from Christophe Lyon --- Created attachment 49206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49206=edit glibc testcase for aarch64 ICE The vfprintf-internal.i preprocessed source from glibc-2.29 creates an ICE on aarch64 with: cc1 -fpreprocessed vfprintf-internal.i -O2 -quiet during RTL pass: sched_fusion vfprintf-internal.c: In function '__vfprintf_internal': vfprintf-internal.c:1702:1: internal compiler error: in operator[], at vec.h:880 1702 | } | ^ 0x850282 vec::operator[](unsigned int) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/vec.h:880 0x850282 pre_and_rev_post_order_compute_fn(function*, int*, int*, bool) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfganal.c:1036 0x850337 pre_and_rev_post_order_compute(int*, int*, bool) [...]
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #6 from Jonathan Wakely --- const_cast lets you add/remove cv-qualifiers from pointers and references, but that doesn't make it OK to write to an object that was originally defined as const. Similar to how reinterpret_cast from int* to float* doesn't make it OK to violate TBAA rules. You can change the type, but that doesn't mean it's safe to use.
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #4 from Tom de Vries ---
-fdump-tree-all-lineno with gcc-10:
...
main ()
{
struct string D.37010;
struct allocator D.37009;
struct string D.37052;
struct allocator D.37051;
int D.40670;
[test.c:7:40] std::allocator::allocator ([test.c:7:40] );
[test.c:7:19] try
{
try
{
[test.c:7:40] std::__cxx11::basic_string::basic_string
([test.c:7:40]
, [test.c:7:40] "str1", [/usr/include/c++/10/bits/basic_string.h:525:59]
);
try
{
try
{
[test.c:7:40] std::operator<< ,
std::allocator<
char> > ([test.c:7:40] , [test.c:7:27] );
}
finally
{
[test.c:7:27] std::__cxx11::basic_string::~basic_string
([test.c:7:27]
);
}
}
finally
{
[test.c:7:27] D.37010 = {CLOBBER};
}
}
finally
{
[/usr/include/c++/10/bits/basic_string.h:525:59]
std::allocator::~allocator ([
/usr/include/c++/10/bits/basic_string.h:525:59] );
}
}
finally
{
[/usr/include/c++/10/bits/basic_string.h:525:59] D.37009 = {CLOBBER};
}
[test.c:8:40] std::allocator::allocator ([test.c:8:40] );
[test.c:8:19] try
{
try
{
[test.c:8:40] std::__cxx11::basic_string::basic_string
([test.c:8:40]
, [test.c:8:40] "str2", [/usr/include/c++/10/bits/basic_string.h:525:59]
);
try
{
try
{
[test.c:8:40] std::operator<< ,
std::allocator<
char> > ([test.c:8:40] , [test.c:8:27] );
}
finally
{
[test.c:8:27] std::__cxx11::basic_string::~basic_string
([test.c:8:27]
);
}
}
finally
{
[test.c:8:27] D.37052 = {CLOBBER};
}
}
finally
{
[/usr/include/c++/10/bits/basic_string.h:525:59]
std::allocator::~allocator ([
/usr/include/c++/10/bits/basic_string.h:525:59] );
}
}
finally
{
[/usr/include/c++/10/bits/basic_string.h:525:59] D.37051 = {CLOBBER};
}
[test.c:9:16] D.40670 = 0;
[test.c:9:16] return D.40670;
[test.c:10:1] D.40670 = 0;
[test.c:10:1] return D.40670;
}
...
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #3 from Tom de Vries ---
-fdump-tree-all-lineno with gcc-9:
...
main ()
{
struct string D.36200;
struct allocator D.36199;
struct string D.36242;
struct allocator D.36241;
int D.39843;
[test.c:7:27] std::allocator::allocator ([test.c:7:27] );
[test.c:7:19] try
{
try
{
[test.c:7:27] std::__cxx11::basic_string::basic_string
([test.c:7:27] , [test.c:7:27] "str1", );
try
{
try
{
[test.c:7:40] std::operator<< ,
std::allocator > ([test.c:7:40] , [test.c:7:27] );
}
finally
{
[test.c:7:27] std::__cxx11::basic_string::~basic_string
([test.c:7:27] );
}
}
finally
{
[test.c:7:27] D.36200 = {CLOBBER};
}
}
finally
{
[test.c:7:27] std::allocator::~allocator ([test.c:7:27]
);
}
}
finally
{
[test.c:7:27] D.36199 = {CLOBBER};
}
[test.c:8:27] std::allocator::allocator ([test.c:8:27] );
[test.c:8:19] try
{
try
{
[test.c:8:27] std::__cxx11::basic_string::basic_string
([test.c:8:27] , [test.c:8:27] "str2", );
try
{
try
{
[test.c:8:40] std::operator<< ,
std::allocator > ([test.c:8:40] , [test.c:8:27] );
}
finally
{
[test.c:8:27] std::__cxx11::basic_string::~basic_string
([test.c:8:27] );
}
}
finally
{
[test.c:8:27] D.36242 = {CLOBBER};
}
}
finally
{
[test.c:8:27] std::allocator::~allocator ([test.c:8:27]
);
}
}
finally
{
[test.c:8:27] D.36241 = {CLOBBER};
}
[test.c:9:16] D.39843 = 0;
[test.c:9:16] return D.39843;
[test.c:10:1] D.39843 = 0;
[test.c:10:1] return D.39843;
}
...
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997 --- Comment #2 from Tom de Vries --- Line number info for main [4009d2,400ad2] with g++ 9.3.1: ... CU: ./test.c: File nameLine numberStarting addressView Stmt test.c 60x4009d2 x test.c 70x4009db x test.c 70x4009fc x test.c 70x400a0d x test.c 80x400a25 x test.c 80x400a46 x test.c 80x400a57 x test.c 90x400a6f x test.c 70x400a79 x test.c 70x400a8a test.c 80x400aa4 x test.c 80x400ab5 test.c100x400acc x ... Line number info for main [4009d6,400ad5] with g++ 10.2.1: ... CU: ./test.c: File nameLine numberStarting addressView Stmt test.c 60x4009d6 x test.c 70x4009df x test.c 70x400a00 test.c 70x400a11 x /usr/include/c++/10/bits/basic_string.h: basic_string.h 5250x400a1d x ./test.c:[++] test.c 80x400a29 x test.c 80x400a4a test.c 80x400a5b x /usr/include/c++/10/bits/basic_string.h: basic_string.h 5250x400a67 x ./test.c:[++] test.c 90x400a73 x test.c 70x400a7a x /usr/include/c++/10/bits/basic_string.h: basic_string.h 5250x400a8b x ./test.c:[++] test.c 80x400aa5 x /usr/include/c++/10/bits/basic_string.h: basic_string.h 5250x400ab6 x ./test.c:[++] test.c100x400ad0 x ...
[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942 --- Comment #38 from Dmitriy Ovdienko --- Wohoo! Accepted: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #5 from Matthijs Kooijman --- > But isn't there const_cast<> to change the value of p? Yes, that makes it possible to write to a const object, but actually doing so is undefined behavior (see [dcl.type.cv] I quoted above). The spec even makes this explicit about const_cast, [expr.const.cast] says: > [ Note: Depending on the type of the object, a write operation through > the pointer, lvalue or pointer to data member resulting from a > const_cast that casts away a const-qualifier may produce undefined > behavior (7.1.6.1). — end note ]
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 CC||vries at gcc dot gnu.org Priority|P3 |P2 Known to fail||10.2.0 Known to work||7.5.0 Summary|step over in gdb always |[10/11 Regression] step |stops in basic_string(const |over in gdb always stops in |_CharT* __s, const _Alloc& |basic_string(const _CharT* |__a = _Alloc()) |__s, const _Alloc& __a = ||_Alloc())
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #4 from Richard Biener --- But isn't there const_cast<> to change the value of p?
[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000 --- Comment #9 from Richard Biener --- Meh, this way of forcing UNIQUE last to speedup lookup is a hack ... but yes, your patch from comment#7 looks OK if you add /* IFN_UNIQUE should be the last insn, to make checking for it as cheap as possible. */ before the new check to say what this is about. Note this will re-introduce the issue that passes cannot insert on loop entry edge without creating new BBs even if we forced preheaders to be created. For some very special case, when UNIQUE is involved. Thus we'll likely have even more hard to trigger latent bugs (before it was also former setjmp calls).
[Bug tree-optimization/96993] [10/11 Regression] invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96993 --- Comment #5 from Jan Smets --- Hi Andrew I agree that __builtin_offsetof would of good use here. However, I believe this code predates the availability of the builtin (was written around the time we were using gcc3.4)
