On Mon, 18 Sep 2006, Mark Mitchell wrote:
> Andrew Pinski wrote:
> > The documention on VECTOR_CST is not clear if we can have missing
> > elements in that the remaining elements are zero. Right we produce such
> > VECTOR_CST for things like:
> > #define vector __attribute__((vector_size(16) ))
>
On Sat, 2 Sep 2006, Rask Ingemann Lambertsen wrote:
>What does this instruction mean?
>
> (set (reg:CC 13 cc)
> (ge (mem/c/i:HI (plus:HI (reg/f:HI 15 argp)
> (const_int 2 [0x2])) [2 x+0 S2 A16])
> (const_int 0 [0x0])))
>...
>The (reg:CC 13 cc) part is the condit
On Fri, 25 Aug 2006, Paolo Bonzini wrote:
> After I'm done with the base_reg_class changes, I will try
> modifying address_operand to be something along the lines of your U
> constraint:
Yeah, that does sound like the real bug; nothing should be using
non-strict checking after reload as address_op
On Thu, 24 Aug 2006, Paolo Bonzini wrote:
> Anyway, I was not meaning to *not* account for anything, but just to
> replace REG_OK_STRICT with checks on reload_in_progress and
> reload_completed. I understand the semantics that you wanted for 'U'.
>
> The bug may be that in some cases, 'U' is check
On Thu, 24 Aug 2006, Paolo Bonzini wrote:
> Some ports, notably MMIX, are using different definitions of
> EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
> the same instruction may be considered invalid in reload.c and valid by
> recog.c.
When I wrote that code, accounti
On Fri, 17 Feb 2006, Grigory Zagorodnev wrote:
> For example cgi-bin/mesg.cgi script of mhonarc mail-to-html converter,
> the one used by gcc.gnu.org, can "extract a message from an archive
> based upon message-id" so having interface to this script would be
> useful. Further the mail client may be
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
> Move/Load/Store without flag is no problem. But for add, to allow
> multiword add, carry is needed and I can't make it optionnal.
As I hinted, perhaps you can have the multiword carry a separate
one from the flags carry, perhaps moved over with a separa
On Wed, 15 Feb 2006, DJ Delorie wrote:
I wrote:
> > Anyway, at least keep a way to add reg+reg and reg+integer, load and
> > store of memory and load of integer and address without condition
> > code effects and your port has a chance to avoid the related bloat.
>
> At least, move/load/store shou
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote:
> Unless I'm delirious (it's way past bedtime) I see a m32c port
> and it's cc0-free. Is there a problem?
I see, in the code in svn trunk the compares aren't optimized
away yet. You must be having a lot of fun right now. ;-)
brgds, H-P
On Wed, 15 Feb 2006, DJ Delorie wrote:
> I hope I can stick with my cmp/jmp model and manage them myself still,
> though, because there's a LOT of patterns in m32c where the set of
> flags affected depends on which alternative you select, and most
> patterns affect the flags in some (usually nonort
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote:
> FWIW, I use
> peephole2s and condition code modes in CRIS w.i.p.
...and cbranch (cc setter + user in one combined insn) which
are split after reload.
brgds, H-P
On Wed, 15 Feb 2006, DJ Delorie wrote:
> > BTW, carry-out from shifts is very rarely used in compiled code.)
> Unless you've expanded SI shifts into a pair of HI shifts.
>
> > Besides what DJ said about performance (both pros and cons
> > there), the problem is as I said with port complexity, becau
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
> What I was thinking for the moment was to have :
> - sign is always the msb of the last ALU output
> - add/sub to modify all flags
> - move/xor/and/not/or only affect zero (and sign)
> - shift operations always affect carry and zero
> - Have some sp
On Wed, 15 Feb 2006, Sylvain Munaut wrote:
> * 2 flags Carry & Zero for testing.
I think most of your questions have been answered, so let me
just add that if nothing else, the port will be much simplified
if you make sure that only specific compare instructions set
condition codes, i.e. not
On Sun, 12 Feb 2006, David Fang wrote:
> > > And now: How do you actually find the PRs? I seem to wrongly use
> > > Bugzilla's search engine. I submitted "int_mode_for_mode" into the
> > > "Enter a bug # or some search terms" box of
> > > http://gcc.gnu.org/bugzilla/ , which didn't find anything.
On Tue, 24 Jan 2006, Eric Fisher wrote:
> ld: cannot find -lm
> collect2: ld returned 1 exit status
> How can I get it?
Port newlib. It's simple enough.
brgds, H-P
On Mon, 16 Jan 2006, DJ Delorie wrote:
> Two copies of gcc, both configured for the same target and built from
> the same sources, should produce identical objects regardless of how
> they are built or what they run on.
For the record, this unfortunately isn't so, at least wasn't
weeks ago, compar
On Thu, 19 Jan 2006, Paolo Bonzini wrote:
> > (define_insn ""
...
> > "%C1f\\t%2,%3"
> > I don't know the meaning of the
> > numeric character "1" between "%C" and "f" in the output template.
>
> It means that operand 1 (the signed_comparison_operator) is passed to
> the dlx.c routine. Likewis
On Wed, 28 Dec 2005, Liu Haibin wrote:
(I'm this far ^ behind on reading mailing lists.)
It's likely that you have since long noticed, but in case not:
> I got a dump of sha.c.27.flow2 from gcc 3.4.1. I don't quite
> understand the LOG_LINKS of insn 498. LOG_LINKS in insn 498 shows that
> it has
On Mon, 2 Jan 2006, Ian Lance Taylor wrote:
> When did the bogus split
> happen?
Sorry, I didn't answer this question and now the gdb session is
gone. Hopefully the answer isn't that important given RTH's
comment? I'd guess reorg.
brgds, H-P
On Mon, 2 Jan 2006, Ian Lance Taylor wrote:
> I wouldn't expect to see any insns with RTX_FRAME_RELATED_P set before
> the prologue and epilogue are threaded in the flow2 pass. So combine
> shouldn't be an issue. And flow2 calls split_all_insns before the
> prologue and epilogue insns are threade
On Mon, 19 Dec 2005, Richard Henderson wrote:
> I think that this is all complicated enough that we should
> simply deny peepholing insns with RTX_FRAME_RELATED_P set.
I was just bitten by the same behavior for define_split.
Should the same go for define_splits and maybe also as a guard
test for c
> Date: Tue, 20 Dec 2005 12:34:30 +0100
> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
> I want it done there *only* because that's what it does for the
> similar but even more complex cc0 code and because combine does
> multi-insn simplifications in general.
Ne
> Date: Tue, 20 Dec 2005 11:13:06 +0100 (CET)
> From: Steven Bosscher <[EMAIL PROTECTED]>
> You really have to wonder if cleaning up this jump is a job combine
> should be doing.
I want it done there *only* because that's what it does for the
similar but even more complex cc0 code and because com
I'd like for combine to perform the following simplification:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228
(parallel [
(set (reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ])))
(clobber (reg:CC 19 dccr))
]) 158 {abssi2} (in
On Sat, 17 Dec 2005, Daniel Jacobowitz wrote:
> On Sun, Dec 18, 2005 at 02:10:36AM +0100, Gerald Pfeifer wrote:
> > I agree with that and plan to do so next week, once the server hosting
> > my GCC trees is online again.
>
> Before you go ahead with that, please check with overseers@; they
> (Frank
On Tue, 13 Dec 2005, DJ Delorie wrote:
> > Summary of the thread: it's known about and may never be fixed, but
> > alternative searchable archives exist (gmane, nabble, probably
> > others like marc and mail-archive too).
>
> Could we put in a google search box on the archive pages at least, to
> s
> Date: Mon, 12 Dec 2005 08:35:41 +0100
> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
> ... the JUMP_LABEL field in a JUMP_P ...
Almost-consistent typo: s/JUMP_LABEL/JUMP_TARGET/g to hopefully
make a little bit more sense of it all. (Attempting a
brain-dump before shuteyes
For once, the documentation seems to be most accurate; more
accurate than random comments in the code, of which some
contradicts other code:
@item REG_LABEL
This insn uses @var{op}, a @code{code_label} or a @code{note} of type
@code{NOTE_INSN_DELETED_LABEL}, but is not a
@code{jump_insn}, or it is
On Thu, 8 Dec 2005, Paul Martinolich wrote:
> I have noticed that when I search the mailing lists the earliest
> messages
> are from May 2005. I don't see anything before that.
>
> http://gcc.gnu.org/ml/gcc/
>
> Search 'fortran' which shows the first message is:
>
> http://gcc.gnu.org/ml/gcc/2005-
> Date: Wed, 07 Dec 2005 09:18:53 +0100
> From: "Jan Beulich" <[EMAIL PROTECTED]>
Just for the record (in case someone else has the same thoughts)
and because I'd already written most of the reply, I also
replied to your first email. See last for your follow-up.
> What has the alignment of type
> Date: Tue, 06 Dec 2005 18:02:51 +0100
> From: "Jan Beulich" <[EMAIL PROTECTED]>
> >2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]>
> >
> > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c,
> > gcc.dg/pr17112-1.c, g+
On Mon, 28 Nov 2005, Mark Mitchell wrote:
> So, we're considering doing what it takes to get ieeelib.c into GCC, or,
> perhaps, borrowing some of its ideas for fp-bit.c.
Very nice! Don't forget the few posts with bug-fixes over the
years from someone or other. (Yes, actually posted here on a
gcc
On Tue, 29 Nov 2005, Mike Stump wrote:
> > What field order looks better to you? I'm agnostic, except I'd
> > like to keep one and the same field delimiter except for the
> > result, and it's *slightly* easier to keep it as "," (as in the
> > original csibe output).
>
> 4.1-sparc-r104567/my-perf-s
On Tue, 29 Nov 2005, Mike Stump wrote:
> On Nov 28, 2005, at 8:41 PM, Hans-Peter Nilsson wrote:
> > runtime,-O1,zlib-1.1.4:minigzip,previous 0.32
>
> Ah, ok, good. I'd eject the ,previous to the filename, and reorder
> slightly, but, certainly that is trivial to do.
Um,
On Mon, 28 Nov 2005, Hans-Peter Nilsson wrote:
> I've attached the work-in-progress
If someone's missing the trivial sim-main-glue.c, here it is,
just for completeness. Not used for "native" testing.
brgds, H-P/* Glue for passing arguments to a simulator that can
On Mon, 28 Nov 2005, Mike Stump wrote:
> On Nov 28, 2005, at 6:21 PM, Hans-Peter Nilsson wrote:
> > I've attached the work-in-progress so I don't have to get into
> > detail about what it does :-) except noting that you'll see in
> > gcc.sum something like:
On Mon, 28 Nov 2005, Jim Wilson wrote:
> The DWARF2 unwind info method has little or no overhead until a
> exception is thrown. This is the preferred method for most targets. In
> this scheme, we read the DWARF2 unwind info from the executable when an
> exception is throw, parse the unwind tables
On Sun, 20 Nov 2005, Andreas Schwab wrote:
> Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
> > On Sat, 19 Nov 2005, Steve Kargl wrote:
> >> On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
> >> I believe if the file is in a cvs repository and the cop
On Sat, 19 Nov 2005, Steve Kargl wrote:
> On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
> I believe if the file is in a cvs repository and the copy
> in your local tree was not obtained via a checkout, cvs
> will replace the local file with whatever is in the repository.
No, it'll co
> From: Paul Brook <[EMAIL PROTECTED]>
> Date: Thu, 17 Nov 2005 15:12:50 +
> > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> >
> >(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
> >(nil))
> > ../../../gcc-head-test/lib
On Fri, 11 Nov 2005, Adrian Prantl wrote:
> Hello everybody,
>
> I am currently working on creating a new gcc backend for a word-addressable
> machine with 24-Bit general purpose registers.
If the smallest unit you can address, the one between
address N and N+1, is a "word" then the unit must be a
On Thu, 10 Nov 2005 [EMAIL PROTECTED] wrote:
> Author: dberlin
> Date: Thu Nov 10 17:23:49 2005
> New Revision: 106743
> 2005-11-10 Daniel Berlin <[EMAIL PROTECTED]>
> (heapvar_lookup): New function.
/home/hp/combined/combined/gcc/tree-ssa-structalias.c: In function
`heapvar_lookup':
/
On Mon, 7 Nov 2005, Steven Bosscher wrote:
> 2) when we see :0 align to the next unit, which seems to be the
>behavior of GCC pre-3.4.
If by "unit" you mean "size of type for the :0 field" for
targets with PCC_BITFIELD_TYPE_MATTERS==1, and "byte" for
non-PCC_BITFIELD_TYPE_MATTERS targets, fin
On Tue, 9 Aug 2005, Sebastian Pop wrote:
> Laurent GUERBY wrote:
> >
> > So I'm asking for project proposals, that is to say people that think
> > that their volunteer time to work on these old machine (scripts,
> > compiling, ... under the limit of minimal external bandwidth use) is of
> > some si
After synchronizing with Ian Lance Taylor on IRC, I'm in the
process of implementing the cc0 replacement machinery he
described here and found at
http://gcc.gnu.org/wiki/general%20backend%20cleanup> after
"Here is a possible approach in which macros are used in the MD
file readers to avoid the patt
On Sat, 23 Apr 2005, Hans-Peter Nilsson wrote:
> On Wed, 6 Apr 2005, Joseph S. Myers wrote:
> > (If test results for a port are so bad that
> > though sent to gcc-testresults they exceed the message size limit, and
> > this remains the case for a prolonged period s
On Wed, 6 Apr 2005, Joseph S. Myers wrote:
> (If test results for a port are so bad that
> though sent to gcc-testresults they exceed the message size limit, and
> this remains the case for a prolonged period such as ever since 4.0
> branched, that also indicates lack of active maintenance.)
No, i
> From: Ian Lance Taylor
> Date: 29 Mar 2005 23:05:11 -0500
> Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
> What am I missing?
If anything, to post an updated proposal spelling out the bits
below!
(I.e. nothing as long as there is always a matching
automatically generated
I'm behind on reading mailing lists and only "skipped ahead" for
this thread. (I may have missed some related follow-ups.)
> From: Ian Lance Taylor
> Date: 24 Mar 2005 11:44:52 -0500
> 1) Modify the programs which read the .md file to look for an
>attribute named clobbercc. If such an attr
On Sun, 13 Mar 2005, Øyvind Harboe wrote:
> Trampolines are strange things... :-)
> - AFAICT, the cris target is saving the value of the
> static chain register in the trampoline. How can that work
> with recursive functions?
What's wrong with that?
Do I miss something fundamental?
> Does t
On cris-axis-elf, with LAST_UPDATED "Wed Mar 16 14:54:19 UTC 2005":
make[9]: Entering directory
`/home/hp/combined/cris-sim/cris-elf/v10/newlib/libc/ctype'
/home/hp/combined/cris-sim/./gcc/xgcc -B/home/hp/combined/cris-sim/./gcc/
-nostdinc -B/home/hp/combined/cris-sim/cris-elf/v10/new\
lib/ -isy
On Mon, 7 Mar 2005, Zack Weinberg wrote:
> I would take this approach if there were a sensible way to deal with
> the generated sources.
(Late in the game here, but I see no solution in later posts in
this thread.)
All #includes that can appear are in the gen* files IIUC.
Can those be marked up,
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Fri, 11 Mar 2005 17:52:03 -0800
> On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> > I don't really understand what you mean: if a thing is called
> > "foo" in the source, then -fglobalize-symb
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Thu, 10 Mar 2005 21:51:12 -0800
> On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote:
> > That question isn't applicable or maybe I should say "by
> > identity mapping". To wit, SYMNAME refers to wh
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Thu, 10 Mar 2005 19:34:01 -0800
> On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > Of course! The simple (and best) way out is to define what
> > happens in all those situations as the equivalent of removi
> Date: Thu, 10 Mar 2005 17:36:37 -0800
> On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote:
> > But that requires source-level instrumentation.
>
> Isn't a compiler option -fglobalize-symbol also a form of source-level
> instrumentation? Either way, you ne
> Date: Thu, 10 Mar 2005 14:41:23 -0800
> From: James E Wilson <[EMAIL PROTECTED]>
> Fredrik Hugosson wrote:
> > My proposal is the following new options:
> > -fglobalize-symbol=SYMBOLNAME
> > -fglobalize-symbols=FILENAME
> > -fglobalize-all-symbols
>
> It is unlikely someone will volunteer to im
On Sun, 6 Mar 2005, Ian Lance Taylor wrote:
> Going forward, in early July of each year ChangeLog would be moved
> into ChangeLog-. Then in early January, ChangeLog would be moved
> to the front of ChangeLog-.
More natural would be to split off ChangeLog entries for the
previous year earl
On Tue, 1 Mar 2005, Peter Barada wrote:
>
> I'm trying to improve atomic operations for ColdFir ein a 2.4 kernel, and
> I tried the following following the current online manual at:
> http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Extended-Asm.html#Extended-Asm
>
> static __inline__ void atomic_inc(at
On Mon, 28 Feb 2005, Dave Korn wrote:
> Hmmm, actually, I would say that moving these macro definitions into the
> cpu.c files is a fairly mechanical and trivial transformation. Given:
WRONG!
> ${CPU}.h:
> #define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
> if ( some very hairy conditiona
> Date: Mon, 21 Feb 2005 11:19:59 +0100
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > Do you know of a reason why that isn't on by default?
>
> Because -fdump-rtl-expand-detailed includes *two* copies of the RTL: one
> lacks the prologue and epilogue but is interleaved with trees, the other
> i
On Wed, 9 Feb 2005, James E Wilson wrote:
> A workaround would be to add a special unspec RTL pattern that emits the
> bgeu/break/label. Then you would no longer have control-flow inside the
> prologue. You can use the gas local label feature to avoid needing to
> create a label rtx.
Or (for the
201 - 263 of 263 matches
Mail list logo
