On Tue, 19 May 2020 at 11:44, Martin Liška wrote:
>
> Hello.
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of
On Tue, 19 May 2020 at 23:19, Jonathan Wakely wrote:
>
> On Tue, 19 May 2020 at 11:44, Martin Liška wrote:
> >
> > Hello.
> >
> > We've just installed server git hooks that verify git messages
> > for a correct ChangeLog format. For a limited time period, please
> > still apply ChangeLog changes
On 5/19/20 3:03 PM, Segher Boessenkool wrote:
This is a compile test, so it does not matter at all what the kernel is
doing or not doing. And the -mcpu=power8 flag should enable altivec.
Apparently it doesn't for you, but why is that?
It's likely the specs file we use for the kernel we are
It's not difficult for multiple threads to drain the entropy available
to the RDSEED instruction, at which point we throw an exception. This
change will try to use RDRAND after RDSEED fails repeatedly, and only
throw if RDRAND also fails repeatedly. This doesn't guarantee a random
value can always
On Mon, Apr 27, 2020 at 2:22 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> The code change that caused this regression was not meant to affect neon
> code-gen, however I missed the REG fall through. This patch makes sure
> we only get the left-hand of the PLUS if it is indeed a PLUS expr.
>
> I sugg
On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote:
> On 5/16/20 6:34 PM, Marek Polacek wrote:
> > Since GCC 9, C++17 support is no longer experimental. It was too late
> > to change the default C++ dialect to C++17 in GCC 10, but I think now
> > it's time to pull the trigger (C++14 was
On Tue, May 19, 2020 at 2:07 PM Uros Bizjak wrote:
>
> On Tue, May 19, 2020 at 9:58 PM H.J. Lu wrote:
> >
> > On Mon, May 18, 2020 at 10:56 PM Uros Bizjak wrote:
> > >
> > > On Tue, May 19, 2020 at 4:17 AM H.J. Lu wrote:
> > > >
> > > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu wrote:
> > > > >
Apologies on this test, the problem is -mdejagnu-cpu doesn't get matched
by the spec logic
If I pass -mcpu=power8, then indeed the test passes fine.
I'm not sure how to fix this cleanly.
Update VPCLMULQDQ check to support processors with AVX version of
VPCLMULQDQ.
PR target/91695
* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
check.
---
libgcc/config/i386/cpuinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/li
After enabling sanitization of the specialization tables, we are
triggering one of the hash table sanity checks in the below testcase.
The reason is that when looking up the specialization j in the
type_specializations table, the sanity check finds that the existing
entry j::m> compares equal to j
Hi,
In r10-4525, and r10-4161, loop unroller was enabled for simply loops at -O2.
At the same time, the GIMPLE cunroll is also enabled, while it is not only for
simple loops. This patch introduces a hook to check if a loop is suitable to
unroll completely. The hook can be used to check if a loop
Hi,
This patch check the size of a loop to be unrolled/peeled completely,
and set the limits to a number (24). This prevents large loop from
being unrolled, then avoid binary size increasing, and this limit keeps
performance.
Bootstrap®test pass on powerpc64le, ok for trunk?
Jiufu
---
gcc/con
Jiufu Guo writes:
> Hi,
>
> This patch check the size of a loop to be unrolled/peeled completely,
> and set the limits to a number (24). This prevents large loop from
> being unrolled, then avoid binary size increasing, and this limit keeps
> performance.
>
> Bootstrap®test pass on powerpc64le,
On Tue, May 19, 2020 at 10:39:59AM -0400, Jason Merrill wrote:
> On 5/18/20 5:07 PM, Marek Polacek wrote:
> > On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches
> > wrote:
> > > On 5/13/20 12:22 PM, Marek Polacek wrote:
> > > > DR 2289 clarified that since structured bindings
Hi Jeff,
on 2020/5/20 上午11:58, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> This patch check the size of a loop to be unrolled/peeled completely,
> and set the limits to a number (24). This prevents large loop from
> being unrolled, then avoid binary size increasing, and this limit keeps
> perform
Martin Liška writes:
Hi Martin,
> On 5/19/20 11:45 AM, Frederik Harwath wrote:
> Thank you Frederick for the patch.
>
> Looking at what I grepped:
> https://github.com/marxin/gcc-changelog/issues/1#issuecomment-621910248
I get a 404 error when I try to access this URL. The repository also
does
On Wed, May 20, 2020 at 3:57 AM H.J. Lu wrote:
>
> Update VPCLMULQDQ check to support processors with AVX version of
> VPCLMULQDQ.
>
> PR target/91695
> * config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
> check.
OK.
Thanks,
Uros.
> ---
> libgcc/config/i38
On Tue, May 19, 2020 at 11:40 PM H.J. Lu wrote:
> > > > > > > > I will take a look to see if we share the same CPU detection
> > > > > > > > code between
> > > > > > > > libgcc and config/i386/driver-i386.c.
> > > > > > >
> > > > > > > I don't think it will bring any benefit, this is mainly one
101 - 118 of 118 matches
Mail list logo
