ChangeLog:
* MAINTAINERS: Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 617133447f0..e89833fb83e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -373,6 +373,7 @@ Gabriel Charette
Chandra Chavva
On 2/19/24 21:21, Alexandre Oliva wrote:
This backport is the second of two required for the pr111935 testcase,
already backported to gcc-13, to pass on riscv64-elf and riscv32-elf.
The V_VLS mode iterator, used in the original patch, is not available in
gcc-13, and I thought that would be
On 2/19/24 21:15, Alexandre Oliva wrote:
This backport is the first of two required for the pr111935 testcase,
already backported to gcc-13, to pass on riscv64-elf and riscv32-elf.
The V_VLS mode iterator, used in the original patch, is not available in
gcc-13, and I thought that would be too
On 2/20/24 07:21, Alexandre Oliva wrote:
On Feb 20, 2024, Jeff Law wrote:
On 2/19/24 21:26, Alexandre Oliva wrote:
This backport for gcc-13 is required for pr90838.c to get the expected
count of andi instructions on riscv64-elf
.
In general, shouldn't backports be focused on correctness
v1 -> v2:
- Rebased to master.
- Specifies "(void)" for the empty parameter list of loongarch_global_init.
v2 -> v3:
- Keep the original option-processing behavior (-march=la664 enables
-mrecip=all)
and fix the ICE when -mfrecipe is not passed with -mrecip.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark -m[no-]recip as
aliases to -mrecip={all,none}.
* config/loongarch/loongarch.opt: Same.
* config/loongarch/loongarch-def.h: Modify ABI condition macros for
convenience.
*
I guess Palmer is too busy, so committed to trunk :P
On Tue, Feb 13, 2024 at 11:55 PM Jeff Law wrote:
>
>
>
> On 2/9/24 09:53, Palmer Dabbelt wrote:
> > This builds for me, and I frequently have python-is-python3 type
> > packages installed so I think I've been implicitly testing it for a
> >
LGTM, and committed :)
On Tue, Feb 20, 2024 at 11:46 PM Palmer Dabbelt wrote:
>
> This came up recently as Edwin was looking through the test suite. A
> few of us were talking about this during the patchwork meeting and were
> surprised. Looks like this is the desired behavior, so let's at
在 2024/2/23 上午11:27, Xi Ruoyao 写道:
On Fri, 2024-02-23 at 11:16 +0800, chenglulu wrote:
在 2024/2/22 下午5:17, Xi Ruoyao 写道:
The gold linker has never been ported to LoongArch (and it seems
unlikely to be ported in the future as the new architectures are
focusing on lld and/or mold for fast
On Fri, 2024-02-23 at 11:16 +0800, chenglulu wrote:
>
> 在 2024/2/22 下午5:17, Xi Ruoyao 写道:
> > The gold linker has never been ported to LoongArch (and it seems
> > unlikely to be ported in the future as the new architectures are
> > focusing on lld and/or mold for fast linkers).
> >
> >
Pushed to r14-9142.
在 2024/2/21 上午11:30, Lulu Cheng 写道:
In binutils 2.40 and earlier versions, only a warning will be reported
when a relocation immediate value is out of bounds. As a result,
the value of the macro HAVE_AS_COND_BRANCH_RELAXATION will also be
defined as 1 when the assembler does
在 2024/2/22 下午5:17, Xi Ruoyao 写道:
The gold linker has never been ported to LoongArch (and it seems
unlikely to be ported in the future as the new architectures are
focusing on lld and/or mold for fast linkers).
ChangeLog:
* configure.ac (ENABLE_GOLD): Remove loongarch*-*-* from
Sorry, I missed review the testcase:
+/* { dg-final { scan-assembler-times "vmv\.v\.i\tv\[0-9\],0" 0 } } */
I think you should use "scan-assembler-not"
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-23 04:02
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai
CC: rdapp.gcc;
On Thu, Feb 22, 2024 at 6:39 PM Hongtao Liu wrote:
>
> On Thu, Feb 22, 2024 at 10:33 PM H.J. Lu wrote:
> >
> > On Sun, Feb 18, 2024 at 8:02 AM H.J. Lu wrote:
> > >
> > > If assembler and linker supports
> > >
> > > add %reg1, name@gottpoff(%rip), %reg2
> > >
> > > with R_X86_64_CODE_6_GOTTPOFF,
lgtm.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-23 04:02
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai
CC: rdapp.gcc; jeffreyalaw
Subject: [PATCH] RISC-V: Fix vec_init for simple sequences [PR114028].
Hi,
for a vec_init (_a, _a, _a, _a) with _a of mode DImode we try to
On Thu, Feb 22, 2024 at 10:33 PM H.J. Lu wrote:
>
> On Sun, Feb 18, 2024 at 8:02 AM H.J. Lu wrote:
> >
> > If assembler and linker supports
> >
> > add %reg1, name@gottpoff(%rip), %reg2
> >
> > with R_X86_64_CODE_6_GOTTPOFF, we can generate it instead of
> >
> > mov name@gottpoff(%rip), %reg2
>
On Thu, Feb 22, 2024 at 04:06:51PM -0800, Andrew Pinski wrote:
> On Thu, Feb 22, 2024, 15:56 Marek Polacek wrote:
>
> > Tested x86_64-pc-linux-gnu, applying to trunk.
>
>
> I backported/pushed the change to 13 branch already so please apply it
> there too.
Ah right. Done.
Marek
On Thu, Feb 22, 2024, 15:56 Marek Polacek wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
I backported/pushed the change to 13 branch already so please apply it
there too.
Thanks,
Andrew
> -- >8 --
> This fixes
> error: 'operator new' takes type 'size_t' ('unsigned int') as first
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
This fixes
error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter
[-fpermissive]
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wmismatched-new-delete-8.C: Use __SIZE_TYPE__.
---
On Linux/x86_64,
1076ffda6ce5e6d5fc9577deaf8233e549e5787a is the first bad commit
commit 1076ffda6ce5e6d5fc9577deaf8233e549e5787a
Author: Andrew Pinski
Date: Wed Feb 21 20:12:21 2024 -0800
warn-access: Fix handling of unnamed types [PR109804]
caused
FAIL:
Hi Mark,
Thanks for testing the patch series!
It is great to know that EFI also works well.
Thank you for your contribution to this work!
Regards,
Evgeny
-Original Message-
Thursday, February 22, 2024 7:11 PM
Mark Harmstone wrote:
Hi all,
Seems to work for me! Nice work.
It also
Hi Maxim,
Thank you for the review and the test build!
Regards,
Evgeny
-Original Message-
Wednesday, February 21, 2024 7:27 PM
Maxim Kuvyrkov wrote:
Hi Evgeny,
Great job!
For reference, here is a test build of this patch series using Linaro Toolchain
CI:
Thanks for the review.
Here's the updated patch. See answers to question below.
On Fri, 2024-01-05 at 14:39 -0500, David Malcolm wrote:
> On Fri, 2024-01-05 at 12:09 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds support for setting the comment ident (analogous to
> > #ident "comment"
On 2/22/24 22:01, Steve Kargl wrote:
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
On the positive side, it not only seems to fix the cases in question,
but also substring references etc., like the following:
If the above passes a regression test, then by all means we should
On Thu, Feb 22, 2024 at 07:49:20PM +, Richard Sandiford wrote:
> Thanks for the update. This is still quite hard to review though.
> Sorry to ask for another round, but could you split it up further?
> The ideal thing would be if patches that move code do nothing other
> than move code, and
This looks like an oversight of handling DEMANGLE_COMPONENT_UNNAMED_TYPE.
DEMANGLE_COMPONENT_UNNAMED_TYPE only has the u.s_number.number set while
the code expected newc.u.s_binary.left would be valid.
So this treats DEMANGLE_COMPONENT_UNNAMED_TYPE like we treat function paramaters
On Thu, Feb 22, 2024 at 12:59:18PM -0800, Greg McGary wrote:
> The sign bit of a sign-extending load cannot be known until runtime,
> so don't attempt to simplify it in the combiner.
>
> 2024-02-22 Greg McGary
>
> PR rtl-optimization/113010
> * combine.cc
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
> Hi Steve!
>
> On 2/22/24 01:52, Steve Kargl wrote:
> > On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> > > On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > > > On 2/21/24 22:00, Steve Kargl wrote:
>
The sign bit of a sign-extending load cannot be known until runtime,
so don't attempt to simplify it in the combiner.
2024-02-22 Greg McGary
PR rtl-optimization/113010
* combine.cc (simplify_comparison): Don't simplify high part
of paradoxical-SUBREG-of-MEM on machines
Thanks for the review and idea.
Here's the updated patch. I added a test, but I could not set -fsigned-
char as this is not an option accepted by the jit frontend.
However, the test still works in the sense that it fails without this
patch and passes with it.
I'm just wondering if it would pass
Hi Gaius,
> On 22 Feb 2024, at 18:06, Gaius Mulley wrote:
>
> Iain Sandoe writes:
>
>> Right now, AFAIK the only target runtimes used by host tools are
>> libstdc++, libgcc and libgnat. I agree that might change with rust -
>> since the rust folks are talking about using one of the runtimes
Hi Matthias,
> libsanitizer fails to build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64,
> triggering an #error in /usr/include/features-time64.h
>
> --- a/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp
> @@ -11,6
Hi Steve!
On 2/22/24 01:52, Steve Kargl wrote:
On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
On 2/21/24 22:00, Steve Kargl wrote:
memleak vs ICE. I think I'll take one over the other.
Probably need to free
Hi,
for a vec_init (_a, _a, _a, _a) with _a of mode DImode we try to
construct a "superword" of two "_a"s. This only works for modes < Pmode
when we can "shift and or" two halves into one Pmode register.
This patch disallows the optimization for inner_mode == Pmode and emits
a simple broadcast
Ajit Agarwal writes:
> Hello Alex/Richard:
>
> I have placed target indpendent and target dependent code in
> aarch64-ldp-fusion for load store fusion.
>
> Common infrastructure of load store pair fusion is divided into
> target independent and target dependent code.
>
> Target independent code
libsanitizer fails to build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64,
triggering an #error in /usr/include/features-time64.h
--- a/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp
@@ -11,6 +11,7 @@
// Before
On Wed, 21 Feb 2024 16:02:50 PST (-0800), Kito Cheng wrote:
Palmer Dabbelt 於 2024年2月22日 週四 07:42 寫道：
On Wed, 21 Feb 2024 15:34:32 PST (-0800), Kito Cheng wrote:
> LGTM for the patch
>
> Li, Pan2 於 2024年2月21日 週三 12:31 寫道：
>
>> Hi kito and juzhe.
>>
>> There may be 2 items for double-confirm.
On Thu, Feb 22, 2024 at 08:34:45AM +, Jason Merrill wrote:
> On 2/20/24 19:15, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This PR asks that our -Wuninitialized for mem-initializers does
> > not warn when binding a reference to an
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable manually before
returning to the parent READ.
I did not address the case of a formatted
[Public]
Hi,
PFA, The patch that enables support for the next generation AMD Zen5
CPU via -march=znver5 with basic znver5 scheduler Model.
znver5 scheduler model is combined with existing znver4 scheduler model
into a single file "zn4zn5.md".
automata size tested using
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> But sure, if you prefer the COLON_SCOPE version of the patch, I can commit
> that. There is no PREV_WHITE in the preprocessor, there is
Yes, I prefer the COLON_SCOPE version.
--
Joseph S. Myers
josmy...@redhat.com
> On 22 Feb 2024, at 17:45, Andrew Pinski wrote:
>
> On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
> wrote:
>>
>> On 21/02/2024 18:30, Evgeny Karpov wrote:
>>>
>> +/* X18 reserved for the TEB on Windows. */
>> +#ifdef TARGET_ARM64_MS_ABI
>> +# define FIXED_X18 1
>> +# define
Hi all,
Seems to work for me! Nice work.
It also works nicely with EFI as well, for anyone interested:
test.c:
#include
EFI_STATUS efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE* SystemTable) {
SystemTable->ConOut->OutputString(SystemTable->ConOut, L"hello, world\r\n");
return
On Thu, Feb 22, 2024 at 05:49:12PM +, Joseph Myers wrote:
> This patch (the one using COLON_SCOPE, *not* the one using PREV_WHITE) is
> OK.
>
> PREV_WHITE is about whether there is whitespace between the tokens in the
> macro expansion, for the purposes of stringization - I don't think it's
Iain Sandoe writes:
> Right now, AFAIK the only target runtimes used by host tools are
> libstdc++, libgcc and libgnat. I agree that might change with rust -
> since the rust folks are talking about using one of the runtimes in
> the FE, I am not aware of other language FEs requiring their
On Thu, 22 Feb 2024, Richard Earnshaw (lists) wrote:
> On 21/02/2024 21:34, rep.dot@gmail.com wrote:
> > On 21 February 2024 19:34:43 CET, Evgeny Karpov
> > wrote:
> >>
> >
> > Please use git send-email. Your mail ends up as empty as here, otherwise.
>
> I don't see anything wrong with
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
> and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes
> or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
> there are
On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
wrote:
>
> On 21/02/2024 18:30, Evgeny Karpov wrote:
> >
> +/* X18 reserved for the TEB on Windows. */
> +#ifdef TARGET_ARM64_MS_ABI
> +# define FIXED_X18 1
> +# define CALL_USED_X18 0
> +#else
> +# define FIXED_X18 0
> +# define
Thanks for the review.
Here's the updated patch.
On Wed, 2024-01-24 at 12:18 -0500, David Malcolm wrote:
> On Thu, 2023-12-21 at 08:33 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch allows comparing aligned integer types as equal.
> > There's a TODO in the code about whether we should check
This patch adds support for MVE Tail-Predicated Low Overhead Loops by using the
doloop funcitonality added to support predicated vectorized hardware loops.
gcc/ChangeLog:
* config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change
declaration to pass basic_block.
This patch adds an attribute to the mve md patterns to be able to identify
predicable MVE instructions and what their predicated and unpredicated variants
are. This attribute is used to encode the icode of the unpredicated variant of
an instruction in its predicated variant.
This will make it
This patch fixes the erroneous use of a mode attribute without a mode iterator
in the pattern and removes unused unspecs and iterators.
gcc/ChangeLog:
* config/arm/iterators.md (supf): Remove VMLALDAVXQ_U, VMLALDAVXQ_P_U,
VMLALDAVAXQ_U cases.
(VMLALDAVXQ): Remove
This patch annotates some MVE across lane instructions with a new attribute.
We use this attribute to let the compiler know that these instructions can be
safely implicitly predicated when tail predicating if their operands are
guaranteed to have zeroed tail predicated lanes. These instructions
This patch adds support in the target agnostic doloop pass for the detection of
predicated vectorized hardware loops. Arm is currently the only target that
will make use of this feature.
gcc/ChangeLog:
* df-core.cc (df_bb_regno_only_def_find): New helper function.
* df.h
Hi,
This is a reworked patch series from. The main differences are a further split
of patches, where:
[1/5] is arm specific and has been approved before,
[2/5] is target agnostic, has had no substantial changes from v3.
[3/5] new arm specific patch that is split from the original last patch and
This looks like an oversight of handling DEMANGLE_COMPONENT_UNNAMED_TYPE.
DEMANGLE_COMPONENT_UNNAMED_TYPE only has the u.s_number.number set while
the code expected newc.u.s_binary.left would be valid.
So this treats DEMANGLE_COMPONENT_UNNAMED_TYPE like we treat function paramaters
Hi Richard,
> It looks like this is really doing two things at once: disabling the
> direct emission of LDP/STP Qs, and switching the GPR handling from using
> pairs of DImode moves to single TImode moves. At least, that seems to be
> the effect of...
No it still uses TImode for the
As part of an effort to learn how create a GENERIC tree in order to
implement a
COBOL front end, I created the dump_generic_nodes(), which accepts a
function_decl at the point it is provided to the middle end. The routine
generates three files. One is ASCII, the second is HTML; they contain the
On Thu, Feb 22, 2024 at 04:35:22PM +0100, Michael Matz wrote:
> On Thu, 22 Feb 2024, Jakub Jelinek wrote:
>
> > > Hmm, shouldn't you be able to use (nonexistence of) the PREV_WHITE flag
> > > on
> > > the second COLON token to see that it's indeed a '::' without intervening
> > > whitespace?
A ChangeLog template using "Moved... ...here" has been generated by
contrib/mklog.py.
It seems that it needs modification.
Regards,
Evgeny
-Original Message-
Thursday, February 22, 2024 12:11 PM
Richard Earnshaw (lists) wrote:
> The ChangeLog has to be expressed in present tense, as
Hello Andrew,
Thank you for the review!
Renaming functions and comments that reference functions with the
i386_ prefix can trigger extensive changes. This task should
ideally be handled in a separate follow-up patch.
The primary goal of the renaming changes in
Hi,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> > Hmm, shouldn't you be able to use (nonexistence of) the PREV_WHITE flag on
> > the second COLON token to see that it's indeed a '::' without intervening
> > whitespace? Instead of setting a new flag on the first COLON token?
> >
> > I.e.
On Thu, Feb 22, 2024 at 03:59:31PM +0100, Michael Matz wrote:
> Hello,
>
> On Thu, 22 Feb 2024, Jakub Jelinek wrote:
>
> > So, the following patch adds a flag during preprocessing at the point
> > where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> > on the first CPP_COLON to
Hi Richard,
Thanks for the review!
TARGET_ARM64_MS_ABI refers to the official Microsoft ARM64 ABI naming used for
the target.
If AARCH64 is a more preferred name, it will be changed in PATCH v2.
https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170
Regards,
Hello,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> So, the following patch adds a flag during preprocessing at the point
> where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> on the first CPP_COLON to mark the consecutive case (as we are tight
> on the bits, I've reused the
On Thu, Feb 22, 2024 at 3:56 AM Richard Biener
wrote:
>
> On Tue, Feb 20, 2024 at 3:33 PM Lewis Hyatt wrote:
> >
> > On Mon, Feb 19, 2024 at 11:36 PM Alexandre Oliva wrote:
> > >
> > > This backport for gcc-13 is the first of two required for the
> > > g++.dg/pch/line-map-3.C test to stop
The following adds another omission to the assert verifying we're
not running into spurious off == -1.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114048
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): MEM_REF
can also produce -1
On Sun, Feb 18, 2024 at 8:02 AM H.J. Lu wrote:
>
> If assembler and linker supports
>
> add %reg1, name@gottpoff(%rip), %reg2
>
> with R_X86_64_CODE_6_GOTTPOFF, we can generate it instead of
>
> mov name@gottpoff(%rip), %reg2
> add %reg1, %reg2
>
> gcc/
>
> * configure.ac
On 22/02/2024 14:26, Jan Hubicka wrote:
Hello,
This patch adds support in gcc+gcov for modified condition/decision
coverage (MC/DC) with the -fcondition-coverage flag. MC/DC is a type of
test/code coverage and it is particularly important for safety-critical
applicaitons in industries like
On 21/02/2024 17:47, Evgeny Karpov wrote:
> Hello,
>
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch
On 21/02/2024 18:40, Evgeny Karpov wrote:
>
+aarch64-*-mingw*)
This doesn't match the glob pattern you added to config.gcc in an earlier
patch, but see my comment on that. The two should really be consistent with
each other or you might get build failures late on.
R.
On 21/02/2024 18:38, Evgeny Karpov wrote:
>
For this change you might want to put some form of re-direct in the manual
under the old name so that anybody used to looking for the old entry will know
where things have been moved to. Something like
x86 Windows Options
See xref(Cygwin and MinGW
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary conditions to slightly different locus.
>
> The test for >64
Hello,
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fcondition-coverage flag. MC/DC is a type of
> test/code coverage and it is particularly important for safety-critical
> applicaitons in industries like aviation and automotive. Notably, MC/DC
On 21/02/2024 18:36, Evgeny Karpov wrote:
>
+/* GNU as supports weak symbols on PECOFF. */
+#ifdef HAVE_GAS_WEAK
Can't we assume this is true? It was most likely needed on i386 because
support goes back longer than the assembler had this feature, but it looks like
it was added in 2000, or
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+ tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
I missed this on first reading...
The GCC port name uses AARCH64, please use that internally rather than other
names. The only time when we should be using ARM64 is when it's needed for
> Hi!
>
> The profile_count::dump (char *, struct function * = NULL) const;
> method has a single caller, the
> profile_count::dump (FILE *f, struct function *fun) const;
> method and for that going through a temporary buffer is just slower
> and opens doors for buffer overflows, which is exactly
When we classify a conditional reduction chain as CONST_COND_REDUCTION
we fail to verify all involved conditionals have the same constant.
That's a quite unlikely situation so the following simply disables
such classification when there's more than one reduction statement.
Bootstrapped and tested
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+/* X18 reserved for the TEB on Windows. */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18 0
+# define CALL_USED_X18 1
+#endif
I'm not overly keen on ifdefs like this (and the one below), it can
On 21/02/2024 18:26, Evgeny Karpov wrote:
>
+/* Available call ABIs. */
+enum calling_abi
+{
+ AARCH64_EABI = 0,
+ MS_ABI = 1
+};
+
The convention in this file seems to be that all enum types to start with
aarch64. Also, the enumeration values should start with the name of the
enumeration
On 21/02/2024 18:16, Evgeny Karpov wrote:
>
+aarch64*-*-mingw*)
Other targets are a bit inconsistent here as well, but, as Andrew mentioned, if
you don't want to handle big-endian, it might be better to match
aarch64-*-mingw* here.
R.
On 21/02/2024 21:34, rep.dot@gmail.com wrote:
> On 21 February 2024 19:34:43 CET, Evgeny Karpov
> wrote:
>>
>
> Please use git send-email. Your mail ends up as empty as here, otherwise.
I don't see anything wrong with it; niether does patchwork
在 2024/2/22 下午6:20, Xi Ruoyao 写道:
To improve Binutils compatibility we've had to backported relaxation
support. But if a user just updates to GCC 13.3 and sticks with
Binutils 2.41, there is no reason to use -mno-explicit-relocs as the
default because we are turning off relaxation for
To improve Binutils compatibility we've had to backported relaxation
support. But if a user just updates to GCC 13.3 and sticks with
Binutils 2.41, there is no reason to use -mno-explicit-relocs as the
default because we are turning off relaxation for Binutils 2.41 (it
lacks conditional branch
On Thu, Feb 22, 2024 at 10:07 AM Jakub Jelinek wrote:
>
> Hi!
>
> The profile_count::dump (char *, struct function * = NULL) const;
> method has a single caller, the
> profile_count::dump (FILE *f, struct function *fun) const;
> method and for that going through a temporary buffer is just slower
The gold linker has never been ported to LoongArch (and it seems
unlikely to be ported in the future as the new architectures are
focusing on lld and/or mold for fast linkers).
ChangeLog:
* configure.ac (ENABLE_GOLD): Remove loongarch*-*-* from target
list.
* configure:
On Wed, 21 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because can_test_argument_range
> returns true for BUILT_IN_{COSH,SINH,EXP{,M1,2}}{F32X,F64X}
> among many other builtins, but get_no_error_domain doesn't handle
> those.
>
> float32x_type_node when supported in
Hi!
The profile_count::dump (char *, struct function * = NULL) const;
method has a single caller, the
profile_count::dump (FILE *f, struct function *fun) const;
method and for that going through a temporary buffer is just slower
and opens doors for buffer overflows, which is exactly why this P1
On Tue, Feb 20, 2024 at 3:33 PM Lewis Hyatt wrote:
>
> On Mon, Feb 19, 2024 at 11:36 PM Alexandre Oliva wrote:
> >
> > This backport for gcc-13 is the first of two required for the
> > g++.dg/pch/line-map-3.C test to stop hitting a variant of the known
> > problem mentioned in that testcase: on
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:19, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport b7e4a4c626eeeb32c291d5bbbaa148c5081b6bfd to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL:
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> Currently, bitint_large_huge::lower_mul_overflow uses cnt 1 only if
> startlimb == endlimb and in that case doesn't use a loop and handles
> everything in a special if:
> unsigned cnt;
> bool use_loop = false;
> if (startlimb
Ping!
Kind regards,
Torbjörn
On 2024-02-07 17:21, Torbjorn SVENSSON wrote:
Hi,
Is it okay to backport 3cbab07b08d2f3a3ed34b6ec12e67727c59d285c to
releases/gcc-13?
Without this backport, I see these failures on arm-none-eabi:
FAIL: gcc.dg/analyzer/switch-enum-1.c (test for bogus messages,
Hi!
Currently, bitint_large_huge::lower_mul_overflow uses cnt 1 only if
startlimb == endlimb and in that case doesn't use a loop and handles
everything in a special if:
unsigned cnt;
bool use_loop = false;
if (startlimb == endlimb)
cnt = 1;
else if (startlimb + 1
On 2/20/24 19:15, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR asks that our -Wuninitialized for mem-initializers does
not warn when binding a reference to an uninitialized data member.
We already check !INDIRECT_TYPE_P in
Hi!
We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes
or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
there are is just a pair of CPP_COLON tokens.
The c-lex.cc hunk
95 matches
Mail list logo
