k8==0xff and
*(_back8-1)&0x80)
_back8--;
//debug_msg(String("Force i\n")+i.dump());
_buffer.assign(_front8, _back8+1);
}
Any thoughts on how to proceed?
Andrew Walrond
On Mon, Jun 12, 2006 at 12:32:36PM +0100, Andrew Haley wrote:
> [EMAIL PROTECTED] writes:
> > I want a reduced test case for this problem for bugzilla, but don't
> > really know the exact cause. I _think_ code is being improperly
> > optimized away, but I don't k
On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
>
> I'm starting to be a little suspicious about host2little(). I wonder
> if that's well-defined.
>
> I'm just guessing here becasue I can't see the code. Is it possible
template T swa
On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> >>
> >> I'm starting to be a little suspicious about host2little().
On Mon, Jun 12, 2006 at 12:30:50PM +, [EMAIL PROTECTED] wrote:
> On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> >
On Mon, Jun 12, 2006 at 01:40:18PM +0100, Andrew Haley wrote:
> [EMAIL PROTECTED] writes:
> > On Mon, Jun 12, 2006 at 12:30:50PM +, [EMAIL PROTECTED] wrote:
> > > On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > > > On 6/12/06, [EMAI
l of its examples, it would simply add esi, edi and ecx to the
clobber list, but that seems illegal now; anything mentioned in inputs
or outputs cannot appear in the clobber list it seems.)
Thanks,
Andrew Walrond
"+S" (_src), "+D" (_dst), "+c" (_numwords)
// Inputs - specify same registers as outputs
: "0" (_src), "1" (_dst), "2" (_numwords)
// Clobbers: direction flag, so "cc", and "memory"
: "cc", "memory"
);
}
Thanks
Andrew Walrond
sn't compile ;(
The correct version is I think,
void longcpy(long* _dst, long* _src, unsigned _numwords)
{
asm volatile (
"cld \n\t"
"rep \n\t"
"movsl \n\t"
// Outputs (read/write)
: "=S" (_src), "=D" (_dst), "=c" (_numwords)
// Inputs - specify same registers as outputs
: "0" (_src), "1" (_dst), "2" (_numwords)
// Clobbers: direction flag, so "cc", and "memory"
: "cc", "memory"
);
}
> Thanks
>
> Andrew Walrond
On Tue, Jun 13, 2006 at 12:01:39PM +0100, Andrew Haley wrote:
>
> All you've got here is an inline asm version of
>
> inline void longcpy(long* _dst, long* _src, unsigned _numwords)
> {
> __builtin_memcpy (_dst, _src, _numwords * sizeof (long));
> }
>
> w
Filter*'
test.cpp:36: error: initializing argument 2 of 'Bifilter::Bifilter(Filter*,
Filter*,Bifilter::DestructorAction)'
Am I missing something (as usual!) or is this a bug?
Andrew Walrond
No negative responses, so I'll enter it in bugzilla.
Andrew Walrond
n = KEEP_ON_DESTRUCTION
);
...
Tricksy ;)
Andrew Walrond
configure test which simply compiles this line:
__thread int foo;
and that configure test must succeed for HAVE_TLS to be set. So, to
fix this we need to find out if that program did compile, and if so,
how.
--disable-tls in the configure line might solve your problem.
Andrew.
bug report, the problem is that CC1_SPEC
is the wrong one.
Adding EB/EL to CPP_SPEC will only fix the C/C++/Objective-C front-ends
and no others.
The attached patch is the more correct way to solve this.
Thanks,
Andrew Pinski
Index: mips.h
gt; }
This should error out and it is a regression from previous versions (I
can check which ones but I think 3.4.0 rejected it). The two targets
that I work on daily at work (including the language extension
specifications), both say this is invalid code and should be rejected.
Thanks,
Andrew Pinski
me thing because I just made sure
of it last week when I was editing that specifications.
Thanks,
Andrew Pinski
ET_CC1_SPEC "%{profile:-p}"
+
/* If we don't set MASK_ABICALLS, we can't default to PIC. */
#undef TARGET_DEFAULT
#define TARGET_DEFAULT MASK_ABICALLS
Thanks,
Andrew Pinski
T_CC1_SPEC is a good second idea of where it
should be defined.
Thanks,
Andrew Pinski
abort ();
> exit (0);
> }
>
> This bug was fixed previously.
> 1. Can i get more information on how the bug was fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6997
> 2. what does sleu pattern mean?
Set if Lessthan or Equal Unsigned.
Andrew.
>
> With svn r117549 bootstrapped on mipsel-none-linux-gnu:
Usually people us gcc_update in contrib to update their
sources which fixes this problem by touching the files
which need to be touched.
Thanks,
Andrew Pinski
On Sat, 2006-10-14 at 21:14 +0100, Martin Michlmayr wrote:
> There have been some discussions recently about a possible release of
> 4.1.2 in the near future and the following information might be useful
> in this debate. Matthias Klose asked me to test 4.1.2 20061007 to
> see whether it can be us
testing ignore.
-- Pinski
> On 17/10/2006, at 11:45 AM, Jack Howarth wrote:
>
> > Geoff,
> >I noticed that the automake maintainers
> > accepted your patch for fixing the multilib
> > issues in automake. However they also seemed
> > to indicate that there would be no more 1.9.x
> > automake releases.
> >Is the r117
s whose
names contain '$' chracaters.
Andrew.
>
> msched-epilog
> Target Undocumented Var(TARGET_SCHED_PROLOG) VarExists
>
> This appears of course to be wrong.
Did you miss VarExists part of line?
Thanks,
Andrew Pinski
which can be found at
http://www.codesourcery.com/cxx-abi/ .
Thanks,
Andrew Pinski
You can have a whole program in one source module so the warning would
get in the way of that case. Plus -combine is useless in that case
also. In fact -combine will go away once LTO finishes.
Thanks,
Andrew Pinski
branching checklist.
As I understand it, it involves editing the mysql database by hand (well
by a script) instead of doing it inside bugzilla. Daniel Berlin has
done that the last couple of releases.
Thanks,
Andrew Pinski
n
you are noticing here is called forward propagation.
Thanks,
Andrew Pinski
>
> It seems that the GMP test is always run, even when installing binutils
> or gdb.
>
> You probably need something like
>
> if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
> ...
> fi
>
> but I think that the whole test now belongs in the GCC subdirectory, not
> in the topleve
>
>
> >> if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
> >> ...
> >> fi
> >>
> >> but I think that the whole test now belongs in the GCC subdirectory, not
> >> in the toplevel (it was anyway a hack for the sake of disabling Fortran).
> >
> > Moving it is not really a good thing
od?
Find how and what? Find the FUNCTION_DECL? (you should already have
that.) Find the body of the function? (function decl has that.) Find
where the function is defined in the source? (the lotus of the function
decl should say where that is).
Thanks,
Andrew Pinski
o CFG at the time you are looking
through the calls.
Why do you need to know the constructor anyways?
Thanks,
Andrew Pinski
On Wed, 2006-10-25 at 13:32 +0900, Paolo Bonzini wrote:
> > I'm more content with the gmp check at the top level and don't plan to
> > submit a change to that. Although I agree if this configure is shared
> > between binutils, gdb and gcc, and you're not compiling gcc, then it
> > shouldn't requir
toplevel
seems correct, maybe someone should add a plugin for the toplevel
configure so we don't end up in a case where they compile for hours and
then find out they need a program or a library installed.
For right now I say we keep this at the toplevel until that gets solved.
Thanks,
Andrew Pinski
On Wed, 2006-10-25 at 14:14 +0900, Paolo Bonzini wrote:
> Not as bad as you put it, if installing and typing "make" solves the
> issue (either for zip/unzip or gmp/mpfr, it is the same). I'll let the
> maintainers decide.
See my other email which explains why it is not user friendly. Waiting
2
e want to continue to perform this
unsafe optimization on our release branch until we are sure that
removing it doesn't cause performance regressions. And, perhaps, if
removing the optimization does cause performance regressions we won't
remove it, preferring bad code to reduced performance.
Is that a fair summary? Perhaps I'm misunderstanding what you wrote.
Andrew.
>
> > and seeing the reaction of people,
> > I probably won't use it. The main reason for considering to use
> > the tree node for me was the possibility to make the number of iterations
> > of the loop as its operand, so that I would not need to worry about
> > keeping it alive through dce, copy
The question now has come to the following point:
Do we want to explict in the IR or have a side table which we use to mark the
SSA_NAME as still useful.
They both have pros and cons. But I say we want to be as explict in the IR
as possible.
Thanks,
Andrew Pinski
PS sorry about my return email add
On Thu, 2006-10-26 at 17:37 -0300, [EMAIL PROTECTED] wrote:
> Hi, I've come with a problem with g++ 4.1.1 and people at gcc-help said
> they think it's a bug, so I'll forward my original email to this list.
And this is the same issue as PR 11407, http://gcc.gnu.org/PR11407 .
-- Pinski
don't call fold but call the other functions, fold_buildN or fold_unary/binary,
etc. instead.
Also some tree optimizers use fold to calculate stuff like how many interations
a loop can run for so the number is bit useless in general if you gather it via
fold directly.
Why do what to know how many simplifications has happened?
Thanks,
Andrew Pinski
On Mon, 2006-10-30 at 09:57 -0800, Geoffrey Keating wrote:
> Hi Kaveh,
>
> 1. Is this intentional?
Yes, do you read any of the mailing lists?
>
> 2. Is it supposed to apply to the host, the target, or both?
HOST.
>
> 3. If it's intentional, what is the list of platforms that you
> intended
>
> On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
> >
> > On 2006-10-30, at 21:37, Daniel Berlin wrote:
> > > Honestly, I don't know any mac people who *don't* use either fink or
> > > macports to install unix software when possible, because pretty much
> > > everything has required some
ltivec PIM
is very clear about "vec_add(vector unsigned int, vector signed int)", it is
not valid code.
Likewise the "C/C++ Language extension for CBEA 2.2" is also clear with respect
of
"spu_add (vector unsigned int, vector signed int)". If we accept those what is
the return type?
Thanks,
Andrew Pinski
> > and that you break their code.
>
> ...is more of a concern, I agree, and is what I worry about most.
The other question how of this was accepted in 3.4.0 or earlier because
the behavior changed in 4.0.0 with respect of accepting these code.
Thanks,
Andrew Pinski
user code unless they are using 4.0.0 and above only.
Thanks,
Andrew Pinski
> So, now if I tell you that despite all reports that it 'works fine',
> I'm getting
>
> > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c -O0 (test for excess
> > errors)
>
> do you think this is likely to be:
> 1. some problem in gmp or mpfr,
> 2. some problem in my build of gmp and/or mpfr, th
>
> > So, now if I tell you that despite all reports that it 'works fine',
> > I'm getting
> >
> > > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c -O0 (test for excess
> > > errors)
> >
> > do you think this is likely to be:
> > 1. some problem in gmp or mpfr,
> > 2. some problem in my build o
>
> Steven Bosscher wrote:
>
> >
> > So you don't report any error messages at all and leave us guessing?
> >
>
> AFAIK fortran is not supposed to be configured at all for a cross-compiler.
> Or has that changed recently? It was certainly not configured in my
> previous
> builds of gcc 4.2
s the problem with this is that we have to support this flag for a long time
but the benifit is that we can change the default to the new way with just
flipping
a switch.
Also it would be nice to have an attribute or a new keyword to get the old
"extern
inline" behavior, something like __extern_but_inline? Or is there a real
equavilant
with C99 style inling (I have not followed this part close enough to figure
that out).
Thanks,
Andrew Pinski
uring compiling but the assembler does. Is
this correct or should we actually reject this during compiling?
Thanks,
Andrew Pinski
>
> Hello!
>
> Does anybody else get these errors in libgfortran during clean bootstrap:
>
> ...
>
> This happens on x86_64-pc-linux-gnu and i686-pc-linux-gnu, FC4.
Yes and it was already discussed in
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
-- Pinski
rams that are too large for
> the most aggressive techniques and my proposal is simply a way to
> gracefully shed the most expensive techniques as the programs get
> very large.
Indeed, yes.
> The alternative is to just to just shelve these bugs and tell the
> submitter not to use optimization on them.
It's hard to argue with your reasoning.
Andrew.
aybe in stage 2, take a quick
run through and see if the throttling is still necessary. Perhaps other
infrastructural changes have helped some, and the throttling decision
needs to be changed. I think its important we not throttle-and-forget
optimizations.
Andrew
type = TREE_TYPE (exp);
tree v_type
= build_qualified_type (exp_type,
TYPE_QUALS (exp_type) | TYPE_QUAL_VOLATILE);
tree addr = build_fold_addr_expr (exp);
v_type = build_pointer_type (v_type);
addr = fold_convert (v_type, addr);
exp = build_fold_indirect_ref (addr);
Andrew.
atest
release version of their OS and the previous version or we should remove
Darwin from being a primary/secondary platform until they are able to.
Thanks,
Andrew Pinski
On Mon, 2006-11-06 at 20:57 -0800, Eric Christopher wrote:
> As far as 4.2 this is the first I've heard of it. What's the problem?
Well you need a new cctools which does not exist for 10.2.
Thanks,
Andrew Pinski
(so is 10.3).
Thanks,
Andrew Pinski
Ricardo FERNANDEZ PASCUAL writes:
> Andrew Haley wrote:
>
> >Ricardo FERNANDEZ PASCUAL writes:
> > > So, I think the real question is: are COMPONENT_REF nodes allowed
> > > to be marked as volatile by themselves? I think they should, and
> > > actual
Dave Korn writes:
> On 07 November 2006 16:33, Andrew Haley wrote:
>
> > Ricardo FERNANDEZ PASCUAL writes:
>
> > > I have done some experiments to try to understand what is happening, and
> > > I am a bit confused by the bahavior of GCC. Consider
rtl).
Andreas, next time can you report the options you pass to configure as
a simple bootstrap just passed for me without any extra flags.
Thanks,
Andrew Pinski
er pace than chip
> improvements over the years. :-)
The other thing we could do is enable it only for stage1 (bootstrap's stage1)
by default,
just like we do for normal checking[1].
Thanks,
Andrew Pinski
[1] well that was broken with toplevel bootstrap, see the patch at
http://gcc.g
> + STRIP_USELESS_TYPE_CONVERSION (sub);
> subtype = TREE_TYPE (sub);
> if (!POINTER_TYPE_P (subtype))
> return NULL_TREE;
>
> If anybody could regtest it, this is a regression from 3.3, likely to be
> present in all 4.x branches.
Regtested x86-
On Wed, 2006-11-08 at 14:33 +0100, Bruno Haible wrote:
> Hi,
>
> 2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
>
> * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> TLS via __thread.
How well does this work with cross compiler?
Thanks,
Andrew Pinski
e cases for -ffixed-form and
-ffixed-line-length. Add a case for -lang-fortran.
Thanks,
Andrew Pinski
>
> How do i determine if two type nodes in the C front end are equivilent?
> In C++ i use same_type_p() but do not see an equivilant for the C front end.
The function you want is comptypes.
Thanks,
Andrew Pinski
also to look into archives for files
with LTO info in them and be able to read them inside the compiler also.
Thanks,
Andrew Pinski
function mechanism that is already in GCC seems like a good
thing. In fact I think of lambda functions as nested functions.
Thanks,
Andrew Pinski
is
is not really part of the compiler so you will not get wrong code from
the compiler, just the testcase will break. If you find some, report it
instead of just complaining about it.
Thanks,
Andrew Pinski
cause foo might never be
called, the example given must be successfully translated by a
conforming implementation.
Thanks,
Andrew Pinski
e except via an unsigned/signed character type is undefined.
Thanks,
Andrew Pinski
doing what it is designed to do. -D_FORTIFY_SOURCE=2
means warn when you are ignoring return values and other stuff. If
chdir fails you should handle that case and not just ignore it like you
are doing.
Thanks,
Andrew Pinski
>
> All,
>
> So, again, Is gcc planning on automatically moving to gpl version 3, staying
> at gpl version 2, or having a protracted discussion? What happens if some
> developers decide they want to stay at 2 and others decide they want to
> go with 3?
We (developers/SC) don't have control over
There's your clue. You're trying to build with "gcc -m64", which 2.95
doesn't do.
How about you tell us what you are really tring to do?
Andrew.
Please join me in congratulating Zdenek and Daniel on their new
> > role. Zdenek and Daniel, please update your listings in the MAINTAINERS
> > file.
>
> done. I am not sure whether it would be useful to indicate
> non-algorithmicness somehow in the MAINTAINERS file?
"non-algorithmicity", I suspect. :-)
Andrew.
David Fang writes:
>
> *sigh* Bootstrapping on me 5+ yr. old dual-G4 takes quite a while, even
> with make -j2 (which helps a lot). Wish-list: gcj-ccache for classpath
> rebuild acceleration.
What would it do?
Andrew.
to have a look.
Andrew
On Fri, 2006-11-17 at 12:22 -0500, Andrew MacLeod wrote:
> I just tried compiling cplusplus_grammer.ii with mainline, checking
> disabled, and had to stop it after 30 minutes (use to be <50 seconds on
> my x86-linux box). A quick check with GDB seems to show that its
> spendin
On Sun, 2006-11-19 at 05:57 +0200, [EMAIL PROTECTED] wrote:
> > Errr, LOOP_EXPR doesn't actually exist anymore :)
> > Loops are always lowered to if-then-else and gotos.
>
> That's nice! I'll check on how things are handled now. Is this true for latest
> release, mainline - current gcc trunk, or g
On Fri, 2006-11-17 at 22:19 -0500, Daniel Berlin wrote:
> On 11/17/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-11-17 at 12:22 -0500, Andrew MacLeod wrote:
> > > I just tried compiling cplusplus_grammer.ii with mainline, checking
> > > disa
On Wed, 2006-11-22 at 22:52 +0100, Daniel Franke wrote:
> The tarball of 4.1.1 includes fastjar/fastjar.info, but not
> libiberty/libiberty.info. The config file fastjar/configure.ac has the
> enable-...-srcdir flag, libiberty/configure.ac does not.
This is because libiberty's API is all interna
1118/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
Andrew.
s, instead it
mentions compatibility of struct based on the element layout.
So what you are asking for is really not going to be the right thing.
For full C rules you might able to read the function comptypes_internal
in c-typeck.c or the C standard. In fact IIRC C99 has slightly
different rules than C89.
Thanks,
Andrew Pinski
(like 99% of the time), this means you GMP/MPFR are broken
and is causing gfortran to crash out.
You might want to try running mk-kinds-h.sh to see what the error
is?
Thanks,
Andrew Pinski
ned by: function_types_compatible_p() then the strings
> should be equal.
Again C has different rules from C++.
In C, the following two TUs combined together are still valid code while in C++,
they are invalid.
tu1.c:
struct a
{
int t;
};
void f(struct a);
---- cut -
tu2.c:
typedef struct
{
int t;
}b;
void f(b a);
cut -
Thanks,
Andrew Pinski
the base+offset.
We have found that we currently get better results with our current IR,
with type based aliasing first.
Thanks,
Andrew Pinski
>
> I have code that goes something like this:
>
> char *foo(char *buf){
> *buf++ = 42;
> *((short*)buf) = 0xfeed;
> buf += 2;
> *((int*)buf) = 0x12345678;
> buf += 4;
> *((int*)buf) = 0x12345678;
> buf += 4;
> return buf;
> }
This does violate C aliasing rules.
>
> On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > > I often need to convince people that gcc is not just
> > > defective for doing random nonsense to code which
> > > violates the C and C++ aliasing rules. Not that I'm
> > >
On Thu, 2006-11-30 at 16:08 +1100, Brendon Costa wrote:
> Hi again,
> Is it safe to assume in the C++ front end that two functions declared in
> such a manner will always share the same implementation in which case it
> is kind-of like a "using" statement?
The C++ front-end is broken and needs t
in
the last couple of weeks.
> Is there any plan to enforce warnings about implicit type conversion ?
http://gcc.gnu.org/wiki/NewWconversion
-Wconversion in 4.3.0 and above.
Thanks,
Andrew Pinski
e will have to review it. This eliminates a lot of
> the code base but it is still generating a lot of cases to examine
> by hand.
Ewww, that's scary. All it tells you is which code breaks today; even
a minor bug fix in gcc might make a difference.
Nonetheless, this is a really interesting idea, and I'm sure we'd all
be very interested to see the results.
Andrew.
(85%) wall
4045 kB ( 1%) ggc
TOTAL :1283.62 9.97 1381.98
451745 kB
Is this new code, or is this the old issue we had a few weeks ago? I
lost track.
Andrew
On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
> My bootstrap/make check cycle took about 10 hours with yesterdays
> checkout (way longer than expected). A quick investigation shows C++
> compilation timed are through the roof.
>
> Using quick (in theory) and trusty c
On Fri, 2006-12-01 at 10:56 -0500, Andrew MacLeod wrote:
> On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigation shows C++
> > compilation
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigation shows C++
> > compilation
e care of various warts. (And to make it more
suitable for some register pressure experimenting, and a
potenital/eventual merge with expand).
Andrew
On Fri, 2006-12-01 at 15:06 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > >
> > > > Using quick (in theory) and trusty cpgram.ii, I get:
> > > &g
On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > > My bootstrap
ces
> definitely want pointers.
Then create an union which contains the two different types of call
back.
You know:
union a
{
void (*callbackwithulong) (unsigned long);
void (*callbackwithptr) (void*);
};
And then you just use the correct in the correct place.
I don't see why there is
1 - 100 of 3457 matches
Mail list logo
