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
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
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
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
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
* 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
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 -
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 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/
>> /
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 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-
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 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:
> 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
-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
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 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
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
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:
> 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 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
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
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
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
24 matches
Mail list logo
