Any update?
Thanks and Regards, Markus
Am 30.07.24 um 09:56 schrieb Jonathan Wakely:
On Tue, 30 Jul 2024, 06:21 Ehrnsperger, Markus,
wrote:
On 2024-07-29 12:16, Jonathan Wakely wrote:
> On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely
wrote:
>> On Mon, 29 Jul 2024 at 09:
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.
That patch had a bug in
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 [
gcc:
PR target/69374
* doc/install.texi (Specific) : Remove note
from 2003.
---
gcc/doc/install.texi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 08de972c8ec..517d1cbb2fb 100644
--- a/gcc/doc/install.texi
+++ b/gc
On Fri, Sep 27, 2024 at 11:56:27AM -0400, Jason Merrill wrote:
> On 9/23/24 7:46 PM, Nathaniel Shead wrote:
> > Currently I just stream DECL_NAME in TU_LOCAL_ENTITYs for use in
> > diagnostics,
> > but this feels perhaps insufficient. Are there any better approached here?
> > Otherwise I don't th
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
On Fri, Sep 27, 2024 at 03:55:14PM -0400, Jason Merrill wrote:
> On 9/27/24 3:38 PM, Jonathan Wakely wrote:
> > On Fri, 27 Sept 2024 at 19:46, Jason Merrill wrote:
> > >
> > > On 9/26/24 6:34 AM, Nathaniel Shead wrote:
> > > > On Thu, Sep 26, 2024 at 01:46:27PM +1000, Nathaniel Shead wrote:
> > >
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
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Some tests e.g. 17_intro/headers/c++1998/all_pedantic_errors.cc FAIL
with GLIBCXX_TESTSUITE_STDS=98 due to numerous C++11 extensions still in
use in the library headers. The recent changes to not make them system
headers means we get warnings now.
Tested x86_64-linux and x86_64-w64-mingw32 (just the
experimental::filesystem parts though).
Pushed to trunk.
-- >8 --
I noticed a -Wc++17-extensions warning due to use of if-constexpr in
std::experimental::filesystem::path, which was not protected by
diagnostic pragmas to disable the warning.
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 posted cleanup patch
> > > saves/restores the m_classificati
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 submitted a patch last year for that bu
On Fri, Sep 20, 2024 at 12:40:26PM -0400, Siddhesh Poyarekar wrote:
> When wholesize != size, there is a reasonable opportunity for static
> object sizes also to be computed using size_for_offset, so use that.
>
> gcc/ChangeLog:
>
> * tree-object-size.cc (plus_stmt_object_size): Call
>
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes two FAILs due to -Wpointer-arith warnings when testing with
c++11 or c++14 dialects.
libstdc++-v3/ChangeLog:
* testsuite/20_util/bind/dangling_ref.cc: Add an additional
dg-warning for -Wreturn-local-addr warning.
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
On 9/27/2024 1:24 PM, Richard Biener wrote:
> On Mon, 23 Sep 2024, Artemiy Volkov wrote:
>
>> Implement a match.pd transformation inverting the sign of X in
>> C1 - X cmp C2, where C1 and C2 are integer constants and X is
>> of a wrapping signed type, by observing that:
>>
>> (a) If cmp is == or !
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
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/basic_string.tcc (resize_for_overwrite): Fix
-Wsign-compare warning.
* include/bits/cow_string.h (resize_for_overwrite): Likewise.
---
libstdc++-v3/include/bits/basic_string.tcc | 2 +-
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 in a cl
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 this patch); this is mor
On 9/27/24 3:38 PM, Jonathan Wakely wrote:
On Fri, 27 Sept 2024 at 19:46, Jason Merrill wrote:
On 9/26/24 6:34 AM, Nathaniel Shead wrote:
On Thu, Sep 26, 2024 at 01:46:27PM +1000, Nathaniel Shead wrote:
On Wed, Sep 25, 2024 at 01:30:55PM +0200, Jakub Jelinek wrote:
On Wed, Sep 25, 2024 at 1
On Fri, 27 Sept 2024 at 19:46, Jason Merrill wrote:
>
> On 9/26/24 6:34 AM, Nathaniel Shead wrote:
> > On Thu, Sep 26, 2024 at 01:46:27PM +1000, Nathaniel Shead wrote:
> >> On Wed, Sep 25, 2024 at 01:30:55PM +0200, Jakub Jelinek wrote:
> >>> On Wed, Sep 25, 2024 at 12:18:07PM +0100, Jonathan Wakel
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
ensures
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 them
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
On 9/26/24 6:34 AM, Nathaniel Shead wrote:
On Thu, Sep 26, 2024 at 01:46:27PM +1000, Nathaniel Shead wrote:
On Wed, Sep 25, 2024 at 01:30:55PM +0200, Jakub Jelinek wrote:
On Wed, Sep 25, 2024 at 12:18:07PM +0100, Jonathan Wakely wrote:
And whether similarly we couldn't use
__attribute__((__v
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
On 9/27/24 5:14 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
We need to ensure that for a declaration in the module purview, that the
resulting declaration has PURVIEW_P set and IMPORT_P cleared so that we
understand it might be som
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
On Fri, 2024-09-27 at 10:21 -0500, Thor Preimesberger wrote:
> That's all correct. I think I got it.
>
> There are times where the code is emitting a json::object* that is
> contained in another json object. Is it good style to return these
> still as a unique_ptr?
Probably not. If you have a j
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 descriptor)
> to the function
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 ru
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/
When traversing gimple to introduce CO-RE relocation entries to
expressions that are accesses to attributed perserve_access_index types,
the access is likely to be split in multiple gimple statments.
In order to keep doing the proper CO-RE convertion we will need to mark
the LHS tree nodes of gimpl
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
On 9/27/2024 1:29 PM, Richard Biener wrote:
> On Mon, 23 Sep 2024, Artemiy Volkov wrote:
>
>> Whenever C1 and C2 are integer constants, X is of a wrapping type, and
>> cmp is a relational operator, the expression X +- C1 cmp C2 can be
>> simplified in the following cases:
>>
>> (a) If cmp is <= an
On 9/27/24 2:00 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
This adds a new xtreme-header testcase to ensure that we have no
regressions with regards to exposures of TU-local declarations
in the standard libr
On 9/27/24 1:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
[module.import] p6 says "A header unit shall not contain a definition of
a non-inline function or variable whose name has external linkage."
This p
On 9/27/24 1:59 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu,
OK for trunk?
-- >8 --
By [module.interface] p3, if an exported declaration is not within a
header unit, it shall not declare a name with internal linkage.
Unfortunately
On 9/23/24 7:46 PM, Nathaniel Shead wrote:
Currently I just stream DECL_NAME in TU_LOCAL_ENTITYs for use in diagnostics,
but this feels perhaps insufficient. Are there any better approached here?
Otherwise I don't think it matters too much, as which entity it is will also
be hopefully clear from
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),
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a FAIL due to a -Wpointer-arith warning when testing with
c++11 or c++14 dialects. As an extension our std::atomic supports
pointer arithmetic in C++11 and C++14, but due to the system header
changes there is now a warning about it. The wa
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
That's all correct. I think I got it.
There are times where the code is emitting a json::object* that is
contained in another json object. Is it good style to return these
still as a unique_ptr? I'm looking over what I wrote again, and in
some parts I wrap the new json object in a unique_ptr (as a
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_component_ref"
as a new routine "handle_counted_by_for
IRC discussion noted that the GettingStarted page was hard to find. Committing
as obvious.
---
htdocs/contribute.html | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index caff1f2a..53c27c6e 100644
--- a/htdocs/contribute.html
+++ b/htdocs/c
GNU properties are emitted to provide some information about the features
used in the generated code like PAC, BTI, or GCS. However, no debug
comment are emitted in the generated assembly even if -dA is provided.
This makes understanding the information stored in the .note.gnu.property
section more
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 pre
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
From: Srinath Parvathaneni
GCS (Guarded Control Stack, an Armv9.4-a extension) requires some
caution at runtime. The runtime linker needs to reason about the
compatibility of a set of relocable object files that might not have
been compiled with the same compiler.
Up until now, GNU properties are
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 ping two other
> > ones :).
>
>
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.org/pipermail/gcc-pat
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!
> > > >
> > > > The following patch on top
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. */
> +
On Sat, 2024-09-21 at 22:49 -0500, -thor wrote:
> From: thor
>
> 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
> find any memory leaks when testing
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;
> setp.neu.f64%r24,
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
Use iterative PTA definitions for members of the same AMD processor family.
Also, fix a couple of related M_CPU_TYPE/M_CPU_SUBTYPE inconsistencies.
No functional changes intended.
gcc/ChangeLog:
* config/i386/i386.h: Add PTA_BDVER1, PTA_BDVER2, PTA_BDVER3,
PTA_BDVER4, PTA_BTVER1 and PTA
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; }
u; unsigned long
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
> through
> one new python fu
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
> > vectors for PCH. Without that as the tes
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 templates we don't report ignor
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 exponential rather than l
> > 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 it
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 between the two targets
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.
Regtest
The following moves my entry to where it belongs alphabetically
(it wasn't moved when s/Guenther/Biener/).
Pushed as obvious.
* doc/contrib.texi (Richard Biener): Move entry.
---
gcc/doc/contrib.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/cont
When there's volatile qualified stores we do not have to treat the
destination as pointing to ANYTHING. It's only when reading from
it that we want to treat the resulting pointers as pointing to ANYTHING.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
PR tree-optimization
From: Mark Mentovai
I pushed this for Mark, after testing locally on x86_64-darwin21, 23,
thanks,
Iain
--- 8< ---
d9cafa0c4f0a stopped building libgcc_s.1 on macOS >= 15, in part because
that is required to bootstrap the compiler using the macOS 15 SDK. The
macOS 15 SDK ships in Xcode 16, which
On Mon, 23 Sep 2024, Artemiy Volkov wrote:
> Implement a match.pd transformation inverting the sign of X in
> C1 - X cmp C2, where C1 and C2 are integer constants and X is
> of a wrapping signed type, by observing that:
>
> (a) If cmp is == or !=, simply move X and C2 to opposite sides of
> the c
On 2024-09-26 18:41, Andrew Pinski wrote:
On Thu, Sep 26, 2024 at 10:28 AM Andrew Pinski wrote:
On Thu, Sep 26, 2024 at 10:15 AM 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
On Fri, 27 Sep 2024, Jakub Jelinek wrote:
> On Fri, Sep 27, 2024 at 08:16:43AM +0200, Richard Biener wrote:
> > > __attribute__((noinline))
> > > struct ref_proxy f ()
> > > {
> > >struct ref_proxy ptr;
> > >struct ref_proxy D.10036;
> > >struct ref_proxy type;
> > >struct ref_prox
On Mon, 23 Sep 2024, Artemiy Volkov wrote:
> Whenever C1 and C2 are integer constants, X is of a wrapping type, and
> cmp is a relational operator, the expression X +- C1 cmp C2 can be
> simplified in the following cases:
>
> (a) If cmp is <= and C2 -+ C1 == +INF(1), we can transform the initial
On Fri, Sep 20, 2024 at 12:40:28PM -0400, Siddhesh Poyarekar wrote:
> --- a/gcc/tree-object-size.cc
> +++ b/gcc/tree-object-size.cc
> @@ -1473,7 +1473,7 @@ merge_object_sizes (struct object_size_info *osi, tree
> dest, tree orig)
> with all of its targets are constants. */
>
> static tree
On Mon, 23 Sep 2024, Artemiy Volkov wrote:
> Implement a match.pd transformation inverting the sign of X in
> C1 - X cmp C2, where C1 and C2 are integer constants and X is
> of an unsigned type, by observing that:
>
> (a) If cmp is == or !=, simply move X and C2 to opposite sides of the
> compari
On Mon, 23 Sep 2024, Artemiy Volkov wrote:
> Implement a match.pd pattern for C1 - X cmp C2, where C1 and C2 are
> integer constants and X is of a UB-on-overflow type. The pattern is
> simplified to X rcmp C1 - C2 by moving X and C2 to the other side of the
> comparison (with opposite signs). If
On Fri, Sep 20, 2024 at 12:40:27PM -0400, Siddhesh Poyarekar wrote:
> --- a/gcc/tree-object-size.cc
> +++ b/gcc/tree-object-size.cc
> @@ -1468,6 +1468,63 @@ merge_object_sizes (struct object_size_info *osi, tree
> dest, tree orig)
>return bitmap_bit_p (osi->reexamine, SSA_NAME_VERSION (orig));
On Mon, 23 Sep 2024, Filip Kastl wrote:
> Hi,
>
> I'd like to ping my patch. You can find it here
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662744.html
>
> Btw I forgot to include [PR116616] in the subject. Hope I didn't confuse
> people. I will take care to include the ta
Pushed.
-- >8 --
ChangeLog:
* MAINTAINERS: Add myself as MVE Reviewer for the AArch32 (arm)
port.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 47b5915e9f8..ded5b3d4f64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -272,6 +272,
Continuing reading
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Technical-Report-13.html
showed that I missed one old item, which could be now removed:
With the new 'storage' map type it was also no longer fully applicable –
and the newly added text already covered it.
Committed as Rev. r15
On Fri, Sep 27, 2024 at 9:52 AM wrote:
>
> From: Pan Li
>
> We iterate all phi node of bb to try to match the SAT_* pattern
> for scalar integer. We also remove the phi mode when the relevant
> pattern matched.
>
> Unfortunately the iterator may have no idea the phi node is removed
> and continu
LGTM, you just need write few more boring ChangeLog in commit log like below:
libgcc/ChangeLog:
* config/riscv/save-restore.S: Check with __riscv_abi_rve
rather than __riscv_32e.
Anyway I committed to trunk with that changelog :)
On Fri, Sep 27, 2024 at 5:19 PM Tsung Chun Lin wrote:
>
>
Le 26/09/2024 à 21:57, Thomas Koenig a écrit :
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 mor
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
We need to ensure that for a declaration in the module purview, that the
resulting declaration has PURVIEW_P set and IMPORT_P cleared so that we
understand it might be something requiring exporting. This is normally
handle
This commitr15-3917-g6b7eaec20b046e updates .texi for one formatting (@emph →
@code) fix and updates some items for post TR13 changes. (The latter is
slightly questionable as the title says TR13, which is the third and
last draft of OpenMP 6.0, scheduled to be released in time for
Supercomputin
Hi Frank, all,
> On 26 Sep 2024, at 15:53, Frank Ch. Eigler wrote:
>> Regarding functionality, perfect enough AFAICT. I was going to
>> make a nitpick comment about comments with full sentences and
>> all that GNU...but better be consistent with the rest of the
>> file. Thanks!
>
> I don't
Hi Roger!
On 2024-07-27T19:18:35+0100, "Roger Sayle" wrote:
> Firstly, thanks to Haochen Gui for recently adding optab support for
> isfinite and isnormal to the middle-end.
Do we, by the way, have documentation (I suppose that should be in
"GNU Compiler Collection (GCC) Internals"?) about the r
On Fri, Sep 27, 2024 at 08:16:43AM +0200, Richard Biener wrote:
> > __attribute__((noinline))
> > struct ref_proxy f ()
> > {
> >struct ref_proxy ptr;
> >struct ref_proxy D.10036;
> >struct ref_proxy type;
> >struct ref_proxy type;
> >struct qual_option D.10031;
> >struct re
On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
+/* Helper function to determine whether SEQ represents a sequence of
+ instructions representing the Armv8.1-M Mainline conditional arithmetic
+ instructions: csinc, csneg and csinv. The cinc instruction is generated
+ using a diffe
On Sun, Sep 22, 2024 at 5:49 AM -thor wrote:
>
> From: thor
>
> 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
> find any memory leaks when testing in valg
On Sun, Sep 22, 2024 at 5:49 AM -thor wrote:
>
> From: thor
>
> This patch allows one to dump a tree as HTML from within gdb by invoking,
> i.e,
> htlml-tree tree
I have managed to get a browser window launched with the following
incremental patch
(xdg-open should be a better default than
From: Pan Li
We iterate all phi node of bb to try to match the SAT_* pattern
for scalar integer. We also remove the phi mode when the relevant
pattern matched.
Unfortunately the iterator may have no idea the phi node is removed
and continue leverage the free data and then ICE similar as below.
1 - 100 of 102 matches
Mail list logo
