Revital1 Eres writes:
> Index: loop-doloop.c
> ===
> --- loop-doloop.c (revision 168397)
> +++ loop-doloop.c (working copy)
> + /* The third case: the compre and decrement instructions
s/compre/compare/.
> Index: con
Hello,
I'm using GCC 4.3.2 (debian provided) on IA64 machine and I'm starting
to be hit by while building GHC (Haskell compiler) HEAD:
/usr/bin/ld: : short data segment overflowed (0x434a58 >= 0x40)
/usr/bin/ld: can't relax section: No such file or directory
linker messages. In the past
Hi,
I've seen GCC emit many unneeded moves in very simple cases when
handling double floating point values. I tracked this down to the
lower-subreg pass that splits DF->DF moves into DF->(2*SI)->DF moves.
I suppose that the introduced mode changes prevent the IRA from
coalescing the moves and thus
On 6 January 2011 10:27, Frederic Riss wrote:
> Hi,
>
> I've seen GCC emit many unneeded moves in very simple cases when
> handling double floating point values. I tracked this down to the
> lower-subreg pass that splits DF->DF moves into DF->(2*SI)->DF moves.
> I suppose that the introduced mode
Frederic Riss writes:
> I tried to limit the lower-subreg pass to splitting integral types by
> constraining MODES_TIEABLE_P. This works for my simple test cases, but
> I get some testsuite regressions of the form:
>
> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
> unrecogn
On 6 January 2011 15:27, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>> unrecognizable insn:
>> (insn 45 2 46 2
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:2 (set
>> (subreg:SI (subreg:DF (reg/v:DI 136 [ d ])
Frederic Riss writes:
> 136 is a pseudo. I have movdf and movsf patterns that accepts
> constants. I'm not sure what happens. Also, strictly speaking, the
> unrecognized pattern above is a SI move and not a floating point move,
> isn't it?
Yes, it is.
> I managed to get thinks going by constrai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/11 07:58, Frederic Riss wrote:
> On 6 January 2011 15:27, Ian Lance Taylor wrote:
>> Frederic Riss writes:
>>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>>> unrecognizable insn:
>>> (insn 45 2 46 2
>>> ../gcc/testsu
On 6 January 2011 16:14, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> I managed to get thinks going by constraining MODES_TIEABLE_P and
>> adding 2 patterns of the form:
>>
>> [(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 0)
>> (match_operand 1 "immediate_operand" "i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/11 03:23, Frederic Riss wrote:
> On 6 January 2011 10:27, Frederic Riss wrote:
>> Hi,
>>
>> I've seen GCC emit many unneeded moves in very simple cases when
>> handling double floating point values. I tracked this down to the
>> lower-subreg
Frederic Riss writes:
> I use nonimmediate_operand as a movsi destination predicate. I think
> this is pretty standard. But if I follow the code in
> recog.c:general_operand, I can see that it will reject (subreg (subreg
> ...)) which my initial pattern is. So yes, my movsi destination
> predicat
On 6 January 2011 17:02, Ian Lance Taylor wrote:
> Oh yeah, you should never have a subreg of a subreg. That's a bug.
> Where did that come from?
Oh, that's interesting information! I have a splitter for movdf that
must be the culprit. I will tighten the split condition to disallow
splitting a s
Frederic Riss writes:
> On 6 January 2011 17:02, Ian Lance Taylor wrote:
>> Oh yeah, you should never have a subreg of a subreg. That's a bug.
>> Where did that come from?
>
> Oh, that's interesting information! I have a splitter for movdf that
> must be the culprit. I will tighten the split co
On 01/06/2011 01:17 AM, Karel Gardas wrote:
> BTW: This is on GCC Compile Farm IA64 machine. Now my question is: how
> to solve this issue? Does GCC already support something Intel
> discusses in 2008 here:
> http://software.intel.com/en-us/articles/short-data-segment-overflow-error-on-linux-64-on-
On 01/06/2011 06:58 AM, Frederic Riss wrote:
> 136 is a pseudo. I have movdf and movsf patterns that accepts
> constants.
This one statement is suspicious to me. Do I read from this that
you have fp move patterns that accept constants but not registers?
Move patterns are special in that they *mus
On 2010/12/31 09:38 PM, Richard Sandiford wrote:
> Mingjie Xing writes:
>> There are two test cases failed when run 'make check-gcc
>> RUNTESTFLAGS="mips.exp"'. The log is,
>>
>> Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc
>> -B/home/xmj/tools/build-test-trunk-mips/gcc/
>> /
I am trying to debug this, alas not very successfully so far and am
looking for a pointer or two.
This happens with head as well; binutils (/usr/local/bin/ld) is 2.20.1.
Note 1: This can be avoid configuring with --disable-rpath. GCC
understands --disable-rpath, yet the string "rpath" does not
On 01/06/2011 07:07 PM, Gerald Pfeifer wrote:
I am trying to debug this, alas not very successfully so far and am
looking for a pointer or two.
This happens with head as well; binutils (/usr/local/bin/ld) is 2.20.1.
Note 1: This can be avoid configuring with --disable-rpath. GCC
understands -
* Gerald Pfeifer wrote on Thu, Jan 06, 2011 at 08:07:26PM CET:
> I am trying to debug this, alas not very successfully so far and am
> looking for a pointer or two.
>
> This happens with head as well; binutils (/usr/local/bin/ld) is 2.20.1.
>
>
> Note 1: This can be avoid configuring with --disa
Le jeudi 06 janvier 2011 à 09:29 -0800, Richard Henderson a écrit :
> On 01/06/2011 06:58 AM, Frederic Riss wrote:
> > 136 is a pseudo. I have movdf and movsf patterns that accepts
> > constants.
>
> This one statement is suspicious to me. Do I read from this that
> you have fp move patterns that
On Thu, 6 Jan 2011, Ralf Wildenhues wrote:
> Could be libtool issue or lib-link.m4 one (or gcj one). Can you send
> ./libtool --tag=GCJ --config
> output?
I assume you mean from libjava in the build tree? Attached.
(Note this is now x86_64-portbld-freebsd8.2, newer than the original
report, b
Snapshot gcc-4.5-20110106 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110106/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
I would like to help with some gcc bug triage, and have a few
questions about doing so.
1. My plan is to start testing bugs against the latest stable build
(4.5.2), on an Intel x86-64 architecture (possibly also testing 32 bit
bugs). My main focus will be on "missed-optimizations", although
Tony Poppleton writes:
> 1. My plan is to start testing bugs against the latest stable build
> (4.5.2), on an Intel x86-64 architecture (possibly also testing 32 bit
> bugs). My main focus will be on "missed-optimizations", although I
> will try and do others too. I have read the
> http://gcc.g
24 matches
Mail list logo
