> Date: Fri, 16 Feb 2007 18:26:10 +0100
> From: Steven Bosscher <[EMAIL PROTECTED]>
> I have tested a small patch on i686, x86_64, ia64, mips, and sh:
> Index: loop-unroll.c
> ===
> --- loop-unroll.c (revision 122011)
> +++ loop
On Wed, 14 Mar 2007, Joe Buck wrote:
> If we allow XFAILing tests that ICE, it should be an extremely rare thing.
> I worry that once the precedent is set, the number of XFAIL ICEs will
> go up with time, making it more likely that users will experience
> compiler crashes.
What's so bad about an I
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
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 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
> 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
> 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
> 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
> 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: 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
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,
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 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
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
> 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
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
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
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 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
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 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 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
> 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 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
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 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 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, 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 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 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 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
> 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+
> 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
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-
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
> 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
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
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
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
> 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
> 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
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
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, 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 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 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
TL;DR: See subject. Verbosity follows.
The git transition is mostly for the better. Thanks to those
investing time and effort. There's always fallout. Here's one
dustcloud:
In the distant past with svn, there messages to gcc-cvs@ were
somewhat like git show --stat, i.e. without the actual cha
On Thu, 6 Feb 2020, Segher Boessenkool wrote:
> Instead of "git am" I had "patch -p1 <",
May I suggest "git apply" instead of the good old patch program.
(The "-p1" is of course built-in and you never have to do a
manual roll-back or separate --dry-run pass.)
brgds, H-P
On Sat, 25 Apr 2020, Eric Botcazou wrote:
> > I very much disagree with this. I think my approach was possibly the
> > only viable one, and definitely the most sensible one for this target.
> > Not only is there nothing meaningful to be gained from separating cc
> > setters and users on m68k given
On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> As you can deduce from the (set_attr "cc" ..), only constraint
> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.
Yes, I recognize that.
> My first version of the port adds a post-reload splitter that adds a
> (clobber (
On Sun, 16 Aug 2020, Pip Cet via Gcc wrote:
> For example, here's what I currently have:
>
> (define_expand "mov"
> [(parallel [(set (match_operand:MOVMODE 0 "nonimmediate_operand" "")
>(match_operand:MOVMODE 1 "general_operand" ""))
> (clobber (reg:CC REG_CC))])]
> ...)
On Wed, 19 Aug 2020, Senthil Kumar Selvaraj wrote:
>
> Hans-Peter Nilsson writes:
>
> > On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> >> As you can deduce from the (set_attr "cc" ..), only constraint
> >> alternatives 0,2,3 and 6 clobber
On Thu, 20 Aug 2020, Senthil Kumar Selvaraj wrote:
> What I didn't understand was the (set-attr "cc")
> part - as far I can tell, this results in (set_attr "cc_enabled" ...) in
> all of the three substituted patterns, so I wondered why not just have
> (set_attr "cc_enabled" ...) in the original de
On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > The post-reload splitter introduces the clobber. The wiki
> > suggests that approach if most insns clobber REG_CC, perhaps because of
> > the missed optimizations you describe
On Wed, 26 Aug 2020, Jeff Law wrote:
> On Tue, 2020-08-25 at 23:58 -0400, Hans-Peter Nilsson wrote:
> > On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> > > On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > > > The post-reload splitter in
On Wed, 26 Aug 2020, Pip Cet via Gcc wrote:
> Note that whether there is a CC-setting variant depends not just on
> the "cc" attr, but also on the precise operands for some values of the
> "cc" attr, which requires hairy C code to figure out.
>
> Is it possible to avoid this situation by avoiding
On Thu, 27 Aug 2020, Pip Cet via Gcc wrote:
> I may be missing an obvious workaround, but it seems we currently emit
> a #line directive when including lines from machine description files
> in C files, but never emit a second directive when switching back to
> the generated C file. This makes step
On Thu, 3 Sep 2020, Hans-Peter Nilsson wrote:
> IMHO stepping into the .md really isn't helpful. Even a pattern
> name in a comment in the generated code would be better.
...and JFTR, yes I noticed there is, or rather line indicator
for example /path/to/mmix.md:211 above gen_add
On Wed, 23 Sep 2020, Ilya Leoshkevich via Gcc wrote:
> Hi,
>
> "Defining How to Split Instructions" in gccint states the following:
>
> The preparation-statements are similar to those statements that are
> specified for define_expand ... Unlike those in define_expand, however,
> these statements mu
On Fri, 20 Nov 2015, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm
> within functions.
We've explictly promised (directed to kernel people IIRC) that
the empty basic asm; 'asm ("")', has forward-compatible
outlining magic, so people would not
On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > On Fri, 20 Nov 2015, Richard Henderson wrote:
> > > I'd be perfectly happy to deprecate and later completely remove basic asm
> > > within fu
On Thu, 26 Nov 2015, David Wohlferd wrote:
> On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote:
> > On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> > > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > > > @item noinline
...
> > > > a
On Fri, 12 Aug 2016, Thorsten Glaser wrote:
> Dixi quod?
>
> >Alexander Monakov dixit:
> >
> >>First of all, I think option -malign-data=abi (new in GCC 5) addresses your
> >>need: it can be used to reduce the default (excessive) alignment to just the
> >>psABI-dictated value (you can play with thi
On Fri, 12 Aug 2016, Thorsten Glaser wrote:
> Hans-Peter Nilsson dixit:
>
> >> ? except -malign-data=abi is, apparently, cris-only.
>
> >ITYM "i386-only". I see "malign-data=" in
> >gcc/config/i386/i386.opt.
>
> No (actually tested on am
On Tue, 1 Jul 2014, Jonathan Wakely wrote:
> On 1 July 2014 20:58, John David Anglin wrote:
> > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
> >
> >> On 1 July 2014 09:40, Matthias Klose wrote:
> >>>
> >>> - HPPA (build log [2]), is missing all the future_base symbols and
> >>> exception_ptr1
On Mon, 21 Jul 2014, David Wohlferd wrote:
> I have been looking at asm_fprintf in final.c, and I think there's a design
> flaw. But since the change affects ARM and since I have no access to an ARM
> system, I need a second opinion.
There's this thing called cross-compilation, which happens for
On Mon, 8 Sep 2014, Pierre-Marie de Rodat wrote:
> # Get newlib and the simulator
> cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim
> # Get binutils
> git clone git://sourceware.org/git/binutils-gdb.git
>
> # Create the combined tree
> rm -rf combined
> mkd
On Thu, 2 Oct 2014, David Wohlferd wrote:
> > You want
> >
> > "=m" (*( struct foo { char x[8]; } __attribute__((may_alias)) *)Dest)
>
> Thank you. With your help, that worse-than-useless sample in the docs
> is getting closer to something people can actually use.
Thank *you* for your investigat
On Thu, 13 Nov 2014, David Wohlferd wrote:
> Sorry for the (very) delayed response. I'm still looking for feedback here so
> I can fix the docs.
Thank you for your diligence.
> As I said before, triggering a full memory clobber for anything over 16 bytes
> (and most sizes under 16 bytes) makes t
On Thu, 8 Jan 2015, Andrew Haley wrote:
> Android native GCC can't support LTO because of a lack of support for
> dlopen() in the C library. How should we patch the configury to disable
> LTO by default?
Doesn't setting unsupported_languages in toplevel configure.ac
work for you?
brgds, H-P
On Fri, 6 Feb 2015, Andrew Haley wrote:
> On 06/02/15 08:00, Hans-Peter Nilsson wrote:
> > On Thu, 8 Jan 2015, Andrew Haley wrote:
> >> Android native GCC can't support LTO because of a lack of support for
> >> dlopen() in the C library. How should we patch the
On Wed, 8 Apr 2015, Gerald Pfeifer wrote:
> On Sun, 30 Dec 2012, Cynthia Rempel wrote:
> > I was looking at http://gcc.gnu.org/simtest-howto.html and was wondering
> > if the bottom of the page could be modified from links to tests ran in
> > 2003 to a link to testresults with a search for sim, lik
On Thu, 23 Apr 2015, Bin.Cheng wrote:
> Hi,
> In libstdc++ testsuite, I noticed that macro _GLIBCXX_RES_LIMITS is
> checked/set by GLIBCXX_CHECK_SETRLIMIT, which is further guarded by
> GLIBCXX_IS_NATIVE as below:
>
> AC_DEFUN([GLIBCXX_CONFIGURE_TESTSUITE], [
> if $GLIBCXX_IS_NATIVE ; then
>
Has there been a change of policy so it's a valid option to use
gcc/ChangeLog for testsuite changes? I was about to move a
semi-randomly spotted misplaced entry, and when checking if
there were others, I noticed that there's like tens of them, so
I thought better ask.
(IMHO it's confusing to have
On Tue, 10 Oct 2017, Paulo Matos wrote:
> This is a suggestion. I am keen to have corrections from people who use
> this on a daily basis and/or have a better understanding of each status.
Not mentioning them (oddly I don't see anyone mentioning them)
makes me think you've not looked there so all
There's no address-sanitizer support for MIPS (in particular for
O32) on trunk, at least not when building for
mipsisa32r2el-linux-gnu and libsanitizer/configure.tgt seems
to support that observation. There's a set of patches "floating
around", but the last sign of work-in-progress was more than
f
> From: Jean Lee
> Date: Fri, 2 Mar 2018 13:29:39 +0800
> 2018-03-02 7:53 GMT+08:00 Hans-Peter Nilsson :
>
> > There's no address-sanitizer support for MIPS (in particular for
> > O32) on trunk, at least not when building for
> > mipsisa32r2el-linux-gnu a
TL;DR: see last sentence.
> From: Jean Lee
> Date: Mon, 5 Mar 2018 19:56:59 +0800
> 2018-03-03 21:14 GMT+08:00 Hans-Peter Nilsson :
>
> > > From: Jean Lee
> > > Date: Fri, 2 Mar 2018 13:29:39 +0800
> > > It is great to go the last mile. I had done the
H.J.: please see last.
> From: Jean Lee
> Date: Sat, 10 Mar 2018 20:22:45 +0800
> > See above regarding looking at patches, but I guess you mean
> > that the patch is trivial, so then I presume it was more or less
> > the same as this, which is basically a copy-paste from looking
> > at rs6000 a
On Thu, 27 Jan 2011, Laurynas Biveinis wrote:
> Thus I propose to separate the two. To avoid introducing another
> --enable-checking option, let's move the annotations to the "misc"
> checking and also enable "misc" too if "valgrind" is requested. Both
> these options are disabled for releases, so
On Fri, 28 Jan 2011, Joel Sherrill wrote:
> This almost works but libstdc++-v3/configure.ac explicitly
> checks $with_newlib to trip some AC_DEFINE's which have
> to be tripped to build. I have a patch attached that logically
> says if on target X, then you are always using newlib so
> if you have
On Fri, 28 Jan 2011, Jean-Marc Saffroy wrote:
> (define_constraint "I"
> "Signed 6-bit integer constant for binops."
> (and (match_code "const_int")
>(match_test "IN_RANGE (ival, -24, 32)")))
>
> (define_register_constraint "A" "ADDR_REGS"
> "The address registers.")
>
> (define_regis
> Date: Thu, 10 Mar 2011 17:55:38 +0100
> From: Paolo Bonzini
> On 03/10/2011 04:47 PM, Nathan Froyd wrote:
> > [moving to gcc@ to get input from a wider audience]
> >
> > On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
> >>> From: Nat
> From: Eric Botcazou
> Date: Thu, 10 Mar 2011 18:42:14 +0100
> SPARC had exactly the same pattern as the 'U' constraint of MMIX. It now
> uses
> reload_in_progress || reload_completed instead (in memory_ok_for_ldd).
Nathan suggested that; great confirmation! Thanks.
brgds, H-P
On Tue, 15 Feb 2011, DJ Delorie wrote:
>
> pr45055 tests a scheduling fix, but on targets that don't support
> scheduling (like m32c-elf), gcc emits a warning that scheduling is not
> supported. This warning causes the test to fail. How do we bypass
> these types of test cases? I don't see a sui
> Date: Tue, 22 Mar 2011 19:51:38 + (UTC)
> From: "Joseph S. Myers"
> Why do a great many targets disable libgcj by default in the toplevel
> configure.ac?
Maybe because the right way, through unsupported_languages,
never caught on and there never was a global conversion? :-)
> Where GCC p
On Tue, 22 Mar 2011, Joseph S. Myers wrote:
> On Tue, 22 Mar 2011, Hans-Peter Nilsson wrote:
> > For MMIX, the issues I mentioned at
> > <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00572.html> are
> > presumably fixed, but pragmatically the interest level for
>
&
On Thu, 19 May 2011, Richard Sandiford wrote:
> Maybe it would be worth breaking with tradition and making
> -fno-delayed-branch imply -Wa,-O0 though. Back in the day,
> the assembler's version of delayed-branch filling was applied
> to pretty much every function, so the separation was probably
>
On Mon, 1 Aug 2011, Georg-Johann Lay wrote:
> Michael Walle schrieb:
> > Hi list,
> >
> > consider the following test code:
> > static void inline f1(int arg)
> > {
> >register int a1 asm("r8") = 10;
> >register int a2 asm("r1") = arg;
> >
> >asm("scall" : : "r"(a1), "r"(a2));
> > }
On Mon, 1 Aug 2011, Richard Henderson wrote:
> On 08/01/2011 01:30 PM, Michael Walle wrote:
> > 1) function inlining
> > 2) deferred argument evaluation
> > 3) because our target has no barrel shifter, (arg >> 10) is emitted as a
> > function call to libgcc's __ashrsi3 (_in place_!)
> > 4) BAM
On Tue, 2 Aug 2011, Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
> > Michael Walle writes:
> > >
> > > Hi,
> > >
> > > > To confirm that try -fno-tree-ter.
> > >
> > > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> > > assem
On Tue, 2 Aug 2011, Richard Guenther wrote:
> > I'd be ok with that, FWIW; I see the problem with keeping the
> > scheduling of operations in a working order (yuck) and I don't
> > see how else to keep it working ...except perhaps make gcc flag
> > functions with register asms as non-inlinable, may
On Wed, 3 Aug 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
> > asm ("scall" : : "asm("r0")" (10), ...)
> Maybe it would be possible to implement this while keeping the syntax
> of existing code by (re-)defining the semantics of register asm to
> basically say that:
>
> If a variable X is
On Thu, 4 Aug 2011, Andreas Schwab wrote:
> Hans-Peter Nilsson writes:
>
> > To make sure, it'd be nice if someone could perhaps grep an
> > entire GNU/Linux-or-other distribution including the kernel for
> > uses of asm-declared *local* registers that don't d
On Tue, 9 Aug 2011, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>
> > Better still would be to change the specification and implementation of
> > local register variables to only guarantee them at the beginning of ASM
> > statements. At other times they are simply the same as other local
> > v
On Tue, 9 Aug 2011, Richard Earnshaw wrote:
> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements.
Only for those asm statements taking the same asm-register
variables as arguments.
> At ot
On Fri, 12 Aug 2011, Rohit Arul Raj wrote:
> On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj
> wrote:
> > Hello All,
> >
> > I am working on 32-bit target with gcc 4.6.0. I need some help on the
> > following:
> >
> > For my target, If my CCR register is set, all the arithmetic
> > instructions
On Fri, 12 Aug 2011, Hans-Peter Nilsson wrote:
> On Fri, 12 Aug 2011, Rohit Arul Raj wrote:
> Assuming that you can indeed emit reasonable code for compares
> and conditional branches without the "CCR register" set to the
> do-not-update state, I'd suggest you im
On Wed, 17 Aug 2011, Rohit Arul Raj wrote:
> On Sat, Aug 13, 2011 at 5:20 AM, Hans-Peter Nilsson wrote:
> >> On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj
> >> wrote:
> >> > Setting the CCR register is done by a built-in function.
> >
> > Wh
On Wed, 17 Aug 2011, Richard Sandiford wrote:
> It also means
> that constants that are slightly more expensive than a register --
> somewhere in the range [0, COSTS_N_INSNS (1)] -- end up seeming
> cheaper than registers.
Yes, perhaps some scale factor has to be applied to get
reasonable cost gr
1 - 100 of 263 matches
Mail list logo