for excess errors)
FAIL: g++.dg/cpp0x/initlist48.C -std=c++17 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2534/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse
Hi William,
Thanks for the review comments!
on 2021/7/28 上午6:25, will schmidt wrote:
> On Wed, 2021-05-26 at 10:59 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>
>
> Hi,
>
>
>> This is the updated version of patch to deal with the bwaves_r
>>
Hi,
v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
This v3 addressed William's review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576154.html
It's mainly to deal with the bwaves_r degradation due to vector
construction fed by strided loads.
Hi:
As described in PR 39821, WIDEN_MULT_EXPR should use a different cost
model from MULT_EXPR, this patch add ix86_widen_mult_cost for that.
Reference basis for the cost model is https://godbolt.org/z/EMjaz4Knn.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
gcc/ChangeLog
ON line 24 i == 5
FAIL: gfortran.dg/guality/pr41558.f90 -Os line 7 s == 'foo'
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2558/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=s
/pr92658-sse4-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-sse4-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-sse4.c scan-assembler-times pmovzxdq 2
FAIL: gcc.target/i386/pr92658-sse4.c scan-assembler-times pmovzxwq 2
with GCC configured with
../../gcc/configure
Committed as obvious fix, and opened pr101668 to record the issue related
to pr92658-{avx512bw-2,sse4-2,sse4}.c.
gcc/testsuite/ChangeLog:
PR target/99881
* gcc.target/i386/pr91446.c: Adjust testcase.
* gcc.target/i386/pr92658-avx512bw-2.c: Ditto.
* gcc.target
On 2021-07-27 23:40, Jeff Law wrote:
On 7/27/2021 12:27 AM, Richard Biener wrote:
On Fri, 23 Jul 2021, Jeff Law wrote:
On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE
/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2591/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c
From: Andrew Pinski
So I was looking at some older PRs (PR 16016 in this case),
I noticed that some of the testcases were removed when
the tree-ssa branch was merged. This adds them back in.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
gcc
oops for the !only_push_innermost_p
> case is important - if we manage to produce a single
> walker with conditionals based on 'flags' then IPA-CP should
> produce optimal clones as well I guess.
>
Thanks for the comments, the updated v2 is attached.
Comparing with v1, it do
Hi Ruoyao,
on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote:
> Ping again.
>
This ping-ed patch has been approved by Richard at
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576001.html
Just chime in as I guess you didn't receive his mail somehow.
BR,
Kewen
> On S
; so far, all untested!)
>
>
Yeah, since this patch is mainly to replace FOR_EACH_LOOP* for loop
traserval, I didn't scan all the class loop *loop, just those ones
used by FOR_EACH_LOOP*. I like your nice proposed further clean-up,
thanks for doing that!
> But first, is this
that context, I think the expected original number has been
assigned to variable orig_loop_num by extracting from the arg0
of IFN_LOOP_DIST_ALIAS call. So replace those ones.
Is it ok for trunk?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576367.html
BR,
Kewen
-
gcc/ChangeLog:
* tree-cf
(vectorizable_load): Likewise. Emulate them by extracting
> scalar offsets, doing scalar loads and a vector construct.
>
> * gcc.target/i386/vect-gather-1.c: New testcase.
> * gfortran.dg/vect/vect-8.f90: Adjust.
> ---
> gcc/testsui
From: Andrew Pinski
Just like the old bug PR9651, unsigned_fix rtl should
also be handled as a trapping instruction.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR rtl-optimization/101683
* rtlanal.c (may_trap_p_1): Handle UNSIGNED_FIX
-not test(l|q|w)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2640/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable
it
of genfusion.pl.
If bootstrap/regtest passes, OK for trunk and backport to 11.2?
Thanks,
Aaron
gcc/
* rs6000.md (define_attr "type"): Add types for fusion.
* genfusion.md (gen_ld_cmpi_p10): Use new fusion types.
(gen_2logical): Use new fusion types.
ess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O3 -g (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -Os (test for excess errors)
From: Aaron Sawdey
This adds some test cases to make sure that the combine patterns for p10
fusion are working.
OK for trunk?
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/fusion-p10-ldcmpi.c: New file.
* gcc.target/powerpc/fusion-p10-2logical.c: New file.
---
.../gcc.target
From: Aaron Sawdey
Two more sets of combine patterns for p10 fusion. These require
the "Add insn types for fusion pairs" patch I posted earlier today.
If ok I would like to put these in gcc 12 trunk and backport for 11.2.
Thanks,
Aaron
Aaron Sawdey (2):
combine patterns f
From: Aaron Sawdey
This patch adds a function to genfusion.pl to add a couple
more patterns so combine can do fusion of pairs of add and
vaddudm instructions.
gcc/ChangeLog:
* gcc/config/rs6000/genfusion.pl (gen_addadd): New function.
* gcc/config/rs6000/fusion.md: Regenerate
From: Aaron Sawdey
This patch modifies the function in genfusion.pl for generating
the logical-logical patterns so that it can also generate the
add-logical and logical-add patterns which are very similar.
gcc/ChangeLog:
* config/rs6000/genfusion.pl (gen_logical_addsubf): Refactor to
-tree-dump-times dse1 "Deleted dead
store: x = " 1
FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead
store: y = " 1
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-382/usr
--enabl
On 2021-05-01 00:27, Jeff Law wrote:
On 4/29/2021 3:50 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n
On 2021-05-01 05:37, Segher Boessenkool wrote:
Hi!
On Thu, Apr 29, 2021 at 05:50:48PM +0800, Jiufu Guo wrote:
When there is the possibility that overflow may happen on the loop
index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
whil
Or alternatively
on SPEC?
In SPEC2017, there are ~240 loops are split. And I saw some performance
improvement on xz.
I would try bootstrap-O3 (encounter ICE).
Actual comments on the patch inline.
Thanks!
Jiufu Guo.
gcc/ChangeLog:
2021-04-29 Jiufu Guo
* params.opt (max-insns-ne-
n.
Bootstrapped/regtested on powerpc64le-linux-gnu P9.
Nothing remarkable was observed with SPEC2017 Power9 full run.
Is it ok for trunk?
BR,
Kewen
--
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_density_test): Early return if
calculating single scalar iteration cost.
g
nu P9.
Nothing remarkable was observed with SPEC2017 Power9 full run,
excepting for bwaves_r degradation has been fixed.
Is it ok for trunk?
BR,
Kewen
--
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_density_test): Add new heuristics
for strided_load density check.
---
gcc/config/
Hi,
For some cases that when we load unsigned char/short values from
the appropriate unsigned char/short memories and convert them to
double/single precision floating point value, there would be
implicit conversions to int first. It makes GCC not leverage the
P9 instructions lxsibzx/lxsihzx
Gentle ping.
Original message:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
Thanks,
Jiufu Guo.
.
Bootstrapped/regtested on powerpc64le-linux-gnu P9, powerpc64-linux-gnu P8,
x86_64-redhat-linux and aarch64-linux-gnu.
Is it ok for trunk?
BR,
Kewen
--
gcc/ChangeLog:
PR tree-optimization/99398
* tree-ssa-forwprop.c (get_prop_source_stmt): Add optional argument
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562015.html
BR,
Kewen
otstrap-O3)? Or alternatively
> on SPEC?
In SPEC2017, there are ~240 loops are split. And I saw some
performance
improvement on xz.
I would try bootstrap-O3 (encounter ICE).
Without this patch, the ICE is also there when building with
bootstrap-O3 on ppc64le.
>
> Actual comments on t
On Fri, Apr 30, 2021 at 1:20 PM Feng Xue OS via Gcc-patches
wrote:
>
> >> This patch implements a new loop optimization according to the proposal
> >> in RFC given at
> >> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html.
> >> So do not repeat th
Hi Richi,
Thanks for the comments!
on 2021/5/7 下午5:43, Richard Biener wrote:
> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> When I was investigating density_test heuristics, I noticed that
>> the current rs6000_density_
Hi,
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569790.html
This is the updated version with one new parameter costing_for_scalar
passed by init_cost hook, instead of checking the passed data point
identity.
Bootstrapped/regtested on powerpc64le-linux-gnu P9.
Is it ok for trunk?
BR
k for trunk?
BR,
Kewen
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569836.html
-----
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_vect_nonmem): Renamed to
vect_nonmem and moved into...
(struct rs6000_cost_data): ...here.
(rs6000_init_cost): Use vect_nonm
Hi Will,
Thanks for the comments!
on 2021/5/7 下午7:43, will schmidt wrote:
> On Fri, 2021-05-07 at 10:28 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> When I was investigating density_test heuristics, I noticed that
>> the current rs6000_density_test coul
(failed to join gcc, so posting here)
Is there any private email where one can file complaints re
project-maintainers (or "those who are supervising the maintainers") ?
Is there any information about the process for such complaints?
Related Issue: https://gcc.gnu.org/bugzilla/show_
On Linux/x86_64,
da9e6e63d1ae22e530ec7baf59f6ed028bf05776 is the first bad commit
commit da9e6e63d1ae22e530ec7baf59f6ed028bf05776
Author: Alexandre Oliva
Date: Mon May 3 22:48:47 2021 -0300
introduce try store by multiple pieces
caused build failure when configured with:
../gcc
Thank you for your quick response.
To me this sounds quite like an "disorganized mess, where bullies, abusers
and even IT-fascists can thrive".
It is clear to me that some gcc project maintainers, the steering committee
and bountysource are crossing ethical (if not legal) boundaries.
scan-assembler-times LFB3 5
FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++17 scan-assembler-times LFB3 5
FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++2a scan-assembler-times LFB3 5
FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98 scan-assembler-times LFB3 5
with GCC configured with
../../gcc
/pr98218-2a.c (internal compiler error)
FAIL: gcc.target/i386/pr98218-2a.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-514/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with
-std=c++14 (test for errors, line 59)
FAIL: g++.dg/gomp/clause-3.C -std=c++17 (test for errors, line 59)
FAIL: g++.dg/gomp/clause-3.C -std=c++2a (test for errors, line 59)
FAIL: g++.dg/gomp/clause-3.C -std=c++98 (test for errors, line 59)
with GCC configured with
../../gcc/configure
--prefi
On Sun, 9 May 2021 at 20:32, Koning, Paul wrote:
>
>
> > On May 9, 2021, at 11:33 AM, abebeos via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >
> > Thank you for your quick response.
> >
> > ...
> > The Issue:
> >
> > https://g
It is just fascinating to see how you don't realize that this affects
mainly gcc.
On Mon, 10 May 2021 at 01:42, Eric Botcazou
wrote:
> > It is a gcc issue, see the very first link you've quoted (
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729).
>
> IIUC
Again, just heavily fascinating to see how you ignore the overall essence
of this, which is of course directly related to gcc.
(bountysource is just a secondary disaster, it all starts here, at gcc.
On Mon, 10 May 2021 at 12:19, Jakub Jelinek wrote:
> On Sun, May 09, 2021 at 07:48:50PM -0
ven IT-fascists can thrive".
> >
> > It is clear to me that some gcc project maintainers, the steering
> committee and bountysource are crossing ethical (if not legal) boundaries.
>
> The GCC project maintainers and the steering committee are definitely
> not crossing ethi
On Mon, 10 May 2021 at 23:32, Ian Lance Taylor wrote:
> On Mon, May 10, 2021, 9:52 AM abebeos
> wrote:
>
>> Again, just heavily fascinating to see how you ignore the overall essence
>> of this, which is of course directly related to gcc.
>>
>> (bountysource is
On Tue, 11 May 2021 at 01:35, Ian Lance Taylor wrote:
> On Mon, May 10, 2021 at 2:45 PM abebeos
> wrote:
> >
> > The bounty was filed/advertised by the gcc project, so the gcc project
> should have intervened immediately at the point where an anonymous coward
> r
On Tue, 11 May 2021 at 01:43, Jeff Law wrote:
>
> On 5/10/2021 3:45 PM, abebeos via Gcc-patches wrote:
> >
> > I've described this in my message here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html
> >
> > The summary is poss
Hi Richi,
on 2021/5/10 下午9:55, Richard Biener wrote:
> On Sat, May 8, 2021 at 10:05 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the comments!
>>
>> on 2021/5/7 下午5:43, Richard Biener wrote:
>>> On Fri, May 7, 2021 at 5:30 AM Ke
Hi Richard,
on 2021/5/10 下午10:08, Richard Sandiford wrote:
> "Kewen.Lin via Gcc-patches" writes:
>> on 2021/5/7 下午5:43, Richard Biener wrote:
>>> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
>>> wrote:
>>>>
>>>> Hi,
Hi Segher,
on 2021/5/11 上午4:12, Segher Boessenkool wrote:
> Hi!
>
> On Sat, May 08, 2021 at 04:12:18PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000.c
>> +++ b/gcc/config/rs6000/rs6000.c
>> @@ -5234,6 +5234,8 @@ typedef struct _rs6000_cost_data
>>
Hi Richi,
> OTOH we already pass scalar_stmt to individual add_stmt_cost,
> so not sure whether the context really matters. That said,
> the density test looks "interesting" ... the intent was that finish_cost
> might look at gathered data from add_stmt, not that it looks at
>
-std=gnu++14 scan-assembler-times pcmpgtd 2
FAIL: g++.target/i386/pr98218-1.C -std=gnu++17 scan-assembler-times pcmpgtd 2
FAIL: g++.target/i386/pr98218-1.C -std=gnu++2a scan-assembler-times pcmpgtd 2
FAIL: g++.target/i386/pr98218-1.C -std=gnu++98 scan-assembler-times pcmpgtd 2
with GCC
GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-742/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux
aused
FAIL: gcc.target/i386/avx-pr94680.c scan-assembler-not pxor
FAIL: gcc.target/i386/avx-pr94680.c scan-assembler-times (?n)vmov[a-z0-9]*[
\\t]*%xmm[0-9] 12
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-760/usr
--enable-cl
op1 gathering (leave V_C_E in code2)
if (code == VIEW_CONVERT_EXPR || code2 == VIEW_CONVERT_EXPR)
do the tricks on arg0/arg1/op2
the previous handlings on CONSTRUCTOR/VECTOR_CST
}
Also updated "shrinked" to "shrunk" as Segher pointed out. :-)
Does it look better
kind == unaligned_load
|| kind == vector_gather_load)
data->nload += count;
if (stmt_info && STMT_VINFO_STRIDED_P (stmt_info))
{
if (kind == scalar_load || kind == unaligned_load)
data->nload_ctor += count;
else if (kind
On Sat, 8 May 2021 at 18:49, abebeos
wrote:
> (failed to join gcc, so posting here)
>
> Is there any private email where one can file complaints re
> project-maintainers (or "those who are supervising the maintainers") ?
>
> Is there any information about the
chard.
Jiufu Guo.
2021-05-14 Richard Biener
Jiufu Guo
PR go/100537
* go-gcc.cc
(Gcc_backend::address_expression): Set TREE_ADDRESSABLE.
---
gcc/go/go-gcc.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index
On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
On 2021-05-14 15:15, Richard Biener wrote:
On May 14, 2021 4:52:56 AM GMT+02:00, Jiufu Guo
wrote:
As discussed in the PR, Richard mentioned the method to
figure out which VAR was not set TREE_ADDRESSABLE, and
then cause this failure. It is
I'm
replying to), in this unregulated circus-show ("The GCC Project"). I've
polluted my mind enough with your nonsense justifications, to be honest it
is becoming quite disgusting.
If any serious person from the FSF (as to my tiny research, the FSF is in
the end legally and ethic
maybe
more accurate, but relative "expensive".
"nowrap_type_p and scev_probably_wraps_p" may be little cheaper,
but "number_of_iterations_exit" would be more accurate.
Is this right?
BR,
Jiufu Guo.
diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
index
-OPT for the generic A ? D : 0 case.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
gcc/ChangeLog:
* match.pd ((A & C) != 0 ? D : 0): Limit to non pointer types.
gcc/testsuite/ChangeLog:
* testsuite/gcc.dg/gimplefe-45.c: New testcase.
---
gcc/matc
and tested on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
gcc:
* match.pd (A?CST1:CST2): Add simplifcations for A?0:+-1, A?+-1:0,
A?POW2:0 and A?0:POW2.
---
gcc/match.pd | 37 +
1 file changed, 37 insertions(+)
diff --git a/gcc/match.pd b/gcc
ikely to block
>> the CTOR and its subsequent chain.
>>
>> btw, as your previous comments on add_stmt_cost, the load/strided/ctor
>> statistics should be gathered there instead, like:
>>
>> if (!data->costing_for_scalar && data->loop_info &&a
/pr100582.c scan-assembler-times pblendvb 1
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-837/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet
On 2021-05-17 16:17, Richard Biener wrote:
On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
wrote:
On 2021-05-14 15:39, guojiufu via Gcc-patches wrote:
> On 2021-05-14 15:15, Richard Biener wrote:
>> On May 14, 2021 4:52:56 AM GMT+02:00, Jiufu Guo
>> wrote:
>>
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would not happen. For example code:
foo (int
On 2021-05-18 18:32, guojiufu wrote:
On 2021-05-18 17:28, guojiufu via Gcc-patches wrote:
On 2021-05-18 14:36, Bernd Edlinger wrote:
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
When there is the possibility that overflow/wrap may happen on the
loop index,
a few optimizations would
On 2021-05-18 14:58, Richard Biener wrote:
On Mon, 17 May 2021, Ian Lance Taylor wrote:
On Mon, May 17, 2021 at 1:17 AM Richard Biener via Gcc-patches
wrote:
>
> On Fri, May 14, 2021 at 11:19 AM guojiufu via Gcc-patches
> wrote:
> >
> > On 2021-05-14 15:39, guojiufu
-objects scan-tree-dump vect
"vectorized 1 loops in function"
FAIL: gcc.dg/vect/pr71264.c scan-tree-dump vect "vectorized 1 loops in function"
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-883/usr
--enabl
at
targets have their own decisions on this costing like the others,
I used parameter instead of one unique macro here.
Testing is ongoing, is it ok for trunk if everything goes well?
BR,
Kewen
---
gcc/ChangeLog:
* doc/invoke.texi (vect-inner-loop-weight-factor): Document new
.dg/gomp/declare-variant-2.f90 -O (test for errors, line 39)
FAIL: gfortran.dg/gomp/declare-variant-2.f90 -O (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-4590/usr
--enable-clocale=gnu --with-sy
I've been looking over the reviews as well as a few things I've
encountered locally, and collected this list:
Unfortunately, I am simply not familiar enough with the gcc tree to
implement patch 16, although there is a slight possibility that I may
be able to do patch 19, and a stronger
ypes within the compiler.
>
But this is the reason why we need patch #2 and #3, not the reason why we need
the special handling for building_libgcc in patch #1, right?
Without or with patch #1, the below ICE in libgcc exists, the ICE should have
nothing to do with the special handling fo
on 2022/12/12 11:23, HAO CHEN GUI wrote:
> Hi Kewen,
>
> 在 2022/12/8 16:47, Kewen.Lin 写道:
>> This documentation update reminds me of that the current prototype of
>> __ieee128
>> variant can be:
>>
>> unsigned int scalar_extract_exp (__ieee128 source);
>>
>> type unsigned int is enough for the
Don't add crtfastmath.o for -shared to avoid changing the MXCSR
register when loading a shared library. crtfastmath.o will be used
only when building executables.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/55522
PR t
ying to get the right KC/TC for the attribute mode stuff.
>
> However, if patches 1-3 aren't put in, just applying the patch to use
> _Float128
> and _Complex _Float128 would fix the immediate problem (of not building GCC on
> systems with IEEE 128-bit long double). However, it is a b
on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
> Hi Mike,
>
> Thanks for fixing this, some comments are inlined below.
>
> on 2022/11/2 10:42, Michael Meissner wrote:
>> This patch fixes the issue that GCC cannot build when the default long double
>> is IEEE 128
Hi Jeff,
on 2022/12/12 09:44, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> Compare with previous patch, this patch updates accoding to comments; fixes
> conflicts with trunk, and recheck bootstrap®test.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607333.html
>
Hi Jakub,
Thanks for the comments!
on 2022/12/14 17:36, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote:
>> on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
>>> Hi Mike,
>>>
>>> Thanks for fixing t
Hi Jeff,
on 2022/12/12 09:38, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> For constant C:
> If '(c & 0x8000ULL) == 0x8000ULL' or say:
> 32(1) || 16(x) || 1(1) || 15(x), using "li; xoris" would be ok.
>
> If '(c & 0
re we can catch any other possible
unexpected cases in time if there are.
Bootstrapped and regtested on powerpc64-linux-gnu P8,
powerpc64le-linux-gnu P9 and P10.
I'm going to push this next week if no objections.
[1] https://gcc.gnu.org/pipermail/gcc/2022-December/240218.html
[2] https://gcc.gnu.o
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
on 2022/11/24 17:15, Kewen Lin wrote:
> Hi,
>
> Following Segher's suggestion, this patch series is to rework
> function rs6000_emit_vector_compare for vector float and
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603350.html
BR,
Kewen
> on 2022/10/12 16:12, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> PR106680 shows that -m32 -mpowerpc64 is different from
>> -mpowerpc64 -m32, this is determined
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607526.html
BR,
Kewen
on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR104024 shows, the option -mpower10-fusion isn't guarded by
> -mcpu=power10, it causes compiler to fuse for som
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html
BR,
Kewen
on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
> if fun->decl is not null but no cgraph node is availab
I had a look-- issue fixed, rough patch below. Full patch will be part of v2.
>From b0d93d8212328fabcbdb32c266c265a4eed49e00 Mon Sep 17 00:00:00 2001
From: Maximilian Downey Twiss
Date: Thu, 15 Dec 2022 09:54:36 +1100
Subject: [PATCH] java: Adjustments to end_params_node and void_list_node.
Patch 19 has been resolved.
fore does not, which I believe is causing the breakage.
Master:
zopolis4@epidural ~/g/x/libjava> /bin/bash ./libtool --tag=GCJ
--mode=link /home/zopolis4/gcjbuild/./gcc/gcj
-B/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/ -B/h
ome/zopolis4/gcjbuild/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/
used only when
building executables.
PR target/55522
* config/i386/gnu-user-common.h (GNU_USER_TARGET_MATHFILE_SPEC):
Don't add crtfastmath.o for -shared.
* doc/invoke.texi (-shared): Add related documentation.
---
gcc/config/i386/gnu-user-common.h | 2 +
AR_mdaz_ftz do_not_use
#endif
and not be saved and restored in cl_target_option_save and
cl_target_option_restore(am I missing something?)
3. Capital the first letter and add more descriptions about -mdaz-ftz and
-shared.
gcc/ChangeLog:
PR target/55522
PR target/36821
'm inclined
to believe it's intentional since there is only a sNaN generation. If so,
we don't want this kind of conversion which is useless and can clear signalling
bit unexpectedly, one shortcut is to just copy the corresponding REAL_VALUE_TYPE
and rebuild with the given type i
on 2022/12/14 18:33, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote:
>>> The hacks with different precisions of powerpc 128-bit floating types are
>>> very unfortunate, it is I assume because the middle-end asserted that scalar
>>> floating point types with differe
Hi Honza,
Thanks for the comments.
on 2022/12/14 21:22, Jan Hubicka wrote:
>>> PR middle-end/105818
>>>
>>> gcc/ChangeLog:
>>>
>>> * predict.cc (optimize_function_for_size_p): Further check
>>> optimize_size of fun->decl w
1901 - 2000 of 43429 matches
Mail list logo
