[Bug libfortran/99148] sanitizer detects stack-buffer-overflow in unpack_generic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99148 --- Comment #1 from Vittorio Zecca --- Reproduction of this issue requires an address sanitized version of libgfortran. I narrowed the issue to unpack0_char changing { gfc_array_char tmp; if (unlikely(compile_options.bounds_check)) unpack_bounds (ret, vector, mask, NULL); memset (&tmp, 0, sizeof (tmp)); GFC_DTYPE_CLEAR(&tmp); tmp.base_addr = field; unpack_internal (ret, vector, mask, &tmp, vector_length); into { gfc_array_char tmp; if (unlikely(compile_options.bounds_check)) unpack_bounds (ret, vector, mask, NULL); printf("sizeof(tmp)=%ld\n",sizeof(tmp));//vz memset (&tmp, 0, sizeof (tmp)); GFC_DTYPE_CLEAR(&tmp); tmp.base_addr = field; int nvz=(&tmp)->dim[0]._stride; unpack_internal (ret, vector, mask, &tmp, vector_length); I found sizeof(tmp)==40 and an address sanitizer error at the "int nvz" definition This is the execution output: LD_PRELOAD=~/libasan.so ./a.out sizeof(tmp)=40 = ==44953==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe78341c78 at pc 0x15270f525567 bp 0x7ffe78341bd0 sp 0x7ffe78341bc8 READ of size 8 at 0x7ffe78341c78 thread T0 #0 0x15270f525566 in _gfortran_unpack0_char ../../../gcc-150221/libgfortran/intrinsics/unpack_generic.c:630 #1 0x40139f in MAIN__ /home/vitti/f95/gfbug153.f:15 #2 0x40146d in main /home/vitti/f95/gfbug153.f:16 #3 0x15270eaa71e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1) #4 0x4010ad in _start (/home/vitti/1TB/f95/a.out+0x4010ad) Address 0x7ffe78341c78 is located in stack of thread T0 at offset 88 in frame #0 0x15270f5252a2 in _gfortran_unpack0_char ../../../gcc-150221/libgfortran/intrinsics/unpack_generic.c:620 This frame has 1 object(s): [48, 88) 'tmp' (line 621) <== Memory access at offset 88 overflows this variable I do not know if it is a false positive or a genuine bug. But I hope this helps if you cannot generate a sanitized version of libgfortran.
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #11 from Iain Sandoe --- (In reply to Andrew Pinski from comment #10) > From the ARM ARM: > An assembler program translating a Load/Store instruction, for example LDR, > is required to encode an unambiguous offset using the unscaled 9-bit offset > form, and to encode an ambiguous offset using the scaled 12-bit offset form. > A programmer might force the generation of the unscaled 9-bit form by using > one of the mnemonics in Table C3-17. Arm recommends that a disassembler > outputs all unscaled 9-bit offset forms using one of these mnemonics, but > unambiguous offsets can be output using a Load/Store single register > mnemonic, for example, LDR. it would be nice if that applied to a 'generic' version of the insn (one might read the advice as so): prf PLDL1KEEP, [x0, 200] ===> assembler chooses prfm/prfum as it likes prfm PLDL1KEEP, [x0, 200] --> use the insn I wrote! prfm PLDL1KEEP, [x0, -8] --> .. or error if I'm dumb prfum PLDL1KEEP, [x0, 200] --> use the insn I wrote! prfum PLDL1KEEP, [x0, 4096] --> .. or error if I'm dumb but I guess we have to live with the status quo.
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Dominique d'Humieres --- > Yes, please. Done
[Bug libfortran/99148] sanitizer detects stack-buffer-overflow in unpack_generic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99148 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug fortran/98573] Dynamic type lost on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98573 --- Comment #7 from Dominique d'Humieres --- A patch has been submitted at https://gcc.gnu.org/pipermail/fortran/2021-January/055624.html and approved at https://gcc.gnu.org/pipermail/fortran/2021-January/055644.html More comments at https://gcc.gnu.org/pipermail/fortran/2021-January/055651.html
[Bug fortran/99171] [10 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed on GCC10 and 11. With GCC9 the run time give When optional function is called without Open MP directive: Printing Something When optional function is called inside Open MP directive: Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something Printing Something
[Bug fortran/99171] [10/11 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Summary|[10 Regression] Optional|[10/11 Regression] Optional |procedure call inside Open |procedure call inside Open |MP parallel loop produces |MP parallel loop produces |Segmentation Fault |Segmentation Fault
[Bug fortran/96724] Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96724 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Dominique d'Humieres --- > Patch at https://gcc.gnu.org/pipermail/fortran/2020-August/054902.html. You should PING the gfortran and patches mailing lists? I hva the patch in my working directory without any problem.
[Bug sanitizer/99179] New: asan failures with -Os on x86_64-apple-darwin20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99179 Bug ID: 99179 Summary: asan failures with -Os on x86_64-apple-darwin20 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, iains 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: --- Host: x86_64-apple-darwin20 Target: x86_64-apple-darwin20 Build: x86_64-apple-darwin20 The following asan tests fail with -Os on x86_64-apple-darwin20 FAIL: c-c++-common/asan/alloca_big_alignment.c -Os output pattern test FAIL: c-c++-common/asan/alloca_detect_custom_size.c -Os output pattern test FAIL: c-c++-common/asan/alloca_overflow_partial.c -Os output pattern test FAIL: c-c++-common/asan/alloca_overflow_right.c -Os output pattern test FAIL: c-c++-common/asan/alloca_underflow_left.c -Os output pattern test With -Os the output is WRITE of size 1 at 0x7ffee72a5f8a thread T0 #0 0x108959dfc in foo(int, int) alloca_big_alignment.c:10 #1 0x108959e3b in main alloca_big_alignment.c:15 while it is WRITE of size 1 at 0x7ffeedd4ef8a thread T0 #0 0x101eb0def in foo(int, int) alloca_big_alignment.c:11 #1 0x101eb0e04 in main alloca_big_alignment.c:15 with the other options: alloca_big_alignment.c:10 versus alloca_big_alignment.c:11
[Bug c++/99180] New: ICE with alias template and empty parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99180 Bug ID: 99180 Summary: ICE with alias template and empty parameter pack Product: gcc Version: 11.0 URL: https://godbolt.org/z/qrGn34 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: szilardszaloki at gmail dot com Target Milestone: --- template struct A { A(Ts...) {} }; template using B = A; template using C = A; template A(Ts...) -> C; int main(int const, char const* const []) { B{}; return 0; }
[Bug libstdc++/99181] New: char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181 Bug ID: 99181 Summary: char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: richardpku at gmail dot com Target Milestone: --- Minimal program to produce bug (run it on a platform where char is a signed type, such as i386/x86-64): /tmp % cat a.cpp #include #include using namespace std; int main() { // constexpr constexpr bool i = ("\xff"sv > "aaa"sv); cout << i << ","; // not constexpr auto a = "\xff"sv, b = "aaa"sv; cout << (a > b) << endl; return 0; } /tmp % g++ -std=gnu++2a a.cpp && ./a.out 0,1 The expected result is "1,1". In a non-constexpr context, std::char_traits::compare invokes __builtin_memcmp, which is required by C standard to interpret characters as unsigned char. In a constexpr context, however, std::char_traits::compare invokes __gnu_cxx::char_traits::compare, which in turn calls __gnu_cxx::char_traits::lt to compare chars. __gnu_cxx::char_traits::lt (unlike std::char_traits::lt) is not specialized to compare chars as unsigned char.
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11. Closing. Thanks for the report!
[Bug c++/99182] New: Misleading fixit hint for misspelled Greek letter identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99182 Bug ID: 99182 Summary: Misleading fixit hint for misspelled Greek letter identifiers Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pilarlatiesa at gmail dot com Target Milestone: --- Fixit hints for UTF-8 identifiers do not work as nicely as for basic ascii set identifiers. $ cat borrar.c int main() { int const νt = 1; int const Δ = 1; return ν * Δ; } $ g++-10 borrar.c borrar.c: In function ‘int main()’: borrar.c:6:10: error: ‘ν’ was not declared in this scope; did you mean ‘Δ’? 6 | return ν * Δ; | ^ | $ g++-10 -v Using built-in specs. COLLECT_GCC=g++-10 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.2.0-5ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04)
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2021-02-20 --- Comment #12 from Iain Sandoe --- I added an issue to the experimental branch : https://github.com/iains/gcc-darwin-arm64/issues/43 And produced two patches to work around the issue (although the first should tighten up the constraint on prf*m for all targets). -- The first patch is a conservative fix, it just prevents the generation of pfrm insns when the offset is out of range (and when it would require pfrum for Darwin) https://github.com/iains/gcc-darwin-arm64/commit/2fbd9a7f9cddc7e243c0025713841e0bc1465c41 The second patch adds predicate, constraint and patterns for the prfum insn, which means that Darwin now generates: prfum [X0, -8] which is accepted by the LLVM backend, https://github.com/iains/gcc-darwin-arm64/commit/881a59f2258a5a7a9c2c862420c4e93e9df17f2c Given some more time, I expect that the two could be combined in some way; at least unless/until LLVM gets a fix and that percolates through to Xcode. So the bug is "fixed on the experimental branch". Given that it cannot be fixed on GCC 'upstream' until we have a chance to submit the port (which isn't ready yet!) .. I suggest that "SUSPEND" is a reasonable state for this bug.
[Bug fortran/99027] Incorrect ubound result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99027 Andrew Burgess changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Burgess --- Can confirm that with latest GCC HEAD I am now seeing the results that I expect. Thanks for the quick fix.
[Bug fortran/99183] New: Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 Bug ID: 99183 Summary: Incompatible Runtime types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: drikosev at gmail dot com Target Milestone: --- Having post a question in c.l.f I was informed that the program below is invalid but gfortran accepts it (several versions). This is the question: https://groups.google.com/g/comp.lang.fortran/c/jWHX3kJMeYY/m/4IMgy19hDgAJ Hope it isn't a duplicate! $ gfortran8 dream-casting.f90 && ./a.out allocatedx = d1(ind=1,i=1) allocatedv = d2(ind=2,j=2) assigned v = x, now v%ind= 1 j= 1 $ cat dream-casting.f90 program test implicit none type :: d0 integer :: ind end type d0 type, extends(d0) :: d1 integer :: i end type d1 type, extends(d0) :: d2 integer :: j end type d2 class(d1), allocatable :: x class(d2), allocatable :: v allocate ( x ,source = d1(1,1)) print *, "allocatedx = d1(ind=1,i=1)" allocate ( v ,source = d2(2,2)) print *, "allocatedv = d2(ind=2,j=2)" v = x print *, "assigned v = x, now v%ind=", v%ind, "j=", v%j end program test
[Bug sanitizer/99179] asan failures with -Os on x86_64-apple-darwin20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99179 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-20 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- So - it's some mismatch in the debug output / consumption I guess. If I re-run the tests using the llvm-symbolizer from LLVM-11 (so at the same revision as the imported libsanitizer), then the -Os cases pass. NOTE: GCC emits the ELF ABI for Darwin (the Mach-O ABI was not implemented by when the sanitizer was added, and it's Yet Another thing on the TODO to fix that). so it could be that the system tool (atos) is expecting Mach-o ABI but the llvm-symbolizer is more tolerant.
[Bug target/99184] New: [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99184 Bug ID: 99184 Summary: [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: avr at gjlay dot de Target Milestone: --- Casting from double to 32-bit and 16-bit integers incorrectly rounds to nearest.
[Bug c++/99185] New: asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185 Bug ID: 99185 Summary: asan initialization-order-fiasco false positive Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kal.conley at dectris dot com Target Milestone: --- The default constructor does not initialize primitive types. a.cc: = struct A { int value; A() = default; }; A g; b.cc: = struct A { int value; A() = default; }; extern A g; int b = []() { g.value = 1; return 0; }(); int main() { return 0; } $ g++ -fsanitize=address -std=c++20 a.cc b.cc; ./a.out = ==3844820==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x00404160 at pc 0x004013c6 bp 0x7fff2371ecc0 sp 0x7fff2371ecb0 WRITE of size 4 at 0x00404160 thread T0 #0 0x4013c5 in b::{lambda()#1}::operator()() const (/home/kal/work/cxx/a.out+0x4013c5) #1 0x4012a8 in __static_initialization_and_destruction_0(int, int) (/home/kal/work/cxx/a.out+0x4012a8) #2 0x40134b in _GLOBAL__sub_I_b (/home/kal/work/cxx/a.out+0x40134b) #3 0x40142c in __libc_csu_init (/home/kal/work/cxx/a.out+0x40142c) #4 0x7f43cfb8b00d in __libc_start_main (/lib64/libc.so.6+0x2700d) #5 0x4010dd in _start (/home/kal/work/cxx/a.out+0x4010dd) 0x00404160 is located 0 bytes inside of global variable 'g' defined in 'a.cc:5:3' (0x404160) of size 4 registered at: #0 0x7f43d00b5cc8 (/lib64/libasan.so.6+0x37cc8) #1 0x401202 in _sub_I_00099_1 (/home/kal/work/cxx/a.out+0x401202) #2 0x40142c in __libc_csu_init (/home/kal/work/cxx/a.out+0x40142c) SUMMARY: AddressSanitizer: initialization-order-fiasco (/home/kal/work/cxx/a.out+0x4013c5) in b::{lambda()#1}::operator()() const Shadow bytes around the buggy address: 0x800787d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x800787e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078810: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 =>0x80078820: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00[f6]f6 f6 f6 0x80078830: f6 f6 f6 f6 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 0x80078840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==3844820==ABORTING
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185 --- Comment #1 from kal.conley at dectris dot com --- Strict init-order checking is enabled.
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185 --- Comment #2 from Andrew Pinski --- I think the error is correct. There is no defined ordering of globalstar between translation units. Can you explain why you think the ordering is defined here?
[Bug c++/99059] Static inline variable can't refer to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059 --- Comment #2 from Luke Dalessandro --- Ran into this in a static constexpr initializer, not really a workaround for it that I can find.
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185 --- Comment #3 from kal.conley at dectris dot com --- I don't think there should be any dynamic initialization of A here. Also, its weird that if the definition if A is changed to: struct A { int value = 0; A() = default; }; then the error goes away.
[Bug c++/99186] New: std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186 Bug ID: 99186 Summary: std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: huili80 at gmail dot com Target Milestone: --- Example code below: #include #include enum class E1 {a}; enum class E2 {b,c}; template < auto > struct S { int i; }; static_assert(not std::is_same_v,S>); struct D : S, S {}; int main() { D d; d.S::i = 0; std::tuple,S,S> x; std::get<0>(x).i = 0; std::get>(x).i = 0; std::get>(x).i = 0; // does not compile return 0; } GCC 10.2 c++17 gives the following error: In file included from main.cpp:2: /usr/local/include/c++/10.2.0/tuple: In instantiation of 'constexpr _Tp& std::get(std::tuple<_UTypes ...>&) [with _Tp = S _Types = {S, S, S}]': main.cpp:27:24: required from here /usr/local/include/c++/10.2.0/tuple:1339:37: error: no matching function for call to '__get_helper2 >(std::tuple, S, S >&)' 1339 | { return std::__get_helper2<_Tp>(__t); } | ~~~^ /usr/local/include/c++/10.2.0/tuple:1327:5: note: candidate: 'template constexpr _Head& std::__get_helper2(std::_Tuple_impl<__i, _Head, _Tail ...>&)' 1327 | __get_helper2(_Tuple_impl<__i, _Head, _Tail...>& __t) noexcept | ^ /usr/local/include/c++/10.2.0/tuple:1327:5: note: template argument deduction/substitution failed: /usr/local/include/c++/10.2.0/tuple:1339:37: note: 'std::_Tuple_impl<__i, S, _Tail ...>' is an ambiguous base class of 'std::tuple, S, S >' 1339 | { return std::__get_helper2<_Tp>(__t); } | ~~~^ /usr/local/include/c++/10.2.0/tuple:1332:5: note: candidate: 'template constexpr const _Head& std::__get_helper2(const std::_Tuple_impl<__i, _Head, _Tail ...>&)' 1332 | __get_helper2(const _Tuple_impl<__i, _Head, _Tail...>& __t) noexcept | ^ /usr/local/include/c++/10.2.0/tuple:1332:5: note: template argument deduction/substitution failed: /usr/local/include/c++/10.2.0/tuple:1339:37: note: 'const std::_Tuple_impl<__i, S, _Tail ...>' is an ambiguous base class of 'std::tuple, S, S >' 1339 | { return std::__get_helper2<_Tp>(__t); } | ~~~^ Output: If E1 and E2 had been non-scoped enums, the code results in the same compiler error. It's curious that the error mentions ambiguous base classes in std::tuple's implementation. Given that std::get>(x) compiles fine, I speculated that the compiler may have incorrectly thought that S and S are the same type since E1::a and E2::b have the same numeric value (zero). However, that speculation is proven wrong by other parts of the example code clearly shows that the compiler does NOT think S and S are the same type, e.g., the static_assert that S and S are not the same type, and that even though struct D inherits from both S, S, we can access its base S's member variable.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #10 from Vittorio Zecca --- This issue seems to have been resolved in the trunk gfortran 11.0.0 gfortran gfbug109.f -fcheck=pointer -g [vitti f95]$./a.out At line 9 of file gfbug109.f Fortran runtime error: Allocatable argument 'aa' is not allocated Error termination. Backtrace: #0 0x1458cf822d74 in ??? #1 0x1458cf823849 in ??? #2 0x1458cf823e5a in ??? #3 0x401b94 in MAIN__ at /home/vitti/f95/gfbug109.f:9 #4 0x401eb1 in main at /home/vitti/f95/gfbug109.f:11
[Bug middle-end/61158] negative shift at fold-const.c:12095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158 Vittorio Zecca changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Vittorio Zecca --- Resolved.
[Bug middle-end/67485] expmed.c sanitizer detects overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67485 Vittorio Zecca changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Vittorio Zecca --- Resolved.