On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 24, 2020 at 03:35:24PM -0500, will schmidt wrote:
> > We have extraneous BTM entry (RS6000_BTM_POWERPC64) in the
> > define for
> > our P10 MISC 2 builtin definition. This does not exist for the
> > '0',
> > '1
In the testcase concepts7.C below, we currently reject the call to f1
but we accept the call to f2, even though their associated constraints
are functionally equivalent.
The reason satisfaction differs for (!!C is due to normalization: the former is already an
atom, and the latter is not. Normali
From: Sergei Trofimovich
Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.
As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.
The problem happens because in a case of mult
On 9/25/20 8:29 AM, Tamar Christina wrote:
Hi All,
This adds some documentation for some test directives that are missing.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* doc/sourcebuild.texi (vect_complex_rot_,
a
Hi!
On Fri, Sep 25, 2020 at 11:09:39AM +0200, Jakub Jelinek wrote:
> libcpp has two specialized altivec implementations of search_line_fast,
> one for power8+ and the other one otherwise.
> Both use __attribute__((altivec(vector))) and the GCC builtins rather than
> altivec.h and the APIs from the
On Fri, Sep 25, 2020 at 04:09:44PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/24/20 8:05 PM, Marek Polacek wrote:
> > This new warning can be used to prevent expensive copies inside range-based
> > for-loops, for instance:
> >
> >struct S { char arr[128]; };
> >void fn () {
> >
Hi,
while adding check for gimple_clobber I reversed the return value
so instead of ignoring the statement ipa-modref gives up. Fixed thus.
This explains the drop between originally reported disambinguations
stats and ones I got later.
Bootstrapped/regtested x86_64-linux.
gcc/ChangeLog:
2020-09
Hi,
ipa-modref propagates knowledge about callee to caller function. This is
not compatible with live patching and thus this patch makes
-flive-patching to imply -fno-ipa-modref.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-09-26 Jan Hubicka
* doc/invoke.texi: A
On 9/24/20 6:05 PM, Marek Polacek via Gcc-patches wrote:
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
void fn () {
S arr[5];
for (const auto x : arr) { }
}
where auto deduces to S and then w
On Fri, Sep 25, 2020 at 08:58:35AM +0200, Richard Biener wrote:
> On Thu, Sep 24, 2020 at 9:38 PM Segher Boessenkool
> wrote:
> > after which I get (-march=znver2)
> >
> > setg:
> > vmovd %edi, %xmm1
> > vmovd %esi, %xmm2
> > vpbroadcastd%xmm1, %ymm1
> > vpb
Hi!
On Fri, Sep 25, 2020 at 09:07:46AM -0500, Paul A. Clarke wrote:
> On Thu, Sep 24, 2020 at 06:22:10PM -0500, Segher Boessenkool wrote:
> > > + result [(__N & 0b)] = __D;
> >
> > Hrm, GCC supports binary constants like this since 2007, so okay. But I
> > have to wonder if this improves an
On Fri, Sep 25, 2020 at 10:41:05AM -0500, will schmidt wrote:
> On Thu, 2020-09-24 at 19:40 -0500, Segher Boessenkool wrote:
> > > +++ b/gcc/testsuite/gcc.target/powerpc/vsx-load-element-extend-
> > > char.c
> > > @@ -0,0 +1,168 @@
> > > +/*
> > > + * Test of vec_xl_sext and vec_xl_zext (load into
On Fri, Sep 25, 2020 at 02:54:01PM -0500, Pat Haugen wrote:
> > +(define_expand "extendditi2"
> > + [(set (match_operand:TI 0 "gpc_reg_operand")
> > +(sign_extend:DI (match_operand:DI 1 "gpc_reg_operand")))]
> > + "TARGET_POWER10"
> > + {
> > +/* Move 64-bit src from GPR to vector re
On Fri, Sep 25, 2020 at 03:34:49PM -0500, will schmidt wrote:
> On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
> > No, it cannot.
> >
> > This is used for pdepd/pextd/cntlzdm/cnttzdm/cfuged, all of which do
> > need 64-bit registers to do anything sane.
> >
> > This should really ha
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3471-g29f5db8ef81fac4db8e66e5f06fdf1d469e8161c.
gcc/analyzer/ChangeLog:
PR analyzer/96646
PR analyzer/96841
* region-model.cc (region_model::get_representative_path_var):
When han
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3472-gd4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3.
gcc/testsuite/ChangeLog:
PR analyzer/94355
* g++.dg/analyzer/placement-new.C: New test.
---
gcc/testsuite/g++.dg/analyzer/placement-new.C | 26 ++
On 9/22/20 4:05 PM, Martin Sebor wrote:
The rebased and retested patches are attached.
On 9/21/20 3:17 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
(I'm working on rebasing the patch on top of the latest trunk which
has changed some of the
On 9/25/20 6:01 PM, Marek Polacek wrote:
On Fri, Sep 25, 2020 at 04:09:44PM -0400, Jason Merrill via Gcc-patches wrote:
On 9/24/20 8:05 PM, Marek Polacek wrote:
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka wrote:
>Hi,
>while adding check for gimple_clobber I reversed the return value
>so instead of ignoring the statement ipa-modref gives up. Fixed thus.
>This explains the drop between originally reported disambinguations
>stats and ones I got
Hi,
this is variant i comitted. Some further testing has shown a problem in
merge operation returing true even if summary was cleanuped to its
original form. This resulted in infinite loop building firefox.
Second problem was that for recurisve functions we need to merge summary
to itself and for
> On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka
> wrote:
> >Hi,
> >while adding check for gimple_clobber I reversed the return value
> >so instead of ignoring the statement ipa-modref gives up. Fixed thus.
> >This explains the drop between originally reported disambinguations
> >stats
101 - 121 of 121 matches
Mail list logo
