On 4/15/24 8:43 AM, Jakub Jelinek wrote:
Hi!
cppcheck apparently warns on the | !!sticky part of the expression and
using | (!!sticky) quiets it up (it is correct as is).
The following patch adds the ()s, and also adds them around mant >> 1 just
in case it makes it clearer to all readers
Hi!
cppcheck apparently warns on the | !!sticky part of the expression and
using | (!!sticky) quiets it up (it is correct as is).
The following patch adds the ()s, and also adds them around mant >> 1 just
in case it makes it clearer to all readers that the expression is parsed
that way already.
On Mon, 15 Apr 2024 at 14:01, Andreas Schwab wrote:
>
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
OK for trunk and gcc-13, thanks.
> ---
> .../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4
> 1 file changed, 4 insertions(+)
>
> diff --git
Richard Biener wrote:
I do wonder whether hot-patching the ELF header from the libgomp plugin
with the actual micro-subarch would be possible to make the driver happy.
For completeness, there is also the possibility to play with an
environment variable as in HSA_OVERRIDE_GFX_VERSION=9.0.0 or
When clicking on the GCC..1x links at
https://gcc.gnu.org/projects/gomp/#omp5.0 , I noticed that the GCC 13
and 14 links did not link to the OpenMP changes.
It turned out that in GCC 12 and before (see commit message for
details), the OpenMP and OpenACC changes are under "New Languages and
Applied the following patch..
Johann
--
AVR: Add 8 more avrxmega3 MCUs.
gcc/
* config/avr/avr-mcus.def: Add: avr16du14, avr16du20,
avr16du28,
avr16du32, avr32du14, avr32du20, avr32du28, avr32du32.
* doc/avr-mmcu.texi: Rebuild.
diff --git
Hello,
On 4/15/24 2:44 PM, Thomas Schwinge wrote:
On top of that, OK to push the attached
"build: Use of cargo not yet supported here in Canadian cross configurations"?
This additional patch looks good. I wonder whether we should enable
canadian cross in the future with cargo or simply wait
On Mon, Apr 15, 2024 at 5:42 AM Jakub Jelinek wrote:
>
> 2024-04-15 Jakub Jelinek
>
> * Makefile.am (install-exec-local, uninstall-local): Add goals
> on the else branch of if NATIVE to ensure reproducibility.
> * Makefile.in: Regenerate.
This is OK. Go ahead and
On Mon, Apr 15, 2024 at 6:14 AM Alex Coplan wrote:
>
> On 04/04/2024 11:00, Alex Coplan wrote:
> > Hi,
> >
> > This adds a note to the GCC 14 release notes mentioning support for
> > __has_{feature,extension} (PR60512).
> >
> > OK to commit?
>
> Ping. Is this changes.html patch OK? I guess it
On Linux/x86_64,
85002f8085c25bb3e74ab013581a74e7c7ae006b is the first bad commit
commit 85002f8085c25bb3e74ab013581a74e7c7ae006b
Author: Tamar Christina
Date: Mon Apr 15 12:06:21 2024 +0100
middle-end: adjust loop upper bounds when peeling for gaps and early break
[PR114403].
caused
On Mon, Apr 15, 2024 at 04:20:16PM -0400, Eric Gallager wrote:
> > I'm not familiar with automake/m4 enough to debug that, so I'm
> > instead offering a workaround, with this patch the order is deterministic.
>
> Is there a bug open with automake upstream for this?
No, feel free to file it.
The warnings:
contrib/testsuite-management/validate_failures.py:65: SyntaxWarning: invalid
escape sequence '\s'
_VALID_TEST_RESULTS_REX = re.compile('(%s):\s*(\S+)\s*(.*)'
contrib/testsuite-management/validate_failures.py:77: SyntaxWarning: invalid
escape sequence '\.'
_EXP_LINE_REX =
Pushed to trunk now.
On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++20 and later it seems OK for trunk now.
>
> -- >8 --
>
> I'm only treating this as a DR for C++20 for now, because it's less work
> and only requires changes to
Pushed to trunk now.
On Mon, 8 Apr 2024 at 17:53, Jonathan Wakely wrote:
>
> Patch v2.
>
> I realised that it's not only negative delim values that cause the
> problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
> will cause traits_type::find to match 'a' but then the
Pushed to trunk now.
On Wed, 10 Apr 2024 at 09:53, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++26 it seems OK for trunk now.
>
> -- >8 --
>
> This C++26 change was just approved in Tokyo, in P2944R3. It adds
> operator== and operator<=> overloads to
On Thu, 11 Apr 2024 at 15:51, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When we are already touching this topic, here is a patch like r13-5126
> > which documents the upcoming release symbol versions in the documentation.
> >
> > Ok for
This just adds a clause to make it more obvious that the vector_size
attribute extension works with typedefs.
Note this whole section needs a rewrite to be a similar format as other
extensions. But that is for another day.
OK?
gcc/ChangeLog:
PR c/92880
* doc/extend.texi (Using
On 4/15/24 7:27 PM, Fei Gao wrote:
On 2024-04-15 21:04 Jeff Law wrote:
On 4/15/24 6:58 AM, Kito Cheng wrote:
It's simple enough, so LGTM for trunk :)
We're already doing this internally. I just hadn't submitted it due to
being deep into stage4.
Jeff
Hi Jeff
Would you like me to
A number of tests that call strndup fail on vxworks, where there's no
strndup. Some of them already had workarounds to skip the strndup
parts of the tests on platforms that don't offer it. I've changed
them to rely on a strndup effective target instead, and extended the
logic to other tests
pr103798-2.c fails in C++ on targets that provide a ISO C++-compliant
declaration of memchr, because it mismatches the C-compatible builtin,
as per PR113706. Expect the C++ test to fail on vxworks as well.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and
A few x86 tests get unexpected insn counts if the toolchain is
configured with --enable-frame-pointer. Add explicit
-fomit-frame-pointer so that the expected insn sequences are output.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok
Hi all,
The testcase seems to fail vectorization on -m32 since the access pattern is
determined as too complex. This skips the vectorization check on ilp32 systems
as I couldn't find a better proxy for being able to do strided 64-bit loads and
I suspect it would fail on all 32-bit targets.
Pushed to r14-9984.
在 2024/4/9 下午4:19, Lulu Cheng 写道:
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.
*
Define macro that prevents mode_t from being defined by vxworks'
headers as well.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/analyzer/fd-4.c: Define macro to avoid
On Mar 11, 2024, Richard Biener wrote:
> On Sat, Mar 9, 2024 at 10:10 AM Alexandre Oliva wrote:
>>
>>
>> The earlier patch for PR112938 arranged for volatile parms to be made
>> indirect in internal strub wrapped bodies.
>>
>> The first problem that remained, more evident, was that the
On 2024-04-15 21:04 Jeff Law wrote:
>
>
>
>On 4/15/24 6:58 AM, Kito Cheng wrote:
>> It's simple enough, so LGTM for trunk :)
>We're already doing this internally. I just hadn't submitted it due to
>being deep into stage4.
>
>Jeff
Hi Jeff
Would you like me to commit it now or leave it to you
Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
adjusted about a year ago to skip long double on some targets, because
the fastfloat library was limited to 64-bit doubles.
The same problem comes up in similar float128_t tests on
aarch64-vxworks. This patch adjusts them
Fix another test that uses -fPIC without requiring fpic support.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
PS: This is neither the first nor the last such patch. Maybe the test
harness could detect -fPIC et al in
arm pac and bti tests that use -march=armv8.1-m.main get an implicit
-mthumb, that is incompatible with vxworks kernel mode. Declaring the
requirement for a 8.1-m.main-compatible toolchain is enough to avoid
those fails, because the toolchain feature test fails in kernel mode.
Regstrapped on
docs: document early break support and pragma novector
---
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
b4c602a523717c1d64333e44aefb60ba0ed02e7a..aceecb86f17443cfae637e90987427b98c42f6eb
100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@
Committed. Thanks Kito and Jeff for the reveiw.
BR
Fei
>
>
>On 4/15/24 7:27 PM, Fei Gao wrote:
>> On 2024-04-15 21:04 Jeff Law wrote:
>>>
>>>
>>>
>>> On 4/15/24 6:58 AM, Kito Cheng wrote:
It's simple enough, so LGTM for trunk :)
>>> We're already doing this internally. I just hadn't
On Mon, Apr 15, 2024 at 8:43 AM Jakub Jelinek wrote:
>
> Hi!
>
> The regen bot recently flagged a difference in gotools/Makefile.in.
> Trying it locally, it seems pretty random
> for i in `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH
> automake; echo -n `git diff Makefile.in
Mark tests that fail due to the lack of fork, as in vxworks kernel
mode, as requiring fork.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/analyzer/pipe-glibc.c: Require
O_ACCMODE is not defined on vxworks, and the test is meaningless and
failing without it, so skip it.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
*
The mangling of the macro name that guards limits.h from reinclusion
was mangling a c23-required macro as well. Make the edit pattern
stricter.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/ChangeLog
Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
declared.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
Test that calls select fails on vxworks because select is only
declared in sys/select.h. Include that header if it's present.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
*
A number of libstdc++ tests that implicitly instantiate
__to_chars_i and also link floating_to_chars.o in
fail on vxworks kernel mode. The platform doesn't support undefweak
symbols (the kernel module loader fails to load modules containing
them), and because creating such modules doesn't
On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
padding bits in the tests are not what we might expect from full-word
struct copies.
I tried adding a function to perform bitwise copying, but even taking
the as.load() argument by const&, we'd still construct a temporary
with
Complete r13-2205, adjusting an arm-specific test that expects a
no-longer-issued error at an empty initializer.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
*
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
Co-authored-by: Olivier Hainque
for gcc/testsuite/ChangeLog
* gcc.target/aarch64/pr94201.c: Add missing
dg-require-effective-target fpic.
*
VxWorks fails to load kernel-mode modules with weak undefined symbols.
In RTP mode modules, that undergo final linking, weak undefined
symbols are not a problem.
This patch adds kernel-mode VxWorks multilibs to the set of targets
that don't support weak undefined symbols without special flags,
The test expected the address of a literal string, converted to long
long, to yield a positive value. That expectation doesn't necessarily
hold, and the test fails where it doesn't.
Adjust the test to use a pointer that will compare as expected.
Regstrapped on x86_64-linux-gnu. Also tested
On Mar 29, 2024, Alexandre Oliva wrote:
> On Mar 22, 2024, Jeff Law wrote:
>> On 3/9/24 2:11 AM, Alexandre Oliva wrote:
>>> ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
>>> don't reach that state and ICE if e.g. ipa-strub passes report errors.
>>> Skip this pass if
On Apr 16, 2024, Alexandre Oliva wrote:
> I'm going to put it in momentarily. It had been approved for gcc 14,
> before it branched off; should I install it there as well?
Ermh, nevermind, I'm not sure how I got the idea that we'd already
branched, but I was absolutely sure that this was the
On Sun, 14 Apr 2024, Martin Uecker wrote:
>
> I had to revert the old patch because it broke LTO which lead
> to PR114574. We now set TYPE_STRUCTURAL_EQUALITY and properly
> update TYPE_CANONICAL for such types and also for pointers
> to such types via a new function c_update_type_canonical
>
On Mon, Apr 15, 2024 at 08:55:56AM +0200, Richard Biener wrote:
> > diff --git a/gcc/ipa-free-lang-data.cc b/gcc/ipa-free-lang-data.cc
> > index 16ed55e2e5a..6f75444e513 100644
> > --- a/gcc/ipa-free-lang-data.cc
> > +++ b/gcc/ipa-free-lang-data.cc
> > @@ -255,7 +255,9 @@ fld_incomplete_type_of
On Mon, 15 Apr 2024, Richard Biener wrote:
> On Sun, 14 Apr 2024, H.J. Lu wrote:
>
> > We can't profile indirect calls to IFUNC resolvers nor their callees as
> > it requires TLS which hasn't been set up yet when the dynamic linker is
> > resolving IFUNC symbols.
> >
> > Add an IFUNC resolver
On 15/04/2024 10:53, Rainer Orth wrote:
Hi Jørgen,
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt:
On 15/04/2024 11:03, Tobias Burnus wrote:
I experimented with some variants to make clearer that each of RDNA2 and
RNDA3 applies to two card types, but at the end I settled on the
fewest-word version.
Comments, remarks, suggestions? (To this change or in general?)
Current version:
On 04/04/2024 11:00, Alex Coplan wrote:
> Hi,
>
> This adds a note to the GCC 14 release notes mentioning support for
> __has_{feature,extension} (PR60512).
>
> OK to commit?
Ping. Is this changes.html patch OK? I guess it needs a review from C++
maintainers since it adds to the C++ section.
On Mon, Apr 15, 2024 at 10:05:58AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > > struct S;
> > > typedef struct S **V[10];
> > > V **foo (int x) { return 0; }
> > > struct S
I experimented with some variants to make clearer that each of RDNA2 and
RNDA3 applies to two card types, but at the end I settled on the
fewest-word version.
Comments, remarks, suggestions? (To this change or in general?)
Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn
Hi!
The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions
assumes that all decls must have types.
I think it is better in something as unimportant as diag_attr_exclusions
to be more robust, if there is no type, it can just diagnose exclusions
on the DECL_ATTRIBUTES, like for
On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > struct S;
> > typedef struct S **V[10];
> > V **foo (int x) { return 0; }
> > struct S { int s; };
> > either.
> > So, maybe let's drop the ipa-free-lang-data.cc
Hi Jørgen,
> On 04/04/2024 14:10, Jan Hubicka wrote:
>>> gcc/ChangeLog:
>>>
>>> * builtins.cc (expand_builtin_fork_or_exec): Check
>>> condition_coverage_flag.
>>> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
>>> * common.opt: Add new options
On 15/04/2024 10:53, Rainer Orth wrote:
Hi Jørgen,
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt:
On Mon, Apr 15, 2024 at 09:38:29AM +0200, Jakub Jelinek wrote:
> I had this spot instrumented to log the different cases (before adding the
> code to fix up also pointer types in c_update_type_canonical) and the only
> thing
> that triggered was that the 2 TYPE_CANONICALs weren't equal if
>
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 09:38:29AM +0200, Jakub Jelinek wrote:
> > I had this spot instrumented to log the different cases (before adding the
> > code to fix up also pointer types in c_update_type_canonical) and the only
> > thing
> > that triggered
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions
> assumes that all decls must have types.
> I think it is better in something as unimportant as diag_attr_exclusions
> to be more robust, if there is no type, it can just
Hi Jørgen,
> The __sigsetjmp test was added as a regression test, which an early
> iteration of the MC/DC support caused an internal compiler error,
> triggered by a code path which did not make it through to the final
> revision. Since this test really only worked on linux and does not
> serve
The new gcc.target/i386/fhardened-1.c etc. tests FAIL on Solaris/x86 and
Darwin/x86:
FAIL: gcc.target/i386/fhardened-1.c (test for excess errors)
FAIL: gcc.target/i386/fhardened-2.c (test for excess errors)
Excess errors:
cc1: warning: '-fhardened' not supported for this target
Support for
---
v2: Remove listing of options.
htdocs/gcc-14/changes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8ac08e9a..665d050a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -231,6 +231,8 @@ a
When one of the two input operands is 0, ADD and IOR are functionally
equivalent.
ADD is slightly preferred over IOR because ADD has a higher likelihood
of being implemented as a compressed instruction when compared to IOR.
C.ADD uses the CR format with any of the 32 RVI registers availble,
while
On Sun, 14 Apr 2024, H.J. Lu wrote:
> We can't profile indirect calls to IFUNC resolvers nor their callees as
> it requires TLS which hasn't been set up yet when the dynamic linker is
> resolving IFUNC symbols.
>
> Add an IFUNC resolver caller marker to cgraph_node and set it if the
> function
On Sun, Apr 14, 2024 at 02:30:27PM +0200, Martin Uecker wrote:
> 2024-04-12 Martin Uecker
> Jakub Jelinek
>
> PR lto/114574
> PR c/114361
> gcc/
> * ipa-free-lang-data.cc (fld_incomplete_type_of): Allow
> either of the types in the assert to have
Hi!
On 2024-01-16T17:43:10+, Arthur Cohen via Gcc-cvs
wrote:
> https://gcc.gnu.org/g:71180a9eed367667e7b2c3f6aea1ee1bba15e9b3
>
> commit r14-7544-g71180a9eed367667e7b2c3f6aea1ee1bba15e9b3
> Author: Pierre-Emmanuel Patry
> Date: Wed Apr 26 10:31:35 2023 +0200
>
> gccrs: libproc_macro:
Hi Jørgen,
>> the new gcc.misc-tests/gcov-22.c test loops on SPARC (both Solaris and
>> Linux). I've filed PR gcov-profile/114720 for this, but couldn't find
>> any bugzilla account of yours to Cc:
>> Rainer
>>
>
> Rainer,
>
> Could you please try this patch? I don't have a sparc nor
The following avoids missing coverage for the line of a switch statement
which happens when gimplification emits a BIND_EXPR wrapping the switch
as that prevents us from setting locations on the containing statements
via annotate_all_with_location. Instead set the location of the GIMPLE
switch
On Mon, 15 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 10:05:58AM +0200, Jakub Jelinek wrote:
> > On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > > > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > > > struct S;
> > > > typedef struct S
On 15/04/2024 13:18, Rainer Orth wrote:
Hi Jørgen,
the new gcc.misc-tests/gcov-22.c test loops on SPARC (both Solaris and
Linux). I've filed PR gcov-profile/114720 for this, but couldn't find
any bugzilla account of yours to Cc:
Rainer
Rainer,
Could you please try this patch? I
On Mon, Apr 15, 2024 at 12:04 PM Tobias Burnus wrote:
>
> I experimented with some variants to make clearer that each of RDNA2 and
> RNDA3 applies to two card types, but at the end I settled on the
> fewest-word version.
>
> Comments, remarks, suggestions? (To this change or in general?)
>
>
Hi,
On 4/15/24 1:50 PM, Thomas Schwinge wrote:
I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
'AC_CHECK_PROG'? (We always want plain 'cargo', not host-prefixed
'aarch64-linux-gnu-cargo' etc., right?) I'll look into changing this.
This is a mistake, we should use
On 15/04/2024 13:00, Richard Biener wrote:
On Mon, Apr 15, 2024 at 12:04 PM Tobias Burnus wrote:
I experimented with some variants to make clearer that each of RDNA2 and
RNDA3 applies to two card types, but at the end I settled on the
fewest-word version.
Comments, remarks, suggestions? (To
Hi!
On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
> The rust frontend requires cargo to build some of it's components,
In GCC upstream still: 's%requires%is going to require'. ;-)
> it's presence was not checked during configuration.
After confirming the desired
On Mon, Apr 15, 2024 at 01:28:00PM +0200, Richard Biener wrote:
> The following avoids missing coverage for the line of a switch statement
> which happens when gimplification emits a BIND_EXPR wrapping the switch
> as that prevents us from setting locations on the containing statements
> via
Hi!
On 2024-04-15T13:14:42+0200, I wrote:
> On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
>> The rust frontend requires cargo to build some of it's components,
>
> In GCC upstream still: 's%requires%is going to require'. ;-)
>
>> it's presence was not checked during
On Fri, Apr 12, 2024 at 03:05:26PM -0400, Jason Merrill wrote:
> > --- gcc/cp/constexpr.cc.jj 2024-02-13 10:29:57.979155641 +0100
> > +++ gcc/cp/constexpr.cc 2024-03-07 19:35:01.032412221 +0100
> > @@ -1877,13 +1877,21 @@ cxx_bind_parameters_in_call (const const
> > x = build_address
Guard the longjmp to not infinitely loop. The longjmp (jump) function is
called unconditionally to make test flow simpler, but the jump
destination would return to a point in main that would call longjmp
again. The longjmp is really there to exercise the then-branch of
setjmp, to verify coverage
Hi!
The regen bot recently flagged a difference in gotools/Makefile.in.
Trying it locally, it seems pretty random
for i in `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH
automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo; for i in `seq
20`; do
Hi,
this adds the missing VLS modes to the mask extract expanders.
I found a dump scan difficult to create reliably so I just
kept the PR's run test case.
Regtested on rv64gcv.
Regards
Robin
gcc/ChangeLog:
PR target/114668
* config/riscv/autovec.md: Add VLS.
Hi!
On 2024-04-15T13:14:42+0200, I wrote:
> On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
>> The rust frontend requires cargo to build some of it's components,
>
> In GCC upstream still: 's%requires%is going to require'. ;-)
>
>> it's presence was not checked during
lgtm
--Reply to Message--
On Mon, Apr 15, 2024 20:43 PM Robin Dapp
On Mon, Apr 15, 2024 at 2:35 PM Jørgen Kvalsvik wrote:
>
> Guard the longjmp to not infinitely loop. The longjmp (jump) function is
> called unconditionally to make test flow simpler, but the jump
> destination would return to a point in main that would call longjmp
> again. The longjmp is really
It's simple enough, so LGTM for trunk :)
Fei Gao 於 2024年4月15日 週一 14:38 寫道：
> When one of the two input operands is 0, ADD and IOR are functionally
> equivalent.
> ADD is slightly preferred over IOR because ADD has a higher likelihood
> of being implemented as a compressed instruction when
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
---
.../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4
1 file changed, 4 insertions(+)
diff --git
a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
On 4/15/24 6:58 AM, Kito Cheng wrote:
It's simple enough, so LGTM for trunk :)
We're already doing this internally. I just hadn't submitted it due to
being deep into stage4.
Jeff
87 matches
Mail list logo
