[Bug testsuite/98114] [11 regression] FAIL: gcc.target/i386/avx512vl-vandnpd-2.c execution test caused by r11-5391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98114 Richard Biener changed: What|Removed |Added Component|target |testsuite Target Milestone|--- |11.0
[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |11.0 Target||x86_64-*-* s390x-*-* Keywords||missed-optimization --- Comment #3 from Richard Biener --- The most straight-forward approach would be to treat r_14 = BIT_INSERT_EXPR ; r_33 = BIT_INSERT_EXPR ; r_32 = BIT_INSERT_EXPR ; r_31 = BIT_INSERT_EXPR ; itself as a SLP source much like we look for CTORs as SLP source. Note the transformed load is an extra complication but at least I added support to SLP existing vectors. Also regresses on x86_64. I'll see whether I can cook up sth.
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- We cannot support it on 32-bit platforms in any case.
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-03 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed. Does this come from real code or is it an artificial test?
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #11 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #10) > Could this PR be closed as INVALID? Yes, I think so.
[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108 --- Comment #1 from Richard Biener --- I think this is undefined since global object initialization order is not well-defined between TUs so thread1/thread2 and std::cout construction are not well-ordered. It probably works (by accident) when doing g++ -pthread file2.cc file1.cc
[Bug tree-optimization/98107] [11 regression] ICE at hash-table.c:137 starting with r11-5663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98107 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1
[Bug target/98114] [11 regression] FAIL: gcc.target/i386/avx512vl-vandnpd-2.c execution test caused by r11-5391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98114
--- Comment #1 from Hongtao.liu ---
Looking at testcase there's are pointer type conversion
void
CALC (double *s1, double *s2, double *r)
{
int i;
long long tmp;
for (i = 0; i < SIZE; i++)
{
tmp = (~(*(long long *) [i])) & (*(long long *) [i]);
r[i] = *(double *)
}
}
modified gcc/testsuite/gcc.target/i386/avx512dq-vandnpd-2.c
@@ -9,6 +9,7 @@
#include "avx512f-mask-type.h"
void
+__attribute__ ((optimize ("no-strict-aliasing"), noinline))
CALC (double *s1, double *s2, double *r)
{
int i;
modified gcc/testsuite/gcc.target/i386/avx512dq-vandpd-2.c
@@ -9,6 +9,7 @@
#include "avx512f-mask-type.h"
void
+__attribute__ ((optimize ("no-strict-aliasing"), noinline))
CALC (double *s1, double *s2, double *r)
{
int i;
modified gcc/testsuite/gcc.target/i386/avx512dq-vorpd-2.c
@@ -9,6 +9,7 @@
#include "avx512f-mask-type.h"
void
+__attribute__ ((optimize ("no-strict-aliasing"), noinline))
CALC (double *src1, double *src2, double *dst)
{
int i;
modified gcc/testsuite/gcc.target/i386/avx512dq-vxorpd-2.c
@@ -9,6 +9,7 @@
#include "avx512f-mask-type.h"
void
+__attribute__ ((optimize ("no-strict-aliasing"), noinline))
CALC (double *src1, double *src2, double *dst)
{
int i;
Could pass testcase.
[Bug c++/98105] constexpr and unnamed namespace yields relocation R_X86_64_PC32 against undefined symbol ... can not be used when making a shared object; recompile with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98105
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Ever confirmed|0 |1
Last reconfirmed||2020-12-03
--- Comment #1 from Richard Biener ---
So somehow we are not emitting
namespace
{
class myFactory:public factory
{ public:
static constexpr LIST s_sList = {
{1.0, 0}
};
...
};
}
but I'm not literate enough in C++ to tell if there's a definition missing.
It works with -std=c++17 but not with -std=c++11 or -std=c++14
[Bug c++/98104] [11 regression] -Wplacement-new false positive (struture padding?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98104 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98102] [9/10/11 Regression] ICE tree check: expected block, have function_decl in change_scope, at final.c:1480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98102 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4 Keywords||openacc --- Comment #1 from Richard Biener --- VTV and openacc ... eh
[Bug c++/98101] ICE in mark_reachable_handlers, at tree-eh.c:4033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98101 --- Comment #2 from Richard Biener --- VTV has it's issues and needs quite some TLC
[Bug target/98100] ICE in expand_debug_locations, at cfgexpand.c:5610
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98100 Richard Biener changed: What|Removed |Added Component|c |target --- Comment #1 from Richard Biener --- Not sure if valid - -mgeneral-regs-only forbits use of vector registers but the code explicitely asks for them(?)
[Bug target/98114] New: [11 regression] FAIL: gcc.target/i386/avx512vl-vandnpd-2.c execution test caused by r11-5391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98114
Bug ID: 98114
Summary: [11 regression] FAIL:
gcc.target/i386/avx512vl-vandnpd-2.c execution test
caused by r11-5391
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hubicka at ucw dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*
Also
FAIL: gcc.target/i386/avx512vl-vandpd-2.c execution test
FAIL: gcc.target/i386/avx512vl-vorpd-2.c execution test
FAIL: gcc.target/i386/avx512vl-vxorpd-2.c execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-5391/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandnpd-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandnpd-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandnpd-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandnpd-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandpd-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandpd-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandpd-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vandpd-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vorpd-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vorpd-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vorpd-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vorpd-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vxorpd-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vxorpd-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vxorpd-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vxorpd-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906 --- Comment #9 from Hongtao.liu --- Fixed in GCC11.
[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906 --- Comment #8 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:70310982492071f98eacdac0747521769b0f0328 commit r11-5697-g70310982492071f98eacdac0747521769b0f0328 Author: liuhongt Date: Mon Nov 30 13:27:16 2020 +0800 Optimize vpsubusw compared to 0 into vpcmpleuw or vpcmpnleuw [PR96906] For signed comparisons, it handles cases that are eq or neq to 0. For unsigned comparisons, it additionaly handles cases that are le or gt to 0(equivilent to eq or neq to 0). Transform case eq to leu, case neq to gtu. .i.e. for -mavx512bw -mavx512vl transform eq case code from vpsubusw%xmm1, %xmm0, %xmm0 vpxor %xmm1, %xmm1, %xmm1 vpcmpeqw %xmm1, %xmm0, %k0 to vpcmpleuw %xmm1, %xmm0, %k0 .i.e. for -mavx512bw -mavx512vl transform neq case code from vpsubusw%xmm1, %xmm0, %xmm0 vpxor %xmm1, %xmm1, %xmm1 vpcmpneqw %xmm1, %xmm0, %k0 to vpcmpnleuw %xmm1, %xmm0, %k0 gcc/ChangeLog PR target/96906 * config/i386/sse.md (_ucmp3): Add a new define_split after this insn. gcc/testsuite/ChangeLog * gcc.target/i386/avx512bw-pr96906-1.c: New test. * gcc.target/i386/pr96906-1.c: Add -mno-avx512f.
[Bug target/97642] Incorrect replacement of vmovdqu32 with vpblendd can cause fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97642 --- Comment #6 from Hongtao.liu --- Fixed in GCC11, GCC10 is fine, no need to backport.
[Bug target/97642] Incorrect replacement of vmovdqu32 with vpblendd can cause fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97642 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:35c4c67e6c534ef3d6ba7a7752ab7e0fbc91755b commit r11-5696-g35c4c67e6c534ef3d6ba7a7752ab7e0fbc91755b Author: liuhongt Date: Tue Nov 3 17:26:43 2020 +0800 Fix incorrect replacement of vmovdqu32 with vpblendd which can cause fault. gcc/ChangeLog: PR target/97642 * config/i386/i386-expand.c (ix86_expand_special_args_builtin): Don't move all-ones mask operands into register. * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec. (*_load_mask): New define_insns for masked load instructions. (_load_mask): Changed to define_expands which specifically handle memory or all-ones mask operands. (_blendm): Changed to define_insns which are same as original _load_mask with adjustment of operands order. (*_load): New define_insn_and_split which is used to optimize for masked load with all one mask. gcc/testsuite/ChangeLog: * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to make sure only masked load instruction is generated. * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto. * gcc.target/i386/avx512f-vmovapd-1.c: Ditto. * gcc.target/i386/avx512f-vmovaps-1.c: Ditto. * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto. * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto. * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto. * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto. * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto. * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto. * gcc.target/i386/pr97642-1.c: New test. * gcc.target/i386/pr97642-2.c: New test.
[Bug target/89057] [8/9/10/11 Regression] AArch64 ld3 st4 less optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057 --- Comment #8 from Abhiraj Garakapati --- Also, cross-checked it with the latest GCC version GCC-8.4.0 with above mentioned reverting changes of "aarch64-simd.md" file and got the expected output same as GCC-7.3.0.
[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113 --- Comment #2 from Kewen Lin --- (In reply to Kewen Lin from comment #1) > (In reply to Ilya Leoshkevich from comment #0) > > s390's vxe/popcount-1.c began to fail after PR96789 fix. > > Sorry to see this regression. > > ... > > > > > that is, replaced a sequence of stores with a sequence of > > BIT_INSERT_EXPRs. > > > > slp1 now says: "missed: not vectorized: no grouped stores in basic > > block", presumably because it doesn't understand BIT_INSERT_EXPRs. > > Yes, currently slp instance is built from group stores (also CTOR), I expect > Richi's ongoing slp rework will extend it to support group loads. For this > BIT_INSERT_EXPR, I guess we can extend vector CTOR handling to cover this if > the BIT_INSERT_EXPR chain can only and fully cover all lanes which is > equivalent to vector CTOR. > > CC @Richi. Hi Richi, what do you think of this? Or another idea is to teach FRE to optimize expected BIT_INSERT_EXPR chain to vector CTOR?
[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113 Kewen Lin changed: What|Removed |Added CC||rguenther at suse dot de Last reconfirmed||2020-12-03 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Kewen Lin --- (In reply to Ilya Leoshkevich from comment #0) > s390's vxe/popcount-1.c began to fail after PR96789 fix. Sorry to see this regression. ... > > that is, replaced a sequence of stores with a sequence of > BIT_INSERT_EXPRs. > > slp1 now says: "missed: not vectorized: no grouped stores in basic > block", presumably because it doesn't understand BIT_INSERT_EXPRs. Yes, currently slp instance is built from group stores (also CTOR), I expect Richi's ongoing slp rework will extend it to support group loads. For this BIT_INSERT_EXPR, I guess we can extend vector CTOR handling to cover this if the BIT_INSERT_EXPR chain can only and fully cover all lanes which is equivalent to vector CTOR. CC @Richi. Hi Richi, what do you think of this?
[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770 --- Comment #13 from Hongtao.liu --- (In reply to Richard Biener from comment #10) > Hmm, but > > DEF_INTERNAL_INT_FN (POPCOUNT, ECF_CONST | ECF_NOTHROW, popcount, unary) > > so there's clearly a mismatch between either the vectorizers interpretation > or the optab. But as far as I can see this is not a direct internal fn so > vectorizable_internal_function shouldn't apply and I do not see the x86 > backend handle POPCOUNT in the vectorizable function target hook. > > So w/o a compiler capable I can't trace how the vectorizer vectorizes this > and thus I have no idea where it goes wrong ... capable compiler is ready.
[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770 --- Comment #12 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:81d590760c31e11e3a09135f4e182aea232035f2 commit r11-5693-g81d590760c31e11e3a09135f4e182aea232035f2 Author: Hongyu Wang Date: Wed Nov 11 09:41:13 2020 +0800 Add popcount expander to enable popcount auto vectorization under AVX512BITALG/AVX512POPCNTDQ target. gcc/ChangeLog PR target/97770 * config/i386/sse.md (popcount2): New expander for SI/DI vector modes. (popcount2): Likewise for QI/HI vector modes. gcc/testsuite/ChangeLog PR target/97770 * gcc.target/i386/avx512bitalg-pr97770-1.c: New test. * gcc.target/i386/avx512vpopcntdq-pr97770-1.c: Likewise. * gcc.target/i386/avx512vpopcntdq-pr97770-2.c: Likewise. * gcc.target/i386/avx512vpopcntdqvl-pr97770-1.c: Likewise.
[Bug target/98093] ICE in gen_vsx_set_v2df, at config/rs6000/vsx.md:3276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093 --- Comment #2 from luoxhu at gcc dot gnu.org --- https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555907.html [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8
[Bug target/98093] ICE in gen_vsx_set_v2df, at config/rs6000/vsx.md:3276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093 luoxhu at gcc dot gnu.org changed: What|Removed |Added CC||luoxhu at gcc dot gnu.org --- Comment #1 from luoxhu at gcc dot gnu.org --- Confirmed, I will fix it. Actually I have pending patch not committed yet. [PATCH 2/4] which generate VIEW_CONVERT_EXPR is not committed, but V2DF VIEW_CONVERT_EXPR will be convert to IFN VEC_SET in gimple-isel now which caused the ICE. VIEW_CONVERT_EXPR(t)[i_12] = x_6(D); (https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555906.html) IFN VEC_SET is not expanded on Power8 yet, [PATCH 3/4] could fix this. Need Segher's approval.
[Bug tree-optimization/98113] New: [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113
Bug ID: 98113
Summary: [11 Regression] popcnt is not vectorized on s390 since
f5e18dd9c7da
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
s390's vxe/popcount-1.c began to fail after PR96789 fix.
The reason is that for the following source code
uv4si __attribute__((noinline))
vpopctf (uv4si a)
{
uv4si r;
int i;
for (i = 0; i < 4; i++)
r[i] = __builtin_popcount (a[i]);
return r;
}
FRE turned
_4 = BIT_FIELD_REF ;
_11 = __builtin_popcountD.1211 (_4);
_18 = (unsigned intD.9) _11;
BIT_FIELD_REF = _18;
i_20 = 1;
ivtmp_21 = 3;
_25 = VIEW_CONVERT_EXPR(aD.2283)[i_20];
_26 = __builtin_popcountD.1211 (_25);
_27 = (unsigned intD.9) _26;
VIEW_CONVERT_EXPR(rD.2286)[i_20] = _27;
i_29 = i_20 + 1;
ivtmp_30 = ivtmp_21 + 4294967295;
_34 = VIEW_CONVERT_EXPR(aD.2283)[i_29];
_35 = __builtin_popcountD.1211 (_34);
_36 = (unsigned intD.9) _35;
VIEW_CONVERT_EXPR(rD.2286)[i_29] = _36;
i_38 = i_29 + 1;
ivtmp_39 = ivtmp_30 + 4294967295;
_1 = VIEW_CONVERT_EXPR(aD.2283)[i_38];
_2 = __builtin_popcountD.1211 (_1);
_3 = (unsigned intD.9) _2;
VIEW_CONVERT_EXPR(rD.2286)[i_38] = _3;
i_10 = i_38 + 1;
ivtmp_16 = ivtmp_39 + 4294967295;
_7 = rD.2286;
rD.2286 ={v} {CLOBBER};
return _7;
into
_4 = BIT_FIELD_REF ;
_11 = __builtin_popcountD.1211 (_4);
_18 = (unsigned intD.9) _11;
r_14 = BIT_INSERT_EXPR ;
_25 = BIT_FIELD_REF ;
_26 = __builtin_popcountD.1211 (_25);
_27 = (unsigned intD.9) _26;
r_33 = BIT_INSERT_EXPR ;
_34 = BIT_FIELD_REF ;
_35 = __builtin_popcountD.1211 (_34);
_36 = (unsigned intD.9) _35;
r_32 = BIT_INSERT_EXPR ;
_1 = BIT_FIELD_REF ;
_2 = __builtin_popcountD.1211 (_1);
_3 = (unsigned intD.9) _2;
r_31 = BIT_INSERT_EXPR ;
_7 = r_31;
return _7;
that is, replaced a sequence of stores with a sequence of
BIT_INSERT_EXPRs.
slp1 now says: "missed: not vectorized: no grouped stores in basic
block", presumably because it doesn't understand BIT_INSERT_EXPRs.
[Bug c/98112] New: Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 Bug ID: 98112 Summary: Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- After "x86-64: Optimize access to globals in PIE with copy reloc", GCC x86-64 asks the assembler to produce an R_X86_64_PC32 for an external data access. * It introduced a configure-time variable HAVE_LD_PIE_COPYRELOC which has a misleading name: PC32 does not necessarily cause a copy relocation. If the external data * It affects users who want to configure GCC not to emit R_X86_64_PC32 for an external data access so that copy relocations can be avoided if the data turns out to be defined in a different shared object/executable * While it made sense (in turns of performance) before H.J. Lu added GOTPCRELX to x86-64, it hardly matters if any nowadays. * This optimization can actually benefit non-x86-64. An option is more suitable. In Clang, the GCC style HAVE_LD_PIE_COPYRELOC is implemented as -mpie-copy-relocations, which has a misleading name. I agree that this should be implemented as an option, instead of a configure-time variable. I suggest that we add a new architecture-independent option -f[no-]direct-access-external-data (I am happy to add a similar one in Clang once consensus is made) and delete HAVE_LD_PIE_COPYRELOC. The option means whether a direct access (PC-relative relocation) can be generated for an external data access. The value can default to true for -fno-pic code (it seems that most architectures behave this way). For non-x86-64, the value defaults to false for -fpie/-fpic code (I believe most architectures use a GOT). In the future, for x86-64, please consider defaulting to -fno-direct-access-external-data for -fpie/-fpic so that issues related to STV_PROTECTED data can be properly fixed (see my analysis last year https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html )
[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-12-03
Ever confirmed|0 |1
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
Blocks||95507
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
The warings are caused by the null tests inserted by the sanitizer that jump
threading turns into calls with constant nulls. See below. Adding attribute
nonnull also to swap_1000 avoids both the warnings and the sanitization.
This is a known problem with the sanitizer and the late warnings and there
probably is a report like this one in Bugzilla somewhere. I suppose the
warning code could look for calls __builtin___ubsan_handle_nonnull_arg (and
similar) preceding the statement it's about to diagnose and avoid triggering if
it's found. Until something like this is implemented the guidance is to live
with these warnings when using the sanitizer or suppress them by -Wno-xxx.
$ gcc -O2 -S -Wall -fsanitize=undefined -fdump-tree-ubsan=/dev/stdout
-fdump-tree-dom2=/dev/stdout pr98109.c
;; Function swap_1000 (swap_1000, funcdef_no=0, decl_uid=2388, cgraph_uid=1,
symbol_order=0)
Introduced new external node (__builtin___ubsan_handle_nonnull_arg/3).
Symbols to be put in SSA form
{ D.2392 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 15
Number of blocks to update: 14 ( 93%)
void swap_1000 (char * elem1, char * elem2, size_t element_size)
{
char buffer[1000];
:
if ( == 0B)
goto ; [0.05%]
else
goto ; [99.95%]
:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0);
:
if (elem1_2(D) == 0B)
goto ; [0.05%]
else
goto ; [99.95%]
:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data1);
:
my_memcpy (, elem1_2(D), 1000);
if (elem1_2(D) == 0B)
goto ; [0.05%]
else
goto ; [99.95%]
:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);
:
if (elem2_4(D) == 0B)
goto ; [0.05%]
else
goto ; [99.95%]
:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data3);
:
my_memcpy (elem1_2(D), elem2_4(D), 1000);
if (elem2_4(D) == 0B)
goto ; [0.05%]
else
goto ; [99.95%]
:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data4);
:
if ( == 0B)
goto ; [0.05%]
else
goto ; [99.95%]
:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data5);
:
my_memcpy (elem2_4(D), , 1000);
buffer ={v} {CLOBBER};
return;
}
;; Function swap_1000 (swap_1000, funcdef_no=0, decl_uid=2388, cgraph_uid=1,
symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7 8
;; 2 succs { 8 3 }
;; 3 succs { 4 }
;; 4 succs { 7 5 }
;; 5 succs { 6 }
;; 6 succs { 1 }
;; 7 succs { 6 }
;; 8 succs { 4 }
void swap_1000 (char * elem1, char * elem2, size_t element_size)
{
char buffer[1000];
[local count: 1073741824]:
if (elem1_2(D) == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data1);
my_memcpy (, 0B, 1000);
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);
[local count: 1073741824]:
if (elem2_4(D) == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data3);
my_memcpy (elem1_2(D), 0B, 1000);
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data4);
[local count: 1073741824]:
my_memcpy (elem2_4(D), , 1000);
buffer ={v} {CLOBBER};
return;
[local count: 1073741824]:
my_memcpy (elem1_2(D), elem2_4(D), 1000);
goto ; [100.00%]
[local count: 1073741824]:
my_memcpy (, elem1_2(D), 1000);
goto ; [100.00%]
}
pr98109.c: In function ‘swap_1000’:
pr98109.c:11:5: warning: argument 2 is null but the corresponding size argument
3 value is 1000 [-Wnonnull]
11 | my_memcpy(buffer, elem1, 1000);
| ^~
pr98109.c:3:7: note: in a call to function ‘my_memcpy’ declared with attribute
‘access (read_only, 2, 3)’
3 | void *my_memcpy(void *destination, const void *source, size_t size)
| ^
pr98109.c:12:5: warning: argument 2 is null but the corresponding size argument
3 value is 1000 [-Wnonnull]
12 | my_memcpy(elem1, elem2, 1000);
| ^
pr98109.c:3:7: note: in a call to function ‘my_memcpy’ declared with attribute
‘access (read_only, 2, 3)’
3 | void *my_memcpy(void *destination, const void *source, size_t size)
| ^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug testsuite/98111] [11 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-18.c fails after r11-5674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98111 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Sebor --- These should be gone with r11-5690.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #34 from abebeos at lazaridis dot com --- (In reply to abebeos from comment #29) [...] > I will today focus on publishing my test-setup, so that my test-results can > be peer-reviewed. Should be available within 12 hours, max 36. [...] https://github.com/abebeos/avr-gnu - drafty, you should await the next version before trying. avrtest setup is missing.
[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 Jakub Jelinek changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #1 from Jakub Jelinek --- *** Bug 98106 has been marked as a duplicate of this bug. ***
[Bug ipa/98106] [11 Regression] gcc trunk miscompiles glibc dynamic loader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Another PR has more details. *** This bug has been marked as a duplicate of bug 98110 ***
[Bug c++/97947] [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Decembe ||r/560922.html --- Comment #7 from Peter Bergner --- Fix pushed to trunk.
[Bug testsuite/98111] New: [11 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-18.c fails after r11-5674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98111 Bug ID: 98111 Summary: [11 regression] gcc.dg/tree-ssa/builtin-sprintf-warn-18.c fails after r11-5674 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:0a7dc4b6440faa8cd57c630f1e394a719469c399, r11-5674 make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-18.c" FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 120) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 122) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors) # of expected passes61 # of unexpected failures3 Looks like the change to builtin-sprintf-warn-18.c isn't quite working right.
[Bug c++/97947] [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947 --- Comment #6 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:7e231b2cfbfa5f99bbf581555ca74eaaba42ad7f commit r11-5687-g7e231b2cfbfa5f99bbf581555ca74eaaba42ad7f Author: Peter Bergner Date: Wed Dec 2 18:12:59 2020 -0600 c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947] MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers from knowing how the bits in a variable with an opaque type are laid out. This makes them a kind of pseudo aggregate type and we need to treat them as such when we process the INIT initializer for variables with an opaque type. 2020-12-02 Peter Bergner gcc/cp/ PR c++/97947 * typeck2.c (digest_init_r): Handle OPAQUE_TYPE as an aggregate type. gcc/testsuite/ PR c++/97947 * g++.target/powerpc/pr97947.C: New test.
[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 H.J. Lu changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/98110] New: [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110
Bug ID: 98110
Summary: [11 Regression] dl-lookup.c in glibc is miscompiled by
r11-5029
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: jh at suse dot cz
Target Milestone: ---
Target: x86-64
Created attachment 49667
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49667=edit
A testcase
On Linux/x86-64, r11-5029 miscompiled dl-lookup.c with
-O2 -std=gnu11 -fgnu89-inline -O2 -g -Wall -Wwrite-strings -Wundef -Werror
-fmerge-all-constants -frounding-math -fno-stack-protector -Wstrict-prototypes
-Wold-style-definition -fmath-errno -fPIC -fno-stack-protector -mno-mmx
-fexceptions -fasynchronous-unwind-tables -ftls-model=initial-exec
_dl_lookup_symbol_x:
.LVL199:
.LFB73:
.loc 1 835 1 view -0
.cfi_startproc
.loc 1 835 1 is_stmt 0 view .LVU632
pushq %r15
.cfi_def_cfa_offset 16
.cfi_offset 15, -16
pushq %r14
.cfi_def_cfa_offset 24
.cfi_offset 14, -24
pushq %r13
.cfi_def_cfa_offset 32
.cfi_offset 13, -32
pushq %r12
.cfi_def_cfa_offset 40
.cfi_offset 12, -40
movq%rdi, %r12
pushq %rbp
.cfi_def_cfa_offset 48
.cfi_offset 6, -48
movq%rdx, %rbp
pushq %rbx
.cfi_def_cfa_offset 56
.cfi_offset 3, -56
.LBB251:
.LBB252:
.LBB253:
.LBB254:
.LBB255:
.LBB256:
.loc 1 640 72 view .LVU633
#APP
# 640 "dl-lookup.c" 1
mov %fs:16,%rax
# 0 "" 2
#NO_APP
Source has
/* Make sure nobody can unload the object while we are at it. */
if (__glibc_unlikely (flags & DL_LOOKUP_GSCOPE_LOCK))
{
/* We can't just call __rtld_lock_lock_recursive (GL(dl_load_lock))
here, that can result in ABBA deadlock. */
THREAD_GSCOPE_RESET_FLAG ();
__rtld_lock_lock_recursive (GL(dl_load_lock));
/* While MAP value won't change, after THREAD_GSCOPE_RESET_FLAG ()
it can e.g. point to unallocated memory. So avoid the optimizer
treating the above read from MAP->l_serial as ensurance it
can safely dereference it. */
But the check is removed by GCC 11.
[Bug c++/80780] Front-end support needed for experimental::source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba3d8dffcc1c23b30370ab24fc20d09cff005d7b commit r11-5685-gba3d8dffcc1c23b30370ab24fc20d09cff005d7b Author: Jakub Jelinek Date: Thu Dec 3 00:25:51 2020 +0100 c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093] While std::source_location::current () is static consteval source_location current() noexcept; in the standard, it also says with LWG3396: "Any call to current that appears as a default member initializer ([class.mem]), or as a subexpression thereof, should correspond to the location of the constructor definition or aggregate initialization that uses the default member initializer. Any call to current that appears as a default argument ([dcl.fct.default]), or as a subexpression thereof, should correspond to the location of the invocation of the function that uses the default argument ([expr.call])." so it must work as compiler magic rather than normal immediate functions, in particular we need to defer its evaluation when parsing default arguments or nsdmis. This patch actually defers evaluation of all the calls to std::source_location::current () until genericization (or constant expression evaluation when called from constant expression contexts). I had to change constexpr.c too so that it temporarily adjusts current_function_decl from the constexpr evaluation context, but we do the same already from __builtin_FUNCTION (). 2020-12-03 Jakub Jelinek PR c++/80780 PR c++/93093 * cp-tree.h (source_location_current_p): Declare. * tree.c (source_location_current_p): New function. * call.c (immediate_invocation_p): New function. (build_over_call): Use it to resolve LWG3396. * constexpr.c (cxx_eval_builtin_function_call): Temporarily set current_function_decl from ctx->call->fundef->decl if any. * cp-gimplify.c (cp_genericize_r) : Fold calls to immediate function std::source_location::current (). * g++.dg/cpp2a/srcloc15.C: New test. * g++.dg/cpp2a/srcloc16.C: New test. * g++.dg/cpp2a/srcloc17.C: New test. * g++.dg/cpp2a/srcloc18.C: New test.
[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba3d8dffcc1c23b30370ab24fc20d09cff005d7b commit r11-5685-gba3d8dffcc1c23b30370ab24fc20d09cff005d7b Author: Jakub Jelinek Date: Thu Dec 3 00:25:51 2020 +0100 c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093] While std::source_location::current () is static consteval source_location current() noexcept; in the standard, it also says with LWG3396: "Any call to current that appears as a default member initializer ([class.mem]), or as a subexpression thereof, should correspond to the location of the constructor definition or aggregate initialization that uses the default member initializer. Any call to current that appears as a default argument ([dcl.fct.default]), or as a subexpression thereof, should correspond to the location of the invocation of the function that uses the default argument ([expr.call])." so it must work as compiler magic rather than normal immediate functions, in particular we need to defer its evaluation when parsing default arguments or nsdmis. This patch actually defers evaluation of all the calls to std::source_location::current () until genericization (or constant expression evaluation when called from constant expression contexts). I had to change constexpr.c too so that it temporarily adjusts current_function_decl from the constexpr evaluation context, but we do the same already from __builtin_FUNCTION (). 2020-12-03 Jakub Jelinek PR c++/80780 PR c++/93093 * cp-tree.h (source_location_current_p): Declare. * tree.c (source_location_current_p): New function. * call.c (immediate_invocation_p): New function. (build_over_call): Use it to resolve LWG3396. * constexpr.c (cxx_eval_builtin_function_call): Temporarily set current_function_decl from ctx->call->fundef->decl if any. * cp-gimplify.c (cp_genericize_r) : Fold calls to immediate function std::source_location::current (). * g++.dg/cpp2a/srcloc15.C: New test. * g++.dg/cpp2a/srcloc16.C: New test. * g++.dg/cpp2a/srcloc17.C: New test. * g++.dg/cpp2a/srcloc18.C: New test.
[Bug ipa/98106] [11 Regression] gcc trunk miscompiles glibc dynamic loader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Summary|gcc trunk miscompiles glibc |[11 Regression] gcc trunk |dynamic loader |miscompiles glibc dynamic ||loader Target Milestone|--- |11.0 Severity|normal |blocker
[Bug ipa/98106] gcc trunk miscompiles glibc dynamic loader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-12-02
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 Andrew Pinski changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Keywords||diagnostic, documentation --- Comment #1 from Andrew Pinski --- This only matters now because output for assembly goto was only added for GCC 11. Which was introduced with: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558870.html
[Bug middle-end/98109] New: Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109
Bug ID: 98109
Summary: Seemingly wrong warnings from -Wnonnull when combined
with -O2 -fsanitize=undefined
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef __SIZE_TYPE__ size_t;
void *my_memcpy(void *destination, const void *source, size_t size)
__attribute__((nonnull (1, 2)))
__attribute__((access (write_only, 1, 3))) __attribute__((access
(read_only, 2, 3)));
void swap_1000(char *elem1, char *elem2, size_t element_size)
{
char buffer[1000];
my_memcpy(buffer, elem1, 1000);
my_memcpy(elem1, elem2, 1000);
my_memcpy(elem2, buffer, 1000);
}
When compiling this with -Wnonnull -O2 -fsanitize=undefined, these warnings are
observed :
test.c: In function ‘swap_1000’:
test.c:11:5: warning: argument 2 is null but the corresponding size argument 3
value is 1000 [-Wnonnull]
11 | my_memcpy(buffer, elem1, 1000);
| ^~
test.c:3:7: note: in a call to function ‘my_memcpy’ declared with attribute
‘read_only (2, 3)’
3 | void *my_memcpy(void *destination, const void *source, size_t size)
| ^
test.c:12:5: warning: argument 2 is null but the corresponding size argument 3
value is 1000 [-Wnonnull]
12 | my_memcpy(elem1, elem2, 1000);
| ^
test.c:3:7: note: in a call to function ‘my_memcpy’ declared with attribute
‘read_only (2, 3)’
3 | void *my_memcpy(void *destination, const void *source, size_t size)
| ^
[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 qinzhao at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from qinzhao at gcc dot gnu.org --- fixed in gcc11
[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #6 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:2cace1cd683318e83e8a613f1aa2f2b16e37a342 commit r11-5684-g2cace1cd683318e83e8a613f1aa2f2b16e37a342 Author: qing zhao Date: Wed Dec 2 23:48:02 2020 +0100 rtl-optimization: Fix data flow maintenance bug in reg-stack.c [pr9] reg-stack pass does not maintain the data flow information correctly. call df_insn_rescan_all after the transformation is done. gcc/ PR rtl-optimization/9 * reg-stack.c (rest_of_handle_stack_regs): call df_insn_rescan_all if reg_to_stack return true. gcc/testsuite/ PR rtl-optimization/9 * gcc.target/i386/pr9.c: New test.
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #10 from Dominique d'Humieres --- Could this PR be closed as INVALID?
[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 --- Comment #10 from Dominique d'Humieres --- The manual says: > On systems that provide libgfortran as a shared and a static library, > this option forces the use of the static version. If no shared version > of libgfortran was built when the compiler was configured, this option > has no effect. On MacOSX if I compile a simple test, I get a.out: /opt/gcc/gcc11w/lib/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0) /opt/gcc/gcc11w/lib/libgcc_s.2.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/gcc/gcc11w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) with -static-libgfortran a.out: /opt/gcc/gcc11w/lib/libgcc_s.2.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/gcc/gcc11w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) and with -static-libgfortran -static-libgcc a.out: /opt/gcc/gcc11w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) So AFAICT on an OS for which -fpic is the default everything seems to work.
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 --- Comment #9 from Jonathan Wakely --- (In reply to dave.anglin from comment #7) > Currently, we also have the following two additional fails: > > FAIL: libstdc++-prettyprinters/91997.cc print a > FAIL: libstdc++-prettyprinters/91997.cc print a Yes it's the same printer for the same type. If the commit above fixed it for libfundts.cc it should fix it for those too. It's possible the problem here is different from the PR 65480 problem for powerpc64 though, so I'll wait to see how your next tests go.
[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed on trunk. I will probably backport this too.
[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:dc2b372ed1b1e9af6db45051cff95478c7616807 commit r11-5683-gdc2b372ed1b1e9af6db45051cff95478c7616807 Author: Jonathan Wakely Date: Wed Dec 2 21:39:08 2020 + libstdc++: Fix std::any pretty printer [PR 68735] This fixes errors seen on powerpc64 (big endian only) due to the printers for std::any and std::experimental::any being unable to find the manager function. libstdc++-v3/ChangeLog: PR libstdc++/65480 PR libstdc++/68735 * python/libstdcxx/v6/printers.py (function_pointer_to_name): New helper function to get the name of a function from its address. (StdExpAnyPrinter.__init__): Use it.
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:dc2b372ed1b1e9af6db45051cff95478c7616807 commit r11-5683-gdc2b372ed1b1e9af6db45051cff95478c7616807 Author: Jonathan Wakely Date: Wed Dec 2 21:39:08 2020 + libstdc++: Fix std::any pretty printer [PR 68735] This fixes errors seen on powerpc64 (big endian only) due to the printers for std::any and std::experimental::any being unable to find the manager function. libstdc++-v3/ChangeLog: PR libstdc++/65480 PR libstdc++/68735 * python/libstdcxx/v6/printers.py (function_pointer_to_name): New helper function to get the name of a function from its address. (StdExpAnyPrinter.__init__): Use it.
[Bug libstdc++/65480] libstdc++-prettyprinters/libfundts.cc test failures on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/98108] New: Broken Schwarz counter for iostreams initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108
Bug ID: 98108
Summary: Broken Schwarz counter for iostreams initialization
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: i.hamsa at gmail dot com
Target Milestone: ---
Iostreams initialization doesn't work in multithreaded environments.
To reproduce one needs two source files:
// file1.cc
#include
void threadfunc();
struct StaticThread {
std::thread t;
StaticThread() : t(threadfunc) {}
~StaticThread() { t.join(); }
};
static StaticThread thread1, thread2;
//file2.cc
#include
void threadfunc() {
std::cout << "Printing\n";
}
int main() {}
//compile
g++ -pthread file1.cc file2.cc
It is important that is NOT included in file1.cc.
The resulting executable always crashes on my machine (Gentoo Linux). Add
to file1.cc, the crash disappears. Change the order of source files
in the command line, the crash disappears.
---
The culprit is ios_base::Init::_S_refcount. Basically it is an atomic nifty
counter. The problem is, the nifty counter idiom doesn't work with
multithreading. Making it atomic achieves absolutely nothing. If we have two or
more threads that can enter Init::Init() at the same time, one should proceed
and the rest must WAIT. It is the same thing as initialization of a static
object in a block scope, and should be interlocked in exactly the same way.
[Bug fortran/97571] long parsing phase for simple array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > > So the new compiler does compile-time simplification already at -O0, > > while older versions maybe not. > > Is this expected? Depends. I'd expect constant expressions like this to be simplified. There could be (artificial) limits when to give up. The tree dump does not really give me the impression nor enough information to know that this happens with previous version of the compiler at this stage.
[Bug fortran/97024] Overriding finalization on polymorphic types triggers ICE error in generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-12-02 Status|UNCONFIRMED |WAITING --- Comment #3 from Dominique d'Humieres --- Confirmed from GCC9 up to trunk.
[Bug tree-optimization/98107] New: [11 regression] ICE at hash-table.c:137 starting with r11-5663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98107 Bug ID: 98107 Summary: [11 regression] ICE at hash-table.c:137 starting with r11-5663 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:329ae1d7751346ba166d34e77a43e8cc33daa1c9, r11-5663 make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/template/canon-type-4.C" FAIL: g++.dg/template/canon-type-4.C -std=c++14 (internal compiler error) FAIL: g++.dg/template/canon-type-4.C -std=c++14 (test for excess errors) # of expected passes3 # of unexpected failures2 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/template/canon-type-4.C -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 -std=c++14 -pedantic-errors -Wno-long-long -S -o canon-type-4.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/template/canon-type-4.C -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 -std=c++14 -pedantic-errors -Wno-long-long -S -o canon-type-4.s hash table checking failed: equal operator returns true for a pair of values with a different hash value /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/template/canon-type-4.C:18:9: internal compiler error: in hashtab_chk_error, at hash-table.c:137 0x1029e5bf hashtab_chk_error() /home/seurer/gcc/git/gcc-test/gcc/hash-table.c:137 0x105c7147 hash_table::verify(spec_entry* const&, unsigned int) /home/seurer/gcc/git/gcc-test/gcc/hash-table.h:1033 0x105c7343 hash_table::find_with_hash(spec_entry* const&, unsigned int) /home/seurer/gcc/git/gcc-test/gcc/hash-table.h:918 0x1057cfcf lookup_template_class_1 /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:9830 0x1057cfcf lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:10186 0x10580d63 tsubst_aggr_type /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:13488 0x10564817 tsubst(tree_node*, tree_node*, int, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:15374 0x1057a247 coerce_template_parms /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:8930 0x1057cebb lookup_template_class_1 /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:9798 0x1057cebb lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:10186 0x105ee5eb finish_template_type(tree_node*, tree_node*, int) /home/seurer/gcc/git/gcc-test/gcc/cp/semantics.c:3442 0x10500027 cp_parser_template_id /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:16991 0x10500687 cp_parser_class_name /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:24213 0x104fad97 cp_parser_qualifying_entity /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:6861 0x104fad97 cp_parser_nested_name_specifier_opt /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:6543 0x104fbbab cp_parser_nested_name_specifier /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:6787 0x10505267 cp_parser_using_declaration /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:20130 0x1051c43b cp_parser_member_declaration /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:25448 0x104d7927 cp_parser_member_specification_opt /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:25310 0x104d7927 cp_parser_class_specifier_1 /home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:24399
[Bug fortran/97571] long parsing phase for simple array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-12-02 Priority|P3 |P4 --- Comment #2 from Dominique d'Humieres --- > So the new compiler does compile-time simplification already at -O0, > while older versions maybe not. Is this expected?
[Bug fortran/96839] gfortran thinks common_bits starts a common block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96839 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- > > Could this PR be considered as FIXED? > > I think so. No objection since three months, closing.
[Bug fortran/94464] [F08] coarrays shoud be enabled by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94464 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-02 --- Comment #3 from Dominique d'Humieres --- > Since "coarrays" is part of Standard Fortran and not an experimental feature > or an extension, why putting it behind a flag? > > There would be a flag to disable it, maybe. > "-fcoarray=single" should be the default. I agree coarrays should be silently accepted. However "-fcoarray=single" has very little interest beside syntax checking. There is a work in progress to implement coarrays with shared memory and to default to "-fcoarray=shared" would much better.
[Bug ipa/98106] gcc trunk miscompiles glibc dynamic loader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I'd say the next step after bisecting a gcc change is bisect which source file it is on (if you have a suspect one, just confirm that, e.g. if you compile the whole dynamic linker with the trunk gcc (or the r11-5029 version) and just that single TU with r11-5028, does it still work? And vice versa, if you compile everything with r11-5028 and only the single TU with r11-5029, does it crash too? In that case, please attach preprocessed source of that TU and state exact gcc command line options. Thanks.
[Bug fortran/97612] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-12-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Is the test valid? What is t() supposed to do?
[Bug ipa/98106] New: gcc trunk miscompiles glibc dynamic loader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106 Bug ID: 98106 Summary: gcc trunk miscompiles glibc dynamic loader Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi, I would like to report a regression in trunk which for me result in glibc segfaulting in the dynamic linker at the very beginning of symbol resolution. I do compile binutils 2.35 (from the release branch, I use git commit 1c5243df7f8c0a18f1518825ab1dacdf40188a41), then gcc, and with the resulting gcc + binutils I build glibc (taken from a rather recent commit from master, git sha1 29fddfc7dfd6444fa61a256e9a0d0127545e1f2e). I build this on x86_64, using just the CFLAGS/CXXFLAGS "-O2" when building all these components. This resulting glibc seems to be miscompiled, as running any program with its dynamic linker results in this seg fault: root@e92b8eb029ef:/# /workdir/build/temporary-system/install/lib/libc.so.6 Segmentation fault (core dumped) root@e92b8eb029ef:/# gdb /workdir/build/temporary-system/install/lib/libc.so.6 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 ... (snapped) Reading symbols from /workdir/build/temporary-system/install/lib/libc.so.6...done. (gdb) r Starting program: /workdir/build/temporary-system/install/lib/libc.so.6 Program received signal SIGSEGV, Segmentation fault. 0x77fdadf0 in _dl_lookup_symbol_x () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 (gdb) bt #0 0x77fdadf0 in _dl_lookup_symbol_x () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #1 0x77fd3627 in dl_main () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #2 0x77fea277 in _dl_sysdep_start () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #3 0x77fd2009 in _dl_start () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #4 0x77fd1058 in _start () from /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 #5 0x0001 in ?? () #6 0x7fffeeae in ?? () #7 0x in ?? () (gdb) info shared >FromTo Syms Read Shared Object Library 0x77fd1050 0x77ff132e Yes (*) /workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2 (gdb) disas (*): Shared library is missing debugging information. Dump of assembler code for function _dl_lookup_symbol_x: 0x77fdade0 <+0>: push %r15 0x77fdade2 <+2>: push %r14 0x77fdade4 <+4>: push %r13 0x77fdade6 <+6>: push %r12 0x77fdade8 <+8>: mov%rdi,%r12 0x77fdadeb <+11>:push %rbp 0x77fdadec <+12>:mov%rdx,%rbp 0x77fdadef <+15>:push %rbx => 0x77fdadf0 <+16>:mov%fs:0x10,%rax 0x77fdadf9 <+25>:sub$0x98,%rsp 0x77fdae00 <+32>:mov%rsi,0x8(%rsp) 0x77fdae05 <+37>:mov%rcx,0x18(%rsp) 0x77fdae0a <+42>:mov%r8,(%rsp) 0x77fdae0e <+46>:mov%r9d,0x14(%rsp) 0x77fdae13 <+51>:mov%rax,0x28(%rsp) 0x77fdae18 <+56>:movzbl (%r12),%edx 0x77fdae1d <+61>:test %dl,%dl 0x77fdae1f <+63>:je 0x77fdb050 <_dl_lookup_symbol_x+624> 0x77fdae25 <+69>:mov%r12,%rcx 0x77fdae28 <+72>:mov$0x1505,%ebx 0x77fdae2d <+77>:nopl (%rax) (gdb) info reg rax0x7fffe980 140737488349568 rbx0x7fffe9a0 140737488349600 rcx0x77ffeb08 140737354132232 rdx0x7fffe978 140737488349560 rsi0x77ffe770 140737354131312 rdi0x77ff32ea 140737354085098 rbp0x7fffe978 0x7fffe978 rsp0x7fffe8b8 0x7fffe8b8 r8 0x7fffe9a0 140737488349600 r9 0x0 0 r100x7022 1879048226 r110x3250 r120x77ff32ea 140737354085098 r130x77ffe770 140737354131312 r140x7fffe978 140737488349560 r150x0 0 rip0x77fdadf0 0x77fdadf0 <_dl_lookup_symbol_x+16> eflags 0x10246 [ PF ZF IF RF ] cs 0x3351 ss 0x2b43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Gcc's trunk from early november had no problem, but trunk from 1st december does expose this
[Bug target/98060] Failure to optimize cmp+setnb+add to cmp+sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98060 Uroš Bizjak changed: What|Removed |Added Attachment #49663|0 |1 is obsolete|| --- Comment #4 from Uroš Bizjak --- Created attachment 49666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49666=edit Updated patch
[Bug c++/97975] [8/9/10 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97975 Marek Polacek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE |unexpected expression |unexpected expression |'(int)A<|'(int)A< || |>::b' of kind |>::b' of kind |implicit_conv_expr |implicit_conv_expr --- Comment #4 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/97975] [8/9/10/11 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97975 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:69bf1c7d5ee21392334f1982d1b40c38e103bbd4 commit r11-5678-g69bf1c7d5ee21392334f1982d1b40c38e103bbd4 Author: Marek Polacek Date: Tue Dec 1 10:39:08 2020 -0500 c++: Fix ICE with inline variable in template [PR97975] In this test, we have static inline const int c = b; in a class template, and we call store_init_value as usual. There, the value is IMPLICIT_CONV_EXPR(b) which is is_nondependent_static_init_expression but isn't is_nondependent_constant_expression (they only differ in STRICT). We call fold_non_dependent_expr, but that just returns the expression because it only instantiates is_nondependent_constant_expression expressions. Since we're not checking the initializer of a constexpr variable, we go on to call maybe_constant_init, whereupon we crash because it tries to evaluate all is_nondependent_static_init_expression expressions, which our value is, but it still contains a template code. I think the fix is to call fold_non_dependent_init instead of maybe_constant_init, and only call fold_non_dependent_expr on the "this is a constexpr variable" path so as to avoid instantiating twice in a row. Outside a template this should also avoid evaluating the value twice. gcc/cp/ChangeLog: PR c++/97975 * constexpr.c (fold_non_dependent_init): Add a tree parameter. Use it. * cp-tree.h (fold_non_dependent_init): Add a tree parameter with a default value. * typeck2.c (store_init_value): Call fold_non_dependent_expr only when checking the initializer for constexpr variables. Call fold_non_dependent_init instead of maybe_constant_init. gcc/testsuite/ChangeLog: PR c++/97975 * g++.dg/cpp1z/inline-var8.C: New test.
[Bug c++/97187] [11 Regression] ICE: tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97187 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/97993] [11 Regression] ICE tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834 since r11-423-gcda6396a1b6e6bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/97187] [11 Regression] ICE: tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97187 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:4192ffd74c69e3fb6d761becc8e5117c3de42052 commit r11-5677-g4192ffd74c69e3fb6d761becc8e5117c3de42052 Author: Marek Polacek Date: Mon Nov 30 14:53:24 2020 -0500 c++: Fix tsubst ICE with invalid code [PR97993, PR97187] I had a strong sense of deja vu when looking into this, and no wonder, since this is almost identical to c++/95728. Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list instead of open coding it. While the latter could return an error node wrapped in a TREE_LIST, the former can return a naked error node. That broke in tsubst_copy_and_build/NEW_EXPR, because we were accessing TREE_VALUE of an error node. gcc/cp/ChangeLog: PR c++/97187 PR c++/97993 * pt.c (tsubst_copy_and_build) : Return error_mark_node if init is erroneous. gcc/testsuite/ChangeLog: PR c++/97187 PR c++/97993 * g++.dg/eh/crash2.C: New test. * g++.dg/template/crash132.C: New test.
[Bug c++/97993] [11 Regression] ICE tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834 since r11-423-gcda6396a1b6e6bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:4192ffd74c69e3fb6d761becc8e5117c3de42052 commit r11-5677-g4192ffd74c69e3fb6d761becc8e5117c3de42052 Author: Marek Polacek Date: Mon Nov 30 14:53:24 2020 -0500 c++: Fix tsubst ICE with invalid code [PR97993, PR97187] I had a strong sense of deja vu when looking into this, and no wonder, since this is almost identical to c++/95728. Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list instead of open coding it. While the latter could return an error node wrapped in a TREE_LIST, the former can return a naked error node. That broke in tsubst_copy_and_build/NEW_EXPR, because we were accessing TREE_VALUE of an error node. gcc/cp/ChangeLog: PR c++/97187 PR c++/97993 * pt.c (tsubst_copy_and_build) : Return error_mark_node if init is erroneous. gcc/testsuite/ChangeLog: PR c++/97187 PR c++/97993 * g++.dg/eh/crash2.C: New test. * g++.dg/template/crash132.C: New test.
[Bug tree-optimization/98095] Optimize __builtin_unordered (...) || __builtin_is{less,greater}{,equal}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98095 --- Comment #1 from joseph at codesourcery dot com --- There's no __builtin_isequal because == and != don't raise exceptions for quiet NaNs anyway. (The lack of __builtin_iseqsig is bug 77928.)
[Bug rtl-optimization/97836] [11 Regression] wrong code at -O1 on x86_64-pc-linux-gnu by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836 --- Comment #6 from Jakub Jelinek --- So, can this be closed as fixed or do you want to do something further?
[Bug c++/98103] [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98103 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r10-5660-g22edf9431e4519c409ebf41c7589cccfb8c4b625
[Bug c++/98104] [11 regression] -Wplacement-new false positive (struture padding?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98104 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think this has been fixed with r11-5628-gb76f83e3859f738809d3aa8bd9dc14e10fc40e24 Might be useful to add the testcase into the testsuite though.
[Bug c++/98103] [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98103 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98105] New: constexpr and unnamed namespace yields relocation R_X86_64_PC32 against undefined symbol ... can not be used when making a shared object; recompile with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98105 Bug ID: 98105 Summary: constexpr and unnamed namespace yields relocation R_X86_64_PC32 against undefined symbol ... can not be used when making a shared object; recompile with -fPIC Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: peter_foelsche at mentor dot com Target Milestone: --- Created attachment 49665 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49665=edit g++-10 -std=c++11 2.cxx -shared -fPIC please compile with g++-10 -std=c++11 2.cxx -shared -fPIC This is g++: g++-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/98104] New: [11 regression] -Wplacement-new false positive (struture padding?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98104
Bug ID: 98104
Summary: [11 regression] -Wplacement-new false positive
(struture padding?)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
With gcc 11 (20201128), the following source (reduced from eigen 3.3.7)
gives a warning:
-- x.cc -
#include
class Base
{
public:
Base();
int* a;
char b;
};
class Der : public Base {};
void baz()
{
Der der;
::new (static_cast()) Base;
}
-
$ g++ -c x.cc
x.cc: In function ‘void baz()’:
x.cc:16:10: warning: placement new constructing an object of type ‘Base’ and
size ‘16’ in a region of type ‘Base’ and size ‘9’ [-Wplacement-new=]
16 | ::new (static_cast()) Base;
| ^~~~
x.cc:11:7: note: ‘Der::’ declared here
11 | class Der : public Base {};
| ^~~
This appears to be a false positive, possibly due to handling
of padding at the end of the structure.
[Bug target/97457] [10 Regression] SVE: wrong code since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97457 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Fixed on trunk and GCC 10 branch.
[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97904 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from rsandifo at gcc dot gnu.org --- Fixed on trunk and GCC 10 branch.
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 --- Comment #7 from dave.anglin at bell dot net --- Currently, we also have the following two additional fails: FAIL: libstdc++-prettyprinters/91997.cc print a FAIL: libstdc++-prettyprinters/91997.cc print a
[Bug rtl-optimization/98037] ICE in dse.c:find_shift_sequence for large non-integer modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98037 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed on trunk and GCC 10 branch.
[Bug target/97457] [10 Regression] SVE: wrong code since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97457 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:75a5af680a1788ba844902fd0681958da8e2a4ce commit r10-9112-g75a5af680a1788ba844902fd0681958da8e2a4ce Author: Richard Sandiford Date: Wed Dec 2 18:39:24 2020 + value-range: Give up on POLY_INT_CST ranges [PR97457] This PR shows another problem with calculating value ranges for POLY_INT_CSTs. We have: ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]> where the VQ coefficient is unsigned but is effectively acting as a negative number. We wrongly give the POLY_INT_CST the range: [9, INT_MAX] and things go downhill from there: later iterations of the unrolled epilogue are wrongly removed as dead. I guess this is the final nail in the coffin for doing VRP on POLY_INT_CSTs. For other similarly exotic testcases we could have overflow for any coefficient, not just those that could be treated as contextually negative. Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we couldn't handle warn_strict_overflow properly. At this stage we're just recording a range that might or might not lead to strict-overflow assumptions later. It still feels like we should be able to do something here, but for now removing the code seems safest. It's also telling that there are no testsuite failures on SVE from doing this. gcc/ PR tree-optimization/97457 * value-range.cc (irange::set): Don't decay POLY_INT_CST ranges to integer ranges. gcc/testsuite/ PR tree-optimization/97457 * gcc.dg/vect/pr97457.c: New test. (cherry picked from commit 54ef7701a9dec8c923a12d1983f8a051ba88a7b9)
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > Ah, I think the problem is that Python 2 has a 42-bit int 32-bit of course. But there's also something else going on. I have a patch.
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98072] [9/10 Regression] ICE in cp_parser_omp_var_list_no_open, at cp/parser.c:34843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98072 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |cp_parser_omp_var_list_no_o |cp_parser_omp_var_list_no_o |pen, at cp/parser.c:34843 |pen, at cp/parser.c:34843 Target Milestone|11.0|9.4 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk, needs to be backported to release branches where it regressed since the latest released minor versions.
[Bug ipa/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> Note the GIMPLE we expand from looks weird:
>
> struct GoodIterD.2094 operator+ (intD.9 D.2129, struct GoodIterD.2094 &
> restrict D.2130)
> {
>[local count: 1]:
> *_2(D) = operator- (_3(D), _4(D)); [return slot optimization] [tail call]
> return _2(D);
>
> somehow the inlined(?) thunk has some indirection exposed and the RSO
> looks misplaced.
How else we can express calls returning through hidden reference at GIMPLE?
I believe the above is effectively telling that the thunk should pass _2(D) as
the hidden return slot pointer.
If I use
struct S { S (); S (const S &); };
int baz (int);
S
foo ()
{
baz (baz (baz (baz (baz (0);
baz (baz (baz (baz (baz (1);
baz (baz (baz (baz (baz (2);
baz (baz (baz (baz (baz (3);
baz (baz (baz (baz (baz (4);
baz (baz (baz (baz (baz (5);
baz (baz (baz (baz (baz (6);
baz (baz (baz (baz (baz (7);
baz (baz (baz (baz (baz (8);
baz (baz (baz (baz (baz (9);
return S ();
}
S
bar ()
{
baz (baz (baz (baz (baz (0);
baz (baz (baz (baz (baz (1);
baz (baz (baz (baz (baz (2);
baz (baz (baz (baz (baz (3);
baz (baz (baz (baz (baz (4);
baz (baz (baz (baz (baz (5);
baz (baz (baz (baz (baz (6);
baz (baz (baz (baz (baz (7);
baz (baz (baz (baz (baz (8);
baz (baz (baz (baz (baz (9);
return S ();
}
instead such that it is at -O2 ipa-icf optimized and is not inlined back, then
that
struct S bar ()
{
[local count: 1073741824]:
*_2(D) = foo (); [return slot optimization] [tail call]
return _2(D);
}
appears in *.optimized dump, yet we apparently don't tail call optimize it even
when we should:
_Z3barv:
.LFB3:
.cfi_startproc
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
movq%rdi, %r12
call_Z3foov
movq%r12, %rax
popq%r12
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE3:
.size _Z3barv, .-_Z3barv
For -O0, perhaps IPA-ICF should be really disabled if !optimize no matter what
the user said, as we e.g. can't really expect any attempts on emitting the tail
calls in that case. But it wouldn't hurt to fix expansion so that it doesn't
ICE on it too.
[Bug c++/98103] [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98103 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-12-02 Keywords||ice-on-invalid-code Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Priority|P3 |P2 Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 --- Comment #1 from Marek Polacek --- ICE confirmed.
[Bug c++/98103] New: [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98103 Bug ID: 98103 Summary: [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Using testfile gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic17.C This changed between 20191215 and 20200105 : $ g++-11-20201129 -c constexpr-dynamic17.C -std=gnu++2a -fsanitize=vptr constexpr-dynamic17.C:20:13: in 'constexpr' expansion of '((D*)(& d))->D::D()' constexpr-dynamic17.C:12:35: in 'constexpr' expansion of '((D*)this)->D::.B::B((&(&((D*)this)->D::)->A::), (&((D*)this)->D::))' constexpr-dynamic17.C:20:13: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003 20 | constexpr D d; | ^ 0x64d1b5 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.c:9984 0x6ebbe3 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:3445 0x6ebbe3 cxx_eval_dynamic_cast_fn ../../gcc/cp/constexpr.c:2003 0x6ebbe3 cxx_eval_call_expression ../../gcc/cp/constexpr.c:2421 0x6eec61 cxx_eval_constant_expression ../../gcc/cp/constexpr.c:5866 0x6ed3de cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6358 0x6ed3de cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6358 0x6eeb2a cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6305 0x6ed39a cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6176 0x6eebda cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6044 0x6ee1ee cxx_eval_statement_list ../../gcc/cp/constexpr.c:5436 0x6ee1ee cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6502 0x6eea4e cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6537 0x6ee1ee cxx_eval_statement_list ../../gcc/cp/constexpr.c:5436 0x6ee1ee cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6502 0x6eb576 cxx_eval_call_expression ../../gcc/cp/constexpr.c:2687 0x6eec61 cxx_eval_constant_expression ../../gcc/cp/constexpr.c:5866 0x6ed39a cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6176 0x6eebda cxx_eval_constant_expression ../../gcc/cp/constexpr.c:6044 0x6ee1ee cxx_eval_statement_list ../../gcc/cp/constexpr.c:5436
[Bug c++/98101] ICE in mark_reachable_handlers, at tree-eh.c:4033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98101 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-12-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/98102] New: [9/10/11 Regression] ICE tree check: expected block, have function_decl in change_scope, at final.c:1480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98102
Bug ID: 98102
Summary: [9/10/11 Regression] ICE tree check: expected block,
have function_decl in change_scope, at final.c:1480
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
This combination of options affects several files
from gcc/testsuite at -O2+, and goes back to r7 :
$ g++-6 -c pr61654.C -g -O2 -fvtable-verify=std -fopenacc
$ g++-11-20201129 -c pr61654.C -g -O1 -fvtable-verify=std -fopenacc
$
$ g++-11-20201129 -c pr61654.C -g -O2 -fvtable-verify=std -fopenacc
during RTL pass: final
pr61654.C: In function '(static initializers for pr61654.C)':
pr61654.C:17:12: internal compiler error: tree check: expected block, have
function_decl in change_scope, at final.c:1480
17 | return a ('\0');
| ~~^~
0x64cac4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9810
0xbc4b19 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3331
0xbc4b19 change_scope
../../gcc/final.c:1480
0xbce0c0 reemit_insn_block_notes
../../gcc/final.c:1581
0xbce0c0 final_start_function_1
../../gcc/final.c:1784
0xbce609 rest_of_handle_final
../../gcc/final.c:4675
0xbce609 execute
../../gcc/final.c:4754
[Bug c++/98101] New: ICE in mark_reachable_handlers, at tree-eh.c:4033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98101
Bug ID: 98101
Summary: ICE in mark_reachable_handlers, at tree-eh.c:4033
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5, only at -O0 :
(used options affect also several testsuite files)
(under the hood maybe related to pr59507/pr88640)
$ cat z1.cc
struct A { virtual ~A(); };
struct B { A a[1]; } b;
$ g++-11-20201129 -c z1.cc -fnon-call-exceptions -fvtable-verify=std -O2
$
$ g++-11-20201129 -c z1.cc -fnon-call-exceptions -fvtable-verify=std
during GIMPLE pass: ehcleanup
z1.cc: In destructor 'B::~B()':
z1.cc:2:8: internal compiler error: in mark_reachable_handlers, at
tree-eh.c:4033
2 | struct B { A a[1]; } b;
|^
0xcd644d mark_reachable_handlers
../../gcc/tree-eh.c:4033
0xcd6482 remove_unreachable_handlers
../../gcc/tree-eh.c:4080
0xcda601 execute_cleanup_eh_1
../../gcc/tree-eh.c:4783
0xcda601 execute
../../gcc/tree-eh.c:4850
---
z1.cc: In destructor 'B::~B()':
z1.cc:2:8: error: statement marked for throw in middle of block
2 | struct B { A a[1]; } b;
|^
# VUSE <.MEM_7>
_13 = _12->_vptr.A;
during GIMPLE pass: vtable-verify
z1.cc:2:8: internal compiler error: verify_gimple failed
0xfcaaf4 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5467
0xe867ee execute_function_todo
../../gcc/passes.c:2039
0xe87692 execute_todo
../../gcc/passes.c:2093
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #10 from Bhavana Kilambi --- Created attachment 49664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49664=edit Removes the push_back() statement
[Bug c/98100] New: ICE in expand_debug_locations, at cfgexpand.c:5610
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98100
Bug ID: 98100
Summary: ICE in expand_debug_locations, at cfgexpand.c:5610
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r7 :
$ cat z1.c
__attribute__((target_clones("default","sse2")))
void f ()
{
__attribute__((__vector_size__(4 * sizeof(float int b = {};
}
$ gcc-11-20201129 -c z1.c -O2 -mgeneral-regs-only -fvar-tracking-assignments
during RTL pass: expand
z1.c: In function 'f.sse2.0':
z1.c:2:6: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5610
2 | void f ()
| ^
0x759573 expand_debug_locations
../../gcc/cfgexpand.c:5606
0x759573 execute
../../gcc/cfgexpand.c:6727
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 --- Comment #9 from Bhavana Kilambi --- Hi, The problem seems to be with the code in add_line_counts() function in gcov.c. Specifically with this statement - line->blocks.push_back (block); This line is present inside the line!= NULL condition while in gcc7 it is within the flag_all_blocks condition. Since all the lines in the function satisfy the condition of line != NULL, this push_back() function gets executed almost everytime. Also, looking at the way the tool is built, initially the relevant data structures would have already been created and in place in the process_file() and other functions while the generate_results() function (which in turn calls add_line_counts() function) is supposed to technically only read/traverse the appropriate data structures and update the coverage information. After removing the above line, the coverage for the testcase in this bug is 100% as required with the -a and -m flags. Also, tested the testcase mentioned in bug #79891. It also shows the expected coverage output. I have attached the patch in this bug. Output after the patch for the testcase specified in this bug : gcov main.cpp -a File 'hello.h' Lines executed:0.00% of 2 Creating 'hello.h.gcov' File 'main.cpp' Lines executed:100.00% of 4 Creating 'main.cpp.gcov' Lines executed:66.67% of 6
[Bug c/98099] New: ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Bug ID: 98099
Summary: ICE in gen_lowpart_common, at emit-rtl.c:1554
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r6 :
$ cat z1.c
struct S { _Decimal128 a; };
_Decimal128 f (struct S x)
{
return x.a;
}
$ gcc-11-20201129 -c z1.c -m32 -fsso-struct=big-endian
during RTL pass: expand
z1.c: In function 'f':
z1.c:5:11: internal compiler error: Segmentation fault
5 | return x.a;
| ~^~
0xb49eaf crash_signal
../../gcc/toplev.c:330
0x825a2f gen_lowpart_common(machine_mode, rtx_def*)
../../gcc/emit-rtl.c:1554
0xafa9ec gen_lowpart_general(machine_mode, rtx_def*)
../../gcc/rtlhooks.c:48
0x83ef31 extract_bit_field_1
../../gcc/expmed.c:1826
0x83f7ff extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
../../gcc/expmed.c:2119
0x84e8ca expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:3
0x859e43 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5859
0x85b206 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5595
0x750c10 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3901
0x750c10 expand_gimple_stmt
../../gcc/cfgexpand.c:3999
0x755e07 expand_gimple_basic_block
../../gcc/cfgexpand.c:6040
0x758476 execute
../../gcc/cfgexpand.c:6724
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- None of the above test cases gives an ICE on x86_64-pc-linux-gnu, even when gcc-11 is configured with --enable-checking=yes.
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 --- Comment #5 from Jonathan Wakely --- Ah, I think the problem is that Python 2 has a 42-bit int and so casting a big endian pointer to int loses half the bits.
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed|2017-12-17 00:00:00 |2020-12-02
--- Comment #4 from Jonathan Wakely ---
The exceptions come from this line:
func = gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'
This casts a function pointer to intptr_t and then tries to find the gdb.Block
corresponding to that address.
The GDB docs say that gdb.block_for_pc will return None, but it seems to throw
instead.
The same thing happens on powerpc64 linux (but not powerpc64le).
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 Jonathan Wakely changed: What|Removed |Added CC||g.bonacci at libero dot it --- Comment #11 from Jonathan Wakely --- *** Bug 98098 has been marked as a duplicate of this bug. ***
[Bug libstdc++/98098] std::call_once throws std::system_error in statically linked executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98098 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- See Bug 58909 which is exactly the same issue. Comment 2 has the solution. This is no longer a problem with the GCC development trunk because std::call_once doesn't use pthread_once. *** This bug has been marked as a duplicate of bug 58909 ***
