This reverts commit 839bc42772ba7af66af3bd16efed4a69511312ae.
I have now pushed the temporary reversion of this to resolve the
P1 regressions this caused. I'll re-install it on trunk once 14.1
was released (which might be a week or two after stage1 opens).
Richard.
---
gcc/combine.cc | 11
On Tue, Apr 09, 2024 at 07:24:33AM -0700, H.J. Lu wrote:
> Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid
> the sanitizer configure check failure.
OK for binutils. (I just fixed my local copy of autoconf so I
wouldn't run into this again.) The proper fix of course is
On 3/12/24 10:51, Patrick Palka wrote:
On Tue, 12 Mar 2024, Patrick Palka wrote:
On Tue, 12 Mar 2024, Jason Merrill wrote:
On 3/11/24 12:53, Patrick Palka wrote:
r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
first so that we prefer processing a local specialization
On 4/9/24 3:19 PM, Peter Bergner wrote:
> Ok, current trunk ignores -mno-direct-move and warns on -mdirect-move, so to
> keep the same behavior for GCC 14 (before removing in stage1), we want just:
>
> mdirect-move
> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>
On Tue, Apr 09, 2024 at 10:28:01AM -0400, Jason Merrill wrote:
> On 4/9/24 09:36, Nathaniel Shead wrote:
> > On Mon, Apr 08, 2024 at 11:17:27PM -0400, Jason Merrill wrote:
> > > On 4/4/24 07:27, Nathaniel Shead wrote:
> > > > On Wed, Apr 03, 2024 at 11:18:01AM -0400, Jason Merrill wrote:
> > > > >
On 2/16/24 10:06, Patrick Palka wrote:
On Thu, 15 Feb 2024, Patrick Palka wrote:
One would expect consecutive calls to bytes_in/out::b for streaming
adjacent bits, as we do for tree flag streaming, to at least be
optimized by the compiler into individual bit operations using
statically known
On Tue, Apr 9, 2024 at 3:05 PM Hongyu Wang wrote:
>
> The latest APX spec announced removal of SHA/KEYLOCKER evex promotion [1],
> which means the SHA/KEYLOCKER insn does not support EGPR when APX
> enabled. Update the corresponding constraints to their EGPR-disabled
> counterparts.
>
>
On Tue, 09 Apr 2024 09:57:11 PDT (-0700), buga...@gmail.com wrote:
On Tue, Apr 9, 2024 at 7:24 PM Palmer Dabbelt wrote:
> I assume the buildbot failure that I just got an email about is
> unrelated; it's failing on some RISC-V thing.
Sorry if I missed something here, do you have a pointer?
I didn't actually regenerate this as I can't figure out how, I've just
pasted in the diff from the sourceware buildbot (which is complaining
about post-regeneration diff).
Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")
gcc/ChangeLog:
* config/riscv/riscv.opt.urls:
On Tue, Apr 9, 2024 at 4:08 PM Sam James wrote:
>
> "H.J. Lu" writes:
>
> > When -fsanitize=address,undefined is used to build, the mmap configure
> > check failed with
>
> I think Paul fixed this in autoconf commit
> 09b6e78d1592ce10fdc975025d699ee41444aa3f, so we should add a comment
> about
Tested x86_64-linux. Richi confirmed this fixes rx-elf bootstrap.
Pushed to trunk.
-- >8 --
If the faster std::from_chars is not supported for floating-point types
then just extract the value from the stream using operator>>.
This fixes a build error for targets where __cpp_lib_to_chars is not
"H.J. Lu" writes:
> When -fsanitize=address,undefined is used to build, the mmap configure
> check failed with
I think Paul fixed this in autoconf commit
09b6e78d1592ce10fdc975025d699ee41444aa3f, so we should add a comment
about that so we can clean this up in future.
>
>
On 3/5/24 10:31, Patrick Palka wrote:
On Tue, 27 Feb 2024, Patrick Palka wrote:
Subject: [PATCH] c++/modules: local type merging [PR99426]
One known missing piece in the modules implementation is merging of a
streamed-in local type (class or enum) with the corresponding in-TU
version of the
Hi FX!
On 4/9/24 09:32, FX Coudert wrote:
Hi Harald,
Thanks for the patch.
+ if (attr.function)
+{
+ gfc_error ("FPTR at %L to C_F_POINTER is a function returning a pointer",
+ >where);
+ return false;
+}
+
if (fptr->rank > 0 && !is_c_interoperable (fptr, , false,
On Tue, 26 Mar 2024, Patrick Palka wrote:
> On Tue, 27 Feb 2024, Patrick Palka wrote:
>
> > On Fri, 16 Feb 2024, Patrick Palka wrote:
> >
> > > On Thu, 15 Feb 2024, Patrick Palka wrote:
> > >
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > OK for trunk?
> > >
On Tue, 26 Mar 2024, Patrick Palka wrote:
> On Tue, 5 Mar 2024, Patrick Palka wrote:
>
> > On Tue, 27 Feb 2024, Patrick Palka wrote:
> >
> > > On Mon, 26 Feb 2024, Patrick Palka wrote:
> > >
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach
> > > > look reasonable?
On Tue, 26 Mar 2024, Patrick Palka wrote:
> On Mon, 11 Mar 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk and release branches?
>
> Ping.
Ping.
>
> >
> > -- >8 --
> >
> > r13-6452-g341e6cd8d603a3 made build_extra_args
On Wed, 27 Mar 2024, Patrick Palka wrote:
> On Mon, 25 Mar 2024, Patrick Palka wrote:
>
> > On Mon, 25 Mar 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > for trunk?
> > >
> > > -- >8 --
> > >
> > > The below testcases use a
On 4/9/24 12:37 AM, Kewen.Lin wrote:
> Since removing it completely is a stage1 thing, I prefer to keep mdirect-move
> and -mno-direct-move handlings as before, WarnRemoved and Ignore separately.
Ok, current trunk ignores -mno-direct-move and warns on -mdirect-move, so to
keep the same behavior
Hi!
On Fri, Apr 05, 2024 at 04:06:01AM +0200, Hans-Peter Nilsson wrote:
> The xpassing change in generated code was as follows, at
> r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert
> to verify that this suspect was the cause). That was so
> much of an improvement that I had to share
On Thu, 19 Oct 2023, Patrick Palka wrote:
> On Tue, 3 Oct 2023, David Malcolm wrote:
>
> > As mentioned in my Cauldron talk, this patch adds a call to
> > diagnostic_show_locus to the "required from here" messages
> > in print_instantiation_partial_context_line, so that e.g., rather
> > than the
On 4/8/24 2:01 PM, David Faust wrote:
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT
On Tue, Apr 9, 2024 at 10:25 AM Andrew Pinski wrote:
>
>
>
> On Tue, Apr 9, 2024, 10:07 H.J. Lu wrote:
>>
>> Since Glibc 2.34 all pthreads symbols are defined directly in libc not
>> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
>> avoid unnecessary locking in
On Tue, Apr 9, 2024, 10:07 H.J. Lu wrote:
> Since Glibc 2.34 all pthreads symbols are defined directly in libc not
> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
> avoid unnecessary locking in single-threaded programs. This means there
> is no reason to avoid linking
I would like to move forward on this patch. Are there any concerns, or
just the formatting of the patch, that needs to be addressed?
Since Glibc 2.34 all pthreads symbols are defined directly in libc not
libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
avoid unnecessary locking in single-threaded programs. This means there
is no reason to avoid linking to libpthread now, and so no reason to use
weak
On Tue, Apr 9, 2024 at 7:24 PM Palmer Dabbelt wrote:
> > I assume the buildbot failure that I just got an email about is
> > unrelated; it's failing on some RISC-V thing.
>
> Sorry if I missed something here, do you have a pointer?
The buildbot failure emails reference [0] and [1].
[0]:
On Tue, 09 Apr 2024 01:04:34 PDT (-0700), buga...@gmail.com wrote:
On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge wrote:
Thanks, pushed to trunk branch:
- commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move GNU/Hurd startfile spec
from config/i386/gnu.h to config/gnu.h"
- commit
Am Tue, Apr 09, 2024 at 05:01:18PM +0200 schrieb Andreas Krebbel:
> On 4/9/24 16:31, Juergen Christ wrote:
> > Loop vectorizer can generate vector permutes with constant indexes
> > where all indexes are equal. Optimize this case to use vector
> > replicate instead of vector permute.
> >
> >
Tamar Christina writes:
> Hi All,
>
> This is a backport of g:306713c953d509720dc394c43c0890548bb0ae07.
>
> The AArch64 vector PCS does not allow simd calls with simdlen 1,
> however due to a bug we currently do allow it for num == 0.
>
> This causes us to emit a symbol that doesn't exist and we
Andrew Carlotti writes:
> The first three patches are trivial changes to the feature list to reflect
> recent changes in the ACLE. Patch 4 removes most of the FMV multiversioning
> features that don't work at the moment, and should be entirely
> uncontroversial.
>
> Patch 5 handles the
Andrew Carlotti writes:
> There was an assumption in some places that the aarch64_fmv_feature_data
> array contained FEAT_MAX elements. While this assumption held up till
> now, it is safer and more flexible to use the array size directly.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.cc
Hello Alex:
On 09/04/24 8:39 pm, Alex Coplan wrote:
> On 09/04/2024 20:01, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 09/04/24 7:29 pm, Alex Coplan wrote:
>>> On 09/04/2024 17:30, Ajit Agarwal wrote:
On 05/04/24 10:03 pm, Alex Coplan wrote:
> On 05/04/2024 13:53, Ajit Agarwal
Richard Ball writes:
> When using LTO, handling the pragma for sme before the pragma
> for the neon-sve-bridge caused the following error on svset_neonq,
> in the neon-sve-bridge.c test.
>
> error: ACLE function '0' can only be called when SME streaming mode is
> enabled.
>
> This has been
On 09/04/2024 20:01, Ajit Agarwal wrote:
> Hello Alex:
>
> On 09/04/24 7:29 pm, Alex Coplan wrote:
> > On 09/04/2024 17:30, Ajit Agarwal wrote:
> >>
> >>
> >> On 05/04/24 10:03 pm, Alex Coplan wrote:
> >>> On 05/04/2024 13:53, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> All
When using LTO, handling the pragma for sme before the pragma
for the neon-sve-bridge caused the following error on svset_neonq,
in the neon-sve-bridge.c test.
error: ACLE function '0' can only be called when SME streaming mode is enabled.
This has been resolved by changing the pragma handlers
On 4/9/24 16:31, Juergen Christ wrote:
> Loop vectorizer can generate vector permutes with constant indexes
> where all indexes are equal. Optimize this case to use vector
> replicate instead of vector permute.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (expand_perm_as_replicate):
Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")
gcc/ChangeLog:
* config/riscv/riscv.opt.urls: Regenerated.
---
gcc/config/riscv/riscv.opt.urls | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/riscv/riscv.opt.urls b/gcc/config/riscv/riscv.opt.urls
index
On 4/9/24 05:57, Jakub Jelinek wrote:
On Mon, Apr 08, 2024 at 06:53:29PM -0400, Jason Merrill wrote:
+ if (warn_tautological_compare)
+{
+ tree cond = *condp;
+ while (TREE_CODE (cond) == ANNOTATE_EXPR)
+ cond = TREE_OPERAND (cond, 0);
+ if (trivial_infinite
+
Patch pushed after pre-approval by Harald on Bugzilla.
Fortran: Fix ICE in gfc_trans_pointer_assignment [PR113956]
2024-04-09 Paul Thomas
gcc/fortran
PR fortran/113956
* trans-expr.cc (gfc_trans_pointer_assignment): Remove assert
causing the ICE since it was
Hello Alex:
On 09/04/24 7:29 pm, Alex Coplan wrote:
> On 09/04/2024 17:30, Ajit Agarwal wrote:
>>
>>
>> On 05/04/24 10:03 pm, Alex Coplan wrote:
>>> On 05/04/2024 13:53, Ajit Agarwal wrote:
Hello Alex/Richard:
All review comments are incorporated.
>>>
>>> Thanks, I was kind-of
Loop vectorizer can generate vector permutes with constant indexes
where all indexes are equal. Optimize this case to use vector
replicate instead of vector permute.
gcc/ChangeLog:
* config/s390/s390.cc (expand_perm_as_replicate): Implement.
(vectorize_vec_perm_const_1): Call
Am Tue, Apr 09, 2024 at 11:51:00AM +0200 schrieb Stefan Schulze Frielinghaus:
> > +static bool expand_perm_as_replicate (const struct expand_vec_perm_d )
>^~~~
> Function names start on a new line.
Fixed
> > +{
> > + unsigned char i;
> > + unsigned char
On 4/9/24 09:36, Nathaniel Shead wrote:
On Mon, Apr 08, 2024 at 11:17:27PM -0400, Jason Merrill wrote:
On 4/4/24 07:27, Nathaniel Shead wrote:
On Wed, Apr 03, 2024 at 11:18:01AM -0400, Jason Merrill wrote:
On 4/2/24 20:57, Nathaniel Shead wrote:
On Tue, Apr 02, 2024 at 01:18:17PM -0400,
Hi Andrew,
On 4/9/24 16:12, Andrew Pinski wrote:
On Mon, Apr 8, 2024 at 9:39 AM wrote:
From: Pierre-Emmanuel Patry
Hello,
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.
NOTE cargo itself is a huge security hole. If
When -fsanitize=address,undefined is used to build, the mmap configure
check failed with
=
==231796==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7cdd3d0defdf in
When -fsanitize=address,undefined is used to build, the mmap configure
check failed with
=
==231796==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7cdd3d0defdf in
When -fsanitize=address,undefined is used to build, the mmap configure
check failed with
=
==231796==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7cdd3d0defdf in
On Mon, Apr 8, 2024 at 9:39 AM wrote:
>
> From: Pierre-Emmanuel Patry
>
> Hello,
>
> The rust frontend requires cargo to build some of it's components,
> it's presence was not checked during configuration.
NOTE cargo itself is a huge security hole. If anything we should place
all of the
On 09/04/2024 17:30, Ajit Agarwal wrote:
>
>
> On 05/04/24 10:03 pm, Alex Coplan wrote:
> > On 05/04/2024 13:53, Ajit Agarwal wrote:
> >> Hello Alex/Richard:
> >>
> >> All review comments are incorporated.
> >
> > Thanks, I was kind-of expecting you to also send the renaming patch as a
> >
> On 9 Apr 2024, at 08:53, Iain Sandoe wrote:
>
>
>
>> On 9 Apr 2024, at 08:48, Jakub Jelinek wrote:
>>
>> On Tue, Apr 09, 2024 at 09:44:01AM +0200, Richard Biener wrote:
>>> (why not do it at each such switch?)
>>
>> Because the traps would then be added even to the bbs which later
>>
So far, tested lightly on aarch64-darwin; if this is acceptable then
it will be possible to back out of the ad hoc fixes used on x86 and
powerpc darwin.
Comments welcome, thanks,
Iain
--- 8< ---
In the PR cited case a target linker cannot handle enpty FDEs,
arguably this is a linker bug - but
On 4/9/24 12:09, Iain Sandoe wrote:
Hi Arthur,
On 9 Apr 2024, at 13:01, Arthur Cohen wrote:
On 4/9/24 10:55, Iain Sandoe wrote:
Hi Arthur,
On 9 Apr 2024, at 11:40, Arthur Cohen wrote:
On 4/9/24 09:47, John Paul Adrian Glaubitz wrote:
Hello,
On Mon, 2024-04-08 at 18:33 +0200,
On Mon, Apr 08, 2024 at 11:17:27PM -0400, Jason Merrill wrote:
> On 4/4/24 07:27, Nathaniel Shead wrote:
> > On Wed, Apr 03, 2024 at 11:18:01AM -0400, Jason Merrill wrote:
> > > On 4/2/24 20:57, Nathaniel Shead wrote:
> > > > On Tue, Apr 02, 2024 at 01:18:17PM -0400, Jason Merrill wrote:
> > > > >
Add target_version attribute to Common Function Attributes and update
target and target_clones documentation. Move shared detail and examples
to the Function Multiversioning page. Add target-specific details to
target-specific pages.
---
I've built and checked the info and dvi outputs. Ok for
Some architecture features have been combined under a single command
line flag, but have been assigned multiple FMV feature names with the
command line flag name enabling only a subset of these features in
the FMV specification. Remove the unsupported FMV subfeatures, and
rename the remaining
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def:
Fix "rmd"->"rdm", and add FMV to "rdma".
* config/aarch64/aarch64.cc (FEAT_RDMA): Define as FEAT_RDM.
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
It currently isn't possible to support function multiversioning features
properly in GCC without also enabling the extension in the command line
options (with the exception of features such as "rpres" that do not
require assembler support). We therefore remove unsupported features
from GCC's list
There was an assumption in some places that the aarch64_fmv_feature_data
array contained FEAT_MAX elements. While this assumption held up till
now, it is safer and more flexible to use the array size directly.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (compare_feature_masks):
Some higher priority FMV features were dependent subsets of lower
priority features. Fix this, using the new priorities specified in
https://github.com/ARM-software/acle/pull/279.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def: Reorder FMV entries.
diff --git
The first three patches are trivial changes to the feature list to reflect
recent changes in the ACLE. Patch 4 removes most of the FMV multiversioning
features that don't work at the moment, and should be entirely uncontroversial.
Patch 5 handles the remaining cases, where there's an
David: Ping.
Le 2024-04-01 à 08 h 20, Antoni Boucher a écrit :
David: Ping.
Le 2024-03-19 à 07 h 03, Arthur Cohen a écrit :
Hi,
On 3/5/24 16:09, David Malcolm wrote:
On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
Hi.
See answers below.
On Thu, 2023-11-09 at 18:04 -0500, David
Sebastian Huber writes:
> On 09.04.24 14:10, Sam James wrote:
>> Sebastian Huber writes:
>>
>>> On 20.11.23 10:56, Florian Weimer wrote:
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change
On Tue, 9 Apr 2024, Jan Hubicka wrote:
> > The following adjusts -flto option processing in lto-wrapper to have
> > link-time -flto override any compile time setting.
> >
> > LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > OK for trunk and branches? GCC 11 seems to be
> The following adjusts -flto option processing in lto-wrapper to have
> link-time -flto override any compile time setting.
>
> LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK for trunk and branches? GCC 11 seems to be unaffected by this.
>
> Thanks,
> Richard.
>
>
On Tue, Apr 09, 2024 at 02:49:09PM +0200, Richard Biener wrote:
> The following adjusts -flto option processing in lto-wrapper to have
> link-time -flto override any compile time setting.
>
> LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK for trunk and branches? GCC 11
The following adjusts -flto option processing in lto-wrapper to have
link-time -flto override any compile time setting.
LTO-boostrapped on x86_64-unknown-linux-gnu, testing in progress.
OK for trunk and branches? GCC 11 seems to be unaffected by this.
Thanks,
Richard.
PR lto/114655
On 09.04.24 14:10, Sam James wrote:
Sebastian Huber writes:
On 20.11.23 10:56, Florian Weimer wrote:
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
Sebastian Huber writes:
> On 20.11.23 10:56, Florian Weimer wrote:
>> In the future, it may make sense to avoid cascading errors from
>> the implicit declaration, especially its assumed int return type.
>> This change here only changes the kind of the diagnostic, not
>> its wording or
On 05/04/24 10:03 pm, Alex Coplan wrote:
> On 05/04/2024 13:53, Ajit Agarwal wrote:
>> Hello Alex/Richard:
>>
>> All review comments are incorporated.
>
> Thanks, I was kind-of expecting you to also send the renaming patch as a
> preparatory patch as we discussed.
>
> Sorry for another meta
The following removes the unused tree_live_info_d->global bitmap.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.
Richard.
* tree-ssa-live.h (tree_live_info_d::global): Remove.
(partition_is_global): Likewise.
(make_live_on_entry): Do not set bit
Hello Alex/Richard:
All review comments are addressed.
Common infrastructure of load store pair fusion is divided into target
independent and target dependent changed code.
Target independent code is the Generic code with pure virtual function
to interface betwwen target independent and
On Tue, 9 Apr 2024, Jørgen Kvalsvik wrote:
> PR114601 shows that it is possible to reach the condition_uid lookup
> without having also created the fn->cond_uids, through
> compiler-generated conditionals. Consider all lookups on non-existing
> maps misses, which they are from the perspective of
On 09/04/2024 13:43, Jørgen Kvalsvik wrote:
PR114601 shows that it is possible to reach the condition_uid lookup
without having also created the fn->cond_uids, through
compiler-generated conditionals. Consider all lookups on non-existing
maps misses, which they are from the perspective of the
PR114601 shows that it is possible to reach the condition_uid lookup
without having also created the fn->cond_uids, through
compiler-generated conditionals. Consider all lookups on non-existing
maps misses, which they are from the perspective of the source code, to
avoid the NULL access.
On 20.11.23 10:56, Florian Weimer wrote:
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
its wording or consequences.
Maybe this change should be added
On Tue, Apr 9, 2024 at 5:18 PM Jakub Jelinek wrote:
>
> On Tue, Apr 09, 2024 at 11:23:40AM +0800, Hongtao Liu wrote:
> > I think we can merge alternative 2 with 3 to
> > * return TARGET_AES ? \"vaesenc\t{%2, %1, %0|%0, %1, %2}"\" :
> > \"%{evex%} vaesenc\t{%2, %1, %0|%0, %1, %2}\";
> > Then it
Hi Arthur,
> On 9 Apr 2024, at 13:01, Arthur Cohen wrote:
>
> On 4/9/24 10:55, Iain Sandoe wrote:
>> Hi Arthur,
>>> On 9 Apr 2024, at 11:40, Arthur Cohen wrote:
>>> On 4/9/24 09:47, John Paul Adrian Glaubitz wrote:
Hello,
On Mon, 2024-04-08 at 18:33 +0200,
Hi Iain!
On 4/9/24 10:55, Iain Sandoe wrote:
Hi Arthur,
On 9 Apr 2024, at 11:40, Arthur Cohen wrote:
On 4/9/24 09:47, John Paul Adrian Glaubitz wrote:
Hello,
On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
The rust frontend requires cargo to build some of
On Mon, Apr 08, 2024 at 06:53:29PM -0400, Jason Merrill wrote:
> > + if (warn_tautological_compare)
> > +{
> > + tree cond = *condp;
> > + while (TREE_CODE (cond) == ANNOTATE_EXPR)
> > + cond = TREE_OPERAND (cond, 0);
> > + if (trivial_infinite
> > + &&
On Tue, Apr 02, 2024 at 09:56:01AM +0200, Juergen Christ wrote:
> Loop vectorizer can generate vector permutes with constant indexes
> where all indexes are equal. Optimize this case to use vector
> replicate instead of vector permute.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc
Pushed to r14-9866.
在 2024/4/8 下午4:45, Yang Yujie 写道:
This patch fixes the back-end context switching in cases where functions
should be built with their own target contexts instead of the
global one, such as LTO linking and functions with target attributes (TBD).
PR target/113233
On Tue, Apr 09, 2024 at 11:23:40AM +0800, Hongtao Liu wrote:
> I think we can merge alternative 2 with 3 to
> * return TARGET_AES ? \"vaesenc\t{%2, %1, %0|%0, %1, %2}"\" :
> \"%{evex%} vaesenc\t{%2, %1, %0|%0, %1, %2}\";
> Then it can handle vaes_avx512vl + -mno-aes case.
Ok, done in the patch
Hi Arthur,
> On 9 Apr 2024, at 11:40, Arthur Cohen wrote:
> On 4/9/24 09:47, John Paul Adrian Glaubitz wrote:
>> Hello,
>> On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
>>> The rust frontend requires cargo to build some of it's components,
>>> it's presence was
Morning all,
On 4/9/24 09:47, John Paul Adrian Glaubitz wrote:
Hello,
On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.
Isn't this creating a
On Tue, 2024-04-09 at 10:00 +0200, Jakub Jelinek wrote:
> On Tue, Apr 09, 2024 at 09:47:18AM +0200, John Paul Adrian Glaubitz wrote:
> > Hello,
> >
> > On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
> > > The rust frontend requires cargo to build some of it's
gcc/ChangeLog:
* config/loongarch/loongarch.opt.urls: Regenerate.
* config/mn10300/mn10300.opt.urls: Likewise.
* config/msp430/msp430.opt.urls: Likewise.
* config/nds32/nds32-elf.opt.urls: Likewise.
* config/nds32/nds32-linux.opt.urls: Likewise.
*
On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge wrote:
> Thanks, pushed to trunk branch:
>
> - commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move GNU/Hurd startfile
> spec from config/i386/gnu.h to config/gnu.h"
> - commit 9670a2326333caa8482377c00beb65723b7b4b26 "aarch64: Add support for
Hi!
My earlier libquadmath change apparently broke mingw32 build, while on Linux
is included and defines these, on Mingw apparently that isn't
the case, while soft-fp wants a guarantee that sfp-machine.h defines these.
Tested on x86_64-linux, committed to trunk.
2024-04-09 Jakub Jelinek
On Tue, Apr 09, 2024 at 09:47:18AM +0200, John Paul Adrian Glaubitz wrote:
> Hello,
>
> On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
> > The rust frontend requires cargo to build some of it's components,
> > it's presence was not checked during configuration.
>
>
On 09/04/2024 09:40, Richard Biener wrote:
On Mon, 8 Apr 2024, Jørgen Kvalsvik wrote:
Generating the constants used for recording the edges taken for
condition coverage would trigger undefined behavior when an expression
had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
> On 9 Apr 2024, at 08:48, Jakub Jelinek wrote:
>
> On Tue, Apr 09, 2024 at 09:44:01AM +0200, Richard Biener wrote:
>> (why not do it at each such switch?)
>
> Because the traps would then be added even to the bbs which later
> end up in the middle of the function.
If we defer the
On Tue, Apr 09, 2024 at 09:44:01AM +0200, Richard Biener wrote:
> (why not do it at each such switch?)
Because the traps would then be added even to the bbs which later
end up in the middle of the function.
Jakub
Hello,
On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote:
> The rust frontend requires cargo to build some of it's components,
> it's presence was not checked during configuration.
Isn't this creating a hen-and-egg problem? How am I supposed to build a Rust
compiler for
On Tue, Apr 9, 2024 at 9:11 AM Jakub Jelinek wrote:
>
> On Tue, Apr 09, 2024 at 09:03:59AM +0200, Richard Biener wrote:
> > > With the possibility of sounding like a broken record, I think
> > > __builtin_unreachable is fundamentally flawed. It generates no code
> > > and just lets the program
On Mon, Apr 8, 2024 at 6:39 PM wrote:
>
> From: Pierre-Emmanuel Patry
>
> Hello,
>
> The rust frontend requires cargo to build some of it's components,
> it's presence was not checked during configuration.
OK.
Please work on documenting build requirements for rust in doc/install.texi,
look for
On Mon, 8 Apr 2024, Jørgen Kvalsvik wrote:
> Generating the constants used for recording the edges taken for
> condition coverage would trigger undefined behavior when an expression
> had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
> constant for the next iteration at the
On Mon, 8 Apr 2024, Jørgen Kvalsvik wrote:
> Properly add the condition -> expression mapping of inlined gconds from
> the caller into the callee map. This is a fix for PR114599 that works
> beyond fixing the segfault, as the previous fixed copied references to
> the source gconds, not the deep
Hi Harald,
Thanks for the patch.
> + if (attr.function)
> +{
> + gfc_error ("FPTR at %L to C_F_POINTER is a function returning a
> pointer",
> + >where);
> + return false;
> +}
> +
>if (fptr->rank > 0 && !is_c_interoperable (fptr, , false, true))
> return
Hi!
On 2024-04-05T15:13:33+0300, Sergey Bugaev wrote:
> On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford
> wrote:
>> I don't know if you're waiting on me, but just in case: this and patch 3
>> still LGTM if Thomas is OK with them.
>
> Thanks. Thomas asked me to resubmit with Changelog entries
1 - 100 of 110 matches
Mail list logo
