> -Original Message-
> From: DJ Delorie [mailto:d...@redhat.com]
> Sent: 11 October 2013 19:19
> To: Paulo Matos
> Cc: richard.guent...@gmail.com; gcc@gcc.gnu.org
> Subject: Re: Invalid tree node causes segfault in diagnostic
>
>
> > While I am at it, can
ct dependence? Why?
--
Paulo Matos
e higher than 'a' (unsigned int) and the loop can't possibly be
infinite.
Does anybody know why GCC is behaving this way?
Paulo Matos
> -Original Message-
> From: Andrew Haley [mailto:a...@redhat.com]
> Sent: 13 November 2013 15:56
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> On 11/13/2013 03:48 PM, Paulo Matos wrote:
>
> Bec
definitely missing something.
Can someone please clarify?
Paulo Matos
Paulo Matos
> -Original Message-
> From: Alan Modra [mailto:amo...@gmail.com]
> Sent: 22 November 2013 04:42
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: rs6000: load_multiple code
>
> On Wed, Nov 20, 2013 at 05:06:13PM +, Paulo Matos wrote:
&
de on
our machine? I am quite confused about what fault it could happen in
BIGGEST_ALIGNMENT is violated, therefore for our machine I guess
BIGGEST_ALIGNMENT can be as high as possible.
Paulo Matos
}
+ else if (GET_MODE_CLASS (rsp->last_set_mode) == MODE_INT
+ && GET_MODE_CLASS (mode) == MODE_INT
+ && GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
(mode))
+return NULL;
tem = get_last_value (x);
Fixed the problem. Any comments?
If you have no comments and like the patch I will submit it formally to
gcc-patches.
Paulo Matos
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 27 November 2013 18:27
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: reg_nonzero_bits_for_combine misunderstood
>
> > But the problem is that if the mode of the regis
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 28 November 2013 11:27
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: reg_nonzero_bits_for_combine misunderstood
>
> > Right, didn't notice nonzero_sign_valid
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 13 November 2013 16:14
> To: Andrew Haley
> Cc: gcc@gcc.gnu.org
> Subject: RE: Infinite number of iterations in loop [v850, mep]
>
> > -
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 08 January 2014 11:03
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> That was refering to the case
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 08 January 2014 14:42
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> Well. We ha
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 08 January 2014 14:42
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> Well. We ha
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 08 January 2014 14:42
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> On Wed, Jan 8, 2014
ormance on my port drops drastically.
What are your thoughts?
Note: I just noticed this doesn't happen in trunk anymore. Any idea of what
went into trunk to fix this?
Paulo Matos
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 10 January 2014 13:25
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Useless statement in loop latch looks like performance regression
>
> Most likely c
goto bb3 else bb4
bb3:
r3 <- r2 << 1
goto bb4
bb4:
...
...
if ... goto bb4 else bb5
Is there any way already implemented to find the value of (and (plus r1 r3)
(const_int 1)) at the end of bb4 and simplify it to (const_int 0)?
Cheers,
Paulo Matos
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: 14 January 2014 13:45
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Context dependent expression simplification
>
> On Tue, Jan 14, 2014 at 01:40:36PM +, Paulo Matos wrot
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 09 January 2014 16:48
> To: Richard Biener
> Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
> Subject: RE: Infinite number of iterations in loop [v850,
GET_MODE_SIZE (from) < GET_MODE_SIZE (to) but it
didn't help.
Any suggestions for a generic solution?
Paulo Matos
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 17 January 2014 16:23
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Avoiding paradoxical subregs
>
> > I can use canonicalize_comparison like s390 to remove the subreg, ho
amp;& GET_MODE_SIZE (outermode) <= GET_MODE_SIZE (GET_MODE (op))
+ && !VECTOR_MODE_P (GET_MODE (XEXP (op, 0
return adjust_address_nv (op, outermode, byte);
/* Handle complex values represented as CONCAT
Comments?
Paulo Matos
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 10:46
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
>
> Paulo Matos writes:
> > Hello,
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 12:21
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
>
> Just in case: the point I was tryi
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 16:34
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
>
> Paulo Matos writes:
> >> If we
ong these lines:
(set (subreg:V2HI (match_dup 0) 0)
(rotate:V2HI (subreg:V2HI (match_dup 1) 0)
(const_int 8)))
(set (match_dup 0)
(rotate:SI (match_dup 0)
(const_int 16)))
Is there a better way to handle a situation like this?
Cheers,
Paulo Matos
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 27 January 2014 16:06
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Mode change for bswap pattern expansion
>
> Paulo Matos writes:
> > On a vector processo
> -Original Message-
> From: Richard Sandiford [mailto:rsand...@linux.vnet.ibm.com]
> Sent: 27 January 2014 16:50
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Mode change for bswap pattern expansion
>
> Sorry, I meant we use an unspec for the firs
s not in mainline.
Does anyone understand why the mentioned patch is forcing the generation of the
sign extend inside the loop? Is this just a problem with cost calculation in
the backends or some issue lurking in tree-ssa-loop-ivopts?
Thanks,
Paulo Matos
> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: 30 January 2014 14:29
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks
> zero-overhead
> loop generation
>
> Pa
> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: 30 January 2014 15:15
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks
> zero-overhead
> loop generation
>
>
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: 30 January 2014 15:50
> To: Paulo Matos; Andreas Schwab
> Cc: gcc@gcc.gnu.org
> Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks
> zero-overhead
> loop generation
>
> &
Since the owner of the repo http://gcc.gnu.org/git/?p=gcc.git;a=summary is
marked as being: gcc@gcc.gnu.org
moving this thread of the gcc mailing list.
Paulo Matos
-Original Message-
From: gcc-help-ow...@gcc.gnu.org [mailto:gcc-help-ow...@gcc.gnu.org] On Behalf
Of Paulo Matos
Sent: 04
patch and its possible integration
into upstream (I guess it can only go upstream once 4.9 is released, right?).
I bootstrapped and tested x86_64-unknown-linux-gnu with no regressions.
Thanks,
Paulo Matos
simplify-using-context.patch
Description: simplify-using-context.patch
optimizations.
Should we mark it as such?
Cheers,
Paulo Matos
as an optimization?
I think we should.
I will submit a patch to gcc-patches.
Thanks,
--
Paulo Matos
) a21(r120,l0) a22(r119,l0) a23(r114,l0) a24(r118,l0) a25(r117,l0)
a26(r113,l0) a28(r116,l0)
;; total conflict hard regs: 0 20-25
;; conflict hard regs: 0 20-25
Why is r122 conflicting with r0? r0 is dead in insn 21, I can't see a reason
for conflict.
Is there something I am missin
property? Do you agree?
Cheers,
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 11 March 2014 10:52
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: dom requires PROP_loops
>
> On Mon, Mar 10, 2014 at 12:57 PM, Paulo Matos wrote:
> > Hello,
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 13 March 2014 11:21
> To: Richard Biener
> Cc: gcc@gcc.gnu.org
> Subject: RE: dom requires PROP_loops
>
>
> PROP_loops is enabled from tree
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 13 March 2014 13:24
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: dom requires PROP_loops
>
>
> Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanu
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 13 March 2014 18:46
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: dom requires PROP_loops
>
> On March 13, 2014 5:00:53 PM CET, Paulo Matos wrote:
> >> ---
) != USE
&& GET_CODE (PATTERN (insn)) != CLOBBER;
}
It is clear that someone [Steven Bosscher] thought it needs fixing but what's
the problem with just removing it from the OR-expression?
Cheers,
Paulo Matos
^
I was expecting a warning for bar as well since sizeof unsigned char is 1 and
sizeof enum xpto is 2, therefore the value is truncated but no warning is
issued.
Shall I open a PR?
Paulo Matos
> -Original Message-
> From: David Brown [mailto:da...@westcontrol.com]
> Sent: 19 March 2014 14:44
> To: Paulo Matos; gcc@gcc.gnu.org
> Subject: Re: returning short-enum and truncate doesn't trigger
> conversion warning
>
> On 19/03/14 15:33, Paulo Matos wr
> -Original Message-
> From: David Brown [mailto:da...@westcontrol.com]
> Sent: 19 March 2014 15:47
> To: Paulo Matos; gcc@gcc.gnu.org
> Subject: Re: returning short-enum and truncate doesn't trigger
> conversion warning
>
>
> Usually the discovery of
Hi,
Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such that jumps
are not modified after sched2?
Or in other words, is there a way to recognize if sched2 has already been ran
(sched2_completed, maybe)?
Cheers,
Paulo Matos
DENTIFIER_NODE. Is this the case?
Paulo Matos
>
> I think the bug is in the documentation, and that
> TARGET_ASM_NAMED_SECTION should accept an IDENTIFIER_NODE.
>
> Ian
I will be reporting this with bugzilla then.
Thanks for the clarification,
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 19 October 2012 09:29
> To: Paulo Matos
> Cc: Ian Lance Taylor; gcc@gcc.gnu.org
> Subject: Re: Inconsistency between code and docs
>
> On Fri, Oct 19, 2012 at 10:28
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 19 October 2012 09:29
> To: Paulo Matos
> Cc: Ian Lance Taylor; gcc@gcc.gnu.org
> Subject: Re: Inconsistency between code and docs
>
> Can you instead produce a patch?
>
literal to be used with asm.
Since this is most likely a problem with the docs, how can I achieve something
like this and have only a string literal as value or TEXT_SECTION_ASM_OP?
Cheers,
Paulo Matos
Does this happen after gcc command line
arguments are read or at gcc's compile time?
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paulo Matos
> Sent: 23 October 2012 12:08
> To: gcc@gcc.gnu.org
&g
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paulo Matos
> Sent: 23 October 2012 14:47
> To: gcc@gcc.gnu.org
> Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP
>
> This sentence is quite confusing. &
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Joseph S. Myers
> Sent: 23 October 2012 15:28
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Documentation problem with TEXT_SECTION_ASM_OP
>
> At &
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Joseph S. Myers
> Sent: 23 October 2012 15:28
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Documentation problem with TEXT_SECTION_ASM_OP
>
> So far only
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Joseph S. Myers
> Sent: 23 October 2012 15:28
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Documentation problem with TEXT_SECTION_ASM_OP
>
> conversions
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: 24 October 2012 13:32
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP
>
> On Wed, 24 Oct 2012, Paulo Matos wrote:
&g
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: 24 October 2012 13:32
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP
>
> I don't like this #else. Presumably the
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: 24 October 2012 13:32
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP
>
>
> I don't like this #else. Presumably
about which hook can be used to tell the
scheduler about this.
--
Paulo Matos
> -Original Message-
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: 05 November 2012 16:32
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Defining scheduling resource constraint
>
> > This cannot happen, but I am unsure about
> -Original Message-
> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
> Sent: 05 November 2012 16:52
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Defining scheduling resource constraint
>
> Depends on why it schedules them in the same cycle. Ei
> -Original Message-
> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
> Sent: 05 November 2012 16:52
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Defining scheduling resource constraint
>
> Depends on why it schedules them in the same cycle. Ei
> -Original Message-
> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
> Sent: 06 November 2012 17:12
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Defining scheduling resource constraint
>
> On 11/06/2012 05:50 PM, Paulo Matos wrote:
>
> &g
> -Original Message-
> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
> Sent: 07 November 2012 10:48
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Defining scheduling resource constraint
>
> Yes... I seem to remember the documentation is just wrong
> -Original Message-
> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
> Sent: 07 November 2012 11:24
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Defining scheduling resource constraint
>
>
> You can effectively remove it by returning zero if a
on is, why do we need to exclude
is_lang_specific(expr) from streamable trees and is there a workaround to allow
this without changing the core?
Paulo Matos
as an argument to this function and GET_CODE (pat) == COND_EXEC
generates the seg fault.
My question is, given it is a forced label, it seems to me that we really
shouldn't delete the label. Is there a missed constraint in the condition above
and therefore some further checks in scheduling?
Paulo Matos
).").
The hook TARGET_VECTORIZE_BUILTIN_CONVERSION sounds like it could be what I
want but I added some test code and in my simple example this function is never
called.
Any suggestions on how to work this out in the backend?
Cheers,
Paulo Matos
Is the lack of replies a sign that I missed to explain something in my email?
Cheers,
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 29 November 2012 17:04
> To: gcc@gcc.gnu.org
> S
seems to be a manifestation of PR32335, where the extra assignment to the
same register (in this case r57) is added by auto_inc_dec analysis and not
explicit in the parallel.
Has anyone come across this before?
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 19 December 2012 17:00
> To: gcc@gcc.gnu.org
> Subject: cselib_record_set breaks due to auto_inc_dec
>
> Hi,
>
> After pro and epil
ones that add the expression to the expr list of the insn when we
add the prologue insn for debug purposes but we don't expect cselib through
dse2 to assume the insn in the expr list to be an extra set.
Is it not allowed to add expressions onto an insn expr list?
--
Paulo Matos
prev_mode = vec_mode;
if (!CONVERT_EXPR_CODE_P (code))
return false;
Is there any reason we only proceed for convert expr codes?
Thanks,
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 25 January 2013 15:59
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: autovectorizer doesn't support multistep widen mult
>
> On Fri, Jan 25, 2013 at 4:13 PM,
27;t think I am doing anything wrong.
If you confirm that this is a bug and no infinite loop should occur I will
write a bug report. I will, in the meantime, look at the genattrtab.c code and
try to find an explanation for this.
Thanks,
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 11 February 2013 10:56
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: genattrtab regression: infinite loop
>
>
> Does it work with -fno-aggressive-loop-optimizat
ks at all the attributes and
instructions, it accumulates all possible values for each attribute, so the
list of attribute values for fpsize and fplength are indeed dependent on each
other even though in the context of br_pred, they are not inter-dependent
because we fixed the value of fplength
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 11 February 2013 15:25
> To: Paulo Matos
> Cc: Richard Biener; gcc@gcc.gnu.org
> Subject: RE: genattrtab regression: infinite loop
>
> Only by giving a nicer error message than an infinite loo
milar constraint. Have I missed a backend that has similar requirements? If
not, is there any way to currently (as of HEAD) model this in GCC?
Thanks,
Paulo Matos
101 - 182 of 182 matches
Mail list logo
