[Bug target/28115] New: possible bug in recog_memoized usage in rs6000.c??

2006-06-20 Thread dkwan at transmeta dot com 
This problem is found by code inspection. The comment of the generated file
insn-recog.c says:

  `recog' contains a decision tree that recognizes whether the rtx
   X0 is a valid instruction.

   recog returns -1 if the rtx is not valid.  If the rtx is valid, recog
   returns a nonnegative number which is the insn code number for the
   pattern that matched.  This is the same as the order in the machine
   description of the entry that matched.  This number can be used as an
   index into `insn_data' and other tables.

recog_memoized() is just a wrapper around recog() to cache results.
In recog.h:

/* Try recognizing the instruction INSN,
   and return the code number that results.
   Remember the code so that repeated calls do not
   need to spend the time for actual rerecognition.

   This function is the normal interface to instruction recognition.
   The automatically-generated function `recog' is normally called
   through this one.  (The only exception is in combine.c.)  */

static inline int
recog_memoized (rtx insn)
{
  if (INSN_CODE (insn) < 0)
INSN_CODE (insn) = recog (PATTERN (insn), insn, 0);
  return INSN_CODE (insn);
}

Yet in rs6000.c, there is code in rs6000_adjust_cost:

line 16312:
  if (! recog_memoized (insn))
return 0;

line: 16355 
  && recog_memoized (dep_insn)
  && (INSN_CODE (dep_insn) >= 0)

These look as if it is assumed that recog_memoized return 0 for invalid
instructions but 0 is a valid result code. The checks should be done against
negative return values instead.


-- 
   Summary: possible bug in recog_memoized usage in rs6000.c??
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dkwan at transmeta dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28115

[Bug libstdc++/33682] libstdc++ broken for !__GTHREAD_HAS_COND hosts

2007-10-07 Thread dkwan at transmeta dot com 


--- Comment #2 from dkwan at transmeta dot com  2007-10-07 17:55 ---
Sorry about the breakage. I only tested the original patch on Linux. The
obvious patch should be fine.  I am not familiar with mingw-w64. Does it
provide a similar conditional variable as POSIX? If so, another way to fix this
is to do similar changes as in gthr-posix.h to make the new locking works for
mingw-w64 as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682

[Bug c++/34846] [4.3 regression] ICE on STL container iterator copy

2008-01-18 Thread dkwan at transmeta dot com 


--- Comment #3 from dkwan at transmeta dot com  2008-01-19 03:33 ---
cc1plus SEG faults because the hash table local_specializations is NULL.  There
are calls to retrieve_local_specialization in pt.c. All but one, which caused
this ICE, are protected by a NULL test.  I have a sandbox with a trivial fix of
checking local_specializations before call retrieve_local_specialization. It
bootstrapped on i686-unknown-linux-gnu and I am now waiting for the regression
tests finish.  If everything looks fine, I will send that out to gcc-patches
tonight or tomorrow the latest.

(In reply to comment #2)
> Looks related to PR34573.
> 
> Backtrace:
> 
> #0  0x010bacb1 in htab_find_with_hash (htab=0x0, 
> element=0x2b899b95a300, hash=863155296)
> at /space/rguenther/src/svn/trunk/libiberty/hashtab.c:566
> #1  0x0047b935 in retrieve_local_specialization (tmpl=0x2b899b95a300)
> at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:980
> #2  0x004bd664 in tsubst (t=0x2b899b95a3c0, args=0x2b899b95d8a0, 
> complain=tf_none, in_decl=0x0)
> at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8859
> #3  0x004bd7a4 in tsubst (t=0x2b899b95a480, args=0x2b899b95d8a0, 
> complain=tf_none, in_decl=0x0)
> at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8879
> #4  0x004bd7a4 in tsubst (t=0x2b899b95a840, args=0x2b899b95d8a0, 
> complain=tf_none, in_decl=0x0)
> at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:8879
> ...
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34846

[Bug target/30451] New: incorrect attributes in *movti_ppc64 of rs6000.md

2007-01-12 Thread dkwan at transmeta dot com 
I found the following problem in rs6000.md:

(define_insn "*movti_ppc64"
  [(set (match_operand:TI 0 "nonimmediate_operand" "=r,o<>,r")
(match_operand:TI 1 "input_operand" "r,r,m"))]
  "TARGET_POWERPC64 && (gpc_reg_operand (operands[0], TImode)
   || gpc_reg_operand (operands[1], TImode))"
  "#"
  [(set_attr "type" "*,load,store")])

It appears that the order of the load and store attributes in the set_attr
expression is incorrect. If operand 0 is memory (o<>) and operand 1 is a
register (r), the instruction should be a store, not a load. Similarly, if
operand 0 is a register ("r") and operand 1 memory ("m"), the instruction
should be load, not a store.

I think either the constraint order or the attribute order need to be reversed
to make constraints and attributes match.


-- 
   Summary: incorrect attributes in *movti_ppc64 of rs6000.md
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
      Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dkwan at transmeta dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: ppu-unknown-lv2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30451

[Bug target/30451] incorrect attributes in *movti_ppc64 of rs6000.md

2007-01-13 Thread dkwan at transmeta dot com 


--- Comment #3 from dkwan at transmeta dot com  2007-01-14 05:47 ---
There is additional code for the CELL PPU to adjust the latencies of data and
address operands of integer stores. The code requires accurate load/store
attributes. I guess there is nothing in the main-line gcc that relies on the
load/store attributes being correct so it does not matter in the main line.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30451