I have a question about *unfused* fma instructions. MIPS has processors
with both fused and unfused multiple and add instructions and for fused
madd's it is clear what to do; define 'fma' instructions in the md file
and let convert_mult_to_fma decide whether or not to use them.
But for non-fused
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote:
>
> ...
> Regardless, the right thing to do is to disable elimination of NULL pointer
> checks on targets where page 0 is mapped and thus a reference to *0 may not
> fault. In my mind this is an attribute of both the processor (see H8 above)
>
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote:
>
> On 02/20/15 04:43, Jonathan Wakely wrote:
>>> ...
>>
>> I'm inclined to agree.
>>
>> Most developers aren't aware of the preconditions on memcpy, but GCC
>> optimizes aggressively based on those preconditions, so we have a
>> large and potent
On 02/20/15 10:09, Florian Weimer wrote:
On 02/20/2015 06:01 PM, Jeff Law wrote:
But that's always true -- this isn't any different than aliasing,
arithmetic overflow, etc. The standards define the contract between the
compiler/library implementors and the developers. Once the contract is
bro
On 02/19/15 14:56, Chris Johns wrote:
On 20/02/2015 8:23 am, Joel Sherrill wrote:
On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
Jakub Jelinek wrote:
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
Starting with gcc 4.9, -O2 implicitly invokes
-fisolate-erroneous-paths-de
On 02/20/15 04:43, Jonathan Wakely wrote:
On 20 February 2015 at 11:06, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E.g., using memcpy (either explicitly or
implicitly
On 02/20/2015 06:01 PM, Jeff Law wrote:
> But that's always true -- this isn't any different than aliasing,
> arithmetic overflow, etc. The standards define the contract between the
> compiler/library implementors and the developers. Once the contract is
> broken, all bets are off.
What I don't
On 02/20/15 05:10, Jakub Jelinek wrote:
On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E.g., using memcpy (either explicitly or
i
On 02/20/15 04:06, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E.g., using memcpy (either explicitly or
implicitly for a structure copy)?
The memcpy problem isn't rest
On 02/20/15 04:45, Florian Weimer wrote:
On 02/20/2015 10:30 AM, Andrew Haley wrote:
I doubt that such a thing is ever going to be safe. The idea that a
null pointer points to nothing is so hard-baked into the design of C
that you can't get away from it. Also, almost every C programmer and
esp
On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
The section "Pointer Bounds Checker builtins" in extend.texi is on my list
for being in need of copy-editing, but reading through the existing text, I
am quite confused. In several places it refers to turn
We are pleased to announce the release of GNU MPC 1.0.3 "Fagus silvatica".
GNU MPC is a C library for the arithmetic of complex numbers with
arbitrarily high precision and correct rounding of the result.
This release contains two bug fixes backported from the trunk:
- Fixed mpc_pow, see
http
On Fri, Feb 20, 2015 at 5:51 AM, Martin Jambor wrote:
> Hi,
>
> I have spent quite some time trying to build an x32 gcc to debug a PR
> this week before I finally found the configure switch that made
> everything work. In order to share this possibly valuable knowledge,
> I have created a wiki mi
Hi,
I have spent quite some time trying to build an x32 gcc to debug a PR
this week before I finally found the configure switch that made
everything work. In order to share this possibly valuable knowledge,
I have created a wiki mini-page detailing how I managed to get it
finally working:
https:
On 02/20/2015 11:06 AM, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>> H, Passing the additional option in user code would be one thing,
>> but what about library code? E.g., using memcpy (either explicitly or
>> implicitly for a structure copy)?
>
> The memcpy pr
On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
> > H, Passing the additional option in user code would be one thing,
> > but what about library code? E.g., using memcpy (either explicitly or
> > implicitly for a structure copy
On 02/20/2015 12:43 PM, Jonathan Wakely wrote:
> On 20 February 2015 at 11:06, Florian Weimer wrote:
>> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>>> H, Passing the additional option in user code would be one thing,
>>> but what about library code? E.g., using memcpy (either explicitly
On 02/20/2015 10:30 AM, Andrew Haley wrote:
> I doubt that such a thing is ever going to be safe. The idea that a
> null pointer points to nothing is so hard-baked into the design of C
> that you can't get away from it. Also, almost every C programmer and
> especially library writer "knows" that
On 20 February 2015 at 11:06, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>> H, Passing the additional option in user code would be one thing,
>> but what about library code? E.g., using memcpy (either explicitly or
>> implicitly for a structure copy)?
>
> The memc
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
> H, Passing the additional option in user code would be one thing,
> but what about library code? E.g., using memcpy (either explicitly or
> implicitly for a structure copy)?
The memcpy problem isn't restricted to embedded architectures.
si
;; Crude Advanced SIMD approximation.
(define_insn_reservation "cortex_53_advsimd" 4
(and (eq_attr "tune" "cortexa53")
(eq_attr:q "is_neon_type" "yes"))
"cortex_a53_simd0")
Does it mean that all AdvSIMD ins
On 18/02/15 19:21, Jeff Prothero wrote:
> BTW, I'd also be curious to know what is regarded as engineering
> best practice for writing a value to address zero when this is
> architecturally required by the hardware platform at hand.
> Obviously one can do various things to obscure the process
> su
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
> The section "Pointer Bounds Checker builtins" in extend.texi is on my list
> for being in need of copy-editing, but reading through the existing text, I
> am quite confused. In several places it refers to turning the Pointer
> Bounds Checker off, but
23 matches
Mail list logo
