> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
> b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
> index d150f20b5d9..02814183dbb 100644
> --- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
Cache the source files as they are read, rather than discarding them at
the end of output_lines (), and move the reading of the source file to
the new function slurp.
This patch does not really change anything other than moving the file
reading out of output_file, but set gcov up for more interact
With -march=cascadelake we use vpermilps instead of shufps.
Tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/116258
* gcc.target/i386/pr116258.c: Also allow vpermilps.
---
gcc/testsuite/gcc.target/i386/pr116258.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Am Donnerstag, dem 08.08.2024 um 00:09 +0200 schrieb Alejandro Colomar:
> Hi Martin,
> >
...
> > >
> > > I would personally prefer supporting [0], and consider that not
> > > supporting [*] is a bug in the implementation of [*] (and thus not my
> > > problem).
> > >
> > > However, since GCC doe
On Wed, Aug 7, 2024 at 9:33 PM Andi Kleen wrote:
>
> > > + /* Create chain of switch tests for each case. */
> > > + tree switch_cond = NULL_TREE;
> > > + tree index = gimple_switch_index (sw);
> > > + for (unsigned i = 1; i < gimple_switch_num_labels (sw); i++)
>
On Thu, Aug 8, 2024 at 12:11 AM Andrew Pinski wrote:
>
> This is a small C++11-ificiation for the use of vect_vect_recog_func_ptrs.
> Changes the loop into a range based loop which then we can remove the variable
> definition of NUM_PATTERNS. Also uses const reference instead of a pointer.
>
> Boo
On Thu, Aug 8, 2024 at 12:17 AM Vineet Gupta wrote:
>
> On 8/7/24 12:28, Jeff Law wrote:
> > On 8/7/24 11:47 AM, Richard Sandiford wrote:
> >> I should probably start by saying that the "model" heuristic is now
> >> pretty old and was originally tuned for an in-order AArch32 core.
> >> The aim was
Rainer Orth writes:
Hello,
> Solaris Ada bootstrap is broken as of 2024-08-06 with
>
> s-taprop.adb:1971:23: error: "int" is not visible
> s-taprop.adb:1971:23: error: multiple use clauses cause hiding
> s-taprop.adb:1971:23: error: hidden declaration at s-osinte.ads:51
> s-taprop.adb:1971:23: e
On Thu, Aug 8, 2024 at 4:03 AM Wentao Zhang wrote:
>
> The referenced page contains more explanation of auxname.gcda produced
> by gcov profiler, which is a continuation of -fprofile-arcs's
> description.
OK
> gcc/ChangeLog:
>
> * doc/invoke.texi (Instrumentation Options): Move the cross
Iain Sandoe writes:
Hello,
> Tested on x86_64-darwin21, OK for trunk?
Yes, thanks!
Marc
On Thu, Aug 8, 2024 at 4:55 AM Peter Damianov wrote:
>
> Currently, if a warning references a cloned function, the name of the cloned
> function will be emitted in the "In function 'xyz'" part of the diagnostic,
> which users aren't supposed to see. This patch follows the DECL_ORIGIN link
> to get
Hello Jens,
On Thu, Aug 08, 2024 at 07:35:12AM GMT, Jₑₙₛ Gustedt wrote:
> Hello Alejandro,
>
> On Thu, 8 Aug 2024 00:44:02 +0200, Alejandro Colomar wrote:
>
> > +Its syntax is similar to @code{sizeof}.
>
> For my curiosity, do you also make the same distinction that with
> expressions you may o
This minor patch, very similar to one posted and approved previously at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657229.html is
required to restore builds on systems using gcc 4.8 as a host compiler.
Using the enumeration constants E_SFmode and E_DFmode avoids issues with
SFmode and DFm
Hi Martin,
On Thu, Aug 08, 2024 at 09:39:59AM GMT, Martin Uecker wrote:
> > $ /opt/local/gnu/gcc/lengthof/bin/gcc zero.c
> > zero.c:18:12: error: variably modified ‘Z’ at file scope
> >18 | static int Z[__lengthof__(Y)];
> > |^
> >
> >
> > See that D, which
Hi!
This is an attempt to implement the https://wg21.link/p3034r1 paper,
but I'm afraid the wording in the paper is bad for multiple reasons.
I think I understand the intent, that the module name and partition
if any shouldn't come from macros so that they can be scanned for
without preprocessing,
On Thu, Aug 8, 2024 at 10:28 AM Roger Sayle wrote:
>
>
> This minor patch, very similar to one posted and approved previously at
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657229.html is
> required to restore builds on systems using gcc 4.8 as a host compiler.
> Using the enumeration co
haochen.jiang wrote:
FAIL: libgomp.c++/static-aggr-constructor-destructor-1.C scan-tree-dump-times optimized
"__attribute__\\(\\([^\n\r]*omp declare target nohost" 1
FAIL: libgomp.c++/static-aggr-constructor-destructor-1.C scan-tree-dump-times optimized
"void _GLOBAL__off_I_v1" 1
Those symbol
Hi,
Gently ping.
Thanks,
Lingling
From: Kong, Lingling
Sent: Tuesday, June 25, 2024 2:46 PM
To: gcc-patches@gcc.gnu.org
Cc: Alexander Monakov ; Uros Bizjak ;
lingling.ko...@gmail.com; Hongtao Liu ; Jeff Law
; Richard Biener
Subject: RE: [PATCH v2 1/2] [APX CFCMOV] Support APX CFCMOV in if_con
Le 07/08/2024 à 12:03, Harald Anlauf a écrit :
Hi Mikael, Thomas!
Am 07.08.24 um 11:11 schrieb Mikael Morin:
Hello,
Le 06/08/2024 à 22:57, Thomas Koenig a écrit :
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also depende
Hi
Am 8. August 2024 10:26:14 MESZ schrieb Alejandro Colomar :
> Hello Jens,
>
> On Thu, Aug 08, 2024 at 07:35:12AM GMT, Jₑₙₛ Gustedt wrote:
> > Hello Alejandro,
> >
> > On Thu, 8 Aug 2024 00:44:02 +0200, Alejandro Colomar wrote:
> >
> > > +Its syntax is similar to @code{sizeof}.
> >
> > For m
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
Cache the source files as they are read, rather than discarding them at
the end of output_lines (), and move the reading of the source file to
the new function slurp.
This patch does not really change anything other than moving the file
reading out of output_file, but set gcov up for more interact
I think this patch is ready for review now. I'm resubmitting these
patches with a few tiny fixes so they build properly.
These are the main highlights since v3:
1. Atomics are issued under -fprofile-update=atomic
2. Giving up after exceeding path limit in more phases to not
accidentally get st
Vineet Gupta writes:
> On 8/7/24 12:28, Jeff Law wrote:
>> On 8/7/24 11:47 AM, Richard Sandiford wrote:
>>> I should probably start by saying that the "model" heuristic is now
>>> pretty old and was originally tuned for an in-order AArch32 core.
>>> The aim wasn't to *minimise* spilling, but to st
Am Donnerstag, dem 08.08.2024 um 10:42 +0200 schrieb Alejandro Colomar:
> >
> > ...
> >
> > > |^
> > >
> > > If I make [0] always result in a constant expression (and thus break
> > > some [*] cases), by doing
> > >
> > > - var = var || (zero && C_TYPE_VARIABLE_SIZE (type
Hi Jens,
On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote:
> > but to maintain expectations, I think it would be better to do
> > the same here.
>
> Just to compare, the recent additions in C23 typeof etc. only have the
> parenthesized versions. So there would be precedent. And it reall
On Thu, Aug 08, 2024 at 11:23:51AM GMT, Martin Uecker wrote:
> > Not really. 'zero' is only true for [0] and for [*], but nor for
> > [zero], right?
> >
> > All vla tests seem to pass if I remove that line. The only issue will
> > be that
> >
> > void f(char (*a)[*], int (*x)[__lengthof__
This patch implements match.pd patterns for the following transformations:
(1) (UB-on-overflow types) C1 - X cmp C2 -> X cmp C1 - C2
(2) (unsigned types) C1 - X cmp C2 ->
(a) X cmp C1 - C2, when cmp is !=, ==
(b) X - (C1 - C2) cmp C2, when cmp is <=, >
(c) X - (C1 - C2 + 1) cmp C2, wh
On Thu, Aug 08, 2024 at 10:44:31AM +0200, Jakub Jelinek wrote:
> I think the patch is at least a step in the direction of the paper's
> intent, but perhaps not full. If we need to check for initial : or .
> in the expansion of the first identifier after the module name or
> module partition, not s
The following tries to address that the vectorizer fails to have
precise knowledge of argument and return calling conventions and
views some accesses as loads and stores that are not.
This is mainly important when doing basic-block vectorization as
otherwise loop indexing would force such arguments
On Thu, 8 Aug 2024, Alejandro Colomar wrote:
> Hi Jens,
>
> On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote:
> > > but to maintain expectations, I think it would be better to do
> > > the same here.
> >
> > Just to compare, the recent additions in C23 typeof etc. only have the
> > par
On 2024-08-08 09:04, Richard Biener wrote:
On Thu, Aug 8, 2024 at 4:55 AM Peter Damianov
wrote:
Currently, if a warning references a cloned function, the name of the
cloned
function will be emitted in the "In function 'xyz'" part of the
diagnostic,
which users aren't supposed to see. This pa
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
The change to 'finish_struct_bits' is not required for this PR but I
felt it was a nice cleanup; happy to commit without it though if
preferred.
-- >8 --
This has caused issues with modules when an import fills in the
definition of
On Sat, Aug 3, 2024 at 2:42 PM Feng Xue OS wrote:
>
> >> 1. Background
> >>
> >> For loop reduction of accumulating result of a widening operation, the
> >> preferred pattern is lane-reducing operation, if supported by target.
> >> Because
> >> this kind of operation need not preserve intermediat
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
While stepping through some code I noticed that we do some extra work
(finding the originating module decl, stripping the template, and
inspecting the attached-ness) for every declaration taken from a header
unit. This doe
On Mon, Aug 5, 2024 at 4:02 PM Juergen Christ wrote:
>
> Am Mon, Aug 05, 2024 at 01:00:31PM +0200 schrieb Richard Biener:
> > On Fri, Aug 2, 2024 at 2:43 PM Juergen Christ wrote:
> > >
> > > Do not convert floats to ints in multiple step if trapping math is
> > > enabled. This might hide some in
On Tue, Aug 6, 2024 at 12:38 PM Manolis Tsamis wrote:
>
> Pinging this for a review and/or further feedback.
>
> Thanks,
> Manolis
>
> On Wed, Jun 26, 2024 at 3:06 PM Manolis Tsamis
> wrote:
> >
> > This change checks when a two_operators SLP node has multiple occurrences of
> > the same stateme
Document -fno-builtin-omp_is_initial_device as discussed:
Jakub Jelinek wrote:
RFC: Should be document this new built-in some where? If so, where? As part
of the routine description in libgomp.texi? Or in extend.texi (or even
invoke.texi)?
I think libgomp.texi in the omp_is_initial_device desc
On Thu, Aug 08, 2024 at 02:18:48PM +0200, Tobias Burnus wrote:
> Document -fno-builtin-omp_is_initial_device as discussed:
>
> Jakub Jelinek wrote:
> > > RFC: Should be document this new built-in some where? If so, where? As
> > > part
> > > of the routine description in libgomp.texi? Or in exte
Update for the very recently released TR13. Unsurprisingly, most item
are still unimplemented.
→ https://www.openmp.org/specifications/ → Technical Report 13
Comments, suggestions, typo fixes? — If not, I will commit it later today.
Tobias
libgomp.texi: Update implementation status table for O
On 8/8/24 8:06 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
While stepping through some code I noticed that we do some extra work
(finding the originating module decl, stripping the template, and
inspecting the attached-ness) for ev
On 8/8/24 7:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
The change to 'finish_struct_bits' is not required for this PR but I
felt it was a nice cleanup; happy to commit without it though if
preferred.
-- >8 --
This has caused issues wit
Hi Richard,
After differing NUM_POLY_INT_COEFFS fix for AArch64/nvptx offloading, the
following minimal test:
int main()
{
int x;
#pragma omp target map(x)
x = 5;
return x;
}
compiled with -fopenmp -foffload=nvptx-none now fails with:
gcc: error: unrecognized command-line option '-m64'
Richard Biener writes:
> The following tries to address that the vectorizer fails to have
> precise knowledge of argument and return calling conventions and
> views some accesses as loads and stores that are not.
> This is mainly important when doing basic-block vectorization as
> otherwise loop i
On Thu, Aug 8, 2024 at 6:11 AM Prathamesh Kulkarni
wrote:
>
> Hi Richard,
> After differing NUM_POLY_INT_COEFFS fix for AArch64/nvptx offloading, the
> following minimal test:
>
> int main()
> {
> int x;
> #pragma omp target map(x)
> x = 5;
> return x;
> }
>
> compiled with -fopenmp -fo
Previously, trampolines worked on GCN3 devices, but the newer GCN5
devices had different permissions on the stack memory space we were
using.
That changed when we added the reverse-offload features because we
switched from using the "private" memory space to using a regular memory
allocation.
The
On 8/8/24 06:20, Jakub Jelinek wrote:
On Thu, Aug 08, 2024 at 02:18:48PM +0200, Tobias Burnus wrote:
Document -fno-builtin-omp_is_initial_device as discussed:
Jakub Jelinek wrote:
RFC: Should be document this new built-in some where? If so, where? As part
of the routine description in libgomp
Paul-Antoine Arras wrote:
This patch introduces the OMP_DISPATCH tree node, as well as two new clauses
`nocontext` and `novariants`. It defines/exposes interfaces that will be
used in subsequent patches that add front-end and middle-end support, but
nothing generates these nodes yet.
LGTM - tha
> > But your comment made me realize there is a major bug.
> >
> > if_convertible_switch_p also needs to check that that the labels don't fall
> > through, so the the flow graph is diamond shape. Need some easy way to
> > verify that.
>
> Do we verify this for if()s? That is,
No we do not. Afte
On 8/8/24 06:21, Tobias Burnus wrote:
Update for the very recently released TR13. Unsurprisingly, most item
are still unimplemented.
→ https://www.openmp.org/specifications/ → Technical Report 13
Comments, suggestions, typo fixes? — If not, I will commit it later today.
I've got a few things
This series of patches fixes issues with some intrinsics being incorrectly
gated by global target options, instad of just using function-specific target
options. These issues have been present since the +tme, +memtag and +ls64
intrinsics were introduced.
This series is an rebased and fixed versio
Move SVE extension checking functionality to aarch64-builtins.cc, so
that it can be shared by non-SVE intrinsics.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins.cc (check_builtin_call)
(expand_builtin): Update calls to the below.
(report_missing_extension, check_requ
From: Javier Miranda
When the attribute Finalization_Size is applied to an interface type
object, the compiler-generated code fails at runtime, raising a
Constraint_Error exception.
gcc/ada/
* exp_attr.adb (Expand_N_Attribute_Reference) :
If the prefix is an interface type, gene
From: Gary Dismukes
When unnesting is enabled, the compiler was failing to copy the At_End_Proc
field from a block statement to the procedure created to replace it when
unnesting of top-level blocks is done. At run time this could lead to
exceptions due to missing finalization calls.
gcc/ada/
The availability of tme intrinsics was previously gated at both
initialisation time (using global target options) and usage time
(accounting for function-specific target options). This patch removes
the check at initialisation time, and also moves the intrinsics out of
the header file to allow for
From: Justin Squirek
This patch fixes an issue in the compiler whereby disabling style checks via
pragma Style_Checks ("-L") resulted in the minimum nesting level being zero
but the style still being enabled - leading to spurious maximum nesting level
exceeded warnings.
gcc/ada/
* style
From: Steve Baird
An access discriminant is allowed to have a default value only if the
discriminated type is immutably limited. In the case of a discriminated
limited private type declaration, this rule needs to be checked when
the completion of the type is seen.
gcc/ada/
* sem_ch6.adb
From: Steve Baird
If the primitive equality operator of the component type of an array type is
abstract, then a call to that abstract function raises Program_Error (when
such a call is legal). The FE generates a raise expression to implement this.
That raise expression is an expression so it shou
From: Justin Squirek
This patch further enhances the mutably tagged type implementation by fixing
several oversights relating to generic instantiations, attributes, and
type conversions.
gcc/ada/
* exp_put_image.adb (Append_Component_Attr): Obtain the mutably
tagged type for the
The availability of ls64 intrinsics and data types were determined
solely by the globally specified architecture features, which did not
reflect any changes specified in target pragmas or attributes.
This patch removes the initialisation-time guards for the intrinsics,
and replaces them with check
The availability of memtag intrinsics and data types were determined
solely by the globally specified architecture features, which did not
reflect any changes specified in target pragmas or attributes.
This patch removes the initialisation-time guards for the intrinsics,
and replaces them with che
On Wed, Aug 7, 2024 at 4:48 PM Jeff Law wrote:
>
>
>
> On 8/7/24 12:27 AM, Christoph Müllner wrote:
> > Test file xtheadfmemidx-medany.c has been added in b79cd204c780 as a
> > test case that provoked an ICE when loading DFmode registers via two
> > SImode register loads followed by a SI->DF[63:32
On 8/8/24 8:34 AM, Christoph Müllner wrote:
On Wed, Aug 7, 2024 at 4:48 PM Jeff Law wrote:
On 8/7/24 12:27 AM, Christoph Müllner wrote:
Test file xtheadfmemidx-medany.c has been added in b79cd204c780 as a
test case that provoked an ICE when loading DFmode registers via two
SImode registe
Am 8. August 2024 13:28:57 MESZ schrieb Joseph Myers :
> On Thu, 8 Aug 2024, Alejandro Colomar wrote:
>
> > Hi Jens,
> >
> > On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote:
> > > > but to maintain expectations, I think it would be better to do
> > > > the same here.
> > >
> > > Just
> Am 08.08.2024 um 15:12 schrieb Richard Sandiford :
>
> Richard Biener writes:
>> The following tries to address that the vectorizer fails to have
>> precise knowledge of argument and return calling conventions and
>> views some accesses as loads and stores that are not.
>> This is mainly im
Hi Saurabh,
> On 7 Aug 2024, at 17:11, saurabh@arm.com wrote:
>
> External email: Use caution opening links or attachments
>
>
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute
Richard Biener writes:
>> Am 08.08.2024 um 15:12 schrieb Richard Sandiford :
>>>PR tree-optimization/116274
>>>* tree-vect-slp.cc (vect_bb_slp_scalar_cost): Cost scalar loads
>>>and stores as simple scalar stmts when they access a non-global,
>>>not address-taken variable that does
DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P templates can only appear as part
of a template friend declaration, and in turn get partially instantiated
only from tsubst_friend_function or tsubst_friend_class. So rather than
having tsubst_template_decl clear the flag, let's leave it up to the
tsubst frien
The predicates for checking an IDENTIFIER node's cp_identifier_kind
currently directly test the three flag bits that encode the kind. This
patch instead makes the checks first reconstruct the cp_identifier_kind
in its entirety and then compare that.
gcc/cp/ChangeLog:
* cp-tree.h (get_ide
Am Donnerstag, dem 08.08.2024 um 16:56 +0200 schrieb Jens Gustedt:
> Am 8. August 2024 13:28:57 MESZ schrieb Joseph Myers :
> > On Thu, 8 Aug 2024, Alejandro Colomar wrote:
> >
> > > Hi Jens,
> > >
> > > On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote:
> > > > > but to maintain expecta
Andrew Carlotti writes:
> Move SVE extension checking functionality to aarch64-builtins.cc, so
> that it can be shared by non-SVE intrinsics.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve-builtins.cc (check_builtin_call)
> (expand_builtin): Update calls to the below.
> (rep
The gimple-if-to-switch pass converts if statements with
multiple equal checks on the same value to a switch. This breaks
vectorization which cannot handle switches.
Teach the tree-if-conv pass used by the vectorizer to handle
simple switch statements, like those created by if-to-switch earlier.
T
From: Andi Kleen
It is using a class now with a different name.
I will commit as obvious unless someone complains
Also I included this patch by mistake in my earlier if conversion v2
patch. Please ignore that hunk there.
gcc/ChangeLog:
* doc/cfg.texi: Fix references to dom_walker.
---
Andrew Carlotti writes:
> The availability of tme intrinsics was previously gated at both
> initialisation time (using global target options) and usage time
> (accounting for function-specific target options). This patch removes
> the check at initialisation time, and also moves the intrinsics ou
Am 8. August 2024 17:42:54 MESZ schrieb Martin Uecker :
> Am Donnerstag, dem 08.08.2024 um 16:56 +0200 schrieb Jens Gustedt:
> > Am 8. August 2024 13:28:57 MESZ schrieb Joseph Myers :
> > > On Thu, 8 Aug 2024, Alejandro Colomar wrote:
> > >
> > > > Hi Jens,
> > > >
> > > > On Thu, Aug 08, 2024 at
The metadata for RDNA3 kernels allocates VGPRs in blocks of 12, which means the
maximum usable number of registers is 252. This patch prevents the compiler
from exceeding this artifical limit.
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_conditional_register_usage): Fix registers
rema
Am Donnerstag, dem 08.08.2024 um 18:23 +0200 schrieb Jens Gustedt:
> As said, even if we don't consider this problematic because we are used to
> the mildly complex case distinction that you just exposed over several
> paragraphs, it doesn't mean that we should
> do it, nor does it mean that it w
Andrew Carlotti writes:
> The availability of memtag intrinsics and data types were determined
> solely by the globally specified architecture features, which did not
> reflect any changes specified in target pragmas or attributes.
>
> This patch removes the initialisation-time guards for the intr
Andrew Carlotti writes:
> The availability of ls64 intrinsics and data types were determined
> solely by the globally specified architecture features, which did not
> reflect any changes specified in target pragmas or attributes.
>
> This patch removes the initialisation-time guards for the intrin
As said, even if we don't consider this problematic because we are used to the
mildly complex case distinction that you just exposed over several paragraphs,
it doesn't mean that we should do it, nor does it mean that it would be
beneficial for our users or for other implementations that would l
On Thu, Aug 08, 2024 at 11:09:10AM +0200, Mikael Morin wrote:
>
> These patches are about inlining, there is no manipulation of the parse
> tree. So I would rather use a separate option (-finline-intrinsics?).
I've only followed the discussion from afar, but gcc already supports
a -finline and -
Applied as obvious.
Johann
--
AVR: Fix a typo in __builtin_avr_mask1 documentation.
gcc/
* doc/extend.texi (AVR Built-in Functions) : Fix a typo.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 89fe5db7aed..ae1ada3cdf8 100644
--- a/gcc/doc/extend.texi
+++ b/g
On Thu, 8 Aug 2024, Jens Gustedt wrote:
> No, the ambiguity is there because the first ( after the keyword could
> start either a type in parenthesis or an expression, and among these a
> compound literal. If that first parenthesis would be part of the
> construct (as for the typeof or offsetof
Some post-inc address adjustments can be skipped when the
address register is unused after.
Johann
--
AVR: Improve POST_INC output in some rare cases.
gcc/
* config/avr/avr.cc (avr_insn_has_reg_unused_note_p): New function.
(_reg_unused_after): Use it to recognize more cases.
Applied this fix to trunk and v14 branch.
Johann
--
AVR: target/116295 - Fix unrecognizable insn with __flash read.
Some loads from non-generic address-spaces are performed by
libgcc calls, and they don't have a POST_INC form. Don't consider
such insns when running -mfuse-add.
PR tar
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk/14?
-- >8 --
This implements the inherited vs non-inherited guide tiebreaker
specified by P2582R1. In order to track inherited-ness of a guide
it seems natural to reuse the lang_decl_fn::context field that already
tra
Hi Martin, Jens, Joseph,
On Thu, Aug 08, 2024 at 06:30:42PM GMT, Martin Uecker wrote:
> Am Donnerstag, dem 08.08.2024 um 18:23 +0200 schrieb Jens Gustedt:
> > As said, even if we don't consider this problematic because we are used to
> > the mildly complex case distinction that you just exposed o
On Linux/x86_64,
ab18785840d7b8afd9f716bab9d1eab415bc4fe9 is the first bad commit
commit ab18785840d7b8afd9f716bab9d1eab415bc4fe9
Author: Manolis Tsamis
Date: Tue Jun 25 08:00:04 2024 -0700
Rearrange SLP nodes with duplicate statements [PR98138]
caused
FAIL: gcc.target/i386/pr105493.c sc
From: Raphael Zinsly
Improve handling of constants where its upper and lower 32-bit
halves are the same and Zbkb is not available in riscv_move_integer.
riscv_split_integer already handles this but the changes in
riscv_build_integer makes it possible to improve code generation for
negative values
Improve handling of constants where the high half can be constructed
by shifting the low half.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_build_integer): Detect constants
were the higher half is a shift of the lower half.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/synt
Am 08.08.24 um 11:09 schrieb Mikael Morin:
As we are not planning to remove the library implementation (-Os!),
this is also the best way to compare library to inline code.
This makes perfect sense, but why reuse the -ffrontend-optimize option?
The manual describes it as:
This option performs f
On 08/08/2024 11:13, Jens Gustedt wrote:
Hi
Am 8. August 2024 10:26:14 MESZ schrieb Alejandro Colomar :
Hello Jens,
On Thu, Aug 08, 2024 at 07:35:12AM GMT, Jₑₙₛ Gustedt wrote:
Hello Alejandro,
On Thu, 8 Aug 2024 00:44:02 +0200, Alejandro Colomar wrote:
+Its syntax is similar to @code{si
On Thu, 8 Aug 2024, Alejandro Colomar wrote:
> How about having __lengthof__ behave like sizeof, but deprecate it in
> sizeof too?
Deprecation would be a matter for WG14.
> We could start by adding a -Wall warning for sizeof without parens, and
> promote it to an error a few versions later.
Thi
Andrew Pinski writes:
> For bar1 and bar2, we currently is expecting to use the bsl instruction but
> with slightly different register allocation inside the loop (which happens
> after
> the removal of the vcond{,u,eq} patterns), we get the bit instruction. The
> pattern that
> outputs bsl inst
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The problem in this PR is that we ended up with
{.rows=(&)->n,
.outer_stride=(&)->rows}
that is, two PLACEHOLDER_EXPRs for different types on the same level
in one { }. That should not happen; we may, for instance, negle
> On Wed, 7 Aug 2024, Richard Biener wrote:
>
> > OK with that change.
> >
> > Did you think about a AVX512 version (possibly with 32 byte vectors)?
> > In case there's a more efficient variant of pshufb/pmovmskb available
> > there - possibly
> > the load on the branch unit could be lessened w
Hi Joseph,
On Thu, Aug 08, 2024 at 05:31:05PM GMT, Joseph Myers wrote:
> On Thu, 8 Aug 2024, Alejandro Colomar wrote:
>
> > How about having __lengthof__ behave like sizeof, but deprecate it in
> > sizeof too?
>
> Deprecation would be a matter for WG14.
Yep; I wouldn't add it to -Wall unless WG
Am Donnerstag, dem 08.08.2024 um 20:04 +0200 schrieb Alejandro Colomar:
>
...
> >
> > *If* the feature were adopted into C++26, we could then consider if
> > existing macros should be renamed to look more like the future language
> > feature.
> >
> > Target code is at least always compiled wi
1 - 100 of 132 matches
Mail list logo
