On Mon, Jun 26, 2006 at 09:24:57PM -0700, Ian Lance Taylor wrote:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > On Jun 26, 2006, at 2:09 PM, Ian Lance Taylor wrote:
> >
> > > As far as I can see, it doesn't.
> >
> > You missed:
> >if (TARGET_MMX)
> > ix86_init_mmx_sse_builtins ();
>
Andrew Pinski wrote:
On Jun 26, 2006, at 10:02 PM, Andrew Pinski wrote:
On Jun 26, 2006, at 9:01 AM, Bryce McKinlay wrote:
Otherwise, this is fine.
No it is not, it broke bootstrap on powerpc-darwin:
Did you look when the function would have been declared.
From gc.h:
#if defined(GC_PT
On Jun 26, 2006, at 10:02 PM, Andrew Pinski wrote:
On Jun 26, 2006, at 9:01 AM, Bryce McKinlay wrote:
Otherwise, this is fine.
No it is not, it broke bootstrap on powerpc-darwin:
Did you look when the function would have been declared.
From gc.h:
#if defined(GC_PTHREADS) && !defined(GC_
On Jun 26, 2006, at 9:01 AM, Bryce McKinlay wrote:
Otherwise, this is fine.
No it is not, it broke bootstrap on powerpc-darwin:
/Users/regress/tbox/svn-gcc/libjava/boehm.cc: In function 'void
_Jv_SuspendThread(_Jv_Thread_t*)':
/Users/regress/tbox/svn-gcc/libjava/boehm.cc:679: error:
'GC_s
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 26, 2006, at 2:09 PM, Ian Lance Taylor wrote:
>
> > As far as I can see, it doesn't.
>
> You missed:
>if (TARGET_MMX)
> ix86_init_mmx_sse_builtins ();
>
> Which HJL should have also quoted.
I didn't miss it, I was just ambiguous. H.J
On Jun 26, 2006, at 2:09 PM, Ian Lance Taylor wrote:
As far as I can see, it doesn't.
You missed:
if (TARGET_MMX)
ix86_init_mmx_sse_builtins ();
Which HJL should have also quoted.
On the other hand, as far as I can
see, __float80 is undocumented and unused for the i386. Why does it
On Thu, Jun 22, 2006 at 09:06:28PM -0400, Daniel Berlin wrote:
> As Joe Buck, a Steering Committee member said, you need to talk to RMS
> directly and get him to accept the idea, before we can do anything about it.
I already asked RMS directly, and he has approved. Again, sorry for
the delay on g
On Thu, Jun 22, 2006 at 11:49:45AM +0200, Roberto COSTA wrote:
> By the way, is there any news about the status of the CIL issue?
> I'm sorry to bother the list readers about this, but whom could I
> directly ask?
Sorry for the delay in answering, Robert. I was out of town, and
apparently people
On 6/26/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
After I've modified the MULTILIB options in t-arm-elf, what's the
fastest way to test the new configuration without rebuilding the
entire toolchain? Right now the best method I have is `make clean-gcc
all-gcc', which is admittedly quite slow.
On 6/26/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
Reading through gcc/genmultilib, it looks as though
MULTILIB_EXCLUSIONS can take a '!' parameter, but MULTILIB_EXCEPTIONS
cannot.
The solutions was to use MULTILIB_EXCLUSIONS!
MULTILIB_EXCLUSIONS += !fPIC/msingle-pic-base
Yeeha!
Cheers,
Sh
"Shaun Jackman" <[EMAIL PROTECTED]> writes:
> Reading through gcc/genmultilib, it looks as though
> MULTILIB_EXCLUSIONS can take a '!' parameter, but MULTILIB_EXCEPTIONS
> cannot.
I forgot about MULTILIB_EXCLUSIONS (it might be nice if it were
documented). I don't know if it would help you, sinc
On 26 Jun 2006 14:42:20 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
No, that wouldn't work. MULTILIB_EXCEPTIONS takes a shell glob
pattern. It is invoked for each option set which is going to be
generated. I would expect that one of the option sets would be simply
"-msingle-pic-base".
"Shaun Jackman" <[EMAIL PROTECTED]> writes:
> On 26 Jun 2006 14:04:36 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> >
> The usual hacked up way is to MULTILIB_EXCEPTIONS to remove
> > -msingle-pic-base without -fPIC. Something like
> >
> > MULTILIB_EXCEPTIONS = -msingle-pic-base
> >
> > might do it
On 26 Jun 2006 14:04:36 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> >
The usual hacked up way is to MULTILIB_EXCEPTIONS to remove
-msingle-pic-base without -fPIC. Something like
MULTILIB_EXCEPTIONS = -msingle-pic-base
might do it.
I tried your suggestion, but it didn't seem to have the desir
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> There are
>
> ix86_init_mmx_sse_builtins ()
> {
> ..
> /* The __float80 type. */
> if (TYPE_MODE (long_double_type_node) == XFmode)
> (*lang_hooks.types.register_builtin_type) (long_double_type_node,
>
"Shaun Jackman" <[EMAIL PROTECTED]> writes:
> I'm using MULTILIB_OPTIONS and MULTILIB_DIRNAMES to compile a PIC/XIP
> toolchain. I'm familiar with the MULTILIB_EXCEPTIONS mechanism to
> specify incompatible configurations. How, though, do I indicate that
> msingle-pic-base depends on fPIC?
>
> MU
After I've modified the MULTILIB options in t-arm-elf, what's the
fastest way to test the new configuration without rebuilding the
entire toolchain? Right now the best method I have is `make clean-gcc
all-gcc', which is admittedly quite slow.
Please cc me in your reply. Thanks!
Shaun
There are
ix86_init_mmx_sse_builtins ()
{
..
/* The __float80 type. */
if (TYPE_MODE (long_double_type_node) == XFmode)
(*lang_hooks.types.register_builtin_type) (long_double_type_node,
"__float80");
else
{
/* The __float80 type
I'm using MULTILIB_OPTIONS and MULTILIB_DIRNAMES to compile a PIC/XIP
toolchain. I'm familiar with the MULTILIB_EXCEPTIONS mechanism to
specify incompatible configurations. How, though, do I indicate that
msingle-pic-base depends on fPIC?
MULTILIB_OPTIONS+= fPIC
MULTILIB_DIRNAMES += pic
MUL
On 6/26/06, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
As of gcc-4.2 it isn't fixed, it's just like any other pseudo generated
by the compiler.
Glad to hear it!
Thanks,
Shaun
On Sun, Jun 25, 2006 at 05:02:41PM -0700, Alexander Verhaeghe wrote:
> Quote Jan-Benedict Glaw "So please shut up now."
>
> Quite friendly I must say, it's the german way I
> suppose of handling things?
>
> To Jan-Benedict Glaw I WON'T SHUT UP because of "Free
> as in Freedom"!
That's fine. Jus
On Jun 26, 2006, at 8:56 AM, Zdenek Dvorak wrote:
Hello,
predcom branch is now ready for testing.
Very cool.
We basically implemented
second-order predictive commoning (quick overview can be found
e.g. in
http://www.cs.ualberta.ca/~amaral/cascon/CDP04/slides/tal.pdf, or
at the
beginning
On Mon, Jun 26, 2006 at 04:16:28PM +0200, Roland Persson wrote:
> Hi,
>
> My target has some instructions that do not exactly match any predefined
> pattern names. What is the correct way to get gcc to use them in code
> generation?
Please see http://gcc.gnu.org/onlinedocs/gccint/Patterns.html>.
"Roland Persson" <[EMAIL PROTECTED]> writes:
> For example, I have an add instruction that can add a 32-bit integer (with
> or without sign extension) to a 64-bit operand and store the result as 64
> bits.
>
> C code like:
> __int64_t a = 1;
> int b = 2;
> a += b;
>
> will generate code that sig
On Mon, 2006-06-26 at 17:48, Shaun Jackman wrote:
> The default -mpic-register (on ARM/Thumb) is r10. In -mthumb mode, r10
> is not available to the math instructions as a direct argument. On top
> of that, preserving r10 complicates the function prologue. Does it
> make more sense to use a directl
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of hector riojas roldan
> Sent: Friday, June 23, 2006 5:40 PM
> To: gcc@gcc.gnu.org
> Subject: Fortran Compiler
>
> Hello, I would like to know if there is a fortran compiler
> that runs on AMD 64 bits.
The default -mpic-register (on ARM/Thumb) is r10. In -mthumb mode, r10
is not available to the math instructions as a direct argument. On top
of that, preserving r10 complicates the function prologue. Does it
make more sense to use a directly accessible register, r7 for example,
as the default -mp
Dave Korn wrote:
On 06 June 2006 15:17, Richard Earnshaw wrote:
On Tue, 2006-06-06 at 15:05, Dirk Behme wrote:
Fengwei Yin wrote:
Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.
Hello,
predcom branch is now ready for testing. We basically implemented
second-order predictive commoning (quick overview can be found e.g. in
http://www.cs.ualberta.ca/~amaral/cascon/CDP04/slides/tal.pdf, or at the
beginning of tree-predcom.c file). There are still some issues we are
working
Andrew MacLeod wrote:
On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
Andrew MacLeod wrote:
The SSA pressure relief through rematerialization described in
Simpson's theses is oriented for such architectures (with a big
regular register file size of 32 as I remember). So
On Mon, 26 Jun 2006, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> > I'll go ahead and revert the ggc-page.c patch now.
>
> Thanks, I think that's the right call. I'm sorry I didn't spot this
> issue in my review. The idea you have is a good one, but it does look
> like some of the funny
Richard Guenther wrote:
> I'll go ahead and revert the ggc-page.c patch now.
Thanks, I think that's the right call. I'm sorry I didn't spot this
issue in my review. The idea you have is a good one, but it does look
like some of the funny games we're playing get in the way.
--
Mark Mitchell
Co
On 6/26/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
> Andrew MacLeod wrote:
> Having no information about the final register allocator decision,
> the partial register pressure reducing through rematerialization is
> not working i
Hi,
My target has some instructions that do not exactly match any predefined
pattern names. What is the correct way to get gcc to use them in code
generation?
For example, I have an add instruction that can add a 32-bit integer (with
or without sign extension) to a 64-bit operand and store the re
On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
> Andrew MacLeod wrote:
> Having no information about the final register allocator decision,
> the partial register pressure reducing through rematerialization is
> not working in many cases. For example, making rematerialization of
On Mon, 26 Jun 2006, Richard Guenther wrote:
> On Mon, 26 Jun 2006, Andrew Pinski wrote:
>
> >
> > On Jun 26, 2006, at 2:07 AM, Richard Guenther wrote:
> >
> > >So even
> > >(len + sizeof (struct tree_string)) & ~__alignof__(struct tree_string)
> > >might magically work in every case.
> >
> >
On Mon, 26 Jun 2006, Andrew Pinski wrote:
>
> On Jun 26, 2006, at 2:07 AM, Richard Guenther wrote:
>
> >So even
> >(len + sizeof (struct tree_string)) & ~__alignof__(struct tree_string)
> >might magically work in every case.
>
> Of course using __alignof__ is wrong in GCC sources since that wou
> but with this things going on, the whole reasoning why the patch is
> correct falls apart (if we declare doing so correct).
That's my understanding too. :-(
> Thanks for tracking this down (and I wonder why ia64 bootstrap succeeded
> with trapping misaligned),
Note that SPARC64 bootstrap succe
On Jun 26, 2006, at 2:07 AM, Richard Guenther wrote:
So even
(len + sizeof (struct tree_string)) & ~__alignof__(struct tree_string)
might magically work in every case.
Of course using __alignof__ is wrong in GCC sources since that would
mean
you have to use GCC to bootstrap with which is
On Mon, 26 Jun 2006, Richard Guenther wrote:
> On Mon, 26 Jun 2006, Eric Botcazou wrote:
>
> > > Reverting your patch makes it go away too. I'll try and look into it
> > > tomorrow.
> >
> > tree
> > build_string (int len, const char *str)
> > {
> > tree s;
> > size_t length;
> >
> > le
On Mon, 26 Jun 2006, Eric Botcazou wrote:
> > Reverting your patch makes it go away too. I'll try and look into it
> > tomorrow.
>
> tree
> build_string (int len, const char *str)
> {
> tree s;
> size_t length;
>
> length = len + sizeof (struct tree_string);
>
> s = ggc_alloc_tree (l
> Reverting your patch makes it go away too. I'll try and look into it
> tomorrow.
tree
build_string (int len, const char *str)
{
tree s;
size_t length;
length = len + sizeof (struct tree_string);
s = ggc_alloc_tree (length);
Breakpoint 5, build_string (len=34,
str=0x1048e58 "No
> I don't think it's a good idea to compile in rpaths to non-standard
> (user-specific) directories by default.
Whether it should be the default is debatable and different people will
have different opinions.
Whether there should be an option to do that seems very useful and
desirable to me. That
On Sun, 25 Jun 2006, Seongbae Park wrote:
> On 6/25/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > So, something obviously wrong with
> > >
> > > struct max_alignment {
> > > char c;
> > > union {
> > >HOST_WIDEST_INT i;
> > >long double d;
> > > } u;
> > > };
> > >
> > > /* The big
* Paul Hilfinger:
> 2. Remember to include the appropriate -W,l-R option or whatever in
>and every compilation.
I don't think it's a good idea to compile in rpaths to non-standard
(user-specific) directories by default. This can lead to trapdoor
rpaths and generally makes the binaries less p
45 matches
Mail list logo
