On Tue, Oct 08, 2024 at 02:09:52AM +0200, Alejandro Colomar wrote:
> On the other hand, should we provide a version of the operator that is
> free from pedantic warnings? A GNU extension?
No, why? One can always use (__extension__ _Lengthof (...)).
Jakub
On Mon, Sep 30, 2024 at 3:33 PM Jan Beulich wrote:
>
> Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly
> said "..., but we need to emit {evex} prefix in the assembly if AES ISA
> is not enabled". Yet it did so only for the TARGET_AES insns. Going from
> the alternative cho
On Mon, 7 Oct 2024, Prathamesh Kulkarni wrote:
>
>
> > -Original Message-
> > From: Prathamesh Kulkarni
> > Sent: Tuesday, October 1, 2024 8:26 PM
> > To: Richard Sandiford
> > Cc: rguent...@suse.de; Thomas Schwinge ; gcc-
> > patc...@gcc.gnu.org
> > Subject: RE: Re-compute TYPE_MODE a
0001-RISC-V-Enable-builtin-__riscv_mul-with-Zmmul-extensi.patch
Description: Binary data
0001-RISC-V-Add-implication-for-M-extension.patch
Description: Binary data
Bah. The pre-commit tester saw my previous message as just a comment on
the thread rather than an update to Palmer's patch. So this is a
re-post so that the pre-commit tester picks up the new patch. The patch
itself is unchanged.
--
> We have cheap logical ops, so let's just move this back
Pushed to r15-4130.
在 2024/7/11 下午7:43, Xi Ruoyao 写道:
This is per the request from the kernel developers. For generating the
ORC unwind info, the objtool program needs to analysis the control flow
of a .o file. If a jump table is used, objtool has to correlate the
jump instruction with the tab
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-10-08 09:21
To: gcc-patches
CC: richard.guenther; Tamar.Christina; juzhe.zhong; kito.cheng; jeffreyalaw;
rdapp.gcc; Pan Li
Subject: [PATCH v1 2/3] RISC-V: Add testcases for form 3 of scalar signed
SAT_SUB
From: Pan Li
Form 3:
#define DE
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-10-08 09:21
To: gcc-patches
CC: richard.guenther; Tamar.Christina; juzhe.zhong; kito.cheng; jeffreyalaw;
rdapp.gcc; Pan Li
Subject: [PATCH v1 3/3] RISC-V: Add testcases for form 4 of scalar signed
SAT_SUB
From: Pan Li
Form 4:
#define DE
From: Pan Li
Form 4:
#define DEF_SAT_S_SUB_FMT_4(T, UT, MIN, MAX) \
T __attribute__((noinline))\
sat_s_sub_##T##_fmt_4 (T x, T y) \
{ \
T minus;
From: Pan Li
Form 3:
#define DEF_SAT_S_SUB_FMT_3(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_sub_##T##_fmt_3 (T x, T y) \
{\
T minus;
From: Pan Li
This patch would like to support the form 3 and form 4 of the scalar signed
integer SAT_SUB. Aka below example:
Form 3:
#define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
T __attribute__((noinline))\
sat_s_add_##T##_fmt_3 (T x, T y)
On Tue, Oct 08, 2024 at 02:04:39AM GMT, Alejandro Colomar wrote:
> Hi Joseph,
>
> On Mon, Oct 07, 2024 at 05:35:16PM GMT, Joseph Myers wrote:
> > Patches 1, 2 and 3 are logically nothing to do with this feature. I'll
> > wait for them to be reviewed so that we only have a single-patch series,
>
Hi Joseph,
On Mon, Oct 07, 2024 at 05:35:16PM GMT, Joseph Myers wrote:
> Patches 1, 2 and 3 are logically nothing to do with this feature. I'll
> wait for them to be reviewed so that we only have a single-patch series,
> before doing final review of the main patch.
I do not fully understand.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
This doesn't seem worth backporting since there should be no
behavior change.
-- >8 --
This implements the library changes in P0849R8 "auto(x): decay-copy
in the language" which consist of replacing most uses of the
exposition-only
ping?
Thanks,
Kugan
From: Kugan Vivekanandarajah
Sent: Tuesday, 20 August 2024 6:18 PM
To: Jakub Jelinek
Cc: gcc-patches@gcc.gnu.org ;
richard.guent...@gmail.com ;
richard.sandif...@arm.com
Subject: Re: [PR middle-end/114635] Set OMP safelen handling to INT_MA
See the previous post for a longer explanation of the motavations for this
patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664694.html
This patch adds a new include file (vector-pair.h) that implements a series of
functions that allows people implementing high performance librar
On 9/28/24 12:49, Torbjörn SVENSSON wrote:
Ok for trunk?
Changes since v1:
- Updated the commit message to mention the actual build error.
- Switch to checking the required define rather than the version number of
MinGW.
Patch looks OK to me.
Thanks for the reminder.
On Monday, October 7th, 2024 at 4:41 PM, Marek Polacek
wrote:
>
>
> On Sat, Jun 15, 2024 at 10:30:35PM -0700, Ken Matsui wrote:
>
> > This patch adds a warning switch for "#pragma once in main file". The
> > warning option name is Wpragma-once-outside-header, which is the same
> > as Clang provi
Committed as r15-4127-gb95ad25f9c9376
Hi Thomas,
Thomas Schwinge wrote:
On 2024-10-07T17:07:05+0200, Tobias Burnus wrote:
If anyone can reproduce this, I would be interested in the excess errors.
gfortran: fatal error: cannot read spec file 'libgomp.spec': No such file
or directory
A
Arsen Arsenović writes:
> This patch series implements support for coroutines whose frames require
> alignment.
>
> The standard currently does not specify much about this case AFAICT, so
> we can do this for now (until P2014 progresses).
>
> The new dump was useful for testing, and might be usef
Hi Tobias!
On 2024-10-07T17:07:05+0200, Tobias Burnus wrote:
> haochen.jiang wrote:
>> On Linux/x86_64,
>> FAIL: gfortran.dg/gomp/allocate-static.f90 -O0 (test for excess errors)
>
> If anyone can reproduce this, I would be interested in the excess errors.
gfortran: fatal error: cannot re
Ping on this patch.
TIA, have a lovely day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
I will post the actual patch in the next post. This part gives the
justification for the patch adding vector-pair.h.
The patch as a followup to this post adds a new include file (vector-pair.h)
that adds support so that users writing high performance libraries can change
their code to allow the g
Another update of
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Technical-Report-13.html
I made another pass through that list, comparing with the current OpenMP
6 draft and found a couple of issues and improved the wording. I am
sure, more word tweaking can be done and not unlikely I missed s
Hi Andre,
On 10/7/24 11:04, Andre Vehreschild wrote:
Hi Harald,
thank you for your input. I still have some small nits to discuss to make
everyone happy. Therefore:
this seems to go into the right direction - except that I am not a
great fan of gfc_error_now, as that tries to paper over defic
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Tuesday, October 1, 2024 8:26 PM
> To: Richard Sandiford
> Cc: rguent...@suse.de; Thomas Schwinge ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: Re-compute TYPE_MODE and DECL_MODE while streaming in for
> accelerator
>
> External em
On Sat, Jun 15, 2024 at 10:30:35PM -0700, Ken Matsui wrote:
> This patch adds a warning switch for "#pragma once in main file". The
> warning option name is Wpragma-once-outside-header, which is the same
> as Clang provides.
I think the patch is OK now, thanks. Other diagnostics inlude the '#'
c
Gentle ping :)
Kind regards,
Torbjörn
On 2024-09-28 14:49, Torbjörn SVENSSON wrote:
Ok for trunk?
Changes since v1:
- Updated the commit message to mention the actual build error.
- Switch to checking the required define rather than the version number of
MinGW.
--
The define ENABLE_VIRTUAL
Hi Marek,
On 7 Oct 2024, at 21:44, Marek Polacek wrote:
> On Mon, Oct 07, 2024 at 07:35:27PM +, Simon Martin wrote:
>> -/* Remove any overridden functions. */
>> -bool seen_non_override = false;
>> +/* Find all the base_fndecls that are overridden, as well as those
>> + tha
Hi Jason,
On 30 Sep 2024, at 20:56, Jason Merrill wrote:
> On 9/17/24 8:14 AM, Simon Martin wrote:
>> The invalid test case in this PR highlights a bad interaction between
>> the tentative_firewall and error recovery in cp_parser_decltype: the
>> firewall makes cp_parser_skip_to_closing_parenthe
This patch seems to have been over looked.
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663101.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Mon, Oct 07, 2024 at 07:35:27PM +, Simon Martin wrote:
> - /* Remove any overridden functions. */
> - bool seen_non_override = false;
> + /* Find all the base_fndecls that are overridden, as well as those
> +that are hidden, in T. */
> for (tree fndecl : ovl_range
Hi Jason,
On 7 Oct 2024, at 18:58, Jason Merrill wrote:
> On 10/7/24 11:27 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 17 Sep 2024, at 18:41, Jason Merrill wrote:
>>
>>> On 9/17/24 10:38 AM, Simon Martin wrote:
Hi Jason,
Apologies for the back and forth and thanks for your patien
On Mon, 7 Oct 2024, Jason Merrill wrote:
> On 10/7/24 10:26 AM, Patrick Palka wrote:
> > On Mon, 7 Oct 2024, Jason Merrill wrote:
> >
> > > On 10/7/24 9:58 AM, Patrick Palka wrote:
> > > > On Sat, 5 Oct 2024, Jason Merrill wrote:
> > > >
> > > > > On 10/4/24 11:00 AM, Patrick Palka wrote:
> > >
Hi Richard,
On 2024-10-07 12:45, Richard Earnshaw (lists) wrote:
On 07/10/2024 09:03, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Update test cases to use -mcpu=unset/-march=unset feature introduced in
r15-3606-g7d6c6a0d15c.
The acronym ET isn't one I recognize - I'm guessing you intend it to
On Wed, Oct 02, 2024 at 05:52:13PM -0400, Jason Merrill wrote:
> On 10/2/24 3:20 PM, Marek Polacek wrote:
> > On Sat, Sep 28, 2024 at 08:39:12AM +0200, Jakub Jelinek wrote:
> > > On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
> > > > So, I think we should go with (but so far complet
On Wed, Sep 18, 2024 at 06:00:48PM +0200, Jakub Jelinek wrote:
> Hi!
>
> The _cpp_trigraph_map initialization used to be done for C99+ using
> designated initializers, but can't be done that way for C++ because
> the designated initializer support in C++ as array designators are just
> an extensio
On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
We have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR target/116615
* config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove.
---
There's a
Patches 1, 2 and 3 are logically nothing to do with this feature. I'll
wait for them to be reviewed so that we only have a single-patch series,
before doing final review of the main patch.
Since the feature was accepted as _Lengthof, that's the form that should
be added to GCC; no __lengthof__
Thanks for the review.
Just pushed as:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9a17e6d03c6ed53e3b2dfd2c3ff9b1066ffa97b9
Qing
> On Oct 7, 2024, at 11:44, Marek Polacek wrote:
>
> On Wed, Oct 02, 2024 at 10:20:11PM +, Qing Zhao wrote:
>> From: qing zhao
>>
>> Hi, this is the 2nd ver
Thanks for the patch! You certainly worked that out faster than I could
create a reproducer. It's a bit late for me now, so I'll have to try it out
tomorrow. Note however that in the final patch I will be only doing TLS for
mingw32.h and not cygming.h. The reason for this is that Cygwin likely
cann
On 10/7/24 10:26 AM, Patrick Palka wrote:
On Mon, 7 Oct 2024, Jason Merrill wrote:
On 10/7/24 9:58 AM, Patrick Palka wrote:
On Sat, 5 Oct 2024, Jason Merrill wrote:
On 10/4/24 11:00 AM, Patrick Palka wrote:
On Thu, 3 Oct 2024, Jason Merrill wrote:
On 10/3/24 12:38 PM, Jason Merrill wrote:
On 10/7/24 11:27 AM, Simon Martin wrote:
Hi Jason,
On 17 Sep 2024, at 18:41, Jason Merrill wrote:
On 9/17/24 10:38 AM, Simon Martin wrote:
Hi Jason,
Apologies for the back and forth and thanks for your patience!
No worries.
On 5 Sep 2024, at 19:00, Jason Merrill wrote:
On 9/5/24 7:02 A
On Sat, 28 Sep 2024, Jakub Jelinek wrote:
> I'd hope that structure assignment is element-wise copying and so doesn't
> need to preserve those bits. What about memcpy, or *(unsigned char *),
> or for C++ std::bit_cast inspection of the bits (constexpr for C++ or not)?
In C, memcpy or *(unsigned
On 10/4/24 1:02 PM, Jakub Jelinek wrote:
On Thu, Oct 03, 2024 at 12:14:35PM -0400, Jason Merrill wrote:
Agreed, the padding bits have indeterminate values (or erroneous in C++26),
so it's correct for infoleak-1.c to complain about 4b.
I've been afraid what the kernel people would say about thi
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In Wmismatched-tags-6.C, we try to compare two declarations of the Cp alias
template, and ICE trying to check whether they're in module purview. We
need to check DECL_LANG_SPECIFIC like elsewhere in the compiler.
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
init_modules has rejected -M -fmodules-ts on the premise that module
dependency analysis requires macro expansion, but this is no longer
accurate; P1857 prohibited module directives produced by macro expansion.
They can still be dependent on
On Wed, Oct 02, 2024 at 10:20:11PM +, Qing Zhao wrote:
> From: qing zhao
>
> Hi, this is the 2nd version of the patch.
> compared to the 1st version, the major changes are to address Marek and
> Jacub's comments.
>
> bootstrapped and regression tested on both x86 and aarch64.
> Okay for com
Hi Jason,
On 17 Sep 2024, at 18:41, Jason Merrill wrote:
> On 9/17/24 10:38 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> Apologies for the back and forth and thanks for your patience!
>
> No worries.
>
>> On 5 Sep 2024, at 19:00, Jason Merrill wrote:
>>
>>> On 9/5/24 7:02 AM, Simon Martin wrote:
>>
haochen.jiang wrote:
On Linux/x86_64,
FAIL: gfortran.dg/gomp/allocate-static.f90 -O0 (test for excess errors)
If anyone can reproduce this, I would be interested in the excess errors.
On two machines – with and without offloading configured – I cannot
reproduce this neither with a bootsstr
Hi!
I'd to ping a few libcpp patches
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662960.html
- [PATCH] libcpp, genmatch: Use gcc_diag instead of printf for libcpp
diagnostics
The genmatch side approved, libcpp remains
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664
Hi!
The _cpp_trigraph_map initialization used to be done for C99+ using
designated initializers, but can't be done that way for C++ because
the designated initializer support in C++ as array designators are just
an extension there and don't allow skipping anything nor going backwards.
But, we can
Hi!
I'd like to ping 16 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662750.html
CWG 2867 - Order of initialization for structured bindings - rest of
implementation [PR115769]
https://gcc.gnu.org/pip
Hi!
I'd like to ping a few #embed related patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657053.html
- [PATCH] libcpp, c, middle-end: Optimize initializers using #embed in C
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658137.html
- [PATCH] libcpp, c++: Optimize initiali
On Mon, 7 Oct 2024, Jason Merrill wrote:
> On 10/7/24 9:58 AM, Patrick Palka wrote:
> > On Sat, 5 Oct 2024, Jason Merrill wrote:
> >
> > > On 10/4/24 11:00 AM, Patrick Palka wrote:
> > > > On Thu, 3 Oct 2024, Jason Merrill wrote:
> > > >
> > > > > On 10/3/24 12:38 PM, Jason Merrill wrote:
> > >
On Linux/x86_64,
a8caeaacf499d58ba7ceabc311b7b71ca806f740 is the first bad commit
commit a8caeaacf499d58ba7ceabc311b7b71ca806f740
Author: Tobias Burnus
Date: Mon Oct 7 10:45:14 2024 +0200
OpenMP: Allocate directive for static vars, clean up
caused
FAIL: gfortran.dg/gomp/allocate-static.f
On 10/7/24 9:58 AM, Patrick Palka wrote:
On Sat, 5 Oct 2024, Jason Merrill wrote:
On 10/4/24 11:00 AM, Patrick Palka wrote:
On Thu, 3 Oct 2024, Jason Merrill wrote:
On 10/3/24 12:38 PM, Jason Merrill wrote:
On 10/2/24 7:50 AM, Richard Biener wrote:
This reduces peak memory usage by 20% for
On Sat, 5 Oct 2024, Jason Merrill wrote:
> On 10/4/24 11:00 AM, Patrick Palka wrote:
> > On Thu, 3 Oct 2024, Jason Merrill wrote:
> >
> > > On 10/3/24 12:38 PM, Jason Merrill wrote:
> > > > On 10/2/24 7:50 AM, Richard Biener wrote:
> > > > > This reduces peak memory usage by 20% for a specific te
Committed attached patch as obvious.
This obvious patch fixes two warnings introduced with the implementation
of arm_noce_conversion_profitable_p hook.
gcc/ChangeLog:
* config/arm/arm.cc (arm_noce_oncersion_profitable_p): Remove unused
argument name.
(arm_is_v81m_cond_
On Mon, 2024-10-07 at 20:37 +0800, Xi Ruoyao wrote:
> On Mon, 2024-10-07 at 14:25 +0200, Jakub Jelinek wrote:
> > On Mon, Oct 07, 2024 at 03:05:56PM +0300, Дилян Палаузов wrote:
> > > does [[noreturn]] optimize the generated [[noreturn]] function itself, or
> > > it optimizes the calls to the [[nor
I suggest not handling the extension implication rules. This way, it
can simplify
the logic and reduce the cost of run-time checks.
Also, you need to consider situations where that extension can't be detected.
And last, I would like to defer this until run-time resolver patch coming, but
welcome
On Mon, 2024-10-07 at 14:25 +0200, Jakub Jelinek wrote:
> On Mon, Oct 07, 2024 at 03:05:56PM +0300, Дилян Палаузов wrote:
> > does [[noreturn]] optimize the generated [[noreturn]] function itself, or
> > it optimizes the calls to the [[noreturn]] function? Hence, in the latter
> > case optimizatio
Hi!
I've noticed some files were marked as executable, as can be
seen with
find . \( -name \*.[chSC] -o -name \*.md -o -name \*.cc \) -a -perm /111 |
xargs ls -l
This commit fixes that.
Committed as obvious.
2024-10-07 Jakub Jelinek
gcc/
* config/riscv/vector-crypto.md: Remove exec
On Mon, Oct 07, 2024 at 03:05:56PM +0300, Дилян Палаузов wrote:
> does [[noreturn]] optimize the generated [[noreturn]] function itself, or
> it optimizes the calls to the [[noreturn]] function? Hence, in the latter
> case optimizations are done based on function declaration, irrespective of
> fun
Hello Jakub,
does [[noreturn]] optimize the generated [[noreturn]] function itself, or it
optimizes the calls to the [[noreturn]] function? Hence, in the latter case
optimizations are done based on function declaration, irrespective of function
body.
Greetings
Дилян
-Original Message-
The following fixes checking for unsupported control flow in
vectorization to also cover the outer loop body.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/116990
* tree-vect-loop.cc (vect_analyze_loop_form): Check the current
loop body
The following makes sure to discover the scalar loop IV exit during
analysis as failure to do so (if DCE and friends are disabled this
can happen due to if-conversion doing DCE and FRE on the if-converted
loop) would ICE later.
I refrained from larger refactoring to be able to eventually backport.
On 10/7/24 10:52, Richard Biener wrote:
On Wed, Oct 2, 2024 at 6:26 PM Victor Do Nascimento
wrote:
Given the categorization of math built-in functions as `ECF_CONST',
when if-converting their uses, their calls are not masked and are thus
called with an all-true predicate.
This, however, is no
On Mon, 7 Oct 2024 at 11:47, Jakub Jelinek wrote:
>
> Hi!
>
> It is autumn again and there is a new Unicode version 16.0.
>
> The following patch updates our Unicode stuff in contrib, libcpp and
> libstdc++ from that Unicode version.
>
> As the patch is really large, I've split the unicode/UnicodeD
As some have detected, the older FSF licenses changed as FSF moved out
of their Franklin Street office.
That's sensible as writing to the old address is not the best way to get
a printed version of the license and as the internet is now really
ubiquitous.
→ https://www.fsf.org/blogs/communit
Hi all,
this patch somehow slipped my attention. Anyone for a review? Third time ping!
Rebased to current mainline.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
On Wed, 18 Sep 2024 12:30:23 +0200
Andre Vehreschild wrote:
> Hi all,
>
> back from my h
On 07/10/2024 09:03, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
The acronym ET isn't one I recognize - I'm guessing you intend it to be
Effective Target, rather than Extra Terrestrial, or E
On 07/10/2024 10:15, Christophe Lyon wrote:
On Mon, 7 Oct 2024 at 11:04, Torbjorn SVENSSON
wrote:
On 2024-10-07 10:53, Andre Vieira (lists) wrote:
Hi Torbjorn,
2. All other the test cases in the list above: These need to be
adapted to the change introduced in r15-3606-g7d6c6a0d15c to
On Sat, Oct 5, 2024 at 10:17 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Time vars normally use times(2) to get the user/sys/wall time, which is
> always a
> system call. I don't think the system time is very useful because most
> overhead
> is in user time. If we only use the wall (or monoto
On Sun, 6 Oct 2024, Jeff Law wrote:
> V2:
> Fix typo in ChangeLog.
> Remove now extraneous comment in cset-sext.c.
> Throttle back branch cost to 1 in various tests
Thank you for addressing my concerns.
There's a bunch of extraneous trailing new lines to remove if you care
doing this in
Could you implement the latest API defined in the doc?
struct {
unsigned length;
unsigned long long features[];
} __riscv_feature_bits;
struct {
unsigned length;
unsigned long long features[];
} __riscv_vendor_feature_bits;
struct {
unsigned mvendorid;
unsigned marchid;
unsigned mimpid;
} __risc
> I'm not quite sure what you mean by a testcase, but when compiling gcc
> itself, when libgomp/libgcc (Can't remember which) is being compiled, gcc
> will spit out invalid assembly that looks something like
>
> movabsq $8+__gcov_indirect_call@secrel32, %rax
OK, I can reproduce this at -O0:
_gco
On Wed, Oct 2, 2024 at 6:26 PM Victor Do Nascimento
wrote:
>
> Given the categorization of math built-in functions as `ECF_CONST',
> when if-converting their uses, their calls are not masked and are thus
> called with an all-true predicate.
>
> This, however, is not appropriate where built-ins hav
On 23/09/2024 11:31, Alex Coplan wrote:
> Hi,
>
> As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into
> returning false when a common base register (in this case, x1) was
> modified between the mem and the store insn. This lead to wrong code as
> the accesses really did alias
Hi Andre,
first, thanks a lot for all your proof reading of patches! That's indeed
helpful and reviewing (with offical LGTM stamp or as bystander) is a
problem, you help to reduce it! :-)
Andre Vehreschild wrote:
@@ -821,6 +821,23 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
+ if (s
On Fri, 4 Oct 2024, Richard Sandiford wrote:
> This series should fix the target-independent parts of PR116583.
> (We also need some target-specific patches, to be posted separately.)
>
> The explanations are in the individual commit messages, but I've
> attached a -b diff below in case my attemp
Hi Tobias,
just a question:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 8231bd255d6..2586c6d7a79 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -821,6 +821,23 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
&& (TREE_STATIC (decl)
On Mon, 7 Oct 2024 at 11:04, Torbjorn SVENSSON
wrote:
>
>
>
> On 2024-10-07 10:53, Andre Vieira (lists) wrote:
> > Hi Torbjorn,
> >
> > On 07/10/2024 09:08, Torbjorn SVENSSON wrote:
> >
> >
> >>
> >> There are 3 test cases that are fixed with these 2 commits, but there
> >> is also a bunch that is
Understood. I will try to reproduce the issue in the meantime as I rewrite
the patch
best regards,
Julian
On Mon, Oct 7, 2024 at 5:07 PM Sam James wrote:
> Julian Waters writes:
>
> > Resending again as I forgot to send it to the list
> >
> >> Sorry, I somehow missed it. :-( Then a configure
Julian Waters writes:
> Resending again as I forgot to send it to the list
>
>> Sorry, I somehow missed it. :-( Then a configure check should be added in
>> the
>> compiler to tell whether the detected linker has the fix or not.
>
>> There are already some specific checks for the PE linker at
On 2024-10-07 10:53, Andre Vieira (lists) wrote:
Hi Torbjorn,
On 07/10/2024 09:08, Torbjorn SVENSSON wrote:
There are 3 test cases that are fixed with these 2 commits, but there
is also a bunch that is marked as new fails.
Looking at the test cases that fail, there are 2 different kinds
Hi Harald,
thank you for your input. I still have some small nits to discuss to make
everyone happy. Therefore:
> this seems to go into the right direction - except that I am not a
> great fan of gfc_error_now, as that tries to paper over deficiencies
> in error recovery.
Me either, but when I r
Hi Torbjorn,
On 07/10/2024 09:08, Torbjorn SVENSSON wrote:
There are 3 test cases that are fixed with these 2 commits, but there is
also a bunch that is marked as new fails.
Looking at the test cases that fail, there are 2 different kinds of
failures.
1. gcc.target/arm/attr_thumb.c: This
Resending again as I forgot to send it to the list
> Sorry, I somehow missed it. :-( Then a configure check should be added
in the
> compiler to tell whether the detected linker has the fix or not.
> There are already some specific checks for the PE linker at
configure.ac:6500,
> although they d
Now committed as r15-4104-ga8caeaacf499d5.
With a wording improvement in the commit log and avoiding an XPASS for
C++ by excluding c++98 from the xfail in dg-bogus... xfail.
Tobias
Tobias Burnus wrote:
'omp allocate' permits to use a different (specified) allocator and
alignment for both sta
On Mon, Oct 07, 2024 at 10:21:05AM +0300, Дилян Палаузов wrote:
> do you mean that optimizations for [[noreturn]] functions can only be done
> when the functions are called from other TU?
No, but if it is static functions called from within the same TU, then the
[[noreturn]] attribute don't help,
Hi All,
FWIW, the previous patch (gcc-15-4066-g7766a2c1eb6) broke bootstrap on
arm-linux-gnueabihf. (reported via
https://linaro.atlassian.net/browse/GNU-1364)
Christophe
On Mon, 7 Oct 2024 at 10:10, Torbjorn SVENSSON
wrote:
>
> Hello Andre,
>
> Compared to a run without any of the 2 patches fo
On Mon, 7 Oct 2024, Jakub Jelinek wrote:
> On Mon, Oct 07, 2024 at 08:59:56AM +0200, Richard Biener wrote:
> > The forwprop added optmization looks like it would match PHI-opt better,
> > but I'm fine with leaving it in forwprop. I do wonder whether instead
> > of adding a flag adding the actual
Hi!
On 2022-12-02T13:03:09+0100, I wrote:
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> -# Check to see if a target is "freestanding". This is as per the definition
> -# in Section 4 of C99 standard. Effectively, it is a target which supports no
> -
Hi!
On 2024-10-03T13:34:47+0200, Richard Biener wrote:
> On Thu, 3 Oct 2024, Thomas Schwinge wrote:
>> On 2024-09-06T11:30:06+0200, Richard Biener wrote:
>> > On Thu, 5 Sep 2024, Richard Biener wrote:
>> >> The following enables single-lane loop SLP discovery for non-grouped
>> >> stores
>> >>
On Mon, Oct 07, 2024 at 08:59:56AM +0200, Richard Biener wrote:
> The forwprop added optmization looks like it would match PHI-opt better,
> but I'm fine with leaving it in forwprop. I do wonder whether instead
> of adding a flag adding the actual values wanted as argument to
> .SPACESHIP would al
Hello Andre,
Compared to a run without any of the 2 patches for PR 116444, I get this
diff:
--- base/m55hard/analysis.gcc2024-09-18 09:07:18.879493251 +
+++ pr116444/m55hard/analysis.gcc2024-10-05 11:44:05.261683071 +
+FAIL: gcc.target/arm/attr_thumb.c scan-assembler it
Ok for trunk?
--
Update test cases to use -mcpu=unset/-march=unset feature introduced in
r15-3606-g7d6c6a0d15c.
gcc/testsuite/ChangeLog
* gcc.target/arm/pr65647.c: Use ET arm_arch_v6m.
* gcc.target/arm/mod_2.c: Use ET arm_cpu_cortex_a57.
* gcc.target/arm/mod_256.c: Likew
> The linker bug blocking this patch has actually already been fixed, see
> https://github.com/bminor/binutils-gdb/commit/72cd2c70977943054ff784b7278cef
> 5262288f32 for the patch that fixed it (Thanks for the help Jan!).
Sorry, I somehow missed it. :-( Then a configure check should be added in t
1 - 100 of 105 matches
Mail list logo
