On Tue, Apr 9, 2024 at 6:03 AM Jeff Law wrote:
>
>
>
> On 4/8/24 5:04 PM, Iain Sandoe wrote:
> > Hi
> >
> > PR 109627 is about functions that have had their bodies completely elided,
> > but still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx).
> >
> > These are causing issues f
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.
Bootstrapped and regtested on x86-64-pc-linux-gnu.
Ok for trunk?
[1].htt
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 continue if ever "reached". This is a
> > security risk and (IM
Hi!
Another patch from eyeballing
git grep -v 'long long\|optab optab\|template template\|double double' | grep '
\([a-zA-Z]\+\) \1 '
output, this time in gcc/ subdirectory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-09 Jakub Jelinek
gcc/
* expr.cc
On Tue, 9 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> Another patch from eyeballing
> git grep -v 'long long\|optab optab\|template template\|double double' | grep
> ' \([a-zA-Z]\+\) \1 '
> output, this time in gcc/ subdirectory.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for tr
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 ad
Hi Harald,
Thanks for the patch.
> + if (attr.function)
> +{
> + gfc_error ("FPTR at %L to C_F_POINTER is a function returning a
> pointer",
> + &fptr->where);
> + return false;
> +}
> +
>if (fptr->rank > 0 && !is_c_interoperable (fptr, &msg, false, true))
> return g
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 co
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 en
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 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 c
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 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
> 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 unreachabl
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
con
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.
>
> I
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 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
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.
* co
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 componen
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 hen-
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 not
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 be
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
gcc/
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 (expand_p
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
> > + && !maybe_constexpr_fn
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 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, pierre-emmanuel.pa...@embec
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 ca
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
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.
P
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 sou
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 t
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 dependen
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 i
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 co
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 consequence
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
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 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.
>
>
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
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 h
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 Mal
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 inconsistenc
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 a/gcc/confi
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):
Us
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
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
b/gcc/config/aarch64/aarch64-option-extensio
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 feat
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
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:
> > > > >
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, pierre-
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 in
> 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
>> en
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
> > prepa
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 required
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 __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 __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 __in
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 a
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, Jason
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 &d)
>^~~~
> Function names start on a new line.
Fixed
> > +{
> > + unsigned char i;
> > + unsigned char ele
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 new
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 expec
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 unnecesary
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
+ &
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 da31820e23
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): Implem
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 to
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 review
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 resolv
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 w
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
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 remaining
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 f
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.
> >
> > gcc/
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 9670a2
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]: https://
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 symbol
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?
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 to
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 single-thr
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 generate
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
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 it
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 fo
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 lambd
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 walk
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 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?
> > > >
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",
+ &fptr->where);
+ return false;
+}
+
if (fptr->rank > 0 && !is_c_interoperable (fptr, &msg, f
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 loc
"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.
>
> ==
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
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 th
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: Regenerated.
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?
T
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.
>
> Bootstrapp
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 bi
1 - 100 of 106 matches
Mail list logo
