On Thu, Jun 30, 2022 at 5:00 AM Xi Ruoyao via Gcc-patches
wrote:
>
> Hi,
>
> We've made a consensus [1] that not to enable trapping for division by
> zero by default for LLVM, and we think GCC should behave similarly.
>
> The main rationales:
>
> 1. Division by zero is undefined behavior, so in th
On Thu, Jun 30, 2022 at 4:17 AM Kito Cheng wrote:
>
> Committed to trunk, thanks :)
>
> Is it OK for gcc-11 and gcc-12 branches?
Yes, if the same failure is corrected there
> On Wed, Jun 29, 2022 at 5:00 PM Richard Biener wrote:
> >
> > On Tue, 28 Jun 2022, Kito Cheng wrote:
> >
> > > That warn
On Wed, Jun 29, 2022 at 4:35 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jun 28, 2022 at 5:54 PM Tamar Christina
> > wrote:
> >>
> >> > -Original Message-
> >> > From: Richard Biener
> >> > Sent: Monday, June 27, 2022 7:10 AM
> >> > To: Tamar Christina
> >> > Cc
Thanks Martin for creating this patch.
Here is a preliminary change for the mold side:
https://github.com/rui314/mold/commit/9ad49d1c556bc963d06cca8233535183490de605
Overall the API is looking fine, though it is not clear what kind of value
is expected as a linker version. A linker version is not
On Thu, Jun 30, 2022 at 7:59 AM Haochen Jiang wrote:
>
> Hi all,
>
> This patch aims to fix the cvtps2pd insn, which should also work on
> memory operand but currently does not. After this fix, when loop == 2,
> it will eliminate movq instruction.
>
> Regtested on x86_64-pc-linux-gnu. Ok for trunk
Hi all,
This patch aims to fix the cvtps2pd insn, which should also work on
memory operand but currently does not. After this fix, when loop == 2,
it will eliminate movq instruction.
Regtested on x86_64-pc-linux-gnu. Ok for trunk?
BRs,
Haochen
gcc/ChangeLog:
PR target/43618
* c
> Am 29.06.2022 um 22:44 schrieb Joseph Myers :
>
> The LTO merging of options from different input files was broken by:
>
> commit 227a2ecf663d69972b851f51f1934d18927b62cd
> Author: Martin Liska
> Date: Fri Mar 12 11:53:47 2021 +0100
>
>lto-wrapper: Use vec data type.
>
> Previously
> Am 30.06.2022 um 03:43 schrieb Andrew MacLeod via Gcc-patches
> :
>
> The routine which tried to fold and's and or's using relations was using the
> dependency cache as a shortcut to determine if there were 2 ssa names on the
> feeding expressions, and assuming that was correct.
>
> ie
>
In libsanitizer code, the size of some GNU libc data structure (notably,
struct stat) is hard coded. These sizes may trigger a static assert
buidling against another libc.
Just make non-GNU libc targets UNSUPPORTED now. If someone really cares
about those alternative libc implementations, please
Hi,
We've made a consensus [1] that not to enable trapping for division by
zero by default for LLVM, and we think GCC should behave similarly.
The main rationales:
1. Division by zero is undefined behavior, so in theory any portable
program shall not depend on it.
2. There are already many targe
Committed to trunk, thanks :)
Is it OK for gcc-11 and gcc-12 branches?
On Wed, Jun 29, 2022 at 5:00 PM Richard Biener wrote:
>
> On Tue, 28 Jun 2022, Kito Cheng wrote:
>
> > That warning won't happen on ilp32 targets, seems like Andrew Pinski
> > already mention that[1] before.
> >
> > Verified
> -Original Message-
> From: Jiang, Haochen
> Sent: Thursday, June 30, 2022 9:51 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ubiz...@gmail.com; Liu, Hongtao
> Subject: [PATCH] i386: Add AVX512BW to AVX512F in MASK_ISA2
>
> Hi all,
>
> I just found in MASK_ISA2_UNSET part, since AVX512BW i
Hi all,
I just found in MASK_ISA2_UNSET part, since AVX512BW is based on AVX512F, we
should add OPTION_MASK_ISA2_AVX512BW_UNSET to AVX512F for maintainence
convenience and logic correctness, or we will need to add all future ISAs based
on AVX512BW in both AVX512F and AVX512BW. This will be easily
The routine which tried to fold and's and or's using relations was using
the dependency cache as a shortcut to determine if there were 2 ssa
names on the feeding expressions, and assuming that was correct.
ie
_16 = a.0_1 < -117;
_17 = a.0_1 >= -83;
_18 = _16 | _17;
the dependency cache
C++2017 and previous standard description:
The value of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are zero-filled. If E1 has an unsigned type,
the value of the result is E1×2E2, reduced modulo one more
than the maximum value representable inthe result type.
Otherwise, if E1 has a
On Tue, Jun 28, 2022 at 7:32 AM Sören Tempel wrote:
>
> Ian Lance Taylor wrote:
> > Given that pretty much every one of these musl patches has led to
> > problems on some glibc systems, it would be very nice if you could do
> > some testing with glibc. Thanks.
>
> Sorry, my bad.
>
> I just teste
This patch to the Go frontend checks repeated const expressions in new
scope, in case they refer to a newly defined name. The test case is
const8.go in https://go.dev/cl/414795. This fixes
https://go.dev/issue/53585. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainlin
Hello
The devel/omp/gcc-12 branch has been pushed to the git repo as the
development branch for new OpenMP, OpenACC and offloading functionality,
based on the GCC 12 branch.
The git doc page has been modified to point to the new branch as the
active OMP development branch, while the previous
On 6/28/22 13:01, Qing Zhao wrote:
On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
On Jun 28, 2022, at 2:22 PM, Jakub Jelinek wrote:
On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote:
Because the flag just tells whet
Hi,
Casting from vector to static array is permitted in the D, and the
front-end generates a reinterpret cast, but casting back the other way
resulted in an error.
This has been fixed to be properly handled in the code generation pass
of VectorExp, and the conversion for lvalue and rvalue handlin
Hi, Jakub and Joseph:
> On Jun 28, 2022, at 12:43 PM, Jakub Jelinek wrote:
>
> On Tue, Jun 28, 2022 at 03:59:22PM +, Qing Zhao via Gcc-patches wrote:
>>> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 03:03:12PM +, Qing Zhao wrote:
2. Then repl
The LTO merging of options from different input files was broken by:
commit 227a2ecf663d69972b851f51f1934d18927b62cd
Author: Martin Liska
Date: Fri Mar 12 11:53:47 2021 +0100
lto-wrapper: Use vec data type.
Previously, find_and_merge_options would merge options it read into
those in *opts
On Wed, Jun 29, 2022 at 08:10:10PM +0200, Tobias Burnus wrote:
> > > + if (output_requires)
> > > +{
> > > + HOST_WIDE_INT val = ((HOST_WIDE_INT) omp_requires_mask
> > > + & (OMP_REQUIRES_UNIFIED_ADDRESS
> > > + | OMP_REQUIRES_UNIFIED_SHARED_
Currently, this is a rather useless patch - even though it helps to reduce
the number of local patches I have. Due to the printed sorry, adding a
testcase with -fdump-tree-* is also not possible, yet.
For reverse offload, the plan is to call
GOMP_target_ext
inside the on the device, passing
'
Dear all,
a CLASS entity cannot have the PARAMETER attribute.
This is detected in some situations, but in others
we ICE because we never reach the existing check.
Adding a similar check when handling the declaration
improves error recovery.
The initial patch is by Steve. I adjusted and moved
it
Hi Jakub,
On 29.06.22 19:02, Jakub Jelinek wrote:
On Wed, Jun 29, 2022 at 04:33:02PM +0200, Tobias Burnus wrote:
+ if (flag_openmp
+ && lookup_attribute ("omp declare target",
+ DECL_ATTRIBUTES (current_function_decl)))
+omp_requires_mask
+ = (enum o
In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
DECL_TI_ARGS corresponds to an identity mapping of the given arguments,
and hence its safe to always elide such substitution. But this PR
demonstrates that such a substitution isn't always the identity mapping,
in particular when
On Wed, Jun 29, 2022 at 12:42:04PM -0400, Jason Merrill wrote:
> > The usual case is that people just use -fsanitize=undefined
> > and get both return and unreachable sanitization, for fall through
> > into end of functions returning non-void done through return sanitization.
> >
> > In the rare c
On Wed, Jun 29, 2022 at 04:33:02PM +0200, Tobias Burnus wrote:
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -2488,6 +2488,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
> fndef_ok,
> break;
> }
>
> + if (flag_openmp
> + && lookup_attribute ("omp
On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote:
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49
Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolvin
On 6/27/22 11:44, Jakub Jelinek wrote:
On Wed, Jun 22, 2022 at 12:04:59AM -0400, Jason Merrill wrote:
On 6/20/22 16:16, Jason Merrill wrote:
On 6/20/22 07:05, Jakub Jelinek wrote:
On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote:
Related to PR104642, the current situation where w
The macro location tables should really mention they are about
locations. So rename them. Also, add a missing free of the remapping
table, and remove some now-unneeded macro checking.
nathan
--
Nathan SidwellFrom b0f25e1fdc6199725e69023a3dc49021f311ba66 Mon Sep 17 00:00:00 2001
From: Nathan S
Hi,
The variables being used to get the result out of TYPE_VECTOR_SUBPARTS
were being flagged by -Werror=maybe-uninitialized. As they have already
been checked for being constant earlier, use `to_constant' instead.
This patch is based on feedback from Andreas. Given the error they got,
this see
In C++03, -Wc++11-compat should warn about
int constexpr;
since 'constexpr' is a keyword in C++11. Jonathan reports that
we don't emit a similar warning for 'alignas' or 'alignof', and,
as I found out, 'thread_local'.
Similarly, we don't warn for most C++20 keywords. That happens
because RID
Excerpts from Andreas Schwab's message of Juni 29, 2022 12:09 pm:
> make[3]: Entering directory '/opt/gcc/gcc-20220629/Build/gcc'
> /opt/gcc/gcc-20220629/Build/./prev-gcc/xg++
> -B/opt/gcc/gcc-20220629/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/
> -nostdinc++
On Nios II, PIC function calls use R_NIOS2_CALL* relocations, which
may refer to a GOT entry that initially points to a PLT entry to
resolve the function on first call and that is then changed by the
dynamic linker to point directly to the function to be called so
subsequent calls do not go through
On 28.06.22 22:36, Harald Anlauf via Gcc-patches wrote:
the simplification of EXTENDS_TYPE_OF() did not handle the
situation that one of its arguments were a CLASS variable
that was improperly declared. NULL pointer dereference.
The fix is obvious. Steve found a similar solution, which
is why
On 29.06.22 14:15, Jakub Jelinek via Fortran wrote:
My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.
Ok for trunk?
LGTM. Thanks!
Tobias
2022-06-29 Jakub Jelinek
* mk-kinds-h.sh: Change __float128 to _F
On 29.06.22 14:13, Jakub Jelinek via Fortran wrote:
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported a
Richard Biener writes:
> On Tue, Jun 28, 2022 at 5:54 PM Tamar Christina
> wrote:
>>
>> > -Original Message-
>> > From: Richard Biener
>> > Sent: Monday, June 27, 2022 7:10 AM
>> > To: Tamar Christina
>> > Cc: Richard Sandiford ; Richard Earnshaw
>> > ; nd ; gcc-
>> > patc...@gcc.gnu.o
Hi Jakub, hi all,
new version attached. It now checks during lto1 whether the values are
consistent – and fails with a hard error.
The actually used value (by libgomp) is stored as a scalar weak symbol –
while for checking, each translation unit stores the integer value for
lto (alongside the of
On Wed, 2022-06-29 at 09:44 -0400, Antoni Boucher wrote:
> It fails with the following error:
>
> gcc/gcc/testsuite/jit.dg/test-asm.cc: In function 'void
> verify_code_2(gcc_jit_context*, gcc_jit_result*)':
> gcc/gcc/testsuite/jit.dg/test-asm.cc:160:11: error: ISO C++ forbids
> declaration of 'uin
It fails with the following error:
gcc/gcc/testsuite/jit.dg/test-asm.cc: In function 'void
verify_code_2(gcc_jit_context*, gcc_jit_result*)':
gcc/gcc/testsuite/jit.dg/test-asm.cc:160:11: error: ISO C++ forbids
declaration of 'uint32_t' with no type [-fpermissive]
gcc/gcc/testsuite/jit.dg/test-asm.
Pushed as it's only cherry-pick that fixes the following
rpmlint issue:
libtsan2.s390x: E: executable-stack (Badness: 1) /usr/lib64/libtsan.so.2.0.0
I'm going to take it also to gcc-12 branch.
Cheers,
Martin
791e0d1bc85d: [compiler-rt] Add NO_EXEC_STACK_DIRECTIVE on s390x
---
libsanitizer
Hi,
This removes a significant number of intrinsic definitions from the arm_neon.h
header file, and reduces the amount of code duplication. The new macros and
data structures are intended to also facilitate moving other intrinsic
definitions out of the header file in future.
There is a a slight c
On 29/06/2022 11:45, Jakub Jelinek wrote:
And omp_init_allocator needs to decide what to do if one asks for features
that need memkind as well as for features that need whatever you/Abid have
been working on. A possible resolution is punt (return omp_null_allocator),
or prefer one feature over t
Hi!
My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.
Ok for trunk?
2022-06-29 Jakub Jelinek
* mk-kinds-h.sh: Change __float128 to _Float128 in a comment.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): A
Hi!
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which i
Split report_conflicting_sanitizer_options(..., SANITIZE_ADDRESS |
SANITIZE_HWADDRESS)
call into 2 calls as we don't have any option that would be
address+hwaddress (that conflicts as well).
PR sanitizer/106132
gcc/ChangeLog:
* opts.cc (finish_options): Use 2 calls to
r
On 6/21/22 14:08, Richard Biener via Gcc-patches wrote:
On Tue, Jun 21, 2022 at 12:05 PM Xionghu Luo wrote:
On 2022/6/21 15:33, Richard Biener via Gcc-patches wrote:
On Tue, Jun 21, 2022 at 5:06 AM xionghuluo(罗雄虎) via Gcc-patches
wrote:
Bootstrap and regression tested pass on x86_64-lin
On Tue, Jun 28, 2022 at 10:29:53PM +0100, Andrew Stubbs wrote:
> On 09/06/2022 09:19, Jakub Jelinek via Gcc-patches wrote:
> > + switch (memspace)
> > +{
> > +case omp_high_bw_mem_space:
> > +#ifdef LIBGOMP_USE_MEMKIND
> > + struct gomp_memkind_data *memkind_data;
> > + memkind_d
make[3]: Entering directory '/opt/gcc/gcc-20220629/Build/gcc'
/opt/gcc/gcc-20220629/Build/./prev-gcc/xg++
-B/opt/gcc/gcc-20220629/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/
-nostdinc++
-B/opt/gcc/gcc-20220629/Build/prev-aarch64-suse-linux/libstdc++-v3/src/.libs
-B/opt/gcc/gc
On Tue, Jun 28, 2022 at 5:19 PM Pekka Seppänen wrote:
>
> Move -pthread from configure.ac to Makefile.in so that it is passed to
> AM_LDFLAGS.
OK
> lto-plugin/ChangeLog:
>
> * configure.ac: Move -pthread from here...
> * Makefile.am: ...to here.
> * configure: Regenerate.
On Tue, Jun 28, 2022 at 5:54 PM Tamar Christina wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, June 27, 2022 7:10 AM
> > To: Tamar Christina
> > Cc: Richard Sandiford ; Richard Earnshaw
> > ; nd ; gcc-
> > patc...@gcc.gnu.org; Marcus Shawcroft
> > Subject: Re
Currently global ranges are stored in SSA_NAME_RANGE_INFO as a pair of
wide_int-like objects along with the nonzero bits. We frequently lose
precision when streaming out our higher resolution iranges. The plan
was always to store the full irange between passes. However, as was
originally discuss
The following fixes a mistake in looking up an extended operand
in the CSE of a truncated operation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-06-28 Richard Biener
PR tree-optimization/106112
* tree-ssa-sccvn.cc (valueized_wider_op): Properly extend
On Tue, 28 Jun 2022, Kito Cheng wrote:
> That warning won't happen on ilp32 targets, seems like Andrew Pinski
> already mention that[1] before.
>
> Verified on riscv32-unknown-elf and riscv64-unknown-elf.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879#c1
OK
> gcc/testsuite/ChangeLo
Thanks so much.
Aldy
On Wed, Jun 29, 2022 at 10:09 AM Martin Liška wrote:
>
> Pushed as obvious.
>
> Martin
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Remove removed evrp-mode.
> ---
> gcc/doc/invoke.texi | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/gcc/doc/invoke.texi b/
Pushed as obvious.
Martin
gcc/ChangeLog:
* doc/invoke.texi: Remove removed evrp-mode.
---
gcc/doc/invoke.texi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bde59ff0472..757775ea576 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/in
"Andre Vieira (lists)" writes:
> On 17/06/2022 11:54, Richard Sandiford wrote:
>> "Andre Vieira (lists)" writes:
>>> Hi,
>>>
>>> This patch adds support for the ACLE Data Intrinsics to the AArch64 port.
>>>
>>> Bootstrapped and regression tested on aarch64-none-linux.
>>>
>>> OK for trunk?
>> Sor
60 matches
Mail list logo
