doloop_end .
2023-10-05 Joern Rennecke
gcc/
* doc/md.texi (doloop_end): Document oprional operand 2.
* loop-doloop.cc (doloop_optimize): Provide 3rd operand to
gen_doloop_end.
* target-insns.def (doloop_end): Add optional 3rd operand.
diff -
> Making operand 0 read/write in define_insn_and_split prevents the web pass
> from creating a new pseudo
> for the clobber, avoiding the whole problem.
That is the right solution. If you clobber a match_dup of an input
operand, that makes it and input-and-output operand, so you should
mark it a
I think it would make sense to leave the exact vector layout, like
vlen and lmul, to the caller.
Attached is an attempt to implement sin and cos vectorized so it
allows lmul values of m1 and m2, while using no more than a quarter of
the vector registers.
The function could live in libgcc and be use
I haven't worked with these targets in years and can't really do sensible
maintenance or reviews of patches for them.
I am currently working on optimizations for other ports like RISC-V.
ARC has still an active maintainer in Claudiu Zissulescu, so is basically
unaffected.
I am not aware of any o
On 2 February 2015 at 21:54, Paul Shortis wrote:
> I could have avoided the expander and used a single instruction pattern for
> a)b)c) if if could have found a way to have alternative dependent clobbers
> in an instruction pattern. I investigated attributes but couldn't see how I
> would be able
On 23 January 2015 at 13:46, Andrew Stubbs wrote:
> How does reload ensure that an SImode value (re)loaded into an FP register
> has a valid stack index?
You could use CANNOT_CHANGE_MODE_CLASS, or request secondary reload.
For the latter, you can look at the memory/pseudo to decide if the
address
On 14 January 2015 at 18:03, vgol...@innovasic.de wrote:
> Hello out there,
>
> I am looking of some support maintaining the m68k target toolchain (incl GDB)
> for the fido1100 (basically a CPU32, the real changes are in GDB). Some
> experience with the m68k target would be helpful.
> Is there s
On 26 November 2014 at 16:48, Mathias Roslund wrote:
> Since then I've added more instructions and gotten to the point where most
> stuff seems to be working. My current issue is that signed divide and all
> shift operations insists on sign/zero extending the operands, resulting in
> 32bit operati
On 24 November 2014 at 10:58, Martin Jambor wrote:
> On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote:
>> Hi,
>>
>> I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and
>> gcc-4_8-branch for which I need the requisite legal paperwork.
>>
>> However, I'd like t
On 11 November 2014 16:22, Joey Ye wrote:
> Markus,
>
> -mmcu probably will not work for ARM architectured MCUs. Reason are
> * Confusion. -mcpu is encouraged and already widely used for ARM
> architectures. Introducing -mmcu will be very confusing.
It' just a matter of bundling specifications.
On 9 November 2014 23:13, Sandra Loosemore wrote:
> Forgive me if this has been raised before -- I tried searching the archives
> but couldn't think of good keywords that would weed out unrelated posts
>
> I was checking the testing requirements for a C front end patch
>
> https://gcc.gnu.org/
On 3 November 2014 21:51, David Kang wrote:
>
> Thank you for the tips.
> I tried the following condition for split.
>
> "reload_completed && FP_REG_P (operands[0])"
>
> But, the registers are still changed.
> How can I specify "after register allocation" in the split condition?
Are you sure t
On 24 October 2014 09:06, Thomas Preud'homme wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>> Behalf Of Joseph S. Myers
>>
>> I'm not clear if you're proposing such a patch for review, but note:
>
> Yep but not yet for inclusion as I'm waiting to see if this would suit th
In __do_global_dtors, I ended up changing the order of execution
in order to get back to the forwards/backwards order as found in
crtstuff.c
The patch I attached to target/63223 is actually an extract from this patch.
gcc:
2014-08-29 Joern Rennecke
Vidya Praveen
On 18 August 2014 11:35, Joey Ye wrote:
> Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html,
> which is already in newlib mainline. I think it solves the same issue
> in a slight different approach.
>
> Does it work for you?
No, this is completely besides the point. avr-libc ha
On 2 September 2014 16:28, Joseph S. Myers wrote:
> On Tue, 2 Sep 2014, Joey Ye wrote:
>
>> Apparently newlib is not following this specification very well, as
>> there are symbols like _abc_r defined every where in current newlib. I
>> am not implying the spec should not be followed, but is newli
On 2 September 2014 11:01, Jakub Jelinek wrote:
> On Tue, Sep 02, 2014 at 11:49:33AM +0200, Andreas Schwab wrote:
>> Richard Biener writes:
>>
>> > On Tue, Sep 2, 2014 at 8:15 AM, Uros Bizjak wrote:
>> >> Hello!
>> >>
>> >>> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are
On 28 August 2014 06:30, Thomas Preud'homme wrote:
>> Yes. I'll have to adjust the avr hook that it'll leave the v*printf /
>> v*scanf functions
>> alone - at least by default / for ISO C behaviour - but it'll give me
>> an easy way
>> to add a switch to tweak the behaviour.
>>
>> Or maybe we ca
On 27 August 2014 11:41, Thomas Preud'homme wrote:
>> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
>> Sent: Wednesday, August 27, 2014 6:13 PM
>>
>> I don't see how it can be any other way. We want to be able to compile
>> translation units in
On 27 August 2014 08:02, Thomas Preud'homme wrote:
>> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
>> Sent: Tuesday, August 26, 2014 6:44 PM
>>
>> Due to the library order defined in the specs, the float-enbled printf
>> definition will
>> b
On 26 August 2014 07:48, Thomas Preud'homme wrote:
> What happens in the case that a program contains both some printf and
> __int_printf call?
Due to the library order defined in the specs, the float-enbled printf
definition will
be picked up from libprintf_flt.a .
> I didn't do extensive yet
For embedded targets with small memories and static linking, the size of
functions like *printf and their dependencies is painful, particularily for
targets that need software floating point.
avr-libc has long had a printf / scanf implementation that by default does not
include floating point supp
On 6 August 2014 11:31, Richard Biener wrote:
> Ok, so the problematical case is
>
> struct X { std::string s; };
> void foo (X&);
Wouldn't it be even more troublesome with an application that dynloads
dsos depending on user input.
The install script might check if the dso with the right soname i
On 29 July 2014 19:29, Joern Rennecke wrote:
> E.g. A GCC release on the 1st April 2015 at 09:00 UTC is made
> 90 days and 9 hours after the start of the year, and should thus carry
> the version number 2015.24760274
P.S.: a patchlevel release in a subsequent year can be marked by i
On 29 July 2014 18:30, Markus Trippelsdorf wrote:
> Since gcc is released annually, why not tie the version to the year of
> the release, instead of choosing an arbitrary number?
>
> 15.o
What did the Romans every do for us? Release GCC XV, obviously...
Unfortunately, they couldn't release *.0 v
On 29 July 2014 18:14, Richard Biener wrote:
> On July 29, 2014 6:45:13 PM CEST, Eric Botcazou
> wrote:
>>> I think that if anybody has strong objections, now is the time to
>>make
>>> them. Otherwise I think we should go with this plan.
>>
>>IMHO the cure is worse than the disease.
>>
>>> Give
On 2 July 2014 08:02, Marc Glisse wrote:
> On Wed, 2 Jul 2014, Tom de Vries wrote:
>
>> On 02-07-14 08:23, Marc Glisse wrote:
>>>
>>> I think it could have used (match_dup 0) instead of operand 1, if there
>>> had been only the first alternative. And then the constraint would have been
>>> +&.
>>
On 21 May 2014 14:13, Sheheryar Zahoor Qazi
wrote:
>>>Building libgcc is not optional. It is required for all targets.
>
> So, irrespective whether i provide floating point implementation by
> soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST?
>
> What if I dont want to generate c
On 30 April 2014 12:20, Richard Biener wrote:
> the delay-slot code is fragile, you probably simply run into a bug.
In particular, we lack in-tree ports with multiple delay slots, so while the
support exists theoretically, it is not tested and maintained in any
meaningful way.
On 22 April 2014 14:10, Jakub Jelinek wrote:
> One year and one month passed from the time when the last major version
> of the GNU Compiler Collection has been announced, so it is the time again
> to announce a new major GCC release, 4.9.0.
>
> GCC 4.9.0 is a major release containing substantial
On 2 April 2014 13:08, Anthony Green wrote:
> I though the answer was to simply add something like this...
>
> (define_insn "zero_extendqisi"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (zero_extend:SI (match_operand:QI 1 "register_operand" "r")))]
> ""
> "; ZERO EXTEND (
As I am doing some work on avr, I would be available as an additional
maintainer, if you and the steering committee agree.
On 27 November 2013 08:22, Jan-Benedict Glaw wrote:
> Looking at the code, I see no way how rclass could be used
> uninitialized. The diagnostic message looks wrong to me. May need a
> fix at a totally different location, where it is issued ;)
That's PR49401:
http://gcc.gnu.org/bugzilla/show_bu
On 26 November 2013 22:05, Jeff Law wrote:
> Open to other suggestions. The fundamental issue is BARRIERs live outside
> the CFG. So a pass that thinks it can manipulate the CFG and ignore the
> underlying RTL are going to have problems with things like this.
Here, the barrier itself acts like
On 26 November 2013 17:38, Joel Sherrill wrote:
> The key to seeing the value of testing *-rtems is moving
> beyond "builds or not" and into running tests on more
> languages.
Well, we are already configuring with --enable-languages=all,ada,go ,
so there are a lot of frontends being build - just
P.S.: This is PR54664.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664
On 26 November 2013 15:55, Paul Koning wrote:
> Is there a requirement that all targets must have branch cost that it, at
> least some of the time, 4 or greater?
Not by design, although there seem to be a number of issues with
supporting targets with a lower branch cost. E.g. consider
LOGICAL_
On 26 November 2013 14:51, Jan-Benedict Glaw wrote:
> On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill
> wrote:
>> Was microblaze-rtems attempted? I would have expected a failure like
>> these if so.
>
> No, it wasn't. It's not on the list of targets in
> .../gcc/contrib/config-list.mk . So w
On 19 November 2013 18:20, Diego Novillo wrote:
> Right, because you're using 4.8. These warnings disappear when using
> trunk and/or do not actually break the build. I suppose this is too
> much for the buildbot then? It won't have a recent trunk around, so
> perhaps restricting it to the tar
>From the discussion on gcc-patches - I wonder how far should the port go
here to paper over basic brokenness in gcc to handle multi-hard-register
pointers.
On 25 October 2013 13:35, Joern Rennecke wrote:
> Well, it's not really a lie if you map hardware registers 22 and 23 to
On 24 October 2013 07:59, DJ Delorie wrote:
> In the past, if I use a register class that excludes the second half
> of register pairs, it can't do anything because it requires both parts
> of the register pair to be in the class (example: in_hard_reg_set_p
> checks this).
>
> Which way is the "r
On 22 October 2013 21:07, Andrew MacLeod wrote:
> I think this is transitional. Its such a mess right now, that I think we
> need to flatten the entire thing, and then rebuild it with some modular
> design in place such that routines and data structures are where they
> belong. then we can consid
On 18 October 2013 19:16, Andrew MacLeod wrote:
> So I think I am in favour of no includes in .h files... It may make it more
> obvious when a file is using some other inappropriate file for something,
> and it is easier for my simple analysis tools to find poor export
> candidates.
>
> I will al
Quoting Richard Biener :
Good. So what remains is the configure parts, the libgcc parts and
the documentation parts. Though for all of them they look ARC
specific so maybe the maintainership covers these as well.
I suppose this automatism when being assigned the maintainership
escaped Joern a
Quoting Ilya Enkovich :
Hi,
I'm fighting with mode switching (to be more precise with
create_pre_exit function) trying to make it work for MPX. I saw
create_pre_exit had some stability issues before and now I'm facing
similar issues trying to have it working when bound register is
returned by
I see that gcc.dg/tree-ssa/ssa-pre-21.c fails for avr.
The computation of k + 1L is done as unsigned int (16 bit),
but later ++k is performed as unsigned long (32 bit), and thus
array[k+1] is not re-used.
Is this to be considered a big in the optimizers for not
optimizing this, or in the testsuit
Quoting Kenneth Zadeck :
if (TREE_CODE (inner) == RSHIFT_EXPR
&& TREE_CODE (TREE_OPERAND (inner, 1)) == INTEGER_CST
&& TREE_INT_CST_HIGH (TREE_OPERAND (inner, 1)) == 0
&& bitnum < TYPE_PRECISION (type)
&& 0 > compare_tree_int (TREE_OPERAND (inner, 1),
Quoting Eric Botcazou :
Bootstrapped/regtested on i686-pc-linux-gnu.
For the record, and as you diagnosed, the change proposed in
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00367.html
means that we must now be very careful with memory dependency checking in the
various RTL optimization pas
Quoting Jakub Jelinek :
On Mon, May 13, 2013 at 10:45:46AM -0400, David Taylor wrote:
There are problems when using current STABS debug format for 64 bit
targets.
Why are you considering extending STABS at this point?
STABS support might very well be dropped altogether from GCC 4.9 or the nex
Quoting Andi Kleen :
if (__builtin_constant_p(x) && x == 1) ... and assume the compiler can
collapse at compile time then a SYMBOL_REF wouldn't DTRT.
Unless you set x to the address of a variable / function and this is
constant-propagated, x will not become a SYMBOL_REF.
If x is a variable wit
The documentation of __builtin_constant_p is somewhat informal. It just
says:
The function
returns the integer 1 if the argument is known to be a compile-time
constant and 0 if it is not known to be a compile-time constant.
But what is a compile-time constant?
My gut feeling is that anything
Quoting Steven Bosscher :
Hello delay-slot target maintainers :-)
N.B., that also includes me as ARC maintainer.
First of all: What is still important to handle?
It's clear that the expectations in reorg.c are "anything goes" but
modern RISCs (everything since the PA-8000, say) probably hav
Quoting David Brown :
I presume fixing the slow, inefficient serial nature of autotools is a
hard job - otherwise it would have been done already. But any
improvements there could have big potential benefits.
I think it's more likely because it is tedious and time-consuming to do,
and is not
Quoting Jeff Law :
Using distcc and ccache is trivial; I spread my builds across ~20
processors around the house...
CC=distcc
CXX=distcc g++
CC_FOR_BUILD=distcc
CXX_FOR_BUILD=distcc
It's not quite that simple if you want bootstraps and/or Canadian crosses.
STAGE_CC_WRAPPER=distcc
STAGE_CXX
Quoting David Fang :
Apart from parallelism, I wished the stage 2,3 compilations had a hook
for ccache-ing
Even better would be distcc, i.e. distribute the new compilers
around a cluster so you don't need to have all your cores and DIMMS
on the same motherboard to harness hugely massive parall
Quoting Richard Biener :
(though doesn't save much space). One file per mail is then convenient for
review anyway.
That would be 84 mails then just for the added files.
And if the testsuite was bigger, that figure would only get larger.
Is that really the preferred way to do this?
Quoting Richard Biener :
That said, filtering any non text/plain mail into spam keeps me off most
spam. Thus be warned when you try to get patches in non text/plain
sent to me ;)
Should I uuencode new port submissions?
Expressing addition of several score files as a 'patch' is not always an
o
Quoting Joern Rennecke :
P.S.:
If we need more than one operation, or mark-things-live when copying
during normal operation causes too much overhead, we could select
operations
to be performed by the copy constructor by adjusting some global state
(need not literally be a global variable - it
Quoting Florian Weimer :
On 11/18/2012 07:06 PM, NightStrike wrote:
What's wrong with std::shared_ptr?
The pointer needs two words, and the per-object overhead for the
reference counts etc. is four words, if I'm counting correctly.
(Other forms of reference counting have less overhead, of c
Quoting Paulo Matos :
Hello,
I am experience a problem in GCC4.7 scheduler whereby the scheduler
is issuing two instructions that write with a cond_exec to the same
register. It ends up looking like this:
Cond_exec p1 != 0 : r2 <- r2 and 0xf8
Cond_exec p0 != 0: r2 <- 0x10
This cannot ha
Quoting Richard Biener :
Can we instead make it sort @gcc.gnu.org accounts first when it asks
to confirm
a CC member? Hard to pick the correct person from all the noise ... (if you
happen to not remember the exact match).
Well, that'd be all right with me, but if there is no @gcc.gnu.org a
Could we make bugzilla recognize all the email addresses in the MAINTAINERs
file? It is frustrating to identify the maintainer of the piece that's
broken, only to find that bugzilla will refuse to add the person the the CC
list. This affects a number of the sub PRs of PR47093 / PR44756 ,
which i
Sorry for the recent loop-doloop.c breakage. I did test it, but I didn't take
a day to re-test it the two hundred configurations in config-list.mk and
sift out the pre-broken ports; as i had only changed 'target-independent'
code since the last full test, I only tested in on i686-pc-linux-gnu.
Wh
Quoting Steven Bosscher :
Paul Matos wrote (http://gcc.gnu.org/ml/gcc/2012-10/msg00123.html):
Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such that
jumps are not modified after sched2?
No, there isn't.
Well, you could add a target-specific pass after sched2 with the sole
I'll have to prepare a few more patches to (supposedly) generic
code to support the ARCompact port, which we (Synopsys and Embecosm)
would like contribute in time for gcc 4.8.
How much time is left till we switch from phase 1 to phase 3?
Quoting Ian Lance Taylor :
On Tue, Sep 11, 2012 at 3:18 PM, Lawrence Crowl wrote:
The contrib/config-list.mk tool appears to be suffering from bitrot.
The make failures for a limited subset of configurations consisted
exclusively of:
cc1: warnings being treated as errors
../../../../gcc/fixin
Quoting Georg-Johann Lay :
The avr backend auto-generates parts of GCC's texi documentation,
namely the supported -mmcu= options, which are about 200.
I hope that autogenerated documentation is still helpful then.
Sometimes an overabundance of verbose documentation can prevent a user
from find
Quoting paul_kon...@dell.com:
I'm running into an ICE due to what looks like wrong register
allocation, and I'm trying to figure out where the problem lies. It
shows up with today's GCC (trunk). I haven't yet tried to narrow
it down to a particular change.
It shows up in the pdp11 ta
Quoting James Dennett :
On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote:
Hi,
Is gcc 4.3 still supported? Will there be release of gcc 4.3.7?
No. http://gcc.gnu.org/ describes GCC 4.5.x as the "oldest maintained
release series".
Of course, if he has the resources and willingness to d
Quoting "H.J. Lu" :
On Sun, May 13, 2012 at 6:17 PM, wrote:
Quoting "H.J. Lu" :
What is the expect run-time behavior when a + b has
overflow/underflow?
The expectation is wrap-around. Note that loop strenght reduction can
cause assumed wrap-around semantics in RTL for strictly conformin
Quoting "H.J. Lu" :
Will x86 backend ever see a memory address with wrap around.
Actually, just this kind of problem made the indexed addressing mode
for SH64 for the ABIs with 32 bit addresses unusable.
If your MMU supports it, you can try to map the second 4 GB * maximum scale
mapped to the
Quoting Richard Sandiford :
nick clifton writes:
OK, but what if it turns out that the new algorithm improves the
performance of some benchmarks/applications, but degrades others, within
the same architecture ? If that turns out to be the case (and I suspect
that it will) then having a docume
Quoting "H.J. Lu" :
Putting our own foo in a section with a special prefix in section name,
like .secondary_*, works with linker support. But it isn't very reliable.
In what way is requiring linker support for STB_GNU_SECONDARY more reliable
than requiring linker support for .secondary_* sect
Quoting "H.J. Lu" :
We only have very few bits to in STB_XXX field.
Well, you could put the information somewhere else. E.g. a special
relocation,
or a special elf section. Or you could mangle the information into
the section name in which the symbol is present.
Even better, you could u
Quoting "H.J. Lu" :
Hi,
We have a need to define a secondary symbol as backup in
case there isn't a primary one. Here is a proposal for
STB_GNU_SECONDARY. Any comments?
If two levels of prevedence (ordinary and weak) are not enough, why will
three levels be so much better?
If you use a sign
Quoting Stefano Lattarini :
By looking at the 'handle_texinfo_helper' function in the automake script,
I suspect adding a new Automake option 'info-in-builddir' (say) and an
handful of lines to the automake script might be enough to give you an easy
way to force the '.info' files to be generated
Quoting Basile Starynkevitch :
I also am in favor of having a software linked dynamically with shared
libraries, for a very pragramtical reason: If a software has shared
libraries, then modifying one such library in its implementation (not its
interface) is very often easier for the developer, w
I find that I'll have to change the epiphany LINK_SPEC to allow sane
interaction
between libc and libgloss. The latter might need errno / __errno from the
former.
May I apply a patch to config/epiphany/epiphany.h to fix this during phase 4?
Shouldn't trunk/gcc/ChangeLog be rotated for the new year?
Also, there is a conflict marker introduced in 182938.
Quoting Dmitry Melnik :
Hi,
In cortex-a8.md call cost is set to 32, while in cortex-a9.md it's 0:
== cortex-a8.md ==
;; Call latencies are not predictable. A semi-arbitrary very large
;; number is used as "positive infinity" so that everything should be
;; finished by the time of return.
(def
Quoting Richard Henderson :
I can fix this in libgcc/config/epiphany/t-epiphany with:
unwind-sjlj.o : CFLAGS += -fno-exceptions
unwind-sjlj.o : c_flags := $(filter-out -fexceptions,$(cflags))
Is that the right way to do it? Or should we more generally remove
-fexceptions
from the build ru
I find that exception handling doesn't work properly for the epiphany with
recent gcc sources (it worked in the pre-merged port with sources from July).
I suppose that is related to the change mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01926.html
Looking at the cleanup-5.c failure
Quoting Gerald Pfeifer :
On Thu, 17 Nov 2011, Richard Guenther wrote:
I indeed do not see where we link to criteria.html. I think we should
duplicate the list of primary/secondary targets on the releases
index.html page(?) and make the rest of the criteria.html generic,
pointing to it from gcc
Quoting Feng LI :
So I suppose with (clobber (reg:CC FLAGS_REG)), the compiler
will be capable to know this register will be modified in this
instruction and
apply proper behavior when necessary?
Depends. It will stop the compiler moving a FLAGS_REG setter and/or user
such that FLAGS_REG
Quoting Ian Lance Taylor :
Offhand I don't know of any way to get the compiler to save CC for you
around your instruction. That's a stiff requirement.
It's easy to do under explicit control of the pattern, using (a) match_scratch
clobber(s) of (a) register(s) of the required class(es) - or if
Quoting Jonathan Wakely :
Of course, such a thing could be done by some GCC plugin, but I
believe providing the
feature inside GCC itself, and documenting the format of the
textual type annotation
file, would give this feature more visibility, and it would help
people a lot. And I am
pre
Quoting David Brown :
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
16-bit integer - basically combining an 8-bit x 8-bit to 16-bi
Quoting Richard Henderson :
(define_predicate "call_address_operand"
(match_code "symbol_ref,const,reg")
{
return (symbolic_operand (op, mode) || (GET_CODE (op) == REG));
})
Nit.
(define_predicate "call_address_operand"
(ior (match_code "reg")
(match_operand 0 "symbolic_operand")
I propose myself as maintainer of the Epiphany port.
This port is currently being submitted / reviewed on the gcc-patches
mailing list.
Quoting Hans-Peter Nilsson :
I came to the somewhat the same conclusion for CRIS where all
insns set condition codes except move to memory and a "add
reg1,reg2" (no immediate operand) and to/from special registers:
there'll one clobbering and one CC_REG-setting pattern plus a
load of others (pee
Quoting DJ Delorie :
I was talking about what addresses are allowed by the
TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
what the register allocator is guided to produce; some optimizers
can get quite 'creative' in mashing rtl together.
I've never seen it actually do that
Quoting DJ Delorie :
m32c.c:m32c_legitimate_address_p allows any rubbish inside a
PRE_MODIFY, as long as the address register is the stack pointer.
OTOH, it does not define any HAVE_*_MODIFY_* macro.
m32c has push/pop and no other pre/post modify
I was talking about what addresses are allow
Quoting amyl...@spamcop.net:
The issue with this patch is that we'll have to check if gen_add3_insn might
fail on any target, and also we have to identify on which targets it will
create an insn that clobbers potentially live hard registers
(like a flags register), and make the substitution fail
Quoting "Paulo J. Matos" :
This is a very strange insn indeed:
(set (ge (reg:QI 0 AH [orig:26 w ] [26])
(const_int 0 [0]))
(plus:QI (plus:QI (ltu:QI (reg:CC 13 CC)
(const_int 0 [0]))
(lt (reg:QI 0 AH [orig:30 a ] [30])
(const_int 0 [0])))
Quoting Ulrich Weigand :
Paulo J. Matos wrote:
(define_insn_and_split "neghi_internal"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_dup 0)))
(set (match_operand:QI 1 "register_operand" "=c")
(plus:QI
(plus:QI
(ltu:QI (
Quoting Gerald Pfeifer :
On Fri, 22 Jul 2011, Joern Rennecke wrote:
I agree that trying to track every library there would be a maintenance
burden, but giving one example of a library that works is meaningful.
And, since GCC is still a GNU project, mentioning the status of GNU libc
doesn&#
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
And all my (define_insn "*mov..." are tagged with a (clobber (reg:CC
RCC
Quoting paul_kon...@dell.com:
It would seem that making it equal to word size (whatever that is on
the platform) or size of the int type would be a way to make this
better. Would that have any bad consequences for other platforms?
For MXP (16-bit word addressed, with 128 bit vector regis
Quoting Richard Guenther :
So are you saying that we should remove the recursive nature of the
rtx_cost/targetm.rtx_costs interface, and have the backend handle any
recursion itself? I.e. targetm.rtx_costs only ever sees a complete
(but perhaps invalid) instruction pattern? Or would you still
Quoting Daniel Marjamäki :
Yes. It sounds unlikely. But not impossible of course. I could also
make sure the member variables are POD types before I inhibit the
warning. I just have no idea how I check if a member is POD. But I
could investigate this.
You could check if it has a constructor, u
1 - 100 of 586 matches
Mail list logo
