https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
--- Comment #5 from Umesh Kalappa ---
Ok thank you @Jakub and @Andrew for the quick reply ,
>>-Winline
Option triggers this diagnostic ,so it better not to use this option in the
debug build ?
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: umesh.kalappa0 at gmail dot com
Target Milestone: ---
Hi ,
We think for the following testcase
https://godbolt.org/z/bzE451zn1
GCC shouldn't warn like Clang does ,and it m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #17 from Umesh Kalappa ---
the following change
#undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
#define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk
/* Return true if rs6000_output_mi_thunk would be able to output the
assembl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #15 from Umesh Kalappa ---
>>Yes, but just use a regular thunk.
you mean ,the target-independent code in the C++ front end will generate a less
efficient heavyweight thunk that calls function instead of jumping to it ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #13 from Umesh Kalappa ---
>>There is no point in emitting an asm thunk if you use a long call though.
thunk required to adjust the this pointer (in c++ cases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #11 from Umesh Kalappa ---
Segher and Alan ,
for our kernel module we always pass option "-mlongcall" and we believe that
,the asm thunk should generate the long call here (through call r12 in this
case) and we can fix the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #3 from Umesh Kalappa ---
options used : -mcpu=e6500 -mno-altivec -mabi=no-altivec -mabi=elfv2
-mcmodel=medium -mhard-float -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #2 from Umesh Kalappa ---
Created attachment 46369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46369&action=edit
testcase
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: umesh.kalappa0 at gmail dot com
Target Milestone: ---
Created attachment 46368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46368&action=edit
testcase
the attached case is failing with segfault and fou
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: umesh.kalappa0 at gmail dot com
Target Milestone: ---
the attached case is failing with segfault and found that r2 was not updated
with toc base ,since r12 doesn't point to Global entry point for the function
,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #15 from Umesh Kalappa ---
like jakub recommended in the other mail thread ,
All the callers of emit_library_call* would need to be changed to pass
triplets rtx, machine_mode, int/bool /*unsignedp*/, instead of just
rtx_mode_t pair o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #11 from Umesh Kalappa ---
>>To make slightly better code we could make the soft float routines be
prototyped?
having the prototype also no luck here like
$cat test.c
#include
double __floatunsidf(unsigned int );
int main () {
un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #7 from Umesh Kalappa ---
Segher,true ,so how do we fix the case , modify the __floatunsidf to clear arg
higher 32 bits , before it use ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88668
--- Comment #5 from Umesh Kalappa ---
Andrew unfortunately your suggestion didn't worked for us and there was
mis-lead in our fix and the actual change was like
--- a/gcc/configure
+++ b/gcc/configure
@@ -11795,15 +11795,16 @@ else
CXX=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88668
--- Comment #4 from Umesh Kalappa ---
Thank you Andrew for the suggestions and let us try the same and update here .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88668
--- Comment #1 from Umesh Kalappa ---
after our investigation we found that the below change ,makes code to be
generated like identical to linux host .
--- a/gcc/configure
+++ b/gcc/configure
@@ -11795,15 +11795,16 @@ else
CXX="${CXX_
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: umesh.kalappa0 at gmail dot com
Target Milestone: ---
Hi All ,
Lets consider the below code
int foo()
{
printf("Hello World");
}
On linux with configure like :
--targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #4 from Umesh Kalappa ---
mateuszb,
Please can you provide us the sample file to investigate more on this .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83377
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #11 from Umesh Kalappa ---
Thank you Jason and Marek for all your support .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
--- Comment #3 from Umesh Kalappa ---
With -O0 , i see the byte load /store like
push{r7}
sub sp, sp, #12
add r7, sp, #0
ldr r2, .L3
mov r3, r7
str r3, [r2]
ldr r3, .L3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: umesh.kalappa0 at gmail dot com
Target Milestone: ---
Created attachment 44389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44389&action=edit
input f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
28 matches
Mail list logo
