[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.
[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 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 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 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++/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 #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++/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] 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 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 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 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 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 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 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 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 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 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 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 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 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/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/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 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/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 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 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 (, 0, sizeof (tmp));
GFC_DTYPE_CLEAR();
tmp.base_addr = field;
unpack_internal (ret, vector, mask, , 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 (, 0, sizeof (tmp));
GFC_DTYPE_CLEAR();
tmp.base_addr = field;
int nvz=()->dim[0]._stride;
unpack_internal (ret, vector, mask, , 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.
