[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #7 from Yuxuan Shui --- Looks similar to Bug 110027, but ASAN is not involved here.
[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #5 from Yuxuan Shui --- And -fstack-protector-strong is needed.
[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #4 from Yuxuan Shui ---
Reduced a bit further:
void setup_tone_curves(float binHz, float center_decay_rate) {
float workc[8][56];
memset(workc, 0, sizeof(workc));
for (int j = 0; j < 8; j++) {
for (int k = 0; k < 56; k++) {
float adj = k * center_decay_rate;
if (adj < 0.)
adj = 0.;
if (adj > 0.)
adj = 0.;
workc[j][k] += adj;
}
}
int lo_curve = log(binHz);
}
Some observations:
1. lo_curve, although dead code, triggers the bug.
2. the 2 if's in the loop are also required for this bug.
3. workc has to be initialized with memset, aggregate initializer doesn't
trigger the bug.
[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #3 from Yuxuan Shui ---
Roughly reduced example:
#include
#include
#define toOC(n) (log(n)*1.442695f-5.965784f)
float *setup_tone_curves(float binHz,
float center_decay_rate) {
float workc[8][56];
float *ret = NULL;
memset(workc, 0, sizeof(workc));
for (int j = 0; j < 8; j++) {
for (int k = 0; k < 56; k++) {
float adj = k * center_decay_rate;
if (adj < 0.)
adj = 0.;
if (adj > 0.)
adj = 0.;
workc[j][k] += adj;
}
}
int lo_curve, bin = 0;
lo_curve = ceil(toOC(bin * binHz + 1) * 2);
return (ret);
}
int main() {
setup_tone_curves(86.1328125, 0.625001);
return 0;
}
[Bug target/114566] Misaligned vmovaps when compiling libvorbis for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #2 from Yuxuan Shui --- /nix/store/qp3k692bxjhlzvsdqpq7mdylfyr7i1ln-gcc-wrapper-13.2.0/bin/gcc -I/tmp/vorbis/include -I/tmp/vorbis/lib -O3 -march=znver4 -mtune=znver4 -g -o psy.c.o -c /tmp/vorbis/lib/psy.c -v Using built-in specs. COLLECT_GCC=/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/bin/gcc Target: x86_64-unknown-linux-gnu Configured with: ../gcc-13.2.0/configure --prefix=/nix/store/-gcc-13.2.0 --with-gmp-include=/nix/store/-gmp-6.3.0-dev/include --with-gmp-lib=/nix/store/-gmp-6.3.0/lib --with-mpfr-include=/nix/store/-mpfr-4.2.1-dev/include --with-mpfr-lib=/nix/store/-mpfr-4.2.1/lib --with-mpc=/nix/store/-libmpc-1.3.1 --with-native-system-header-dir=/nix/store/-glibc-2.38-44-dev/include --with-build-sysroot=/ --with-gxx-include-dir=/nix/store/-gcc-13.2.0/include/c++/13.2.0/ --program-prefix= --enable-lto --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin --disable-libcc1 --with-isl=/nix/store/-isl-0.20 --disable-bootstrap --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-fPIC' '-O2' '-U' '_FORTIFY_SOURCE' '-Wformat=1' '-Wformat-security' '-Werror=format-security' '-fstack-protector-strong' '--param=ssp-buffer-size=4' '-fno-strict-overflow' '-I' '/tmp/vorbis/include' '-I' '/tmp/vorbis/lib' '-O3' '-march=znver4' '-mtune=znver4' '-g' '-o' 'psy.c.o' '-c' '-v' '-U' '_FORTIFY_SOURCE' '-D' '_FORTIFY_SOURCE=3' '-B' '/nix/store/bzjyfnr8g585gvxjgiabn28qdm32b02n-glibc-2.38-44/lib/' '-idirafter' '/nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include' '-idirafter' '/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed' '-B' '/nix/store/7ngrcd0a7q460gyg8grx6pipwzpgy0vq-gcc-13.2.0-lib/lib' '-B' '/nix/store/qp3k692bxjhlzvsdqpq7mdylfyr7i1ln-gcc-wrapper-13.2.0/bin/' '-frandom-seed=wbmyj7xk8s' '-isystem' '/nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include' '-isystem' '/nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include' /nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/libexec/gcc/x86_64-unknown-linux-gnu/13.2.0/cc1 -quiet -v -I /tmp/vorbis/include -I /tmp/vorbis/lib -U _FORTIFY_SOURCE -U _FORTIFY_SOURCE -D _FORTIFY_SOURCE=3 -idirafter /nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include -idirafter /nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed -isystem /nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include -isystem /nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include /tmp/vorbis/lib/psy.c -quiet -dumpbase psy.c.c -dumpbase-ext .c -march=znver4 -mtune=znver4 -g -O2 -O3 -Wformat=1 -Wformat-security -Werror=format-security -version -fPIC -fstack-protector-strong -fno-strict-overflow -frandom-seed=wbmyj7xk8s --param=ssp-buffer-size=4 -o /tmp/nix-shell.Yn7YW0/ccu1mT2u.s GNU C17 (GCC) version 13.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "/nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include" ignoring nonexistent directory "/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../x86_64-unknown-linux-gnu/include" ignoring duplicate directory "/nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include" ignoring duplicate directory "/nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed" #include "..." search starts here: #include <...> search starts here: /tmp/vorbis/include /tmp/vorbis/lib /nix/store/5zr21xnk4h8pdi1s8n20y31y1x5hn8i0-libogg-1.3.5-dev/include /nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include /nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/include /nix/store/iwwfrvi5b20irhl0vz8zdqzjf5i7vil2-gcc-13.2.0/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed /nix/store/j79rphhc2vmb7rrxvx0aymhkw8bpkckf-glibc-2.38-44-dev/include End of search list. Compiler executable checksum: b33e0c81578694d9e35e19d87dacd083 COLLECT_GCC_OPTIONS='-fPIC' '-O2' '-U' '_FORTIFY_SOURCE' '-Wformat=1' '-Wformat-security' '-Werror=format-security' '-fstack-protector-strong' '--param=ssp-buffer-size=4'
[Bug c/114566] New: Misaligned vmovaps when compiling libvorbis for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 Bug ID: 114566 Summary: Misaligned vmovaps when compiling libvorbis for znver4 Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yshuiv7 at gmail dot com Target Milestone: --- Haven't tried to minimize it yet, but here is how to reproduce it: 1. Download libvorbis 1.3.7 source: https://github.com/xiph/vorbis/tree/v1.3.7 2. Configure it: cmake -B build -DCMAKE_C_FLAGS="-march=znver4 -mtune=znver4" -DCMAKE_CXX_FLAGS="-march=znver4 -mtune=znver4" -DCMAKE_BUILD_TYPE=Release . 3. Run tests: make -C build test Stack trace: #0 0x00410d2e in setup_tone_curves (curveatt_dB=curveatt_dB@entry=0x4e1834, binHz=binHz@entry=86.1328125, n=n@entry=256, center_boost=-1.0203, center_decay_rate=) at /tmp/vorbis/lib/psy.c:129 #1 0x00413b24 in _vp_psy_init (p=0x4fe8c0, vi=, gi=gi@entry=0x4e0be0, n=256, rate=) at /tmp/vorbis/lib/psy.c:326 #2 0x0040a7b5 in _vds_shared_init (v=v@entry=0x7fffb370, vi=vi@entry=0x7fffb330, encp=encp@entry=1) at /tmp/vorbis/lib/block.c:225 #3 0x0040a93f in vorbis_analysis_init (v=v@entry=0x7fffb370, vi=vi@entry=0x7fffb330) at /tmp/vorbis/lib/block.c:298 #4 0x00404ad2 in write_vorbis_data_or_die ( filename=filename@entry=0x7fffb700 "vorbis_1ch_q-0.5_44100.ogg", srate=srate@entry=44100, q=q@entry=-0.050007, data=data@entry=0x4dc080 , count=count@entry=2048, ch=ch@entry=1) at /tmp/vorbis/test/write_read.c:61 #5 0x0040456d in main () at /tmp/vorbis/test/test.c:58 Relevant part of the code: 0x00410cee <+1854>: add$0xe0,%rdx 0x00410cf5 <+1861>: vmovups %zmm17,-0xe0(%rdx) 0x00410cff <+1871>: vaddps -0xa0(%rdx),%zmm7,%zmm17 0x00410d09 <+1881>: vmovups %zmm17,-0xa0(%rdx) 0x00410d13 <+1891>: vaddps -0x60(%rdx),%zmm6,%zmm17 0x00410d1d <+1901>: vmovups %zmm17,-0x60(%rdx) 0x00410d27 <+1911>: vaddps -0x20(%rdx),%ymm0,%ymm17 => 0x00410d2e <+1918>: vmovaps %ymm17,-0x20(%rdx) $rdx is 0x7fff3a10
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 --- Comment #18 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #17) > (In reply to Yuxuan Shui from comment #16) > > ... > > So -fno-strict-overflow does -fno-wrapv-pointer so we can assume pointer > arithmetic wraps now and then `a+1` could in theory wrap to nullptr. hmm, but why does that make the null check that previously was not removable, removable? also another observation, if I change `struct obj *dso` to `int *dso`, and `>i` to `[1]`, then the null check will be preserved. despite this code still being undefined?
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 --- Comment #16 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #13) > (In reply to Yuxuan Shui from comment #12) >> ... > > Except that is undefined ... > Manually unswitching introduces the undefined behavior in the code. > So even though the code was unswitched before GCC 13 incorrectly, GCC didn't > take into that account before hand. > > I am 99% sure what is happening is GCC is see `if (a+1)` and then assuming a > can't be a nullptr. Which is due to undefinedness there of adding 1 to an > null ptr ... (for C that is). > > Basically the unswitch is the issue ... Or we maybe we should turn `if > (a+1)` into just `if (a)` ... Likewise for `if (>i)` into `if (a)` I see. but if it's undefined, why was the `if (dso)` only removed when -fno-strict-overflow is enabled? and it still happens with `-fno-delete-null-pointer-checks`
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #15 from Yuxuan Shui ---
(In reply to Marek Polacek from comment #14)
> I don't see a complete testcase that I could bisect.
Please use the code sample in the original comment. since there are questions
that the manually unswitched version is undefined.
link that code with this:
#include
struct obj {
int __pad;
int i;
};
/* aborts when called with NULL */
int assert_not_null(void *n) {
if (!n)
abort();
}
void bug(struct obj **root, struct obj *dso);
int main() {
struct obj x = {};
struct obj *y =
bug(y, NULL);
}
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #12 from Yuxuan Shui ---
I think this is the MRE:
void bug(struct obj *dso) {
if (>i) {
if (dso == (void *)0)
return;
assert_not_null(dso);
}
}
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #11 from Yuxuan Shui ---
reduced it a bit:
void bug(struct obj **root, struct obj *dso) {
if (>i) {
while (1) {
struct obj *this = *root;
if (dso == (void *)0)
// should return here
return;
if (dso == this)
return;
// shouldn't reach here
assert_not_null(dso);
}
}
}
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 --- Comment #10 from Yuxuan Shui --- the manually unswitched version can probably be reduced further.
[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
Yuxuan Shui changed:
What|Removed |Added
Summary|[13 Regression] |[13 Regression]
|Miscompilation with -O1 |Miscompilation with -O1
|-funswitch-loops|-fno-strict-overflow
|-fno-strict-overflow|
--- Comment #9 from Yuxuan Shui ---
So, to add some details to people said above, and to make sure I understood
this correctly.
What gcc did here is:
1. move the `if (!>i)` branch out of the loop, duplicate the loop for the
then/else branches.
2. `>i` cannot be 0, so the else branch is eliminated.
3. in the then branch, this condition confused the compiler. it thought since
`>i` is not 0, `dso` is not 0 either, causing the bug.
I diffed `-fdump` outputs and it does match what I expected to see.
(minus is the correct one, plus the incorrect)
@@ -2686,7 +2686,11 @@
;; 4 succs { 5 6 }
;; 6 succs { 3 }
;; 5 succs { 1 }
-Removing basic block 6
+Folding predicate _1 == 0B to 0
+Exported global range table:
+
+_1 : [irange] int * [1, +INF]
+Merging blocks 4 and 6
* * *
this made me think whether loop unswitching is actually relevant here. since
12.3 also unswitches this loop, but doesn't miscompile. so I manually
unswitched the loop:
void bug(struct obj **root, struct obj *dso) {
if (!>i) {
while (1) {
struct obj *this = *root;
if (dso == (void *)0)
// should return here
return;
if (dso == this)
return;
// shouldn't reach here
assert_not_null(dso);
break;
}
} else {
while (1) {
struct obj *this = *root;
if (dso == (void *)0)
// should return here
return;
if (dso == this)
return;
// shouldn't reach here
assert_not_null(dso);
}
}
}
and now the miscompile happens without -funswitch-loops. I wonder if this
happens on trunk as well.
looks this this is a -fno-strict-overflow related ranger bug.
[Bug rtl-optimization/113551] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 --- Comment #2 from Yuxuan Shui --- regression from 12.3 -> 13.2
[Bug rtl-optimization/113551] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551 --- Comment #1 from Yuxuan Shui --- code is reduced from perf, source file util/dsos.c
[Bug rtl-optimization/113551] New: Miscompilation with -O1 -funswitch-loops -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
Bug ID: 113551
Summary: Miscompilation with -O1 -funswitch-loops
-fno-strict-overflow
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yshuiv7 at gmail dot com
Target Milestone: ---
Code:
struct obj {
int __pad;
int i;
};
/* aborts when called with NULL */
int assert_not_null(void *);
void bug(struct obj **root, struct obj *dso) {
while (1) {
struct obj *this = *root;
if (dso == (void *)0)
// should return here
return;
if (dso == this)
return;
// shouldn't reach here
assert_not_null(dso);
if (!>i)
break;
}
}
// call like this: bug(, NULL);
Result:
* -O1: ok
* -O1 -funswitch-loops: ok
* -O1 -fno-strict-overflow: ok
* -O1 -funswitch-loops -fno-strict-overflow: abort
[Bug libgcc/106674] New: Potential for symbol conflicts between libgcc_s and libunwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106674 Bug ID: 106674 Summary: Potential for symbol conflicts between libgcc_s and libunwind Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: yshuiv7 at gmail dot com Target Milestone: --- libunwind and ligcc_s provides the same set of symbols, if an application depends on both, then in very specific scenarios, conflicts can happen. I hit the problem when running C++ code built by wineg++. When an exception is thrown, libgcc_s' _Unwind_RaiseException somehow calls into libunwind's _Unwind_GetCFA, and got garbage. I don't know exactly how this happens. Arch Linux does this to libunwind: https://github.com/archlinux/svntogit-packages/blob/bd8ecd47e91dbb2cf77f82ca3a5a94ef1263eb31/trunk/PKGBUILD#L26 I don't know if that is to fix this problem in specific, but it does make the problem go away.
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #16 from Yuxuan Shui --- But yeah, that's definitely a bug in itself as well.
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #15 from Yuxuan Shui --- (In reply to Jonathan Wakely from comment #13) > (In reply to Yuxuan Shui from comment #1) > > Example: > > > > This program normally deadlocks when using linked pthread: > > > > https://godbolt.org/z/Yrza4e > > > > But it will throw recursive_init_error when using dlopen'd pthread: > > > > https://godbolt.org/z/afMe5d > > I'm not sure what these examples are very helpful. Throwing > recursive_init_error is the correct behaviour here, it's a bug that we fail > to detect the recursion when it happens in the same thread. This is just to demonstrate the difference in the behavior. It's easy to imagine this happen in a legitimate use case (and we indeed have one).
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #9 from Yuxuan Shui --- (In reply to Jonathan Wakely from comment #7) > It will work when Glibc defines all the pthread functions in libc.so and > libpthread.so becomes empty. Won't that mean libstdc++ will always use the thread-safe behavior? If that's the goal, why don't we just remove the __gthread_active_p check?
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #6 from Yuxuan Shui --- I meant to say "Is there anything ... can do, to improve the situation?"
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #5 from Yuxuan Shui --- (In reply to Richard Biener from comment #4) > it's been always that way - but yes, people repeatedly fall into this trap If there anything libstdc++, or maybe the middle man (Mesa in my case) can do, to improve the situation. Maybe if there is an API Mesa can call to "refresh" libstdc++'s memory about pthread?
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #3 from Yuxuan Shui --- (In reply to Jonathan Wakely from comment #2) > Dynamically loading libpthread breaks everything in libstdc++, it just isn't > supported. But it has real use cases, e.g. writing a C++ OpenGL program that doesn't use thread itself. This is such an easy hole for the end user to fall into. How would they know that they have to link against pthread even though their program doesn't use any threading?
[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 --- Comment #1 from Yuxuan Shui --- Example: This program normally deadlocks when using linked pthread: https://godbolt.org/z/Yrza4e But it will throw recursive_init_error when using dlopen'd pthread: https://godbolt.org/z/afMe5d
[Bug libstdc++/96817] New: __cxa_guard_acquire unsafe against dynamically loaded pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817 Bug ID: 96817 Summary: __cxa_guard_acquire unsafe against dynamically loaded pthread Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: yshuiv7 at gmail dot com Target Milestone: --- If pthread is loaded dynamically via dlopen() after libstdc++ is loaded, __gthread_active_p() would return wrong result, cause guard acquire to be thread unsafe. An example of this problem: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3199
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #22 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #21) > >Your suggestion is just a workaround as well, as it avoided using the ABS > >symbol. > > ABS symbols are invalid in PIE mode. That is my point. Well if that's the case, can you point me to something (Specs, standards, etc.) that says ABS symbols are not allowed in PIE? Otherwise it's just your words.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #20 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #18) > (In reply to Yuxuan Shui from comment #17) > > Sorry, I am here to report a bug, not to find a workaround for my use case. > > I gave you the correct usage for your use case. If you don't like it is not > my fault. Can you please point me to something that shows me I am wrong? Your suggestion is just a workaround as well, as it avoided using the ABS symbol.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|UNCONFIRMED --- Comment #19 from Yuxuan Shui --- comment #8 claims C variables cannot refer to ABS symbols without substantiate that claim. comment #9 suggests a change that is just wrong. Reopening as previous WONTFIX/WORKSFORME resolutions are not valid.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #17 from Yuxuan Shui ---
(In reply to H.J. Lu from comment #16)
> (In reply to Yuxuan Shui from comment #15)
> > Your code is going to dereference the value stored in the ABS symbol as an
> > address (e.g. if the symbol has value 10, your code will access (*(char
> > *)10), barring the unwanted relocation), which is not the intention here.
>
> This works in all cases:
>
> unsigned long
> size2 (void)
> {
> return ((unsigned long) &_binary_a_c_end
> - (unsigned long) &_binary_a_c_start);
> }
Sorry, I am here to report a bug, not to find a workaround for my use case.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #15 from Yuxuan Shui --- (In reply to H.J. Lu from comment #12) > (In reply to Yuxuan Shui from comment #11) > > (In reply to Andrew Pinski from comment #8) > > > Also it is wrong for a person to assume a normal C variable could be > > > SHN_ABS; that is the bug here. It is a bug in the user code. > > > I showed up to fix it by using an top level inline-asm. > > > > Why is this wrong? Is it written down somewhere that a C variable can never > > be SHN_ABS, perhaps in the standard, or in the X86-psABI? > > > > If this is wrong, then what is the correct way to access a SHN_ABS symbol? > > Is it just no way to do it? If so, what's the purpose of objcopy generating > > such symbols? > > Have you tried my way with ld? Lld bug is a different issue. Your code is going to dereference the value stored in the ABS symbol as an address (e.g. if the symbol has value 10, your code will access (*(char *)10), barring the unwanted relocation), which is not the intention here.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #11 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #8) > Also it is wrong for a person to assume a normal C variable could be > SHN_ABS; that is the bug here. It is a bug in the user code. > I showed up to fix it by using an top level inline-asm. Why is this wrong? Is it written down somewhere that a C variable can never be SHN_ABS, perhaps in the standard, or in the X86-psABI? If this is wrong, then what is the correct way to access a SHN_ABS symbol? Is it just no way to do it? If so, what's the purpose of objcopy generating such symbols?
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Yuxuan Shui --- If you read the reply, you will find out that is not the same bug as this: > This is an over reduction. The real problem is that we are not tracking > absoluteness correctly. In the original case vvar_vsyscall_gtod_data > should not be absolute > > --- ELF/Relocations.cpp > > +++ ELF/Relocations.cpp > > @@ -356,6 +356,10 @@ > >return true; > > if ( == ElfSym::MipsGpDisp) > >return true; > > +// Sometimes code has relocations to absolute symbol defined in linker > > script. > > +// Example is linux kernel. Hence we allow it. > > +if (!Body.File) > > + return true; > We should not do this. It would accept broken cases too.
[Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Bug ID: 94391
Summary: gcc refers to absolute symbols with R_X86_64_PC32
relocation
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yshuiv7 at gmail dot com
Target Milestone: ---
Test case:
Source file (a.c):
extern char _binary_a_c_size[];
unsigned long foo() { return (unsigned long)_binary_a_c_size; }
Run:
objcopy -B i386:x86-64 -I binary -O elf64-x86-64 a.c b.o
gcc -fuse-ld=lld -fpie -pie a.c b.o
lld complains about:
ld.lld: error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
_binary_a_c_size
>>> defined in b.o
>>> referenced by a.c
>>> /tmp/cc3iReeC.o:(foo)
Also, this seems to be more than just a problem in gcc. Doing the same test
with clang+lld yields the expected results. However, with clang+gold/bfd, the
absolute symbol is relocated.
[Bug target/87421] GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421 Yuxuan Shui changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Yuxuan Shui --- Sorry, you are totally right. I misunderstood the ABI definition.
[Bug target/87421] GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421 --- Comment #1 from Yuxuan Shui --- FYI, clang/llvm correctly generates movups instruction for the read.
[Bug target/87421] New: GCC generates unaligned movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421
Bug ID: 87421
Summary: GCC generates unaligned movdqa
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yshuiv7 at gmail dot com
Target Milestone: ---
C++ Test case:
struct A {
unsigned int a1;
long a5;
unsigned int a6;
};
int fun(A *res);
int fun2(A *desc)
{
A resource;
fun();
*desc = resource;
return 0;
}
Target: amd64
Compiler flags:
g++ test.cc -c -O2 -fno-omit-frame-pointer -std=gnu++11
Compiles to:
<_Z4fun2P1A>:
// Assuming 16 bytes stack alignment
0: 55 push %rbp // rsp now aligns to
16 bytes + 8 bytes
1: 48 89 e5mov%rsp,%rbp // rbp also aligns to
16 + 8
4: 53 push %rbx
5: 48 89 fbmov%rdi,%rbx
8: 48 8d 7d d0 lea-0x30(%rbp),%rdi
c: 48 83 ec 28 sub$0x28,%rsp
10: 64 48 8b 04 25 28 00mov%fs:0x28,%rax
17: 00 00
19: 48 89 45 e8 mov%rax,-0x18(%rbp)
1d: 31 c0 xor%eax,%eax
1f: e8 00 00 00 00 callq 24 <_Z4fun2P1A+0x24>
24: 48 8b 45 e0 mov-0x20(%rbp),%rax
28: 66 0f 6f 45 d0 movdqa -0x30(%rbp),%xmm0 // rbp-0x30 is not
aligned to 16 bytes
2d: 48 89 43 10 mov%rax,0x10(%rbx)
31: 0f 11 03movups %xmm0,(%rbx)
34: 48 8b 55 e8 mov-0x18(%rbp),%rdx
38: 64 48 33 14 25 28 00xor%fs:0x28,%rdx
3f: 00 00
41: 75 09 jne4c <_Z4fun2P1A+0x4c>
43: 48 83 c4 28 add$0x28,%rsp
47: 31 c0 xor%eax,%eax
49: 5b pop%rbx
4a: 5d pop%rbp
4b: c3 retq
4c: e8 00 00 00 00 callq 51 <_Z4fun2P1A+0x51>
[Bug lto/56088] [4.8/4.9 Regression] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 Yuxuan Shui yshuiv7 at gmail dot com changed: What|Removed |Added CC||yshuiv7 at gmail dot com --- Comment #11 from Yuxuan Shui yshuiv7 at gmail dot com --- This is still reproducible in GCC 4.8.2 on Gentoo when compiling packages like findutils.
