[Bug target/113960] [11 Regression] std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960 --- Comment #20 from mfarca --- Thank you for your help Jonathan.
[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960 --- Comment #13 from mfarca --- Would you please backport this to 12 when the patch lands?
[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960 --- Comment #12 from mfarca --- I've applied the above patch directly to `/usr/include/c++/12/bits/stl_algobase.h` under my fedora 36 env with gcc 12.2.1 and it solved the problem.
[Bug c++/113960] New: std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Bug ID: 113960
Summary: std::map with std::vector as input overwrites itself
with c++20, on s390x platform
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miladfarca at gmail dot com
Target Milestone: ---
Host: s390x
Target: s390x
```
#include
#include
#include
int main(){
std::vector v1 = {1};
std::vector v2 = {2};
std::map, int> m;
m[v1] = 1;
m[v2] = 2; // this overwrites m[v1]
std::cout << m.size() << std::endl; // prints 1, should be 2
return 0;
}
```
Compile with `g++ std=c++20`. Output is correct with c++17. Tested on g++
12.2.1 and g++ 13.2.1
[Bug c++/109091] New: AIX: thread_local is not being internally linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109091
Bug ID: 109091
Summary: AIX: thread_local is not being internally linked
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miladfarca at gmail dot com
Target Milestone: ---
Sample:
0.cc
```
void check();
namespace {
thread_local int num = 0;
}
int main(){
num = 5;
check();
return 0;
}
```
1.cc
```
#include
namespace {
thread_local int num = 0;
}
void check(){
std::cout << num << std::endl;
}
```
Compile with g++ -lpthread 0.cc 1.cc and run.
Expected output: 0
Output on AIX: 5
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 --- Comment #4 from mfarca --- Thanks for creating the issue for improving documentation. Could you then clarify if call to the incorrect address is a bug or not? instructions are allowed to be under `.rodata` section as this section is still executable and works fine on x64, more on this: https://stackoverflow.com/a/44938843
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 --- Comment #2 from mfarca --- > Toplevel inline-asm will be emitted without any knowledge of the current > section. So this is a limitation of gcc I guess? as clang does have the knowledge on which is which. The main issue still persists as call is made to the wrong address.
[Bug c/107736] New: call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Bug ID: 107736
Summary: call to a function, generated by inline asm, is off by
one byte
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: miladfarca at gmail dot com
Target Milestone: ---
Tested on Arm64, PPC64 and s390x with gcc 12.
```
const char num = 0;
void call();
asm( ".globl call\n"
".type call, %function \n"
".hidden call \n"
"call: \n"
// Just return.
"ret\n");
int main(){
call();
return 0;
}
```
TL;DR:
The instruction generated for `call();` is jumping to the address of `num` and
causing a crash as `num` is not an instruction, seems to be an alignment issue?
Details:
- This doesn't happen on x64 and call is made to the correct address. It also
does not happen with clang on either platforms (tested with version 6.0).
- gcc is putting "call" into .rodata section of memory including on x64. Not
sure if this is a separate bug or intentional. clang is putting it under
".text" as expected.
- gcc is incorrectly assuming `` is the address of `call` and jumping to it
which is off by 1 byte.
- Workarounds include adding either ".text \n" or ".align 8" to the inline asm,
tho call should be made to the correct address even without them?
[Bug libstdc++/102531] New: std::hash does not work correctly on Big Endian platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102531
Bug ID: 102531
Summary: std::hash does not work correctly on Big Endian
platforms
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: miladfarca at gmail dot com
Target Milestone: ---
std::hash does not work correctly on BE machines using the following key types:
- std::hash
- std::hash>
They both break the 5th rule, a large number of inputs will end up having the
same hash:
https://en.cppreference.com/w/cpp/utility/hash
### std::bitset
```
#include
#include
#include
int main(){
std::bitset<2> a(0b01);
std::bitset<2> b(0b10);
std::size_t h1 = std::hash>{}(a);
std::size_t h2 = std::hash>{}(b);
std::cout << h1 << std::endl;
std::cout << h2 << std::endl;
return 0;
```
Output will be the same on BE machines.
The input length calculation is done incorrectly here:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/bitset#L1575
`bitset` writes 0 extended size_t sized values into memory. Reading smaller
lengths might return 0 as bytes are not reversed on BE.
### std::vector
```
#include
#include
#include
int main(){
std::vector a= {static_cast(1), static_cast(2)};
std::vector b= {static_cast(1), static_cast(2),
static_cast(3)};
std::size_t h1 = std::hash>{}(a);
std::size_t h2 = std::hash>{}(b);
std::cout << h1 << std::endl;
std::cout << h2 << std::endl;
return 0;
}
```
Similar issue as bitset. vector writes size_t sized values into memory.
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/vector.tcc#L987
The calculated length in the above link might be smaller than the input and
only 0s will get returned as bytes are not reversed on BE.
