Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec registers. */\
77, 78,
Revital Eres wrote on 01/03/2007 10:37:36:
>
> Hello,
>
> I wonder why this order (non-consecutive, decreasing) of Altivec
registers
> was chosen when specifying the allocation order in REG_ALLOC_ORDER.
>
> (taken from rs6000.h)
>
>/* AltiVec registers. */
Hello:
I am Jiang Hongjiang and recently I am porting the GCC backend
to a DSP, and get puzzled about the "decrement_and_branch_until_zero"
pattern.By Reading the GCC source, I find that this pattern is used in
loop optimization, and it's used under the condition of defining the
"doloop_end"
Hi,
I noticed while editing gcc files, that there are a lot of *useless*
whitespaces at the end of lines or within empty lines, which are getting
automatic removed by some *smarter* editors as I am common to use *sigh*.
This leads to huge diff files and the real change is getting veiled. I
thi
Kai Tietz wrote:
Hi,
I noticed while editing gcc files, that there are a lot of *useless*
whitespaces at the end of lines or within empty lines, which are getting
automatic removed by some *smarter* editors as I am common to use *sigh*.
This leads to huge diff files and the real change is get
> > I noticed while editing gcc files, that there are a lot of *useless*
> > whitespaces at the end of lines or within empty lines, which are getting
> > automatic removed by some *smarter* editors as I am common to use *sigh*.
> > This leads to huge diff files and the real change is getting vei
> It also forbids embedded horizontal tabs for similar reasons (avoiding
> junk difs).
That would be a problem with GCC, due to emacs being so heavily used,
but a similar convention *requiring* horizontal tabs would solve the
issue in question.
Thanks, that is what I want to hear. May it would be good point to run
over the source to be as the GNAT standard demands ?
Regards,
i.A. Kai Tietz
On 2/28/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 02/28/07 11:07:
> Is there a way to install a finalizing function? (to be called after
> all functions in the pass have been processed)
> Or to know if the current function being processed is the last one?
> (maybe if I
Paulo J. Matos wrote on 03/01/07 10:41:
My IPA pass seems to be run only for -On, n>=1, is there a way to make
it ran even for -O0?
No, we only run IPA passes if flag_unit_at_a_time is set. That only is
set when optimizing. At -O0, we simply emit functions individually.
On 3/1/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 03/01/07 10:41:
> My IPA pass seems to be run only for -On, n>=1, is there a way to make
> it ran even for -O0?
No, we only run IPA passes if flag_unit_at_a_time is set. That only is
set when optimizing. At -O0, we si
[EMAIL PROTECTED] (Richard Kenner) writes:
>> It also forbids embedded horizontal tabs for similar reasons (avoiding
>> junk difs).
>
> That would be a problem with GCC, due to emacs being so heavily used,
> but a similar convention *requiring* horizontal tabs would solve the
> issue in question.
Kai Tietz <[EMAIL PROTECTED]> writes:
> Hi,
>
> I noticed while editing gcc files, that there are a lot of *useless*
> whitespaces at the end of lines or within empty lines, which are getting
> automatic removed by some *smarter* editors as I am common to use
> *sigh*.
Well, really smart editor
"redriver jiang" <[EMAIL PROTECTED]> writes:
>I am Jiang Hongjiang and recently I am porting the GCC backend
> to a DSP, and get puzzled about the "decrement_and_branch_until_zero"
> pattern.By Reading the GCC source, I find that this pattern is used in
> loop optimization, and it's used u
Sergei Organov wrote:
Emacs could be configured either way:
(setq-default indent-tabs-mode nil)
If that is to become a policy, simply append:
// Local Variables:
// whitespace-global-mode
// indent-tabs-mode:t
// tab-width:8
// c-basic-offset:4
// End:
At the end of each file. This way, em
On Mar 1, 2007, at 12:57 AM, Tehila Meyzels wrote:
Revital Eres wrote on 01/03/2007 10:37:36:
Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec
registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec registers
Successful build/install of gcc-4.1.2 on Solaris10
The previous version of GCC used for the build was 3.4.6
I just built the compiler until I worked around the toolchain
problems: downrev gawk and missing gmp (watch 32 vs 64 bit) and mpfr.
Then a reconfig for everything built and installed in /usr
On Thu, 2007-03-01 at 15:04 +0100, Kai Tietz wrote:
> Thanks, that is what I want to hear. May it would be good point to run
> over the source to be as the GNAT standard demands ?
If I recall, Mike Stump submitted a patch once to do something like
this. His patch was not particularly popular be
> more potential conflicts between the trunk and the branch and makes
^^ branches
On 3/1/07, Mike Stump <[EMAIL PROTECTED]> wrote:
To steal an idea from llvm, if we permit post checkin review for
people that submit 100 good patches, would the wheels fall off the
bus? It seems to work for them, is there some reason why it couldn't
for us? Would it be more efficient and led to
On Mar 1, 2007, at 3:28 PM, Andrew Pinski wrote:
Also I think GCC is doing the correct thing right now with respect of
approving patches. Yes in the past we were not as good but now we
have corrected those mistakes.
So, are you saying that an 18 month review process isn't a mistake,
or that
On 3/1/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Mar 1, 2007, at 3:28 PM, Andrew Pinski wrote:
> Also I think GCC is doing the correct thing right now with respect of
> approving patches. Yes in the past we were not as good but now we
> have corrected those mistakes.
So, are you saying that
On Mar 1, 2007, at 4:51 PM, Andrew Pinski wrote:
No I am not saying that. I am saying that those patches might not
be worth commenting on.
Or, maybe they are. I think it would be better to have a policy that
addresses this issue, rather than require 18 months of silence for
someone to in
On 3/1/07, Mike Stump <[EMAIL PROTECTED]> wrote:
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
(or the target removed)
It is not, just nobody cares about that target any more, we hav
Mike Stump <[EMAIL PROTECTED]> writes:
> I don't see why:
>
>http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
>
> was a bad thing. i think gcc would have been better if it had just
> been committed.
Not fair. Zack himself says the patch is not recommended for commit,
and it just a
On Thu, 1 Mar 2007, Andrew Pinski wrote:
> No I am not saying that. I am saying that those patches might not be
> worth commenting on. If you feel they are worth commenting on, then
> comment on them but I don't see you commenting on those patches at
> all. I have not seen any patches that requ
On 02/03/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
A week is too short of time to ping a patch.
Ups! I actually believed that a week was the recommended time to ping
a patch. What is it then?
And sorry for the ping-flood then.
Manuel.
On Fri, Mar 02, 2007 at 01:31:12AM +, Manuel López-Ibáñez wrote:
> On 02/03/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> >
> >A week is too short of time to ping a patch.
> >
>
> Ups! I actually believed that a week was the recommended time to ping
> a patch. What is it then?
Sometimes the
On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
> If someone wants a patch committed they will ping it
> a couple of times and if they lost interest because they now decide it
> is not a good thing or they no longer care about it, it will just fall
> down the way side.
If it's a new
Mike Stump <[EMAIL PROTECTED]> writes:
> Likewise:
>
>http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html
This patch looks wrong to me. I don't understand how it could be
correct in the presence of __attribute__ ((aligned (N))). It checks
TYPE_PACKED but not TYPE_ALIGN or TYPE_USER_ALI
On 02/03/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Fri, Mar 02, 2007 at 01:31:12AM +, Manuel López-Ibáñez wrote:
> On 02/03/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> >
> >A week is too short of time to ping a patch.
> >
>
> Ups! I actually believed that a week was the recommended time t
On Fri, Mar 02, 2007 at 01:45:21AM +, Manuel López-Ibáñez wrote:
> On 02/03/07, Joe Buck <[EMAIL PROTECTED]> wrote:
> >On Fri, Mar 02, 2007 at 01:31:12AM +, Manuel López-Ibáñez wrote:
> >> On 02/03/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> >> >
> >> >A week is too short of time to ping
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
> > If someone wants a patch committed they will ping it
> > a couple of times and if they lost interest because they now decide it
> > is not a good thing or they no longer care about it,
Hi Ian,
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
Not fair. Zack himself says the patch is not recommended for commit,
and it just a baseline for further work. For this kin
Kazu Hirata <[EMAIL PROTECTED]> writes:
> Hi Ian,
>
> >> I don't see why:
> >>
> >>http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
> >>
> >> was a bad thing. i think gcc would have been better if it had just
> >> been committed.
> > Not fair. Zack himself says the patch is not recom
On 01 Mar 2007 18:05:50 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
> > If someone wants a patch committed they will ping it
> > a couple of times and if they lost interest becaus
On Thu, Mar 01, 2007 at 06:05:50PM -0800, Ian Lance Taylor wrote:
> One answer to that is to have patch advocates to help push patches in.
> They would need some experience with the community, but would not need
> deep technical knowledge. This would be a volunteer position, along
> the lines of t
Andrew Pinski wrote:
100 good patches != good knowledge in one area.
Also I think I already submitted 100 good patches but every once in a
while I submit a bad one though I think it is good to begin with.
To tangent off this in a rather different direction: One of the things
that I've noticed
38 matches
Mail list logo
