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
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
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.
>
>>
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
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
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_
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 &
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
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
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
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
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
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
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
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,
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 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
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
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
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
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
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[
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
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,
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 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
> >>
>
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 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&#
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 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 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 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 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 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 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
> >
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
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 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
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
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
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 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
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 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,
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
45 matches
Mail list logo
