Hi Edwin
> I believe the only problematic failures are the 5 vls calling convention
> ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.
Does this "only 24" comes from calling-convention-1.c?
> This is what I'm getting locally (first instance of wrong match):
> v32qi_RET1_ARG8:
>
Jerry,
The patch looks good to me, but please give Harald a chance
to comment.
--
steve
On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float
On 2/1/2024 8:28 PM, Li, Pan2 wrote:
Hi Edwin,
Just rerun the newlib and there is no ICE but still 160 dump failures as below.
Pan
Hi Pan,
Thanks for confirming! Having dump failures is expected. There are
around 7 more unique failures than I expected
On Fri, Feb 02, 2024 at 11:43:21PM +, Jonathan Yong wrote:
> On 2/1/24 15:33, Jonathan Yong wrote:
> > On 2/1/24 15:25, Jakub Jelinek wrote:
> > > On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
> > > > No, besides the formatting being incorrect both in ChangeLog and in the
> >
Attached patch OK? Fixes the following warnings:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function
‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’
[-Wbuiltin-declaration-mismatch]
17 | memcpy(void* __restrict __dest, const void*
On 2/1/24 15:33, Jonathan Yong wrote:
On 2/1/24 15:25, Jakub Jelinek wrote:
On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
No, besides the formatting being incorrect both in ChangeLog and in the
patch, this pessimizes ILP32 hosts unnecessarily.
So like this instead?
This libgo patch generates better error messages then the Go GOARCH
and GOOS values can't be determined from the target. This indicates
that the target is not supported. This is for GCC PR 113530.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
This patch to the Go frontend exports the type "any" as a builtin.
Otherwise we can't tell the difference between builtin type "any" and
a locally defined type "any".
This will require updates to the gccgo export data parsers in the main
Go repo and the x/tools repo. These updates are
On 2/1/24 10:24 PM, Jeff Law wrote:
On 2/1/24 18:24, Greg McGary wrote:
However, for a machine where (WORD_REGISTER_OPERATIONS &&
load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM
is only known at runtime as 0s or 1s. That's the downstream bug. The
fix for such machines
Changes in v5:
1. Add pr113689-3.c.
2. Use %r10 if ix86_profile_before_prologue () return true.
3. Try a callee-saved register which has been saved on stack in the
prologue.
Changes in v4:
1. Remove pr113689-3.c.
2. Use df_get_live_out.
Changes in v3:
1. Remove r10_ok.
Changes in v2:
1. Add
The testcase gcc.target/aarch64/vect_ctz_1.c fails execution when running
with -march=armv9-a due to the testcase calls __builtin_ctz with a value of 0.
The testcase should not depend on undefined behavior of __builtin_ctz. So this
changes it to use the g form with the 2nd argument of 32. Now the
On 2/2/24 15:57, Patrick Palka wrote:
On Fri, 2 Feb 2024, Patrick Palka wrote:
On Fri, 2 Feb 2024, Jason Merrill wrote:
On 2/2/24 14:41, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
In r11-3261-gb28b621ac67bee we made
On Fri, 2 Feb 2024, Patrick Palka wrote:
> On Fri, 2 Feb 2024, Jason Merrill wrote:
>
> > On 2/2/24 14:41, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > In r11-3261-gb28b621ac67bee we made
On Fri, 2 Feb 2024, Jason Merrill wrote:
> On 2/2/24 14:41, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk?
> >
> > -- >8 --
> >
> > In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
> > substitute into a
On 2/2/24 14:41, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order
On 2/2/24 14:41, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
OK.
-- >8 --
In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement? This is not a bugfix and barely related to the previous
patch, but the previous patch's new use of entering_scope=true motivated
me to submit this patch since it seems like a nice simplification.
-- >8 --
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.
On Fri, Feb 02, 2024 at 05:10:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 07:42:00AM -0800, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -22749,6 +22749,39 @@ current_fentry_section (const char **name)
> >return true;
> > }
> >
> >
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.
PR c++/110084
gcc/cp/ChangeLog:
* pt.cc (tsubst_function_decl): Only check a function defaulted
I've confirmed that these changes fix the error in MIRI, too. I'll post
an updated patch once I confirm that there aren't any regressions.
On Fri, Feb 2, 2024 at 10:38 AM Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 04:32:09PM +0100, Jakub Jelinek wrote:
> > Anyway, I think all of
> >
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.
This is the first step in fixing PR target/59778. libatomic/fenv.c
needs fixing for hppa so exceptions are correctly raised.
Committed to trunk.
Dave
---
hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
This change implements
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
On Wed, 31 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> On Sat, Jan 27, 2024 at 08:53:42AM +0100, Jakub Jelinek wrote:
> > The following testcase ends up with SIGFPE in __divmodbitint4.
> > The problem is a thinko in my attempt to implement Knuth's algorithm.
>
> Here is an updated version of the
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
Thank you for your careful review!
> But we don't need a new one if it's going to be used in exactly one test and
> if the new option does the same thing for all targets that run the test.
Got it, thanks. Now add option "-latomic" directly, but it still rely
on the trick "[atomic_link_flags
On Fri, Feb 02, 2024 at 05:32:31PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote:
> > > With -pedantic-errors we would have __has_extension behaving like
> > > __has_feature, and I wanted to check in the test that this doesn't get
> > > reported as a
On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote:
> > With -pedantic-errors we would have __has_extension behaving like
> > __has_feature, and I wanted to check in the test that this doesn't get
> > reported as a feature or extension.
>
> Oh I see. A comment to that effect might be
On Fri, Feb 02, 2024 at 03:45:48PM +, Alex Coplan wrote:
> On 02/02/2024 09:34, Marek Polacek wrote:
> > On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote:
> > > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> > >
> > > Thanks,
> > > Alex
> > >
> > > -- >8 --
> > >
On Fri, Feb 02, 2024 at 07:42:00AM -0800, H.J. Lu wrote:
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -22749,6 +22749,39 @@ current_fentry_section (const char **name)
>return true;
> }
>
> +/* Return an caller-saved register, which isn't live, at entry for
> +
Currently sed command in flag cleanup removes all the -O[0-9] flags, ignoring
the context. This leads to issues when the optimization flags is passed to
linker:
CFLAGS="-Os -Wl,-O1 -Wl,--hash-style=gnu"
is converted into
CFLAGS="-Os -Wl,-Wl,--hash-style=gnu"
Which leads to configure failure with
tested on i686, x86_64 Darwin, x86_64, aarch64 linux, pushed to trunk,
thanks,
Iain
--- 8< ---
Darwin's linker defaults to error on undefined (which makes it look as
if we do not support shared, leading to tests being marked incorrectly
as unsupported).
This fixes the issue by allowing the
On 02/02/2024 09:34, Marek Polacek wrote:
> On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote:
> > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> >
> > Thanks,
> > Alex
> >
> > -- >8 --
> >
> > When __has_feature was introduced for GCC 14, I included the feature
> >
On Fri, Feb 2, 2024 at 4:22 AM Jakub Jelinek wrote:
>
> On Thu, Feb 01, 2024 at 03:02:47PM -0800, H.J. Lu wrote:
> > @@ -2763,6 +2789,8 @@ construct_container (machine_mode mode, machine_mode
> > orig_mode,
> >{
> >case X86_64_INTEGER_CLASS:
> >case
Changes in v4:
1. Remove pr113689-2.c.
2. Use df_get_live_out.
Changes in v3:
1. Remove r10_ok.
Changes in v2:
1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
On Fri, Feb 02, 2024 at 04:32:09PM +0100, Jakub Jelinek wrote:
> Anyway, I think all of
> decBasic.c: for (; UBTOUI(umsd)==0 && umsd+3 decBasic.c: for (; *umsd==0 && umsd decBasic.c: for (; UBTOUI(hi->msd)==0 && hi->msd+3lsd;) hi->msd+=4;
> decBasic.c: for (; *hi->msd==0 && hi->msdlsd;)
On Fri, Feb 02, 2024 at 10:09:05AM -0500, Ian McCormack wrote:
> This patch fixes a minor instance of undefined behavior in libdecnumber. It
> was discovered in the Rust bindings for libdecnumber (`dec`) using a custom
> version of MIRI that can execute foreign functions.
>
> Within the
c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++:
FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c -std=gnu++20 scan-assembler-not memchr
FAIL:
On Thu, Jan 25, 2024 at 05:45:00PM +, Andre Vieira wrote:
>
> This patch ensures we use TARGET_ARRAY_MODE to determine the storage mode of
> large bitints that are represented as arrays in memory. This is required to
> support such bitints for aarch64 and potential other targets with similar
This patch fixes a minor instance of undefined behavior in libdecnumber. It was
discovered in the Rust bindings for libdecnumber (`dec`) using a custom version
of MIRI that can execute foreign functions.
On the last iteration of the `while` loop in `decNumberGetBCD`, the pointer
`up` will be
This patch fixes a minor instance of undefined behavior in libdecnumber. It was
discovered in the Rust bindings for libdecnumber (`dec`) using a custom version
of MIRI that can execute foreign functions.
Within the function `decFloatFMA`, the pointer `lo->msd` is initialized to
point to a byte
> Sorry, I wasn't clear about this in previous patch -- noipa will
> subsume other ipa attributes,
> so there's no need to have noinline, noclone along with noipa.
> int __attribute__((noipa)) callee(int i) should be sufficient for
> disabling IPA optimizations involving callee.
I thought you
On Fri, Feb 02, 2024 at 01:18:06PM +, Joseph Myers wrote:
> On Fri, 2 Feb 2024, Andi Kleen wrote:
>
> > This patchkit implements a [[musttail]] attribute for C/C++.
> >
> > v4:
> > Addressed all feedback except clang::musttail is still supported
> > (I don't want to force an #ifdef to most
On Thu, Jan 25, 2024 at 05:45:01PM +, Andre Vieira wrote:
> This patch adds support for C23's _BitInt for the AArch64 port when compiling
> for little endianness. Big Endianness requires further target-agnostic
> support and we therefor disable it for now.
>
> gcc/ChangeLog:
>
> *
On 1/30/24 10:04, Khem Raj wrote:
libgcc/
* config/i386/enable-execute-stack-mingw32.c: Include
stdlib.h for abort() definition.
Thanks. Pushed to the trunk.
jeff
Teted x86_64-linux. Pushed to trunk.
-- >8 --
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h
On 2/1/24 07:20, Richard Biener wrote:
The following avoids re-associating
(minus:DI (reg/f:DI 119)
(minus:DI (reg/f:DI 120)
(reg/f:DI 114)))
into
(minus:DI (plus:DI (reg/f:DI 114)
(reg/f:DI 119))
(reg/f:DI 120))
as that possibly confuses the REG_POINTER
On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote:
> Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
>
> Thanks,
> Alex
>
> -- >8 --
>
> When __has_feature was introduced for GCC 14, I included the feature
> cxx_constexpr_string_builtins, since of the relevant string
On 1/29/24 22:19, Andrew Pinski wrote:
The vect-avg-*.c testcases are trying to make sure
the AVG internal function are used and not
doing promotion to `vector unsigned short`
but when V4QI is implemented, `vector(2) unsigned short`
shows up in the detail dump file and causes the failure.
To
On 1/30/24 03:31, Iain Sandoe wrote:
tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks
Iain
--- 8< ---
We use the ubsan tests from both C, C++, D and Fortran.
the sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver, and
On 1/30/24 03:30, Iain Sandoe wrote:
tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks
Iain
--- 8< ---
We use the shared asan/hwasan from both C,C++,D and Fortran.
The sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver,
Tested x86_64-linux and powerpc-ibm-aix7.3.1.0. Pushed to trunk.
-- >8 --
This fails due to "u" being used in a system header.
FAIL: experimental/names.cc -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:77: error: expected unqualified-id before ';' token
These new headers should probably have the usual boilerplate at the top,
so make the Python scripts output it.
-- >8 --
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.
libstdc++-v3/ChangeLog:
*
On Fri, 2 Feb 2024, Andi Kleen wrote:
> This patchkit implements a [[musttail]] attribute for C/C++.
>
> v4:
> Addressed all feedback except clang::musttail is still supported
> (I don't want to force an #ifdef to most users) and I'm also still
I'm fine with supporting [[clang::musttail]].
On Tue, 9 Jan 2024 at 12:44, Jonathan Wakely wrote:
>
> I was talking to Matthias Klose about enabling libstdc++_libbacktrace.a
> for Ubuntu's gcc package and I realised that it would be preferable if
> the gcc-13 branch had those libbacktrace symbols in libstdc++exp.a. I
> already did that for
On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote:
> Hi Joseph!
>
> On Tue, 30 Jan 2024 14:54:49 + (UTC)
> Joseph Myers wrote:
>
> > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> >
> > > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > >
On 02/02/24 12:14 +, Jonathan Wakely wrote:
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased
On Thu, Feb 01, 2024 at 03:02:47PM -0800, H.J. Lu wrote:
> @@ -2763,6 +2789,8 @@ construct_container (machine_mode mode, machine_mode
> orig_mode,
>{
>case X86_64_INTEGER_CLASS:
>case X86_64_INTEGERSI_CLASS:
> + if (!in_return)
> + set_int_parameter_registers_bit
On Fri, Feb 2, 2024 at 4:07 AM wrote:
>
> On 2 February 2024 00:02:54 CET, "H.J. Lu" wrote:
> >On Thu, Feb 1, 2024 at 10:32 AM Jakub Jelinek wrote:
> >>
> >> On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
> >> > --- a/gcc/config/i386/i386.cc
> >> > +++ b/gcc/config/i386/i386.cc
> >> >
Changes in v3:
1. Remove r10_ok.
Changes in v2:
1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.
---
2
On 2 February 2024 00:02:54 CET, "H.J. Lu" wrote:
>On Thu, Feb 1, 2024 at 10:32 AM Jakub Jelinek wrote:
>>
>> On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
>> > --- a/gcc/config/i386/i386.cc
>> > +++ b/gcc/config/i386/i386.cc
>> > @@ -22749,6 +22749,31 @@ current_fentry_section (const
On 26/01/2024 15:31, Richard Ball wrote:
> v2: Formatting and test options fix.
>
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
>
> gcc/ChangeLog:
>
> * config/arm/arm.cc (arm_output_mi_thunk): Emit
> insn for bti_c when bti is enabled.
>
On Fri, 2 Feb 2024 at 14:44, Andi Kleen wrote:
>
> Mostly adopted from the existing C musttail plugin tests.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/musttail1.c: New test.
> * c-c++-common/musttail2.c: New test.
> * c-c++-common/musttail3.c: New test.
> *
Hi Joseph!
On Tue, 30 Jan 2024 14:54:49 + (UTC)
Joseph Myers wrote:
> On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
>
> > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.
>
>
Hi!
Rainer pointed out that __PFX__ and __FIXPTPFX__ prefix replacement is done
solely for libgcc-std.ver.in and not for the *.ver files in config.
I've used the __PFX__ prefix even in config/i386/libgcc-glibc.ver because it
was used for similar symbols in libgcc-std.ver.in, and that results in
On Fri, 2 Feb 2024 at 11:10, wrote:
>
> On 1 February 2024 18:15:34 CET, Christophe Lyon
> wrote:
> >BUILD_INFO is currently a byproduct of checking makeinfo
> >presence/version. INSTALL_INFO used to be defined similarly, but was
> >removed in 2000 (!) by commit
Tested x86_64-linux. Pushed to releases/gcc-12 branch.
-- >8 --
This avoids a linker error with -fkeep-inline-functions when including
. We can't backport the fix from trunk because it adds an
export to the shared library. By marking the "missing" symbol
always_inline for C++20 mode we don't
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This looks like a typo in the upstream test that causes a failure in
debug mode. It has been reported upstream.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second
Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
Thanks,
Alex
-- >8 --
When __has_feature was introduced for GCC 14, I included the feature
cxx_constexpr_string_builtins, since of the relevant string builtins
that GCC implements, it seems to support constexpr evaluation of those
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
*
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This should not be noexcept because its _M_syncbuf member has a
potentially-throwing move assignment operator. The noexcept was removed
by LWG 3867.
libstdc++-v3/ChangeLog:
* include/std/syncstream (basic_osyncstream::operator=): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
On Fri, Feb 2, 2024 at 9:59 AM Rainer Orth
wrote:
>
> gcc.target/i386/pr71321.c FAILs on 64-bit Solaris/x86 with the native
> assembler:
>
> FAIL: gcc.target/i386/pr71321.c scan-assembler-not lea.*0
>
> The problem is that /bin/as doesn't fully support cfi directives, so the
> .eh_frame section
> Am 01.02.2024 um 22:34 schrieb Tamar Christina :
>
>
>>
>>>
>>> If the above is correct then I think I understand what you're saying and
>>> will update the patch and do some Checks.
>>
>> Yes, I think that's what I wanted to say.
>>
>
> As discussed:
>
> Bootstrapped Regtested on
> Am 02.02.2024 um 10:41 schrieb Jakub Jelinek :
>
> Hi!
>
> Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
> arguments, var_to_partition will not work for those, but unlike calls
> where we just create a new uninitialized SSA_NAME here we need to change
> the inline
> Am 02.02.2024 um 10:53 schrieb Jakub Jelinek :
>
> Hi!
>
> I thought one needs to cast first to pointer-sized integer before casting to
> pointer, but apparently that is not the case.
> So the following patch arranges for the large/huge _BitInt to
> pointer/reference conversions to use the
> Am 01.02.2024 um 23:46 schrieb Jakub Jelinek :
>
> On Tue, Jan 30, 2024 at 07:33:10AM -, Roger Sayle wrote:
> + wide_int bits = wide_int::from (tree_nonzero_bits (rhs),
>
>
On 1 February 2024 18:15:34 CET, Christophe Lyon
wrote:
>BUILD_INFO is currently a byproduct of checking makeinfo
>presence/version. INSTALL_INFO used to be defined similarly, but was
>removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
>(svn r38141).
>
>In order to save
On Tue, Jan 30, 2024 at 10:09:51AM +0800, Lulu Cheng wrote:
> From: chenguoqi
>
> libsanitizer/ChangeLog:
>
> * configure.tgt: Enable tsan and lsan for loongarch64.
> * tsan/Makefile.am: Add tsan_rtl_loongarch64.S to
> EXTRA_libtsan_la_SOURCES.
This line is too long and should
We call loongarch_symbol_insns with mode = MAX_MACHINE_MODE sometimes.
But in loongarch_symbol_insns:
if (LSX_SUPPORTED_MODE_P (mode) || LASX_SUPPORTED_MODE_P (mode))
return 0;
And LSX_SUPPORTED_MODE_P is defined as:
#define LSX_SUPPORTED_MODE_P(MODE) \
(ISA_HAS_LSX \
Hi!
This is fixed by the PR113692 patch.
Will commit as obvious if that patch makes it in.
2024-02-02 Jakub Jelinek
PR tree-optimization/113691
* gcc.dg/bitint-83.c: New test.
--- gcc/testsuite/gcc.dg/bitint-83.c.jj 2024-02-01 12:32:39.555709390 +0100
+++
Hi!
I thought one needs to cast first to pointer-sized integer before casting to
pointer, but apparently that is not the case.
So the following patch arranges for the large/huge _BitInt to
pointer/reference conversions to use the same code as for conversions
of them to small integral types.
LGTM :)
On Fri, Feb 2, 2024 at 9:58 AM Juzhe-Zhong wrote:
>
> This patch fixes the following:
>
> vsetvli a5,a1,e32,m1,tu,ma
> sllia4,a5,2
> sub a1,a1,a5
> vle32.v v2,0(a0)
> add a0,a0,a4
> vadd.vv v1,v2,v1
> bne a1,zero,.L3
Hi!
Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
arguments, var_to_partition will not work for those, but unlike calls
where we just create a new uninitialized SSA_NAME here we need to change
the inline asm input to be an uninitialized VAR_DECL.
Bootstrapped/regtested
On 2/1/24 22:33, Tamar Christina wrote:
Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu no
issues.
Also checked both with --enable-lto --with-build-config='bootstrap-O3
bootstrap-lto' --enable-multilib
and --enable-lto --with-build-config=bootstrap-O3
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
PR83324
gcc/c/ChangeLog:
* c-parser.cc (struct attr_state): Define with musttail_p.
(c_parser_statement_after_labels): Handle [[musttail]]
gcc/ChangeLog:
* doc/extend.texi: Document [[musttail]]
---
gcc/doc/extend.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 142e41ab8fbf..866f6c4a9fed 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@
This patchkit implements a [[musttail]] attribute for C/C++.
v4:
Addressed all feedback except clang::musttail is still supported
(I don't want to force an #ifdef to most users) and I'm also still
using the lookup/remove_attributes (not clear if anything else
is worth it and it would certainly be
Mostly adopted from the existing C musttail plugin tests.
gcc/testsuite/ChangeLog:
* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
*
- Give error messages for all causes of non sibling call generation
- Don't override choices of other non sibling call checks with
must tail. This causes ICEs. The must tail attribute now only
overrides flag_optimize_sibling_calls locally.
- Error out when tree-tailcall failed to mark a must-tail
gcc.target/i386/sse2-stv-1.c FAILs on 32-bit Solaris/x86:
FAIL: gcc.target/i386/sse2-stv-1.c scan-assembler-not %[er]sp
FAIL: gcc.target/i386/sse2-stv-1.c scan-assembler-not shldl
The test assumes the Linux/x86 default of -mno-stackrealign, while
32-bit Solaris/x86 default to -mstackrealign.
gcc.target/i386/pr80569.c FAILs on Solaris/x86 with the native
assembler:
FAIL: gcc.target/i386/pr80569.c (test for excess errors)
Excess errors:
Assembler: pr80569.c
"/var/tmp//ccm4_iqb.s", line 2 : Illegal mnemonic
Near line: ".code16gcc"
"/var/tmp//ccm4_iqb.s",
gcc.target/i386/pr71321.c FAILs on 64-bit Solaris/x86 with the native
assembler:
FAIL: gcc.target/i386/pr71321.c scan-assembler-not lea.*0
The problem is that /bin/as doesn't fully support cfi directives, so the
.eh_frame section is specified explicitly, which includes ".long 0".
The regular
LGTM :)
On Thu, Feb 1, 2024 at 11:46 PM Juzhe-Zhong wrote:
>
> Realize in recent benchmark evaluation (coremark-pro zip-test):
>
> vid.v v2
> vmv.v.i v5,0
> .L9:
> vle16.v v3,0(a4)
> vrsub.vxv4,v2,a6 ---> LICM failed to hoist it outside the
> loop.
>
1 - 100 of 102 matches
Mail list logo
