On 29/12/2023 22:14, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt: Add new options -fcondition-coverage and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #12 from Ian Lance Taylor ---
libgo/runtime/runtime.h:
#if defined(__x86_64__) && defined(__linux__) && !defined(__CET__)
...
#else
#define __go_context_t ucontext_t
#define __go_getcontext(c) getcontext(c)
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113176
--- Comment #1 from Andrew Pinski ---
I should note the non-constant case is already handled:
```
int unopt(int n, int c) {
if (n / c)
return n / c;
else
return 0;
}
```
It is just the constant case that has issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113176
Bug ID: 113176
Summary: `(n / 4) ? n / 4 : 0` is not optimized to just `n /4`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
On 12/29/23 10:46, YunQiang Su wrote:
When we try to combine RTLs, the result may be very complex,
and `rtx_cost` may think that it need lots of costs. But in
fact, it may match a pattern in machine descriptions, which
may emit only 1 or 2 hardware instructions. This combination
may be
On 12/28/23 19:07, YunQiang Su wrote:
In general, I agree with this change.
When gcc12 on RV64, more than one `sext.w` will be produced with our test.
(Note, use -O1).
There are two things that help here. The first is that the most significant
bit never appears in the middle of a field,
On 12/28/23 22:56, Li, Pan2 wrote:
Thanks Jeff.
I think I locate where aarch64 performs the trick here.
1. In the .final we have rtl like
(insn:TI 6 8 29 (set (reg:SF 32 v0)
(const_double:SF -0.0 [-0x0.0p+0]))
At 14:28 +0800 on 2023-12-29th, Chenghua Xu wrote:
> chenxiaolong writes:
>
> > In order to improve and check the function of vector quantization
> > in
> > LoongArch architecture, tests on vector instruction set are
> > provided
> > in target-support.exp.
> >
> > gcc/testsuite/ChangeLog:
> >
>
I'm not completely sure I got the intent of the "log2_limit",
or whether "limit" is sane to decrease like this; it just
looked like an obvious and safe reduction. Also, I verified
the 10+ minute runtime, on this same host (clocked at 11:43.61
elapsed time) for a r12-2797-g307e0d40367996 build
Tested for mmix and observing the increased timeout in the .log
file - and the test passing.
Ok to commit? Or better suggestions?
-- >8 --
Testing for mmix (a 64-bit target using Knuth's simulator). The test
is largely pruned for simulators, but still needs 5m57s on my laptop
from 3.5 years
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #11 from Steve Kargl ---
On Fri, Dec 29, 2023 at 08:34:38PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
>
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #6 from Daniel Kolesa ---
If it helps, I have reduced the patches to just the two that strictly necessary
for stage 1 build (I can't get rid of those, sorry, that would be asking for
the impossible), which are:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
Bug ID: 113175
Summary: [14 Regression] MMIX:
testsuite/std/ranges/iota/max_size_type.cc 5x times
slower
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070
Andreas Schwab changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113173
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
There will be another update in January.
* MAINTAINERS: Update my email address.
diff --git a/MAINTAINERS b/MAINTAINERS
index 343560c5b84..fe5d95ae970 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -34,7 +34,7 @@ Jeff Law
Michael Meissner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #5 from Andrew Pinski ---
(In reply to Daniel Kolesa from comment #4)
> I don't think builds with completely unchanged source are going to work, as
> the compiler won't even reach this point then (at very least several of them
> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #4 from Daniel Kolesa ---
I don't think builds with completely unchanged source are going to work, as the
compiler won't even reach this point then (at very least several of them are
necessary for stage 1 to build at all)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #3 from Daniel Kolesa ---
this is the preprocessed source: https://0x0.st/HEt7.ii
It's generated with the following command line:
/builddir/gcc-13.2.1_git20231014/build/./prev-gcc/xg++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
Andrew Pinski changed:
What|Removed |Added
Host||powerpc64el-linux-musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
Bug ID: 113174
Summary: gcc fails to bootstrap on pp64le with clang-based host
environment (internal compiler error)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Snapshot gcc-12-20231229 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231229/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Mon, 25 Dec 2023 10:28:14 -0600
Segher Boessenkool wrote:
> That is wrong. Build dir as a subdir of the source dir is not
> supported. It might work in many cases, but that does not mean it is
> okay to do.
Works perfectly fine on every version of GCC I've used, from 5 to 12, and I've
> Hi Honza,
Hi,
>
> I wasn't sure what to do here so I figured I'd ask.
>
> In adding support for multiple exits to the vectorizer I didn't know how to
> update this bit:
>
> https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-vect-loop-manip.cc#L3363
>
> Essentially, if skip_vector (i.e.
Hi Honza,
I wasn't sure what to do here so I figured I'd ask.
In adding support for multiple exits to the vectorizer I didn't know how to
update this bit:
https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-vect-loop-manip.cc#L3363
Essentially, if skip_vector (i.e. not enough iteration to
Hi,
> This patch implements lockfile used for incremental LTO.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * Makefile.in: Add lockfile.o.
> * lockfile.cc: New file.
> * lockfile.h: New file.
I can't approve it, but overall it looks good to me.
We
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * lto-streamer.cc (lto_get_section_name): Remove random_seed in WPA.
This is also OK. (since it lacks explanation - the random suffixes are
added for ld -r to work. This never happens between WPA and ltrans, so
they
Hi,
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * lto-opts.cc (lto_write_options): Skip OPT_fltrans_output_list_.
OK,
thanks,
Honza
> ---
> gcc/lto-opts.cc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/lto-opts.cc b/gcc/lto-opts.cc
> index
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin_fork_or_exec): Check
> condition_coverage_flag.
> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
> * common.opt: Add new options -fcondition-coverage and
> -Wcoverage-too-many-conditions.
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113172
--- Comment #2 from Tamar Christina ---
Patch submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #10 from Tamar Christina ---
Patch submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144
--- Comment #8 from Tamar Christina ---
Patch submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113136
--- Comment #9 from Tamar Christina ---
Patch submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #13 from Tamar Christina ---
Patch submitted
Hi All,
This patch fixes several interconnected issues.
1. When picking an exit we wanted to check for niter_desc.may_be_zero not true.
i.e. we want to pick an exit which we know will iterate at least once.
However niter_desc.may_be_zero is not a boolean. It is a tree that encodes
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83181
Eddie Nolan changed:
What|Removed |Added
CC||eddiejnolan at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113172
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2023-12-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> Created attachment 56949 [details]
> patch with implementation
Not a review, just a comment:
diff --git a/gcc/fortran/simplify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with trunk 20231229 on aarch64-linux-gnu, last successful build from
20231214
[...]
libtool: compile: /<>/build/./gcc/gccgo
-B/<>/build/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #9 from kargl at gcc dot gnu.org ---
Current patch is incomplete as it fails to scalarize.
It seems I need to remember how to register the new
intrinsic subprograms in trans-intrinsics.cc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113172
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113172
Bug ID: 113172
Summary: ice in move_early_exit_stmts
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
When we try to combine RTLs, the result may be very complex,
and `rtx_cost` may think that it need lots of costs. But in
fact, it may match a pattern in machine descriptions, which
may emit only 1 or 2 hardware instructions. This combination
may be refused due to cost comparison failure.
Since
When combine some instructions, the generic `rtx_cost`
may over estimate the cost of result RTL, due to that
the RTL may be quite complex and `rtx_cost` has no
information that this RTL can be convert to simple
hardware instruction(s).
In this case, Let's use `get_attr_insn_count` to estimate
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
--- Comment #7 from Jeffrey A. Law ---
So far that's the only fallout I've seen on the embedded targets.
The qemu emulated natives aren't running as I've got some kind of network
problem here and the workers are going offline after a few hours
The accurate cost of an pattern can get with
insn_count * perf_ratio
The default value is set to 0 instead of 1, since that
we will need to distinguish the default value and it is
really set for an pattern. Since it is not set for most
patterns yet, to use it, we will need to be sure
This match pattern allows combination (zero_extract:DI 8, 24, QI)
with an sign-extend to 32bit INS instruction on TARGET_64BIT.
The problem is that, for SI mode, if the sign-bit is modified by
bitops, we will need a sign-extend operation.
Since 32bit INS instruction can be sure that result is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #24 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:984bdeaa39b6417b11736b2c167ef82119e272dc
commit r14-6865-g984bdeaa39b6417b11736b2c167ef82119e272dc
Author: Tamar Christina
On Wed, 27 Dec 2023, Martin Uecker wrote:
> This patch hopefully fixes the test failure we see with gnu23-tag-4.c.
> It does for me locally with -march=native (which otherwise reproduces
> the problem).
>
> Bootstrapped and regession tested on x86_64
>
>
> C: Fix type compatibility for structs
Tamar Christina writes:
> Hi All,
>
> In gimple the operation
>
> short _8;
> double _9;
> _9 = (double) _8;
>
> denotes two operations. First we have to widen from short to long and then
> convert this integer to a double.
Think it's worth saying "two operations on AArch64". Some targets
can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
Tamar Christina changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113169
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi All,
Only trying to update certain dominators doesn't seem to work very well
because as the loop gets versioned, peeled, or skip_vector then we end up with
very complicated control flow. This means that the final merge blocks for the
loop exit are not easy to find or update.
Instead of
Hi All,
We can't support nonlinear inductions other than neg when vectorizing
early breaks and iteration count is known.
For early break we currently require a peeled epilog but in these cases
we can't compute the remaining values.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Hi All,
This adds an implementation for conditional branch optab for AArch32.
The previous version only allowed operand 0 but it looks like cbranch
expansion does not check with the target and so we have to implement all.
I therefore did not commit it. This is a larger version.
For e.g.
void
Hi All,
In gimple the operation
short _8;
double _9;
_9 = (double) _8;
denotes two operations. First we have to widen from short to long and then
convert this integer to a double.
Currently however we only count the widen/truncate operations:
(double) _5 6 times vec_promote_demote costs 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113171
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113171
Bug ID: 113171
Summary: Unneeded zero extend after widening load with SVE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165
--- Comment #3 from mecej4 ---
Thanks for the prompt response and the rapid fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #12 from Tamar Christina ---
ok, x86_64 bootstrap and regtest with -O3 and --enable-checking=yes,rtl,extra
now passes.
aarch64 hit a small issue in libgcc that I'm not sure I should be allowing or
not. will investigate and either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113170
--- Comment #1 from Kirkezz ---
I was experimenting with the template template parameters, and ICE occured.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113170
Bug ID: 113170
Summary: ICE: Segfault (template template parameter, alias
template, default value)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #11 from Tamar Christina ---
Created attachment 56963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56963=edit
maintain-lcssa-peeled.patch
patch undergoing testing for both this and PR113136
gcc/ChangeLog:
* config/loongarch/loongarch.md (bstrins__for_ior_mask):
For the condition, remove unneeded trailing "\" and move "&&" to
follow GNU coding style. NFC.
---
Pushed as obvious.
gcc/config/loongarch/loongarch.md | 4 ++--
1 file changed, 2 insertions(+), 2
Pushed v4 as attached, with the format issues fixed and a minor
adjustment in the commit message ("define_insn_and_split" is changed to
"define_insn_and_rewrite" to match the actual change).
On Fri, 2023-12-29 at 19:55 +0800, Xi Ruoyao wrote:
> On Fri, 2023-12-29 at 15:57 +0800, chenglulu wrote:
On Fri, 2023-12-29 at 15:57 +0800, chenglulu wrote:
/* snip */
> > diff --git a/gcc/config/loongarch/loongarch.md
> > b/gcc/config/loongarch/loongarch.md
> /* snip */
> > +(define_insn_and_rewrite "simple_load"
> > + [(set (match_operand:LD_AT_LEAST_32_BIT 0 "register_operand" "=r,f")
> > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113169
--- Comment #1 from Matthias Klose ---
last known successful build was 20231214
The accurate cost of an pattern can get with
insn_count * perf_ratio
The default value is set to 0 instead of 1, since that
we will need to distinguish the default value and it is
really set for an pattern. Since it is not set for most
patterns yet, to use it, we will need to be sure
This match pattern allows combination (zero_extract:DI 8, 24, QI)
with an sign-extend to 32bit INS instruction on TARGET_64BIT.
The problem is that, for SI mode, if the sign-bit is modified by
bitops, we will need a sign-extend operation.
Since 32bit INS instruction can be sure that result is
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with trunk 20231229 on amdgcn-amdhsa. the offload compiler itself is built
with trunk 20231229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113091
--- Comment #8 from Feng Xue ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641547.html
This patch is meant to fix over-estimation about SLP vector-to-scalar cost for
STMT_VINFO_LIVE_P statement. When pattern recognition is involved, a
statement whose definition is consumed in some pattern, may not be
included in the final replacement pattern statements, and would be skipped
when
Szabolcs Nagy writes:
> With new glibc one more loop can be vectorized via simd exp in libmvec.
>
> Found by the Linaro TCWG CI.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran/vect/vect-8.f90: Accept more vectorized loops.
OK. At first I thought it would be good to "defend" the increase when
Di Zhao OS writes:
> This patch adds a new tuning option 'AARCH64_EXTRA_TUNE_FULLY_PIPELINED_FMA',
> to consider fully pipelined FMAs in reassociation. Also, set this option
> by default for Ampere CPUs.
>
> Tested on aarch64-unknown-linux-gnu. Is this OK for trunk?
>
> Thanks,
> Di Zhao
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113168
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
The post-reload splitter currently allows xmm16+ registers with TARGET_EVEX512.
The splitter changes SFmode of the output operand to V4SFmode, but the vector
mode is currently unsupported in xmm16+ without TARGET_AVX512VL. lowpart_subreg
returns NULL_RTX in this case and the compilation fails with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #9 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:1e7f9abb892443719c82bb17910caa8fb5eeec15
commit r14-6862-g1e7f9abb892443719c82bb17910caa8fb5eeec15
Author: Uros Bizjak
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #8 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #6)
> Aha, I see what happened. x/ymm16+ are usable for AVX512F w/o AVX512VL and
> that is why I added that to allow them.
>
> Let me find a way to see if we can fix
84 matches
Mail list logo
