On Thu, Oct 27, 2022 at 2:59 AM H.J. Lu via Gcc-patches
wrote:
>
> In i386.md, neg patterns which set MODE_CC register like
>
> (set (reg:CCC FLAGS_REG)
> (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))
>
> can lead to errors when operand 1 is a constant value. If
On 28/10/2022 01:05, Palmer Dabbelt wrote:
On Thu, 27 Oct 2022 15:56:17 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 10/26/22 01:49, Sebastian Huber wrote:
The RV32A extension does not support 64-bit atomic operations. For
RTEMS, use
a 32-bit gcov type for RV32.
gcc/ChangeLog:
*
On Thu, 2022-10-27 at 17:44 -0700, Palmer Dabbelt wrote:
> though I don't have an opinion on whether libitm should be taking ports
> to new targets, I'd never even heard of it before.
I asked this question to myself when I reviewed LoongArch libitm port.
But I remember one maintainer of Deepin
I'm going to check in this patch.
On Wed, Oct 26, 2022 at 10:30 AM liuhongt wrote:
>
> Enable V4BFmode and V2BFmode with the same ABI as V4HFmode and
> V2HFmode. No real operation is supported for them except for movement.
> This should solve PR target/107261.
>
> Also I notice there's
On Thu, 27 Oct 2022 16:05:19 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
> On 10/27/22 06:49, Xiongchuan Tan via Gcc-patches wrote:
>> libitm/ChangeLog:
>>
>> * configure.tgt: Add riscv support.
>> * config/riscv/asm.h: New file.
>> * config/riscv/sjlj.S: New file.
>>
C2x adds support for enums with a fixed underlying type specified
("enum e : long long;" and similar). Implement this in the C front
end. The same representation is used for these types as in C++, with
two macros moved from cp-tree.h to c-common.h.
Such enums can have bool as the underlying
On Sat, Oct 22, 2022 at 6:45 AM Sören Tempel wrote:
>
> PING.
>
> soe...@soeren-tempel.net wrote:
> > From: Sören Tempel
> >
> > On glibc-based systems, off_t is a 32-bit type on 32-bit systems and a
> > 64-bit type on 64-bit systems by default. However, on systems using musl
> > libc off_t is
Unicode does not support such values because they are unrepresentable in
UTF-16.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps-format=` specifies the format for the
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 18 ++
libcpp/internal.h | 2 ++
3 files changed, 26 insertions(+)
diff --git
Hi,
This patch adds initial support for ISO C++'s [P1689R5][], a format for
describing C++ module requirements and provisions based on the source
code. This is required because compiling C++ with modules is not
embarrassingly parallel and need to be ordered to ensure that `import
some_module;`
On 10/26/22 06:10, Thomas Schwinge wrote:
Hi!
OK to push the attached patch to "Document 'distclean-stage[N]'"?
OK
jeff
On 10/27/22 06:49, Xiongchuan Tan via Gcc-patches wrote:
libitm/ChangeLog:
* configure.tgt: Add riscv support.
* config/riscv/asm.h: New file.
* config/riscv/sjlj.S: New file.
* config/riscv/target.h: New file.
---
v2: Change HW_CACHELINE_SIZE to 64 (in
On Thu, 27 Oct 2022 15:56:17 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 10/26/22 01:49, Sebastian Huber wrote:
The RV32A extension does not support 64-bit atomic operations. For RTEMS, use
a 32-bit gcov type for RV32.
gcc/ChangeLog:
* config/riscv/riscv.cc
On 10/21/22 07:52, Dimitrije Milosevic wrote:
From: Dimitrije Milošević
This patch reverts the computation of address cost complexity
to the legacy one. After f9f69dd, complexity is calculated
using the valid_mem_ref_p target hook. Architectures like
Mips only allow BASE + OFFSET addressing
On 10/25/22 14:59, Aldy Hernandez via Gcc-patches wrote:
[As Richi, and probably Jakub, have mentioned in the past...]
As mentioned earlier, we should be using HONOR_* on types rather than
flag_finite_math_only.
Will commit pending tests.
gcc/ChangeLog:
* value-range.cc
On 10/26/22 01:49, Sebastian Huber wrote:
The RV32A extension does not support 64-bit atomic operations. For RTEMS, use
a 32-bit gcov type for RV32.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_gcov_type_size): New.
(TARGET_GCOV_TYPE_SIZE): Likewise.
*
On 10/26/22 05:09, Martin Liška wrote:
PR sanitizer/107298
gcc/ChangeLog:
* doc/invoke.texi: Document sanitizers can trigger warnings.
OK
jeff
On 10/27/22 08:41, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
According to
https://github.com/gcc-mirror/gcc/commit/f95d3d5de72a1c43e8d529bad3ef59afc3214705.
Since GCC 4.8.6 doesn't support constexpr, we should change it back to
CONSTEXPR.
gcc/ChangeLog:
*
On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
[Richi/Jakub/FP experts, does this sound like the right solution, or am I
missing some subtle IPA/inlining issue?]
The problem here is that we're inlining a global range with NANs into
a function that has been tagged with
On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu wrote:
On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
christoph.muell...@vrull.eu> wrote:
From: Christoph Muellner
This patch adds support for the Zawrs ISA extension.
The patch depends on the corresponding Binutils
On 10/27/22 04:09, Thomas Schwinge wrote:
Hi!
On 2022-10-26T20:27:19-0600, Sandra Loosemore wrote:
One of my test cases examines the .s output to make sure that the clones
are emitted as local symbols and not global. I have not been able to
find the symbol linkage information in any of the
On Thu, 27 Oct 2022, Patrick Palka wrote:
> This also implements the proposed resolutions of the tentatively ready
> LWG issues 3760 and 3761.
>
> I'm not sure how/if we should implement the recommended practice of:
>
> difference_type should be the smallest signed-integer-like type that
>
On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
christoph.muell...@vrull.eu> wrote:
> From: Christoph Muellner
>
> This patch adds support for the Zawrs ISA extension.
> The patch depends on the corresponding Binutils patch
> to be usable (see [1])
>
> The specification can be found here:
>
> Am 27.10.2022 um 10:43 schrieb Martin Liška :
>
> Hi.
>
> Ready to be installed?
Ok
Richard
> Thanks,
> Martin
>
> gcc/lto/ChangeLog:
>
>* lto-dump.cc (dump_list): Remove trailing return.
>(dump_symbol): Likewise.
>(dump_body): Filter name based on mangled name.
>
> Am 27.10.2022 um 17:11 schrieb apinski--- via Gcc-patches
> :
>
> From: Andrew Pinski
>
> This is a simple patch to do some DCE after a successful
> match and simplify replacement in PHI-OPT. match and simplify
> likes to generate some extra statements which should be cleaned
> up.
>
>
From: Christoph Muellner
This patch adds support for the Zawrs ISA extension.
The patch depends on the corresponding Binutils patch
to be usable (see [1])
The specification can be found here:
https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
Note, that the Zawrs extension is not frozen
Hello-
May I please ask for a review of this patch from June? I realize it's a
10-year-old PR that doesn't seem to be bothering people much, but I still feel
like it's an unfortunate gap in C++11 support that is not hard to fix.
Original submission is here:
This also implements the proposed resolutions of the tentatively ready
LWG issues 3760 and 3761.
I'm not sure how/if we should implement the recommended practice of:
difference_type should be the smallest signed-integer-like type that
is sufficiently wide to store the product of the maximum
(Explicitly) Templated lambdas have a different signature to
implicitly templated lambdas -- '[] (T) {}' is not the
same as '[](auto) {}'. This should be reflected in the mangling. The
ABI captures this as
https://github.com/itanium-cxx-abi/cxx-abi/issues/31, and clang has
implemented such
I got this testcase:
auto f() -> std::optional;
for (char c : f().value()) { }
which has a dangling reference: std::optional::value returns
a reference to the contained value, but here it's the f() temporary.
We warn, which is great, but only with -Wsystem-headers, because
the function comes
From: Andrew Pinski
This is a simple patch to do some DCE after a successful
match and simplify replacement in PHI-OPT. match and simplify
likes to generate some extra statements which should be cleaned
up.
OK? Bootstrapped and tested on x86_64-linux with no regressions.
Thanks,
Andrew Pinski
From: Ju-Zhe Zhong
According to
https://github.com/gcc-mirror/gcc/commit/f95d3d5de72a1c43e8d529bad3ef59afc3214705.
Since GCC 4.8.6 doesn't support constexpr, we should change it back to
CONSTEXPR.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc: Change constexpr back to
> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva wrote:
>
> On Oct 25, 2022, Qing Zhao wrote:
>
>>> 'all' for leaf functions is likely wasteful. If no other functions are
>>> called, one can determine exactly which registers might carry
>>> information out and thus need zeroing, and 'used' is
In 9482a5e4eac8d696129ec2854b331e1bb5dbab42 I'd replaced uses
of CONSTEXPR with direct uses of constexpr. However, it turns
out that we still have CONSTEXPR for a reason: GCC 4.8 doesn't
implement constexpr properly, and for example rejects things like:
extern const int x;
constexpr int x =
On 24/10/2022 19:06, Richard Biener wrote:
Am 24.10.2022 um 18:51 schrieb Andrew Stubbs :
I've committed this to the OG12 branch to remove some test failures. We
probably ought to have something on mainline also, but a proper fix would be
better.
Without this. the
libitm/ChangeLog:
* configure.tgt: Add riscv support.
* config/riscv/asm.h: New file.
* config/riscv/sjlj.S: New file.
* config/riscv/target.h: New file.
---
v2: Change HW_CACHELINE_SIZE to 64 (in accordance with the RVA profiles, see
On Thu, Oct 27, 2022 at 12:55 PM liuhongt wrote:
>
> Matching constraints are used in these circumstances. More precisely,
> the two operands that match must include one input-only operand and
> one output-only operand. Moreover, the digit must be a smaller number
> than the number of the operand
I'm surprised by the hard-coded 128-byte cache line size. If we need
to hard-code a value, it should be 64 (in accordance with the RVA
profiles, see https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc),
but ideally this would be queried dynamically.
On Thu, Oct 27, 2022 at 3:51 AM
Matching constraints are used in these circumstances. More precisely,
the two operands that match must include one input-only operand and
one output-only operand. Moreover, the digit must be a smaller number
than the number of the operand that uses it in the constraint.
In pr107057, the 2
libitm/ChangeLog:
* configure.tgt: Add riscv support.
* config/riscv/asm.h: New file.
* config/riscv/sjlj.S: New file.
* config/riscv/target.h: New file.
---
libitm/config/riscv/asm.h| 52 +
libitm/config/riscv/sjlj.S | 144
On 10/25/22 08:33, Jørgen Kvalsvik wrote:
Gentle ping. I have a tuned the summary output slightly (decisions covered ->
condition outcomes covered) already.
Sorry for a small delay, I'm working on it.
One general issue I noticed is you use an invalid coding style, where you use 4
spaces
for
On 10/27/22 04:17, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, apparently my r13-2887 P1467R9 changes
regressed these tests on powerpc64le-linux with IEEE quad by default.
I believe my changes just uncovered a latent bug.
The problem is that push_namespace calls find_namespace_slot,
which
Hi!
On 2022-10-26T20:27:19-0600, Sandra Loosemore wrote:
> On 10/20/22 08:07, Jakub Jelinek wrote:
>> Thus, IMHO it is exactly the pass_omp_simd_clone pass where you want to
>> implement this auto-simdization discovery, guarded with
>> #ifdef ACCEL_COMPILER and the new option (which means it
On 10/27/22 11:09, Mayshao-oc wrote:
Hi Martin:
Thanks for your patch, I comment the questions below.
Hi.
:)
Hello.
I noticed this patch set which is kind of related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364
>>
>> Hi Martin:
>> Thanks for your patch, I comment the questions below.
>Hi.
>:)
>>
>>> Hello.
>>
>>> I noticed this patch set which is kind of related to
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364.
>>
>>> And I have a couple of questions:
>>
>>>1) I noticed you drop
Hi.
Ready to be installed?
Thanks,
Martin
gcc/lto/ChangeLog:
* lto-dump.cc (dump_list): Remove trailing return.
(dump_symbol): Likewise.
(dump_body): Filter name based on mangled name.
(dump_tool_help): Use GIMPLE wording.
(lto_main): Update wording.
---
It's the similar condition we use in lto-dump.
Pushed as obvious.
MArtin
PR lto/107418
gcc/lto/ChangeLog:
* lto-dump.cc (lto_main): Do not load LTO stream for aliases.
---
gcc/lto/lto-dump.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Hi!
As mentioned in the PR, apparently my r13-2887 P1467R9 changes
regressed these tests on powerpc64le-linux with IEEE quad by default.
I believe my changes just uncovered a latent bug.
The problem is that push_namespace calls find_namespace_slot,
which does:
tree *slot =
(...snip...)
+RUST_SELFTEST_FLAGS = -xrs $(SELFTEST_FLAGS)
I've noticed that this patch contains a typo which prevents self-tests
from running properly. This should be `-xrust`, not `-xrs`. I assume
there will be some other review comments, so that will be fixed in a v4
of the patches.
On 10/26/22 23:04, David Malcolm wrote:
%{On Wed, 2022-10-26 at 10:18 +0200, arthur.co...@embecosm.com wrote:
From: Philip Herron
Extern crates statements to tell the front-end to look for another
library.
The mechanism here is heavily inspired from gccgo, so when we compile
a
library for
Hi!
The following patch on top of
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
adds std::{,b}float16_t support for std::to_chars.
When precision is specified (or for std::bfloat16_t for hex mode even if not),
I believe we can just use the std::to_chars float (when float is
On 2022-10-26 22:26, Vladimir Makarov wrote:
On 2022-10-25 06:01, Torbjörn SVENSSON wrote:
In commit 081c96621da, the call to resize_reg_info() was moved before
the call to remove_scratches() and the latter one can increase the
number of regs and that would cause an out of bounds usage on
> Am 27.10.2022 um 09:10 schrieb Kewen.Lin :
>
> Hi,
>
> The test cases vect-bitfield-read-* requires vector shift
> target support, they need one explicit vect_shift effective
> target requirement checking. Besides, the vectype for struct
> in test cases vect-bitfield-read-{2,4} is vector
Hi,
The test cases vect-bitfield-read-* requires vector shift
target support, they need one explicit vect_shift effective
target requirement checking. Besides, the vectype for struct
in test cases vect-bitfield-read-{2,4} is vector of long long,
we need to check effective target vect_long_long
On Wed, Oct 26, 2022 at 8:59 PM H.J. Lu wrote:
>
> In i386.md, neg patterns which set MODE_CC register like
>
> (set (reg:CCC FLAGS_REG)
> (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))
>
> can lead to errors when operand 1 is a constant value. If FLAGS_REG in
>
>
56 matches
Mail list logo
