[Bug middle-end/110194] GCC shouldn't warn for inline functions when -g provided.
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 ?
[Bug c/110194] New: GCC shouldn't warn for inline functions when -G provided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194 Bug ID: 110194 Summary: GCC shouldn't warn for inline functions when -G provided. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal 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 mislead the developers in debug mode . Thank you
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #20 from Umesh Kalappa --- Segher , We have a vague requirement in VxWorks, where we support soft-float for a better context switch, same carried with ppc64 too . hence we made these changes
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
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 assembler code for the thunk function specified by the arguments it is passed, and false otherwise. */ static bool rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT, const_tree) { if (rs6000_default_long_calls) return false; /* The loader neither creates the glue code sequence that loads r12 nor uses the local entry point for the sibcall's target in the ELFv2 ABI. */ return DEFAULT_ABI != ABI_ELFv2; } when we have longcall enabled ,we fall through regular asm thunk generation like above . is that ok to commit and we regressed for powerpc and no-regress found .
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
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 ?
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
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)
[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
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 here to do so (more conservative and un-optimial for now).
[Bug target/90513] powerpcelfv2 :R2 is not updated to the TOC base .
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
[Bug target/90513] Pwerplcelfv2 :R2 is not updated to the TOC base .
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
[Bug target/90512] New: Pwerplcelfv2 :R2 is not updated to the TOC base .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90512 Bug ID: 90512 Summary: Pwerplcelfv2 :R2 is not updated to the TOC base . Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 found that r2 was not updated with toc base ,since r12 doesn't point to Global entry point for the function ,since its local call (like bl func). like eric mentioned,its the issue with vxworks kernel module and following fix in the compiler #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 assembler code for the thunk function specified by the arguments it is passed, and false otherwise. */ static bool rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT, const_tree) { /* The only possible issue is for VxWorks in kernel mode. */ if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP) return true; /* The loader neither creates the glue code sequence that loads r12 nor uses the local entry point for the sibcall's target in the ELFv2 ABI. */ return DEFAULT_ABI != ABI_ELFv2; } will fix the issue ,but not optimal .
[Bug target/90513] New: Pwerplcelfv2 :R2 is not updated to the TOC base .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 Bug ID: 90513 Summary: Pwerplcelfv2 :R2 is not updated to the TOC base . Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 ,since its local call (like bl func). like eric mentioned,its the issue with vxworks kernel module and following fix in the compiler #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 assembler code for the thunk function specified by the arguments it is passed, and false otherwise. */ static bool rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT, const_tree) { /* The only possible issue is for VxWorks in kernel mode. */ if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP) return true; /* The loader neither creates the glue code sequence that loads r12 nor uses the local entry point for the sibcall's target in the ELFv2 ABI. */ return DEFAULT_ABI != ABI_ELFv2; } will fix the issue ,but not optimal .
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
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 or add a new set of emit_library_call* APIs that would take those triplets. we feel thats clean fix ,but needs exhaust testing here (impact on other targets).
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
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 () { unsigned int x=-1; double d=x; printf("%lf",d); return 0; } $./ccppc -mcpu=e6500 -mabi=elfv2 -msoft-float -m64 test.c $./a.out 9223372036854775810.00 while Expected output is: 4294967295.00 >>Maybe it is because not many people use soft-float with 64bit which explains >>why this has not been seen before. But we do have this case ,where we ended up using the soft float and any suggestions on @kamllesh fix ,where we don't promote for libcalls ?
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
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 ?
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #3 from Umesh Kalappa --- https://members.openpowerfoundation.org/document/dl/576 it says we infer that, Map simple integer types (char, short, int, long, enum) to a single doubleword. Sign or zero extend values shorter than a doubleword to a doubleword based on whether the source data type is signed or unsigned.
[Bug bootstrap/88668] Code generated was different for PowerPC when build!=host compared to build=host
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="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \ LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \ GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \ + enable_targets=$enable_targets\ ${realsrcdir}/configure \ --enable-languages=${enable_languages-all} \ --target=$target_alias --host=$build_alias --build=$build_alias and my bad for miscommunication here .
[Bug bootstrap/88668] Code generated was different for PowerPC when build!=host compared to build=host
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 .
[Bug c/88668] Code generated was different for PowerPC on Windows W.R.T Linux.
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_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \ LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \ GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \ + gcc_cv_as=../as gcc_cv_ld=../collect-ld enable_targets=$enable_targets\ ${realsrcdir}/configure \ --enable-languages=${enable_languages-all} \ --target=$target_alias --host=$build_alias --build=$build_alias This change would affect the value of macros defined in auto-build.h which is used when building the toolchain for Windows, the different value of macros result the different code in generated file insn-conditions.md, insn-recog.c etc which eventually makes a different compiler is built for Windows. Before we conclude with our changes ,we would like to hear from the experts here on the difference behaviour(b/w hosts) and the fix .
[Bug c/88668] New: Code generated was different for PowerPC on Windows W.R.T Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88668 Bug ID: 88668 Summary: Code generated was different for PowerPC on Windows W.R.T Linux. Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal 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 : --target=powerpc-linux-gnu --prefix=/usr/local/wind/tmp/compilers --with-pkgversion=' GCC 8.1.0.0 - 2018.10.29' --disable-nls --enable-languages=c,c++ --enable-targets=all --disable-multilib --enable-threads --enable-tls --enable-__cxa_atexit --enable-secureplt code generated like addis 3,2,.LC0@toc@ha addi 3,3,.LC0@toc@l where offset signed 32 bit used relatively to toc base on linux as expected for the medium code model . and the relocation entry will be generated by gas : R_PPC64_TOC16_HA and R_PPC64_TOC16_LO On windows with configure like : --host i686-w64-mingw32 --target=powerpc-linux-gnu --prefix=/usr/local/wind/tmp/compilers --with-pkgversion='GCC 8.1.0.0 - 2018.10.25' --disable-nls --enable-languages=c,c++ --enable-targets=all --disable-multilib --enable-threads --enable-tls --enable-__cxa_atexit --enable-secureplt code generated like : la 3,.LC0@toc(2) where offset used is signed 16 bit used relatively to toc base and the relocation entry will be : R_PPC64_TOC16 (signed 16 bit offset ).
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
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 .
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #3 from Umesh Kalappa --- mateuszb, Please can you provide us the sample file to investigate more on this .
[Bug rtl-optimization/83377] Missed optimization (x86): Bit operations should be converted to arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83377 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #2 from Umesh Kalappa --- we can this transformation in the match,pd too (at gimple level).
[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869 --- Comment #11 from Umesh Kalappa --- Thank you Jason and Marek for all your support .
[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #8 from Umesh Kalappa --- the following patch fix all the reported cases and tested with latest trunk and 8.1 source i.e Index: gcc/cp/parser.c === --- gcc/cp/parser.c (revision 266026) +++ gcc/cp/parser.c (working copy) @@ -24615,6 +24615,8 @@ { tree expr; cp_lexer_consume_token (parser->lexer); + + inject_this_parameter (current_class_type, TYPE_UNQUALIFIED); if (cp_lexer_peek_token (parser->lexer)->type == CPP_OPEN_PAREN) { ok to commit ?
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
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 ldr r3, [r3] ldrbr2, [r3] movsr2, #0 orr r2, r2, #1 strbr2, [r3] ldrbr2, [r3, #1] movsr2, #0 orr r2, r2, #4 strbr2, [r3, #1] ldrbr2, [r3, #2] movsr2, #0 strbr2, [r3, #2] ldrbr2, [r3, #3] movsr2, #0 strbr2, [r3, #3] ldr r3, .L3 ldr r3, [r3] ldr r2, [r3]@ unaligned ldr r3, .L3 ldr r3, [r3] uxtbr2, r2 strbr2, [r3, #4] ldr r3, .L3 ldr r3, [r3] ldrbr3, [r3, #4]@ zero_extendqisi2 mov r0, r3 addsr7, r7, #12 mov sp, r7 @ sp needed pop {r7} bx lr but ,why you are compiling with -O0 , any reason such ?
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #1 from Umesh Kalappa --- with trunk i see below output for the attached case . main: @ args = 0, pretend = 0, frame = 8 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. sub sp, sp, #8 movwr3, #1025 str r3, [sp] ldr r0, [sp] ldr r3, .L4 uxtbr0, r0 str sp, [r3] add sp, sp, #8 @ sp needed bx lr $ arm-windriver-linux-gnueabi-gcc -mcpu=cortex-m3 -mthumb '-DDEBUG=1' -O2 -pedantic -Wall -Wextra -fmessage-length=0 -mno-sched-prolog -fno-builtin -fshort-enums test.c -S
[Bug libgcc/86512] New: Incorrect sub result for float subnormal inputs in armv7(with -msoft-float).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512 Bug ID: 86512 Summary: Incorrect sub result for float subnormal inputs in armv7(with -msoft-float). Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: 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 filename command used : arm-none-linux-gnueabi-gcc test.c -msoft-float -march=armv7 file test.c attached. expected o/p :0xf incorrect o/p:0xe with (-mhard-float) getting the expected o/p (with flush to zero mode disabled). while debugging the soft-float code,we see that ,the compiler calls the intrinsic "__aeabi_dsub" with arm calling conventions i.e passing "a" in r0 and r1 registers and respectively for "b" and we are investigating the routine "__aeabi_dsub" that comes from libgcc(libgcc/config/arm/ieee754-df.S) for incorrect result. any inputs from the community will be appreciated. thank you
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #7 from Umesh Kalappa --- Thank you Jakub for the quick fix and as stated the patch works for reported case.