James E Wilson wrote:
This revised patch does appear to fix the only complaint that Geoff had
with the original patch. I think it is OK with the typo fixed and the
addition of a doc change.
OK, done.
Thank you.
Peter
2005-08-?? Peter O'Gorman <[EMAIL PROTECTED]>
PR 21366
*
On Thu, 2005-08-04 at 05:41, Peter O'Gorman wrote:
> + trying to interpret the rest of the command line.
> + Use heuristic that all copnfiguration names must have at least
> + one dash '-'. This allows us to pass options starting with -b. */
There is a typo here copnfiguration->confi
Tabony, Charles wrote:
How can I
distinguish recognized from unrecognized insns in ASM_OUTPUT_OPCODE?
Try using the variable this_is_asm_operands.
ASM_OUTPUT_OPCODE is an old macro that doesn't get used much anymore.
FINAL_PRESCAN_INSN is better if you can use it. No recog_data.operand
tric
> I think I understand what was being attempted now. IIUC, the logic
> should have been (again, for the QI/SI instance):
>
>If at least _26_ bits are set, and if c1 is < 64, ok to make the
> transformation.
Yes, that was the intended logic.
> In this case, I don't see an instance where "comp
Am I misinterpreting the logic? Am I missing something
fundamental? I appreciate any feedback / pointers / clues / etc...
Nothing like hitting the send button to make the lightbulb go on.
I think I understand what was being attempted now. IIUC, the logic
should have been (again, for the
Snapshot gcc-4.0-20050804 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050804/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050804
You'll
I'm seeing invalid code produced for a simple test case targeting arm-
none-elf (attached), which I believe is caused by an invalid
transformation in simplify_comparison. It's transforming code of the
form:
(compare (subreg:QI (plus (reg:SI) (-1)))
(-3))
into:
(compare (plu
Giovanni --
On July 12th, you posted:
http://gcc.gnu.org/ml/gcc/2005-07/msg00483.html
asking about handing of new ports.
The SC has discussed the issue, at your request. Fundamentally, the SC
feels that this issue is outside its purview as a "board of directors"
for GCC; this is an issue
Hi,
I am trying to use recog_data.operand in ASM_OUTPUT_OPCODE to access the
operands of the current insn for printing as the documentation for
ASM_OUTPUT_OPCODE suggests. However, this does not work for printing
inline assembly because asm insns are never matched. How can I
distinguish recogniz
On Thursday 04 August 2005 19:12, Jan Hubicka wrote:
> > Hi,
> > I've branches the IPA branch yesterday and re-directed current SPEC
> > testers running tree-profiling branch (now officially retired ;) to it.
> > ( http://www.suse.de/~aj/SPEC/amd64 ).
> > The branch should be used for interprocedur
> Hi,
> I've branches the IPA branch yesterday and re-directed current SPEC
> testers running tree-profiling branch (now officially retired ;) to it.
> ( http://www.suse.de/~aj/SPEC/amd64 ).
> The branch should be used for interprocedural optimization projects that
> has serious chance to get into
Gunther Nikl <[EMAIL PROTECTED]> writes:
> Is EPILOGUE_USES only for the save and restore? I would have to add
> some big chunk of code to it and that would propagate to several
> places. It seems emitting a USE has lower impact.
EPILOGUE_USES doesn't emit code. It simply takes a register
Hi,
I've branches the IPA branch yesterday and re-directed current SPEC
testers running tree-profiling branch (now officially retired ;) to it.
( http://www.suse.de/~aj/SPEC/amd64 ).
The branch should be used for interprocedural optimization projects that
has serious chance to get into 4.2 (or perh
Hi Volker,
On Thu, 4 Aug 2005 02:31 am, Volker Reichelt wrote:
> You might want to try a recent snapshot of gcc 4.0.2, first.
> Two aliasing bugs got fixed after the 4.0.1 release:
>
> http://gcc.gnu.org/PR22591
> http://gcc.gnu.org/PR23192
>
> The first even caused std::list::swap to be miscompile
On 8/4/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> The gcc mailing list is [EMAIL PROTECTED]
I'd say it's gcc@gcc.gnu.org though...
--
Cheers,
/ChJ
On 8/4/05, Carl Whitwell <[EMAIL PROTECTED]> wrote:
> Hi,
> thought I'd drop you a mail, would put it on gcc mailing list but
> haven't got time to work out how to send it there at this moment.
The gcc mailing list is [EMAIL PROTECTED]
> All testing here is done on x86 processors using g
Successfully built and installed GCC version 4.0.1 on i686-pc-linux-gnu
Debian Sarge 3.1
# ../config.guess
i686-pc-linux-gnu
# /usr/local/bin/gcc4.0 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /usr/local/src/gcc-4.0.1/configure --program-suffix=4.0
--enable-threads --en
Is it possible to leverage the new -fstack-protector-all feature
in gcc 4.1 branch to discover the origin of memory leaks that are
clobbering the stack? I have a fortran program which segfaults in
the next write it attempts after a particular read. I have compiled
this fortran code with -fstack-
based very much on the work done previously by Geoff and Devang.
If this is okay, could the approver please commit, I do not have write access.
"Tested" as follows:
imac% ./xgcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.2.0
Configured with: ../configure --enable-languages=c
Thre
On Wed, 2005-08-03 at 22:54 -0700, Dan Kegel wrote:
> Geez, 'delta' from http://www.cs.berkeley.edu/~dsw
> really does seem to make it easy to track down
> near-minimal testcases for ICEs.
Just remember to use topformflat and -Wfatal-errors to make it faster
(it's particularly helpful for C++ :P)
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
>> > No it is not, once you take the address (which should be
>> rejected), it > is of type "unsigned int *" and not unaligned
>> variable, passing it to > memcpy assumes the type alignment is the
>> natural alignment.
>>
>> T
On Wed, Aug 03, 2005 at 10:49:49AM -0700, Ian Lance Taylor wrote:
> Gunther Nikl <[EMAIL PROTECTED]> writes:
>
> > "Attempt to delete prologue/epilogue insn"
> >
> > unless the stackslot was marked with MEM_VOLATILE_P. I don't think thats
> > the proper fix.
>
> As Nathan said, you can add a U
22 matches
Mail list logo
