On Wed, Apr 9, 2008 at 3:28 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Continuation of the last one, different bug, building libstdc++ ...
> Look familiar to anyone? If not, I'll try to hunt down the cause.
> The culprit is this line:
>
> D.25530 = (unsigned int) D.25529;
>
> For m32cm,
On Wed, Apr 9, 2008 at 8:10 AM, Pranav Bhandarkar
<[EMAIL PROTECTED]> wrote:
> > Btw, I have a fix.
>
> oh gr8. I just saw your post on the gcc-patches. Do you still want me
> to add this to PR35163 for the record ?
Yes, IMHO it will be helpful if anyone is digging in these bugzillas.
Thanks,
Dear gcc users and developers,
This might be a stupid question, nevertheless...
I've been wondering for a long time, why the behaviour of
variable-length arrays w.r.t. the sizeof operator is different
for local/auto variables and for function arguments (in C99):
#include
void foo(int s, in
Hi Andrew,
I've been looking at doing this possibly in the store sinking pass and
have the following query as below.
On Mon, Apr 7, 2008 at 9:11 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 3:31 AM, Ramana Radhakrishnan <[EMAIL PROTECTED]>
> wrote:
> > The basic case i
[EMAIL PROTECTED] wrote:
> Dear gcc users and developers,
>
> This might be a stupid question, nevertheless...
>
> I've been wondering for a long time, why the behaviour of
> variable-length arrays w.r.t. the sizeof operator is different
> for local/auto variables and for function arguments
> You'd want to avoid translating from tuples back to nested trees. Instead
> when
> expanding from SSA form (ok, let's make that "semi"-SSA form that just keeps
> the UD chains but gets rid of PHI nodes (and maybe overlapping life ranges))
> the expander can do expression combining by follow
> Depends on what SSA form you want. A rewriting form is problematic because
> backends are allowed to modify the IL behind the back of the optimizers and
> can emit instructions that are difficult/impossible to represent in SSA form
> (parallel).
I don't exactly know what rewriting SSA form mea
FYI: my h8/300h builds are failing with the same message, but with
different types. Haven't investigated yet.
> What size is the internal 'sizetype'?
16 bits.
> Is there an integer type with the same width as the pointer type?
No. The m32c doesn't have enough operators to have a pointer-size
Hello all,
For a target that i porting in gcc 4.1.2 i am getting the following
assert failure :
internal compiler error: in schedule_region, at sched-rgn.c:2413
This is due to the following line
gcc_assert (sched_rgn_n_insns == rgn_n_insns);
I executed the program with -O2 option. When -fno-sc
On Wed, Apr 09, 2008 at 01:22:15PM +0100, Andrew Haley wrote:
> [EMAIL PROTECTED] wrote:
> > Dear gcc users and developers,
> >
> > This might be a stupid question, nevertheless...
> >
> > I've been wondering for a long time, why the behaviour of
> > variable-length arrays w.r.t. the sizeof
On Wed, Apr 9, 2008 at 4:05 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> FYI: my h8/300h builds are failing with the same message, but with
> different types. Haven't investigated yet.
>
>
> > What size is the internal 'sizetype'?
>
> 16 bits.
>
>
> > Is there an integer type with the same w
[Putting the gcc-list back in CC:, ]
Le mardi 08 avril 2008 à 18:24 -0400, DJ Delorie a écrit :
> Do you have one insn for each pair of src/dest that movqi supports?
> If so, this isn't the best way to do it - you should have one insn
> with multiple constraint alternativess, not multiple insns.
> switch (which_alternative) {
> case 0: /* register to register */
Better to just use the @ syntax that gcc offers, to provide multiple
patterns:
"@
tfr %0,%1
ldih %0, hi(%1); ldil %0, lo(%1)
ldih %0, hi(%1); ldil %0, lo(%1
Sigh, I cleaned out my local patches and now I'm tripping over this again:
if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
&& arg0 && arg1 && tt && POINTER_TYPE_P (tt))
gcc_assert (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
INTEGER_CST);
I had locall
Ben Elliston wrote:
C++ is not supported because this proposal came from WG14 (which is not
the C++ working group, WG21). There is no such proposal from the C++
folks.
I don't know that implementing this right away in the C++ front-end is
such a great idea.
I agree. Much to my dismay, the C
Le mercredi 09 avril 2008 à 12:41 -0400, DJ Delorie a écrit :
> > switch (which_alternative) {
> > case 0: /* register to register */
>
> Better to just use the @ syntax that gcc offers, to provide multiple
> patterns:
>
> "@
> tfr %0,%1
>
Robert C. Seacord wrote:
> void f(char *buf) {
> unsigned int len = len = 0xFF00;
>
> if (buf+len < buf) puts("true");
>
> }
You need to be more precise. That is not the same example
that you quoted for GCC.
In fact, if you vary the criteria too much, you will find
situations where GCC
I tracked it down to this:
/* Allow conversions between integral types and pointers only if
there is no sign or zero extension involved. */
if (((POINTER_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (op)))
|| (POINTER_TYPE_P (TREE_TYPE (op)) && INTEGRAL_TY
Le mercredi 09 avril 2008 à 21:19 +0200, Stelian Pop a écrit :
> > You might need to define LEGITIMIZE_RELOAD_ADDRESS, or at least
> > LEGITIMIZE_ADDRESS. I don't know if reload has assumptions about such
> > offsets, but the m32c port has a limit on the offset range so it might
> > help you fig
> > All the links your reference later in your email are actually dead
> > links, from the documentation pre-Docbook. IMHO they should not be
> > part of the libstdc++ online docs at all, but I don't know how to
> > remove them.
>
> That should happen automatically, as far as I can tell, now that
> Maybe I should reserve a special register for this usage (say r0).
That might be the only way, yes.
Note that reload also assumes that such adds don't change the flags
(i.e. a compare/jump pair must not have a flag-modifying add between
them).
Snapshot gcc-4.2-20080409 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080409/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, 4 Apr 2008, Michael Eager wrote:
> Xilinx has a PowerPC 405 processor with an attached
> single precision floating point processor. I have a
> patch which supports this FP unit, but want to clean
> it up a bit before submitting it.
What do you propose as the function call and return ABI
Joseph S. Myers wrote:
On Fri, 4 Apr 2008, Michael Eager wrote:
Xilinx has a PowerPC 405 processor with an attached
single precision floating point processor. I have a
patch which supports this FP unit, but want to clean
it up a bit before submitting it.
What do you propose as the function c
I came across the following problem when trying to instrument the program.
If I take the address of trees using build_fold_addr_expr at O2 the
compiled programs
crash (segmentation fault) at runtime. They run OK at O0. In this
particular case I only took
the addresses of var_decl and parm_decl nod
Hi Mark
> I agree. Much to my dismay, the C and C++ committees don't seem to be
> willing to work together to make sure that C remains a subset of C++.
I'm afraid my patch doesn't address that. :-)
> Ben, to answer your original question, I don't think that lack of nested
> address spaces i
Hello,
I am a beginner interested in learning gcc internals and contributing
to the community.
I have started implementing PR35423 - omp workshare in the fortran
front-end. I have some questions - any guidance and suggestions are
welcome:
- For scalar assignments, wrapping them in OMP_SINGLE cla
-- Forwarded message --
From: Sandeep Maram <[EMAIL PROTECTED]>
Date: Thu, Apr 10, 2008 at 11:57 AM
Subject: Re: Fusing two loops
To: Zdenek Dvorak <[EMAIL PROTECTED]>
Hi Zdenek,
I have written this function
/* The following function fuses two loops. */
void
fuse_loops (st
28 matches
Mail list logo
