[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.
[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 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/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] 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/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 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 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/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/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 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 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 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 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
--- 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 #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/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] 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 #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 #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 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 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++/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++/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 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 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 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 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 ?
