Re: [Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)
Hi Segher ,
We would like to know comments on the below proposed change ?
Thank you
~Umesh
On Tue, Jun 11, 2019 at 10:23 PM umesh.kalappa0 at gmail dot com
wrote:
>
> 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 .
Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Hi All,
We are able to fix the subjected issue with the peephole patterns
(target specific) in the md file (attached the patch pr54589.patch).
While testing the fix ,we end up with some of the C constructs like
Testcase 1:
#include
struct param {
int a, b, c, d;
__m128i array[256];
};
void func(struct param p, unsigned char *src, int *dst)
{
__m128i x = p.array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 for x86-64 and asm looks like
func:
movzbl (%rdi), %eax
addq$1, %rax
salq$4, %rax
movl8(%rsp,%rax), %eax
movl%eax, (%rsi)
ret
Testcase 2:
#include
struct param {
int a, b, c, d;
__m128i array[256];
};
struct param *p1;
void func(unsigned char *src, int *dst)
{
__m128i x = p1->array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 on x86-64 :
func:
movzbl (%rdi), %eax
addq$1, %rax
salq$4, %rax
addqp1(%rip), %rax
movl(%rax), %eax
movl%eax, (%rsi)
ret
So, we are thinking to extend our fix with few more peephole patterns
in the md file.
OR it’s better to handle all C constructs in combiner/fwprop pass
,please let us know your suggestions or comments on this ,that guides
us in the right direction.
Thank you
~Umesh
On Fri, Nov 23, 2018 at 3:56 PM Umesh Kalappa wrote:
>
> Hi Richard,
>
> for the subjected issue , we found few suggestions to handle the issue like
>
> 1. be more conservative(target specific) and defining the peephole in
> the md file to handle the patterns like add,shl and movl to "shlq and
> movl"
> 2. like you mentioned in fwprop/combiner .
>
> we would like to know your inputs /suggestions before we go ahead with
> the patch.
>
> Thank you
> ~Umesh
pr54589.patch
Description: Binary data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Hi Richard, for the subjected issue , we found few suggestions to handle the issue like 1. be more conservative(target specific) and defining the peephole in the md file to handle the patterns like add,shl and movl to "shlq and movl" 2. like you mentioned in fwprop/combiner . we would like to know your inputs /suggestions before we go ahead with the patch. Thank you ~Umesh
Re: [Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses
Hi Jason /Nathan ,
We are able to fix the below issue and would like to hear any comments
/ suggestions will be appreciated.
Thank you
~Umesh
On Mon, Nov 12, 2018 at 5:07 PM umesh.kalappa0 at gmail dot com
wrote:
>
> 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 ?
PIE/PIC issue ...w.r.t linker variable
Hi Guys ,
we do have a issue with below code ,When we enabled the pie (-fpie/pie) option
i.e
main.c
extern int *my_ptr ;
int main()
{
return *my_ptr;
}
foo.s
.syntax unified
.cpu cortex-m0
.fpu softvfp
.thumb
.global my_ptr
.global my_var
.data
.align 2
.type my_ptr, %object
.size my_ptr, 4
my_ptr:
.word my_var //where my_var is the linker variable
custom.ld (linker script)
/* Set stack top to end of RAM, and stack limit move down by
190 * size of stack_dummy section */
191 my_var = 20;
192 __StackTop = ORIGIN(RAM) + LENGTH(RAM);
193 __StackLimit = __StackTop - SIZEOF(.stack_dummy);
194 PROVIDE(__stack = __StackTop);
command used
3 arm-none-eabi-gcc -c -fPIC main.c -mthumb -mcpu=cortex-m0
4
5 arm-none-eabi-gcc -c -fPIC foo.S -mthumb -mcpu=cortex-m0
6 arm-none-eabi-gcc -c -fPIC
/home/egoumal/Downloads/gcc-arm-none-eabi-5_2-2015q4/share/gcc-arm-none-eabi/samples/startup/startu
p_ARMCM0.S -mthumb -mcpu=cortex-m0 -D__STARTUP_CLEAR_BSS
-D__START=main
7
8 arm-none-eabi-ld -pie main.o foo.o startup_ARMCM0.o -L.
-L/home/egoumal/Downloads/gcc-arm-none-eabi-5_2-2015q4/share/gcc-ar
m-none-eabi/samples/ldscripts -T nokeep.ld -Map=test.map -o test
we expect my_ptr value to be 20 ,but we do see the value 0 and without
pie option ,the my_ptr has the value 20 .
do we missing something here or value 0 expected (which is incorrect)
Thank you and appreciate any lights on this
~Umesh
