e the capture provides code access to local variables like "insn".
Without this patch, the issued code was basically return { code };
The patch bootstraps + regtests with no changes.
Ok for trunk?
Johann
p.s. Some months ago I discussed the feature with Richard, and he said
that the
: New file.
* sym-exec-condition.h: New file.
* sym-exec-expression-is-a-helper.h: New file.
* sym-exec-expression.cc: New file.
* sym-exec-expression.h: New file.
* sym-exec-state.cc: New file.
* sym-exec-state.h: New file.
Patch not attached.
jeff
On 9/13/24 5:06 AM, Mariam Arutunian wrote:
This patch adds a new compiler pass aimed at identifying naive CRC
implementations,
characterized by the presence of a loop calculating a CRC (polynomial
long division).
Upon detection of a potential CRC, the pass prints an informational message
On 9/13/24 5:06 AM, Mariam Arutunian wrote:
gcc/testsuite/gcc.target/aarch64/
* crc-builtin-pmul64.c: New test.
OK
jeff
On 9/13/24 5:06 AM, Mariam Arutunian wrote:
This patch introduces two new expanders for the aarch64 backend,
dedicated to generate optimized code for CRC computations.
The new expanders are designed to leverage specific hardware
capabilities to achieve faster CRC calculations,
particularly
On 9/13/24 5:05 AM, Mariam Arutunian wrote:
This patch introduces two new expanders for the i386 backend,
dedicated to generating optimized code for CRC computations.
The new expanders are designed to leverage specific hardware
capabilities to achieve faster CRC calculations,
particularly
On 9/13/24 5:05 AM, Mariam Arutunian wrote:
gcc/testsuite/gcc.target/riscv/
* crc-builtin-zbc32.c: New file.
* crc-builtin-zbc64.c: Likewise.
OK
jeff
On 9/13/24 5:05 AM, Mariam Arutunian wrote:
If the target is ZBC or ZBKC, it uses clmul instruction for the CRC
calculation. Otherwise, if the target is ZBKB, generates
table-based
CRC, but for reversing inputs and the output uses bswap and brev8
instructions. Add new
* Andrew Pinski:
>> + append (flags & SECTION_CODE, "CODE");
>
> I notice you capture result and it seems like you could also capture
> flags and change this to:
> append (SECTION_CODE, "CODE");
Thanks, I've made the change locally.
Florian
On 9/13/24 5:05 AM, Mariam Arutunian wrote:
This patch introduces new built-in functions to GCC for computing bit-
forward and bit-reversed CRCs.
These builtins aim to provide efficient CRC calculation capabilities.
When the target architecture supports CRC operations (as indicated by
the
On 9/13/24 5:05 AM, Mariam Arutunian wrote:
Add two new internal functions (IFN_CRC, IFN_CRC_REV), to provide faster
CRC generation.
One performs bit-forward and the other bit-reversed CRC computation.
If CRC optabs are supported, they are used for the CRC computation.
Otherwise, table-based
On 9/20/24 3:48 PM, Pietro Monteiro wrote:
From: Pietro Monteiro
SH: Document extended asm operand modifers
gcc/ChangeLog:
* doc/extend.texi (SH Operand Modifiers): New.
Signed-off-by: Pietro Monteiro
---
Tested by running "make info pdf html" and looking at the pdf and html outpu
On Sun, Sep 29, 2024 at 8:13 AM Florian Weimer wrote:
>
> Sometimes this is a user error, sometimes it is more of an ICE.
> In either case, more information about the conflict is helpful.
>
> I used to this to get a better idea about what is going on with
> PR116887. The original diagnostics look
On 9/22/24 7:00 AM, Mikael Pettersson wrote:
The intermediate expression (unsigned char) '\234' * scale overflows
int on int16 targets, causing the test case to fail there. Fixed by
performing the arithmetic in unsigned type, as suggested by Andrew Pinski.
Regression tested on x86_64-pc-linu
On 9/17/24 4:44 AM, Georg-Johann Lay wrote:
This patch updates more web links from nongnu to Github.
The http://www.nongnu.org/avr links still worked, but the
"super project" seems to be deserted. Instead, it now links:
* https://avrdudes.github.io/avr-libc/avr-libc-u
On 9/27/24 1:36 AM, Jovan Vukic wrote:
Based on the valuable feedback I received, I decided to implement the patch
in the RTL pipeline. Since a similar optimization already exists in
simplify_binary_operation_1, I chose to generalize my original approach
and place it directly below that code
le "$SRC/gcc/gcc/gdbhooks.py", line 168, in intptr
return long(gdbval) if sys.version_info.major == 2 else int(gdbval)
gdb.error: Cannot convert value to long.
This patch makes VecPrinter handle such references by stripping them
(dereferencing) at the top of the relevant func
On 9/24/24 2:57 AM, Eikansh Gupta wrote:
This patch simplify `(trunc)copysign ((extend)x, CST)` to `copysign (x,
-1.0/1.0)`
depending on the sign of CST. Previously, it was simplified to `copysign (x,
CST)`.
It can be optimized as the sign of the CST matters, not the value.
The patch also
On 9/24/24 8:55 PM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to implement the sssub form 1. Aka:
Form 1:
#define DEF_SAT_S_SUB_FMT_1(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_sub_##T##_fmt_1 (T x, T y
On 9/25/24 2:30 AM, Eikansh Gupta wrote:
This patch simplify `min(a,b) op max(a,b)` to `a op b`. This optimization
will work for all the binary commutative operations. So, the `op` here can
be one of {plus, mult, bit_and, bit_xor, bit_ior, eq, ne, min, max}.
PR tree-optimization
On 9/29/24 3:16 AM, Yangyu Chen wrote:
Good job. I'm currently working on RISC-V target_clone and
target_versions support in GCC and found this patch is needed as my
prerequisite.
However, I found this tagged as "dropped" on Patchwork. What happened?
I think Kito was going
Sometimes this is a user error, sometimes it is more of an ICE.
In either case, more information about the conflict is helpful.
I used to this to get a better idea about what is going on with
PR116887. The original diagnostics look like this:
dl-find_object.c: In function ‘_dlfo_process_initial’
On Sun, Sep 08, 2024 at 08:48:57AM +0300, Dimitar Dimitrov wrote:
> This test helped discover PR116621, so it is worth being documented.
>
> gcc/ChangeLog:
>
> * doc/sourcebuild.texi: Document struct-layout-1.exp.
>
> Signed-off-by: Dimitar Dimitrov
LGTM.
Jakub
On Sun, Sep 08, 2024 at 08:48:57AM +0300, Dimitar Dimitrov wrote:
> This test helped discover PR116621, so it is worth being documented.
>
> gcc/ChangeLog:
>
> * doc/sourcebuild.texi: Document struct-layout-1.exp.
>
> Signed-off-by: Dimitar Dimitrov
> ---
> gcc/doc/sourcebuild.texi | 18
Good job. I'm currently working on RISC-V target_clone and
target_versions support in GCC and found this patch is needed as my
prerequisite.
However, I found this tagged as "dropped" on Patchwork. What happened?
On Sat, Sep 28, 2024 at 08:32:00PM +0200, Thomas Koenig wrote:
> Hello world,
>
> here's another small patch for FINDLOC for unsigned.
>
> OK for trunk?
>
OK. Other than UNSIGNED being a new experimental feature,
this patch almost qualifies as "Obvious".
--
Steve
OK. Thanks for the patch.
--
steve
On Sat, Sep 28, 2024 at 09:33:20AM +0200, Thomas Koenig wrote:
>
> this patch, consisting almost entirely of the test cases, implements
> CSHIFT and EOSHIFT for unsigneds.
>
> OK for trunk?
>
> Implement CSHIFT and EOSHIFT for u
Hello world,
here's another small patch for FINDLOC for unsigned.
OK for trunk?
Best regards
Thomas
Implement FINDLOC for UNSIGNED.
gcc/fortran/ChangeLog:
* check.cc (intrinsic_type_check): Handle unsigned.
(gfc_check_findloc): Likewise.
* gfortran
define __GTHREAD_INLINE inline __GTHREAD_ALWAYS_INLINE
#else
# define __GTHREAD_INLINE static inline
#endif
and then marking maybe even just the new inline functions with
visibility hidden should be OK?
Nathaniel
Here's a new patch that does this. Also since v1 it adds anothe
Ok for trunk?
Changes since v1:
- Updated the commit message to mention the actual build error.
- Switch to checking the required define rather than the version number of
MinGW.
--
The define ENABLE_VIRTUAL_TERMINAL_PROCESSING was introduced in MinGW
7.0
Build failure when building with MinGW
The following fixes the case when vectorizing a load hoists an invariant
load and dependent stmts, thereby breaking UID order of said stmts.
While we duplicate the load we just move the dependences.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR tree-optimizat
the expression -C2 - 1 can be shortened to
> >> bit_not (C2).
> >>
> >> This transformation allows to occasionally save load-immediate /
> >> subtraction instructions, e.g. the following statement:
> >>
> >> 10 - (int)f() >= 20;
> >>
>
On Fri, 27 Sep 2024, Jakub Jelinek wrote:
> On Fri, Sep 27, 2024 at 12:14:47PM +0200, Richard Biener wrote:
> > I can investigate a bit when there's a testcase showing the issue.
>
> The testcase is pr78687.C with Marek's cp-gimplify.cc patch.
OK, I can reproduce. The
On Sat, Sep 28, 2024 at 5:23 AM H.J. Lu wrote:
>
> On Wed, Sep 25, 2024, 7:06 PM Uros Bizjak wrote:
>>
>> On Wed, Sep 25, 2024 at 11:42 AM H.J. Lu wrote:
>> >
>> > Address override only applies to the (reg32) part in the thread address
>> > fs:(reg32). Don't rewrite thread address like
>> >
>>
Hello world,
this patch, consisting almost entirely of the test cases, implements
CSHIFT and EOSHIFT for unsigneds.
OK for trunk?
Implement CSHIFT and EOSHIFT for unsigned.
gcc/fortran/ChangeLog:
* check.cc (gfc_check_eoshift): Handle BT_UNSIGNED
On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
> So, I think we should go with (but so far completely untested except
> for pr78687.C which is optimized with Marek's patch and the above testcase
> which doesn't have the clearing anymore) the following patch.
T
On Wed, Sep 25, 2024, 7:06 PM Uros Bizjak wrote:
> On Wed, Sep 25, 2024 at 11:42 AM H.J. Lu wrote:
> >
> > Address override only applies to the (reg32) part in the thread address
> > fs:(reg32). Don't rewrite thread address like
> >
> > (set (reg:CCZ 17 flags)
> > (compare:CCZ (reg:SI 98 [
s where a declaration
> > naming a TU-local entity is not an exposure, notably the bodies of
> > non-inline templates and friend declarations in classes. This patch
> > ensures that these references do not error when exporting the module.
> >
> > We do need
On 26 September 2024 20:51:55 CEST, Fangrui Song wrote:
>On Thu, Sep 26, 2024 at 11:21 AM Ramana Radhakrishnan
> wrote:
>>
>> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>> >
>> > From: Fangrui Song
>> >
>> > -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
>> > for
internal linkage to start with).
> > > > >
> > > > > But it sounds like doing something like
> > > > >
> > > > > #ifdef __has_attribute
> > > > > # if __has_attribute(__always_inline__)
> > > > > # define __GTHREAD
On Fri, Sep 20, 2024 at 12:40:29PM -0400, Siddhesh Poyarekar wrote:
> Don't bail out early if the offset to a pointer in __builtin_object_size
> is a variable, return the wholesize instead since that is a better
> fallback for maximum estimate. This should keep checks in place for
> fortified func
On Fri, 2024-09-27 at 09:54 -0400, Lewis Hyatt wrote:
> On Fri, Sep 27, 2024 at 9:41 AM David Malcolm
> wrote:
> >
> > On Thu, 2024-09-26 at 23:28 +0200, Jakub Jelinek wrote:
> > > Hi!
> > >
> > > The following patch on top of the just
On Fri, Sep 27, 2024 at 10:26 AM Jakub Jelinek wrote:
>
> On Fri, Sep 27, 2024 at 09:54:13AM -0400, Lewis Hyatt wrote:
> > A couple comments that may be helpful...
> >
> > -This is also PR 64117 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117)
> >
> > -I
p1, offset_limit) <= 0)
> +|| bytes != wholesize || compare_tree_int (op1, offset_limit) <=
> 0)
> bytes = size_for_offset (bytes, op1, wholesize);
> /* In the static case, with a negative offset, the best estimate for
>minimum size is size_unk
On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote:
> On 9/18/24 5:06 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > 1) We're hitting the assert in cp_parser_placeholder_type_specifier.
> > It says that if it turns out to b
owing statement:
>>
>> 10 - (int)f() >= 20;
>>
>> now compiles to
>>
>> addia0,a0,-11
>> sltia0,a0,-20
>>
>> instead of
>>
>> li a5,10
>> sub a0,a5,a0
>> sltit0,a0,20
>> xoria0,t0,1
>
On 9/18/24 5:06 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) We're hitting the assert in cp_parser_placeholder_type_specifier.
It says that if it turns out to be false, we should do error() instead.
Do so, then.
2) lambda-targ8.C should compi
On 9/5/24 6:32 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
We ICE in decay_conversion with this test:
struct S {
S() {}
};
S arr[1][1];
auto [m](arr3);
But not when the last line is:
auto [n] = arr3;
Therefore t
On 9/19/24 7:56 PM, Nathaniel Shead wrote:
Noticed how to fix this while working on the other patch.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This implements part of P1787 to no longer complain about redeclaring an
entity via using-decl other than i
On 9/19/24 7:53 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
Alternatively I could solve this the other way around (have a new
'old_target = strip_using_decl (old)' and replace all usages of 'old'
except the usages in
en marking maybe even just the new inline functions with
visibility hidden should be OK?
Nathaniel
Here's a new patch that does this. Also since v1 it adds another two
internal linkage declarations I'd missed earlier from libstdc++, in
pstl; it turns out that doesn't include .
e(__always_inline__)
> >># define __GTHREAD_ALWAYS_INLINE __attribute__((__always_inline__))
> >># endif
> >>#endif
> >>#ifndef __GTHREAD_ALWAYS_INLINE
> >># define __GTHREAD_ALWAYS_INLINE
> >>#endif
> >>
> >>#ifd
On 9/27/24 1:58 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
A header unit may contain anonymous namespaces, and those declarations
are exported (as with any declaration in a header unit). This patch
ensu
Le 27/09/2024 à 17:08, Thomas Koenig a écrit :
Hi Mikael,
Now for the remaining intrinsics (FINDLOC, MAXLOC,
MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing).
I have one patch series touching (inline) MINLOC and MAXLOC to post in
the coming days. Could you please keep away from
CO-RE accesses with non pointer struct variables will also generate a
"0" string access within the CO-RE relocation.
The first index within the access string, has sort of a different
meaning then the remaining of the indexes.
For i0:i1:...:in being an access index for "struct A a" declaration, its
define __GTHREAD_ALWAYS_INLINE
#endif
#ifdef __cplusplus
# define __GTHREAD_INLINE inline __GTHREAD_ALWAYS_INLINE
#else
# define __GTHREAD_INLINE static inline
#endif
and then marking maybe even just the new inline functions with
visibility hidden should be OK?
Nathaniel
Here'
On Fri, Sep 27, 2024 at 08:12:01PM +0200, Andre Vehreschild wrote:
>
> the testcase is in the coarray directory, where tests are executed mit
> -fcoarray=single and lib. I don't know about none. Because the code stops
> compiling when it encounters a coarray with no single or lib. Therefore I
> su
be something requiring exporting. This is normally
handled for a declaration by set_instantiating_module, but when this
declaration is a redeclaration duplicate_decls needs to propagate this
to olddecl.
This patch only changes the logic for template declarations, because in
the non-template case
Hi, this is the 7th version of the patch.
Compare to the 6th version, the major changes are several style issues
raised by Jakub for the 6th version of the patchs.
The 6th version is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663992.html
bootstrapped and regress tested on both
Hi Steve,
the testcase is in the coarray directory, where tests are executed mit
-fcoarray=single and lib. I don't know about none. Because the code stops
compiling when it encounters a coarray with no single or lib. Therefore I
suppose there no way to run it without coarrays.
Hope that helps,
A
> > This is the second revision of:
> > >
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662849.html
> > >
> > > I've incorporated the feedback given both by Richard and David -
> > > I
> > > didn't
> >
On Fri, Sep 27, 2024 at 03:20:43PM +0200, Andre Vehreschild wrote:
>
> attached patch fixes a runtime issue when a coarray was passed as
> parameter to a procedure that was itself a parameter. The issue here
> was that the coarray was passed as array pointer (i.e. w/o descript
On 27 September 2024 16:05:01 CEST, "Richard Earnshaw (lists)"
wrote:
>On 26/09/2024 19:21, Ramana Radhakrishnan wrote:
>> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>>>
>>> From: Fangrui Song
>>>
>>> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
>>> for FDPIC (
This patch seems to have been over looked.
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663101.html
I ran a set of spec 2017 benchmarks with this patch applied and compared it to
a run without the patch applied. There were no regressions, but 3 benchmarks
had slight improvement in
Based on observation within bpf-next selftests and comparisson of GCC
and clang compiled code, the BPF loader expects all CO-RE relocations to
point to BTF non const type nodes.
---
gcc/btfout.cc | 2 +-
gcc/config/bpf/btfext-out.cc | 6
gcc/
gimple expressions as explicit CO-RE accesses,
such that the gimple traverser will further convert the sub-expressions.
This patch makes sure that this LHS marking will not happen in case the
gimple statement is a function call, which case it is no longer
expecting to keep generating CO-RE accesses
Hi everyone,
This patches series includes fixes for bugs uncovered when executing
bpf-next selftests.
Looking forward to your comments.
Regards,
Cupertino
Cupertino Miranda (3):
bpf: make sure CO-RE relocs are never typed with a BTF_KIND_CONST
bpf: calls do not promote attr access_index on
X (eliminate the right hand side since it holds for any X)
>>
>> (c) The > and < cases are negations of (a) and (b), respectively.
>>
>> This transformation allows to occasionally save add / sub instructions,
>> for instance the expression
>>
>> 3 +
ch entities.
Looks fine, please squash this with the patch that adds the warning.
PR c++/115126
gcc/testsuite/ChangeLog:
* g++.dg/modules/xtreme-header-8.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/testsuite/g++.dg/modules/xtreme-header-8.C | 8
1 file chang
."
This patch implements this requirement, and cleans up some issues in the
testsuite where this was already violated. To handle deduction guides
we mark them as inline, since although we give them a definition for
implementation reasons, by the standard they have no definition, and so
we sho
for some kinds of declarations it's not
always obvious where it should be moved to.
This patch instead introduces a new function to check that the linkage
of a declaration within a module is correct, to be called for all
declarations once their linkage is fully determined.
As a drive-by fix th
c-linux-gnu, OK for trunk?
-- >8 --
[basic.link] p14 lists a number of circumstances where a declaration
naming a TU-local entity is not an exposure, notably the bodies of
non-inline templates and friend declarations in classes. This patch
ensures that these references do not error when exportin
On 9/23/24 7:45 PM, Nathaniel Shead wrote:
I feel like there should be a way to make use of LAMBDA_TYPE_EXTRA_SCOPE to
avoid the need for the new TYPE_DEFINED_IN_INITIALIZER_P flag, perhaps once
something like my patch here[1] is accepted (but with further embellishments
for concepts, probably
The previous implementation to emit build attributes did not support
string values (asciz) in aeabi_subsection, and was not emitting values
associated to tags in the assembly comments.
This new approach provides a more user-friendly interface relying on
typing, and improves the emitted assembly co
I noticed that IRC information was difficult to find on the website. OK?
---
htdocs/style.mhtml | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/style.mhtml b/htdocs/style.mhtml
index d015029a..f1aa8214 100644
--- a/htdocs/style.mhtml
+++ b/htdocs/style.mhtml
@@ -67,6 +67,7 @@
Snaps
f:
> >
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662849.html
> >
> > I've incorporated the feedback given both by Richard and David - I
> > didn't
> > find any memory leaks when testing in valgrind :)
>
> Thanks for the upda
Hi, this is the 6th version of the patch.
Compare to the 5th version, the major changes are (Address Jakub's comments)
1. delete the new global "in_builtin_counted_by_ref"
2. split the "counted_by" specific handling from the routne
"build_comp
more difficult than needed.
This patch adds assembly comments (if -dA is provided) next to the GNU
properties. For instance, if PAC and BTI are enabled, it will emit:
.word 3 // GNU_PROPERTY_AARCH64_FEATURE_1_AND (BTI, PAC)
gcc/ChangeLog:
* config/aarch64/aarch64.cc
Hi Mikael,
Now for the remaining intrinsics (FINDLOC, MAXLOC,
MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing).
I have one patch series touching (inline) MINLOC and MAXLOC to post in
the coming days. Could you please keep away from them for one more week
or two?
Looking at the
gcc/ChangeLog:
* config.gcc: Add aarch64-dwarf-metadata.o to extra_objs.
* config/aarch64/aarch64-dwarf-metadata.h (class section_note_gnu_property):
Encapsulate GNU properties code into a class.
* config/aarch64/aarch64.cc
(GNU_PROPERTY_AARCH64_FEATURE_1_AND): Define.
(GNU
attributes.
This patch adds a first support for AArch64 GCS build attributes.
This support includes generating two new assembler directives:
.aeabi_subsection and .aeabi_attribute. These directives are
generated as per the syntax mentioned in spec "Build Attributes for
the Arm® 64-bit Architecture (AA
The primary focus of this patch series is to add support for build attributes
in the context of GCS (Guarded Control Stack, an Armv9.4-a extension) to the
AArch64 backend.
It addresses comments from a previous review [1], and proposes a different
approach compared to the previous implementation
Jakub,
Thanks a lot for your comments, I will fix all these issues in the next version.
Qing
> On Sep 27, 2024, at 10:18, Jakub Jelinek wrote:
>
> On Fri, Sep 27, 2024 at 02:01:19PM +, Qing Zhao wrote:
>> + /* Currently, only when the array_ref is an indirect_ref to a call to the
>> +
On Fri, Sep 27, 2024 at 10:23 AM David Malcolm wrote:
> > -I submitted a patch last year for that but did not get any response
> > (
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635648.html).
> > I guess I never pinged it because I am still trying to
On Fri, Sep 27, 2024 at 09:54:13AM -0400, Lewis Hyatt wrote:
> A couple comments that may be helpful...
>
> -This is also PR 64117 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117)
>
> -I submitted a patch last year for that but did not get any response
> (https://gcc.gnu
On Fri, 2024-09-27 at 10:23 -0400, David Malcolm wrote:
> On Fri, 2024-09-27 at 09:54 -0400, Lewis Hyatt wrote:
> > On Fri, Sep 27, 2024 at 9:41 AM David Malcolm
> > wrote:
> > >
> > > On Thu, 2024-09-26 at 23:28 +0200, Jakub Jelinek wrote:
> > > > Hi
On Fri, Sep 27, 2024 at 02:01:19PM +, Qing Zhao wrote:
> + /* Currently, only when the array_ref is an indirect_ref to a call to the
> + .ACCESS_WITH_SIZE, return true.
> + More cases can be included later when the counted_by attribute is
> + extended to other situations. */
> +
> find any memory leaks when testing in valgrind :)
Thanks for the updated patch.
[...snip...]
> diff --git a/gcc/tree-emit-json.cc b/gcc/tree-emit-json.cc
> new file mode 100644
> index 000..df97069b922
> --- /dev/null
> +++ b/gcc/tree-emit-json.cc
[...snip...]
Hi Roger!
If you don't mind, I could use your help here (but: low priority!):
On 2024-07-27T19:18:35+0100, "Roger Sayle" wrote:
> Previously, for isnormal, GCC -O2 would generate: [...]
> and with this patch becomes:
>
> mov.f64 %r23, %ar0;
>
Hi,
This is my first patch of GCC. It there are any problems, please let me know.
0001-RISC-V-libgcc-Save-Restore-routines-for-E-goes-with-.patch
Description: Binary data
On 26/09/2024 19:21, Ramana Radhakrishnan wrote:
> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>>
>> From: Fangrui Song
>>
>> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
>> for FDPIC (absolute addressing for symbol references and no function
>> descriptor). The
On Fri, Sep 27, 2024 at 12:14:47PM +0200, Richard Biener wrote:
> I can investigate a bit when there's a testcase showing the issue.
The testcase is pr78687.C with Marek's cp-gimplify.cc patch.
Or the
struct S { union U { struct T { void *a, *b, *c, *d, *e; } t; struct V {} v; }
On Sat, 2024-09-21 at 22:49 -0500, -thor wrote:
> From: thor
>
> This patch allows one to dump a tree as HTML from within gdb by
> invoking,
> i.e,
> htlml-tree tree
>
> gcc/ChangeLog:
> * gcc/gdbhooks.py: Rudimentary dumping of GENERIC trees as html
>
On Fri, Sep 27, 2024 at 9:41 AM David Malcolm wrote:
>
> On Thu, 2024-09-26 at 23:28 +0200, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch on top of the just posted cleanup patch
> > saves/restores the m_classification_history and m_push_list
> > v
On Thu, 2024-09-26 at 23:28 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following patch on top of the just posted cleanup patch
> saves/restores the m_classification_history and m_push_list
> vectors for PCH. Without that as the testcase shows during parsing
> of the templat
On Thu, 2024-09-26 at 23:24 +0200, Jakub Jelinek wrote:
> Hi!
>
> diagnostic.h already relies on vec.h, it uses auto_vec in one spot.
>
> The following patch converts m_classification_history and m_push_list
> hand-managed arrays to vec templates.
> The main advantage is ex
> > So should we adjust very-cheap to allow niter peeling as proposed or
> > should we switch
> > the default at -O2 to cheap?
>
> Any thoughts from other backend maintainers?
No preference from RISC-V since is variable length vector flavor, so
no epilogue for those case, I mean it's already vecto
Resending as v2 so CI picks it up.
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a dec_insn.
This dec_insn is the instruction that decreases the loop counter inside a
decrementing loop and we expect
On 26/09/2024 18:14, Matthieu Longo wrote:
> A previous patch ([1]) introduced a build regression on aarch64-none-elf
> target. The changes were primarilly tested on aarch64-unknown-linux-gnu,
> so the issue was missed during development.
> The includes are slighly different bet
Hi all,
attached patch fixes a runtime issue when a coarray was passed as
parameter to a procedure that was itself a parameter. The issue here
was that the coarray was passed as array pointer (i.e. w/o descriptor)
to the function, but the function expected it to be an array
w/ descriptor
801 - 900 of 11319 matches
Mail list logo
