Hi
Please ignore the previous mail.
在 2019/3/1 下午10:17, Segher Boessenkool 写道:
Hi!
On Fri, Mar 01, 2019 at 04:39:38PM +0800, JunMa wrote:
Since MAX_INLINE_INSNS_AUTO should be below or equal to
MAX_INLINE_INSNS_SINGLE (see params.def), there is no need
to do second inlining limi
--
发件人：Segher Boessenkool
发送时间：2019年3月1日(星期五) 22:18
收件人：JunMa
抄 送：gcc-patches
主 题：Re: [PATCH GCC10] ipa-inline.c: Trivial fix on function not declared inline
check in want_inline_small_function_p
Hi!
On Fri, Mar 01, 2019 at 04:3
Ping:
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01949.html
Thanks
Xionghu
On 2019/2/26 AM9:13, luo...@linux.ibm.com wrote:
> From: Xiong Hu Luo
>
> dfp printf/scanf of Ha/HA, Da/DA and DDa/DDA is not set properly, cause
> incorrect warning happens:
> "use of 'D' length modifier with 'a' typ
On Mon, 4 Mar 2019 at 01:26, Ville Voutilainen
wrote:
> I consider variant to no longer be in the state of sin after this.
Sigh, except for the places where it self-destructs or placement-news
over things that it shouldn't. That's hopefully
the next bit that I'll rectify, Real Soon Now.
On Wed, 6 Feb 2019 at 15:12, Ville Voutilainen
wrote:
> And, to emphasize, the most important reason for this was to be able
> to write straightforward
> code for the special member functions, with the hope that it wouldn't
> have a negative codegen
> effect. Our Microsoft friends described the g
PR libstdc++/89562
* src/filesystem/ops-common.h (do_copy_file): Open files in binary
mode for mingw.
Tested x86_64-linux, and lightly tested on mingw-w64 to verify the fix
works.
commit b15e67df3477fac3fea5a3df234be91391719fcd
Author: Jonathan Wakely
Date: Sun Mar 3
On Sun, Mar 3, 2019 at 10:18 PM H.J. Lu wrote:
>
> On Sun, Mar 3, 2019 at 9:27 AM Uros Bizjak wrote:
> >
> > On Thu, Feb 28, 2019 at 8:10 PM H.J. Lu wrote:
> > >
> > > 32-bit indices in VSIB address are sign-extended to 64 bits. In x32,
> > > when 32-bit indices are used as addresses, like in
>
On Sun, Mar 3, 2019 at 9:27 AM Uros Bizjak wrote:
>
> On Thu, Feb 28, 2019 at 8:10 PM H.J. Lu wrote:
> >
> > 32-bit indices in VSIB address are sign-extended to 64 bits. In x32,
> > when 32-bit indices are used as addresses, like in
> >
> > vgatherdps %ymm7, 0(,%ymm9,1), %ymm6
> >
> > 32-bit ind
ld/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -O2 -S
bar.i
[hjl@gnu-cfl-2 pr88828]$ cat bar.s
.file "bar.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.
The return value specified in "8.1.2 associated Legendre polynomials"
of ISO/IEC JTC 1/SC 22/WG 21 N3060 (which is identical to the
expression in the doxygen comment of the patched function) is well-
defined for m>l: it is always zero because $ P_l(x) $ is a polynomial
of degree l.
The standard do
I didn't see any disagreement, so committed to trunk (rev.269353)
and "backported" to 7- and 8-branches.
Thanks,
Harald
On 03/02/19 00:15, Steve Kargl wrote:
> On Sat, Mar 02, 2019 at 12:12:10AM +0100, Harald Anlauf wrote:
>> The attached patch (originally by Steve Kargl) fixes a NULL pointer
>>
Hello all,
I wanted to ask for some feedback on an issue which has affected GDC
for a long time now: Letting the D garbage collector scan
emulated TLS memory. Basically, for every variable instance in TLS
memory we need to be able to get the address and size of that instance,
so the GC can scan th
On Thu, Feb 28, 2019 at 8:10 PM H.J. Lu wrote:
>
> 32-bit indices in VSIB address are sign-extended to 64 bits. In x32,
> when 32-bit indices are used as addresses, like in
>
> vgatherdps %ymm7, 0(,%ymm9,1), %ymm6
>
> 32-bit indices, 0xf7fa3010, is sign-extended to 0xf7fa3010 which
> is i
)
,On Sun, Mar 3, 2019 at 6:32 AM H.J. Lu wrote:
>
> For vector init constructor:
>
> ---
> typedef float __v4sf __attribute__ ((__vector_size__ (16)));
>
> __v4sf
> foo (__v4sf x, float f)
> {
> __v4sf y = { f, x[1], x[2], x[3] };
> return y;
> }
> ---
>
> we can optimize vector init construc
For vector init constructor:
---
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
__v4sf
foo (__v4sf x, float f)
{
__v4sf y = { f, x[1], x[2], x[3] };
return y;
}
---
we can optimize vector init constructor with vector copy or permute
followed by a single scalar insert:
__v4sf
Hi Thomas,
This is good for trunk.
Thanks
Paul
On Sun, 3 Mar 2019 at 09:46, Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes a 7/8/9 regression by rejecting an invalid
> expression in coarray allocation that led to an ICE. It also adds a few
> more checks.
>
> One point that
We set __USE_MINGW_ACCESS for windows hosts to use MinGWs wrapper
for the access function. The wrapper ensures that access behaves
in the expected way (e.g. for special files, such as nul).
However, we now compile most sources with the C++ compiler and
the __USE_MINGW_ACCESS in CFLAGS is not used t
I wrote:
First, this talks about a C pointer having a target. Second, you can
re-estabilsh the association to a different pointer to the Fortran
program.
There is another point to consider: This is interoperability with C
we are dealing with, so we also have to follow C semantics.
And, love i
Hello world,
the attached patch fixes a 7/8/9 regression by rejecting an invalid
expression in coarray allocation that led to an ICE. It also adds a few
more checks.
One point that is checked for is that, unlike normal arrays, coarrays
cannot be empty.
Regression-tested. OK for trunk and affec
19 matches
Mail list logo
