Pedro Alves writes:
> On 07/12/2018 12:40 PM, Jonathan Wakely wrote:
>> On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
>>> +Only use non-constant references in the following situations:
>>> +
>>> +
>>> +
>>> +when they are necessar
Following on from:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00603.html
this patch is an RFC to mention references in the C++ coding conventions.
It allows const references anywhere they're useful but only allows
non-constant references in contexts that conform to a standard
interface, or
Jeff Law writes:
> Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff.
> When we left things I think we were trying to decide between
> CLOBBER_HIGH and clobbering the appropriate subreg. The problem with
> the latter is the dataflow we compute is inaccurate (overly pessimistic)
Steve Ellcey writes:
> On Wed, 2018-05-16 at 22:11 +0100, Richard Sandiford wrote:
>>
>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED is the only current way
>> of saying that an rtl instruction preserves the low part of a
>> register but clobbers the high part. We would
Andrew Pinski writes:
> On Fri, May 25, 2018 at 3:35 PM, Steve Ellcey wrote:
>> I was curious if there was any reason that REG_ALLOC_ORDER is not
>> defined for Aarch64. Has anyone tried this to see if it could help
>> performance? It is defined for many other platforms.
>
> https://gcc.gnu.org
Steve Ellcey writes:
> On Wed, 2018-05-16 at 17:30 +0100, Richard Earnshaw (lists) wrote:
>> On 16/05/18 17:21, Steve Ellcey wrote:
>> >
>> > It doesn't look like GCC has any existing mechanism for having different
>> > sets of caller saved/callee saved registers depending on the function
>> > at
Andrew Stubbs writes:
> Hi all,
>
> I'm in the process of trying to update our AMD GCN port from GCC 7 to
> GCC 8+, but I've hit a problem ...
>
> It seems there's a new assumption that pointers and addresses will be
> scalar, but GCN load instructions require vectors of pointers.
> Basically,
Thomas Koenig writes:
> Hello world,
>
> whenever I look at the list of serious bugs, I find myself chaning the
> columns to add the priority field.
>
> What do you think about adding the priority field when clicking on that
> link? A patch is attached.
I don't think anyone replied to this so fa
Jeff Law writes:
> On 05/12/2018 10:02 AM, Richard Sandiford wrote:
>> "A. Skrobov" writes:
>>>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
>>>> (sigh, bad modularity). I'm not at all familiar with how the hashing
>>
"A. Skrobov" writes:
>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb
>> (sigh, bad modularity). I'm not at all familiar with how the hashing
>> is used within the selective scheduler, so I can't really say what the
>> selective scheduler *should* be doing here.
>
> OK, I se
Hi,
"A. Skrobov" writes:
> Hello,
>
> While working on a port of GCC for a non-public architecture that has
> pre/post-modify memory access instructions, I discovered what looks
> like a bug which can cause incorrect code generation.
>
> My suggested fix is trivial:
> https://github.com/tyomitch/
Joseph Myers writes:
> On Mon, 19 Feb 2018, Sandra Loosemore wrote:
>
>> On 02/19/2018 09:45 AM, Joseph Myers wrote:
>> > On Sun, 18 Feb 2018, Sandra Loosemore wrote:
>> >
>> > > Thanks, this makes sense. I think I could produce a documentation patch
>> > > that
>> > > explains that the differen
Steve Ellcey writes:
> On Fri, 2018-02-09 at 17:15 +0000, Richard Sandiford wrote:
>>
>>
>> If the code you're adding is inherently specific to Advanced SIMD
>> (not sure, but guessing yes based on this being aarch64-builtins.c)
>> then like Kugan says,
Steve Ellcey writes:
> I have a question about the poly_uint64 type and the TYPE_VECTOR_SUBPARTS
> macro. I am trying to copy some code from i386.c into my aarch64 build
> that is basically:
>
> int n;
> n = TYPE_VECTOR_SUBPARTS (type_out);
>
> And it is not compiling for me, I get:
>
> /home/sel
Richard Biener writes:
> On Thu, Aug 31, 2017 at 1:41 PM, Aldy Hernandez wrote:
>> So ok to default to a lazy one, or are suggesting we leave things
>> as they are?
>
> Either leave as-is or default to the lazy one.
FWIW, I think we should leave it. The risk isn't just laziness:
it could ma
Richard Biener writes:
> On August 21, 2017 5:43:08 PM GMT+02:00, Aldy Hernandez
> wrote:
>>The attached patch fixes the problem by sign extending before
>>constructing the wide int. It does so while constructing the
>>hwi_with_prec object, since the int_traits
>>container has is_sign_extended
Richard Biener writes:
> On August 3, 2017 7:05:05 PM GMT+02:00, Richard Sandiford
> wrote:
>>Torvald Riegel writes:
>>> On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>>>> Torvald Riegel writes:
>>>> > On Wed, 2017-08-02 at 14:09 +0
Torvald Riegel writes:
> On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>> Torvald Riegel writes:
>> > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
>> >> (1) Does the approach seem reasonable?
>> >>
>> >>
Torvald Riegel writes:
> On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
>> (1) Does the approach seem reasonable?
>>
>> (2) Would it be acceptable in principle to add this extension to the
>> GCC C frontend (only enabled where necessary)?
>>
Hi Joseph,
Thanks for the quick feedback.
Joseph Myers writes:
> On Wed, 2 Aug 2017, Richard Sandiford wrote:
>
>> (1) Does the approach seem reasonable?
>>
>> (2) Would it be acceptable in principle to add this extension to the
>> GCC C frontend
Summary
===
This is an RFC about some C language changes to support ARM's Scalable
Vector Extension (SVE). A detailed description of SVE is available here:
https://static.docs.arm.com/ddi0584/a/DDI0584A_a_SVE_supp_armv8A.pdf
but the only feature that really matters for this RFC is that
Andrew Pinski writes:
> Hi,
> I was looking into why we don't produce fmls with a scalar register
> as the last argument but I found a difference in how fnma4 is
> described in RTL which I think is causing the missed optimization.
> Look at the scalar version:
>
> (define_insn "fnma4"
> [(set
Richard Sandiford writes:
> We have various other changes that aren't yet in the branch. The two
> main ones are:
>
> (a) Support for gather loads and scatter stores. This includes support
> for using gathers and scatters for strided loads and stores, or for
> g
Richard Biener writes:
> On Thu, Nov 17, 2016 at 11:00 PM, Richard Sandiford
> wrote:
>> Thanks for the comments.
>>
>> Richard Biener writes:
>>> On Fri, Nov 11, 2016 at 6:50 PM, Richard Sandiford
>>
Thanks for the comments.
Richard Biener writes:
> On Fri, Nov 11, 2016 at 6:50 PM, Richard Sandiford
>> Constructing variable-length vectors
>>
>>
>> Currently both tree and rtl vector constants require the number of
>> ele
This message describes the arrangement of the patches on the SVE branch.
We've tried to make them fit a plausible submission order, with each
patch having its own covering note and rationale (but no changelog :-)).
They should also be bisect-friendly.
The patches break down into the following broa
This message describes how the SVE patches implement full-loop
predication/masking. To give an example:
void
foo (int *restrict dst, int *restrict src, int count)
{
for (int i = 0; i < count; ++i)
dst[i] = src[i] + 1;
}
compiles to:
foo:
cmp w2, 0
ble .L1
m
As described in the covering note, one of big differences for SVE is that
things like mode sizes, offsets, and numbers of vector elements can depend
on a runtime parameter. This message describes how the SVE patches handle
that and how they deal with vector constants in which the number of element
Hi,
We'd like to submit GCC support for ARM's Scalable Vector Extension (SVE).
For more details about the extension itself, please see Nigel's blog post at:
https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architect
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
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
"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
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
"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
"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
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
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
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
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,
Umesh Kalappa writes:
> Hi All,
>
> I'm trying to fetch the string constant from the constant pool entry
> for the symbol_ref rtx like
>
> c sample
>
> int i;
> int main()
> {
> printf("%d",i);
> }
>
> rtl is
>
> (gdb) p debug_rtx(val)
> (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
The SYMBOL_REF_D
I have some plans to "clean up" the machine_mode handling and perhaps
make it hierarchical, so that functions that can only handle scalar
integer modes (say) will be able to take a scalar_int_mode rather than
a machine_mode as argument. The first step would be to do a blanket
removal of the (in C+
Rainer Orth writes:
>>> Apart from that, why are you invoking gcc with -x assembler-with-cpp
>>> when the input is clearly anything but assembler input? You're
>>> obviously lying to the compiler, and I'd go as far as claiming that you
>>> get what you deserve: garbage in, garbage out.
>>
>> :-)
Richard Biener writes:
> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni
> wrote:
>> Hi,
>>Sorry to ask a stupid question, but I am having issues writing patterns
>> involving casts. I am trying to write patterns from simplify_rotate.
>>
>> Could you show me how to write a patterns that
I'll need to step down as MIPS maintainer this weekend in order to avoid
a possible conflict of interest with a new job. SC: please could you
appoint some new maintainers to take over?
Matthew and Catherine (cc:ed) have been among the biggest contributors
to the MIPS port recently and they said t
Andreas Schwab writes:
> Richard Sandiford writes:
>> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
>> in the number stay the same but the meanings of __GNU_MINOR__ and
>> __GNU_PATCHLEVEL__ change.
>
> There is no change in meaning.
Sur
Sorry for the gdb/gcc crosspost, but can anyone offer any advice for
the situation Matthew describes in the message quoted below? We have
three ABIs:
(1) traditional o32 with 32-bit FP registers. The FP registers act as pairs
when storing doubles. Some architectures can only store one singl
Richard Biener writes:
> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
> wrote:
>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
>>>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
>>>>>
Richard Biener writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>>> On May 26, 2014, at 2:22 AM, FX wrote:
>>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>>> > compiler is clang-based). Since
Richard Sandiford writes:
> Gerald Pfeifer writes:
>> On Sat, 17 May 2014, Richard Sandiford wrote:
>>> To rule out one possibility: which GCC are you using for stage1?
>>
>> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
>> FreeBSD 8, 9 a
Gerald Pfeifer writes:
> On Sat, 17 May 2014, Richard Sandiford wrote:
>> To rule out one possibility: which GCC are you using for stage1?
>
> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
> FreeBSD 8, 9 and 10 all build fine on i386 (= i486) and amd64.
Gerald Pfeifer writes:
> On Sat, 10 May 2014, Gerald Pfeifer wrote:
>> Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
>> fail as follows:
>>
>> Comparing stages 2 and 3
>> warning: gcc/cc1obj-checksum.o differs
>> warning: gcc/cc1-checksum.o differs
>> warning: gcc
Ramana Radhakrishnan writes:
> On Wed, May 14, 2014 at 5:38 PM, Richard Sandiford
> wrote:
>> Hey, I resent that. You make it sound I came up with SCHED_PRESSURE_MODEL
>> on a whim without any evidence to back it up. I implemented it because
>> it gave better EEMBC res
Vladimir Makarov writes:
> On 2014-05-13, 6:27 AM, Kyrill Tkachov wrote:
>> Hi all,
>>
>> In haifa-sched.c (in rank_for_schedule) I notice that live range
>> shrinkage is not performed when SCHED_PRESSURE_MODEL is used and the
>> comment mentions that it results in much worse code.
>>
>> Could any
Jan-Benedict Glaw writes:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
>> > please hold off on committing patches for the next couple of hours
>> > as we have a very large merge to do.
>> > thanks.
>>
>> All done… It is in.
>
> Jus
Kyrill Tkachov writes:
> On 28/04/14 18:03, Kenneth Zadeck wrote:
>> At this point we have believe that we have addressed all of the concerns
>> that the community has made about the wide-int branch. We have also
>> had each of the sections of the branch approved by the area maintainers.
>>
>> W
Richard Biener writes:
> On Tue, 29 Apr 2014, Richard Sandiford wrote:
>
>> Kyrill Tkachov writes:
>> > On 28/04/14 18:03, Kenneth Zadeck wrote:
>> >> At this point we have believe that we have addressed all of the concerns
>> >> that the community
Kyrill Tkachov writes:
> On 28/04/14 18:03, Kenneth Zadeck wrote:
>> At this point we have believe that we have addressed all of the concerns
>> that the community has made about the wide-int branch. We have also
>> had each of the sections of the branch approved by the area maintainers.
>>
>> W
pshor...@dataworx.com.au writes:
> On 17.04.2014 13:00, Jeff Law wrote:
>> On 04/16/14 16:19, Richard Henderson wrote:
>>>
>>> The register allocators only select an alternative for a move. They
>>> do not
>>> choose between N different patterns, separately describing loads,
>>> stores, and
>>>
Umesh Kalappa writes:
> Richard ,
> Pmode is defined HImode and private target is 16 bit where int ,short
> and Pmode is defined HImode and long as SImode.
>
> Please do let me know if it requires more information on the target.
In that case I suggest you compile with -da and compare the .expa
pshor...@dataworx.com.au writes:
> Found it ...
>
> I had
>
> (define_expand "zero_extendhisi2"
> [
> (set (subreg:HI (match_operand:SI 0 "general_operand" "")0)
> (match_operand:HI 1 "general_operand" ""))
> (set (subreg:HI (match_dup 0)2)
>
Andrew Haley writes:
> On 04/10/2014 04:12 PM, Umesh Kalappa wrote:
>
>> Please somebody from the group can share their thoughts and will be
>> appricate the same.
>
> But unoptimized code is expected to be large. Why do you expect
> otherwise?
Sure, but this is a bit extreme. I don't see off-h
Michael Eager writes:
> On 04/06/14 05:29, Claudia Henriques wrote:
>> Hi everybody!
>>
>> My name is Claudia and I am currently working on my master's thesis.
>>
>> I am working with an embedded system, so part of my code will target
>> microblaze, while the remaining
>> code will target x86_64.
Richard Hulme writes:
> Is there any way of preventing the compiler going with the indirect
> alternative? Can a 'parallel' match be defined in the machine
> description that indicates the '(set (reg/f:HI...' should be discarded?
No, that wouldn't work. The register is only dead if both combi
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Hi Richard,
>> >
>> > As part of implementing the new O32 FPXX ABI I am making use of the
>> > HARD_REGNO_CALL_PART_CLOBBERED macro to allow odd-numbered
>
David Guillen writes:
> The thing is that I had a similar problem before with the "-m"
> parameter, which didn't had any parameter, therefore I used to had -m
> -dynamic-linker (which is wrong) and I fixed it by adding:
>
> -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \
> +#define LI
Matthew Fortune writes:
> Hi Richard,
>
> As part of implementing the new O32 FPXX ABI I am making use of the
> HARD_REGNO_CALL_PART_CLOBBERED macro to allow odd-numbered
> floating-point registers to be considered as 'normally' callee-saved
> but call clobbered if they are being used to hold SImo
dw writes:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement. Further, the compiler will not assume that any
> memory-based values read before the @code{asm} will remain unc
dw writes:
>> I think it really is general though. In:
>>> The same problem can occur if one output parameter (@var{a}) allows a
>>> register constraint, is updating the parameter value, and references an
>>> address while another output parameter (@var{b}) allows a memory
>>> constraint.
>
> Yep,
dw writes:
> On 3/25/2014 4:20 AM, Richard Sandiford wrote:
>> dw writes:
>>>> asm ("" : "=m" (*x), "=r" (y));
>>>>
>>>> you have to assume that the address in %0 might use the same register as %1
>>> Ok, no
Matthew Fortune writes:
> Joseph Myers writes:
>> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>>
>> > Hi Richard, we talked about (a.) originally - it was the design of the
>> > libraries. Joseph, as I recollect, you raised language issues with
>> > requirements for compile-time constant values for
dw writes:
>>asm ("" : "=m" (*x), "=r" (y));
>>
>> you have to assume that the address in %0 might use the same register as %1
>
> Ok, now I'm getting there. It helps that I've compiled some examples
> and can see what is happening. This one is subtle. I'm going to have
> to go back and r
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Maciej W. Rozycki writes:
>> >> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>> >>
>> >> > > Thanks Joseph. I guess I'm not really pushing
"Maciej W. Rozycki" writes:
> What I'm concerned the most about is the matter is so obscure to people
> outside a narrow group of hardware/kernel/toolchain/library experts (that
> regrettably does not include distribution packagers) that once that "don't
> care" approach is set in the environm
Matthew Fortune writes:
> Maciej W. Rozycki writes:
>> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>>
>> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
>> > > supported as it would take a lot of effort to determine whe
Sorry for the slow response.
dw writes:
> On 3/3/2014 3:36 AM, Richard Sandiford wrote:
>> Well, like you say, things can be moved across branches. So, although
>> this is a very artificial example:
>>
>> asm ("x");
>> asm ("y")
"Thomas Preud'homme" writes:
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>>
>> "Thomas Preud'homme" writes:
>>
>> -mno-float causes gcc to define the macro __mips_no_float, which the
>> implementation can u
Matthew Fortune writes:
> Thanks Joseph. I guess I'm not really pushing to have don't-care
> supported as it would take a lot of effort to determine when code does
> and does not care, you rightly point out more cases to deal with
> too. I'm not sure if the benefit would then be worth it or not as
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Richard Sandiford writes:
>> >> Matthew Fortune writes:
>> >> > As it stands I wasn't planning on supporting .module arch= I was
>> >> > j
Umesh Kalappa writes:
> Hi All ,
>
> We are porting gcc4.8.1 to the new target and we created the new
> .rodata section w.r.t flags by get_unnamed_section() .
>
> Now we need to associate the global %object data of type .word or
> .byte to the created .rodata section and also we need to emit
Richard Sandiford writes:
> What DJ meant below was that you should reject all pseudo registers
> if strict_p. I.e. REG_P (foo) should be:
>
>REG_P (foo) && (!strict_p || REGNO_MODE_OK_FOR_BASE_P (foo, mode))
sorry:
REG_P (foo) && (!strict_p || REGNO_MODE_OK_F
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > As it stands I wasn't planning on supporting .module arch= I was just
>> > going to add .module fp= and leave it at that. The only thing I need
>> > to give assembly
"Thomas Preud'homme" writes:
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>>
>> -mno-float as it stands today is really just -msoft-float with some
>> floating-point support removed from the library to save space.
>> One of the
David Guillen writes:
> So far I'm still facing problems regarding memory addresses even with
> the most restrictive conditions. The non-recognized instruction is:
>
> ../../../libgcc/libgcc2.c: In function '__muldi3':
> ../../../libgcc/libgcc2.c:559:1: error: insn not satisfying its restrictions
Matthew Fortune writes:
> As it stands I wasn't planning on supporting .module arch= I was just
> going to add .module fp= and leave it at that. The only thing I need to
> give assembly code writers absolute control over is the overall FP mode
> of the module. I don't currently see any real need t
Matthew Fortune writes:
>> > With these defaults, the closest supported ABI is used for each
>> > architecture based on the --with-o32-fp build option. The only one I
>> > really care about is the middle one as it makes full use of the O32
>> > FPXX ABI without a user needing to account for arch r
Matthew Fortune writes:
> The spec on:
> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
> has been updated and attempts to account for all the feedback. Not
> everything has been possible to simplify/rework as requested but I
> believe I have managed to address many point
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> >> I think instead we should have a configuration switch that allows a
>> >> particular -mfp option to be inserted alongside -mabi=32 if no
>> >> explicit -mfp is
Returning to this old thread...
Richard Sandiford writes:
> Tejas Belagod writes:
>> When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
>> gcc.c-torture/execute/copysign1.c generates incorrect code because LRA
>> cannot
>> seem to handle subregs like
Matthew Fortune writes:
>> I think instead we should have a configuration switch that allows a
>> particular -mfp option to be inserted alongside -mabi=32 if no explicit
>> -mfp is given. This is how most --with options work. Maybe --with-fp-
>> 32={32|64|xx}? Specific triples could set a defau
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Are you're OK with automatically selecting fpxx if no -mfp option, no
>> > .module and no .gnu_attribute exists? Such code would currently end up
>> > as FP ABI Any eve
Matthew Fortune writes:
> Are you're OK with automatically selecting fpxx if no -mfp option, no
> .module and no .gnu_attribute exists? Such code would currently end up
> as FP ABI Any even if FP code was present, I don't suppose anything
> would get worse if this existing behaviour simply continu
Matthew Fortune writes:
>> Matthew Fortune writes:
>> >> > Sorry, forgot about that. In that case maybe program headers would
>> >> > be best, like you say. I.e. we could use a combination of GNU
>> >> > attributes and a new program header, with the program header
>> >> > hopefully being more g
Thomas Preudhomme writes:
>> I think the ability to detect the case of generating ABI agnostic
>> code would be useful for other architectures too.
>
> I do not know the other architecture to know if that is the case but
> according to what you said for MIPS it seems to be the case. Right now I
Matthew Fortune writes:
>> > Sorry, forgot about that. In that case maybe program headers would be
>> > best, like you say. I.e. we could use a combination of GNU attributes
>> > and a new program header, with the program header hopefully being more
>> > general than for just this case. I suppo
dw writes:
> On 2/27/2014 11:32 PM, Richard Sandiford wrote:
>> dw writes:
>>> On 2/27/2014 4:11 AM, Richard Sandiford wrote:
>>>> Andrew Haley writes:
>>>>> Over the years there has been a great deal of traffic on these lists
>>>>> ca
Andrew Bennett writes:
> Hi,
>
> I have noticed that a patch was placed in bugzilla to do this change, but it
> does not appear to have been pushed. I was wondering if anyone could comment
> why this is the case?
>
> The bugzilla URL is the following:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi
Georg-Johann Lay writes:
> Notice that in code1, func might contain such asm-pairs to implement
> atomic operations, but moving costly_func across func does *not*
> affect the interrupt respond times in such a disastrous way.
>
> Thus you must be *very* careful w.r.t. optimizing against asm volati
Eric Botcazou writes:
>> One of the big grey areas is what should happen for floating-point ops
>> that depend on the current rounding mode. That isn't really modelled
>> properly yet though. Again, it affects calls as well as volatile asms.
>
> There is an explicit comment about this in the sch
dw writes:
> On 2/27/2014 4:11 AM, Richard Sandiford wrote:
>> Andrew Haley writes:
>>> Over the years there has been a great deal of traffic on these lists
>>> caused by misunderstandings of GCC's inline assembler. That's partly
>>> be
Yury Gribov writes:
> Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
>>>
>>> That could
101 - 200 of 549 matches
Mail list logo
