Re: GCC 4.2.0 boostrap problems on FreeBSD/ia64

[Andreas Schwab]

Alexander Kabaev <[EMAIL PROTECTED]> writes:

> The instruction below appears to be the problematic one, but I cannot
> tell why:
>
> [MMI]  st8 [r16]=r17

This insn looks completely benign, I'd rather it's the next insn that is
the problem:

chk.a.clr r14, .L1063

This is a speculation check (see
 for the
Itanium Instruction Set Descriptions).  The insn checks the result of a
preceding advanced load and branches to the label if the check failed.
The branching behaviour of the insn may be unimplemented, and would have
to be emulated in the kernel, but apparently FreeBSD doesn't support it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pr11135: make PIC register a pseudo

[Rask Ingemann Lambertsen]

On Fri, Jan 06, 2006 at 02:48:30PM -0800, Richard Henderson wrote:
> 
> What they're looking for is, for functions that don't use
> the pic register, to not reserve the pic register so that
> it's available for computation.  This is harder.  In theory,
> ppc has some scheme for this, where they eliminate the pic
> register to itself.  I've never really understood how that's
> supposed to work.

   Suppose you tell reload that %rpic can be eliminated as %rpic + 0. Reload
will start out by assuming that the elimination is possible and %rpic will
be available for reloads. If no insns mention %rpic at all, it should just
work, and you will have recovered a register.

-- 
Rask Ingemann Lambertsen

Missed optimisation

[Tom Womack]

I have some code of the form

const int primes[] = {7,11,13,17,19};
const int nprimes = sizeof(primes)/sizeof(int);

and later an inmost loop of the form

bool happy = true;
for (int i=0; i

Re: GCC 4.2.0 Status Report (2007-05-11)

[Joseph S. Myers]

On Sun, 13 May 2007, Paul Jarc wrote:

> > Maybe there could be something like --with-libc=/some/path that
> > would automatically generate the correct Makefiles; that would be an
> > enhancement.
> 
> Yes, although a more general enhancement would be to let the user add
> arbitrary flags to LDFLAGS_FOR_TARGET.

You can add --sysroot=, and the supported way to have libc in an unusual 
location is to build as a cross compiler and use --with-sysroot / 
--with-build-sysroot.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.2.0 boostrap problems on FreeBSD/ia64

[Alexander Kabaev]

On Sun, 13 May 2007 10:53:44 +0200
Andreas Schwab <[EMAIL PROTECTED]> wrote:

> Alexander Kabaev <[EMAIL PROTECTED]> writes:
> 
> > The instruction below appears to be the problematic one, but I
> > cannot tell why:
> >
> > [MMI]  st8 [r16]=r17
> 
> This insn looks completely benign, I'd rather it's the next insn that
> is the problem:
> 
> chk.a.clr r14, .L1063
> 
> This is a speculation check (see
>  for
> the Itanium Instruction Set Descriptions).  The insn checks the
> result of a preceding advanced load and branches to the label if the
> check failed. The branching behaviour of the insn may be
> unimplemented, and would have to be emulated in the kernel, but
> apparently FreeBSD doesn't support it.
> 
> Andreas.
> 

Andreas and Zack,

thank you both for pointing me into the right direction. It does indeed
look like unimplemented instruction emulation in FreeBSD kernel.

-- 
Alexander Kabaev


signature.asc
Description: PGP signature

Re: GCC 4.2.0 Status Report (2007-05-11)

[Richard Guenther]

On 5/13/07, Jason Merrill <[EMAIL PROTECTED]> wrote:

Mark Mitchell wrote:
> PR 30252: Wrong code generation, perhaps due to the C++ front end's
> representation for base classes.  Jason, are you actively investigating
> this one?

I haven't been; I've been working on the forced unwind stuff, and
looking at the rvalue refs patch.  If you want I can work on this first,
but I doubt that the patch would be safe enough for the release branch.

Also, has someone actually verified that this is something that would be
fixed by the bases-as-fields work?


Possibly not.  See the audit trail of the PR.  But, we can work around the
problem by (bootstrapped and tested on x86_64-unknown-linux-gnu):

Index: passes.c
===
--- passes.c(revision 124635)
+++ passes.c(working copy)
@@ -498,8 +498,8 @@ init_optimization_passes (void)
  /* Initial scalar cleanups.  */
  NEXT_PASS (pass_ccp);
  NEXT_PASS (pass_fre);
-  NEXT_PASS (pass_dce);
  NEXT_PASS (pass_forwprop);
+  NEXT_PASS (pass_dce);
  NEXT_PASS (pass_copy_prop);
  NEXT_PASS (pass_merge_phi);
  NEXT_PASS (pass_vrp);

though the base on which I would say this patch is safe is contradicted
by the fact that it does fix (ok, work around) a regression ;)  The underlying
problem looks like an alias problem or a frontend problem leading to the
alias problem, but I'm out of fu here and Sunday asks for some other things
to do.

Richard.

Re: GCC 4.2.0 Status Report (2007-05-11)

[Mark Mitchell]

Jason Merrill wrote:
> Mark Mitchell wrote:
>> PR 30252: Wrong code generation, perhaps due to the C++ front end's
>> representation for base classes.  Jason, are you actively investigating
>> this one?
> 
> I haven't been; I've been working on the forced unwind stuff, and
> looking at the rvalue refs patch.  If you want I can work on this first,
> but I doubt that the patch would be safe enough for the release branch.

Yes, that's a good point.

> Also, has someone actually verified that this is something that would be
> fixed by the bases-as-fields work?

No, I don't think we know.  There's speculation in the PR trail, but
that's it.  I'd appreciate it if you were able to investigate further,
but I think I'd best just accept that this will not be fixed for 4.2.0.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

[Daniel Berlin]

On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:

Daniel Berlin wrote:
> On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Every time I think we're almost there with this release, I seem to
>> manage to get stuck. :-(  However, we're very close: the only PRs that
>> I'm waiting for are:
>>
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>> Daniel, I see you've been commenting on this; are you working on the
>> fix?  If so, do you have an ETA?
>
> It's not actually a PRE bug, andrew is right.
> None of the statements accessing volatile variables end up with
> has_volatile_ops set on them, which is what is really causing the
> problem.

Thanks -- but that doesn't answer my questions. :-)  Seriously, what I'm
trying to figure out is whether you (or someone) is working on fixing
this, so I can get a sense of the tradeoffs between releasing and
waiting for a fix.


It means we have to figure out what is breaking it first :)
I believe richard guenther has taken it over.

Re: GCC 4.2.0 Status Report (2007-05-11)

[Richard Guenther]

On 5/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:

On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
> > On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >> Every time I think we're almost there with this release, I seem to
> >> manage to get stuck. :-(  However, we're very close: the only PRs that
> >> I'm waiting for are:
> >>
> >> PR 31797: An infinite loop in the compiler while building RTEMS.
> >> Daniel, I see you've been commenting on this; are you working on the
> >> fix?  If so, do you have an ETA?
> >
> > It's not actually a PRE bug, andrew is right.
> > None of the statements accessing volatile variables end up with
> > has_volatile_ops set on them, which is what is really causing the
> > problem.
>
> Thanks -- but that doesn't answer my questions. :-)  Seriously, what I'm
> trying to figure out is whether you (or someone) is working on fixing
> this, so I can get a sense of the tradeoffs between releasing and
> waiting for a fix.

It means we have to figure out what is breaking it first :)
I believe richard guenther has taken it over.


Yes, it's fixed.

Richard.

[patches] fine grained bounds checking patches for gcc 4.0.4 and 3.4.6

[William Bader]

I have updated the bounds checking patches for gcc 4.0.2 and 3.4.4 on 
http://sourceforge.net/projects/boundschecking/

My patches are available from http://williambader.com/bounds/example.html
I have tested them under CentOS 4.4 Linux and Solaris/SPARC 10.

The patches add a -fbounds-checking flag that adds bounds checking tests to 
pointer and array accesses. Richard Jones developed the patches against 
gcc-2.7 in 1995. Herman ten Brugge is the current maintainer and updates 
patches to the boundschecking project at sourceforge.


You may freely mix object modules compiled with and without bounds checking. 
The bounds checker also includes replacements for mem* and str* routines and 
can detect invalid calls against checked memory objects, even from modules 
compiled without bounds checking.


You can run the bounds checking gcc from its build area using the script 
/u/gnu/bgcc-x.y/gcc/bounds/bgcc
For more build information, see the files created by the patches in 
/u/gnu/bgcc-x.y/gcc/bounds/.


To build a bounds checking gcc:
 cd /u/gnu  # go to a work area
 tar xzf gcc-x.y.tar.gz # unpack gcc
 mv gcc-x.y bgcc-x.y# rename the gcc directory
 cd bgcc-x.y# go to the bgcc directory
 patch -p1 -T < gcc-x.y-bgcc-x.y.pat # apply the patches
 touch gcc/c-parse.in   # force a rebuild of .y and .c
 mkdir objdir   # make an object file area
 cd objdir  # enter the area
 /u/gnu/bgcc-x.y/configure  # initialize the build
 make bootstrap # do the build

Here are some features of the patches:

   * Modules compiled with and without bounds checking may be linked 
together without special preparation.
 o Checked pointers may be passed to modules compiled without 
bounds checking.
 o Structures containing pointers may be passed between modules 
compiled with and without bounds checking.
   * Modules compiled without bounds checking still check some pointer 
accesses.
 o Checked pointers (pointers created by malloc or by modules 
compiled with bounds checking) are checked in calls to the str* and mem* 
library functions and in calls to modules compiled with bounds checking.
 o The checks are similar to a malloc debug library, except more 
powerful because they also check local and static variables created in 
modules compiled with checking.
   * The GCC_BOUNDS_OPTS environment variable passes options to the bounds 
checker.

 o The -never-fatal option continues after errors.
 o The -print-heap option shows memory leaks.

William Bader
email: [EMAIL PROTECTED]
www:   http://williambader.com

_
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

Re: Missed optimisation

[Eric Christopher]

On May 13, 2007, at 3:48 AM, Tom Womack wrote:


I have some code of the form



This really isn't enough, I put a bit of a testcase together, but  
nothing that would give bad behavior at -O3 (there is no -O9).


Have more of a testcase? Something compilable?

-eric

Likely code generation bug in GCC 4.0.1

[Claus Fischer]

Dear GCC folks,


I think I found a code generation bug in GCC 4.0.1.

I'm sending this mail to make sure this bug is known and
is or will be removed in newer versions.
On a quick glance I couldn't find it in the bug database,
so it may not be known.


***


I am developing a simulation program that appears to show a
bug when compiled with gcc 4.0.1 (cross-compiler on Linux
for MINGW target) but compiles fine with GCC 3 or GCC 4.1.2
(native on Linux) as well as with gcc 3 mingw on Cygwin/Windows.

For the 4.0.1 cross-compiled program, the bug disappears
when the function is duplicated under another name, and
the duplicate is called instead in the critical place.
The original (buggy) function is not inlined, but the
duplicate is inlined because it's only called in one
place.

The function is an AVL tree deletion which operates
with pointers only.

I attach the C source code and the assembler code (output of
objdump -d) to this mail. I have marked the two places in C
where I think the bug appears with a comment containing "BUG".
I'm not good enough in assembler to verify the bug there.

What seems to happen is that the value of ta, which should be
set to the address of the parent node's left-child pointer in
this case, remains unchanged, i.e. remains pointing to 'dummy'.
Then, in the subsequent assignment *ta = r the pointer does
not get changed appropriately.

Before filing this as a bug, I'd like some person who can
read assembler to examine the situation.
I'll gladly assist with further information.

***


The code is compiled with this command:

i386-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../bugsklsim/src -I..
-std=gnu9x -W -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wbad-function-cast -Wcast-qual -Wcast-align -Wmissing-declarations 
-Wnested-externs -Winline -Waggregate-return -Wshadow -g -O2 -MT sklsim.o -MD 
-MP -MF ".deps/sklsim.Tpo" -c -o sklsim.o ../../bugsklsim/src/sklsim.c



Best regards,

Claus Fischer

-- 
Claus Fischer <[EMAIL PROTECTED]>
http://www.clausfischer.com/

Likely code generation bug in GCC 4.0.1

[Claus Fischer]

Dear GCC folks,


I think I found a code generation bug in GCC 4.0.1.

I'm sending this mail to make sure this bug is known and
is or will be removed in newer versions.
On a quick glance I couldn't find it in the bug database,
so it may not be known.


***


I am developing a simulation program that appears to show a
bug when compiled with gcc 4.0.1 (cross-compiler on Linux
for MINGW target) but compiles fine with GCC 3 or GCC 4.1.2
(native on Linux) as well as with gcc 3 mingw on Cygwin/Windows.

For the 4.0.1 cross-compiled program, the bug disappears
when the function is duplicated under another name, and
the duplicate is called instead in the critical place.
The original (buggy) function is not inlined, but the
duplicate is inlined because it's only called in one
place.

The function is an AVL tree deletion which operates
with pointers only.

I attach the C source code and the assembler code (output of
objdump -d) to this mail. I have marked the two places in C
where I think the bug appears with a comment containing "BUG".
I'm not good enough in assembler to verify the bug there.

What seems to happen is that the value of ta, which should be
set to the address of the parent node's left-child pointer in
this case, remains unchanged, i.e. remains pointing to 'dummy'.
Then, in the subsequent assignment *ta = r the pointer does
not get changed appropriately.

Before filing this as a bug, I'd like some person who can
read assembler to examine the situation.
I'll gladly assist with further information.

***


The code is compiled with this command:

i386-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../bugsklsim/src -I..
-std=gnu9x -W -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wbad-function-cast -Wcast-qual -Wcast-align -Wmissing-declarations 
-Wnested-externs -Winline -Waggregate-return -Wshadow -g -O2 -MT sklsim.o -MD 
-MP -MF ".deps/sklsim.Tpo" -c -o sklsim.o ../../bugsklsim/src/sklsim.c



Best regards,

Claus Fischer

-- 
Claus Fischer <[EMAIL PROTECTED]>
http://www.clausfischer.com/
typedef struct sklsim_event_s {
/* AVL tree */
int ev_bal; /* Tree balance: -1 left 0 middle 1 right */
struct sklsim_event_s *ev_l;/* Left subtree */
struct sklsim_event_s *ev_r;/* Right subtree */
struct sklsim_event_s *ev_p;/* Parent */

/* Those members not used in deletend function: */
double t;   /* Time of next event */
sklsim_otype_t otype;   /* Object type: OTYPE_PAX, OTYPE_AC, ... */
} sklsim_event_t;



/* AVL Tree: Delete node d from the tree. Node d must be in the tree.
 * Return a pointer to the tree root, or to the top node of the tree.
 * For root-less trees, return the new tree pointer.
 */
static sklsim_event_t * eventtree_deletend( sklsim_event_t * d)
{
sklsim_event_t * s;		/* Node to be removed */
sklsim_event_t * su;		/* Parent of s */
sklsim_event_t * sc;		/* Child of s */

/* Nodes for the rebalancing loop */
sklsim_event_t * t;
sklsim_event_t * x;

/* The algorithm removes element d from the tree. If d has
   two children, the algorithm first removes d's next left
   neighbour, s, which is the rightmost node in d's left
   subtree. At the very end, s is put in d's place in the
   tree. */


/* (1) Find node s to remove instead of d */
/* ** */


/* Find node s such that
 * - if d has not two children, s is d
 * - else s is the immediate left neighbour of d
 * - s has one child node or none
 */
s = d;
if (s->ev_r != 0)
{
	sklsim_event_t * ss;
	ss = s->ev_l;
	while (ss != 0)
	{
	s = ss;
	ss = s->ev_r;
	}
}



/* (2) Adjust the tree above s to reflect the future reduced height of s */
/* * */


/* State:
 * The height of the subtree rooted at s will be reduced in (3)
 * when s will be removed. Before that happens, the balances
 * of all nodes above s need to be adjusted.
 * In the loop, the height of s is considered to be reduced already.
 */


/* The loop reduces height of subtree x under its parent t */
x = s;
t = s->ev_p;
while (t != 0)
{
	sklsim_event_t * tu;		/* parent of subtree t */
	sklsim_event_t * *ta;	/* address of pointer to subtree t */
	sklsim_event_t * dummy;

	/* Parent and address of t */
	tu = t->ev_p;
	if (tu != 0)
	{
	if (tu->ev_l == t)
		ta = &tu->ev_l;	/* BUG HAPPENS HERE, I THINK */
	else
		ta = &tu->ev_r;
	}
	else
	{
	ta = &dummy;
	}

	/* State:
	 * - The height of x has been reduced.
	 * - t is the parent of x.
	 * - t's subtree will be rearranged (including t)
	 * - tu is the parent of t or NIL
	 * - ta is the address of the parent's pointer to t
	 * After rearrangement:
	 * - the new subtree will be hooked under ta
	 * - if the subtree under ta has lost height:
	 *   x is set to the new subtree under ta
	 *   and the loop will con

Re: GCC 4.2.0 Status Report (2007-05-11)

[Mark Mitchell]

Kenneth Hoste wrote:

> I admit this is not a blocking bug, but it seems fairly (very) easy to
> solve... I still have to figure out how the patch submission framework
> works (never contributed to an open-source project before), so I didn't
> get around to solve it myself.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31586
> 
> Maybe someone could solve this, so it is solved in GCC 4.2 and others?

Yes, this would be an easy bug to fix, and it would be good to do so,
but I don't think this is likely before 4.2.0.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

[Jason Merrill]

Mark Mitchell wrote:

No, I don't think we know.  There's speculation in the PR trail, but
that's it.  I'd appreciate it if you were able to investigate further,
but I think I'd best just accept that this will not be fixed for 4.2.0.


Or revert the patch that revealed the bug, or apply Richard Guenther's 
other patch to work around it?


Jason

Re: Status of the pointer_plus branch

[Andrew Pinski]

On 5/12/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:


The two regressions which exist are:

FAIL: gcc.dg/vect/vect-102.c scan-tree-dump-times possible dependence
between data-refs 1
FAIL: gcc.dg/vect/vect-104.c scan-tree-dump-times possible dependence
between data-refs 1



I had forgot to handle POINTER_PLUS_EXPR in split_constant_offset, I
am testing that patch with the merge from the mainline also right now.
So after this patch, there are no testsuite regressions on i686-linux-gnu.

Thanks,
Andrew Pinski

GCC 4.2.0 Status Report (2007-05-13)

[Mark Mitchell]

Thanks to the efforts of Richard G. and others, we've managed to close
PR 31797, one of the two I highlighted in my previous status report on
Friday.

Meanwhile, PR 30252, which is the other issue I highlighted, looks more
difficult to solve.  In particular, we don't yet understand the cause of
the failure.

The only changes from RC3 are:

+2007-05-12  Richard Guenther  <[EMAIL PROTECTED]>
+
+   PR tree-optimization/31797
+   * tree-ssa-forwprop.c (forward_propagate_addr_expr): Do not
+   propagate into a stmt that has volatile ops.

+2007-05-11  Jerry DeLisle  <[EMAIL PROTECTED]>
+
+   PR libfortran/31880
+   * io/unix.c (fd_alloc_r_at): Fix calculation of physical offset.

+2007-05-07  Ian Lance Taylor  <[EMAIL PROTECTED]>
+
+   PR java/31842
+   * java/lang/natString.cc (_Jv_FormatInt): Avoid undefined signed
+   overflow.

Therefore, I'm going to get 4.2.0 out the door.

Please consider the 4.2.0 branch completely frozen at this time.

I will be working through the release checklist tonight.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

[Mark Mitchell]

Jason Merrill wrote:
> Mark Mitchell wrote:
>> No, I don't think we know.  There's speculation in the PR trail, but
>> that's it.  I'd appreciate it if you were able to investigate further,
>> but I think I'd best just accept that this will not be fixed for 4.2.0.
> 
> Or revert the patch that revealed the bug, or apply Richard Guenther's
> other patch to work around it?

Sorry, your message *just* crossed:

  http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html

in which I declared failure. :-)

However, the release isn't really released until it's on the FTP sites,
of course, so there's still time to talk me into a different course of
action.

I'm concerned about either of the other approaches, in that we don't
fully understand why they work, so we can't really be confident we're
not just pushing the bug around.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

GCC 4.2.0 Branch Frozen for Release

[Mark Mitchell]

As per:

http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html

> Therefore, I'm going to get 4.2.0 out the door.
> 
> Please consider the 4.2.0 branch completely frozen at this time.
> 
> I will be working through the release checklist tonight.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

[Jason Merrill]

Mark Mitchell wrote:

I'm concerned about either of the other approaches, in that we don't
fully understand why they work, so we can't really be confident we're
not just pushing the bug around.


Yes.  But I would assert that pushing the bug back to where it was in 
previous releases is better because it's not a regression.


Jason

Re: GCC 4.2.0 Status Report (2007-05-11)

[Mark Mitchell]

Jason Merrill wrote:
> Mark Mitchell wrote:
>> I'm concerned about either of the other approaches, in that we don't
>> fully understand why they work, so we can't really be confident we're
>> not just pushing the bug around.
> 
> Yes.  But I would assert that pushing the bug back to where it was in
> previous releases is better because it's not a regression.

I agree in principle -- much better the bugs we know than the ones we
don't.  But, IIUC, the patch we'd be reverting is from March, 2006,
which means that there's potentially a lot more that depends on it.  In
that sense, I don't even feel confident that reverting the change is a
conservative move, likely to lead to less optimal code, but not wrong
code.  Are you?  (That's a serious question; not a rhetorical one.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

[Jason Merrill]

Mark Mitchell wrote:


I agree in principle -- much better the bugs we know than the ones we
don't.  But, IIUC, the patch we'd be reverting is from March, 2006,
which means that there's potentially a lot more that depends on it.  In
that sense, I don't even feel confident that reverting the change is a
conservative move, likely to lead to less optimal code, but not wrong
code.  Are you?  (That's a serious question; not a rhetorical one.)


That's a fair question; I don't know anything about the patch or the bug 
it was intended to fix.  Richard would know better.


Jason

Re: GCC 4.2.0 boostrap problems on FreeBSD/ia64

[Maxim Kuvyrkov]

Alexander Kabaev wrote:

On Sun, 13 May 2007 10:53:44 +0200
Andreas Schwab <[EMAIL PROTECTED]> wrote:


Alexander Kabaev <[EMAIL PROTECTED]> writes:


The instruction below appears to be the problematic one, but I
cannot tell why:

[MMI]  st8 [r16]=r17

This insn looks completely benign, I'd rather it's the next insn that
is the problem:

chk.a.clr r14, .L1063

This is a speculation check (see
 for
the Itanium Instruction Set Descriptions).  The insn checks the
result of a preceding advanced load and branches to the label if the
check failed. The branching behaviour of the insn may be
unimplemented, and would have to be emulated in the kernel, but
apparently FreeBSD doesn't support it.


As a workaround you can supply '-mno-sched-ar-in-data-spec' switch to 
the compiler which will turn of data speculations that require chk.a 
instructions to check them.


Am I right that you are using Itanium1 machine for compilation?  I 
understand that Itanium2 should not have this issue as it supports 
chk.[as] instructions in hardware.


Considering the long term solution I will post a patch that will turn 
off speculations requiring chk.[as] instruction for Itanium1.


Can you please file a PR in the bugzilla if you haven't done so yet?


Thanks,

Maxim