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 TYPE_STRUCTU
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 (tr
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
> TYPE_S
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 was
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 typ
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 p
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 d
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 -fcondition-coverage
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 a
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: A
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 -fha
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: A
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
Compil
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: https://gcc
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 {
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!
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 semant
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 non-gl
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 dir
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 annota
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 **V[10];
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 don
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 confi
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?)
>
> Curre
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 'AC_CHECK_PROG'
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 (x)
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 t
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 is
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 PATH=~/automake-1.15
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.
gcc/testsuite/C
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 confi
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 compar
* 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
b/libstdc++-v3/config/abi/post
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!
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.
O
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 that
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
>
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
La
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 f
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 a/gcc/co
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 commi
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
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 trunk?
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 std::refer
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 operat
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 eq_int
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
FA
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 |
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 ne
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 = re.comp
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 V
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 w
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 co
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.
*
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.
* gcc.targe
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, i
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 si
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 wi
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 tha
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 mode_
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
* gcc.dg/analyzer/fd-access-mode-t
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 for
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
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
* gcc.dg
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 x86
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 involv
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 co
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 x8
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
* gcc.target/arm/bfloa
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 t
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
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 indire
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 errors
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
@@ -20
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 ca
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.
Regte
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 submi
On Tue, 16 Apr 2024, 04:17 Alexandre Oliva, wrote:
>
> 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
> th
On Tue, 16 Apr 2024, 04:19 Alexandre Oliva, wrote:
>
> 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 fl
On Tue, 16 Apr 2024 at 04:49, Alexandre Oliva wrote:
>
>
> 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.
Aha, I was wondering why this was failing on ARM!
> I tried adding a function
On Tue, 16 Apr 2024 at 04:37, Alexandre Oliva wrote:
>
>
> 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 co
On Tue, 16 Apr 2024, Tamar Christina wrote:
> docs: document early break support and pragma novector
OK.
> ---
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index
> b4c602a523717c1d64333e44aefb60ba0ed02e7a..aceecb86f17443cfae637e90987427b98c42f6eb
> 100644
> --- a/ht
87 matches
Mail list logo
