https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Sam James changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #17 from Gavin Howard ---
> These links are dead. That's why we want references to a standalone testcase
> given (lines in it or functions and so on)...
Fair enough, but in my defense, it's been two years. I was pretty sure this had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #19 from Gavin Howard ---
Understood.
If I had to guess, and this is a *wild* guess, it's because I'm putting a
pointer to a function in the allocation.
As far as I can tell, this is still allowed, per the docs:
> Attribute `mallo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #18 from Sam James ---
That's exactly where I saw it ;)
I go over bugs marked as needs-reduction/wrong-code/needs-bisection often, but
this bug wasn't marked as those, so I didn't see it. WAITING means we need the
reporter to give u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #16 from Sam James ---
(In reply to Gavin Howard from comment #0)
> [1]:
> https://git.yzena.com/Yzena/Yc/src/commit/
> 6afdc86bd2c17f98b2f9e97e79e37fdf8c6b7708/src/alloc/stackpool.c#L441
>
> [2]:
> https://git.yzena.com/Yzena/Yc/sr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #15 from Andrew Pinski ---
void*
y_realloc(void* ptr, y_usize size) __attribute__((malloc));
Yes that should NOT be malloc.
I wonder if removing malloc from y_realloc fixes the issue.
NOTE realloc is not marked as malloc.
See th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Sam James changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #14 from Sam James ---
Hm, dropping the attribute everywhere doesn't help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #11 from Sam James ---
It still aborts with -O1 -fno-strict-aliasing (just to be sure, though -O1
shouldn't need it). It passes with -O1 -fno-tree-pta.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #13 from Sam James ---
(In reply to Sam James from comment #12)
> I suspect this is abuse of __attribute__((malloc)).
y_stackpool_malloc returns a value derived from input `p`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #12 from Sam James ---
I suspect this is abuse of __attribute__((malloc)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #10 from Gavin Howard ---
I have confirmed that the GCC bug (if it is a bug) also exists in 12.2.1, at
least using the amal.c I have attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #9 from Gavin Howard ---
> I suspect cmake didn't add -fno-strict-aliasing really.
It did. I ran the build under `intercept-build` and looked at the
`compile_commands.json` output. It had the `-fno-strict-aliasing` for every
file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #8 from Gavin Howard ---
Created attachment 54310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54310&action=edit
Amalgamation with License Header
Not important for the bug, but I reuploaded the amalgamation with its proper
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #7 from Andrew Pinski ---
I do notice some aliasing violations with y_map_index and
y_strucon_handleErrorHelper
y_vec* stack;
...
y_map_existsStringKey_v(d->contexts, ("com.yzena.yc.error_handler"),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #6 from Gavin Howard ---
Created attachment 54302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54302&action=edit
An Amalgamation to Reproduce
I have managed to make an amalgamation that reproduces the bug. When you unzip
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #5 from Gavin Howard ---
As mentioned, it works at -O0, and UBSan reports nothing until the segfault.
ASan also reports nothing. Valgrind also reports nothing. They all report
nothing at -O0 and -O2.
I keep my code clean of such thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #4 from Andrew Pinski ---
Does it work at -O0?
Does -fsanitizer=address -fsanitizer=undefined report anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #3 from Gavin Howard ---
> Have you tried -fno-strict-aliasing ? I have a feeling like you have some
> aliasing issues in this code ...
Just tried it, same thing happens.
I'll try to make a better test case, but in this case, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #2 from Andrew Pinski ---
Have you tried -fno-strict-aliasing ? I have a feeling like you have some
aliasing issues in this code ...
20 matches
Mail list logo
