On Mon, Aug 10, 2020 at 10:41 PM Kewen.Lin wrote:
>
> Hi Bin,
>
> on 2020/8/10 下午8:38, Bin.Cheng wrote:
> > On Mon, Aug 10, 2020 at 12:27 PM Kewen.Lin wrote:
> >>
> >> Hi Bin,
> >>
> >> Thanks for the review!!
> >>
> >> on 2020/8/8 下午4:01, Bin.Cheng wrote:
> >>> Hi Kewen,
> >>> Sorry for the
On Tue, Jul 28, 2020 at 10:13:31PM +0100, Roger Sayle wrote:
[ You attached something binary, which makes it hard to reply to. ]
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr96298.c
> @@ -0,0 +1,19 @@
> +/* PR rtl-optimization/96298 */
> +/* { dg-do run } */
> +/* { dg-options "-O2
Hi!
On Sun, Jul 19, 2020 at 10:42:16AM +0100, Roger Sayle wrote:
> This patch to simplify-rtx.c
> simplifies (sign_extend:HI (truncate:QI (?shiftrt:HI x 8))) to just
> (ashiftrt:HI x 8), as the inner shift already sets the high bits
> appropriately.
> The one oddity of the patch is that it tests
Hi!
On Sat, Aug 15, 2020 at 12:10:42PM +0100, Roger Sayle wrote:
> I'll quote Joseph Myers (many thanks) who describes things clearly as:
> > (a) When both arguments are NaNs, the return value should be a qNaN,
> > but sometimes it is an sNaN if at least one argument is an sNaN.
Where is this
for bitfield MEMREFs
[FIX] Propagate uncached type attributes to unaligned/packed types
[ARC] Update tests
gcc/
-xx-xx Petro Karashchenko
* emit-rtl.c (adjust_address_1): Do not drop the object
if the new memory reference is outside the underlying
object to
On 8/14/20 10:43 PM, Alexandre Oliva wrote:
On Aug 14, 2020, Nathan Sidwell wrote:
Since you don't seem to have liked 'aka' either, how about 'nickname',
or 'nicknamed'? A more convenient name to refer to an entity is exactly
what this is about, eh?
I'm sorry, I think those are awful
Hi,
the change looks good to me, OK for master.
Regards
Thomas
This arose from work by Sandra on "Unify C and C++ handling of loops and
switches"
Kind regards,
Toon.
Forwarded Message
Subject: [PATCH V2 3/4] Work around bootstrap failure in Fortran front end.
HI Alexandre
I don’t want to derail the discussion - but FIO mostly….
Alexandre Oliva wrote:
On Aug 15, 2020, Iain Sandoe wrote:
* if the target ABI does not support symbol aliases, then this facility
cannot
be used.
True. I'm surprised there are modern platforms that don’t.
On Aug 15, 2020, Iain Sandoe wrote:
> what about annotating the import pragma in some way such that the platform
> mangling is applied by the compiler?
Oh, one more thing about this.
Requiring all names to be given in canonical form might alleviate some
of the problems I raised, since it would
On Aug 15, 2020, Iain Sandoe wrote:
> * if the target ABI does not support symbol aliases, then this facility
> cannot
>be used.
True. I'm surprised there are modern platforms that don't.
What is it that stands in the way? Lack of support for .set in the
assembler? If that's the case,
Hi Martin,
On Sat, 15 Aug 2020 at 01:14, Martin Sebor via Gcc-patches
wrote:
>
> On 8/13/20 11:44 AM, Martin Sebor wrote:
> > On 8/13/20 10:21 AM, Jeff Law wrote:
> >> On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
> >>> The folders for these functions (and some others)
On Sat, 15 Aug 2020 at 00:52, David Malcolm wrote:
>
> PR testsuite/96609 and PR analyzer/96616 report various testsuite
> failures seen on powerpc64, aarch64, and arm in new tests added by
> r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d.
>
> Some of these failures (in
On Sat, Aug 15, 2020 at 11:09:17AM +0100, Roger Sayle wrote:
> +/* Recognize ((T)bswap32(x)<<32)|bswap32(x>>32) as bswap64(x). */
> +(simplify
> + (bit_ior:c
Any reason for supporting bit_ior only? Don't plus:c or bit_xor:c
work the same (i.e. use (for op (bit_ior bit_xor plus) ...)?
The following patches are still awaiting review (longer than a week or two).
gfortran: Improve translation of POPPAR intrinsic
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548055.html
PR middle-end/90597: gcc_assert ICE in layout_type
The motivation for this patch is PR middle-end/85811, a wrong-code
regression entitled "Invalid optimization with fmax, fabs and nan".
The optimization involves assuming max(x,y) is non-negative if (say)
y is non-negative, i.e. max(x,2.0). Unfortunately, this is an invalid
assumption in the
Hi Marc,
Here's version #2 of the patch to recognize bswap32 and bswap64
incorporating your
suggestions and feedback. The test cases now confirm the transformation is
applied
when int is 32 bits and long is 64 bits, and should pass otherwise; the
patterns now
reuse (more) capturing groups, and
Hi Alexandre,
I built the patch on x86_64-linux and darwin*** (fwiw).
* It’s firmly agreed that there are times when referring to C++ mangled names
is less than ideal.
* IIUC, the objective is to have a short-hand way of annotating an export
from
C++ so that it’s (a) more human-readable
17 matches
Mail list logo
