Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: msl0000023508 at gmail dot com
Target Milestone: ---
Building of GCC 15-20240825 fails with:
../../../gcc-15-20240825/libssp/ssp.c: In function 'fail
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: msl023508 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337
--- Comment #11 from WHR ---
Created attachment 49259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49259&action=edit
gcc-10.2.0-sanitizer-madvise-fix.diff
Replace non-standard madvise(2) with posix_madvise(3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337
--- Comment #10 from WHR ---
Created attachment 49258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49258&action=edit
gcc-10.2.0-sanitizer-solaris-libelf-h-without-file-offset-bits-64.diff
Solaris libelf.h doesn't work with _FILE_OFFSET_B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337
--- Comment #9 from WHR ---
Created attachment 49257
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49257&action=edit
gcc-10.2.0-sanitizer-linux-procfs-fix.diff
Limit this Linux procfs code to Linux only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337
WHR changed:
What|Removed |Added
CC||msl023508 at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87488
--- Comment #24 from WHR ---
Looks like commit r10-6643-g458c8d6459c4005fc9886b6e25d168a6535ac415 is a well
fix, and my terminal is no longer nosiy running GCC 10.
I have a suggestion, consider check for a few more 'TERM' types that would
certai
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msl023508 at gmail dot com
Target Milestone: ---
I'm not sure whether this test program is valid, but here it is:
$ cat test-case.c
extern int printf(const char *, ...);
union {
unsigned i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
--- Comment #4 from WHR ---
OK, I'm now fully understood what's happens.
If the loop breaks, 'p' must be 0, so the later '**p' will dereference a null
pointer.
Looks like this is actually a feature...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
--- Comment #1 from WHR ---
This happens with in x86_64 (-m64) and i386 (-m32) targets.
But not in early versions such GCC 9.2.
As a reference, compiling it with GCC 9.2 didn't trigger the crash:
$ gcc-9.2 -v
Using built-in specs.
COLLECT_GCC=gc
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msl023508 at gmail dot com
Target Milestone: ---
$ cat preprocessed.c
int g1 = 2;
int *g2 = &g1;
int g3 = 6;
void func
11 matches
Mail list logo