Hi,
When analyzing code size differences between a 4.9.x compiler and
trunk for the AVR target, I found quite a few cases where extra
registers were being used to hold smaller types (two 8 bit registers
for a uint8_t, for example).
On deeper analysis, I found that the VRP pass (gcc/tree
On Thu, Nov 12, 2015 at 08:37:02PM +0100, Richard Biener wrote:
> On November 12, 2015 8:10:05 PM GMT+01:00, Senthil Kumar Selvaraj
> wrote:
> >Hi,
> >
> > When analyzing code size differences between a 4.9.x compiler and
> > trunk for the AVR target, I found
Hi,
While tracking down a performance regression for the AVR target from
4.9.x to trunk, I noticed that failing the SHRINK_WRAPPING_ENABLED
check in ira.c led to noticeably worse code for the following
case. That check prevents live range splitting of pseudos containing
formal args, and
Eric Botcazou writes:
>> Output of -fstack-usage is not accurate
>> ===
>>
>> This article mentions a "call cost":
>> https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/
>>
>> I checked for myself, by looking at the change of the stackpointer
David Malcolm writes:
> A user filed a bug about a bad location in a warning. It was marked as
> an "easyhack" in bugzilla, and I had a go at fixing it.
>
> I though it may be useful for new GCC developers if I document what I
> did to fix it.
>
> FWIW, the bug was PR c/71610
> i.e. https://gc
Richard Biener writes:
> On July 20, 2016 2:01:18 AM GMT+02:00, Andrew Pinski
> wrote:
>>Hi,
>> I noticed that ubsan testsuite sometimes has failures due to dejagnu
>>buffer gets full and we no longer match on the output any more.
>>As you can see from the .log file:
>>/data1/jenkins/workspace
Hi Johann,
Turning off -fcaller-saves for AVR makes the testcase I had for PR 71873
pass unless I explicitly add -fcaller-saves to force the compiler to
generate the triggering insn patterns.
Wonder if we should modify the existing test cases in gcc.target/avr to
be tested both ways (wi
Hi,
For this C code (slightly modified from PR 30908)
void wait(int i)
{
while (i-- > 0)
asm volatile("nop" ::: "memory");
}
gcc 4.8 at -Os produces
jmp .L2
.L3:
nop
decl%edi
.L2:
testl %edi, %edi
jg .L3
Segher Boessenkool writes:
> On Wed, Jan 04, 2017 at 10:05:49AM +0100, Richard Biener wrote:
>> > The code size is identical, but the trunk version executes one more
>> > instruction everytime the loop runs (explicit jump to .L5 with trunk vs
>> > fallthrough with 4.8) - it's faster only if the l
On Mon, Sep 01, 2014 at 09:14:31AM +0800, Peng Fan wrote:
>
>
> On 09/01/2014 08:09 AM, Matt Thomas wrote:
> >
> > On Aug 31, 2014, at 11:32 AM, Joel Sherrill
> > wrote:
> >
> >>> Hi,
> >>>
> >>> I am writing some code and found that system crashed. I found it was
> >>> unaligned access which
Hi,
For this (reduced) test case
extern int x, y, z;
void foo(void);
void bar(void);
void blah(void);
void test (void)
{
int flag = 0;
flag = ((x && y) || z);
if (flag && x && y) {
bar();
}
}
I expected gcc -Os (x86_64, if it matters) to generate code equivalent to
if (x &
someone
apply if it is ok?
Regards
Senthil
2013-03-27 Senthil Kumar Selvaraj
* gcc.dg/debug/dwarf2/global-used-types.c: Specify -gdwarf-2 in
dg-options
diff --git gcc/testsuite/gcc.dg/debug/dwarf2/global-used-types.c
gcc/testsuite/gcc.dg/debug/dwarf2/global-used-types.c
index 54fa58a
Hi,
I was looking at why gcc.dg/c1x-align-3.c (test for errors, line 15) is
failing for the AVR target, and I found that the test expects _Alignas
with -__INT_MAX__ - 1 to fail with a "too large" error.
I looked at the code responsible for generating the error (c-common.c,
check_user_alignment) a
On Wed, Mar 27, 2013 at 08:43:53AM -0700, Mike Stump wrote:
> On Mar 27, 2013, at 1:02 AM, Senthil Kumar Selvaraj
> wrote:
> > global-used-types.c in gcc/testsuite/gcc.dg/debug/dwarf2 only specifies
> > -g in dg-options. For a target that is not configured to generate
> >
On Wed, Mar 27, 2013 at 03:13:13PM +, Joseph S. Myers wrote:
> On Wed, 27 Mar 2013, Senthil Kumar Selvaraj wrote:
>
> > Hi,
> >
> > I was looking at why gcc.dg/c1x-align-3.c (test for errors, line 15) is
> > failing for the AVR target, and I found that the
On Fri, Mar 29, 2013 at 02:46:49PM -0400, Jason Merrill wrote:
> On 03/28/2013 06:09 PM, Mike Stump wrote:
> >Hum… I can't help but wonder if there was supposed to be code that checks to
> >ensure dwarf is supported and the default before doing the entire test suite.
>
> That's what I thought, ye
On Mon, Apr 01, 2013 at 06:46:29PM -0700, Mike Stump wrote:
> On Apr 1, 2013, at 6:43 PM, Jason Merrill wrote:
> > On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote:
> >> I couldn't find a way to ask gcc to just generate DWARF (default
> >> version)
On Tue, Apr 02, 2013 at 11:09:12AM -0400, Jason Merrill wrote:
> On 04/02/2013 09:07 AM, Senthil Kumar Selvaraj wrote:
> >Ok, how about the following (tentative) patch? If -gdwarf- is
> >specified without any argument, it picks DWARF 4 as the default.
>
> -gdwarf- looks a
On Wed, Apr 03, 2013 at 11:07:04PM -0400, Jason Merrill wrote:
> On 04/02/2013 03:25 PM, Senthil Kumar Selvaraj wrote:
> >+gdwarf
> >+Common UInteger Var(dwarf_default_version, 4) Negative(gdwarf-)
> >+Generate debug information in the default DWARF version format
>
> T
On Thu, Apr 04, 2013 at 01:41:30PM -0400, Jason Merrill wrote:
> On 04/04/2013 11:48 AM, Senthil Kumar Selvaraj wrote:
> >+Common Var(dwarf_version, 4) Negative(gdwarf-)
>
> I don't think you need to mention the variable on this line; it's
> already there and stati
On Fri, Apr 05, 2013 at 12:02:49AM +0530, Senthil Kumar Selvaraj wrote:
> On Thu, Apr 04, 2013 at 01:41:30PM -0400, Jason Merrill wrote:
> > On 04/04/2013 11:48 AM, Senthil Kumar Selvaraj wrote:
> > >+Common Var(dwarf_version, 4) Negative(gdwarf-)
> >
> > I don&#
I noticed that there is a bunch of testcases in gcc.dg/tree-ssa
(slsr-27.c, for e.g.) that assume that the size of the integer is 4
bytes. For example, slsr-27.c has
struct x
{
int a[16];
int b[16];
int c[16];
};
and
void
f (struct x *p, unsigned int n)
{
foo (p->a[n], p->c[n], p->b[n
On Fri, Apr 26, 2013 at 10:03:43AM +0200, Richard Biener wrote:
> On Thu, Apr 25, 2013 at 6:00 PM, Mike Stump wrote:
> > On Apr 25, 2013, at 7:44 AM, Senthil Kumar Selvaraj
> > wrote:
> >> What is right way to fix these? I saw one testcase that did
> >>
>
Hi,
The help text for the --with-dwarf2 configure option says it forces
the default debug format to be DWARF 2. However, the built compiler
still produces DWARF 4, unless -gdwarf-2 is explicitly specified when
compiling.
I see that the darwin target gets around this by using the
SUBSU
On Mon, Aug 26, 2013 at 10:23:24AM +0200, Jakub Jelinek wrote:
> On Mon, Aug 26, 2013 at 01:42:18PM +0530, Senthil Kumar Selvaraj wrote:
> > The help text for the --with-dwarf2 configure option says it forces
> > the default debug format to be DWARF 2. However, the built compi
Hi,
gcc.c-torture/compile/pr34856.c and a couple of other tests segfault
for the AVR target. Looking at the code, I found that the
x_ira_register_move_cost array[TImode] is NULL, while the code goes on
to dereference it (ira_register_move_cost
[ALLOCNO_MODE (a)][best][aclass] at line 18
Ping !
Regards
Senthil
On Thu, Dec 26, 2013 at 03:11:25PM +0530, Senthil Kumar Selvaraj wrote:
> Hi,
>
> gcc.c-torture/compile/pr34856.c and a couple of other tests segfault
> for the AVR target. Looking at the code, I found that the
> x_ira_register_move_cost array[
I have been hacking a bit on dwarf2out.c to make gcc generate DWARF
information that gets discarded along with the appropriate function section
code when compiled with -ffunction-sections and then linked with
--gc-sections. Currently, debug information for discarded functions is not
removed, an
All,
gcc.c-torture/execute/pr58419.c has a call to getpid, and this causes
a linker error on the AVR (embedded) target. Is the call intentional,
and if yes, how should this be fixed for targets that don't support an
OS?
Regards
Senthil
ssage-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Senthil Kumar Selvaraj
> Sent: 27 January 2014 15:18
> To: gcc@gcc.gnu.org
> Subject: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c
>
> All,
>
> gcc.c-torture/execute/pr58419.c
On Thu, Mar 27, 2014 at 07:51:06PM -0400, Niranjan Hasabnis wrote:
> Hi DJ Delorie,
>
> Thank you for your answer. It is useful. One more question: so does the
> main testsuite cover all md entries? Meaning all possible assembly
> instructions that could be generated by that md are checked by the
Hi,
The following program, when compiled with -O0 -g3 (x86_64 target, but
doesn't seem to matter), shows wrong values for p (function parameter)
when debugging.
[saaadhu@jaguar scratch]$ cat test.c
int func(int p)
{
p = 20;
p = 30;
}
int main()
{
int local = 42;
func(local);
}
T
On Mon, Aug 06, 2012 at 01:40:57PM -0400, Frank Ch. Eigler wrote:
> Senthil Kumar Selvaraj writes:
>
> > [...]
> > The following program, when compiled with -O0 -g3 (x86_64 target, but
> > doesn't seem to matter), shows wrong values for p (function parameter)
> &
Hi,
What is the recommended way to skip specific (non target specific) testcases
for a subtargets?
There are a bunch of tests in the gcc testsuite that are too big (in
terms of code size or memory) for a subtarget of the avr target. The
subtarget is specified in the dejagnu board configurat
On Fri, Aug 10, 2012 at 09:54:17AM -0700, Janis Johnson wrote:
> On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote:
> > Hi,
> >
> > What is the recommended way to skip specific (non target specific)
> > testcases for a subtargets?
> >
> > There ar
On Sat, Aug 11, 2012 at 09:40:52AM -0700, Janis Johnson wrote:
> On 08/11/2012 09:18 AM, Senthil Kumar Selvaraj wrote:
> > On Fri, Aug 10, 2012 at 09:54:17AM -0700, Janis Johnson wrote:
> >> On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote:
> >>> Hi,
> >>
On a 64 bit machine, executing
$ make check RUNTESTFLAGS="avr-torture.exp=builtins-1.c
--target_board=atxmega128a1"
causes virtual memory allocation failure and/or large scale machine
slowdown, with cc1 using up gobs (>35G) virtual memory.
I tracked this down to
void delay_4 (void) { __builti
Some tests in gcc/testsuite/gcc.target/avr/torture (builtins-2.c, for
e.g.) have -Tavr51-flash1.x specified in dg-options. The tests currently
fail with an unable to open linker script error for that file.
Is that linker script supposed to be checked into source control? Or am
I missing some confi
Hi all,
For the AVR target, the FP register spans two registers, yet the DWARF
location information (DW_AT_location) for a local variable refers to only one
of them.
Looking at the code, I found that based_loc_descr in dwar2out.c, which handles
base+offset based location descriptions, gets
Hi,
I'm working on porting AVR to MODE_CC, and there are quite a few
patterns that clobber the condition code reg only for certain
constraint alternatives. For e.g.,
(define_insn "mov_insn"
[(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d,Qm ,r
,q,r,*r")
(match_
Pip Cet writes:
> On Sun, Aug 16, 2020 at 12:50 AM Segher Boessenkool
> wrote:
>> On Sat, Aug 15, 2020 at 10:18:27AM +, Pip Cet wrote:
>> > > > What I'm currently doing is this:
>> > > >
>> > > > (define_split
>> > > > [(set (match_operand 0 "nonimmediate_operand")
>> > > > (match_ope
Pip Cet writes:
> On Mon, Aug 17, 2020 at 7:31 AM Senthil Kumar Selvaraj
> wrote:
>> > (define_split
>> > [(parallel [(set (match_operand:ALL1 0 "nonimmediate_operand")
>> > (match_operand:ALL1 1 "nox_general_o
Hans-Peter Nilsson writes:
> On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
>> As you can deduce from the (set_attr "cc" ..), only constraint
>> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.
>
> Yes, I recognize that.
>
>>
Hans-Peter Nilsson writes:
> On Wed, 19 Aug 2020, Senthil Kumar Selvaraj wrote:
>>
>> Hans-Peter Nilsson writes:
>>
>> > On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
>> >> As you can deduce from the (set_attr "cc" ..), only
Pip Cet writes:
> On Tue, Aug 18, 2020 at 6:52 AM Senthil Kumar Selvaraj
> wrote:
>> > recognize such insns, but as it stands that define_insn would
>> > recognize the incorrect insn:
>> >
>> > [(set (reg:QI 0) (const_int 0))
>> > (clobb
45 matches
Mail list logo
