Paolo Carlini writes:
> Andrew Haley wrote:
>
> > > Ok, I believe you. However, isn't true that, in general, because the
> > > sign of the result is implementation defined,
> >
> >The sign of the result of % is no longer (since C99) implemen
such it may be too expensive,
> performance-wise, to fix in GCC. It seems as one of those
> classical things that can be worked-around in the kernel.
I guess, or it can be fixed-up in user space. We already do this for
the Java language.
Andrew.
Gabriel Dos Reis writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> | Michael Veksler writes:
> | > Roberto Bagnara wrote:
> | > >
> | > > Reading the thread "Autoconf manual's coverage of signed integer
> | > > overf
Roberto Bagnara writes:
> Andrew Haley wrote:
> > Roberto Bagnara writes:
> > >
> > > Reading the thread "Autoconf manual's coverage of signed integer
> > > overflow & portability" I was horrified to discover about GCC's
&
Roberto Bagnara writes:
> Andrew Haley wrote:
> >
> > If the quotient a/b is *not* representable, is the behaviour of %
> > well-defined or not? It doesn't say.
>
> To the point that, when a/b is not representable, raising SIGFPE
> for a%b is sta
need a more general patch to hoist invariants in gcj -- there are a
lot of these -- but this is a good start.
Andrew.
2007-01-16 Andrew Haley <[EMAIL PROTECTED]>
* expr.c (expand_byte_code): Call cache_this_class_ref() and
cache_cpool_data_ref().
Set TYPE_CPOOL_DA
ably isn't a
bug, and there is a performance penalty to be paid for changing the
behaviour, so we shouldn't fix it.
If I had believed that it surely was a bug, then I wouldn't have made
the performance argument: correctness first, then performance.
Andrew.
s the best chance to eliminate the test for -1.
> Doing it during gimplification would be easy, if perhaps rather
> ugly. If there are indeed several processors with this oddity,
> then it would even make a certain degree of sense as a
> target-independent option.
x86, x86-64, S/390, as far as I'm aware.
Andrew.
>
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>
> | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
> | > To be clear, in my opinion, this should always be selected by an
> | > option, it should never be default behaviour for any target.
> |
> | I disagree. One should get correct results
ent
boundary (the page boundary) and that would then call the unaligned
exception handler and that is rarer).
Who really need to start getting the PS3 game OS to do an unaligned
exception handler that works instead of hanging.
Thanks,
Andrew Pinski
>
> Andrew Pinski wrote:
> I have no idea how your reply is related to my question about the
> change in alignment of char arrays between gcc-3.4 and gcc-4.1.
It was not really a rely to that part of the question but rather the
assertion in general that unaligned access was slower
inserted.
>From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero performance degradation of
existing code. I don't think there's any need for gcc to be altered
to handle this.
Andrew.
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> |
> | From a performance/convenience angle, the best place to handle this is
> | either libc or the kernel.
>
> Hmm, that is predicated on assumptions not convenient to users
> on targets tha
David Daney writes:
>
> That only works if the operation causes a trap.
Which it does in almost all cases. Let PPC do something different, if
that's what really PPC needs.
Andrew.
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> | Gabriel Dos Reis writes:
> | > On Wed, 17 Jan 2007, Andrew Haley wrote:
> | >
> | > |
> | > | From a performance/convenience angle, the best place to handle this is
&
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> [...]
>
> | > | "To a man with a hammer, all things look like a nail." It's very
> | > | tempting for us in gcc-land always to fix things in gcc, not because
> | > |
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> | Gabriel Dos Reis writes:
> | > On Wed, 17 Jan 2007, Andrew Haley wrote:
> | >
> | > [...]
> | >
> | > | > | "To a man with a hammer, all things look like a nail
>
> One use of -Wconversion is to draw attention to
>
>int x = 2.3; // warning: be careful, is this what you want?
> // this is a potential bug as it is value altering.
>
> and in an upcoming revision to C++, it is very likely that implicit
> conversion that may lose info
't think Parkinson uses this term. He states a similar
> principle as:
>
> * THE LAW OF TRIVIALITY: The time spent on any item of a committee's
> agenda will be in inverse proportion to the sum of money involved.
Mm, but although the problem being dicussed here is trivial, some of
the proposed solutions aren't. As the saying goes, "the cure is worse
than the disease."
Andrew.
.
For example, here's one in __udivmoddi4:
if (d0 == 0)
d0 = 1 / d0;/* Divide intentionally by zero. */
Andrew.
er is no, there is nothing quite like you describe.
>
> But I think it would be a good idea.
Something like this would greatly improve the code generation quality
of gcj. There are a great many assertions that I could pass to VRP
and the optimizers: this is invariant, this is less than that, and so
on.
Andrew.
>
> Mike Stump <[EMAIL PROTECTED]> writes:
>
> > Here is an innovative new build failure, as seen on i686-apple-darwin9:
> >
> > ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in
> > conditional expression
> > make[3]: *** [expmed.o] Error 1
> > make[2]: *** [all-stage2-gcc] Erro
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
> It would be nice to have such a construct in GNU C, something that
> could be used in a macro expansion, and would turn off _all_ warnings
> for the code within the construct.
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
Bu
write_barrier() is missing in the libgcj build. Fixed thusly.
Andrew.
2007-01-22 Andrew Haley <[EMAIL PROTECTED]>
* sysdep/alpha/locks.h (write_barrier): New.
Index: locks.h
===
--- locks.h (revision
t that
there isn't any simple correspondence between the stack slots used and
any variables declared by the programmer.
Andrew.
>
>
> Wiadomo¶æ napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
>
> > For 4, you should probably spend some time figuring out why bugs are
> > being introduced into the code in the first place. Is test coverage
> > not good enough?
The test coverage is not good for C++ while it i
tage1 and then again at the end of stage2.
This will get the time down for reporting of major bugs. We will still end
up with the problem that all code is ran through so we get bug reports after
the .1 release that now block the next .0 release from happening.
Sorry about the length of this email.
Thanks,
Andrew Pinski
On Tue, 2007-01-23 at 23:19 -0600, [EMAIL PROTECTED] wrote:
> GCC should treat plain char in the same fashion on all types of machines
> (by default).
No, no, no. It is up to the ABI what char is.
> The ISO C standard leaves it up to the implementation whether a char
> declared plain char is sig
>
> On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said:
>
> That's largely because individual tests in the test suite are too
> long, which in turn is because the tests are testing code at a
> per-binary granularity: you have to run all of gcc, or all of one
> of the prog
files.
>
> Why would this happen?
>
> > That is the only insight I can provide.
> >
> > David Daney
>
> Thanks for your response and your time on this issue.
We don't have enough information. What was your configure line, for example?
Andrew.
>
> On FC6 x86_64-pc-linux-gnu with the svn trunk r121257 configured like this:
>
> ../trunk/configure --with-gmp=/usr/local --with-mpfr=/usr/local
> --disable-multilib --enable-languages=c,c++,java
>
> I am seeing this failure when bootstrapping. It worked for me last week:
>
> /home/daney
On Sun, 2007-01-28 at 15:41 -0800, Ray Hurst wrote:
> Shouldn't the compiler error out here.
> The statement: p = "" should have been p = '\0';
> Or does the compiler treat them as equivalent.
>
> It seems that only characters should be assigned to char's and strings
> are illegal
Read about the
We weren't marking calls to external fndecls DECL_EXTERNAL, and this
was causing build failures on PPC64.
Andrew.
2007-01-29 Andrew Haley <[EMAIL PROTECTED]>
* class.c (add_method_1): Mark fndecl as external unless we are
compiling it into this object file.
Ind
>
> This is a multi-part message in MIME format.
> --050002020005030600040801
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
>
> >> You know (or so I assume) this was a very Very VERY BAD thing to do
> >
> > are not helpful. Of cou
Gerald Pfeifer writes:
> I can no longer build libjava on a machine with "just" 512MB of main
> memory (FreeBSD/i386 5.4 in this case).
>
> Three weeks ago the build worked on that very machine; did we raise
> our minimum requirements
We just imported a whole new release of the Classpath li
Marco Trudel writes:
> Andrew Haley wrote:
> > Gerald Pfeifer writes:
> > > I can no longer build libjava on a machine with "just" 512MB of main
> > > memory (FreeBSD/i386 5.4 in this case).
> > >
> > > Three weeks ago the buil
the logic that decides if a symbol is external to the
> compilation unit is faulty.
>
> Any ideas about where it might have gone wrong?
Does http://gcc.gnu.org/ml/gcc/2007-01/msg01184.html fix this?
Andrew.
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> Anyway, I tried again, this time with the right file, and it took
> Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> 0maxres
Gerald Pfeifer writes:
> On Tue, 30 Jan 2007, Andrew Haley wrote:
> > 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> > 0maxresident)k
> >
> > and indeed, it does want a lot of memory - at peak some 550m. It'll
> > be smaller
Mark Wielaard writes:
> On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote:
> > >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > Andrew> Anyway, I tried again, this time with the right file, and it took
> >
Andrew Haley writes:
> >
> > It does look like we are scaring away some people with the long
> > build times and memory hungry build of libjava. I only started
> > building libgcj again recently when I got a
> > 3Ghz/64-bit/dual-core/2GB machine. And eve
erring to me. But
before we do anything we need to know more about the machine on which
it failed.
Ultimately, it's a question of what we consider to be a reasonable
machine on which to build libgcj. I don't know the answer to that.
Andrew.
; I suspect it is the same problem. APH's patch would not have fixed it
> if it were.
OK. Does your patch work? If it does, I'm going to trace through jc1
to see if I can find the real origin of this regression.
TVM,
Andrew.
>
> On Wed, 31 Jan 2007, Andrew Haley wrote:
> > Can you tell us a bit more about the config? It really shouldn't be
> > failing to compile this program.
>
> The tester where this problem first surfaced as a 32-bit Athlon machine,
> with 512MB main memory and 1GB
Joe Buck writes:
> On Sat, Feb 10, 2007 at 12:49:56AM -0500, David Edelsohn wrote:
> > >>>>> Tom Tromey writes:
> >
> > Tom> David probably knows this, but for others, Jakub and Andrew put in a
> > Tom> patch for this today. I think it is
g,
> California time.
Done.
Andrew.
>
> Hi Rask,
>
> Basically the CPU has the 'SCALE_28_4' instruction which does the following:
> output = (operand1 >> 28) | (operand2 << 4)
Isn't that a rotate? if so you can use either rotate or rotatert instead.
Thanks,
Andrew Pinski
>
> In http://gcc.gnu.org/gcc-4.3/changes.html appears
>
> "Support for SSSE3 built-in functions and code generation are available
> via |-mssse3|."
>
> Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
> Is it -mssse3 or -msse3?
-mssse3 is S-SSE3 which was added for code dual 2.
Yes the opt
>
> Andrew Pinski wrote:
> >> In http://gcc.gnu.org/gcc-4.3/changes.html appears
> >>
> >> "Support for SSSE3 built-in functions and code generation are available
> >> via |-mssse3|."
> >>
> >> Is it SSE3 (i686 SIMD) or SSSE3
> globals and 10 locals (3RG+10RL<<31).
>
> So basically this is known at compile-time. Such as "dynamic" register
> allocator.
> Is it that possible and what are the implications on the register
> allocator ???
That's more or less what the IA-64 does. You could look at how that
port works.
Andrew.
>
>
> Hello,
>
> We saw that the reassociation pass does not operate on built-in functions,
> for example:
>
> vp3 = vec_madd (vp1, vp2, vp3);
One thing which could be done is expand the builtins into tree code
instead of keeping around a builtin function.
This might also help other cases too
>
>
> > > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > > after that merge dataflow branch.
>
> FWIW I agree with Vlad and Paolo Bonzini.
>
> It seems as if 4.2 was branched with critical flaws
nciple?
I think this is a great extension as someone was requesting the same thing
here too.
Thanks,
Andrew Pinski
<http://gcc.gnu.org/ml/gcc/2001-01/msg01775.html and
http://gcc.gnu.org/ml/gcc/2001-01/msg01777.html>
And I thought this was really part of our coding style too but I
cannot find it on http://gcc.gnu.org/codingconventions.html .
Thanks,
Andrew Pinski
header with WIFEXITED, WEXITSTATUS, etc.
See http://sourceware.org/bugzilla/show_bug.cgi?id=1392 .
Thanks,
Andrew Pinski
On 2/28/07, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
Is there anyway to do this?
Yes look at config/rs6000/rs6000.h and ASM_CPU_SPEC and EXTRA_SPECS
and ASM_SPEC.
Thanks,
Andrew Pinski
we were not as good but now we
have corrected those mistakes.
Thanks,
Andrew Pinski
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
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
" by "div" and validation will succeed.
As far as I can tell this is correct in the cvs holding the html.
Plus http://gcc.gnu.org/ valids as valid XHTML 1.0 Transitional. So
something in the conversion method that www.gnu.org does to the web
pages break the validation.
Thanks,
Andrew Pinski
t) or can it be a complex expression?
Thanks,
Andrew Pinski
t so
that failing is known. You might want to try adding
-fno-strict-aliasing.
I have been asking someone who has the power to submit an alt to SPEC
for that failure for 3 years now and now it is too late really.
Thanks,
Andrew Pinski
has an issue too but IV-OPTs dump gives:
D.1604_5 = MEM[base: (double *) &a, index: ivtmp.34_12];
MEM[base: (double *) &c, index: ivtmp.34_12] = D.1604_5;
the expression matching in final_cleanup was just a symptom of the issue.
Thanks,
Andrew Pinski
o be edges, you would have something like 100 basic
blocks for a simple function which is too excusive.
Thanks,
Andrew Pinski
On 3/4/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
Another important thing to do is to make the 1st scheduler register
pressure sensitive.
I don't know how many times this has to be said, no this is not the
correct approach to fix that issue. The correct fix is able for the
register all
still with this change?
<http://gcc.gnu.org/ml/gcc/2007-03/msg00120.html> for the reference of
the regressions.
Thanks,
Andrew Pinski
On 05 Mar 2007 12:24:18 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
If Mark agrees with you, then I'm unfortunately going to have to lobby
to disable VRP by default in 4.2.
Then it should also be disabled by defau
8, and propagated di into the
compare. insn 7 would be dead and we'd get the code the PR is looking
for :-)
Andrew
2007-03-05 Andrew MacLeod <[EMAIL PROTECTED]>
* tree-ssa-ter.c (find_replaceable_in_bb): Allow expression replacement
of same basename variables for s
to mainline which I attached to the note (it only
causes tree-ssa-ter.c to be recompiled), and the provided 2 line
testcase causes this situation.
I plan to check the patch in, but not until this wrong code bug is
resolved.
Andrew
the first 3 as 'will not fix', or whatever you
do to indicate they aren't going to be resolved in 4.2. When I actually
have a fix for them (or RTL optimizers fix them), we can look at what it
takes to port them back, but for this release I'd claim they are a
no-go.
Andrew
On 3/8/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Another convenient way of allocating a pool of memory is to use obstacks
(See libiberty/obstack.c).
Though alloc-pool might be a better idea than obstack, see
alloc-pool.[ch]. As alloc-pool contains checking code while obstack
does not.
-- P
x27;t is better to have for this cast monster a structure. Something
> like
> struct sFieldArray {
> size_t count;
> void *arr[1];
> }
> ?
Andrew.
limit.
This is recorded as PR 31134.
Thanks,
Andrew Pinski
On 3/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Unfortunately, my ISP has apparently picked today to make DNS not
work. So, I'm having a hard time getting around the internet.
Sounds like the DST bug :).
-- Pinski
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
* PR 30132 (Pinski, Berlin) -- This is an aliasing crash on complex
numbers. Andrew, you mentioned you might have a patch.
Yes I have a patch but I need to go back and look at the sources
again, I can get to this bug tomorrow as the s
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi,
just wanted to say explicitely that I'm supporting completely Doug'
efforts at fixing this issue. Well, I'm a little biased, because I'm
working on C++/26099 and I will need at least one new tree code, but
that's not the point, the point i
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Can I recommend something just crazy, rewrite the C and C++ front-ends
> so they don't use the tree structure at all except when lowering until
> gimple like
Kai Tietz writes:
> I want to remove some trailing whitespaces from gcc source as coding style
> demands. Also I wrote, while doing a small tool for that, a feature to
> replace horiz. tabs by spaces. But the question is by which width should
> be used ?
8.
Andrew.
... a little tip. Add this to your c-mode-hook:
(set-variable 'show-trailing-whitespace t)
And you'll see all the trailing whitespace. On my system it appears
bright red.
Andrew.
On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote:
> ... a little tip. Add this to your c-mode-hook:
>
>(set-variable 'show-trailing-whitespace t)
>
> And you'll see all the trailing whitespace. On my system it appears
> bright red.
>
Doesn't seem to work on xemacs :(
Andrew Walrond
On 3/13/07, Andrew Walrond <[EMAIL PROTECTED]> wrote:
Doesn't seem to work on xemacs :(
xemacs != emacs
Anyways I was going to say:
Don't
But now we are getting into emacs vs vi vs xemacs which is getting offtopic.
-- Pinski
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Kai Tietz writes:
> >
> > > I want to remove some trailing whitespaces from gcc source as coding
> > style
> > > demands. Also I wrote, while doing a small to
Dave Korn writes:
> On 13 March 2007 14:02, Andrew Haley wrote:
>
> > Kai Tietz writes:
> >
> > > I want to remove some trailing whitespaces from gcc source as coding
> > style > demands. Also I wrote, while doing a small tool for that, a
> >
Kai Tietz writes:
> Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57:
>
> > Ian Lance Taylor writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > Kai Tietz writes:
> > > >
27;m sure that I
have checked in no trailing spaces since enabling it.
Andrew.
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Which C type is HOST_WIDE_INT?
It can either be long, or long long depending on if the target needs
it to be 64bits and what size of long on the host.
Isn't the type of the constant always integer_type?
No, it can be POINTER_TYPE, ENUME
On 3/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
My attempt to build GCC 4.2.0 RC1 failed with:
cp doc/gcc.1 doc/g++.1
cp: cannot stat `doc/gcc.1': No such file or directory
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899 yes, yes I
have bugzilla memorized.
-- Pinski
On 3/13/07, Kazu Hirata <[EMAIL PROTECTED]> wrote:
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
There
On 3/13/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Tue, 13 Mar 2007, Andrew Pinski wrote:
It's true that in development we may not want to XFAIL them - but it's
also true that this FAIL is on 4.2 branch and 4.2.0 is likely to be
released with it. And users installi
On 3/14/07, Tristan Gingold <[EMAIL PROTECTED]> wrote:
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
I think this is also related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
Yes, yes I have the whole bugzilla memorized. :)
we do for the Cell also, we expect people to compile
using two different compilers right now, but we are actually looking
into doing an "one source" based compiling where some functions or
loops are pushed off to the SPUs via annotations like the OpenMP ones.
Thanks,
Andrew Pinski
l, this is already filed as PR 22076 and others.
There was a patch posted as an RFC to fix this but it caused
regression on x86_64 and the person who submitted has not updated it
yet for the mainline.
Thanks,
Andrew Pinski
On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
My thinking is that if libobjc was changed then we could put in a
depreciated message on these builtins for 4.3 and maybe remove them for
4.4.
libobjc has not changed yet. There was a patch a while back to change
libobjc to use libffi but I n
On 3/16/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
Do you mean this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html
Yes, thanks for finding the patch.
I will look over it this weekend and apply it if it is good.
-- Pinski
Steven Bosscher writes:
> On 3/16/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> > > My thinking is that if libobjc was changed then we could put in a
> > > depreciated message on these bui
On 3/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Are there any performance issues to consider? Is using libffi
slower/faster than the builtins?
It is most likely slower but these APIs in libobjc are not used as
much as the other ones, plus GNUStep already uses libffi as the
forw
: ld terminated with signal 11 [Segmentation fault]
> make[8]: *** [libstdc++.la] Error 1
Usually that means there is a bug in binutil's ld. It might be better
to use a real FSF stable release of binutils instead of what the
vendor (distro) provides you with.
Thanks,
Andrew Pinski
On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
I'll try, but I doubt it. According to the installation
documentation, amd64 is not a multilib target.
HUH??? Which documentation? x86_64 for GCC is a multilib target and
has been since day 1 IIRC.
-- Pinski
the actual pointer and which is the integer that has been
added to it.
Is there another way to find out which is which?
Not right now, I have been working on a new representation of pointer
arithmetic for the tree level. The basic implementation is already
done, see the pointer_plus branch.
Tha
201 - 300 of 3457 matches
Mail list logo
