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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
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 usi
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
>
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|RESOLVED
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 y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #22 from Yuxuan Shui --
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
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
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
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 impro
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?"
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
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(&resource);
*
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421
Yuxuan Shui changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088
Yuxuan Shui changed:
What|Removed |Added
CC||yshuiv7 at gmail dot com
--- Comment #11
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
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.
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
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. Configu
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.
C
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];
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++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #5 from Yuxuan Shui ---
And -fstack-protector-strong is needed.
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #2 from Yuxuan Shui ---
regression from 12.3 -> 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
Yuxuan Shui changed:
What|Removed |Added
Summary|[13 Regression] |[13 Regression]
|Miscom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #10 from Yuxuan Shui ---
the manually unswitched version can probably be reduced further.
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 (&dso->i) {
while (1) {
struct obj *this = *root;
if (dso == (voi
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 (&dso->i) {
if (dso == (void *)0)
return;
assert_not_null(dso);
}
}
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
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 ev
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866
Yuxuan Shui changed:
What|Removed |Added
CC||yshuiv7 at gmail dot com
--- Comment #7
38 matches
Mail list logo
