Stephen Rothwell reported that he also saw it on powerpc.

I verified the bug on powerpc with the following gcc versions:
- 4.2.4
- 4.3, latest svn
- 4.4, latest svn

4.1.2 is fine.

Created attachment 16025 [details]
hw.i.gz

$ powerpc64-linux-gcc --version
powerpc64-linux-gcc (GCC) 4.4.0 20080805 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ powerpc64-linux-gcc -O1 hw.i
/TMP/git/linux-next/drivers/net/wireless/ath9k/hw.c: In function 'ath9k_hw_9280_spur_mitigate':
/TMP/git/linux-next/drivers/net/wireless/ath9k/hw.c:4660: internal compiler error: in expand_expr_real_1, at expr.c:9176
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$

Reducing for PPC-linux-gnu.

Reduced testcase:
void ath9k_hw_9280_spur_mitigate( int bin, int cur_vit_mask) {
  int i;
  signed char mask_m[123];
  signed char mask_p[123];
  signed char mask_amt;
  for (i = 0; i < 123;i++)
  {
    int __x1 = ({int __x = cur_vit_mask - bin;(__x < 0) ? -__x : __x;});
    mask_amt =  __x1< 75;
    mask_m[cur_vit_mask ] = mask_amt;
    mask_p[cur_vit_mask] = mask_amt;
    cur_vit_mask --;
  }
  f(mask_p);
  f(mask_m);
}

Expand is getting:
(int) ivtmp.20 >= -74 && (int) ivtmp.20 <= 74

Which comes from folding of:
ABS_EXPR <(int) ivtmp.20> <= 74

Which is folded at:
4509              exp = fold_convert (lang_hooks.types.type_for_mode
4510                                    (GET_MODE (SUBREG_REG (target)),
4511                                     SUBREG_PROMOTED_UNSIGNED_P (target)),
4512                                  exp);

This worked for at least 3.4.0 as this tree was able to be expanded :).

(In reply to comment #4)
I can confirm that the reduced test case fails for me with gcc 4.0.4, 4.1.2, 4.2.4, and 4.3.1 on both powerpc and powerpc64. gcc-3.4.6 and older work.

It doesn't fail for me with gcc-4.x on either sparc64 or arm.

I think the options are:
1) handle TRUTH_{AND,OR}IF_EXPR in expand_expr again (revert part of Paolo's
   2004-08-09 expr.c "dead" code removals) - while these aren't present
   in GIMPLE nor can be created by TER, they can be created by folding during
   expansion.  Maybe even COMPOUND_EXPR could be handled there and all the
   ugly hacks builtins.c does to work around this could be removed.
2) have a special flag for fold-const.c, set during expansion, that would
   preclude certain kinds of folding (e.g. creation of the trees that aren't
   handled by the expander)
3) have expand's special versions of the various fold* routines, look for the
   unhandled trees in what it creates and either fail to fold them, or transform
   to something else.

IMHO 1) would be probably easiest to implement, 3) too ugly to live, 2) possible.

Subject: Bug 37014

Author: jakub
Date: Tue Aug 12 18:05:43 2008
New Revision: 139029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139029
Log:
	PR middle-end/37014
	* expr.c (expand_expr_real_1): Handle TRUTH_ANDIF_EXPR
	and TRUTH_ORIF_EXPR.
	* dojump.c (do_jump): Likewise.

	* gcc.c-torture/compile/20080812-1.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/20080812-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dojump.c
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog

Subject: Bug 37014

Author: jakub
Date: Tue Aug 12 18:36:28 2008
New Revision: 139032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139032
Log:
	PR middle-end/37014
	* expr.c (expand_expr_real_1): Handle TRUTH_ANDIF_EXPR
	and TRUTH_ORIF_EXPR.
	* dojump.c (do_jump): Likewise.

	* gcc.c-torture/compile/20080812-1.c: New test.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/20080812-1.c
Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/dojump.c
    branches/gcc-4_3-branch/gcc/expr.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

Fixed.