Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-13.1-b20230212.de.po',
Sandra Loosemore writes:
> On 3/9/23 13:38, Arsen Arsenović wrote:
>> Found the change. HTML got support for CONTENTS_OUTPUT_LOCATION,
>> which defaults to after_top, which ignores the inline location of
>> these elements. Here's a patch:
>> maintainer-scripts/ChangeLog:
>> * update_web_d
I've checked in the attached patch per discussion in another thread
about possibly updating the minimum required Texinfo version. This
patch doesn't do that; it just recommends using a more recent version,
removes redundant references to version 4.7, and fixes some related
obsolete bits.
BTW
Even though this PR was reported with an ubsan issue, the problem is
tree_nonzero_bits is being called with an expression which is a vector type.
This fixes three patterns I noticed which does that.
And adds a testcase for one of the patterns.
Committed after a bootstrapped and tested on x86_64-li
On 3/9/23 13:38, Arsen Arsenović wrote:
Found the change. HTML got support for CONTENTS_OUTPUT_LOCATION,
which defaults to after_top, which ignores the inline location of
these elements. Here's a patch:
maintainer-scripts/ChangeLog:
* update_web_docs_git: Set CONTENTS_OUTPUT_LOCATION
At present, map/to/from clauses on OpenMP "target" directives may be
expanded into several mapping nodes if they describe array sections with
pointer or reference bases, or similar. This patch allows the original
clause to be replaced during that expansion, mostly by passing the list
pointer to th
This patch fixes "exit data" for (C++) reference-to-pointer struct
components with array sections, such as:
struct S { int *&ptr; [...] };
...
#pragma omp target exit data map(from: str->ptr, str->ptr[0:n])
Such exits need two "detach" operations. We need to unmap
both the pointer and the s
This series implements support for the "array shape-operator" (OpenMP
5.0, 2.1.4) and strided accesses for update operations. It follows on
from the in-review series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609031.html
and makes use of some of the infrastructure introduced in th
docs: update copyright year in libstdc++ manual
gcc/ChangeLog
* libstdc++-v3/doc/xml/faq.xml: update copyright year in libstdc++
manual
---
libstdc++-v3/doc/xml/faq.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v
This takes care of the failing gcc.dg/torture/ftrapv-1.c and
-ftrapv-2.c for cris-elf.
For simplicity, assume simulators are the GNU simulator (in the gdb
repo). But cris-elf is newlib, so a newlib target forking? Yes: the
I/O, etc. interface to the simulator uses the Linux/CRIS ABI.
*
Committed as obvious.
-- >8 --
Targets that don't support scheduling get a warning:
cc1: warning: instruction scheduling not supported on this target machine
Do like other target-generic tests unconditionally passing
-fschedule-insns: require effective target scheduling.
* gcc.dg/pr108117
Committed as obvious.
-- >8 --
Targets that don't support prefetching get a warning:
cc1: warning: '-fprefetch-loop-arrays' not supported for this target
Align with other tests passing -fprefetch-loop-arrays for
all targets: add "-w" to options.
* gcc.dg/pr106397.c: Add -w to options.
---
In simple_dce_from_worklist, we were removing an inline-asm which had a vdef.
We should not be removing inline-asm which have a vdef as this code
does not check to the store.
This fixes that oversight. This was a latent bug exposed recently
by both VRP and removal of stores to static starting to us
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
power of two. The RISC-V target has vector modes (e.g. VNx1DImode) that
are not a power of two.
Tested on RISCV and x86_64-linux-gnu. Okay?
2023-03-09
On Fri, Mar 10, 2023 at 07:01:29PM +0100, Richard Biener via Fortran wrote:
>
>
> > Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran
> > :
> >
> > Hello world, here's the patch that was discussed.
> >
> > Regression-tested. OK for trunk?
> >
> > Since this appeared only in gcc13, I s
std::span is a view and therefore should be treated as a reference
wrapper class for the purposes of -Wdangling-reference. I'm not sure
there's a pattern that we could check for.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107532
gcc/cp/ChangeLog:
* call
On Fri, 10 Mar 2023, Sandra Loosemore wrote:
> AFAIK we have not knowingly changed any specific requirements beyond the
> stated 4.7 and 4.9 for PDF output, but it concerns me that nobody is
> likely to be using versions that old on a regular basis to make sure
> they continue to work and we hav
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a61d3ae06df..3c533cb651d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -318,6 +318,7 @@ from other maintainers or reviewers.
Ma
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Better not to ICE after various valid errors.
PR c++/108972
gcc/cp/ChangeLog:
* lambda.cc (compare_lambda_template_head): Check more
for error_mark_node.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-l
On 3/10/23 11:17, Marek Polacek wrote:
We crash here since r10-3661, the store_init_value hunk in particular.
Before, we called cp_fully_fold_init, so e.g.
{.str=VIEW_CONVERT_EXPR("")}
was folded into
{.str=""}
but now we don't fold and keep the VCE around, and it causes trouble in
cxx_
On 3/10/23 10:43, Jakub Jelinek wrote:
Hi!
This is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
patches (to be precise, the latter isn't essential for it), I've
realized that for the PR10770
On 11/24/22 04:13, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-
On 3/9/23 14:40, Jakub Jelinek wrote:
Hi!
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds
Jakub Jelinek writes:
> On Wed, Mar 01, 2023 at 01:32:43PM +0100, Jakub Jelinek via Gcc-patches wrote:
>> On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches
>> wrote:
>> > On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via
>> > Gcc-patches wrote:
>> > > Thoughts on
On Fri, Mar 10, 2023 at 07:07:36PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2023 at 07:44:53PM -0500, Marek Polacek wrote:
> > On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote:
> > > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> > > > I think this is a reasonab
On 3/10/23 10:51, Sandra Loosemore wrote:
On 3/10/23 01:50, Iain Sandoe wrote:
Hi all,
On 9 Mar 2023, at 23:35, Sandra Loosemore via Gcc-patches
wrote:
On 3/9/23 01:26, Richard Biener wrote:
SLES 12 has texinfo 4.13a, SLES 15 has texinfo 6.5. We still
provide up-to-date GCC for SLES 12 bu
Sorry for the slow reply.
Prathamesh Kulkarni writes:
> Unfortunately it regresses code-gen for the following case:
>
> svint32_t f(int32x4_t x)
> {
> return svdupq_s32 (x[0], x[1], x[2], x[3]);
> }
>
> -O2 code-gen with trunk:
> f:
> dup z0.q, z0.q[0]
> ret
>
> -O2 code-gen
On Thu, Mar 09, 2023 at 07:44:53PM -0500, Marek Polacek wrote:
> On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> > > I think this is a reasonable way to address the regression, so OK.
> >
> > It is true that both
> Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran
> :
>
> Hello world, here's the patch that was discussed.
>
> Regression-tested. OK for trunk?
>
> Since this appeared only in gcc13, I see no need for a backport.
> I will also document this in the changes file.
The „problem“ is l
On Fri, Mar 10, 2023 at 06:54:10PM +0100, Thomas Koenig via Gcc-patches wrote:
> Hello world, here's the patch that was discussed.
>
> Regression-tested. OK for trunk?
>
> Since this appeared only in gcc13, I see no need for a backport.
> I will also document this in the changes file.
>
> Best r
Hello world, here's the patch that was discussed.
Regression-tested. OK for trunk?
Since this appeared only in gcc13, I see no need for a backport.
I will also document this in the changes file.
Best regards
Thomas
Set -frapv if -std=legacy is set.
Fortran legacy codes sometimes cont
On 3/10/23 01:50, Iain Sandoe wrote:
Hi all,
On 9 Mar 2023, at 23:35, Sandra Loosemore via Gcc-patches
wrote:
On 3/9/23 01:26, Richard Biener wrote:
SLES 12 has texinfo 4.13a, SLES 15 has texinfo 6.5. We still
provide up-to-date GCC for SLES 12 but we can probably manage in
some ways when
After r6-2044-g98e30e515f184b, code like "((x & 0xff00ff00U) >> 8)"
would be optimized like (x >> 8) & 0xff00ffU which is normally better
except on aarch64, the shift right could be combined with another
operation in some cases. So we need to add a few define_splits
to the aarch64 backends that mat
Note that in HTML < and > have a special meaning, so we cannot simply
write "<* noreturn *>", but need to escape it as "<* noreturn *>".
Pushed.
Gerald
---
htdocs/gcc-13/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/
> Hi,
>
> Looking into the behavior of profile count updating in PR 107925, I
> noticed that an option not considered possible was actually happening,
> and - with the guesswork in place to distribute unexplained counts -
> it simply can happen. Currently it is handled by dropping the counts
> to
> Hi,
>
> the patch below fixes various issues in function
> update_specialized_profile. The main is removal of the assert which
> is bogus in the case of recursive cloning. The division of
> unexplained counts is guesswork, which then leads to updates of counts
> of recursive edges, which then
Hi!
Pushed to master branch commit f8332e52a498df480f72303de32ad0751ad899fe
"Use 'GOMP_MAP_VARS_TARGET' for OpenACC compute constructs [PR90596]",
see attached.
libgomp/oacc-parallel.c| 13 +-
libgomp/plugin/plugin-gcn.c| 47 ++-
libgomp/plugin/plugin-nvptx.c | 154 ++
If a bound region gets overwritten with UNKNOWN due to being
possibly-aliased during a write, that could have been the only
region keeping its value live, in which case we could falsely report
a leak. This is hidden somewhat by the "uncertainty" mechanism for
cases where the write happens in the s
Jakub Jelinek writes:
> On Fri, Mar 10, 2023 at 11:50:39AM +, Richard Sandiford wrote:
>> > Will test it momentarily (including the patch it depends on):
>
> Note, testing still pending, I'm testing in a Fedora scratch build
> and that is quite slow (lto bootstrap and the like).
>
>> A naive q
We crash here since r10-3661, the store_init_value hunk in particular.
Before, we called cp_fully_fold_init, so e.g.
{.str=VIEW_CONVERT_EXPR("")}
was folded into
{.str=""}
but now we don't fold and keep the VCE around, and it causes trouble in
cxx_eval_store_expression: in the !refs->is_emp
Hi Gerald,
Gerald Pfeifer writes:
> On Fri, 10 Mar 2023, Arsen Arsenović wrote:
>> Thanks, Thomas. I'd be happy to undergo this process later today. If I
>> understood right, I should fill out
>> https://sourceware.org/cgi-bin/pdw/ps_form.cgi and name you, right?
>
> Yes.
Thanks, done. Exci
Afternoon,
Sandra Loosemore writes:
> On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
>> The @gol macro appears to have existed as a workaround for a bug in old
>> versions of makeinfo and/or texinfo.tex, where they would, in some types
>> of output, fail to emit line breaks in @gccoptl
On Fri, 10 Mar 2023, Arsen Arsenović wrote:
> Thanks, Thomas. I'd be happy to undergo this process later today. If I
> understood right, I should fill out
> https://sourceware.org/cgi-bin/pdw/ps_form.cgi and name you, right?
Yes.
(Thomas, you, and me actually could have met a FOSDEM. Next year
> Am 10.03.2023 um 16:36 schrieb Jonathan Wakely via Gcc-patches
> :
>
> Bootstrapped and regtested on powerpc64le-linux.
>
> OK for trunk?
Ok.
Thanks,
Richard
> It's safe to do now rather than waiting for Stage 1, because if we were
> actually relying on copy-assigning these types it wo
Hi!
This is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
patches (to be precise, the latter isn't essential for it), I've
realized that for the PR107703 bugfix in the first patch I haven't
add
On Fri, Mar 10, 2023 at 11:50:39AM +, Richard Sandiford wrote:
> > Will test it momentarily (including the patch it depends on):
Note, testing still pending, I'm testing in a Fedora scratch build
and that is quite slow (lto bootstrap and the like).
> A naive question:
>
> > --- libgcc/config
Bootstrapped and regtested on powerpc64le-linux.
OK for trunk?
It's safe to do now rather than waiting for Stage 1, because if we were
actually relying on copy-assigning these types it would have failed to
compile with this change. So it has no functional change, but will help
prevent any future
Hi!
On 2021-07-27T12:01:18+0200, I wrote:
> On 2021-06-29T16:42:03-0700, Julian Brown wrote:
>> This patch fixes several places in libgomp/target.c where "ephemeral" data
>> (on the stack or in temporary heap locations) may be used as the source of
>> an asynchronous host-to-device copy that may
Hi!
Pushed to master branch commit 199867d07be65cb0227a318ebf42b8376ca09313
"Simplify OpenACC 'no_create' clause implementation", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter
Hi!
Pushed to master branch commit b5037d4a073f2e4625afab5ec1f35624d9f9eba1
"OpenACC: Remove 'acc_async_test' -> skip shortcut in
'libgomp/oacc-async.c:goacc_wait'",
see attached.
Chung-Lin, in case you did "worry" ;-) -- no need to, this code dates
back way before your "async re-work".
Grüße
> Am 10.03.2023 um 15:12 schrieb Tamar Christina via Gcc-patches
> :
>
>
>>
As Andrew has been advising on this one, I'd prefer for him to review it.
However, he's on vacation this week. FYI...
Aldy
On Mon, Mar 6, 2023 at 12:22 PM Tamar Christina
wrote
Hi!
In order to document/verify one aspect of OpenACC 'async' semantics, I've
pushed to master branch commit 442d51a20ef13a8e6c080ca30bc37fc93b6bfac4
"Document/verify another aspect of OpenACC 'async' semantics in
'libgomp.oacc-c-c++-common/data-3.c'",
see attached.
Grüße
Thomas
> >> As Andrew has been advising on this one, I'd prefer for him to review it.
> >> However, he's on vacation this week. FYI...
> >>
> >> Aldy
> >>
> >> On Mon, Mar 6, 2023 at 12:22 PM Tamar Christina
> >> wrote:
> >>> Ping.
> >>>
> >>> And updated the patch to reject cases that we don't expect o
Hi!
On 2019-09-06T09:02:13-0700, Julian Brown wrote:
> This patch adds profiling support to the AMD GCN libgomp plugin, modeled
> after the equivalent support in the NVPTX plugin. This gives a positive
> test delta in AMD GCN offload testing.
Yay! \o/
> I will apply to the openacc-gcc-9-branch
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were failing to come up with the name for the anonymous union. It seems
like unfortunate redundancy, but the ABI does say that the name of an
anonymous union is its first named member.
PR c++/108566
gcc/cp/ChangeLog:
*
> On Mar 10, 2023, at 2:54 AM, Richard Biener wrote:
>
> On Thu, 9 Mar 2023, Qing Zhao wrote:
>
>>
>>
>>> On Mar 9, 2023, at 7:20 AM, Richard Biener wrote:
>>>
>>> On Fri, 24 Feb 2023, Qing Zhao wrote:
>>>
GCC extension accepts the case when a struct with a C99 flexible array
m
With calls we now often get contraints like
callarg = *callarg + UNKNOWN
or similar cases. The important thing to note is that this
complex constraint changes the node solution itself, so when
solving the node is marked as changed immediately again. When
that happens it's profitable to iterat
Integration testing showed various false positives from
-Wanalyzer-deref-before-check where the expression that's dereferenced
is different from the one that's checked, but the diagnostic is emitted
because they both evaluate to the same symbolic value.
This patch rejects such warnings, unless we
On 3/9/23 14:37, Tamar Christina wrote:
Cheers,
Thanks! I'll way for him to come back then 😊
Thanks,
Tamar
-Original Message-
From: Aldy Hernandez
Sent: Wednesday, March 8, 2023 8:57 AM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org; nd ; amacl...@redhat.com
Subject: Re: [PATCH 2/4
Hi!
On 2019-11-26T22:49:21+0800, Chung-Lin Tang wrote:
> this is a reorg of the last non-contiguous arrays patch.
(Sorry, this is still not the master branch integration email...)
Just a small clean-up, to simplify other changes that I'm working on:
> (4) Along the way, I've added a 'gomp_map
Sandra Loosemore writes:
> On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
>> maintainer-scripts/ChangeLog:
>> * update_web_docs_git (CSS): Update CSS reference to point to
>> /texinfo-manuals.css.
>
> I'm going to defer to Gerald on this one, since I am ignorant of how docume
Hi Gerald, Thomas,
Thomas Schwinge writes:
> Hi!
>
> On 2023-03-10T01:17:04+0100, Gerald Pfeifer wrote:
>> On Thu, 9 Mar 2023, Sandra Loosemore wrote:
>>> This is OK, but I'd like to see this patch split into two separate
>>> commits as well -- one for the texinfo.tex import, and one for the @g
Morning,
Sandra Loosemore writes:
> On 2/23/23 03:27, Arsen Arsenović via Gcc-patches wrote:
>> The @gol macro appears to have existed as a workaround for a bug in old
>> versions of makeinfo and/or texinfo.tex, where they would, in some types
>> of output, fail to emit line breaks in @gccoptlis
This patch adds the 'Zfa' extension for riscv, which is based on:
https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7
latest 'Zfa' change on the master branch of the RISC-V ISA Manual as
of this writing.
The Wiki Page (details):
https://github.com/a4lg/binu
Jakub Jelinek writes:
> On Fri, Mar 10, 2023 at 08:43:02AM +, Richard Sandiford wrote:
>> > So, either __bf16 should be also extended floating-point type
>> > like decltype (0.0bf16) and std::bfloat16_t and in that case
>> > it is fine if it mangles u6__bf16, or __bf16 will be a distinct
>> >
On Fri, 10 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> This patch, incremental to the just posted one, improves the reverse
> operation ranges significantly by widening just by 0.5ulp in each
> direction rather than 1ulp. Again, REAL_VALUE_TYPE has both wider
> exponent range and wider mantissa pre
Hi!
On 2021-06-30T10:28:00+0200, I wrote:
> On 2021-06-29T16:42:00-0700, Julian Brown wrote:
>> - The OpenACC profiling-interface implementation did not measure
>>asynchronous operations properly.
>
> We'll need to be careful: (possibly, an older version of) that one we
> internally had iden
Tested x86_64-linux (GDB 13.1).
Pushed to trunk for now, will do backports too.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/109064
* python/libstdcxx/v6/xmethods.py (SharedPtrUseCountWorker):
Remove self-recursion in __init__. Add missing _supports.
* testsuite
On Fri, Mar 10, 2023 at 08:43:02AM +, Richard Sandiford wrote:
> > So, either __bf16 should be also extended floating-point type
> > like decltype (0.0bf16) and std::bfloat16_t and in that case
> > it is fine if it mangles u6__bf16, or __bf16 will be a distinct
> > type from the latter two,
>
The following allows to get PTA stats with -stats without blowing
up your filesystem by guarding constraint and solution dumping
with TDF_DETAILS and the SSA points-to info with TDF_DETAILS
or TDF_ALIAS.
Queued for stage1.
* tree-ssa-structalias.cc (dump_sa_stats): Split out from...
Andrew Pinski via Gcc-patches writes:
> After r6-2044-g98e30e515f184b, code like "((x & 0xff00ff00U) >> 8)"
> would be optimized like (x >> 8) & 0xff00ffU which is normally better
> except on aarch64, the shift right could be combined with another
> operation in some cases. So we need to add a few
Bernhard Reutner-Fischer via Gcc-patches writes:
> On 7 March 2023 07:21:23 CET, juzhe.zh...@rivai.ai wrote:
>>From: Ju-Zhe Zhong
>>
>
>>+class vleff : public function_base
>>+{
>>+public:
>>+ unsigned int call_properties (const function_instance &) const override
>>+ {
>>+return CP_READ_ME
Hi!
On 2023-03-10T01:17:04+0100, Gerald Pfeifer wrote:
> On Thu, 9 Mar 2023, Sandra Loosemore wrote:
>> This is OK, but I'd like to see this patch split into two separate
>> commits as well -- one for the texinfo.tex import, and one for the @gol
>> changes.
>
> I believe Arsen does not have git w
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
> Meh - I wonder if we can avoid all this by making float_widen_lhs_range
> friend of frange and simply access m_min/m_max directly and use the
> copy-CTOR to copy bounds and nan state ... after all verify_range
> will likely fail afte
On 3/10/23 09:37, Jakub Jelinek wrote:
Hi!
I'd like to ping this patch (as I wrote a week ago, NightStrike has tested
it):
Thanks, pushed to master branch.
On Fri, 2023-03-10 at 09:05 +, Richard Biener wrote:
> On Fri, 10 Mar 2023, Jakub Jelinek wrote:
>
> > Hi!
> >
> > I'd like to ping these patches. All 3 variants have been
> > bootstrapped/regtested on x86_64-linux and i686-linux, the last
> > one is my preference I guess. The current state
Hi!
I'd like to ping this patch (as I wrote a week ago, NightStrike has tested
it):
On Fri, Mar 03, 2023 at 07:44:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > > 2023-02-22 Jakub Jelinek
> > >
> > > PR target/107998
> > > * config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64
On Fri, 10 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping this patch, which has been successfully
> bootstrapped/regtested on x86_64-linux and i686-linux:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
> - PR108634 - P3 - tree: Use comdat tree_code_{type,len
On Fri, 10 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping these patches. All 3 variants have been
> bootstrapped/regtested on x86_64-linux and i686-linux, the last
> one is my preference I guess. The current state breaks e.g. ccache.
>
> https://gcc.gnu.org/pipermail/gcc-patches/202
Hi!
I'd like to ping this patch, which has been successfully
bootstrapped/regtested on x86_64-linux and i686-linux:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
- PR108634 - P3 - tree: Use comdat tree_code_{type,length} even for C++11/14
Thanks
Jakub
On Thu, Feb
Hi!
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
- PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants
for non-aggregates
Thanks
Jakub
On Thu, Nov 24, 2022 at 10:13:55AM +0100, Jakub Jelinek via Gcc-patches wrot
Hi!
On Wed, Mar 01, 2023 at 01:32:43PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Thoughts on this? I guess my preference
On Fri, 10 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch does two things (both related to range extension
> around the boundaries).
>
> The first part (in the 2 real_isfinite blocks) is to make the ranges
> narrower when the old boundaries are minimum and/or maximum representable
Hi!
I'd like to ping these patches. All 3 variants have been
bootstrapped/regtested on x86_64-linux and i686-linux, the last
one is my preference I guess. The current state breaks e.g. ccache.
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
- PR108464 - P1 - file-prefix-map
Hi all,
> On 9 Mar 2023, at 23:35, Sandra Loosemore via Gcc-patches
> wrote:
>
> On 3/9/23 01:26, Richard Biener wrote:
>
>> SLES 12 has texinfo 4.13a, SLES 15 has texinfo 6.5. We still provide
>> up-to-date GCC for SLES 12 but we can probably manage in some ways
>> when the texinfo requireme
Jakub Jelinek writes:
> On Thu, Mar 09, 2023 at 05:14:11PM +, Richard Sandiford wrote:
>> We decided to keep the current mangling of __bf16 and use it for
>> std::bfloat16_t too. __bf16 will become a non-standard arithmetic type.
>> This will be an explicit diversion from the Itanium ABI.
>>
Tamar Christina writes:
> Hi,
>
> Here's the respun patch.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR target/108583
> * target.def (preferred_div_as_shifts_over_mult): New.
> * doc/tm.texi.i
On Thu, Mar 09, 2023 at 05:14:11PM +, Richard Sandiford wrote:
> We decided to keep the current mangling of __bf16 and use it for
> std::bfloat16_t too. __bf16 will become a non-standard arithmetic type.
> This will be an explicit diversion from the Itanium ABI.
>
> I think that's equivalent
Hi Kewen,
I tested it with my fortran test case. It works. Thanks a lot.
Gui Haochen
在 2023/3/6 17:27, Kewen.Lin 写道:
> Hi,
>
> According to Haochen's finding in [1], currently ppc-fortran.exp
> doesn't support Fortran specific warning or error messages well.
> By looking into it, it's due to t
Committed to trunk, thanks :)
On Wed, Mar 8, 2023 at 3:49 PM Richard Biener wrote:
>
> On Wed, 8 Mar 2023, juzhe.zh...@rivai.ai wrote:
>
> > From: Ju-Zhe Zhong
> >
> > Hi, current maybe_gen_insn can only expand 9 nops.
> > For RVV intrinsics, I need to extend it as 10, otherwise I should use
>
Hi!
This patch, incremental to the just posted one, improves the reverse
operation ranges significantly by widening just by 0.5ulp in each
direction rather than 1ulp. Again, REAL_VALUE_TYPE has both wider
exponent range and wider mantissa precision (160 bits) than any
supported type, this patch u
From: Ju-Zhe Zhong
vfrsub_vf_m.cpp: In function 'int main()':
vfrsub_vf_m.cpp:5:43: error: invalid argument to built-in function
5 | vbool32_t d = __riscv_vmflt_vf_f32m1_b32(c, b, 8);
| ~~^
during RTL pass: expand
vfrsub_vf_m.cpp:5:43
Hi!
The following patch does two things (both related to range extension
around the boundaries).
The first part (in the 2 real_isfinite blocks) is to make the ranges
narrower when the old boundaries are minimum and/or maximum representable
finite number. In that case frange_nextafter gives -Inf
93 matches
Mail list logo
