On 12/9/24 10:00 AM, Richard Sandiford wrote:
Mariam Arutunian writes:
Hello,
This patch series is a revised version of the following:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html.
In this version:
- Patch 09/12 has been updated with comments provided by Matevos
On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote:
>
> On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote:
> >Hello,
> >
> >This ports some misc test away from is_trivial.
>
> This is fine, thanks.
I'm seeing a number of FAILures not fixed by this patch:
FAIL: experimental/iterator/requirements.cc
The tests are specifying -mcpu=, but do not explicitly define an ABI.
Thus the test spuriously fail when the toolchain has been built for
RV32E. Fix by adding the necessary markings.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr109508.c: Pass -mabi=lp64d option.
* gcc.target/ris
As PR c++/106212 shows, the Debug Mode checks cause a compilation error
for equality comparisons involving std::array prvalues in constant
expressions. Those Debug Mode checks are redundant when
comparing two std::array objects, because we already know we have a
valid range. We can also avoid the u
On Fri, 6 Dec 2024, Thomas Schwinge wrote:
> First: Tom, what was your original intention why we'd keep the generated
> files in the sources? (..., instead of just generating them at build
> time, like 'gcc/config/nvptx/t-omp-device' does for
> 'omp-device-properties-nvptx', for example. In that
On Tue, Dec 10, 2024, 5:31 AM Joseph Myers wrote:
> On Fri, 6 Dec 2024, Richard Biener wrote:
>
> > On Wed, Dec 4, 2024 at 9:48 PM H.J. Lu wrote:
> > >
> > > Remove the targetm.calls.promote_prototypes call from C, C++ and Ada
> > > frontends.
> >
> > I'm conditionally approving this unless FE m
On Mon, Dec 09, 2024 at 02:07:07PM +0100, Richard Biener wrote:
> On Tue, Dec 3, 2024 at 2:42 PM Richard Biener
> wrote:
> >
> > On Tue, Dec 3, 2024 at 2:07 PM Lewis Hyatt wrote:
> > >
> > > On Tue, Dec 03, 2024 at 01:28:28PM +0100, Richard Biener wrote:
> > > > On Mon, Dec 2, 2024 at 1:55 AM Lew
On Mon, 9 Dec 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> We are crashing here because decode_cmdline_options_to_array has:
>
> if (!strcmp (opt, "-fdiagnostics-plain-output"))
> ...
>
> but that doesn't handle the '--FLAG' vari
In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
fix the constant (any non-zero value is converted to all 1s) and emit
a warning.
On MVE, V8
On Fri, 6 Dec 2024, Richard Biener wrote:
> On Wed, Dec 4, 2024 at 9:48 PM H.J. Lu wrote:
> >
> > Remove the targetm.calls.promote_prototypes call from C, C++ and Ada
> > frontends.
>
> I'm conditionally approving this unless FE maintainers complain before
> holidays
> (the effect of the hook i
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
In a template, for things like void() we'll create a CAST_EXPR with
a null operand. That causes a crash with -Wduplicated-branches on:
false ? void() : void();
because we do
if (warn_duplicated_branches
&& (comp
On Fri, Dec 06, 2024 at 12:48:35PM -0500, Jason Merrill wrote:
> On 12/6/24 12:29 PM, Marek Polacek wrote:
> > On Thu, Dec 05, 2024 at 01:15:49PM -0500, Jason Merrill wrote:
> > > On 12/4/24 12:27 PM, Marek Polacek wrote:
> > > > On Tue, Dec 03, 2024 at 04:27:22PM -0500, Jason Merrill wrote:
> > >
> Please pass 'sbitmap' instead of auto_sbitmap&, it should properly
> decay to that. Applies everywhere I think.
>
Changed.
> In fact I wonder whether we should simply populate the bitmap
> from a
>
> for (auto loop : loops_list (cfun, LI_ONLY_INNERMOST))
> bitmap_set_bit (original_innerm
On 12/9/24 3:43 PM, Richard Sandiford wrote:
Thanks. I was just about to reach out to confirm we're OK on aarch64.
I was going to run everything through one of the cfarm machines or
perhaps my rpi as a final test.
Ah, yeah. I'm hopelessly behind on gcc-patches, so hadn't seen that
you wer
On 12/9/24 6:32 PM, Marek Polacek wrote:
On Fri, Dec 06, 2024 at 12:48:35PM -0500, Jason Merrill wrote:
On 12/6/24 12:29 PM, Marek Polacek wrote:
On Thu, Dec 05, 2024 at 01:15:49PM -0500, Jason Merrill wrote:
On 12/4/24 12:27 PM, Marek Polacek wrote:
On Tue, Dec 03, 2024 at 04:27:22PM -0500,
Hello,
The attached patch fixes a compile error when converting a weak_ptr of
array type to a compatible type, for instance:
std::weak_ptr wptr;
std::weak_ptr wptr2 = wptr; // ERROR
https://gcc.godbolt.org/z/EWYb73Mvf
The reason seems to be a typo: the inner __weak_ptr class has a lock()
im
On 12/9/24 1:52 PM, Iain Sandoe wrote:
On 9 Dec 2024, at 17:41, Jason Merrill wrote:
On 10/31/24 4:40 AM, Iain Sandoe wrote:
This version tested on x86_64-darwin,linux, powerpc64-linux, on folly
and by Sam on wider codebases,
Why don't you need a variable to preserve o across suspensions i
On Mon, 9 Dec 2024 at 20:34, Giuseppe D'Angelo
wrote:
>
> On 09/12/2024 18:43, Jonathan Wakely wrote:
> > On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote:
> >> On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote:
> >>> Hello,
> >>>
> >>> This ports some misc test away from is_trivial.
> >> This is
On 12/9/24 2:39 PM, Iain Sandoe wrote:
On 9 Dec 2024, at 19:34, Jason Merrill wrote:
On 12/9/24 2:00 PM, Iain Sandoe wrote:
On 9 Dec 2024, at 18:56, Jason Merrill wrote:
On 11/29/24 8:47 AM, Iain Sandoe wrote:
Tested on x86_64-darwin, x86_64-linux,
OK for trunk?
thanks
Iain
--- 8< ---
At
Hi all,
The attached patch fixes this bug by checking for the case of a short
READ that should be padded with blanks and if the BZ mode is enabled,
those blanks should be treated as trailing zero's.
New test case courtesy Malcom Cohen.
Regression tested on X86_64_linux_gnu.
OK for trunk and
This patch adds basic support for three new tree node types that will
be used in subsequent patches to support OpenMP metadirectives and
dynamic selectors.
OMP_METADIRECTIVE is the internal representation of parsed OpenMP
metadirective constructs. It's produced by the front ends and is expanded
d
I realized last week that the previous version of this patch series that I
posted on Nov 15:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669053.html
collided with Paul-Antoine's "dispatch" construct patches that were
pushed a few days later, and no longer applied cleanly. I've prepar
Presently, the code to handle OpenMP attribute-syntax pragmas in the C
front end assumes nothing else is messing with redirecting
parser->tokens, and makes no provision for restoring it from anything
other than parser->tokens_buf when the buffer allocated for the pragma
is exhausted. Adding suppor
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds partial support for dynamic selectors
(PR113904) and fixes a selector scoring bug reported as PR114596. I hope
this rewrite also improve
After reimplementing late resolution of "declare variant", the
declare_variant_alt and calls_declare_variant_alt flags on struct
cgraph_node are no longer used by anything. For the purposes of
marking functions that need late resolution, the
has_omp_variant_constructs flag has replaced
calls_decla
gcc/testsuite/ChangeLog
* c-c++-common/gomp/attrs-metadirective-1.c: New.
* c-c++-common/gomp/attrs-metadirective-2.c: New.
* c-c++-common/gomp/attrs-metadirective-3.c: New.
* c-c++-common/gomp/attrs-metadirective-4.c: New.
* c-c++-common/gomp/attrs-metadirec
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
gcc/c-family/ChangeLog
PR middle-end/112779
PR middle-end/113904
* c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META.
(c_omp_expand_variant_construct): Declare.
* c
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic selector support.
(OpenM
gcc/fortran/ChangeLog
PR middle-end/112779
PR middle-end/113904
* decl.cc (gfc_match_end): Handle COMP_OMP_BEGIN_METADIRECTIVE and
COMP_OMP_METADRIECTIVE.
* dump-parse-tree.cc (show_omp_node): Handle EXEC_OMP_METADIRECTIVE.
(show_code_node): Likewise.
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
gcc/cp/ChangeLog
PR middle-end/112779
PR middle-end/113904
* cp-tree.h (struct saved_scope): Add new field
x_processing_omp_trait_property_expr.
(processing_omp_trait_proper
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
Hello,
On 04/12/2024 13:20, Giuseppe D'Angelo wrote:
Thank you for the review!
I think I've incorporated all the changes, new patch is attached. Some
other comments...
By doing some more testing, I've noticed that this patch causes a build
issue when a weak_ptr is used to construct a weak_pt
Jeff Law writes:
> On 12/9/24 10:00 AM, Richard Sandiford wrote:
>> Mariam Arutunian writes:
>>> Hello,
>>>
>>> This patch series is a revised version of the following:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html.
>>>
>>> In this version:
>>>
>>> - Patch 09/12 has
This patch removes the remaining traces of the vcond{,u,eq} optabs.
Earlier patches removed the target-independent uses and I couldn't
find any direct references to either the *_optabs or the ifns
in target-specific code.
Tested on aarch64-linux-gnu. OK to install?
Richard
gcc/
* doc/m
On Mon, Dec 9, 2024 at 3:02 PM Richard Sandiford
wrote:
>
> Prompted by Richard E's arm patch, this one removes the aarch64
> support for the vcond{,u} optabs.
>
> Tested on aarch64-linux-gnu. I'll push tomorrow if there are no
> objections. There might still be some fallout from the transition
Prompted by Richard E's arm patch, this one removes the aarch64
support for the vcond{,u} optabs.
Tested on aarch64-linux-gnu. I'll push tomorrow if there are no
objections. There might still be some fallout from the transition
that we need to fix (haven't checked yet), but this code wouldn't
fo
On Linux/x86_64,
6c41a912f5e654a1b6f7cf8d6b23f00d8612988c is the first bad commit
commit 6c41a912f5e654a1b6f7cf8d6b23f00d8612988c
Author: Giuseppe D'Angelo
Date: Mon Dec 9 01:28:08 2024 +0100
libstdc++: deprecate is_trivial for C++26 (P3247R2)
caused
FAIL: g++.dg/cpp0x/trivial1.C -std=c
Thank you all very much for your help! )
Mariam
On Tue, Dec 10, 2024, 04:04 Jeff Law wrote:
>
>
> On 12/9/24 3:43 PM, Richard Sandiford wrote:
>
> >> Thanks. I was just about to reach out to confirm we're OK on aarch64.
> >> I was going to run everything through one of the cfarm machines or
>
From: Pan Li
This patch would like to refactor the all signed SAT_ADD patterns,
aka:
* Extract type check outside.
* Re-arrange the related match pattern forms together.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 full
VN again is the culprit for exploiting address equivalences before
__builtin_object_size got the chance to do its job. This time
it isn't about union members but adjacent structure fields where
an address to one after the last element of an array field can
spill over to the next field.
The follow
On Linux/x86_64,
e4a0157c2397c9b582cff71d114240a6b083a3dc is the first bad commit
commit e4a0157c2397c9b582cff71d114240a6b083a3dc
Author: Giuseppe D'Angelo
Date: Mon Dec 9 02:11:19 2024 +0100
libstdc++: port bitwise relocatable away from is_trivial
caused
FAIL: g++.dg/warn/uninit-pr10556
Ping.
Thanks,
Jennifer
> On 3 Dec 2024, at 09:14, Jennifer Schmitz wrote:
>
> Ping.
> Thanks,
> Jennifer
>
>> On 26 Nov 2024, at 09:18, Jennifer Schmitz wrote:
>>
>>
>>
>>> On 20 Nov 2024, at 13:43, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening links or attachm
101 - 142 of 142 matches
Mail list logo
