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 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
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
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 biggest alignment required. */
>
> #define MAX_ALIGNMENT (offsetof (struct max_alignment,
> So, something obviously wrong with
>
> struct max_alignment {
> char c;
> union {
>HOST_WIDEST_INT i;
>long double d;
> } u;
> };
>
> /* The biggest alignment required. */
>
> #define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
>
> for SPARC 32bit?
I don't think so, the ABI sa
On Sun, 25 Jun 2006, Eric Botcazou wrote:
> > At least this one looks "easier" to look at. Is SPARC/Solaris a
> > strict alignment target?
>
> Yes, all SPARC targets are.
So, something obviously wrong with
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
}
> At least this one looks "easier" to look at. Is SPARC/Solaris a
> strict alignment target?
Yes, all SPARC targets are.
--
Eric Botcazou
On 6/25/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> It would be nice if you can track down this some more, as I do not
> have access to ppc-darwin.
And to SPARC/Solaris 32-bit? :-)
No ;) But I verified that i386-apple-darwin still works. Also ppc-aix still
works.
/opt/build/eric/gcc/./g
> It would be nice if you can track down this some more, as I do not
> have access to ppc-darwin.
And to SPARC/Solaris 32-bit? :-)
/opt/build/eric/gcc/./gcc/xgcc -B/opt/build/eric/gcc/./gcc/
-B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/bin/
-B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/l
On 6/25/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Sun, Jun 25, 2006 at 07:59:14PM +0200, Richard Guenther wrote:
> pass? What is MAX_ALIGNMENT on ppc-darwin? It's defined as
>
> struct max_alignment {
> char c;
> union {
> HOST_WIDEST_INT i;
> long double d;
> } u;
> };
On Sun, Jun 25, 2006 at 11:19:45AM -0700, Andrew Pinski wrote:
> Maybe the struct should be rewritten like:
> >struct max_alignment {
> > char c;
> > union {
> >long double d;
> >HOST_WIDEST_INT i;
> > } u;
> >};
>
> To make sure the long double was first which is usually the cures the
On Jun 25, 2006, at 11:12 AM, Daniel Jacobowitz wrote:
I learned while working on the zone collector that there is at least
one platform where this doesn't work, because "long double" had an
alignment of eight on its own and four as a structure field. It might
have been powerpc-darwin.
Maybe
On Sun, Jun 25, 2006 at 07:59:14PM +0200, Richard Guenther wrote:
> pass? What is MAX_ALIGNMENT on ppc-darwin? It's defined as
>
> struct max_alignment {
> char c;
> union {
> HOST_WIDEST_INT i;
> long double d;
> } u;
> };
>
> /* The biggest alignment required. */
>
> #define M
On Sun, 25 Jun 2006, Andrew Pinski wrote:
>
> On Jun 24, 2006, at 6:58 AM, Andrew Pinski wrote:
>
> >I can reproduce this, something is miscompiling cc1plus.
>
> If I revert:
> 2006-06-23 Richard Guenther <[EMAIL PROTECTED]>
>
>* ggc-page.c (init_ggc): Do not round up the extra_order
On Jun 24, 2006, at 6:58 AM, Andrew Pinski wrote:
I can reproduce this, something is miscompiling cc1plus.
If I revert:
2006-06-23 Richard Guenther <[EMAIL PROTECTED]>
* ggc-page.c (init_ggc): Do not round up the
extra_order_size_table
sizes to MAX_ALIGNMENT. Fix the si
On Jun 23, 2006, at 7:42 PM, Jack Howarth wrote:
I have run into a build problem with tonights gcc trunk on
MacOS X which didn't exist in yesterdays
svn pull. The gcc trunk build on MacOS X 10.4.6 crashes with...
I can reproduce this, something is miscompiling cc1plus.
-- Pinski
cking whether to build shared libraries... yes
checking whether to build static libraries... yes
appending configuration tag "CXX" to libtool
checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
24 matches
Mail list logo
