Hi,
Some platforms, such as Blackfin, have a special prefix for assembly
symbols as opposed to C symbols. For this reason, a function named
"foo()" in C will in fact be visible as a symbol called "_foo" in the
ELF binary.
The current linker version script logic in libgcc doesn't take into
account
ping!
2016-11-19 10:12 GMT+01:00 Janus Weil :
> Hi all,
>
>> I previously assumed that the test case for this PR would be legal,
>> but by now I think that's wrong. The test case should be rejected, and
>> we already have checking mechanisms for this (see
>> resolve_fl_variable), but apparently t
On 11/24/2016 03:32 PM, Segher Boessenkool wrote:
On Thu, Nov 24, 2016 at 10:14:24AM -0600, Segher Boessenkool wrote:
On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote:
On 11/24/2016 07:53 AM, Segher Boessenkool wrote:
That we compare different kinds of costs (which really has no meani
On 25 November 2016 at 14:48, Richard Biener wrote:
> On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 25 November 2016 at 13:43, Richard Biener wrote:
>> > On Fri, 25 Nov 2016, Jakub Jelinek wrote:
>> >
>> >> On Fri, Nov 25, 2016 at 01:28:06PM +0530, Prathamesh Kulkarni wrote:
>> >> > ---
> From my investigations on the m68k, the effects on the IL are minimal
> with a slight bias towards better code (by suppressing if-conversions of
> some now more costly blocks). *But* the size of the resulting code was
> all over the place -- sometimes it was better, others worse. From
> lookin
On 22 November 2016 at 17:06, Jonathan Wakely wrote:
>> so I can certainly change all these swaps to use operator! rather than
>> __not_. Is the
>> patch otherwise ok for trunk? What about the tuple part?
>
>
> Yes, OK changing the top-level __not_s to operator!
> I haven't reviewed the tuple part
If there is no objection, I’ll commit the following patch
--- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0
+0100
+++ gcc/fortran/intrinsic.texi 2016-11-26 16:47:12.0 +0100
@@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne
seconds
@item Minute
2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
> If there is no objection, I’ll commit the following patch
Looks good to me!
If you want, you could also fix the remaining items I mentioned in
comment 1 in the PR:
* apply the same fix to GMTIME
* fix it in the libgfortran sources as well
* poss
And one last point: The description of LTIME mentions TIME8, but if I try this:
call ltime(time8(), values)
I get:
Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4
So maybe the reference to TIME8 should be replaced by TIME?
Cheers,
Janus
2016-11-26 16:54 GMT+01:00 Janu
On 11/26/2016 04:11 AM, Eric Botcazou wrote:
From my investigations on the m68k, the effects on the IL are minimal
with a slight bias towards better code (by suppressing if-conversions of
some now more costly blocks). *But* the size of the resulting code was
all over the place -- sometimes it w
Dominique,
your patch sounds good to me.
2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
> If there is no objection, I’ll commit the following patch
>
> --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0
> +0100
> +++ gcc/fortran/intrinsic.texi 2016-11-26 16:47:12.0
> Le 26 nov. 2016 à 16:54, Janus Weil a écrit :
>
> 2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
>> If there is no objection, I’ll commit the following patch
>
> Looks good to me!
>
> If you want, you could also fix the remaining items I mentioned in
> comment 1 in the PR:
> * apply the s
> Le 26 nov. 2016 à 17:00, Janus Weil a écrit :
>
> And one last point: The description of LTIME mentions TIME8, but if I try
> this:
>
> call ltime(time8(), values)
>
> I get:
>
> Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4
Well LTIME cannot accept both kind(4) an
> Le 26 nov. 2016 à 10:45, Janus Weil a écrit :
>
> ping!
>
The patch is working has expected. Note the removed block has been introduced
by Daniel Franke at r126826.
Dominique.
>> * possibly add some more cross-links to intrinsic.texi
>
> Could you please elaborate?
I just mean it might be useful to add some more links from LTIME to
ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very
similar.
>> And one last point: The description of LTIME mentions TIME8
2016-11-26 17:58 GMT+01:00 Janus Weil :
>>> * possibly add some more cross-links to intrinsic.texi
>>
>> Could you please elaborate?
>
> I just mean it might be useful to add some more links from LTIME to
> ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very
> similar.
Sorry, I meant
On Sat, Nov 26, 2016 at 7:03 PM, Janus Weil wrote:
> 2016-11-26 17:58 GMT+01:00 Janus Weil :
* possibly add some more cross-links to intrinsic.texi
>>>
>>> Could you please elaborate?
>>
>> I just mean it might be useful to add some more links from LTIME to
>> ITIME, IDATE and DATE_AND_DATE (
Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference
to TIME8 looks like a mistake, isn’t it?
>>>
>>> Huh, in libgfortran I see two versions with different kinds (ltime_i4
>>> and ltime_i8), but in my tests I never get LTIME to work with kind=8
>>> arguments. I gues
On Sat, Nov 26, 2016 at 03:44:22AM -0700, Jeff Law wrote:
> On 11/24/2016 03:32 PM, Segher Boessenkool wrote:
> >On Thu, Nov 24, 2016 at 10:14:24AM -0600, Segher Boessenkool wrote:
> >>On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote:
> >>>On 11/24/2016 07:53 AM, Segher Boessenkool wrote:
>
2016-11-26 17:37 GMT+01:00 Dominique d'Humières :
>
>> Le 26 nov. 2016 à 10:45, Janus Weil a écrit :
>>
>> ping!
>>
> The patch is working has expected. Note the removed block has been introduced
> by Daniel Franke at r126826.
Right, thanks for the reference. I think that commit is plain wrong,
On 11/25/2016 10:20 AM, Jakub Jelinek wrote:
Hi!
Here is an attempt to fix a couple of bugs in gimple-ssa-sprintf.c.
First of all, it assumes size_t is always the same as uintmax_t, which
is not necessarily the case.
Second, it uses static tree {,u}intmax_type_node; variables for caching
those t
> Still, since we internally already have both implementations for
> kind=4 and kind=8, we could as well make use of them, I guess.
I let this for people understanding what to do.
> If not, we definitely need to fix the documentation of LTIME, since
> the current version simply does not work wi
>> If not, we definitely need to fix the documentation of LTIME, since
>> the current version simply does not work with TIME8(), unless one uses
>> -fdefault-integer-8 (which is not mentioned in the docu).
>
> What about the attached patch
Yes, looks good to me. Ok to commit!
One minor nit (optio
On Tue, Nov 1, 2016 at 11:08 AM, Andrew Pinski wrote:
> On Tue, Nov 17, 2015 at 2:10 PM, Andrew Pinski wrote:
>> Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2 (variant
>> 1)
>> is an ARMv8.1 part, I needed to add detecting of the variant also for this
>> difference. Also I s
On Sat, Nov 26, 2016 at 09:15:48AM -0700, Jeff Law wrote:
> On 11/26/2016 04:11 AM, Eric Botcazou wrote:
> >> From my investigations on the m68k, the effects on the IL are minimal
> >>with a slight bias towards better code (by suppressing if-conversions of
> >>some now more costly blocks). *But* t
Use the recently introduced unaligned variant of __m128i and add a similar
__m64 and use those to make it clear these two intrinsics require neither 128-
bit nor 64-bit alignment.
`Allan
Index: gcc/config/i386/emmintrin.h
===
--- gcc
In code like the following from KVM:
/* it is a read fault? */
error_code = (exit_qualification << 2) & PFERR_FETCH_MASK;
it would be nicer to write
/* it is a read fault? */
error_code = (exit_qualification & VMX_EPT_READ_FAULT_MASK) ?
PFERR_FETCH_MASK : 0;
ins
change_zero_ext handles (zero_extend:M1 (subreg:M2 (reg:M1) ...))
already; this patch extends it to also deal with any
(zero_extend:M1 (subreg:M2 (reg:M3) ...)) where the subreg is not
paradoxical.
Tested on powerpc64-linux. This is needed for some of the rlwimi
testcases to be optimised properly
On Sat, 26 Nov 2016, Allan Sandfeld Jensen wrote:
Use the recently introduced unaligned variant of __m128i and add a similar
__m64 and use those to make it clear these two intrinsics require neither 128-
bit nor 64-bit alignment.
Thanks for doing this. You'll want Uros or Kirill to review your
simplify_truncation changes the truncation of many operations into
the operation on the truncation. This patch makes this code also
handle extracts.
Tested on powerpc64-linux. With this patch the rlwimi testcases work.
Is this okay for trunk?
Segher
---
gcc/simplify-rtx.c | 30
On Sat, 26 Nov 2016, Paolo Bonzini wrote:
--- match.pd(revision 242742)
+++ match.pd(working copy)
@@ -2554,6 +2554,19 @@
(cmp (bit_and@2 @0 integer_pow2p@1) @1)
(icmp @2 { build_zero_cst (TREE_TYPE (@0)); })))
+/* If we have (A & C) != 0 ? D : 0 where C and D are powers of 2,
+ c
Also see discussions from libstdc++/71500.
Bootstrapped and tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 6c862a2b84578a651d458b09572551c8391082e4
Author: Tim Shen
Date: Sat Nov 26 12:36:20 2016 -0800
2016-11-26 Tim Shen
PR libstdc++/71500
On Sat, Nov 26, 2016 at 11:22:44PM +0100, Paolo Bonzini wrote:
> The combine.c hunk instead is needed to simplify cases that do not use the
> ternary operator (the "h" and "i" functions in the testcases) like this:
>
> return ((x >> 9) & 1) << 7;
>
> Normally this is simplified just fine to
On 11/25/2016 12:51 PM, Jeff Law wrote:
On 11/23/2016 06:15 PM, Martin Sebor wrote:
gcc_assert works only in some instances (e.g., in c-ada-spec.c:191)
but not in others because some actually do make the alloca(0) call
at runtime: at a minimum, lto.c:3285, reg-stack.c:2008, and
tree-ssa-threade
This 4-patch series contains the following in order:
a.diff: Remove uses-allocator ctors. They are going away, and removing
it reduces the maintenance burden from now on.
b.diff: Add constexpr support for get<> and comparisons. This patch
also involves small refactoring of _Variant_storage.
c.di
35 matches
Mail list logo
