Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> introducing a tree LOOP_HEADER with single argument N (number of
> iterations of the loop), that would be present in IL at the beginning of
> header of each loop. I have following mo
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> "Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
>
>> I have built a cross-compiler for m68k-elf with GCC 4.1.1.
>> I need to know the difference in implementations of -fpic and -fPIC
>> for this particular target.
>
> -fpic uses a 16-bit offset when acces
Roger Sayle <[EMAIL PROTECTED]> writes:
> Once explained, I'd expect most maintainers would make precisely the
> same call?
I suppose the counter-argument is that we shouldn't ship 4.2 in its
current state. We should either back out the patch that made
REG_POINTER more prominent or go with the fi
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Also, having patches on mainline and not a release branch can cause
>> quite a bit of confusion. Witness what happend with PR 28243, where I
>> fixed something on mainline, but it was not directly approved for a
>> release branch. Then Eric B. worked a
Gah! My seond procedural post in as many days, sorry.
First: I've been very disappointed by the tone that some gcc developers
have taken against Liqin. We've built up an awful lot of rules and
procedures around gcc -- with many more now than when I started six
years ago -- and I don't think it's
Can a register be used more than once in an insn if one of those uses is
an auto-modification? I've looked at this several times in the past and
never come to a conclusion. doc/rtl.texi says:
If a register used as the operand of these [auto-modification]
expressions is used in another addres
Brooks Moses <[EMAIL PROTECTED]> writes:
> Anyhow, if I try this, I get the following error (trimmed slightly for
> clarity):
>
>gcc -c [...] ../../svn-source/gcc/genconstants.c
>In file included from tm.h:7,
> from ../../svn-source/gcc/genconstants.c:32:
>options.h
Weidong Cui <[EMAIL PROTECTED]> writes:
> Hi, Everyone:
> I am trying to build gcc with distcc on 3 linux
> boxes. But when I build gcc with option '--enable-bootstrap',
> the 'distcc' doesn't work. So I disabled bootstrap , then 'distcc'
> worked effective.
>
> My question is: how to build
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>> I am thinking of extending the *.opt machinery (ie the
>> gcc/opt-functions.awk gcc/optc-gen.awk gcc/opth-gen.awk files) to
>> offer some GCC options which can be disabled or enabled by an
>> appropriate configure flag.
>>
>> More precisely, conf
Paul Eggert <[EMAIL PROTECTED]> writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>> it sounds like that would eliminate most of the problem. Certainly,
>> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> easy thing to do; that's just a guarantee about constant folding.
>
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:
>> Paul Eggert <[EMAIL PROTECTED]> writes:
>> > Mark Mitchell <[EMAIL PROTECTED]> writes:
>> >> it sounds like that would
I know Andrew replied privately, but I hope he doesn't mind me raising
the issue on-list. I just wanted to guage the general feeling as to
whether I'd screwed up, and whether I should have submitted the patches
in a different way.
Richard
--- Begin Message ---
[off-list]
Posting sixty patches
Thanks to everyone for the feedback. I just wanted to apologise for
something that Eric brought up...
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> I know Andrew replied privately, but I hope he doesn't mind me raising
>> the issue on-list. I just wanted to guage the general feeling as to
>> whet
David Daney <[EMAIL PROTECTED]> writes:
> Sometime between 1/7 and 1/16 on the trunk I started getting wrong code
> on a bunch of java testcases under mipsel-linux.
>
> It looks related to (but not necessarily caused by) this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html
>
> F
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:
> I found the following in my build logs, and thought it was worth
> reporting to you. Although I don't speak texinfo, the lines in
> questions are the ones introduced by your ColdFire 9/63 patch
> (commited as rev. 120713):
>
> perl /home/fxcou
CodeSourcery is gearing up to submit support for the VxWorks RTP PIC
model. Six targets are affected: arm, i386, mips, rs6000, sh and sparc.
All this code is conditional on TARGET_VXWORKS_RTP being true and refers
to two other macros: VXWORKS_GOTT_BASE and VXWORKS_GOTT_INDEX.
Before submitting pa
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> 1) Wrap it in #ifdef TARGET_VXWORKS_RTP.
>>
>> 2) Provide an always-false definition of TARGET_VXWORKS_RTP in
>> arm.h, i386.h, etc.
Jim Wilson <[EMAIL PROTECTED]> writes:
> Dave Korn wrote:
>> But it is ok to use a define_expand (that accepts all alternatives) for
>> movsf and use that to generate one of several movsf_ insns, isn't it?
>
> Reload doesn't use the move define_expands. It can't. A define_expand
> is allow
Jupming in at a random point.
First, unless my memory is completely faulty, Stan Cox should be named
in this change too. ISTR he did the initial implementation for one
particular coprocessor, which we later generalised to cover other user-
configurable coprocessors. However, as DJ says, it's bee
emoved options which are now documented there.
I'd argue that...
> 2006-02-18 Richard Sandiford <[EMAIL PROTECTED]>
> (-fsection-anchors): Document.
belongs in that category too. It only works for two ports at present
(MIPS and PowerPC) and for one of them it's on by defa
"Fu, Chao-Ying" <[EMAIL PROTECTED]> writes:
> After tracing GCC 4.x to see why MADD is not generated for MIPS32,
> I found out the main issue is that the pattern "adddi3"
> is not available for MIPS32. Because the missing
> of adddi3, GCC 4.x needs to split 64-bit addition to 4 separate
> RTL in
Nigel Stephens <[EMAIL PROTECTED]> writes:
> While I agree with you philosophically, it feels like (b) might be quite
> a major task. A number of optimisation passes which currently recognise
> and MUL and PLUS separately (e.g. loop strength reduction) would now
> need to be extended to handle t
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> This should be a post-reload (i.e. predicated on reload_completed)
>>> split, I think.
>>
>> Actually, with the relatively recent lower-subreg work, it is
>> desirable to split this sort of instruction before reload. That is,
>> do an unconditional sp
Nigel Stephens <[EMAIL PROTECTED]> writes:
> OK, so maybe as the person who removed adddi3 from the MIPS backend, and
> the main proponent of the new fused opcodes, you get to volunteer to
> implement this? :)
Hey, I was pretty happy with the status quo ;)
Richard
Nigel Stephens <[EMAIL PROTECTED]> writes:
> I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris,
> mcore, score, arm & pa backends still implement adddi3 as either a
> define_insn which outputs two instructions or an explicit define_expand
> followed define_split and associated
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> I realise no-one else has spoken out in support of me, so perhaps
>> I'm in a minority of one here. But it does seem to me that in the
>> Tree-SSA world, it
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>
>> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>> > Richard Sandiford <[EMAIL PROTECTED]> writes:
>> >> I realise no-one else has spoken out in
Andreas Krebbel <[EMAIL PROTECTED]> writes:
> What I'm curious about is why this didn't occur earlier?! The symbol
> is available since 2003 and I can hardly imagine that no platform was
> ever in need of it till now.
To answer that, I'm afraid my patch is
Zack Weinberg <[EMAIL PROTECTED]> writes:
> I have worked out a tentative plan for replacing most of these macros
> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
> LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRE
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> I've been converting the ppc options to use the .opt machinery, and
> am confused as to how to approach subtargets.
>
> What's the deal with these?
>
> I need options only for certain subtargets. For example, aix.h has
> some options that should not be
"Mile Davidovic" <[EMAIL PROTECTED]> writes:
> But problem is passing G0 option, if I simple put
> MULTILIB_OPTIONS = G0 mlong-calls msoft-float EL/EB mips32/mips64
> building library fail.
If you add something to MULTILIB_OPTIONS, you need to add an entry
to MULTILIB_DIRNAMES as well.
(Sorry
Kazu Hirata <[EMAIL PROTECTED]> writes:
> I would like to propose that the c4x port be obsoleted for 4.0.
>
> c4x-*
> tic4x-*
>
> The primary reason is that the port doesn't build.
>
> Richard Sandiford's recent patch allows us to go further during the
> build process, but the port still does
[EMAIL PROTECTED] writes:
> asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));
In addition to Daniel's reply: you wouldn't want to use "r" here.
That's for general registers only.
The MIPS port does in theory support coprocessors, but the functionality
isn't tested much (if at all). The c
Mark Mitchell <[EMAIL PROTECTED]> writes:
> If you are willing to help, please download the release candidate, build
> it on appropriate platforms, and post testresults by using
> contrib/test_summary. Please use the release candidate itself, *not*
> the CVS 4.0 release branch, as part of the goal
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4. The problem is the following hack in mips.h:
/* When generating mips16 code we want to put the jump table in the .text
section. In
Richard Sandiford <[EMAIL PROTECTED]> writes:
> PS. mips.c has the following
>
>
> /* Return the length of instruction INSN.
>
>??? MIPS16 switch tables go in .t
Ian Lance Taylor writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> Huh. For the record: it can't. get_attr_length() returns 0
>> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
>> the comment when applying the bug-fix patch to m
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Mark,
>
> I tried running some MIPS16 tests against RC1 and found a regression
> from 3.4. The problem is the following hack in mips.h:
> [...]
> The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
Mark Mitchell <[EMAIL PROTECTED]> writes:
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_summary script, an
Jonathan Larmour <[EMAIL PROTECTED]> writes:
> On MIPS, libgcc is built with -G 0, which is used to ensure the contents
> don't assume they will be placed in the small data/bss section. Setting
> -G 0 is used to allow for the possibility of large applications, or
> those where even small data may b
Zack Weinberg <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> The only reliable way to get what you want is to either (a) add -G0
>> multilibs or (b) change the default -G setting. Perhaps a configure
>> option would be useful h
Andreas Krebbel <[EMAIL PROTECTED]> writes:
> In:
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00456.html
>
> you proposed to take care of this in the 4.1 (formerly 3.6) timeframe fixing
> all places where shift rtxes are generated besides optabs.
> Is this still on your todo list?
Yes, but so a
Nadezhda Ivanоvna Vyukova <[EMAIL PROTECTED]> writes:
> The __builtin_isless, __builtin_islessequal functions are provided as
> implementations of standard C99 functions 'isless', 'isgreater'. Please,
> explain why gcc for mips implements them via instructions
>
> c.lt.FMT and
> c.le.FMT
David Edelsohn <[EMAIL PROTECTED]> writes:
> I notice that options.h no longer is included, but including that
> file does not fix the problem.
Argh! Sorry for the breakage. Can you send me the preprocessed
options.c file?
Richard
Richard Sandiford <[EMAIL PROTECTED]> writes:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>> I notice that options.h no longer is included, but including that
>> file does not fix the problem.
>
> Argh! Sorry for the breakage. Can you send me the preproce
As David describes here:
http://gcc.gnu.org/ml/gcc/2005-05/msg00807.html
having options.c include config.h, system.h, coretypes.h and tm.h
was causing a bootstrap failure on AIX. The first of the two problems
was caused by options.c including before anything else.
The patch below changes th
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> For example, "Results for 4.1.020050506(experimental) testsuite on
> mips64-unknown-elf" with the components of the version number all run
> together
> [...]
> Ensuring your test results
> use the standard Subject header format makes it more likely
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Wed, 18 May 2005, Richard Sandiford wrote:
>> FWIW, those mips messages _were_ sent with test_summary. I'm not
>> sure why they got mangled. Are there any known issues that would
>> cause that?
>
&
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Henderson wrote:
>> After three days of sequential bootstrap breakage, I'd like to propose
>> that mainline go into slush, wherein all these bootstrap problems, and
>> all the new testsuites failures get fixed. No other patches would be
>> allowe
Eric Christopher <[EMAIL PROTECTED]> writes:
>> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
>>
>> Just to let folks know that mips-elf fails to build newlib.
>> There's a segfault in is_gimple_reg_type(), which is being
>> passed a null type. I'm not sure if I'll have time to look
>> at it toni
Diego Novillo <[EMAIL PROTECTED]> writes:
> On Mon, May 30, 2005 at 11:03:24AM -0600, Jeffrey A Law wrote:
>> In this case I'd replace the .* with _5 and see if it matches
>> properly. If it does, then I'd tighten the wildcard.
>> Something like p_[0-9]*
>>
> Excellent, that worked. I wonder why
Thanks for the summary. It sounds from your message, and particularly
the quote from RMS, that we should be accepting the patches unless we
have a particular reason not to trust MIPS to do what they said they'd
do. I certainly have no reason not to trust MIPS, so I guess that
means the patches ca
Mark Mitchell <[EMAIL PROTECTED]> writes:
> The GCC 4.0.1 RC1 prerelease is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Some mips-elf results:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00692.html
which are the same as for 4.0.0.
Richard
[EMAIL PROTECTED] writes:
> I'm trying to trace the source code of gcc/mips.
> It uses a SYMBOL_REF_SMALL_P macro,
> According to the index of 'GNU Compiler Collection Internals',
> it should be documented on section RTL representation-Access to Special
> Operands but it's not.
> How can I find it'
"IM.Nobody" <[EMAIL PROTECTED]> writes:
> I am wondering if MIPS-X has been supported.
Not by FSF releases, no. I'm not aware of a private port either,
but perhaps others know better.
Richard
Ian Lance Taylor writes:
> Steven Bosscher <[EMAIL PROTECTED]> writes:
>> So you have a few instructions bundled into a VLIW instruction, and
>> one of the instructions in the bundle is moved into the delay slot,
>> thus breaking your VLIW bundle. Right?
>
> I think there are two natural approach
David Daney <[EMAIL PROTECTED]> writes:
> I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1) and
> whenever I compile even the simplest hello-world.c libgcc_s.so is linked.
FWIW, I'm seeing the same thing with a similar native setup.
I hope to have a look at it soon.
Richard
Summary:
This optimisation will allow GCC to access more than one object from
the same symbolic address. For example, suppose a section contains
two variables x and y, and x and y are close together. The
optimisation will create a common anchor point -- let's call it A --
and a
"Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
> The destination operand of the `sub' instruction, d0, will be written
> back in the 4th cycle, and the instruction `max' will use it as source
> operand (i.e., there is a true data dependency).
>
> I figured out that the state_transition() returns -1 w
Wu Zhou <[EMAIL PROTECTED]> writes:
> I am reading <> and found two typoes. Here is a patch to
> fix them.
Thanks! I've applied it under the obviously-correct rule after testing
with "make dvi" and "make info".
> Is this the correct mail-list for this kind of patch. Thanks.
Not quite: there's
Further to Eric's good advice:
Do you already have access to a mips64 version of glibc? (You said in
your message that you'd tried a native build, but I wasn't sure whether
that was using a 32-bit OS or a 64-bit OS)
It's tricky to build a toolchain and glibc in tandem (i.e. when neither
is avail
Mark Mitchell <[EMAIL PROTECTED]> writes:
> GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the:
>
> pub/gcc/prerelease-4.0.2-20050913/
>
> subdirectory.
>
> It's important to test the actual tarballs, rather than CVS, to check
> for any packaging issues. If you can, download a
I notice that the following testcase:
int x[4];
void f1 (long long n) { while (n-- != 0) x[n] = 1; }
void f2 (long long n) { while (n-- != 0) x[n] = 1; }
void f3 (long long n) { while (n-- != 0) x[n] = 1; }
when compiled with optimisation enabled on i386-linux-gnu, causes us to
go
Ian Lance Taylor writes:
> This kind of error generally means that the operand predicate accepts
> an operand which no constraint matches. If the predicate (e.g.,
> register_operand) accepts an operand, then there must be a constraint
> that matches it. Otherwise you will get an error in
> const
Albert Chin <[EMAIL PROTECTED]> writes:
> On Wed, Oct 12, 2005 at 05:09:20PM +0200, Rainer Orth wrote:
>> Albert Chin <[EMAIL PROTECTED]> writes:
>>
>> > ld32: FATAL 2 : Internal: at ../../ld/section_type.c In load_info()
>> > unknown section type
>> > collect2: ld returned 1 exit status
>
"Richard Earnshaw (lists)" writes:
> On 21/01/2020 17:20, Jason Merrill wrote:
>> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
>>> On 21/01/2020 15:39, Jakub Jelinek wrote:
On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists)
wrote:
>> Some examples would be us
TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an
associated source-level decl and neither of which are in an anchor block:
(Q1) can a valid byte access at X+C alias a valid byte access at Y+C?
(Q2) can a valid byte access at X+C1 alias a valid byte access at Y+C2,
C1
Thanks for the answer, and sorry for slow follow-up. Got distracted by
other things...
Jeff Law writes:
> On Sat, 2020-01-25 at 09:31 +0000, Richard Sandiford wrote:
>> TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an
>> associated source-level decl and n
"H.J. Lu" writes:
> On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
>>
>> On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
>> > > > In my experience the output of git log is a total mess so cannot
>> > > > replace ChangeLogs. But we can well decide to drop ChangeLog for
>> > > > the tes
changelog
format should be one acceptable way of writing good patch descriptions,
but not the only acceptable way.
Sometimes the traditional changelog is better than a plain English
description (the SVE PCS work being one recent example from my POV).
But for modern VCSes there's IMO
Andrew Stubbs writes:
> Hi all,
>
> Up until now the AMD GCN port has been using exclusively 64-lane vectors
> with masking for smaller sizes.
>
> This works quite well, where it works, but there remain many test cases
> (and no doubt some real code) that refuse to vectorize because the
> numbe
Bernd Edlinger writes:
> On 4/1/20 8:51 AM, Bernd Edlinger wrote:
>> On 3/26/20 4:27 PM, Bernd Edlinger wrote:
>>> On 3/26/20 4:16 PM, Christopher Faylor wrote:
marc.info is an independent site that is not associated with
sourceware.org. We don't control it. If you have questions
Bernd Edlinger writes:
> On 4/2/20 11:01 AM, Richard Sandiford wrote:
>> Bernd Edlinger writes:
>>> On 4/1/20 8:51 AM, Bernd Edlinger wrote:
>>>> On 3/26/20 4:27 PM, Bernd Edlinger wrote:
>>>>> On 3/26/20 4:16 PM, Christopher Faylor wrote:
>>&
Thomas Neumann via Gcc writes:
>> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate
>> implementation in GLIBC creates its own set of advantages and
>> disadvantages.
>
> so what should I do now? Should I try to move the lookup into GLIBC? Or
> handled it within libgcc, as I had or
Martin Liška writes:
> Hi.
>
> Thanks to Jakub, we finally set up an experimental environment:
> gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
>
> The repository now contains a new pre-commit hook that validates
> the git commit format ([1]) and provides a reasonable error message
> when violate
Richard Biener writes:
> I'm facing the issue that we have vector type dependent information
> stored in dr_vec_info (the misalignment at least) and that with
> BB vectorization (at least) we want to be able to access a DR group with
> two different vector types.
>
> I've run into this with
> htt
Jonathan Wakely via Gcc writes:
> On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote:
>>
>> * Jonathan Wakely via Gcc:
>>
>> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc
>> > wrote:
>> >>
>> >> Hi *GCC*:
>> >>
>> >> On page:
>> >>
>> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros
PR96191 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191]
was a bug raised against the aarch64 implementation of -fstack-protector.
As it happens, the same bug affected arm, but AFAICT those are the only
two affected targets.
-fstack-protector works by:
* creating a special canary slot in the
oke.texi
>
>
> http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf
Thanks for the heads-up. I've applied the GCC patch below to trunk
and all active branches, and applied the web patch too.
Richard
>From 0
Pip Cet via Gcc writes:
> 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 stepping through the ba
"Qian, Jianhua" writes:
> Hi
>
> I'm adding a new machine model. I have a problem when writing the
> "define_insn_reservation" for instruction scheduling.
> How to write the "define_insn_reservation" for one instruction that there are
> different latencies and pipelines according to parameter.
>
Anton Youdkevitch writes:
> Folks,
>
> I'm trying to deal with CFG construction at RTL level and I bumped into a
> problem
> when I created a jump to a certain label. After the jump is created I try
> to extract the
> label using JUMP_LABEL but I get nothing.
>
> The code looks like like this:
>
>
Segher Boessenkool writes:
> Hi!
>
> On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote:
>> This is just personal opinion, but in general (from the point of view
>> of a new port, or a new subport like SVE), I think the best approach
>> to handling the &
Segher Boessenkool writes:
> On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > You can also use some other attributes to classify instructions, you
>> > don't have to put it all in one "type" attribu
Ilya Leoshkevich via Gcc writes:
> On Wed, 2020-09-09 at 16:09 -0500, Segher Boessenkool wrote:
>> Hi Ilya,
>>
>> On Wed, Sep 09, 2020 at 11:50:56AM +0200, Ilya Leoshkevich via Gcc
>> wrote:
>> > I have a vector pseudo containing a single 128-bit value (V1TFmode)
>> > and
>> > I need to access it
Ilya Leoshkevich writes:
> On Fri, 2020-09-11 at 12:17 +0200, Ilya Leoshkevich wrote:
>> On Fri, 2020-09-11 at 10:46 +0100, Richard Sandiford wrote:
>> > Ilya Leoshkevich via Gcc writes:
>> > > On Wed, 2020-09-09 at 16:09 -0500, Segher Boessenkool wrote:
>>
"Qian, Jianhua" writes:
> Hi Richard and Segher
>
> I don't know if I exactly understood your discussion.
> If I misunderstood, please let me know.
>
> I am trying to test these two cases.
> Case 1. keep the TYPE attribute unchanged, add new attributes
> It works well as below.
> (define_a
Segher Boessenkool writes:
>> Although this looks/sounds complicated, the advantage is that everything
>> remains up-to-date. If we instead added a second attribute and only
>> defined it for instructions like *add__, other instructions
>> (including config/arm instructions) would still have type
Christophe Lyon via Gcc writes:
> On Wed, 23 Sep 2020 at 01:47, Martin Sebor wrote:
>>
>> On 9/22/20 9:15 AM, Christophe Lyon wrote:
>> > On Tue, 22 Sep 2020 at 17:02, Martin Sebor wrote:
>> >>
>> >> Hi Christophe,
>> >>
>> >> While checking recent test results I noticed many posts with results
"Hu, Jiangping" writes:
> Hi,
>
> I find there are many "ATTRIBUTE_UNUSED" macros in the function parameter
> lists,
> but some of the parameters are used in the function bodies in fact. E.g.
>
> @@gcc/final.c
> void
> output_operand (rtx x, int code ATTRIBUTE_UNUSED)
> {
> if (x &&
Sorry in advance for inviting a bikeshed discussion, but while making
the hashing changes that I just committed, I noticed that the C++ification
has been done in a variety of different styles. I ended up having to follow
the "do what the surrounding code does" principle that some code bases have,
Mikhail Maltsev writes:
> On 06/25/2015 09:28 PM, Richard Sandiford wrote:
>> Sorry in advance for inviting a bikeshed discussion, but while making
>> the hashing changes that I just committed, I noticed that the C++ification
>> has been done in a variety of different style
I have a series of patches to convert all non-optab instructions to
the target-insns.def interface. config-list.mk showed up one problem
though. The pa indirect_jump pattern is:
;;; Hope this is only within a function...
(define_insn "indirect_jump"
[(set (pc) (match_operand 0 "register_operan
Trevor Saunders writes:
> On Tue, Jun 30, 2015 at 09:53:31PM +0100, Richard Sandiford wrote:
>> I have a series of patches to convert all non-optab instructions to
>> the target-insns.def interface. config-list.mk showed up one problem
>> though. The pa indirect_jump patter
"H.J. Lu" writes:
> Since ira_implicitly_set_insn_hard_regs may be called outside of
> ira-lives.c, it can't use the local variable, preferred_alternatives.
> This patch adds an alternative_mask argument to
> ira_implicitly_set_insn_hard_regs.
>
> OK for master and 5 branch if there are no regress
"H.J. Lu" writes:
> On Thu, Aug 6, 2015 at 11:19 AM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> Since ira_implicitly_set_insn_hard_regs may be called outside of
>>> ira-lives.c, it can't use the local variable, preferred_alternativ
Jeff Law writes:
> On 08/20/2015 11:28 AM, Claudiu Zissulescu wrote:
>> Hi Jeff,
>>
>> In the gencodes.c:89, it explicitly decrements by one the return
>> value of get_num_insn_codes(). While for the get_num_insn_codes is
>> stated this:
>>
>> /* Return the number of possible INSN_CODEs. Only me
"Steve Ellcey " writes:
> I have a question about gengtype and GTY. I was looking at adding some
> code to mips.c and it occurred to me that that file was getting very
> large (19873 lines). So I wanted to add a new .c file instead but that
> file needed some types that were defined in mips.c an
Richard Biener writes:
> On Mon, 9 Nov 2015, Prathamesh Kulkarni wrote:
>> c) Gating the divmod transform -
>> I tried gating it on checks for optab_handlers on div and mod, however
>> this doesn't enable transform for arm cortex-a9
>> anymore (cortex-a9 doesn't have hardware instructions for inte
Kyrill Tkachov writes:
> On 05/03/16 05:52, Jeff Law wrote:
>> On 03/04/2016 09:33 AM, Kyrill Tkachov wrote:
>>>
>>> On 04/03/16 16:21, Jeff Law wrote:
On 03/04/2016 08:05 AM, Richard Biener wrote:
>> does that mean that the shift amount should be DImode?
>> Seems like a more flexible
1 - 100 of 559 matches
Mail list logo
