Hi,
This patch fixes loss of return statement in maxbcd of bcd-4.c. Without
return statement, it returns an invalid bcd number and make the test
noneffective. The patch also enables test to run on Power9 and Big Endian,
as all bcd instructions are supported from Power9.
Bootstrapped and
Hi,
Ping this RFC, look forward to comments for the incoming stage1...
Jeff (Jiufu Guo)
Jiufu Guo writes:
> Hi,
>
> As known there are a few PRs (meta-bug PR101926) about
> accessing aggregate param/returns which are passed through registers.
>
> We could use the current SRA pass in a
Hi,
I would like to ping this patch.
Jeff (Jiufu Guo)
Jiufu Guo writes:
> Hi,
>
> Same like PR101168, this patch is need for s390 to
> avoid peeking eof after vector keyword.
> And similar test case is also ok for s390.
>
> Is this ok for trunk?
>
> Jeff (Jiufu Guo)
>
> PR
Hi all,
The driver currently will remove "/lib" and "/usr/lib" from the library path
that gets passed to the linker because it considers them as paths that the
linker will already known to search. But this is not true for newer linkers,
mold and lld for an example don't have a default search
On Apr 15, 2024, at 8:50 PM, Alexandre Oliva wrote:
>
> 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
On Apr 15, 2024, at 8:20 PM, Alexandre Oliva wrote:
>
> 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
On Mon, Apr 8, 2024 at 9:39 AM wrote:
>
> From: Pierre-Emmanuel Patry
>
> Hello,
>
> The rust frontend requires cargo to build some of it's components,
> it's presence was not checked during configuration.
WHY did this go in right before the release of GCC 14?
I don't get why this is considered
Hi!
OK to push the attached "GCN: Enable effective-target 'vect_long_long'"?
(Or is that not what you'd expect to see for GCN? I haven't checked the
actual back end code...)
Grüße
Thomas
>From d74cc9caadfe36652503782a8da172ae1975915c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* config/locale/dragonfly/numeric_members.cc: Fix typos in
comments.
* config/locale/gnu/numeric_members.cc: Likewise.
---
libstdc++-v3/config/locale/dragonfly/numeric_members.cc | 4 ++--
On Tue, Apr 16, 2024 at 04:00:59PM +0200, Richard Biener wrote:
> Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
> (but -fsanitize=undefined does nothing). That's not consistent
> with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
> with -ftrapv. Both are
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the
On Tue, Apr 16, 2024 at 07:12:23AM +, Tamar Christina wrote:
> Regtested on x86_64-pc-linux-gnu with -m32,-m64 and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/114403
> * gcc.dg/vect/vect-early-break_124-pr114403.c: Fix
The following fixes a DFS walk issue when identifying to be ignored
latch edges. We have (bogus) SLP_TREE_REPRESENTATIVEs for VEC_PERM
nodes so those have to be explicitly ignored as possibly being PHIs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR
The neg induction vectorization code isn't prepared to deal with
single element vectors.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR tree-optimization/114733
* tree-vect-loop.cc (vectorizable_nonlinear_induction): Reject
neg induction
Hi Harald,
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
FX
On 2024/4/12 3:14 PM, Thomas Schwinge wrote:
>> I have re-tested the patch *without* the gomp_increment/decrement_refcount
>> changes,
>> and have these regressions (just to demonstrate what is affected):
>> +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nested-1.c
>>
On Mon, Apr 15, 2024 at 10:30:15PM +0200, Jakub Jelinek wrote:
> 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
On 16/04/2024 04:50, Alexandre Oliva wrote:
>
> 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?
>
>
Morning Thomas,
On 4/15/24 13:07, Thomas Schwinge wrote:
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
On 16/04/2024 04:08, Alexandre Oliva wrote:
> 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
>
On 16/04/2024 04:48, Alexandre Oliva wrote:
>
> 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
Hi Thomas,
On 4/15/24 14:44, Thomas Schwinge wrote:
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'.
On Tue, 16 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> While studying the TYPE_CANONICAL/TYPE_STRUCTURAL_EQUALITY_P stuff,
> I've noticed some nits in comments, the following patch fixes them.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK (IMO obvious).
Richard.
>
Hi!
While studying the TYPE_CANONICAL/TYPE_STRUCTURAL_EQUALITY_P stuff,
I've noticed some nits in comments, the following patch fixes them.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-16 Jakub Jelinek
* tree.cc (array_type_nelts): Ensure 2 spaces
Hi!
https://eel.is/c++draft/bit.cast#3 says that std::bit_cast isn't constexpr
if To, From and the types of all subobjects have certain properties which the
check_bit_cast_type checks (such as it isn't a pointer, reference, union,
member pointer, volatile). The function doesn't cp_walk_tree
On Mon, Apr 15, 2024 at 01:33:18PM +0200, Richard Biener wrote:
> > But looking at all the build_variant_type_copy callers and the call itself,
> > the call itself sets TYPE_CANONICAL to the TYPE_CANONICAL of the type on
> > which it is called and the only caller I can find that changes
> >
On Tue, Apr 16, 2024 at 5:43 AM Alexandre Oliva wrote:
>
>
> 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?
OK.
> PS: This is neither the first nor
On Tue, Apr 16, 2024 at 5:31 AM Alexandre Oliva wrote:
>
>
> 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
On Tue, Apr 16, 2024 at 5:29 AM Alexandre Oliva wrote:
>
>
> 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
> On Tue, Apr 16, 2024 at 09:00:53AM +0200, Richard Biener wrote:
> > > PR tree-optimization/114403
> > > * gcc.dg/vect/vect-early-break_124-pr114403.c: Skip in ilp32.
> > >
> > > ---
> > > diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
>
On Tue, Apr 16, 2024 at 5:27 AM Alexandre Oliva wrote:
>
>
> 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?
>
OK
> for
On Tue, Apr 16, 2024 at 5:25 AM Alexandre Oliva wrote:
>
>
> 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?
OK
>
> for
On Tue, Apr 16, 2024 at 5:26 AM Alexandre Oliva wrote:
>
>
> 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?
OK
>
On Tue, Apr 16, 2024 at 5:23 AM Alexandre Oliva wrote:
>
>
> 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
On Tue, Apr 16, 2024 at 2:26 AM Andrew Pinski wrote:
>
> 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?
OK
On Tue, Apr 16, 2024 at 09:00:53AM +0200, Richard Biener wrote:
> > PR tree-optimization/114403
> > * gcc.dg/vect/vect-early-break_124-pr114403.c: Skip in ilp32.
> >
> > ---
> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
> >
On Tue, 16 Apr 2024, Tamar Christina wrote:
> 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
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
> ---
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
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, 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
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
>
42 matches
Mail list logo
