PR analyzer/109098 notes that the SARIF spec mandates that .sarif
files are UTF-8 encoded, but -fdiagnostics-format=sarif-file naively
assumes that the source files are UTF-8 encoded when quoting source
artefacts in the .sarif output, which can lead to us writing out
.sarif files with non-UTF-8
Successfully bootstrapped on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6859-gfdb06fe68253d2
gcc/ChangeLog:
* doc/analyzer.texi (Debugging the Analyzer): Add notes on useful
debugging options.
(Special Functions for Debugging the Analyzer): Convert to a
table, and
On Thu, Mar 23, 2023 at 04:10:22PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> Thanks for fixing this, some minor comments are inlined below.
>
> on 2023/3/22 07:53, Michael Meissner wrote:
> > The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
> > optimization generates illegal
I posted a version of patch on March 21st. This patch makes some code changes
suggested in the genfusion.pl code. The only change is in genfusion.pl. The
fusion.md that it makes is the same.
The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
optimization generates illegal
On Fri, Mar 24, 2023 at 06:11:44PM -0400, Jason Merrill wrote:
> > When we touch this for COMPONENT_REF, shouldn't we then handle it as
> > unary given that the second operand is FIELD_DECL and third/fourth
> > will likely be NULL and even if not, aren't user expressions that should be
> >
On 3/23/23 17:03, Jakub Jelinek wrote:
On Thu, Mar 23, 2023 at 04:35:07PM -0400, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Jakub, does this make sense to you? Do we have a
way of testing for compile-hog regressions?
-- 8< --
The patch for PR91415 fixed -Wsequence-point to treat
Hi!
The testcase in the PR (which unfortunately because of my lack of experience
with SVE I'm not able to turn into a runtime testcase that verifies it)
is miscompiled on aarch64-linux in the regname pass, because while the
function takes arguments in the p0 register, FUNCTION_ARG_REGNO_P doesn't
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param
register
and thus due to our ABI, already correctly sign/zero extended?
>>>
>>> I don't think REE has ever considered exploiting ABI constraints. Handling
>>>
Dear all,
while looking at variations of testcases in pr107560, I discovered
a minor FE memleak that was introduced in the BOZ rework and is
fixed by the attached simple patch.
Regtested on x86_64-pc-linux-gnu on OK'ed in the PR by Steve.
Thanks,
Harald
From
On Fri, Mar 24, 2023 at 1:14 AM Fangrui Song via Gcc-patches
wrote:
>
> On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
> wrote:
> >
> >
> >
> > > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches
> > > wrote:
> > >
> > > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov
On Fri, 2023-03-24 at 18:45 +0100, Alejandro Colomar wrote:
> Hi David,
>
> On 3/24/23 15:53, David Malcolm wrote:
> > On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-
> > patches
> > wrote:
> > > Warn about the following:
> > >
> > > char s[3] = "foo";
> > >
> [...]
>
> > >
Hi!
On Thu, Mar 23, 2023 at 12:06:39AM -0300, Alexandre Oliva wrote:
> On Mar 13, 2023, Segher Boessenkool wrote:
> > Yes. On most architectures you can get multiple machine instructions of
> > course (for long calls for example), but on rs6000 (with some ABIs, in
> > some circumstances) we
Hi David,
On 3/24/23 15:53, David Malcolm wrote:
> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches
> wrote:
>> Warn about the following:
>>
>> char s[3] = "foo";
>>
[...]
>> ---
>>
>> Hi,
>
> Hi Alex, thanks for the patch.
:)
>
>>
>> I sent v1 to the wrong list.
Jakub Jelinek writes:
> 2023-03-24 Jakub Jelinek
>
> PR middle-end/109258
> * go-gcc.cc (Gcc_backend): Add new static data members builtin_pure
> and builtin_nothrow.
> (Gcc_backend::Gcc_backend): Pass builtin_pure | builtin_nothrow for
> BUILT_IN_MEMCMP.
>
Stumbled over 'Reverse offload are', fixed by changing it to 'Reverse
offload regions are'.
Committed as r13-6854
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
On Fri, Mar 24, 2023 at 11:52:30AM -0400, Andrew MacLeod wrote:
> Thanks.. Ive incorporated it into my commit too.
Note, both my earlier version of the patch and your patch regress:
FAIL: gcc.dg/tree-ssa/vrp-float-3a.c scan-tree-dump-not evrp "link_error"
FAIL: gcc.dg/tree-ssa/vrp-float-4a.c
Hi!
This had fallen out of some earlier work of mine; I've now pushed to
devel/omp/gcc-12 branch commit ae2dca26602678f8b70e22da1bce8302c0751b75
"Add 'libgomp.c/alloc-ompx_host_mem_alloc-1.c'", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the case
for partial ordering.
PR c++/105481
gcc/cp/ChangeLog:
* pt.cc
Just to keep track myself, the following OpenMP are pending review - either
by Jakub or by me. It does not look as if any of those will get into GCC 13,
but who knows. I think the first three could:
[Doc patch - will go into GCC 13, still comments are welcome:]
[patch V2] Docs, OpenMP: Correct
Hi!
On 2023-02-16T18:06:41+, Andrew Stubbs wrote:
> 2. 230216-amd-low-lat.patch
>
> Allocate the memory, adjust the default address space, and hook up the
> allocator.
Like done for nvptx in og12 commit 23f52e49368d7b26a1b1a72d6bb903d31666e961
"Miscellaneous clean-up re OpenMP
On 3/23/23 11:00, Patrick Palka wrote:
Here when resolving the implicit object for '' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context. And yet at this point
current_class_ref still corresponds to the outer class
> "Segher" == Segher Boessenkool writes:
>> FWIW I sent a gdb patch to work around this bug. However, in my
>> examples, I only ever saw a nop following the call instruction -- so I
>> had gdb check for this.
Segher> GCC inserts just a nop in most cases, but the linker or dynamic linker
Hi!
On 2023-02-28T11:56:01+0100, I wrote:
> I'm currently reviewing 'gomp_copy_host2dev', 'ephemeral' in a different
> context, and a question came up here;
> commit r13-706-g49d1a2f91325fa8cc011149e27e5093a988b3a49
> "OpenMP: Handle descriptors in target's firstprivate [PR104949]":
It doesn't
> Am 24.03.2023 um 15:44 schrieb David Malcolm via Gcc-patches
> :
>
> I'd like to ping the following patch for review:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614165.html
Ok.
Richard
> Thanks
> Dave
>
>> On Fri, 2023-03-17 at 16:53 -0400, David Malcolm wrote:
>> PR
Thanks.. Ive incorporated it into my commit too.
Andrew
On 3/24/23 11:15, Jakub Jelinek wrote:
On Fri, Mar 24, 2023 at 11:08:54AM -0400, Andrew MacLeod wrote:
Before floating point relations were added, we tried to sanitize
value-relation records to not include non-sensensical records... ie
Add the parsing of loop transformations on inner loops of a loop-nest.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_nested_loop_transform_clauses):
Add argument for the level of loop-nest at which the clauses
appear, ...
(c_parser_omp_tile): ... adjust use here,
So far the implementation of the "omp tile" and "omp unroll"
directives restricted their use to the outermost loop of a loop-nest.
This commit changes the Fortran front end to parse and verify the
directives on inner loops. The transformation clauses are extended to
carry the information about
Hi!
On 2022-01-04T15:32:17+, Andrew Stubbs wrote:
> This patch implements the OpenMP pinned memory trait [...]
I figure it may be helpful to document the current og12 state of affairs;
does the attached "libgomp: Document OpenMP 'pinned' memory" look good to
you?
Grüße
Thomas
This commit adds the C and C++ front end support for the "omp tile"
directive.
gcc/c-family/ChangeLog:
* c-omp.cc (c_omp_directives): Add PRAGMA_OMP_TILE.
* c-pragma.cc (omp_pragmas_simd): Likewise.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_TILE.
(enum
This commit implements the Fortran front end support for the "omp
tile" directive and the corresponding middle end transformation.
gcc/fortran/ChangeLog:
* gfortran.h (enum gfc_statement): Add ST_OMP_TILE, ST_OMP_END_TILE.
(enum gfc_exec_op): Add EXEC_OMP_TILE.
Hi!
On 2023-03-15T15:47:47+0100, I wrote:
> 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...)
>
>
> I noticed the following while working on something else:
>
>> ---
Hi!
On 2023-03-21T16:53:31+0100, I wrote:
> On 2022-08-26T11:07:28+0200, Tobias Burnus wrote:
>> This patch adds initial [OpenMP reverse offload] support for nvptx.
>
>> CUDA does lockup when trying to copy data from the currently running
>> stream; hence, a new stream is generated to do the
Hi!
On 2020-12-04T22:15:46+0800, Chung-Lin Tang wrote:
> this is a new version of the structure element mapping patch for OpenMP 5.0
> requirement
> changes.
> (gomp_exit_data): [...]
> adjust to queue splay-tree keys for removal
> after main loop.
> --- a/libgomp/target.c
>
OMP_CLAUSE_TILE will be used for the OpenMP 5.1 loop transformation
construct "omp tile".
gcc/ChangeLog:
* tree-core.h (enum omp_clause_code): Rename OMP_CLAUSE_TILE.
* tree.h (OMP_CLAUSE_TILE_LIST): Rename to ...
(OMP_CLAUSE_OACC_TILE_LIST): ... this.
This commit implements the C and the C++ front end changes to support
the "omp unroll" directive. The execution of the loop transformation
relies on the pass that has been added as a part of the earlier
Fortran patch.
gcc/c-family/ChangeLog:
* c-gimplify.cc (c_genericize_control_stmt):
Hi,
this patch series implements the OpenMP 5.1 "unroll" and "tile"
constructs. It includes changes to the C,C++, and Fortran front end
for parsing the new constructs and a new middle-end
"omp_transform_loops" pass which implements the transformations in a
source language agnostic way. The
On Fri, Mar 24, 2023 at 11:08:54AM -0400, Andrew MacLeod wrote:
> Before floating point relations were added, we tried to sanitize
> value-relation records to not include non-sensensical records... ie x != x
> or x < x. Instead, we made a VREL_VARYING record with no operands.
>
> When floating
Before floating point relations were added, we tried to sanitize
value-relation records to not include non-sensensical records... ie x !=
x or x < x. Instead, we made a VREL_VARYING record with no operands.
When floating point relation support was added, some of these were no
longer
On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches
wrote:
> Warn about the following:
>
> char s[3] = "foo";
>
> Initializing a char array with a string literal of the same length as
> the size of the array is usually a mistake. Rarely is the case where
> one wants to
I'd like to ping the following patch for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614165.html
Thanks
Dave
On Fri, 2023-03-17 at 16:53 -0400, David Malcolm wrote:
> PR other/109163 notes that when we write out JSON files, we traverse
> the keys within each object via
From: Pan Li
Fix the bug of the incorrect code generation for the
below code sample.
typedef unsigned short __attribute__((__vector_size__ (32))) V;
typedef unsigned short u16;
void
foo (V m, u16 *ret)
{
V v = 6 > ((V) { 2049, 8 } & m);
*ret = v[0]; // + a + b + c + d;
}
Before this
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
In some cases, for writing
> >
> > Actually on second thought, I think I can break this either by making
> > the wraping function to be thunk or alias or by moving it to different
> > compilation unit.
> > Also with LTO we will get body later.
> >
> > So I think we need to drop this optimization.
>
> It's the same
Emulated gather/scatter behave similar to strided elementwise
accesses in that they need to decompose the offset vector
and construct or decompose the data vector so handle them
the same way, pessimizing the cases with may elements.
For pr88531-2c.c instead of
.L4:
leaq(%r15,%rcx),
This adds a scatter vectorization capability to the vectorizer
without target support by decomposing the offset and data vectors
and then performing scalar stores in the order of vector lanes.
This is aimed at cases where vectorizing the rest of the loop
offsets the cost of vectorizing the
> Emulated gather/scatter behave similar to strided elementwise
> accesses in that they need to decompose the offset vector
> and construct or decompose the data vector so handle them
> the same way, pessimizing the cases with may elements.
>
> For pr88531-2c.c instead of
>
> .L4:
> leaq
On Fri, 24 Mar 2023, Jan Hubicka wrote:
> > From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> > From: Richard Biener
> > Date: Thu, 16 Mar 2023 13:51:19 +0100
> > Subject: [PATCH] tree-optimization/106912 - clear const attribute from
> > fntype
> > To:
> From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> From: Richard Biener
> Date: Thu, 16 Mar 2023 13:51:19 +0100
> Subject: [PATCH] tree-optimization/106912 - clear const attribute from fntype
> To: gcc-patches@gcc.gnu.org
>
> The following makes sure that after clearing
Hi!
The following patch attempts to document the PR36113 changes to the
GNU C extension support of enumerators which don't fit into int.
Ok for wwwdocs?
Shall we mention it in porting_to.html as well?
The only known affected package is (was?) the Linux kernel.
diff --git
On Fri, Mar 3, 2023 at 10:28 AM Andrew Pinski wrote:
>
> On Thu, Feb 9, 2023 at 7:54 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > The problem here is that aarch64_expand_setmem does not change the alignment
> > for strict alignment case.
> > This is version 4 of the fix, major changes from
> On Fri, 17 Mar 2023, Jakub Jelinek wrote:
>
> > On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > > > + /* Drop the const attribute from the call type (the pure
> > > > + attribute is not available on types). */
> > > > + tree fntype
Hi!
This PR was fixed by r13-1268-g8c99e307b20, I'm adding testcase
to make sure we don't regress on it in the future.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2023-03-24 Jakub Jelinek
PR tree-optimization/99739
*
On Mon, 20 Mar 2023, Richard Biener wrote:
> On Fri, 17 Mar 2023, Jakub Jelinek wrote:
>
> > On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > > > + /* Drop the const attribute from the call type (the pure
> > > > + attribute is not available on
Prior to the removal of STABS support the gdwarf, gstabs, ... options
formed a cycle with their Negative(..) option attribute. But that
didn't actually have any effect since most of the options also
are Joined or JoinedOrMissing for which there's no pruning of options
and so once ran into the
The following adds RejectNegative to the gdwarf, gdwarf-, ggdb and gvms
options since the current behavior is to treat the negative variant
the same as the positive variant. In particular -ggdb -gno-gdb
do not cancel, and plain -gno-dwarf will enable (dwarf!) debug output.
Rejecting the negative
On Fri, 24 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> The PR109086 r13-6690 inline_string_cmp change to
> if (diff != result)
> emit_move_insn (result, diff);
> regressed
> FAIL: go.test/test/fixedbugs/bug207.go, -O2 -g (internal compiler error: in
> emit_move_insn, at expr.cc:4224)
Hi!
The PR109086 r13-6690 inline_string_cmp change to
if (diff != result)
emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go, -O2 -g (internal compiler error: in
emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp
Hi!
The PR109086 r13-6690 inline_string_cmp change to
if (diff != result)
emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go, -O2 -g (internal compiler error: in
emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp
Hi!
On Wed, Mar 22, 2023 at 01:37:39PM -0400, Vladimir Makarov via Gcc-patches
wrote:
> * gcc.target/i386/pr109137.c: New.
The testcase has a couple of small problems:
1) had -m32 in dg-options, that should never be done, instead the test
should be guarded on ia32
2) adds -fPIC
On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
wrote:
>
>
>
> > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches
> > wrote:
> >
> > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov
> > wrote:
> >>
> >>
> >> On Wed, 22 Mar 2023, Richard Biener wrote:
> >>
> >>> I think
On Thu, Mar 23, 2023 at 7:37 PM Andrew MacLeod via Gcc-patches
wrote:
>
> Detailed info in the PR.
>
> As we walk the DOM tree to calculate ranges, any block with multiple
> predecessors is processed by evaluating and unioning incoming values.
> This catches more complex cases where the dominator
On Thu, Mar 23, 2023 at 7:05 PM Martin Jambor wrote:
>
> Hello,
>
> On Wed, Mar 22 2023, Richard Biener wrote:
> > On Tue, Mar 21, 2023 at 8:25 PM Martin Jambor wrote:
> >>
> >> Hello,
> >>
> >> is the following item documenting that gcc13 can generate code for Zen 4
> >> OK for the changes.html
From: Juzhe-Zhong
Co-authored-by: kito-cheng
Co-authored-by: kito-cheng
This patch fixes the issue of incorrect reigster order of RVV.
The new register order is coming from kito original RVV GCC implementation.
Consider this case:
void f (void *base,void *base2,void *out,size_t vl, int n)
{
From: Juzhe-Zhong
This patch fixes the issue of incorrect reigster order of RVV.
The new register order is coming from kito original RVV GCC implementation.
Consider this case:
void f (void *base,void *base2,void *out,size_t vl, int n)
{
vuint64m8_t bindex = __riscv_vle64_v_u64m8 (base +
On Fri, Mar 3, 2023 at 10:14 PM Jerry D via Fortran wrote:
> I am certainly not a C++ expert but it seems to me this all begs for
> automatic finalization where one would not have to invoke free at all.
> I suspect the gfortran frontend is not designed for such things.
+1 for RAII
Hi Juzhe,
Thank you for your reply, I'm really doing some optimization work right now.
I am very interested in the question you have raised, and I will take the time
to try to optimize it.
I hope I can communicate with you and learn from you more in the future.
Thanks.
66 matches
Mail list logo
