[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target||x86_64-pc-linux-gnu
Host|x86_64-pc-linux-gnu |
--- Comment #1 from Andrew Pinski ---
choose_mult_variant (machine_mode mode, HOST_WIDE_INT val,
...
synth_mult (, val - 1, , mode);
But slsr should not be processing any of these IR I don't think.
_7 = _4 * Inf;
c$imag_8 = (long intD.8) _7;
# VUSE <.MEM_16>
i.1_9 = iD.1980;
# RANGE [-2147483648, 2147483647]
_10 = (long intD.8) i.1_9;
c$real_23 = c$real_6 * _10;
c$imag_24 = c$imag_8 * _10;
Huh? This does not make sense at all.
float _4;
float _7;
if (tree_fits_shwi_p (rhs2))
return mult_by_coeff_cost (tree_to_shwi (rhs2), lhs_mode, speed);
But I don't see that even call that.
bool
tree_fits_shwi_p (const_tree t)
{
return (t != NULL_TREE
&& TREE_CODE (t) == INTEGER_CST
&& wi::fits_shwi_p (wi::to_widest (t)));
}
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #4 from Hongtao.liu ---
(In reply to bartoldeman from comment #3)
> Created attachment 53786 [details]
> Corrected test case
>
> In my eagerness to make it as short as possible I made it too short indeed!
35 [local count: 105119324]:
36 bnd.12_91 = (unsigned int) n_29(D);
37 _90 = (long unsigned int) inc_x_33(D);
38 _89 = _90 * 8;
39 ivtmp.24_45 = (unsigned long) x_31(D);
40 ivtmp.26_3 = (unsigned long) y_32(D);
41
42 [local count: 955630225]:
43 # vect_dot_3_55.16_71 = PHI
44 # ivtmp.19_55 = PHI
45 # ivtmp.24_49 = PHI
46 # ivtmp.26_1 = PHI
47 _75 = (void *) ivtmp.24_49;
48 _78 = MEM [(const double *)_75];
49 _76 = MEM [(const double *)_75 + _89 * 1];
50 vect_cst__74 = {_78, _76}; --- here
51 vect__4.14_73 = VEC_PERM_EXPR ;
52 _5 = (void *) ivtmp.26_1;
53 _86 = MEM [(const double *)_5];
54 _84 = MEM [(const double *)_5 + _89 * 1];
55 vect_cst__82 = {_86, _84}; -- here
56 vect__6.13_81 = VEC_PERM_EXPR ;
57 vect__20.17_70 = .FMA (vect__4.14_73, vect__6.13_81, vect_dot_3_55.16_71);
58 ivtmp.19_92 = ivtmp.19_55 + 1;
59 ivtmp.24_46 = ivtmp.24_49 + _89;
60 ivtmp.26_2 = ivtmp.26_1 + _89;
61 if (bnd.12_91 != ivtmp.19_92)
62goto ; [90.00%]
63 else
64goto ; [10.00%]
65
66 [local count: 105119324]:
67 _51 = .REDUC_PLUS (vect__20.17_70); [tail call]
It looks like it should be vect_cst__82 = {_84, _86} not {_86, _84}, similar
for vect_cst__74 = {_76, _78} not {_78, _76}.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #20 from Kewen Lin --- (In reply to Alan Modra from comment #4) > The disassembly says this is powerpc64le. Possibly interesting fact: the > offsets used above the stack frame are 400, 432, 440, which all correspond > to the parameter save area. I don't see any reason that DGEBAL should have > a parameter save area though since all parameters can be passed in regs. This also confuses me, since the function prototype SUBROUTINE DGEBAL( JOB, N, A, LDA, ILO, IHI, SCALE, INFO ) only has eight parameters, by looking into it the reason is that the first parameter "CHARACTER JOB" has one more hidden associated length argument. "For arguments of CHARACTER type, the character length is passed as a hidden argument at the end of the argument list. " as said in [1], so this function actually has nine (more than eight) doubleword arguments, then it does need one parameter save area. [1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html Surya's analysis looks reasonable to me, the current stub scheme with function pointer call in C doesn't match the Fortran side.
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 --- Comment #32 from Hongtao.liu --- (In reply to Marko Mäkelä from comment #31) > Much of this seems to work in GCC 12.2.0 as well as in clang++-15. For clang > there is a related ticket https://github.com/llvm/llvm-project/issues/37322 > > I noticed a missed optimization in both g++-12 and clang++-15: Some > operations involving bit 31 degrade to loops around lock cmpxchg. I compiled 31 is sign bit, and c = a & 1U << 31; c == 0 is optimized to (sign int)a >= 0. The optimization we did in optimize_atomic_bit_test_and is supposed to match a & 1U << 31, and it failed. I guess it could be extend to match (sign int)a >= 0 when mask is 1U << 31. 7 : 8 : 9 _1 = __atomic_fetch_or_4 (v, 2147483648, 0); 10 _2 = (signed int) _1; 11 if (_2 >= 0) goto ; else goto ; 12 : 13 return; 14} 15
[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I have not tested this at all but I suspect this patch will fix the issue: Oh I don't have time to submit this patch either. But maybe someone else could do it.
[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 --- Comment #3 from Andrew Pinski --- I have not tested this at all but I suspect this patch will fix the issue: apinski@xeond:~/src/upstream-gcc/gcc/gcc/c-family$ git diff c-warn.cc diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc index 6742f447ff5..44d16111370 100644 --- a/gcc/c-family/c-warn.cc +++ b/gcc/c-family/c-warn.cc @@ -2302,8 +2302,8 @@ warn_for_sign_compare (location_t location, sop = fold_for_warn (sop); uop = fold_for_warn (uop); - STRIP_TYPE_NOPS (sop); - STRIP_TYPE_NOPS (uop); + STRIP_SIGN_NOPS (sop); + STRIP_SIGN_NOPS (uop); base_type = (TREE_CODE (result_type) == COMPLEX_TYPE ? TREE_TYPE (result_type) : result_type); -- CUT And if it does, then I was right on the reason why typedef vs using unsigned short directly too.
[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Known to work||4.1.2 Summary|Bogus warning: promoted |[10/11/12/13 Regression] |bitwise complement of an|Bogus warning: promoted |unsigned value is always|bitwise complement of an |nonzero |unsigned value is always ||nonzero Ever confirmed|0 |1 Known to fail||4.4.7, 4.8.1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=8715 Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-31 --- Comment #2 from Andrew Pinski --- >Also, it's weird that the warning is only issued with a typedef for the type >of "x". My bet there is some IR difference (inside GCC) which is causing an extra NOP_EXPR (a cast) being added due to the typedef and "unsigned short" are not represented the same internally for diagnostic reasons. Confirmed. r0-88988-g2d12797c692346 (PR 8715) introduced the warning in GCC 4.4.0 which seems to point to that is what is causing the bogus warning to show up.
[Bug target/107261] ICE: in classify_argument, at config/i386/i386.cc:2523 on __bf16 vect argument or return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107261 --- Comment #6 from Hongtao.liu --- Fixed in GCC13.
[Bug c/107465] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 Andrew Pinski changed: What|Removed |Added Known to fail||11.3.0, 12.1.0, 6.1.0, ||8.1.0 --- Comment #1 from Andrew Pinski --- The diagnostic changed between GCC 9 and 10. 9: promoted ~unsigned is always non-zero 10: promoted bitwise complement of an unsigned value is always nonzero
[Bug target/107261] ICE: in classify_argument, at config/i386/i386.cc:2523 on __bf16 vect argument or return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107261 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:6913cad2a38bc406b137b06d579b650f6fe9a2e6 commit r13-3565-g6913cad2a38bc406b137b06d579b650f6fe9a2e6 Author: liuhongt Date: Tue Oct 25 13:31:54 2022 +0800 Enable V4BFmode and V2BFmode. Enable V4BFmode and V2BFmode with the same ABI as V4HFmode and V2HFmode. No real operation is supported for them except for movement. This should solve PR target/107261. Also I notice there's redundancy in VALID_AVX512FP16_REG_MODE, and remove V2BFmode remove it. gcc/ChangeLog: PR target/107261 * config/i386/i386-modes.def (VECTOR_MODE): Support V2BFmode. * config/i386/i386.cc (classify_argument): Handle V4BFmode and V2BFmode. (ix86_convert_const_vector_to_integer): Ditto. * config/i386/i386.h (VALID_AVX512FP16_REG_MODE): Remove V2BFmode. (VALID_SSE2_REG_MODE): Add V4BFmode and V2BFmode. (VALID_MMX_REG_MODE): Add V4BFmode. * config/i386/i386.md (mode): Add V4BF and V2BF. (MODE_SIZE): Ditto. * config/i386/mmx.md (MMXMODE) Add V4BF. (V_32): Add V2BF. (V_16_32_64): Add V4BF and V2BF. (mmxinsnmode): Add V4BF and V2BF. (*mov_internal): Hanlde V4BFmode and V2BFmode. gcc/testsuite/ChangeLog: * gcc.target/i386/pr107261.c: New test.
[Bug c++/105511] [12/13 Regression] Spurious warning: "expected 'template' keyword..." when lt and gt compare over ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105511 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||11.1.0, 11.3.0 Summary|Spurious warning: "expected |[12/13 Regression] Spurious |'template' keyword..." when |warning: "expected |lt and gt compare over |'template' keyword..." when |ternary |lt and gt compare over ||ternary Known to fail||12.1.0 Target Milestone|--- |12.3 Ever confirmed|0 |1 Last reconfirmed||2022-10-31 --- Comment #1 from Andrew Pinski --- Confirmed. r12-6563-gb8ffa71e4271ae introduced the warning and enabled it by default. I say this is a regression since the warning is enabled by default and I can't even see how to avoid the warning.
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 --- Comment #9 from Chris MacGregor --- With the testcase I just attached, using 13.0.0 20221030 via Godbolt: https://godbolt.org/z/8Y4cr6MxY : In instantiation of 'Event::Event(EventCat, auto:1) [with auto:1 = int]': :38:32: required from here :30:30: internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy, at cp/pt.cc:17024 30 | boundsCheck(a_category, kEventCat_Min); // using "EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail | ~^~~
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 --- Comment #8 from Andrew Pinski --- *** Bug 107460 has been marked as a duplicate of this bug. ***
[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460 --- Comment #5 from Andrew Pinski --- (In reply to Chris MacGregor from comment #4) > @Andrew, how did you get the output in comment #2, with "tree check: > expected enumeral_type, have record_type in tsubst_copy" in it? When gcc is configured --enable-checking=yes (or as on the development trunk it is enabled by default) Gcc has many extra internal checks to make sure things are not accessed incorrectly but only enabled if requested for release builds as they introduce some overhead on compile time. > > Also, should this be marked as directly a dup of 103081, rather than as dup > of a dup (105787)? (I did look at 103081, but it wasn't clear that it was > necessarily the same bug, since the upper part of the backtrace is different > from what I saw, and the lower part seems to be missing in the 103081 > report.) Yes. Though it does not matter that much as it does not change anything in fixing the bug. *** This bug has been marked as a duplicate of bug 103081 ***
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 Chris MacGregor changed: What|Removed |Added CC||chris-gcc-bugzilla@cybermat ||o.com --- Comment #7 from Chris MacGregor --- Created attachment 53800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53800=edit testcase originally for bug 107460 Now that bug 107460 (ICE with "using enum" member passed to template function, g++ 11.x-13) is marked a dup of this (indirectly, via bug 105787), attaching the testcase here; hopefully that's helpful.
[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460 --- Comment #4 from Chris MacGregor --- @Andrew, how did you get the output in comment #2, with "tree check: expected enumeral_type, have record_type in tsubst_copy" in it? Also, should this be marked as directly a dup of 103081, rather than as dup of a dup (105787)? (I did look at 103081, but it wasn't clear that it was necessarily the same bug, since the upper part of the backtrace is different from what I saw, and the lower part seems to be missing in the 103081 report.)
[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-30 Ever confirmed|0 |1
[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467 --- Comment #3 from Andrew Pinski --- Created attachment 53799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53799=edit Testcase compile with -O2 -fno-strict-aliasing -flto New self contained testcase.
[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467 Andrew Pinski changed: What|Removed |Added Known to work||11.1.0, 11.3.0 Target Milestone|--- |12.3 Known to fail||12.1.0 Summary|Miscompilation involing -Os |[12/13 Regression] |, -flto and |Miscompilation involing -Os |-fno-strict-aliasing|, -flto and ||-fno-strict-aliasing
[Bug tree-optimization/107467] Miscompilation involing -Os , -flto and -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
--- Comment #2 from Andrew Pinski ---
Here is a single file example which just needs -Os -flto -fno-strict-aliasing:
template
struct pair
{
int first;
T second;
};
template
[[gnu::optimize("strict-aliasing")]]
bool __attribute__((noinline))
compare_pairs(const pair , const pair ) {
return lhs.first == rhs.first && lhs.second == rhs.second;
}
template struct Combined {
pair
__attribute__((noinline)) get_const() {
return pair{123, nullptr};
}
[[gnu::optimize("strict-aliasing")]]
bool
__attribute__((noinline)) clashy() {
return compare_pairs(get_const(), get_const());
}
};
class SomeClass {};
class OtherClass {};
[[gnu::optimize("strict-aliasing")]]
[[gnu::used]]
void some_func() {
Combined myvar;
__builtin_printf("%i\n", myvar.clashy());
}
[[gnu::optimize("strict-aliasing")]]
void other_func() {
Combined myvar;
__builtin_printf("%i\n", myvar.clashy());
}
[[gnu::optimize("O0")]]
int main()
{
other_func();
}
[Bug tree-optimization/107467] Miscompilation involing -Os , -flto and -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
--- Comment #1 from Andrew Pinski ---
Here is the unincluded version of the source:
#include
template
bool __attribute__((noinline))
compare_pairs(const std::pair , const std::pair ) {
return lhs.first == rhs.first && lhs.second == rhs.second;
}
template struct Combined {
std::pair __attribute__((noinline)) get_const() {
return std::make_pair(123, nullptr);
}
bool __attribute__((noinline)) clashy() {
return compare_pairs(get_const(), get_const());
}
};
class SomeClass {};
class OtherClass {};
void some_func() {
Combined myvar;
__builtin_printf("%i\n", myvar.clashy());
}
void other_func() {
Combined myvar;
__builtin_printf("%i\n", myvar.clashy());
}
[Bug translation/107467] New: Miscompilation involing -Os , -flto and -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
Bug ID: 107467
Summary: Miscompilation involing -Os , -flto and
-fno-strict-aliasing
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: volker.weissmann at gmx dot de
Target Milestone: ---
Created attachment 53798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53798=edit
Source Code
g++ -g Record.cpp -c -fPIC -Os -flto
g++ -g -shared Record.o -fno-strict-aliasing -o librecord.so
g++ main.cpp -L. -lrecord
LD_LIBRARY_PATH=$PWD ./a.out
This sometimes prints 1 and sometimes prints 0.
If I remove the -fno-strict-aliasing flag of the second g++ command, or add it
to the first g++ command, it always prints 1.
There is no violation of the strict-aliasing rule in Record.cpp, at least none
that I could spot.
If you are afraid of non-reproducibility, fear not, the generated assembly is
the same every time, and is obviously wrong:
The method Combined::clashy() is missing a call to get_const
objdump librecord.so --disassemble=_ZN8CombinedI10OtherClassE6clashyEv.isra.0
113e <_ZN8CombinedI10OtherClassE6clashyEv.isra.0>:
113e: 48 83 ec 38 sub$0x38,%rsp
1142: 64 48 8b 04 25 28 00mov%fs:0x28,%rax
1149: 00 00
114b: 48 89 44 24 28 mov%rax,0x28(%rsp)
1150: 31 c0 xor%eax,%eax
1152: 48 8d 74 24 18 lea0x18(%rsp),%rsi
1157: 48 8d 7c 24 08 lea0x8(%rsp),%rdi
115c: e8 b9 ff ff ff call 111a
<_Z13compare_pairsIP10OtherClassEbRKSt4pairIiT_ES6_>
1161: 48 8b 54 24 28 mov0x28(%rsp),%rdx
1166: 64 48 2b 14 25 28 00sub%fs:0x28,%rdx
116d: 00 00
116f: 74 05 je 1176
<_ZN8CombinedI10OtherClassE6clashyEv.isra.0+0x38>
1171: e8 ca fe ff ff call 1040 <__stack_chk_fail@plt>
1176: 48 83 c4 38 add$0x38,%rsp
117a: c3 ret
The almost identical Combined::clashy() gets compiled correctly:
objdump librecord.so --disassemble=_ZN8CombinedI9SomeClassE6clashyEv.isra.0
117c <_ZN8CombinedI9SomeClassE6clashyEv.isra.0>:
117c: 48 83 ec 38 sub$0x38,%rsp
1180: 64 48 8b 04 25 28 00mov%fs:0x28,%rax
1187: 00 00
1189: 48 89 44 24 28 mov%rax,0x28(%rsp)
118e: 31 c0 xor%eax,%eax
1190: 48 8d 74 24 18 lea0x18(%rsp),%rsi
1195: 48 8d 7c 24 08 lea0x8(%rsp),%rdi
119a: e8 97 ff ff ff call 1136
<_ZN8CombinedI9SomeClassE9get_constEv.constprop.0>
119f: 48 89 54 24 20 mov%rdx,0x20(%rsp)
11a4: 89 44 24 18 mov%eax,0x18(%rsp)
11a8: e8 89 ff ff ff call 1136
<_ZN8CombinedI9SomeClassE9get_constEv.constprop.0>
11ad: 48 89 54 24 10 mov%rdx,0x10(%rsp)
11b2: 89 44 24 08 mov%eax,0x8(%rsp)
11b6: e8 5f ff ff ff call 111a
<_Z13compare_pairsIP10OtherClassEbRKSt4pairIiT_ES6_>
11bb: 48 8b 54 24 28 mov0x28(%rsp),%rdx
11c0: 64 48 2b 14 25 28 00sub%fs:0x28,%rdx
11c7: 00 00
11c9: 74 05 je 11d0
<_ZN8CombinedI9SomeClassE6clashyEv.isra.0+0x54>
11cb: e8 70 fe ff ff call 1040 <__stack_chk_fail@plt>
11d0: 48 83 c4 38 add$0x38,%rsp
11d4: c3 ret
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --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-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
$ cat main.cpp
void other_func();
int main() { other_func(); }
[Bug c++/107124] Reference template parameter refers to a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107124 --- Comment #3 from Fedor Chelnokov --- The latter example is indeed a bug in MSVC: https://developercommunity.visualstudio.com/t/Cannot-find-template-function-with-expli/1672180 And here is the related discussion according the original issue: https://stackoverflow.com/a/73921590/7325599
[Bug c++/107124] Reference template parameter refers to a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107124
--- Comment #2 from Andrew Pinski ---
Here is one which GCC/clang agree and accepts but MSVC/ICC reject (even before
the static assert):
template
struct A {};
template
constexpr int f(A) { return 0; }
template
constexpr int f(T) { return 1; }
const int tt = 0;
static_assert( f(A{}) == 0, "" );
CUT
So it looks like it is more complex than what I even orginally though.
[Bug c++/107124] Reference template parameter refers to a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107124
--- Comment #1 from Andrew Pinski ---
MSVC also invokes the static assert but ICC accepts it.
Note I think clang/ICC get the following wrong too:
template
struct A {};
template
constexpr int f(A) { return 0; }
template
constexpr int f(T) { return 1; }
const int tt = 0;
static_assert( f(A{}) == 1 );
I don't think any compiler implements this correct either ...
[Bug c++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 --- Comment #2 from Jonathan Wakely --- I don't think this is a compiler bug. Converting that value to uint16_t is narrowing. The problem is that the standard requires subtract_with_carry_engine to use linear_congruential_engine where each of those values is converted to T. This appears to mean subtract_with_carry_engine cannot be used with uint16_t.
[Bug c++/61596] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61596 Andrew Pinski changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 105560 has been marked as a duplicate of this bug. ***
[Bug c++/105560] Spurious -Wunused-local-typedefs warning on a typedef used on returned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105560 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Yes this is a dup of bug 61596. *** This bug has been marked as a duplicate of bug 61596 ***
[Bug c++/105560] Spurious -Wunused-local-typedefs warning on a typedef used on returned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105560 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61596 --- Comment #3 from Andrew Pinski --- I suspect this is basically PR 61596 .
[Bug c++/105560] Spurious -Wunused-local-typedefs warning on a typedef used on returned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105560 Andrew Pinski changed: What|Removed |Added Known to fail||4.8.1 --- Comment #2 from Andrew Pinski --- Hmm, it used not to warn in GCC 4.7.1 but C++11 was not fully implemented until 4.8 so I don't think this could be considered a regression.
[Bug c++/105560] Spurious -Wunused-local-typedefs warning on a typedef used on returned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105560
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-10-30
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed. Reduced testcase without lambdas:
template
bool call(F&&) {
typename F::Out var = false;
return var;
}
bool test() {
struct localc {
using Out = bool;
};
return call(localc{});
}
[Bug c++/107461] GCC rejects program with ambiguity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-10-30
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. reduced testcase:
template constexpr const T min(const T t0, const T t1) { return 0; }
template
struct Matrix{
template
friend Matrix
operator+(Matrix const& lhs, Matrix const& rhs);
};
template
Matrix
operator+(Matrix const& lhs, Matrix const& rhs);
void f()
{
Matrix<1> a;
a+a;
}
CUT
Note the min function inside the return type is important and is looking like
is what is causing issues to not match the two decls to be the same.
Having min as a non-template function allows it to be matched.
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 Andrew Pinski changed: What|Removed |Added CC||doodspav at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 104398 has been marked as a duplicate of this bug. ***
[Bug c++/104398] [c++20] ICE triggered by templated class with base class containing `using enum`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104398 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 103081. *** This bug has been marked as a duplicate of bug 103081 ***
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 Andrew Pinski changed: What|Removed |Added CC||tamas+...@hudson-trading.co ||m --- Comment #5 from Andrew Pinski --- *** Bug 105787 has been marked as a duplicate of this bug. ***
[Bug c++/105787] ICE in tree check: expected enumeral_type, have record_type in tsubst_copy since r11-5003-gd50310408f54e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105787 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 103081. *** This bug has been marked as a duplicate of bug 103081 ***
[Bug c++/105787] ICE in tree check: expected enumeral_type, have record_type in tsubst_copy since r11-5003-gd50310408f54e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105787 Andrew Pinski changed: What|Removed |Added CC||chris-gcc-bugzilla@cybermat ||o.com --- Comment #3 from Andrew Pinski --- *** Bug 107460 has been marked as a duplicate of this bug. ***
[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Duplicate of bug 105787. *** This bug has been marked as a duplicate of bug 105787 ***
[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460 --- Comment #2 from Andrew Pinski --- : In instantiation of 'Event::Event(EventCat, auto:1) [with auto:1 = int]': :38:32: required from here :30:30: internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy, at cp/pt.cc:17024 30 | boundsCheck(a_category, kEventCat_Min); // using "EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail | ~^~~
[Bug c++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
--- Comment #1 from Andrew Pinski ---
Shorter testcase (still includes):
#include
void f() {
std::subtract_with_carry_engine();
}
[Bug c++/107466] New: [12 Regression] invalid -Wnarrowing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Bug ID: 107466 Summary: [12 Regression] invalid -Wnarrowing error Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: littlefox+gcc-bugzi...@lf-net.org Target Milestone: --- Created attachment 53797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53797=edit Code triggering the error Hi, the attached code (and Godbolt[1]) fails in gcc 12+ with an -Wnarrowing error in a stdlibc++ template instantiated with an uint16_t and apparently trying to work with a 2^31: /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/random.tcc:545:9: error: narrowing conversion of '2147483563' from 'unsigned int' to 'short unsigned int' [-Wnarrowing] 545 | __lcg(__value == 0u ? default_seed : __value); The code works fine in 11.3 and clang (14) and since it also works in clang using libstdc++ 12.2, this error is probably in gcc itself and not in libstdc++. Tested this on my machine (debian testing), where it broke after a some system updates where installed - including a gcc update. Then tested this in Godbolt to check compiler versions and other configurations and asked in libera.chat/#c++ for others to verify if my code makes sense - which it seems to do. Best, Mara [1] Godbolt link: https://godbolt.org/z/sj18Mv5j9
[Bug c++/107463] Better error request for invalid initializer list of aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107463
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=90475
Last reconfirmed||2022-10-30
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, related to PR 90475.
Note clang in this case is just as bad as GCC (unlike PR 90475):
:9:7: error: no matching constructor for initialization of 'S'
S s({
^ ~
:1:8: note: candidate constructor (the implicit copy constructor) not
viable: cannot convert initializer list argument to 'const S'
struct S {
^
:1:8: note: candidate constructor (the implicit move constructor) not
viable: cannot convert initializer list argument to 'S'
struct S {
^
:5:5: note: candidate constructor not viable: cannot convert
initializer list argument to 'const Config'
S(Config const & cfg);
^
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 Iain Sandoe changed: What|Removed |Added Ever confirmed|1 |0 Status|SUSPENDED |UNCONFIRMED --- Comment #48 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #47) > (In reply to Ian Lance Taylor from comment #46) > > A small bit of work is needed on the codegen, to read and write the export > > data. And some work is required on the runtime, to clean it up to support > > Darwin. It has to be done by someone with access to a modern Darwin system. > > I could do something on this, perhaps, provided it is not overly demanding > in terms of expertise. Or do those parts which are such :) > > While I have more interest in Darwin PPC, since Go is broken there (ppc32 > support exists in out-of-tree branch of Go 1.9, though not for Darwin, > however the only Go bootstrappable from C, 1.4, is x86-only), access to > modern x86_64 Darwin is there. with care, most of the time, FE stuff tends to be quite neutral about the eventual Darwin target (generic Mach-O constraints are similar between the sub-targets***). The runtime, of course, is likely to be more specific. I'd recommend starting on x86_64 since that's pretty stable, and then we can look at i686 ... and when that works, ppc is likely to be quite easy. Arm64 is still pretty experimental, and there are known TODOs for ABI compliance, so I'd avoid that sub-platform initially (despite that it's the most modern). *** aarch64/arm64 Darwin has some much tighter constraints security-wise - in particular stack-based trampolines are not allowed - but we have a draft of a heap-based scheme in the devt. branch .. you'd just need to look at what has been done for C, Fortran and Ada.
[Bug c/107465] New: Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465
Bug ID: 107465
Summary: Bogus warning: promoted bitwise complement of an
unsigned value is always nonzero
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
Tried on both Ubuntu and Cygwin, the same gcc-11.3.0 -- and the same problem:
$ gcc --version
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Copyright (C) 2021 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.
$ gcc --version
gcc (GCC) 11.3.0
Copyright (C) 2021 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.
The code:
$ cat test.c
extern void fun2(void);
#ifdef BOGUS_WARNING
typedef unsigned short uint2;
#else
#define uint2 unsigned short
#endif
static void fun(uint2 x)
{
if (!(x ^ 0x))
fun2();
}
int main(void)
{
fun(0);
}
The compilation:
$ gcc -Wall -Wextra -O6 -c test.c
(clean)
BUT:
$ gcc -Wall -Wextra -O6 -c -DBOGUS_WARNING test.c
test.c: In function ‘fun’:
test.c:11:9: warning: promoted bitwise complement of an unsigned value is
always nonzero [-Wsign-compare]
11 | if (!(x ^ 0x))
| ^
The variable "x" is an unsigned short, so it gets promoted to int without the
sign extension; the second argument to XOR is a 32-bit int with only 16 bits
set to 1. The result of XOR is not necessarily non-0 because it does not flip
all the bits in an int, but only the lower 16 (so there's no promotion of any
sort, IMO). Also, it's weird that the warning is only issued with a typedef
for the type of "x".
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #47 from Sergey Fedorov --- (In reply to Ian Lance Taylor from comment #46) > A small bit of work is needed on the codegen, to read and write the export > data. And some work is required on the runtime, to clean it up to support > Darwin. It has to be done by someone with access to a modern Darwin system. I could do something on this, perhaps, provided it is not overly demanding in terms of expertise. Or do those parts which are such :) While I have more interest in Darwin PPC, since Go is broken there (ppc32 support exists in out-of-tree branch of Go 1.9, though not for Darwin, however the only Go bootstrappable from C, 1.4, is x86-only), access to modern x86_64 Darwin is there.
[Bug c++/107464] Expression error in qualified name lookup with lambdas in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107464 --- Comment #3 from Andrew Pinski --- There are definitely issues with lamdba in decltype and aliases and this is just one of many.
[Bug c++/107464] Expression error in qualified name lookup with lambdas in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107464 --- Comment #2 from Роман Санду --- Here's a link to godbolt with the minimal reproducing test case: https://godbolt.org/z/5PoYd3sPs Note that the bug is present in both gcc trunk and gcc 12.2.
[Bug c++/107464] Expression error in qualified name lookup with lambdas in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107464 --- Comment #1 from Роман Санду --- Created attachment 53796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53796=edit No bug with unqualified name
[Bug c++/107464] New: Expression error in qualified name lookup with lambdas in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107464 Bug ID: 107464 Summary: Expression error in qualified name lookup with lambdas in unevaluated context Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roma.sandu at gmail dot com Target Milestone: --- Created attachment 53795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53795=edit Minimal bug repro I've discovered an interesting bug with unevaluated context lambdas. In the attached examples, trying to instantiate `boo` with a qualified name results in an expression error. If we instead bring the name `spooky::boo` into the `evil` namespace with a `using` statement and instantiate `boo` through an unqualified name, it works as expected. And finally, if one removes the unevaluated context lambda in `boo`'s definition, it works in all cases.
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #46 from Ian Lance Taylor --- A small bit of work is needed on the codegen, to read and write the export data. And some work is required on the runtime, to clean it up to support Darwin. It has to be done by someone with access to a modern Darwin system.
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #45 from Iain Sandoe --- (In reply to Ian Lance Taylor from comment #44) > gccgo still does not work on Darwin. is work needed on the runtime, or on code-gen (or both)? If there was someone who had some spare time to work on it...
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #44 from Ian Lance Taylor --- gccgo still does not work on Darwin.
[Bug c++/107463] New: Better error request for invalid initializer list of aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107463
Bug ID: 107463
Summary: Better error request for invalid initializer list of
aggregate
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
struct S {
struct Config {
int x;
};
S(Config const & cfg);
};
void f() {
S s({
.y = "x"
});
}
results in:
: In function 'void f()':
:11:6: error: no matching function for call to 'S::S()'
11 | });
| ^
:5:5: note: candidate: 'S::S(const Config&)'
5 | S(Config const & cfg);
| ^
:5:22: note: no known conversion for argument 1 from '' to 'const S::Config&'
5 | S(Config const & cfg);
| ~~~^~~
:1:8: note: candidate: 'constexpr S::S(const S&)'
1 | struct S {
|^
:1:8: note: no known conversion for argument 1 from '' to 'const S&'
:1:8: note: candidate: 'constexpr S::S(S&&)'
:1:8: note: no known conversion for argument 1 from '' to 'S&&'
It would be a lot more helpful if the error was something like "there's no
member named y in Config, did you mean x?"
PR71542 seems related, but different.
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
hicham at mouline dot org changed:
What|Removed |Added
CC||hicham at mouline dot org
--- Comment #12 from hicham at mouline dot org ---
I see this warning still in g++ (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2) with
tbb-2020.3-9.fc35.x86_64
In file included from /usr/include/c++/12/pstl/parallel_backend_tbb.h:26,
from /usr/include/c++/12/pstl/parallel_backend.h:20,
from /usr/include/c++/12/pstl/algorithm_impl.h:22,
from /usr/include/c++/12/pstl/glue_execution_defs.h:50,
from /usr/include/c++/12/execution:32,
from 4.cpp:8:
/usr/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h
is deprecated. For details, please see Deprecated Features appendix in the TBB
reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details,
please see Deprecated Features appendix in the TBB reference manual.")
[Bug tree-optimization/107462] Missed optimization of std::atomic::fetch_xxx "null operations" to std::atomic::load()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107462 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- There might be a dup of this bug already but gcc does not try to optimize fetch and add to just fetch if the operation was going to be a nop.
[Bug target/107456] std::atomic::fetch_xxx generate LOCK CMPXCHG instead of simpler LOCK instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107456
--- Comment #2 from Marko Mäkelä ---
Sorry for the noise. I posted a variant of the program to
https://github.com/llvm/llvm-project/issues/58685 and g++-12 is already
emitting the optimal code. Example:
#include
bool lock_add_sete(std::atomic , uint32_t b)
{
return 0 == b + a.fetch_add(b);
}
0: f0 01 37lock add %esi,(%rdi)
3: 0f 94 c0sete %al
6: c3 ret
[Bug c++/107462] New: Missed optimization of std::atomic::fetch_xxx "null operations" to std::atomic::load()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107462
Bug ID: 107462
Summary: Missed optimization of std::atomic::fetch_xxx "null
operations" to std::atomic::load()
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marko.makela at mariadb dot com
Target Milestone: ---
In g++-12 -c -O2 targeting x86-64, the fetch_xxx() variants are translated to
LOCK XADD or loops around LOCK CMPXCHG, instead of the simple MOV. I did not
test other targets.
#include
uint32_t load(const std::atomic )
{ return a.load(std::memory_order_relaxed); }
uint32_t load_add(std::atomic )
{ return a.fetch_add(0, std::memory_order_relaxed); }
uint32_t load_sub(std::atomic )
{ return a.fetch_sub(0, std::memory_order_relaxed); }
uint32_t load_or(std::atomic )
{ return a.fetch_or(0, std::memory_order_relaxed); }
uint32_t load_xor(std::atomic )
{ return a.fetch_xor(0, std::memory_order_relaxed); }
uint32_t load_and(std::atomic )
{ return a.fetch_and(~uint32_t(0), std::memory_order_relaxed); }
clang++-15 would translate each function to the same x86-64 code:
0: 8b 07 mov(%rdi),%eax
2: c3 ret
When using the default std::memory_order_seq_cst, an MFENCE instruction would
be emitted before the MOV except in load().
[Bug c++/107461] New: GCC rejects program with ambiguity error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Bug ID: 107461
Summary: GCC rejects program with ambiguity error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following well-formed program(afaik) is rejected by gcc but accepted by
clang and msbc. Demo: https://godbolt.org/z/bMWxd8bEa
```
#include
#include
#include
#include
#include
#include
#include
using namespace std;
#include
#include
#include
#include
namespace MLL{
template
class Matrix;//this forward declaration not needed but you can have
this if you want and if you do then make sure that you only provide the default
arg 256 in declaration and not in definition
//vvv>added
this default arg here instead of in forward declaration
template
class Matrix{
static constexpr bool IS_STATIC = n_rows * n_cols <= MAX;
using container_t = typename std::conditional, std::vector>::type;
container_t m_data_list;
public:
Matrix(){
if constexpr( !IS_STATIC ){
m_data_list.resize(n_rows * n_cols);
}
}
explicit Matrix(data_t default_value){
if constexpr( IS_STATIC ){
m_data_list.fill(default_value);
}else{
m_data_list.resize(n_rows * n_cols, default_value);
}
}
explicit Matrix(std::initializer_list&& value_list){
std::copy(value_list.begin(), value_list.end(),
m_data_list.begin());
}
Matrix(Matrix const& other)
: m_data_list(other.m_data_list){
}
Matrix(Matrix&& other) noexcept
: m_data_list(std::move(other.m_data_list)){
}
Matrix& operator=(Matrix const& other){
m_data_list = other.m_data_list;
return *this;
}
Matrix& operator=(Matrix&& other) noexcept{
m_data_list = std::move(other.m_data_list);
return *this;
}
//renamed all the arguments by prefexing them with OP for better
readibility
template
friend Matrix() + std::declval()),
n_rowst, n_colsOP, std::min(MAXOP, other_MAXOP)>
operator+(Matrix const& lhs,
Matrix const& rhs);
};
template
Matrix() + std::declval()), n_rowst,
n_colsOP, std::min(MAXOP, other_MAXOP)>
operator+(Matrix const& lhs,
Matrix const& rhs){
const std::size_t n = n_rowst * n_colsOP;
for( std::size_t i = 0; i < n; ++i ){
// lhs.m_data_list[i] += rhs.m_data_list[i]; //can't assing using
const lvalue reference
}
return lhs;
}
}
int main()
{
MLL::Matrix a({1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16});
a+a;
return 0;;
}
```
GCC rejects this with the error:
```
:82:6: error: ambiguous overload for 'operator+' (operand types are
'MLL::Matrix' and 'MLL::Matrix')
82 | a+a;
| ~^~
| | |
| | Matrix<[...],[...],[...]>
| Matrix<[...],[...],[...]>
:70:5: note: candidate: 'MLL::Matrix() +
declval())), n_rowst, n_colsOP, std::min(MAXOP,
other_MAXOP)> MLL::operator+(const Matrix&,
const Matrix&) [with data_tOP = int; TOP =
int; long unsigned int n_rowst = 4; long unsigned int n_colsOP = 4; long
unsigned int MAXOP = 256; long unsigned int other_MAXOP = 256; decltype
((declval() + declval())) = int]'
70 | operator+(Matrix const& lhs,
Matrix const& rhs){
| ^~~~
:65:5: note: candidate: 'MLL::Matrix() +
declval())), n_rowst, n_colsOP, std::min(MAXOP,
other_MAXOP)> MLL::operator+(const Matrix&,
const Matrix&) [with data_tOP = int; TOP =
int; long unsigned int n_rowst = 4; long unsigned int n_colsOP = 4; long
unsigned int MAXOP = 256; long unsigned int other_MAXOP = 256; data_t = int;
long unsigned int n_rows = 4; long unsigned int n_cols = 4; long unsigned int
MAX = 256; decltype ((declval() + declval())) = int]'
65 | operator+(Matrix const& lhs,
Matrix const& rhs);
| ^~~~
```
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #43 from Sergey Fedorov --- What is the current status of gccgo on Darwin?
[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460 --- Comment #1 from Chris MacGregor --- Created attachment 53794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53794=edit preprocessed source
[Bug c++/107460] New: ICE with "using enum" member passed to template function (g++ 11.x-13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460
Bug ID: 107460
Summary: ICE with "using enum" member passed to template
function (g++ 11.x-13)
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris-gcc-bugzilla at cybermato dot com
Target Milestone: ---
Created attachment 53793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53793=edit
file generated by -freport-bug
The following code (also attached) causes an ICE in tsubst_copy on every
version of g++ that can handle "using enum", with either -std=c++20 or
-std=gnu++20, regardless of -O0, -O1, -O2, etc.:
trunk (13.0.0 20221028) (Godbolt)
12.2.0 (Godbolt)
12.1.0 (Ubuntu 22.04)
11.3.0 (Godbolt)
11.2.0 (Ubuntu 22.04)
11.1(Ubuntu 20.04)
(10.4 and earlier don't seem to support "using enum")
clang 13, 14, and 15 compile it with no complaint, as does MSVC (19.33 per
Godbolt, plus VS 2019 and VS 2022).
If I pass 'EventCat::kEventCat_Min' to boundsCheck() instead of just
'kEventCat_Min', it compiles without error.
-
void fatal [[noreturn]] (const char * msg);
template
ToType boundsCheck(const FromType & value, const MinType & min)
{
if (int(value) >= int(min))
{
return static_cast(value);
}
fatal ("nope");
}
enum class EventCat
{
kEventCat_NeverUseThis = 0,
kUninitialized,
kTesting,
kEventCat_Min = kEventCat_NeverUseThis + 1,
};
struct Event
{
using enum EventCat;
Event(EventCat a_category, auto)
: category(a_category)
{
boundsCheck(a_category, kEventCat_Min); // using
"EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail
}
EventCat category = EventCat::kUninitialized;
};
void foo()
{
Event(EventCat::kTesting, 0);
}
-
On Ubuntu 22.04 using g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0:
$ g++-12 -c -std=c++20 g++-ice-in-tsubst_copy.cpp
g++-ice-in-tsubst_copy.cpp: In instantiation of ‘Event::Event(EventCat, auto:1)
[with auto:1 = int]’:
g++-ice-in-tsubst_copy.cpp:38:32: required from here
g++-ice-in-tsubst_copy.cpp:30:30: internal compiler error: in tsubst_copy, at
cp/pt.cc:16919
30 | boundsCheck(a_category, kEventCat_Min); // using
"EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail
| ~^~~
0x661b9b tsubst_copy
../../src/gcc/cp/pt.cc:16919
0x80f2ce tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:21399
0x81e961 tsubst_copy_and_build_call_args
../../src/gcc/cp/pt.cc:19937
0x80f8c0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:20687
0x8200e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:19491
0x821097 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x821097 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18504
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18833
0x821632 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x821632 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18476
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18833
0x81f63c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:26412
0x81f63c instantiate_body
../../src/gcc/cp/pt.cc:26412
0x81ff09 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.cc:26704
0x834bdb instantiate_pending_templates(int)
../../src/gcc/cp/pt.cc:26783
0x739197 c_parse_final_cleanups()
../../src/gcc/cp/decl2.cc:5128
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See for instructions.
