[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #20 from Martin Liška --- All right Matt, for now I would really recommend updating to gcc-11. I think it should help.
[Bug rtl-optimization/63315] -fcompare-debug bootstrap issue in libjava (fixup_abnormal_edges related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63315 --- Comment #3 from Andrew Pinski --- So I looked and I suspect in the end was the same issue as PR 69838. I have no way to prove this though.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #17 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #16)
> typedef int v4si __attribute__ ((vector_size(16)));
>
> v4si f(v4si a, v4si b) {
> v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
> v4si b1 = __builtin_shufflevector (b, a, 2, 3 ,1 ,0);
> return a1 * b1;
> }
>
> gcc generate
>
> f:
> vpshufd xmm1, xmm1, 30
> vpshufd xmm0, xmm0, 30
> vpmulld xmm0, xmm0, xmm1
> ret
>
> llvm generate
>
> f: # @f
> vpmulld xmm0, xmm1, xmm0
> vpshufd xmm0, xmm0, 30 # xmm0 = xmm0[2,3,1,0]
> ret
For the above, this is safe for -ftrapping-math as all elements are still used.
It is when elements that are not used it might not be safe ...
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #16 from Hongtao.liu ---
typedef int v4si __attribute__ ((vector_size(16)));
v4si f(v4si a, v4si b) {
v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
v4si b1 = __builtin_shufflevector (b, a, 2, 3 ,1 ,0);
return a1 * b1;
}
gcc generate
f:
vpshufd xmm1, xmm1, 30
vpshufd xmm0, xmm0, 30
vpmulld xmm0, xmm0, xmm1
ret
llvm generate
f: # @f
vpmulld xmm0, xmm1, xmm0
vpshufd xmm0, xmm0, 30 # xmm0 = xmm0[2,3,1,0]
ret
[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 --- Comment #6 from Jiu Fu Guo --- (In reply to Richard Earnshaw from comment #5) > (In reply to Jiu Fu Guo from comment #4) > > > I did not find arm big-endian yet, I'm trying to reproduce this issue on > > other targets... > > For testing purposes you should be able to build a standard arm-eabi config > and then compile the testcase with -mbig-endian. Thanks a lot! config with --target=arm-none-eabi, I could reproduce the ice for -mcpu=cortex-a9.
[Bug rtl-optimization/64525] Duplicate instructions in both paths in conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64525 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- It is not broken. The C++ FE knows std::construct_at is special and allows placement new in there as implementation detail in constant expressions. See uses of is_std_construct_at in gcc/cp/constexpr.c.
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #19 from Andrew Pinski --- Can't reproduce the original issue with upstream GCC releases so this is a bug to ubuntu only.
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056 Andrew Pinski changed: What|Removed |Added Known to work||4.8.0 --- Comment #7 from Andrew Pinski --- 4.7: ;;0-->11 simple_return :athlon-vector,athlon-ieu,athlon-ieu ;;0--> 5 prefetch(`x',0,0x3) :nothing 4.8.0: ;;0--> 5prefetch(`x',0,0x3) :nothing ;;0--> 10simple_return :athlon-vector,athlon-ieu,athlon-ieu
[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #19 from Martin Liška --- (In reply to Andrew Pinski from comment #18) > I wonder if this is fixed for GCC 10 by the patch which fixes PR 88220. This ICE is about variables for those we are unable loading a constructor.
[Bug target/101796] Miss optimization to optimized (vashl op0, (op1: const_duplicate_vector)) to (ashl op0 op1_inner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101796
--- Comment #4 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #3)
> Combine is able to do the combine but it fails as it does not match:
> Trying 10, 9 -> 14:
>10: r92:HI=0x3
> 9: r91:V32HI=vec_duplicate(r92:HI)
> REG_DEAD r92:HI
> REG_EQUAL const_vector
>14: r88:V32HI=r96:V8DI#0 0>>r91:V32HI
> REG_DEAD r96:V8DI
> REG_DEAD r91:V32HI
> Failed to match this instruction:
> (set (reg:V32HI 88)
> (lshiftrt:V32HI (subreg:V32HI (reg:V8DI 96) 0)
> (const_vector:V32HI [
> (const_int 3 [0x3]) repeated x32
> ])))
>
> This instruction does not have alt for the dup/const_vect case I think:
> (define_insn "_v"
> [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
> (any_lshift:VI2_AVX512VL
> (match_operand:VI2_AVX512VL 1 "register_operand" "v")
> (match_operand:VI2_AVX512VL 2 "nonimmediate_operand" "vm")))]
> "TARGET_AVX512BW"
> "vpv\t{%2, %1, %0|%0,
> %1, %2}"
> [(set_attr "type" "sseishft")
>(set_attr "prefix" "maybe_evex")
>(set_attr "mode" "")])
>
> Note I don't think simplify-rtx will change const_vector to just 3 though.
Yes, it's rejected at
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576837.html
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #19 from Andrew Pinski --- (In reply to Hongtao.liu from comment #18) > For vector integers it should be ok? > For vector floating point we can add condition > flag_unsafe_math_optimizations || !flag_trapping_math for the optimization. I think only flag_trapping_math needed really.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 --- Comment #2 from Martin Liška --- Started with r12-3136-g3673dcf6d6baeb67.
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #14 from Martin Liška ---
Even simpler test-case:
#pragma GCC target "avx"
typedef float __m256 __attribute__((__vector_size__(32)));
__m256 _mm256_blendv_ps___Y, _mm256_blendv_ps___M, _mm256_mul_ps___A,
_mm256_mul_ps___B, IfThenElse___trans_tmp_9;
struct Raw256 {
using type = __m256;
};
struct Vec256 {
using Raw = Raw256::type;
Raw raw;
} UndoXYBInPlace_linear_g;
Vec256 IfThenElse(Vec256 no) {
IfThenElse___trans_tmp_9 = __builtin_ia32_blendvps256(
no.raw, _mm256_blendv_ps___Y, _mm256_blendv_ps___M);
return {IfThenElse___trans_tmp_9};
}
Vec256 operator*(Vec256, Vec256) {
__m256 __trans_tmp_11 = _mm256_mul_ps___A * _mm256_mul_ps___B;
return {__trans_tmp_11};
}
struct TF_SRGB {
template void EncodedFromDisplay(D, V x) {
Vec256 __trans_tmp_12, linear = x * __trans_tmp_12;
IfThenElse(linear);
}
};
#pragma GCC target "avx512vl"
void UndoXYBInPlace_d() {
TF_SRGB().EncodedFromDisplay(UndoXYBInPlace_d, UndoXYBInPlace_linear_g);
}
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #13 from Martin Liška ---
There's a reduced test-case:
#pragma GCC target "avx"
typedef float __m256 __attribute__((__vector_size__(32)));
__m256 _mm256_blendv_ps___Y, _mm256_blendv_ps___M, _mm256_mul_ps___A,
_mm256_mul_ps___B, IfThenElse___trans_tmp_9;
struct Raw256 {
using type = __m256;
};
struct Vec256 {
using Raw = Raw256::type;
Raw raw;
} UndoXYBInPlace_linear_g;
Vec256 IfThenElse(Vec256 no) {
IfThenElse___trans_tmp_9 = __builtin_ia32_blendvps256(
no.raw, _mm256_blendv_ps___Y, _mm256_blendv_ps___M);
return {IfThenElse___trans_tmp_9};
}
Vec256 operator*(Vec256, Vec256) {
__m256 __trans_tmp_11 = _mm256_mul_ps___A * _mm256_mul_ps___B;
return {__trans_tmp_11};
}
struct TF_SRGB {
template void EncodedFromDisplay(D, V x) {
Vec256 __trans_tmp_12, linear = x * __trans_tmp_12;
IfThenElse(linear);
}
};
#pragma GCC target
\
"avx,avx2,bmi,bmi2,fma,f16c,avx512f,avx512vl,avx512dq,avx512bw"
void UndoXYBInPlace_d() {
TF_SRGB().EncodedFromDisplay(UndoXYBInPlace_d, UndoXYBInPlace_linear_g);
}
[Bug tree-optimization/102091] some interesting looking code in gimple_could_trap_p_1 in gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102091 --- Comment #2 from Andreas Schwab --- It helps to enable blink-matching-paren.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 --- Comment #7 from Andrew Pinski --- *** Bug 43056 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Andrew Pinski --- Dup of bug 55153. *** This bug has been marked as a duplicate of bug 55153 ***
[Bug ipa/102081] [12 regression] ICE building compiler starting with r12-3159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102081 Richard Biener changed: What|Removed |Added Version|9.4.1 |12.0 Target Milestone|--- |12.0 --- Comment #4 from Richard Biener --- part of this might be already fixed
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Summary|ICE on valid code at -O3 on |[12 Regression] ICE on |x86_64-linux-gnu: in|valid code at -O3 on |determine_exit_conditions, |x86_64-linux-gnu: in |at |determine_exit_conditions, |tree-ssa-loop-manip.c:1049 |at ||tree-ssa-loop-manip.c:1049 Target Milestone|--- |12.0 Version|unknown |12.0 --- Comment #1 from Richard Biener --- This looks similar to PR102072
[Bug sanitizer/102085] libsanitizer/asan/asan_errors.cpp:387: declaration and definition do not match ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102085 Martin Liška changed: What|Removed |Added Resolution|--- |MOVED URL||https://bugs.llvm.org/show_ ||bug.cgi?id=51641 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Liška --- Yes, it should be fixed in the upstream first.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|[12 Regression] ICE on |[12 Regression] ICE on |valid code at -O3 on|valid code at -O3 on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |determine_exit_conditions, |determine_exit_conditions, |at |at |tree-ssa-loop-manip.c:1049 |tree-ssa-loop-manip.c:1049 ||since ||r12-3136-g3673dcf6d6baeb67 Last reconfirmed||2021-08-27 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/80371] std::is_integral and std::is_floating_point fail with vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80371 --- Comment #1 from Andrew Pinski --- GCC, ICC and clang all cause the assert to happen.
[Bug tree-optimization/102091] New: some interesting looking code in gimple_could_trap_p_1 in gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102091 Bug ID: 102091 Summary: some interesting looking code in gimple_could_trap_p_1 in gimple.c Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The code looks like return (operation_could_trap_p (op, FLOAT_TYPE_P (t), (INTEGRAL_TYPE_P (t) && TYPE_OVERFLOW_TRAPS (t)), div)); the result of the function call operation_could_trap_p is not used at all. If I understand this correctly, it is testing if div is non-null only. So it is only returning true always for gimple binary cases. This code has been wrong since the merge of the tuples branch.
[Bug tree-optimization/45178] CDDCE doesn't eliminate conditional code in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45178 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:41439e1f6d2da1e86538c726f0603cffd5dd098e commit r12-3182-g41439e1f6d2da1e86538c726f0603cffd5dd098e Author: Richard Biener Date: Fri Aug 27 09:47:49 2021 +0200 tree-optimization/45178 - DCE of dead control flow in infinite loop This fixes DCE to be able to elide dead control flow in an infinite loop without an exit edge. This special situation is handled well by the code finding an edge to preserve since there's no chance it will find the exit edge and make the loop finite. 2021-08-27 Richard Biener PR tree-optimization/45178 * tree-ssa-dce.c (find_obviously_necessary_stmts): For infinite loops without exit do not mark control dependent edges of the latch necessary. * gcc.dg/tree-ssa/ssa-dce-3.c: Adjust testcase.
[Bug tree-optimization/45178] CDDCE doesn't eliminate conditional code in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45178 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/102091] some interesting looking code in gimple_could_trap_p_1 in gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102091 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- I cannot read tonight, the parentheses were correct.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #18 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Hongtao.liu from comment #16)
> > typedef int v4si __attribute__ ((vector_size(16)));
> >
> > v4si f(v4si a, v4si b) {
> > v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
> > v4si b1 = __builtin_shufflevector (b, a, 2, 3 ,1 ,0);
> > return a1 * b1;
> > }
> >
> > gcc generate
> >
> > f:
> > vpshufd xmm1, xmm1, 30
> > vpshufd xmm0, xmm0, 30
> > vpmulld xmm0, xmm0, xmm1
> > ret
> >
> > llvm generate
> >
> > f: # @f
> > vpmulld xmm0, xmm1, xmm0
> > vpshufd xmm0, xmm0, 30 # xmm0 = xmm0[2,3,1,0]
> > ret
>
> For the above, this is safe for -ftrapping-math as all elements are still
> used. It is when elements that are not used it might not be safe ...
For vector integers it should be ok?
For vector floating point we can add condition flag_unsafe_math_optimizations
|| !flag_trapping_math for the optimization.
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #12 from Richard Biener --- (In reply to Hongtao.liu from comment #11) > Created attachment 51363 [details] > Proposed patch > > I'm testing this patch. This looks sensible - Richard, any opinion?
[Bug target/101796] Miss optimization to optimized (vashl op0, (op1: const_duplicate_vector)) to (ashl op0 op1_inner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101796
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-27
Severity|normal |enhancement
Component|rtl-optimization|target
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Combine is able to do the combine but it fails as it does not match:
Trying 10, 9 -> 14:
10: r92:HI=0x3
9: r91:V32HI=vec_duplicate(r92:HI)
REG_DEAD r92:HI
REG_EQUAL const_vector
14: r88:V32HI=r96:V8DI#0 0>>r91:V32HI
REG_DEAD r96:V8DI
REG_DEAD r91:V32HI
Failed to match this instruction:
(set (reg:V32HI 88)
(lshiftrt:V32HI (subreg:V32HI (reg:V8DI 96) 0)
(const_vector:V32HI [
(const_int 3 [0x3]) repeated x32
])))
This instruction does not have alt for the dup/const_vect case I think:
(define_insn "_v"
[(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
(any_lshift:VI2_AVX512VL
(match_operand:VI2_AVX512VL 1 "register_operand" "v")
(match_operand:VI2_AVX512VL 2 "nonimmediate_operand" "vm")))]
"TARGET_AVX512BW"
"vpv\t{%2, %1, %0|%0,
%1, %2}"
[(set_attr "type" "sseishft")
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
Note I don't think simplify-rtx will change const_vector to just 3 though.
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #18 from Andrew Pinski --- (In reply to Kristian Spangsege from comment #13) > I've now run into this problem too, and it seems to be general, not just > limited to Ubuntu. > > There is the code that I compile: So this comment #13 is definitely PR 60555 and is fixed in 6.5, 7.4, 8.3 and 9+. Still looking into the original issue to see if it can be reproduce and such.
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 --- Comment #7 from Jakub Jelinek --- http://eel.is/c++draft/new.syn doesn't say placement new should be constexpr.
[Bug other/101711] Error when gcc cross compile libvtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97465 --- Comment #9 from Andrew Pinski --- Similar to PR 97465.
[Bug other/97465] cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97465 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug other/97465] cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97465 --- Comment #4 from Andrew Pinski --- I will try to find a simple way to reproduce this tomorrow.
[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
--- Comment #7 from Jiu Fu Guo ---
For this case: it was generated as:
l_12 = l_25 + 1;
if (l_12 > n_13(D))
Here: cmp is ">", bound is "n_13", and "iv(base=l_xx, step=1)".
This hits the assert in determine_exit_conditions.
For members of tree_niter_desc, the comments(as below) align with the asserts
in determine_exit_conditions.
/* The simplified shape of the exit condition. The loop exits if
CONTROL CMP BOUND is false, where CMP is one of NE_EXPR,
LT_EXPR, or GT_EXPR, and step of CONTROL is positive if CMP is
LE_EXPR and negative if CMP is GE_EXPR. This information is used
by loop unrolling. */
affine_iv control;
tree bound;
enum tree_code cmp;
Current code the "control, bound and cmp" are set in number_of_iterations_lt:
if (integer_nonzerop (iv0->step))
{
niter->control = *iv0;
niter->cmp = LT_EXPR;
niter->bound = iv1->base;
}
else
{
niter->control = *iv1;
niter->cmp = GT_EXPR;
niter->bound = iv0->base;
}
This code may need to refine for the case "step until wrap condition".
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 --- Comment #5 from Jonathan Wakely --- Since language linkage of an entity without linkage makes no sense, it wouldn't make sense to even allow specifying language linkage in an unnamed namespace if it did nothing.
[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #21 from Matt Godbolt --- Thanks, I'd love to upgrade but in this instance I'm stuck on GCC 9.x until the rest of my company can move to it. Nothing annoys me more than having to say that, but ... at least we know what it is and that it's fixed in the future :) This will help me make a case to upgrade!
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 H.J. Lu changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from H.J. Lu --- *** Bug 102072 has been marked as a duplicate of this bug. ***
[Bug c++/102097] New: Error in selecting more specialized function in case of ambiguity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102097
Bug ID: 102097
Summary: Error in selecting more specialized function in case
of ambiguity
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
In this program
```
void fun(auto&){}
void fun(auto&&){}
int main() { void(*ptr)(int&) = }
```
GCC reports ambiguity of function selection. Clang reports the same error as
well. But the community of stack-overflow believes
(https://stackoverflow.com/questions/68949303/which-is-the-most-specialized-function-template-in-the-context-of-taking-the-add)
that it is not correct compiler behavior and a more specialized function
`fun(auto&)` must be selected.
[Bug c++/51923] cxa_atexit test changed outcome with gld 2.22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51923 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Target Milestone|--- |10.0 --- Comment #1 from Andrew Pinski --- Since r10-340, GCC does not support anything before solaris 11 and solaris 11.4 includes __cxa_atexit (and is the only solaris 11 which GCC supports now) so we can close this as won't fix.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 H.J. Lu changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #4 from H.J. Lu --- Reopen. This test isn't specific to armeb.
[Bug c++/53868] Temporary for indirect binding is not destroyed when destructor from initializer temp throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53868 Andrew Pinski changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu | Host|powerpc64-unknown-linux-gnu | See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66139, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52320 --- Comment #2 from Andrew Pinski --- clang and GCC both produce the same result while ICC produces the bug reporter expected result. This is also most likely related to PR 66139 and PR 52320.
[Bug d/102093] New: d: Add --enable-d-flags= configure option to libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102093 Bug ID: 102093 Summary: d: Add --enable-d-flags= configure option to libphobos Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- To do the same action as --enable-cxx-flags=
[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 102087 ***
[Bug d/102094] New: d: ICE in gimple_register_canonical_type_1, at lto/lto-common.c:430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102094
Bug ID: 102094
Summary: d: ICE in gimple_register_canonical_type_1, at
lto/lto-common.c:430
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gcc dot gnu.org
Target Milestone: ---
Looks like there's a TYPE_CXX_ODR_P mismatch between D closure frames and user
defined types.
---
extern(C) int printf(char* s, ...);
struct Wow
{
int a;
}
void formatValue()
{
Wow x;
void nested()
{
printf(cast(char*)0, x);
}
}
[Bug c/102096] New: Gcc unnecessarily initializes indeterminate variables passed across function boundaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102096
Bug ID: 102096
Summary: Gcc unnecessarily initializes indeterminate variables
passed across function boundaries
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Compared to clang where:
long ret_unspec(void){ auto long rv; return rv; }
void take6(long,long,long,long,long,long);
void call_take6(void)
{
//6 unnecessary XORs on GCC
auto long id0; //indeterminate
auto long id1; //indeterminate
auto long id2; //indeterminate
auto long id3; //indeterminate
auto long id4; //indeterminate
auto long id5; //indeterminate
take6(id0,id1,id2,id3,id4,id5);
}
yields (x86_64):
ret_unspec:# @ret_unspec2
retq
call_take6: # @call_take6
jmp take6
(1+5 bytes), GCC compiles the above to
ret_unspec2:
xorl%eax, %eax
ret
call_take6:
xorl%r9d, %r9d
xorl%r8d, %r8d
xorl%ecx, %ecx
xorl%edx, %edx
xorl%esi, %esi
xorl%edi, %edi
jmp take6
(3+19 bytes), unnecessarily 0-initializing the indeterminate
return-value/arguments.
Type casting the called function can often be hackishly used to get the same
assembly but doing so is technically UB and not as generic as supporting the
passing of unspecified arguments/return values, which can be used to omit
argument register initializations not just for arguments at the end of an
argument pack but also in the middle.
TL;DR: Allowing to passing/return indeterminate variables without generating
initializing code for them would be nice. Clang already does it.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #6 from Jiu Fu Guo ---
Drafting patch to calculate three items: control, bound and cmp.
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 7af92d1c893..c6e4b24fd83 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -1482,7 +1482,7 @@ number_of_iterations_until_wrap (class loop *, tree type,
affine_iv *iv0,
affine_iv *iv1, class tree_niter_desc *niter)
{
tree niter_type = unsigned_type_for (type);
- tree step, num, assumptions, may_be_zero;
+ tree step, num, assumptions, may_be_zero, span;
wide_int high, low, max, min;
may_be_zero = fold_build2 (LE_EXPR, boolean_type_node, iv1->base,
iv0->base);
@@ -1513,6 +1513,8 @@ number_of_iterations_until_wrap (class loop *, tree type,
affine_iv *iv0,
low = wi::to_wide (iv0->base);
else
low = min;
+
+ niter->control = *iv1;
}
/* {base, -C} < n. */
else if (tree_int_cst_sign_bit (iv0->step) && integer_zerop (iv1->step))
@@ -1533,6 +1535,8 @@ number_of_iterations_until_wrap (class loop *, tree type,
affine_iv *iv0,
high = wi::to_wide (iv1->base);
else
high = max;
+
+ niter->control = *iv0;
}
else
return false;
@@ -1556,6 +1560,14 @@ number_of_iterations_until_wrap (class loop *, tree
type, affine_iv *iv0,
niter->assumptions, assumptions);
niter->control.no_overflow = false;
+ tree niter_m1 = fold_build2 (MINUS_EXPR, niter_type, niter->niter,
+ build_int_cst (niter_type, 1));
+ span = fold_build2 (MULT_EXPR, niter_type, niter_m1,
+ fold_convert (niter_type, niter->control.step));
+ niter->bound = fold_build2 (PLUS_EXPR, niter_type, span,
+ fold_convert (niter_type, niter->control.base));
+ niter->bound = fold_convert (type, niter->bound);
+ niter->cmp = NE_EXPR;
return true;
}
While this code may generate complicated niter->bound if the step is not +-1.
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 --- Comment #6 from Jonathan Wakely --- Actually I suppose that's not true, since in theory C language linkage gives the function a different type, orthogonal from internal/external/no linkage, but nobody implements that.
[Bug c++/102092] New: [C++2b] Passing argument to auto template parameter modifies the value of argument inside function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102092 Bug ID: 102092 Summary: [C++2b] Passing argument to auto template parameter modifies the value of argument inside function Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andrei.popa105 at yahoo dot com Target Milestone: --- Created attachment 51364 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51364=edit In this cpp file, I have created a structure that models a polynomial function. Outside of this structure I have created 2 template functions for adding and multiplying 2 polynomials. Hi, For this example, I used gcc trunk (gcc version 12.0.0 experimental) on x86-64 platform. For compiling, I used the following command: - g++ auto_template_paramater_bug.cpp -O3 -std=c++2b -Wall -Wextra -Wpedantic -o bug_report In auto_template_paramater_bug.cpp file, I have created a structure that models a polynomial function. Outside of this structure I have created 2 templated functions using auto template parameter for adding and multiplying 2 polynomials, called add and mult. In main function I multiplied polynomials p1 and p2, polynomials p3 and p4, and after that I multiplied these 2 results. All works fine until I made an addition of polynomials p1 and p5. As you can see from these example, if I pass p5 to function add through auto template parameter, the value of p5 is different in function add that it is in main function (look at p5 and p5_passed_to_add_function in the output of the program). I have 2 mentions: 1) If you comment out all those multiplies for making only the addition, the values are passed correctly through function add. 2) As you can see, the type for values of coefficients for those polynomial functions are double through Type macro. If you change Type to be another type like an integral or float or long double, the code works as expected. It seems that it is a problem with double type. For another information, I am here to answer. Thank you, Andrei
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 Jiu Fu Guo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jiu Fu Guo --- Yes, it is a duplicate of PR102072. *** This bug has been marked as a duplicate of bug 102072 ***
[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 Jiu Fu Guo changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #8 from Jiu Fu Guo --- *** Bug 102087 has been marked as a duplicate of this bug. ***
[Bug fortran/58334] preprocessor behavior diffs under line continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- Some useful links copied from the duplicated report: https://gcc.gnu.org/ml/gcc/2014-11/msg00357.html See also the comments in https://gcc.gnu.org/ml/gcc/2014-12/msg3.html and follow-ups.
[Bug sanitizer/102095] New: Returned reference to temporary not caught by -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102095
Bug ID: 102095
Summary: Returned reference to temporary not caught by
-fsanitize=undefined
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The following code results in undefined behaviour (I believe), but it is not
caught by -fsanitize=undefined:
#include
#include
#include
template
std::function constant(const T& c) {
return [c]() noexcept -> const T&{ return c; };
}
template
std::function()> zip_good(const std::function& f) {
return [f]() { return std::tuple{f()}; };
}
template
std::function()> zip_bad(const std::function& f) {
return [f]() { return std::tuple{f()}; }; // <- UNDEFINED if T is const ref
}
int main() {
std::cout << std::get<0>(zip_good(constant(1.0))()) << std::endl;
std::cout << std::get<0>(zip_bad(constant(1.0))()) << std::endl;
}
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 --- Comment #7 from Jiu Fu Guo --- If step is +-1, or if the 'iv base' is constant, the 'bound' would be calculated as const. Otherwise, the 'bound' maybe something like: "(max - base) / step * step + base". For this case, then runtime cost may need to calculate 'bound'. I'm wondering if it is beneficial to support this kind of case.
[Bug target/102068] [AIX] field alignment ignores packed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102068 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Edelsohn --- Fixed partially.
[Bug other/102099] New: Diagnostics do not consider the user's locale when printing source lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102099 Bug ID: 102099 Summary: Diagnostics do not consider the user's locale when printing source lines Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: lhyatt at gcc dot gnu.org Target Milestone: --- If the user has a non-UTF-8 locale configured, they will currently still receive UTF-8 output from GCC's stderr under some conditions: -If a filename for which diagnostics are issued contains extended characters -If a source line for which diagnostics are issued contains extended characters. When a source line contains identifier names with extended characters, the C/C++ front ends take care to convert them to the user's locale, by always passing them to identifier_to_locale() before output. However, this only affects the diagnostics messages generated by the front end, and does not affect the source line itself which is printed separately. Example: $ cat á.cpp int á = 0; int á = 1; #in UTF-8 locale, looks fine $ gcc -c á.cpp á.cpp:2:5: error: redefinition of ‘int á’ 2 | int á = 1; | ^ á.cpp:1:5: note: ‘int á’ previously defined here 1 | int á = 0; | ^ #in C locale, only partially converted to UCNs $ LC_ALL=C gcc -c á.cpp á.cpp:2:5: error: redefinition of 'int \U00e1' 2 | int á = 1; | ^ á.cpp:1:5: note: 'int \U00e1' previously defined here 1 | int á = 0; | ^ The attached patch arranges for the output to be rather: #corrected by this patch $ LC_ALL=C gcc -c á.cpp \U00e1.cpp:2:5: error: redefinition of 'int \U00e1' 2 | int \U00e1 = 1; | ^ \U00e1.cpp:1:5: note: 'int \U00e1' previously defined here 1 | int \U00e1 = 0; | ^ In the above example I showed C locale, where the extended characters need to be escaped, but the patch would also handle e.g. latin1 locale, where it would output as expected, using iconv to convert to the output charset. The patch is pretty complete, and bootstraps all languages with no regression. However there are a couple potential issues with it that may need to be discussed before it's ready to be used, so I have held off submitting to gcc-patches for now. The two main points of concern are: 1. Diagnostics recently acquired a lot of infrastructure to know the correct display width of extended characters, so that things like carets and label lines show up at the correct place. This infrastructure however is not currently able to handle locale dependence of the display width. Changing that is rather complicated, because determining that the display width of "á" is actually 10 columns instead of 1 (in case of UCN escape), requires attempting to convert the character to the user's locale (perhaps with iconv), and determining if it can be displayed or requires an escape. So the process of determining the display width becomes an expensive operation that should be optimized and performed once for the line, not something that can be computed on the fly as is done now. This breaks the assumptions in the design of the current approach and so would require it to be redone. That is certainly doable but it seems unfortunate to make that process much more complicated, for what's not probably a commonly needed use case. I suspect, that in many cases, users with a C locale configured actually still see UTF-8 output fine in their terminal anyway... The output with UCN escapes already looks bad, so perhaps having misaligned labels and carets is not a big deal and it's fine as it is. 2. The testsuite always runs with LC_ALL=C currently. Therefore, after the change in this patch, a test is no longer able to test for UTF-8 output in diagnostics, it will be UCN escaped instead. There is one such test currently (gcc.dg/diagnostic-input-charset-1.c). It doesn't seem suitable to change that test to look for UCN escapes, because the purpose of that test is to confirm that correct UTF-8 is generated when an input file is in another charset. So I instead added a new option -fdiagnostics-format=force-utf8. This is the same as -fdiagnostics-format=text except it disables the conversion to the user's locale and restores the previous behavior. That seemed more simple than adding ability to change the locale in the testsuite, plus I thought users may want this option for themselves for some reason, if say they do not have access to a UTF-8 locale somehow but their terminal still displays it fine. So that much seems fine, however there is a wrinkle here that I am not sure how to fix. The user probably expects that this new option will cause all diagnostics output to be UTF-8 regardless of locale. But some of the output is not generated by the diagnostics infrastructure at all. For example, localized strings are converted by
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- [dcl.link] p8: "A declaration directly contained in a linkage-specification is treated as if it contains the extern specifier (9.2.2) for the purpose of determining the linkage of the declared name and whether it is a definition. Such a declaration shall not specify a storage class."
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Ever confirmed|0 |1 Resolution|INVALID |--- Last reconfirmed||2021-08-27 --- Comment #7 from Jonathan Wakely --- This is not very helpful: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#2230 A discussion in 2017 concluded that Stephan is correct, but that never made it to the issues list. So confirming as a bug.
[Bug testsuite/57606] Failure in testing stage 3 of gcc-4.7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57606 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||iains at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #2 from Iain Sandoe --- 4.7 is long closed, all implemented languages and their support libraries are working on macOS 10.5 through 11.4 for the current open branches (9.x ... master).
[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #21 from Iain Sandoe --- fixed on all open branches. distributions using earlier branches would be advised to back-port to those.
[Bug other/102099] Diagnostics do not consider the user's locale when printing source lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102099 --- Comment #1 from Lewis Hyatt --- Created attachment 51365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51365=edit Tested patch
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 --- Comment #8 from friedkeenan at protonmail dot com --- Sorry for wasting your time with this bug report. It just didn't make sense to me why placement-new couldn't be constexpr
[Bug target/99557] [AIX] Alignment of double for struct and C++ classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99557 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Edelsohn --- Fixed.
[Bug c/102098] New: ICE when #include with -fmodules-ts -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098 Bug ID: 102098 Summary: ICE when #include with -fmodules-ts -std=c++20 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: accelerator0099 at gmail dot com Target Milestone: --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC) System: Linux 5.13.12 Command: g++ -std=c++20 -fmodules-ts -Wall -c broadcast_server.cc -save-temps Sources: Attached below Output: broadcast_server.cc:3:8: internal compiler error: in tree_node, at cp/module.cc:9057 3 | export module broadcast_server; |^ 0x1797368 internal_error(char const*, ...) ???:0 0x67f8f9 fancy_abort(char const*, int, char const*) ???:0 0x765323 trees_out::core_vals(tree_node*) ???:0 0x768e78 trees_out::tree_value(tree_node*) ???:0 0x761e9c trees_out::tree_node(tree_node*) ???:0 0x765323 trees_out::core_vals(tree_node*) ???:0 0x768e78 trees_out::tree_value(tree_node*) ???:0 0x761e9c trees_out::tree_node(tree_node*) ???:0 0x765323 trees_out::core_vals(tree_node*) ???:0 0x768e78 trees_out::tree_value(tree_node*) ???:0 0x761e9c trees_out::tree_node(tree_node*) ???:0 0x765323 trees_out::core_vals(tree_node*) ???:0 0x768e78 trees_out::tree_value(tree_node*) ???:0 0x761e9c trees_out::tree_node(tree_node*) ???:0 0x765323 trees_out::core_vals(tree_node*) ???:0 0x768e78 trees_out::tree_value(tree_node*) ???:0 0x761e9c trees_out::tree_node(tree_node*) ???:0 0x765323 trees_out::core_vals(tree_node*) ???:0 0x768e78 trees_out::tree_value(tree_node*) ???:0 0x761e9c trees_out::tree_node(tree_node*) ???:0 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. As you can see, there are "???:0"s instead of sources and line numbers. Maybe the gcc on my os doesn't comtain debug information. Do I need to rebuild it with debug enabled?
[Bug libstdc++/102100] New: _GLIBCXX_ASSERTIONS information missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102100 Bug ID: 102100 Summary: _GLIBCXX_ASSERTIONS information missing. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://godbolt.org/z/1M1EsaT1r The printf function disappears
[Bug c++/102092] [C++2b] Passing argument to auto template parameter modifies the value of argument inside function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102092 --- Comment #1 from Andrei-Edward Popa --- This is a link for code compilation in compiler explorer. https://godbolt.org/z/3jMr6Wze6
[Bug c++/79531] bad location when trying to define undeclared method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79531 --- Comment #3 from Tom Tromey --- (In reply to Andrew Pinski from comment #2) > Which seems ok, unless I am missing something. Looks good to me too, IMO you could close this bug.
[Bug c++/102101] New: Another spurious -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102101
Bug ID: 102101
Summary: Another spurious -Warray-bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
Target Milestone: ---
On recent trunk (basepoints/gcc-12-3135-gdb3d4129b6f):
> $ cat test.cc
> #include
> #include
> long dummy();
> void * rtl_allocateMemory();
> struct XInterface {
> virtual void acquire() = 0;
> void release();
> };
> struct WeakComponentImplHelperBase: XInterface {
> static void * operator new(std::size_t) { return rtl_allocateMemory(); }
> static void operator delete(void *);
> virtual void acquire();
> };
> struct XPrimitive2D: XInterface {};
> struct PartialWeakComponentImplHelper: WeakComponentImplHelperBase,
> XPrimitive2D {
> void acquire() { WeakComponentImplHelperBase::acquire(); }
> };
> struct FillHatchPrimitive2D: PartialWeakComponentImplHelper {
> FillHatchPrimitive2D();
> };
> struct Reference {
> XInterface * _pInterface;
> ~Reference() { if (_pInterface) _pInterface->release(); }
> Reference(XPrimitive2D * pInterface) {
> _pInterface = static_cast(static_cast *>(pInterface));
> if (_pInterface) _pInterface->acquire();
> }
> };
> struct Size {
> Size();
> bool IsEmpty() const { return nA || nB; }
> int nA, nB;
> };
> struct PropertyHolder {
> bool getLineOrFillActive() { return mbLineColor || mbFillColor; }
> bool mbLineColor, mbFillColor;
> };
> struct NonOverlappingFillGradientPrimitive2D: FillHatchPrimitive2D {
> void create2DDecomposition() { if (dummy()) dummy(); }
> NonOverlappingFillGradientPrimitive2D() {}
> };
> void implInterpretMetafile(PropertyHolder & rPropertyHolders) {
> int nCount = dummy();
> int nAction = 0;
> switch(dummy()) {
> case 0:
> while (0 == dummy() && nAction < nCount) {}
> case 1:
> while (0 == dummy() && nAction < nCount) {}
> case 2:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 3:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 4:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 5:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 6:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 7:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 8:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 9:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 10:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 11:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 12:
> {
> int nTextLength = dummy();
> int nTextIndex = dummy();
> int nStringLength = dummy();
> if (nTextLength + nTextIndex > nStringLength) {
> nTextLength = nTextIndex > nStringLength ? 0 : nStringLength
> - nTextIndex;
> }
> if (nTextLength && dummy()) {
> std::vector< double > aDXArray;
> aDXArray.reserve(nTextLength);
> }
> }
> case 13:
> if (dummy() && dummy())
> if (dummy() && dummy()) dummy();
> case 14:
> {
> Size rRectangle;
> if (rRectangle.IsEmpty() && dummy()) dummy();
> }
> case 15:
> Reference(new FillHatchPrimitive2D);
> }
> }
> $ g++ -D_GLIBCXX_DEBUG -Werror -Warray-bounds -O2 -c test.cc
> In member function ‘virtual void PartialWeakComponentImplHelper::acquire()’,
> inlined from ‘Reference::Reference(XPrimitive2D*)’ at test.cc:26:46,
> inlined from ‘void implInterpretMetafile(PropertyHolder&)’ at
> test.cc:122:9:
> test.cc:16:58: error: array subscript 0 is outside array bounds of
>
[Bug libstdc++/80371] std::is_integral and std::is_floating_point fail with vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80371 --- Comment #2 from Jonathan Wakely --- (In reply to jwjagersma from comment #0) > Testing with std::is_integral or std::is_floating_point fails for > vector types. I don't think that's supposed to happen. Says who? The docs on the attribute don't say anything about whether they are new scalar types, but the name "vector" pretty strongly hints they're not scalar types! The traits check for the arithmetic types defined in the standard, and don't consider vectors of those types to be the same as those underlying types. I think that's the right behaviour.
[Bug libstdc++/102100] [12 Regression] _GLIBCXX_ASSERTIONS information missing under _GLIBCXX_VERBOSE==1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102100 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Known to fail||12.0 Status|UNCONFIRMED |ASSIGNED Summary|_GLIBCXX_ASSERTIONS |[12 Regression] |information missing under |_GLIBCXX_ASSERTIONS |_GLIBCXX_VERBOSE==1.|information missing under ||_GLIBCXX_VERBOSE==1. Known to work||11.2.1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2021-08-27 Ever confirmed|0 |1 Keywords||diagnostic Priority|P3 |P2 --- Comment #1 from Jonathan Wakely --- This is because of PR libstdc++/101429 where you complained about the assertions. The problem is that _GLIBCXX_VERBOSE isn't defined yet at that point in the c++config.h file, so it's always false.
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2016-08-21 00:00:00 |2021-8-27
[Bug c++/65845] typeid doesn't work consistently on pure virtual classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65845 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86252 --- Comment #2 from Andrew Pinski --- Fixed for GCC 11 by r11-5036 aka PR 86252
[Bug c/102103] missing warning for arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=33925 --- Comment #1 from Andrew Pinski --- Related to PR 33925.
[Bug tree-optimization/102006] A false warning "Array subscript -N is outside array bounds warning"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102006 --- Comment #9 from Martin Sebor --- Created attachment 51366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51366=edit Reduced test case. Attached is a reduced test case.
[Bug go/102102] New: [12 Regression] trunk 20210827 ftbfs libgo on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102 Bug ID: 102102 Summary: [12 Regression] trunk 20210827 ftbfs libgo on x86_64-linux-gnux32 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at debian dot org CC: cmang at google dot com Target Milestone: --- trunk 20210827 ftbfs libgo on x86_64-linux-gnux32, also seen on x86_64-linux-gnu when configuring with --with-multilib-list=m32,m64,mx32 /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:35:30: error: integer constant overflow 35 | seed ^= hashkey[0] ^ m1 | ^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:61:50: error: integer constant overflow 61 | seed = mix(r8(p)^m2, r8(add(p, 8))^seed) | ^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:62:60: error: integer constant overflow 62 | seed1 = mix(r8(add(p, 16))^m3, r8(add(p, 24))^seed1) |^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:63:60: error: integer constant overflow 63 | seed2 = mix(r8(add(p, 32))^m4, r8(add(p, 40))^seed2) |^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:69:42: error: integer constant overflow 69 | seed = mix(r8(p)^m2, r8(add(p, 8))^seed) | ^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:76:20: error: integer constant overflow 76 | return mix(m5^s, mix(a^m2, b^seed)) |^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:76:32: error: integer constant overflow 76 | return mix(m5^s, mix(a^m2, b^seed)) |^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:81:22: error: integer constant overflow 81 | return mix(m5^4, mix(a^m2, a^seed^hashkey[0]^m1)) | ^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:81:32: error: integer constant overflow 81 | return mix(m5^4, mix(a^m2, a^seed^hashkey[0]^m1)) |^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:81:54: error: integer constant overflow 81 | return mix(m5^4, mix(a^m2, a^seed^hashkey[0]^m1)) | ^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:86:22: error: integer constant overflow 86 | return mix(m5^8, mix(a^m2, a^seed^hashkey[0]^m1)) | ^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:86:32: error: integer constant overflow 86 | return mix(m5^8, mix(a^m2, a^seed^hashkey[0]^m1)) |^ /packages/gcc/snap/gcc-snapshot-20210827/src/libgo/go/runtime/hash64.go:86:54: error: integer constant overflow 86 | return mix(m5^8, mix(a^m2, a^seed^hashkey[0]^m1)) | ^
[Bug c++/72753] sole flexible array member in a typedef rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72753 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93753 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed for GCC 9.3 and GCC 10+ by the patch which fixed PR 93753.
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 --- Comment #9 from Jakub Jelinek --- One of the reasons might be that placement new returns void *, and cast of that to pointer to some other type is not valid in constant expressions. std::construct_at bypasses all of that just by being a magic function, it is up to the implementation how it achieves what it is supposed to do.
[Bug c++/77299] No warning for unused "INT64_MAX" and similar constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77299 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- It is a dup of bug 77513 though. *** This bug has been marked as a duplicate of bug 77513 ***
[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513 Andrew Pinski changed: What|Removed |Added CC||wipedout at yandex dot ru --- Comment #10 from Andrew Pinski --- *** Bug 77299 has been marked as a duplicate of this bug. ***
[Bug c++/77557] gcc doesn't warn about code (clang does), __PRETTY_FUNCTION__ used in struct in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59795 --- Comment #5 from Andrew Pinski --- I think this is a similar bug to PR 59795 in the sense the nestedness of the struct has a namesearch issues. Confirmed.
[Bug c++/77566] Warnings (-Wextra) disappear for a public reference to the this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77566 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/62165] Misleading error messages when using "impossible" brace initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62165 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2014-08-17 00:00:00 |2021-8-27 --- Comment #5 from Andrew Pinski --- I don't know how important this is as the code in question is only invalid C++11 (and C++98 but for other reasons) and is valid c++14 code. clang and ICC (EDG) both have a similar error message as GCC does.
[Bug c++/60815] prologue line is wrong for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Inconsistent prologue line |prologue line is wrong for |table location |templates Ever confirmed|0 |1 Last reconfirmed||2021-08-27 --- Comment #4 from Andrew Pinski --- Confirmed, For templates, we should save off func_brace_location (somewhere) and set DECL_STRUCT_FUNCTION (decl)->function_start_locus when the function gets instantiated.
[Bug c++/78704] operator-> pointer return type is not recognized as pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78704 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81045 Target Milestone|--- |7.2 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed for GCC 7.2 and GCC 8+; most likely by the patch which fixed PR 81045.
[Bug tree-optimization/102006] A false warning "Array subscript -N is outside array bounds warning"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102006
--- Comment #10 from Martin Sebor ---
With the reduced test case from attachment 51366 I get the same warning:
$ gcc -O2 -S -Wall -std=c++20 -xc++ ListTest.cpp.i
In constructor ‘double_iterator::double_iterator(single_iterator) [with T =
Element; DLink = quick_link; ForwardLink = forward_link;
BackwardLink = backward_link]’,
inlined from ‘quick_list::iterator quick_list::end()
[with T = Element; DLink = quick_link]’ at ListTest.cpp.i:66:43,
inlined from ‘void ListHolder::PrintList()’ at ListTest.cpp.i:92:73,
inlined from ‘void List_TestFunc(const TestContext&)’ at
ListTest.cpp.i:103:19:
ListTest.cpp.i:30:96: warning: array subscript 0 is outside array bounds of
‘ListHolder [1]’ [-Warray-bounds]
30 | ator i) : double_iterator(static_cast(*i)) { }
| ^
ListTest.cpp.i: In function ‘void List_TestFunc(const TestContext&)’:
ListTest.cpp.i:102:14: note: at offset -16 into object ‘holder’ of size 16
102 | ListHolder holder (context);
| ^~
[Bug c++/92193] Poor diagnostics when a constexpr function call follows a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/65174] noexcept() returns true when operator delete with a NULL PTR that has a throwing destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65174
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2018-10-17 00:00:00 |2021-8-27
Summary|noexcept() returns true |noexcept() returns true
|when operator delete with |when operator delete with a
|the object that has a |NULL PTR that has a
|throwing destructor |throwing destructor
Keywords||wrong-code
--- Comment #4 from Andrew Pinski ---
Updated testcase to show that noexcept will also cause it to happen so it does
matter for C++17+ (where throw(std::bad_alloc) support has been removed):
#include
struct foo1 {
~foo1() noexcept(false) {}
};
int main() {
std::cout << std::boolalpha;
std::cout << noexcept(delete static_cast(nullptr)) << std::endl;
std::cout << noexcept(delete reinterpret_cast(0)) << std::endl;
std::cout << noexcept(delete reinterpret_cast(1)) << std::endl;
return 0;
}
[Bug c++/69698] [meta-bug] flexible array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698 Bug 69698 depends on bug 72753, which changed state. Bug 72753 Summary: sole flexible array member in a typedef rejected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72753 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/77299] No warning for unused "INT64_MAX" and similar constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77299 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2021-08-27 Ever confirmed|0 |1 Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #2 from Andrew Pinski --- This is not a dup of bug 77297 but there might be another bug this is a dup of though. The problem here is the macros come from system headers. Using -Wsystem-headers allows for the warnings to get through.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 102019, which changed state. Bug 102019 Summary: [12 Regression] UBSAN error: hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' since r12-2975-g32c3a75390623a0470df52af13f78baddd562981 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102019 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/102019] [12 Regression] UBSAN error: hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' since r12-2975-g32c3a75390623a0470df52af13f78baddd562981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102019 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug c++/78019] Local class with lambda in default member initializer cannot default-capture this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78019 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed for GCC 8+.
[Bug c/102103] New: missing warning for arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103
Bug ID: 102103
Summary: missing warning for arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC issues -Waddress only for the equality test in f() but not those in g() or
h(), even though all three evaluate to false (and even though GCC folds all
three to false even with no optimization). It would be helpful to diagnose all
three.
$ cat z.c && gcc -S -Wall -fdump-tree-optimized=/dev/stdout z.c
void f (void)
{
int i;
if ( == 0) // -Waddress (good)
__builtin_abort ();
}
void g (void)
{
int a[1];
if (a == 0) // missing warning
__builtin_abort ();
}
void h (void)
{
int a[1][2];
if (a[0] == 0) // missing warning
__builtin_abort ();
}
z.c: In function ‘f’:
z.c:4:10: warning: the comparison will always evaluate as ‘false’ for the
address of ‘i’ will never be NULL [-Waddress]
4 | if ( == 0) // -Waddress (good)
| ^~
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
void f ()
{
int i;
:
i ={v} {CLOBBER};
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
void g ()
{
int a[1];
:
a ={v} {CLOBBER};
return;
}
;; Function h (h, funcdef_no=2, decl_uid=1951, cgraph_uid=3, symbol_order=2)
void h ()
{
int a[1][2];
:
a ={v} {CLOBBER};
return;
}
Clang diagnoses both the one in f() and in g() (but not the one in h()). GCC
4.4.7 does as well but the latter has been lost since GCC 4.5 (see
https://gcc.godbolt.org/z/8dbjxv89E) so technically this could be viewed as a
regression.
[Bug c++/60924] __attribute__((no_sanitize_address)) and friends should (only?) be allowed at function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60924 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- This is not going to change. clang implements it this way too. As mentioned GCC is consistent with itself here in that function attributes apply for both.
[Bug middle-end/102101] spurious -Warray-bounds on a virtual function call and a derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102101 Martin Sebor changed: What|Removed |Added Blocks||56456 Summary|Another spurious|spurious -Warray-bounds on |-Warray-bounds |a virtual function call and ||a derived class Ever confirmed|0 |1 Keywords||diagnostic Last reconfirmed||2021-08-27 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101600 Component|c++ |middle-end --- Comment #1 from Martin Sebor --- The warning is working as designed in this case (as opposed to pr101600) but the design has its shortcomings. It complains about the negative offset from the D.25604.D.25576 subobject in this: MEM[(struct FillHatchPrimitive2D *)_150].D.25604.D.25576 in the IL below. Only accesses within the bounds of each subobject are considered valid. But here, the negative offset has to do with getting at the virtual table in struct XInterface but that code is transformed into the invalid-looking MEM_REF. I'm not sure how to handle this yet. It's in the same class as the other "representational" problems where downstream warnings assume the IL corresponds to the source and where prior transformations result in something that's indistinguishable from a bug. The warnings also don't understand C++ very well and that makes the "naive subobject logic" more susceptible to false positives in these cases. : _150 = rtl_allocateMemory (); FillHatchPrimitive2D::FillHatchPrimitive2D (_150); [local count: 916872327]: if (_150 != 0B) goto ; [70.00%] else goto ; [30.00%] [local count: 275061695]: # iftmp.34_242 = PHI <0B(106)> if (iftmp.34_242 != 0B) goto ; [70.00%] else goto ; [30.00%] [local count: 82518508]: goto ; [100.00%] [local count: 641810632]: iftmp.34_119 = [(struct FillHatchPrimitive2D *)_150].D.25604.D.25576; [local count: 834353819]: # iftmp.34_203 = PHI _218 = [(struct PartialWeakComponentImplHelper *)iftmp.34_203 + -8B].D.25575; <<< -Warray-bounds WeakComponentImplHelperBase::acquire (_218); <<< virtual call Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Andrew Pinski changed: What|Removed |Added CC||lhyatt at gmail dot com --- Comment #17 from Andrew Pinski --- *** Bug 58740 has been marked as a duplicate of this bug. ***
[Bug c++/58740] incorrect access check of static base class member in derived template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58740 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 41437 and fixed for GCC 11+. *** This bug has been marked as a duplicate of bug 41437 ***
[Bug rtl-optimization/70892] additional memory access generated in loop if destructor is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70892 Andrew Pinski changed: What|Removed |Added Component|middle-end |rtl-optimization Known to fail||9.1.0 Keywords||missed-optimization, ra Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2021-08-27 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- So the different comes from sum having to be alive across eh edges. GCC would spill the register to the stack before GCC 9. In GCC 10+, it uses a register. Still not the best code: .L6: movq%r12, %xmm1 addsd (%rax), %xmm1 addq$8, %rax movq%xmm1, %r12 cmpq%rax, %rdx jne .L6 But no longer spills to the stack inside the loop.
