Re: Incoming Msg
Please, read the document.
Changes..
Here is the file.
[Bug fortran/25412] gfortran 4.0.2 seg fault
--- Comment #2 from root at WPI dot EDU 2005-12-14 15:35 --- Created an attachment (id=10487) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10487&action=view) the file that breaks gfortran 4.0.2, for easier retrieval -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25412
[Bug libgcc/57754] New: Loongson 3A is MIPS64R2-compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754 Bug ID: 57754 Summary: Loongson 3A is MIPS64R2-compatible Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: root at heiher dot info Loongson 3A is MIPS64R2-compatible, so this means that it should based on ISA_MIPS64R2 (not ISA_MIPS64) ? References: http://www.loongson.cn/uploadfile/201204/Loongson3A_processor_user_manual_P2_GS464processor_core_V1.3.pdf (Page 16)
[Bug target/57754] Loongson 3A is MIPS64R2-compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754 --- Comment #1 from Heiher --- Created attachment 30409 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30409&action=edit Patch
[Bug c++/63386] New: Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 Bug ID: 63386 Summary: Release version of CB wont compile Bullet (-o2) Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: root at borealis dot su mingw32-g++.exe -Wall -fexceptions -O2 -I..\Bullet\src -c C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp -o obj\Release\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.o C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp: In member function 'virtual void btConnectivityProcessor::processTriangle(btVector3*, int, int)': C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp:310:2: internal compiler error: Segmentation fault } ^ This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp:310:2: internal compiler error: Aborted This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. mingw32-g++.exe: internal compiler error: Aborted (program cc1plus) libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Report for v2.x , same for v3.x . Using codeblocks & MinGW. Same error with TDM. Using CodeBlocks to compile , release version. In debug version that doesnt happen. That does happen with -O2 i think ( didnt try , but that is all diffrence betwen my Debug & Release , beside Wall) Sources can be found at bullet off. site
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #1 from TechoMan --- Using latests MinGW & TDM.
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #2 from TechoMan --- -O2 causes that , -O1 doesnt.
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #4 from TechoMan --- gcc version 4.8.1 (GCC). Why CB release - that error was only on release of CB. It changes some variables , such as -O2. Originaly it was rel. CB, but i found what its O2
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #5 from TechoMan --- TDM version - gcc version 4.8.1 (tdm-2)
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386
--- Comment #7 from TechoMan ---
https://github.com/bulletphysics/bullet3/blob/master/src/BulletCollision/CollisionDispatch/btInternalEdgeUtility.cpp
<- that file. For 3.x line would be 310 , '{'.
[Bug c++/72865] New: Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865
Bug ID: 72865
Summary: Adding __may_alias__ attribute triggers a compilation
error
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: root at zta dot lk
Target Milestone: ---
The following (correct) code triggers a compilation error when compiled with
gcc. It does compiles under clang.
Removing __attribute__((__may_alias__)) clause fixes the problem.
$ cat sf.cpp
template
class rv: public T
{
rv();
~rv() throw();
rv(rv const&);
void operator=(rv const&);
} __attribute__((__may_alias__));
class A
{
A(A &);
A& operator=(A &);
public:
explicit A(rv& safetyCamera);
A& operator=(rv& safetyCamera);
operator const rv&() const { return *static_cast*>(this); }
};
A::A(rv&) {}
A& A::operator=(rv&) { return *this; }
The error message
=
$ g++ -c sf.cpp
sf.cpp:20:1: error: prototype for ‘A::A(rv&)’ does not match any in class
‘A’
A::A(rv&) {}
^
sf.cpp:15:12: error: candidates are: A::A(rv&)
explicit A(rv& safetyCamera);
^
sf.cpp:12:3: error: A::A(A&)
A(A &);
^
sf.cpp:21:4: error: prototype for ‘A& A::operator=(rv&)’ does not match any
in class ‘A’
A& A::operator=(rv&) { return *this; }
^
sf.cpp:16:6: error: candidates are: A& A::operator=(rv&)
A& operator=(rv& safetyCamera);
^
sf.cpp:13:6: error: A& A::operator=(A&)
A& operator=(A &);
^
[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865 --- Comment #1 from Aleksej Lebedev --- Forgot to tell what platform I'm running this: $ uname -a Linux zhtw-pc 4.2.0-41-generic #48-Ubuntu SMP Fri Jun 24 11:28:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Exact version of the GCC: $ g++ --version g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865 --- Comment #2 from Aleksej Lebedev --- Just tried it with gcc-6.0.0 under DragonflyBSD. It seems that the bug is fixed. $ uname -a DragonFly kl.zta.lk 4.4-RELEASE DragonFly v4.4.3.1.gf6df7-RELEASE #8: Thu Apr 21 17:59:21 CEST 2016 r...@kl.zta.lk:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 $ g++6 --version g++6 (FreeBSD Ports Collection) 6.0.0 20160410 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ $ g++6 sf.cpp -c $ echo $? 0 Not sure what's your policy in this case. You decide if you want to close this as "Won't fix", but this bug prevents us from using boost::move for classes with move constructors (in some cases).
[Bug c++/41420] New: Command-line defines(-D) are not working with include(-I)
We have simple source file: file.64.cpp
int main()
{
#ifdef SOME64
printf("64\r\n");
#else
printf("32\r\n");
#endif
return 0;
}
So. If we build file with that command
$CC -DSOME64 -I../../common/src -O0 -g3 -Wall -c "systemcontroller.64.cpp"
then SOME64 are undefined in file(../../common/src is valid path).
if we erase include block(-I) or write invalid path like this
$CC -DSOME64 -I../../common/src_1 -O0 -g3 -Wall -c "systemcontroller.64.cpp"
than everithing work fine... i mean SOME64 are defined in file.
$CC can be g++, gcc, cc, c++.
os: Bluewhite64-current
gcc-config:
Reading specs from /usr/lib/gcc/x86_64-pc-linux/4.3.3/specs
Target: x86_64-pc-linux
Configured with: ../gcc-4.3.3/configure --prefix=/usr --libdir=/usr/lib
--enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose
--disable-multilib --target=x86_64-pc-linux --build=x86_64-pc-linux
--host=x86_64-pc-linux
Thread model: posix
gcc version 4.3.3 (GCC)
--
Summary: Command-line defines(-D) are not working with include(-
I)
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smal dot root at gmail dot com
GCC build triplet: x86_64
GCC host triplet: x86_64
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41420
[Bug c++/41420] Command-line defines(-D) are not working with include(-I)
--- Comment #2 from smal dot root at gmail dot com 2009-09-20 17:30 --- I correct clock, restart Xorg and everything work... Its good. Sorry -- smal dot root at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41420
[Bug c/43104] New: Incorrect code generation for target mcu ATMega164P
Source
volatile uint8_t mUsart0BufferReadPtr;
void Usart0AtModeSkipLine(void)
{
uint8_t rdptr = 0;
rdptr = mUsart0BufferReadPtr;
rdptr = mUsart0BufferReadPtr;
rdptr = mUsart0BufferReadPtr;
}
-
Generated asm
+0694: 93DFPUSH R29Push register on stack
+0695: 93CFPUSH R28Push register on stack
+0696: 920FPUSH R0 Push register on stack
+0697: B7CDINR28,0x3D In from I/O location
+0698: B7DEINR29,0x3E In from I/O location
179: uint8_t rdptr = 0;
+0699: 8219STD Y+1,R1 Store indirect with
displacement
181:rdptr = mUsart0BufferReadPtr;
+069A: 9180LDS R24,0x Load direct from data space
+069C: 8389STD Y+1,R24Store indirect with
displacement
182:rdptr = mUsart0BufferReadPtr;
+069D: 91800264LDS R24,0x0264 Load direct from data space
+069F: 8389STD Y+1,R24Store indirect with
displacement
183:rdptr = mUsart0BufferReadPtr;
+06A0: 91800264LDS R24,0x0264 Load direct from data space
+06A2: 8389STD Y+1,R24Store indirect with
displacement
OS: WinXP
gcc: avr-gcc.EXE (WinAVR 20100110) 4.3.3
--
Summary: Incorrect code generation for target mcu ATMega164P
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smal dot root at gmail dot com
GCC host triplet: Win32
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104
[Bug target/43104] Incorrect code generation for target mcu ATMega164P
--- Comment #2 from smal dot root at gmail dot com 2010-03-08 21:15 --- (In reply to comment #1) > I cannot reproduce the problem. > >c: 80 91 00 00 lds r24, 0x Its mean load data from SRAM at address 0x. Variable (in our case mUsart0BufferReadPtr) has address not equal to zero. In my first post i use three equal strings rdptr = mUsart0BufferReadPtr; because first generated with error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104
[Bug target/43104] Incorrect code generation for target mcu ATMega164P
--- Comment #4 from smal dot root at gmail dot com 2010-03-08 21:49 --- > I still cannot reproduce the error you got >>lds r24, 0x that is error! address of variable is NULL. Address of volatile uint8_t SomeVariable cant be NULL in any case. -- Data Memory Map for ATmega164P/324P/644P. 0x - 0x001F - 32 Registers 0x0020 - 0x005F - 64 I/O Registers 0x0060 - 0x00FF - 160 Ext I/O Reg. 0x0100 - 0x04FF/0x08FF/0x10FF - Internal SRAM (1024/2048/4096 x 8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104
[Bug target/43104] Incorrect code generation for target mcu ATMega164P
--- Comment #6 from smal dot root at gmail dot com 2010-03-09 01:02 --- Well, I will make necessary tests -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104
[Bug c/119314] New: Possibly wrong code generation for branch after tail function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
Bug ID: 119314
Summary: Possibly wrong code generation for branch after tail
function call
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: root at hsnovel dot net
Target Milestone: ---
gcc -v output
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20250207 (GCC)
The code is a part of a much larger proprietary codebase, so it's not possible
for me to share the exact code that reproduces it. I am writing this report to
inform you, as I unfortunutely I cannot share the code.
These are the flags:
-fno-optimize-sibling-calls -fwrapv -std=c11 -fno-strict-aliasing
-Wstrict-prototypes -Wall -Wextra -Wfloat-conversion -Wreturn-local-addr
-Wshadow -Wformat -Wcast-align -Wmisleading-indentation -msse4.1 -O2 -DNDEBUG
-fomit-frame-pointer
This is the the snippet, (part of a much bigger function):
STRING CachedName = tctx_lookupTable->playerNames[playerHandle.slot].string;
DEBUG_LOG_INFO("2 Data %p\n", dest.Data);
DEBUG_LOG_INFO("2 Size %d\n", dest.Size);
if (dest.Data)
{
DEBUG_LOG_INFO("3 Data %p\n", dest.Data);
U32 CopySize = Min(CachedName.Size, dest.Size);
memcpy(dest.Data, CachedName.Data, CopySize);
return CopySize;
}
else
{
return CachedName.Size;
}
where DEBUG_LOG_INFO is:
#define log_info(...) log_log(Log_Info, __VA_ARGS__)
#define DEBUG_LOG_INFO(...) log_info(__VA_ARGS__)
static const char* log_level_colors[] = {
[Log_Err] = "\x1b[31m",
[Log_Warn] = "\x1b[33m",
[Log_Info] = "\x1b[36m",
[Log_Enum_Count] = "\x1b[0m"
};
static const char* log_level_string[] = {
[Log_Err] = "[ERROR]: ",
[Log_Warn] = "[WARN] : ",
[Log_Info] = "[INFO] : ",
};
void log_log(enum log_level level, const char *args, ...)
{
va_list va;
FILE *fd;
if (level == Log_Err)
fflush(stdout);
va_start(va, args);
fd = (level == Log_Err) ? stderr : stdout;
fprintf(fd, "%s", log_level_colors[level]);
fprintf(fd, "%s", log_level_string[level]);
vfprintf(fd, args, va);
if (level == Log_Err)
fflush(stderr);
fprintf(fd, "%s", log_level_colors[Log_Enum_Count]);
va_end(va);
}
and STRING is:
typedef struct
{
char *Data;
unsigned int Size;
} STRING;
When the code snippet executes, it runs:
[INFO] : 2 Data (nil)
[INFO] : 2 Size 0
[INFO] : 3 Data (nil)
It enters the if branch and prints 3 Data (nil), even tough it prints the
pointer as (nil) in "2 Data", right before entering the branch.
This is the assembly that got generated for that snippet:
; CODE XREF from sym.IGNORE_THIS_ITS_FUNCTION_NAME @ 0x8bcc(x)
; 0x28f58
lea rdi, section..got
call fcn.6260;[ob]
; int64_t arg3
mov rdx, rbp
; int64_t arg1
mov edi, 2
; int64_t arg2
; 0x234e6
; "2 Data %p\n"
lea rsi, str.2_Data__p_n
mov rax, qword [rax]
add rbx, qword [rax + 0x10]
xor eax, eax
mov r13, qword [rbx + 8]
mov ebx, dword [rbx + 0x10]
call sym.log_log;[oa]
[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #4 from Novel ---
(In reply to Andrew Pinski from comment #1)
> >The code is a part of a much larger proprietary codebase, so it's not
> >possible for me to share the exact code that reproduces it. I am writing
> >this report to inform you, as I unfortunutely I cannot share the code.
>
>
> And there is not much we can do without a testcase sorry.
I know, I just wanted to report it regardless. Tought it could help in some
way.
(In reply to Andrew Pinski from comment #2)
> See https://gcc.gnu.org/bugs/#need
>
> Also try using -fsanitize=address,undefined and fixing all of the issues
> that it reports if any.
I will do it when I get back to the working enviroment.(In reply to Andrew
Pinski from comment #3)
> Before `DEBUG_LOG_INFO("2 Data %p\n", dest.Data);`
> is there any calls before hand? Like say to memcpy? or anything that might
> have the nonnull attribute on it and uses dest.Data?
>
> Note memcpy before C23 was undefined (even if the length was 0) to pass a
> null pointer to it.
>
> Does -fno-delete-null-pointer-checks if the issue you are running into? If
> so there is most likely a what I described, `-fsanitize=undefined` should
> catch that at runtime.
No there isn't any call before that touches the variable dest, or anything that
has an attribute nonnull. dest also is an argument to the function, and this
function doesn't get called in anywhere in the source code. This program is a
shared library, and it returns the address of the function in a function that
is exported.
I did not specify any attribute or logic that might make the compiler assume
what dest.Data can be. It's not even accessed in any way before and after the
snipped I showed. It's a parameter to a function that isn't even called
anywhere in the entire project. But this bug does indeed happen only on release
builds. Debug builds work just fine.
If the compiler can determine that dest.Data is somehow non null, I can tell
that there is clearly a bug, unless it's some super agressive compiler
optimization.
I will test the sanitizer as soon as I get back the working place, I will
report back when I do.
[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314 --- Comment #6 from Novel --- (In reply to Andrew Pinski from comment #5) > (In reply to Novel from comment #0) > > > ; CODE XREF from sym.IGNORE_THIS_ITS_FUNCTION_NAME @ 0x8bcc(x) > > ; 0x28f58 > > lea rdi, section..got > > call fcn.6260;[ob] > > ; int64_t arg3 > > mov rdx, rbp > > ; int64_t arg1 > > mov edi, 2 > > ; int64_t arg2 > > ; 0x234e6 > > ; "2 Data %p\n" > > lea rsi, str.2_Data__p_n > > mov rax, qword [rax] > > add rbx, qword [rax + 0x10] > > xor eax, eax > > mov r13, qword [rbx + 8] > > mov ebx, dword [rbx + 0x10] > > call sym.log_log;[oa] > > xor eax, eax > > ; int64_t arg3 > > mov edx, r14d > > ; int64_t arg1 > > mov edi, 2 > > ; int64_t arg2 > > ; 0x234f1 > > ; "2 Size %d\n" > > lea rsi, str.2_Size__d_n > > call sym.log_log;[oa] > > test rbp, rbp > > je 0x8a98 > > Test %RBP . > > So if a function does not restore correctly %RBP things could go wrong. > > Also try running your test program under valgrind, it might catch some stuff > too. > > The other thing to try is change log_info to be a just printf. > > There could be a bug in musl fprintf too that is not restoring some register > correctly. It is not obvious what is going on here from even the snip of > code. I tested it today and neither valgrind nor sanitizer did report anyhting related to this. I did link with glibc, instead of musl and tested printf but it's still the same. I am not sure if further discussion in this report would be usefull to any gcc maintainer, as I am not able to provide much information unfortunately. I can test other things, if some maintainer wants me to experiment with some flag somehow, otherwise you can close this report when you see fit.
[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #8 from Novel ---
(In reply to Sam James from comment #7)
> Please try to reduce the relevant functions and we can take a look with a
> testcase.
I am not sure to what extend it is possible for you to make a testcase for it
because as much as I try to reduce the functions around it, everything is kind
of interconnected to each other but, the following code does still produce the
same anomaly, even tough a large portion of the actual code is removed. I am
not sure if you can make a testcase, but regardless the following is the code:
(I stripped some api prefixes and renamed some types and variables that might
revel something, so there might be a typo)
Also note that the program code gets loaded by Java virtual machine over JNI.
So the types jobject and jstring are Java Native Interface's types. And the
function GetPlayerName doesn't get called in anywhere in the codebase.
Here is the code:
/*
===
LUT is a struct that merely contains pointers to fixed sized arrays.
playerObjects variable are: (will make sense later)
typedef struct {
UINT slotGenerationCounter;
jobject Object;
} LUT_OBJECT;
UINT is typedef to uint32_t
===
*/
static LUT GlobalLookupTable;
__thread LUT *ThreadLocalLUT; // This points to GlobalLookupTable in this
particular case
typedef struct {
UINT slot;
UINT SlotGenerationCounter;
} PLAYER_HANDLE __aligned(8);
__force_inline static jobject
IsPlayerHandleValid(
PLAYER_HANDLE PlayerHandle
)
{
LUT_OBJECT Slot = ThreadLocalLUT->playerObjects[PlayerHandle.slot];
if (likely(PlayerHandle.slot <= MAX_PLAYER_COUNT))
{
UINT ExistingSlotGenerationCounter = Slot.SlotGenerationCounter;
jobject PlayerObject = Slot.Object;
if(likely(ExistingSlotGenerationCounter ==
PlayerHandle.SlotGenerationCounter)
&& likely(PlayerObject))
{
return PlayerObject;
}
else
{
return NULL;
}
}
else
{
return NULL;
}
}
// The calls to writeJStringToMemory and getJStringUTFSize call
// a function that is executed by the Java virtual machine.
static void
LUT_UpdateStringWithJString(
LUT_STRING *dest,
jstring newString,
STRING dup
)
{
if(lut_shouldCacheResult())
{
UINT nameSize = getJStringUTFSize( newString );
THREAD_LOCAL_STORAGE *tctx = GetThreadLocalStorage();
STRING result = {
.Size = nameSize,
.Data = PoolPush(&tctx->TempArena, nameSize),
};
writeJStringToMemory( newString, result.Size, result.Data );
memcpy(dup.Data, result.Data, dup.Size);
dest->string = result;
dest->eventGenerationCounter = ThreadLocalLUT->eventGenerationCounter;
}
else
{
writeJStringToMemory( newString, dup.Size, dup.Data );
}
}
static UINT
GetPlayerName(
PLAYER_HANDLE Player,
VSP_STRING dest
)
{
PLAYER_HANDLE PlayerHandle = Player;
if(IsPlayerHandleValid(PlayerHandle))
{
// LUT_GoThroughCache is a tail function, that doesn't have any
sidefects nor any special attributes. It doesn't modify any global state, nor
does it mutate anything.
if(!LUT_GoThroughCache(ThreadLocalLUT->PlayerNames[PlayerHandle.slot].EventGenerationCounter))
{
jobject Player =
ThreadLocalLUT->playerObjects[PlayerHandle.slot].Object;
jstring PlayerName = GetPlayerName(Player);
LUT_UpdateStringWithJString(&ThreadLocalLUT->PlayerNames[playerHandle.slot],
PlayerName, dest);
}
STRING CachedName =
ThreadLocalLUT->PlayerNames[PlayerHandle.slot].String;
DEBUG_LOG_INFO("2 Data %p\n", dest.Data);
DEBUG_LOG_INFO("2 Size %d\n", dest.Size);
if (dest.Data)
{
DEBUG_LOG_INFO("3 Data %p\n", dest.Data);
U32 CopySize = Min(CachedName.Size, dest.Size);
memcpy(dest.Data, CachedName.Data, CopySize);
return CopySize;
}
else
{
return CachedName.Size;
}
}
else
{
// This is not relevant same thing happens even if this is removed.
INVALID_ARGUMENT_PASSED_CALLBACK("Invalid Player handle");
}
return 0;
}
This is as much code as I can share. I am not allowed to reveal more.
[Bug middle-end/119314] Possibly wrong code generation for branch after leaf function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #13 from Novel ---
(In reply to Andrew Pinski from comment #3)
> Before `DEBUG_LOG_INFO("2 Data %p\n", dest.Data);`
> is there any calls before hand? Like say to memcpy? or anything that might
> have the nonnull attribute on it and uses dest.Data?
>
> Note memcpy before C23 was undefined (even if the length was 0) to pass a
> null pointer to it.
>
> Does -fno-delete-null-pointer-checks if the issue you are running into? If
> so there is most likely a what I described, `-fsanitize=undefined` should
> catch that at runtime.
It seems like what Andrew Pinski suggested at the beggining was indeed true. It
was LUT_UpdateStringWithJString that had a memcpy
deep inside a callstack. I didn't see it at first because the function did
branch into so many different code paths that it was couple of layers down the
call stack.
I have no idea why the sanitizer or valgrind didn't catch it, maybe they don't
work well when they run under JNI, I don't know.
So for -fno-delete-null-pointer-checks, it seems like I was a complete idiot
and pasted that to the wrong place.
Sorry for wasting everyone's time. And thanks for the help.
