> I was wondering if any addition work had been completed toward pragma
> support for the autovectorization branch (see
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html)?
>
I think Devang was planning to continue this work - I'm not sure where it
stands
dorit
> Thanks..
>
> Chad
You are cool, now I found a
(set (reg:CC_Z 33 cc)
(compare:CC_Z (zero_extend:SI (subreg:QI (reg/v:SI 166 [ a ]) 0))
(const_int 0 [0x0])))
It's what I'm looking for.
Thank you so much.
On Mon, 2005-08-01 at 14:18 +0200, Steven Bosscher wrote:
> On Monday 01 August 2005 11:44, michael meeks wrote:
> > However - the log(s) term is rather irrelevant to my argument :-)
>
> Not really. Maybe the oprofile results for the linker show that the
> behavior is worse, or maybe better
Hi H.J.,
On Mon, 2005-08-01 at 08:55 -0700, H. J. Lu wrote:
> > -fvisibility is helpful - as the paper says, not as helpful as the old
> > -Bsymbolic (or link maps exposing only 3 or so functions) were. However
> > - -fvisibility can only help so much - if you have:
>
> Since you were comparin
On Mon, Aug 01, 2005 at 10:12:37PM -0700, Ian Lance Taylor wrote:
> Harald van D??k <[EMAIL PROTECTED]> writes:
>
> > I finally managed to track down the problem I've been having to this
> > short code:
> >
> > typedef struct {
> > unsigned car;
> > unsigned cdr;
> > } con
On 8/2/05, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 01, 2005 at 10:12:37PM -0700, Ian Lance Taylor wrote:
> > Harald van D??k <[EMAIL PROTECTED]> writes:
> >
> > > I finally managed to track down the problem I've been having to this
> > > short code:
> > >
> > > typedef struct {
>
On 8/2/05, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 8/2/05, Diego Novillo <[EMAIL PROTECTED]> wrote:
> > On Mon, Aug 01, 2005 at 10:12:37PM -0700, Ian Lance Taylor wrote:
> > > Harald van D??k <[EMAIL PROTECTED]> writes:
> > >
> > > > I finally managed to track down the problem I've been ha
On Tue, Aug 02, 2005 at 02:56:50PM +0200, Richard Guenther wrote:
> Oh, and a workaround and slight correction would be to write
>
> void nconc (unsigned x, unsigned y) {
> unsigned *ptr = &((cons *)x)->cdr;
> while(!(*ptr & 3))
> ptr = &((cons *)(*ptr))->cdr;
>
Hello. I'm not on the list, so please CC me with any replies.
I have come across a bug found during some code which serializes
doubles. The bug is only encountered when the optimization level is set
to -O2 or greater.
The bug is not encountered when compiled under
gcc (GCC) 3.3.3 200404
On Tue, Aug 02, 2005 at 09:08:51AM -0400, Diego Novillo wrote:
> On Tue, Aug 02, 2005 at 02:56:50PM +0200, Richard Guenther wrote:
> > Oh, and a workaround and slight correction would be to write
> >
> > void nconc (unsigned x, unsigned y) {
> > unsigned *ptr = &((cons *)x)->cdr;
> >
On 8/2/05, Mark Frazer <[EMAIL PROTECTED]> wrote:
> Hello. I'm not on the list, so please CC me with any replies.
>
> I have come across a bug found during some code which serializes
> doubles. The bug is only encountered when the optimization level is set
> to -O2 or greater.
>
> The bug is no
Richard Guenther <[EMAIL PROTECTED]> [05/08/02 09:29]:
> Try -fno-strict-aliasing. This may be related to PR23192.
-fno-strict-aliasing does indeed make the problem go away.
thanks!
-mark
--
Forget your stupid theme park! I'm gonna make my own! With hookers! And
blackjack! In fact, forget the
Mark Frazer <[EMAIL PROTECTED]> [05/08/02 09:18]:
> Hello. I'm not on the list, so please CC me with any replies.
>
> I have come across a bug found during some code which serializes
> doubles. The bug is only encountered when the optimization level is set
> to -O2 or greater.
Oh, I forgot to m
On Tue, Aug 02, 2005 at 10:59:01AM +0100, michael meeks wrote:
> Hi H.J.,
>
> > Why can't you you do it with ELF using a linker map? Libstdc++.so is
> > built with a linker map. Any C++ shared library should use one if the
> > startup time is a big concern. Of coursee, if gcc can generate a list
On Tue, Aug 02, 2005 at 09:39:56AM -0400, Daniel Jacobowitz wrote:
> Then the alias analyzer's broken.
>
Broken? I'm saying that we currently get this right. I don't
know what position are you arguing.
> This isn't pointer arithmetic in the sense that you mean. It
> would be if the line were:
On Tue, Aug 02, 2005 at 09:57:39AM -0400, Diego Novillo wrote:
> On Tue, Aug 02, 2005 at 09:39:56AM -0400, Daniel Jacobowitz wrote:
>
> > Then the alias analyzer's broken.
> >
> Broken? I'm saying that we currently get this right. I don't
> know what position are you arguing.
Sorry, my mistake.
On Tue, Aug 02, 2005 at 10:05:37AM -0400, Daniel Jacobowitz wrote:
> Yes, it does - well, it's implementation defined, but GCC has long
> chosen the natural interpretation. C99 6.3.2.3, paragraph 5. This is
> no different from that classic example, a pointer which escapes via
> printf/scanf.
>
Diego Novillo <[EMAIL PROTECTED]> writes:
> Does the language allow the creation of address locations out of
> arbitrary integer values?
Yes.
6.3.2.3 Pointers
5 An integer may be converted to any pointer type. [...]
> Is the dereference of such an address a defined operation?
It is i
Mark Frazer <[EMAIL PROTECTED]> [05/08/02 09:32]:
> Richard Guenther <[EMAIL PROTECTED]> [05/08/02 09:29]:
> > Try -fno-strict-aliasing. This may be related to PR23192.
>
> -fno-strict-aliasing does indeed make the problem go away.
changing the de-serialization function to:
double parse_d
On Tue, 2005-08-02 at 06:57 -0700, H. J. Lu wrote:
> Maitaining a C++ linker map isn't easy. I think gcc should help out
> here.
What do you suggest ? - something separate from the visibility markup ?
perhaps what I'm suggesting is some horribly mis-use of that. Clearly
adding a new visib
Hello All,
I applied the recent patches to the 7/23 snapshot, and am still seeing
some 387 to sse moves. In particular, in SpecFP's 177.mesa (matrix.c),
I'm seeing fld1's feeding moves to sse registers.
Compiled via: gcc -O3 -march=k8 -mfpmath=sse matrix.c
Thanks.
Tony
-Original Messag
On Aug 2, 2005, at 12:10 AM, Dorit Naishlos wrote:
I was wondering if any addition work had been completed toward pragma
support for the autovectorization branch (see
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html)?
I think Devang was planning to continue this work - I'm not sure
w
On Tue, Aug 02, 2005 at 08:32:53AM -0400, Diego Novillo wrote:
> Having said that, I sent rth a 4.0 patch for a similar bug that
> will "fix" this problem. Richard, have you applied it yet?
No, I forgot about it.
r~
On Tue, Aug 02, 2005 at 10:05:53AM -0700, Richard Henderson wrote:
> On Tue, Aug 02, 2005 at 08:32:53AM -0400, Diego Novillo wrote:
> > Having said that, I sent rth a 4.0 patch for a similar bug that
> > will "fix" this problem. Richard, have you applied it yet?
>
> No, I forgot about it.
>
That
Diego Novillo <[EMAIL PROTECTED]> writes:
> On Tue, Aug 02, 2005 at 10:05:37AM -0400, Daniel Jacobowitz wrote:
>
> > Yes, it does - well, it's implementation defined, but GCC has long
> > chosen the natural interpretation. C99 6.3.2.3, paragraph 5. This is
> > no different from that classic exa
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out->srcIPAddr = in->dstIPAddr;
... I used...
memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
... to account for the unaligned destination. This worked until gcc 4,
which now gener
Original Message
>From: Shaun Jackman
>Sent: 02 August 2005 18:33
> In a typical Ethernet/IP ARP header the source IP address is
> unaligned. Instead of using...
> out->srcIPAddr = in->dstIPAddr;
> ... I used...
> memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
> ...
[EMAIL PROTECTED] wrote:
I guess the combiner generates something like
a trucation pattern when special constant are detected.
The combiner also takse a similiar action in pattern
See the section of the documentation that talks about instruction
canonicalization.
http://gcc.gnu.org/online
Shaun Jackman <[EMAIL PROTECTED]> writes:
> In a typical Ethernet/IP ARP header the source IP address is
> unaligned. Instead of using...
> out->srcIPAddr = in->dstIPAddr;
> ... I used...
> memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
> ... to account for the unaligned de
> From: Dale Johannesen [mailto:[EMAIL PROTECTED]
>
> On Jul 21, 2005, at 5:04 PM, Tabony, Charles wrote:
>
> >> From: Dale Johannesen [mailto:[EMAIL PROTECTED]
> >>
> >> On Jul 21, 2005, at 4:36 PM, Tabony, Charles wrote:
> >>
> >>> Hi,
> >>>
> >>> I am working on a port for a processor that ha
On Aug 2, 2005, at 10:32 AM, Shaun Jackman wrote:
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out->srcIPAddr = in->dstIPAddr;
... I used...
memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
... to account for the unaligned destinati
On 8/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> In order for anyone to answer your questions about the alignment of
> various types in a struct, don't you think you should perhaps have told us a
> little about what those types actually are and how the struct is laid out?
Of course, my apologie
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as "packed" work when applied
to structs.
It would be natural to assume, as Shaun did, that marking a struct
"packed" (or, for that matter, "packed,aligned(2)") would apply that
attribute
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> One of the things that continues to baffle me (and my colleagues) is
> the bizarre way in which attributes such as "packed" work when applied
> to structs.
>
> It would be natural to assume, as Shaun did, that marking a struct
> "packed" (or, for
> > OK, thanks. That settles it then.
>
> Just to close out this thread for the record, Andrew Pinski opened PR
> 23912 for this problem, and Diego checked in a patch for the 4.0
> br
> n
> h. So all should be well in 4.0.2.
>
And the alias analyzer for 4.1 has tihs code, which is why it comes
Original Message
>From: Shaun Jackman
>Sent: 02 August 2005 20:26
> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
>> One of the things that continues to baffle me (and my colleagues) is
>> the bizarre way in which attributes such as "packed" work when applied
>> to structs.
>>
>> It
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> Original Message
>> From: Shaun Jackman Sent: 02 August 2005 20:26
>> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
>>> One of the things that continues to baffle me (and my colleagues)
>>> is the bizarre way in which at
Hi,
The number of open PRs registered as CC-3.4.x regressions only and
targetted for 3.4.5 has decreased from 125 (last week) to 115. Which
is a progress! Still, we have too many PRs for a stable branch.
Here is the complete list as communicated to me by the bugzilla mail
interface. Note t
On 8/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> There are two separate issues here:
>
> 1) Is the base of the struct aligned to the natural alignment, or can the
> struct be based at any address
The base of the struct is aligned to the natural alignment, four bytes
in this case.
> 2) Is t
> "Shaun" == Shaun Jackman <[EMAIL PROTECTED]> writes:
>> 2) Is there padding between the struct members to maintain their
>> natural alignments (on the assumption that the struct's base
>> address is aligned.)
Shaun> There is no padding. The structure is defined as
Shaun> __attribute__(
On Aug 2, 2005, at 1:15 PM, Shaun Jackman wrote:
There is no padding. The structure is defined as
__attribute__((packed)) to explicitly remove the padding. The result
is that gcc knows the unaligned four byte member is at an offset of
two bytes from the base of the struct, but uses a four byte lo
>
> On Aug 2, 2005, at 1:15 PM, Shaun Jackman wrote:
> > There is no padding. The structure is defined as
> > __attribute__((packed)) to explicitly remove the padding. The result
> > is that gcc knows the unaligned four byte member is at an offset of
> > two bytes from the base of the struct, but
Andrew Pinski <[EMAIL PROTECTED]> writes:
> > Yes, this is a compiler bug in the expansion of memcpy, please file a
> > bug report. The solution is for the compiler to notice the memory
> > alignment of the destination and `do-the-right-thing' when it isn't
> > aligned.
>
> No it is not, o
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
>> Yes, this is a compiler bug in the expansion of memcpy, please
>> file a bug report. The solution is for the compiler to notice the
>> memory alignment of the destination and `do-the-right-thing' when
>> it isn't aligned.
Andrew
Although we're still in Stage 3, it's time to start thinking about GCC
4.2. I know that many people are working on projects that they hope to
include in GCC 4.2, and it's reasonable to start gathering them. I
don't plan to actually work on ordering them in any coherent way for a
few more week
On Aug 2, 2005, at 1:37 PM, Andrew Pinski wrote:
No it is not,
:-) Ah, yes, the old, we don't have pointers to unaligned types
problem... anyway, we can at least agree that this is a gapping hole
people can drive trucks though in the type system, but I'm still
claiming it isn't a featur
On Tue, Aug 02, 2005 at 02:04:16PM -0700, Mike Stump wrote:
> Shaun, want to do up an entry in the manual describing this? We have
> known about this for years and years, but, we don't do a good job
> communicating it to users. Essentially, & doesn't work as one would
> expect on unaligned
On Aug 2, 2005, at 1:45 PM, Ian Lance Taylor wrote:
That argument doesn't make sense to me. memcpy takes a void*
argument, which has no presumed alignment.
The memcpy builtin uses the static type of the actual argument
(before conversion to void*), to gain hints about the alignments of
the
On Tue, Aug 02, 2005 at 02:29:44PM -0700, Mike Stump wrote:
> On Aug 2, 2005, at 1:45 PM, Ian Lance Taylor wrote:
> >That argument doesn't make sense to me. memcpy takes a void*
> >argument, which has no presumed alignment.
>
> The memcpy builtin uses the static type of the actual argument
> (b
On Tue, Aug 02, 2005 at 04:07:00PM -0600, Shaun Jackman wrote:
> On 8/2/05, Joe Buck <[EMAIL PROTECTED]> wrote:
> > I suppose we could make & on an unaligned project return a void*. That
> > isn't really right, but it would at least prevent the cases that we know
> > don't work from compiling.
>
On 8/2/05, Joe Buck <[EMAIL PROTECTED]> wrote:
> I suppose we could make & on an unaligned project return a void*. That
> isn't really right, but it would at least prevent the cases that we know
> don't work from compiling.
That sounds like a dangerous idea only because I'd expect...
int
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> It sounds like the workaround is to avoid memcpy, and just use
> variable assignment. Alternatively, cast the pointers to char*, which
> should force memcpy to do the right thing. Ugh.
I swear originally, back in the gcc 2.95 days, I used memcp
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> It sounds like the workaround is to avoid memcpy, and just use
> variable assignment. Alternatively, cast the pointers to char*, which
> should force memcpy to do the right thing. Ugh.
Casting to void* does not work either. gcc keeps the alignm
On 8/2/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> operator. None of these examples produce an unaligned load:
I should clarify the wording I'm using here. By "an unaligned load" I
mean code to safely load from an unaligned pointer.
Cheers,
Shaun
On Tue, 2005-08-02 at 22:07 +0200, Gabriel Dos Reis wrote:
> Hi,
>
> The number of open PRs registered as CC-3.4.x regressions only and
> targetted for 3.4.5 has decreased from 125 (last week) to 115. Which
> is a progress! Still, we have too many PRs for a stable branch.
>
> Here is the com
Snapshot gcc-3.4-20050802 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050802/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050802
You'll
Hi, all
So far, using the dataflow info (gen with df.c and df.h), I can find out the
pseudo registers use
and def in a one bb loop.
Now, need to establish a struct to record the lifetime activity of each pseudo
register in a
software pipelined loop. According to this struct, we can allocate
I have a partial success on x86_64-slackware-linux. It is partial
because it (mostly) bootstraps (see item 1) and but fails to install
(see item 2).
1. Java compilation repeatedly failed, so I dropped it from the
languages to build
2. While bootstrap succeeds, "make install" fails with the foll
Hi
Sorry if this is the wrong address to contact.
This is a minor request for a minor libmudflap problem.
Could somebody with appropriate privilege please do me a favor and reopen
the following bugzilla PR?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
It seems the system won't let me do
59 matches
Mail list logo
