In the meantime, is there a simple way to disable this "more correct"
mechanism so I can get my timings?
You'll get testsuite failures if you disable it because it fixes a
bunch of bugs.
You can always disable all of PTA, but i would not recommend it.
With the attached patch, it should take l
[EMAIL PROTECTED] wrote:
> So, are we using "P1" instead to mark release-blocking bugs? Should
> we fix the severities of existing bugs?
I am using priorities to indicate how important it is to fix a bug
before the next release. This is consistent with the meanings of the
terms "priority" and "
> > There might be a subtle issue with ccache assuming that the compiler
> > that created a cache-hit object did not change. I'm only aware of
> > ccache verifying compiler versions (string compare) in the
> > hit-check, which alone doesn't suffice to guarantee that the cache
> > is (or should be)
> On a somewhat related note, I'd be interested to hear if ccache
> could be snuck into bootstrapping to speed up recompiles in the
> intermediate stages, especially with incremental changes. (Anyone
> tried this?) I've noted that ccache-ing only speeds up the first
> stage, as one would expect.
It isn't only on the AVR that bswap_32() is nontrivial to get
right.
These two versions would rule on the i386 if GCC would be just a
little bit
smarter:
I prefer the single instruction bswap that we now generate for
__builtin_bswap[32,64] myself...
-eric
> Can any one get me the information/implementation of below mentioned
> functions?
>
> 1. operands[0] = gen_rtx_REG (SImode,REGNO (set_dest));
> 2. operands[0] = gen_highpart (SImode, set_dest);
Sure, emit-rtl.c, lines 488 and 1165.
Ben
> Let me know if that works for you.
After applying the Andrew Pinski's patch for pr29879, the build of snapshot
20061118 went without problem on OSX 10.3.9. So your patch fixes the
problem I have reported. Thanks a lot.
If I may abuse of the situation, I am using the following patches:
Index:
Hello,
> I'm running into some troubles with an if-conversion pass that runs
> after reload, where we have to avoid lifting insns across a loop
> exit edge into a loop. ifcvt.c uses flow_loops_find to find loops
> and mark all loop exit edges:
>
> if ((! targetm.cannot_modify_jumps_p ())
>
On Fri, Nov 17, 2006 at 04:30:53PM -0700, Shaun Jackman wrote:
> Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
> with -O2.
>
> I won't bother to show bswap_32 here, which produces a real disaster!
> Think 47 instructions, for what should be 6.
You may get better code i
On Sun, Nov 19, 2006 at 08:31:22AM -0700, Eric Weddington wrote:
> Rask, do you have FSF paperwork in place?
Yes, it was completed recently.
--
Rask Ingemann Lambertsen
On 19 November 2006 16:07, Gerald Pfeifer wrote:
> On Wed, 4 Oct 2006, Daniel Jacobowitz wrote:
"This file can be found in the same directory that
contains cc1 (run gcc -print-prog-name=cc1 to find it)."
>>> I think that indicates someone trying to be overly clever when they
On 11/15/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
> > >
> > > * gimplify.c (fold_indirect_ref_rhs): Use
>
On Wed, 4 Oct 2006, Daniel Jacobowitz wrote:
>>> "This file can be found in the same directory that
>>> contains cc1 (run gcc -print-prog-name=cc1 to find it)."
>> I think that indicates someone trying to be overly clever when they
>> configured your gcc package. Normally libdir and l
> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 19, 2006 3:55 AM
> To: Eric Weddington
> Cc: Paul Brook; gcc@gcc.gnu.org; Shaun Jackman;
> avr-gcc-list@nongnu.org
> Subject: Re: [avr-gcc-list] Re: AVR byte swap optimization
>
> On 11/19/
Bruce,
On Thu, 19 Oct 2006, Bruce Korb wrote:
> I was going to re-subscribe my dropped subscription to gcc-patches,
> but the only links (that I can find) on gcc.gnu.org lead to the archives,
> not to the subscription page. Thanks - Bruce
I understand your immediate issue has been addressed alre
On Mon, 6 Nov 2006, Ian Lance Taylor wrote:
> gcc always supports "long long" for all targets.
I just noticed that while the base compiler may support "long long", this
extension fails to interact well with at least one other extension: hash_map<>
in libstdc++.
Specifically, the following exampl
> On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote:
> > while speaking about uninitialized variables gcc developers probably
want
> > to look at their own sources first:
> > gcc/testsuite/gcc.dg/vect/vect-27.c
>
> If any code in the testsuite is broken, it should be changed.
should be f
On 11/19/06, Eric Weddington <[EMAIL PROTECTED]> wrote:
> Use gcc head, __builtin_bswap and make sure the AVR backend
> implements the
> bswap rtl patterns.
There's the problem. You can't just glibly say "make sure the AVR backend
implements the bswap rtl patterns". There are precious few volunt
--- Begin Message ---
Hi,
if I define this type:
typedef unsigned char UCHAR __attribute__((aligned(32)));
void func(void) {
char example;
UCHAR vector[40];
...
}
The vector array is 4 byte alignment in any case?
Regards Michael
--- End Message ---
19 matches
Mail list logo
