Pushed.
Gerald
---
htdocs/gcc-4.7/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-4.7/changes.html b/htdocs/gcc-4.7/changes.html
index 846946d6..c61106e5 100644
--- a/htdocs/gcc-4.7/changes.html
+++ b/htdocs/gcc-4.7/changes.html
@@ -691,7 +691,7 @@
>But in principle @2 or @3 could safely differ in sign, you'd then need to
>ensure
>to insert sign conversions to @2/@3 to the signedness of @4/@5.
Changed.
>you are not testing for this anywhere?
It's tested in vect_recog_cond_expr_convert_pattern, I've move it to match.pd
>Btw, matching up the
On 2/9/22 08:08, Richard Sandiford wrote:
Dan Li writes:
+
+ /* When shadow call stack is enabled, the scs_pop in the epilogue will
+ restore x30, and we don't need to pop x30 again in the traditional
+ way. Pop candidates record the registers that need to be popped
+
On 2/9/22 15:15, Patrick Palka wrote:
On Wed, 9 Feb 2022, Jason Merrill wrote:
On 2/9/22 11:36, Patrick Palka wrote:
On Wed, 9 Feb 2022, Jason Merrill wrote:
On 2/9/22 10:45, Patrick Palka wrote:
In filter_memfn_lookup, we weren't correctly recognizing and matching up
member functions
On 2/9/22 16:01, Qing Zhao wrote:
On Feb 9, 2022, at 12:23 PM, Jason Merrill wrote:
On 2/9/22 10:51, Qing Zhao wrote:
On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote:
On 2/8/22 15:11, Qing Zhao wrote:
Hi,
This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
Hi!
I wrote a patch for PR 25689, but I feel like it may not be the ideal
fix. Furthermore, there are some standing issues with the patch for
which I would like tips on how to fix them.
Specifically, there are 2 issues:
1. GCC warns about if (a.operator=(0)). That said, this may not be a
major
Here's the updated patch.
Le mardi 25 janvier 2022 à 12:13 -0500, Antoni Boucher via Jit a
écrit :
> See answers below.
>
> Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit :
> > On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote:
> > > Hi.
> > >
> > > Le mardi 18 janvier 2022
From: Andrew Pinski
The problem here is that the aarch64 back-end was placing const0_rtx
into the constant vector RTL even if the mode was a floating point mode.
The fix is instead to use CONST0_RTX and pass the mode to select the
correct zero (either const_int or const_double).
Committed as
On Linux/x86_64,
1ce5395977f37e8d0c03394f7b932a584ce85cc7 is the first bad commit
commit 1ce5395977f37e8d0c03394f7b932a584ce85cc7
Author: Jason Merrill
Date: Wed Feb 9 00:31:12 2022 -0500
c++: modules and explicit(bool) [PR103752]
caused
FAIL: g++.dg/modules/xtreme-header-5_a.H
In addition to other test coverage, this adds the examples from
https://cwe.mitre.org/data/definitions/457.html
(aka "CWE-457: Use of Uninitialized Variable")
For reference, the output from -fanalyzer looks like this
(after stripping away the DejaGnu directives):
uninit-CWE-457-examples.c: In
This patch to the Go frontend stops warning for calls of print(). We
used to warn for calls to print(), because it doesn't do anything.
However, a Go 1.18 test uses that call, and it is valid Go. Change
the compiler to just accept it and compile it; this will produce calls
to printlock and
This patch to the Go frontend uses a nil pointer for a zero length
string constant. We used to pointlessly set the pointer of a zero
length string constant to point to a zero byte constant. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
This patch to the Go frontend treats notinheap types as not being
pointers. By definition, a type is marked noinheap doesn't contain
any pointers that the garbage collector cares about, and neither does
a pointer to such a type. Change the type descriptors to consistently
treat such types as not
On 2/9/22 00:12, Richard Biener wrote:
On Tue, 8 Feb 2022, Jeff Law wrote:
On 2/8/2022 12:03 AM, Richard Biener via Gcc-patches wrote:
The following improves early uninit diagnostics by computing edge
reachability using our value-numbering framework in its cheapest
mode and ignoring
In the Go 1.18 release libgo needs to link against -lrt on GNU/Linux
only, to call the timer_create, timer_settime, and timer_delete
functions. In preparation this patch changes the gccgo driver to link
against -lrt when linking libgo statiically, and the gotools Makefile
to link the runtime test
Dear all,
as we did not properly check the initialization of pointers in
DATA statements for valid initial data targets, we could either
ICE or generate wrong code. Testcase based on Gerhard's, BTW.
The attached patch adds a check in gfc_assign_data_value by
calling gfc_check_pointer_assign, as
> On Feb 9, 2022, at 12:23 PM, Jason Merrill wrote:
>
> On 2/9/22 10:51, Qing Zhao wrote:
>>> On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote:
>>>
>>> On 2/8/22 15:11, Qing Zhao wrote:
Hi,
This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
Hi!
After vec_clrl and vec_clrr were implemented and during review of the
documentation, it was agreed to change their names to vec_clr_first and
vec_clr_last to more clearly describe their bi-endian semantics. ("Left"
and "right" are the wrong terms to be using.) It looks like I neglected
to
Hello
Le 06/02/2022 à 22:14, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
some instances of valid constant array constructors did lead to ICEs.
It turned out that on the one hand we need to attempt simplification of
elements of the constructor, especially when we encounter
On Wed, 9 Feb 2022 at 17:35, Thomas Rodgers via Libstdc++
wrote:
>
> This patch changes the memory order used in the spin wait code to match
> that of libc++.
OK for trunk (and gcc-11 if needed).
Tested x86_64-pc-linux-gnu, committed to master, backported to gcc-11.
On Wed, Feb 9, 2022 at 9:14 AM Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 17:10, Thomas Rodgers wrote:
> >
> > Updated patch. I reverted the memory order change (and will submit that
> as another patch) and fixed some
On Linux/x86_64,
5390a2f191682dae3c6d1e1deac20e05be413514 is the first bad commit
commit 5390a2f191682dae3c6d1e1deac20e05be413514
Author: H.J. Lu
Date: Sun Jan 30 10:08:14 2022 -0800
x86: Check each component of source operand for AVX_U128_DIRTY
caused
FAIL:
On Wed, 9 Feb 2022, Jason Merrill wrote:
> On 2/9/22 11:36, Patrick Palka wrote:
> > On Wed, 9 Feb 2022, Jason Merrill wrote:
> >
> > > On 2/9/22 10:45, Patrick Palka wrote:
> > > > In filter_memfn_lookup, we weren't correctly recognizing and matching up
> > > > member functions introduced via a
This patch adds middle-end support for target ABIs that pass/return
floating point values in integer registers with precision wider than
the original FP mode. An example, is the nvptx backend where 16-bit
HFmode registers are passed/returned as (promoted to) SImode registers.
Unfortunately, this
On 2/7/22 13:24, Vineet Gupta wrote:
On 2/7/22 10:58, Palmer Dabbelt wrote:
On Mon, 07 Feb 2022 09:41:10 PST (-0800), Vineet Gupta wrote:
On 2/7/22 01:28, Philipp Tomsich wrote:
Vineet,
On Mon, 7 Feb 2022 at 07:06, Vineet Gupta
wrote:
This is at par with other major arches such as
Compile PR target/104441 tests with -march=x86-64 to fix test failures
when GCC is configured with --with-arch=native --with-cpu=native.
PR target/104441
* gcc.target/i386/pr104441-1a.c: Compile with -march=x86-64.
* gcc.target/i386/pr104441-1b.c: Likewise.
---
On Fri, Feb 04, 2022 at 12:39:53PM +0100, Tobias Burnus wrote:
> Already during parsing, the allocatable character array assignment
>x = (x)
>
> is converted to two gfc_codes with EXEC_ASSIGN, namely:
>
> ASSIGN z1:_F.DA0(FULL) (parens z1:x(FULL))
> ASSIGN z1:x(FULL) z1:_F.DA0(FULL)
>
>
2022-02-09 Uroš Bizjak
gcc/ChangeLog:
PR target/104462
* common/config/i386/i386-common.cc (OPTION_MASK_ISA2_XSAVE_UNSET):
Also include OPTION_MASK_ISA2_AVX2_UNSET.
gcc/testsuite/ChangeLog:
PR target/104462
* gcc.target/i386/pr104462.c: New test.
Bootstrapped and
Input operands can be in the form of:
(subreg:DI (reg:V2SF 96) 0)
which chokes lowpart_subreg. Force inputs to a register, which is
preferable even when the input operand is from memory.
2022-02-09 Uroš Bizjak
gcc/ChangeLog:
PR target/104458
* config/i386/i386-expand.cc
This isn't technically a regression, but it only impacts the v850 target
and fixes a long standing code correctness issue.
As outlined in slightly more detail in the PR, the v850 is using the
pattern name "fnmasf4" and "fnmssf4" to generate fnmaf.s and fnmsf.s
instructions respectively.
On Wed, Feb 09, 2022 at 04:56:13PM +0800, Kewen.Lin wrote:
> Hi Michael,
>
> on 2022/2/9 上午11:27, Michael Meissner via Gcc-patches wrote:
> > Reset -mpower8-fusion for power9 inlining power8 functions, PR 102059.
> >
> > This patch is an attempt to make a much simpler patch to fix PR
> >
On Wed, 9 Feb 2022, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase ICEs, because when creating PAREN_EXPR for
> __builtin_assoc_barrier the FE doesn't do the usual tweaks for
> EXCESS_PRECISION_EXPR or C_MAYBE_CONST_EXPR. I believe that the
> declared effect of the
On 2/9/22 10:51, Qing Zhao wrote:
On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote:
On 2/8/22 15:11, Qing Zhao wrote:
Hi,
This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
cp/cxx-pretty-print.c:128)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
It's possible that
On 2/9/22 11:36, Patrick Palka wrote:
On Wed, 9 Feb 2022, Jason Merrill wrote:
On 2/9/22 10:45, Patrick Palka wrote:
In filter_memfn_lookup, we weren't correctly recognizing and matching up
member functions introduced via a non-dependent using-decl. This caused
us to crash in the below
Hello,
On Fri, Jan 21 2022, Aldy Hernandez via Gcc-patches wrote:
> As discussed in PR103721, the problem here is that we are crossing a
> backedge and causing us to use relations from a previous iteration of a
> loop.
>
> This handles the testcases in both PR103721 and PR104067 which are
My earlier patch to correct the -fgo-dump-spec field name
(https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587464.html)
was incomplete. It replaced part of the name with "_", but not all of
it. This patch completes the job. Bootstrapped and ran Go and
-fgo-dump-spec testsuite on
This patch changes the memory order used in the spin wait code to match
that of libc++.
From 92caa08b272520ec4a272b302b37d8fb47afb2ab Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Wed, 9 Feb 2022 09:26:00 -0800
Subject: [PATCH] libstdc++: Strengthen memory order for atomic::wait/notify
On Wed, 9 Feb 2022 at 17:10, Thomas Rodgers wrote:
>
> Updated patch. I reverted the memory order change (and will submit that as
> another patch) and fixed some spelling and grammar errors.
OK for trunk and gcc-11, thanks.
Updated patch. I reverted the memory order change (and will submit that as
another patch) and fixed some spelling and grammar errors.
On Wed, Feb 9, 2022 at 2:43 AM Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++
> wrote:
> >
> > This issue was observed as a
This patch extends the previous support for 16-byte vec_concat
so that it supports pairs of 4-byte elements. This too isn't
strictly a regression fix, since the 8-byte forms weren't affected
by the same problems as the 16-byte forms, but it leaves things in
a more consistent state.
gcc/
This patch is the second of two to remove the old
move_lo/hi_quad expanders and move_hi_quad insns.
gcc/
* config/aarch64/aarch64-simd.md (@aarch64_split_simd_mov):
Use aarch64_combine instead of move_lo/hi_quad. Tabify.
(move_lo_quad_, aarch64_simd_move_hi_quad_):
After previous patches, we have a (mostly new) group of vec_concat
patterns as well as vestiges of the old move_lo/hi_quad patterns.
(A previous patch removed the move_lo_quad insns, but we still
have the move_hi_quad insns and both sets of expanders.)
This patch is the first of two to remove the
vec_combine is really one instruction on aarch64, provided that
the lowpart element is in the same register as the destination
vector. This patch adds patterns for that.
The patch fixes a regression from GCC 8. Before the patch:
int64x2_t s64q_1(int64_t a0, int64_t a1) {
if (__BYTE_ORDER__
move_lo_quad_internal_ and move_lo_quad_internal_be_
partially duplicate the later aarch64_combinez{,_be} patterns.
The duplication itself is a regression.
The only substantive differences between the two are:
* combinez uses vector MOV (ORR) instead of element MOV (DUP).
The former seems more
This patch generalises the load_pair_lanes guard so that
it uses aarch64_check_consecutive_mems to check for consecutive
mems. It also allows the pattern to be used for STRICT_ALIGNMENT
targets if the alignment is high enough.
The main aim is to avoid an inline test, for the sake of a later
The aarch64_simd_vec_set define_insn takes memory operands,
so this patch makes the vec_set optab expander do the same.
gcc/
* config/aarch64/aarch64-simd.md (vec_set): Allow the
element to be an aarch64_simd_nonimmediate_operand.
---
gcc/config/aarch64/aarch64-simd.md | 2 +-
1
This patch fixes some case in which *general_operand was used over
*nonimmediate_operand by patterns that don't accept immediates.
This avoids some complication with later patches.
gcc/
* config/aarch64/aarch64-simd.md (aarch64_simd_vec_set): Use
aarch64_simd_nonimmediate_operand
The main purpose of this patch series is to fix a performance
regression from GCC 8. Before the patch:
int64x2_t s64q_1(int64_t a0, int64_t a1) {
if (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__)
return (int64x2_t) { a1, a0 };
else
return (int64x2_t) { a0, a1 };
}
generated:
fmov
> On Feb 9, 2022, at 10:20 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi, Richard,
>>
>> Could you please review this patch? This is a fix to the previous
>> -fzero-call-used-regs implementation.
>>
>> PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with
On Wed, 9 Feb 2022, Jason Merrill wrote:
> On 2/9/22 10:45, Patrick Palka wrote:
> > In filter_memfn_lookup, we weren't correctly recognizing and matching up
> > member functions introduced via a non-dependent using-decl. This caused
> > us to crash in the below testcases in which we correctly
Qing Zhao writes:
> Hi, Richard,
>
> Could you please review this patch? This is a fix to the previous
> -fzero-call-used-regs implementation.
>
> PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with
> -mthumb -fzero-call-used-regs=used)
>
Dan Li writes:
> Shadow Call Stack can be used to protect the return address of a
> function at runtime, and clang already supports this feature[1].
>
> To enable SCS in user mode, in addition to compiler, other support
> is also required (as discussed in [2]). This patch only adds basic
>
Hello,
On Wed, 9 Feb 2022, Richard Biener wrote:
> > That breaks down when a birth is there (because it was otherwise
> > reachable) but not on the taken path:
> >
> > if (nevertrue)
> > goto start;
> > goto forw;
> > start:
> > {
> > int i;
> > printf("not really
> On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote:
>
> On 2/8/22 15:11, Qing Zhao wrote:
>> Hi,
>> This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
>> cp/cxx-pretty-print.c:128)
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
>> It's possible that the TYPE_NAME of a
On 2/9/22 10:45, Patrick Palka wrote:
In filter_memfn_lookup, we weren't correctly recognizing and matching up
member functions introduced via a non-dependent using-decl. This caused
us to crash in the below testcases in which we correctly pruned the
overload set for the non-dependent call
On Wed, 9 Feb 2022 at 15:45, Jakub Jelinek wrote:
>
> On Wed, Feb 09, 2022 at 03:38:32PM +, Jonathan Wakely wrote:
> > On Wed, 9 Feb 2022 at 15:24, Jakub Jelinek wrote:
> > >
> > > On Wed, Feb 09, 2022 at 09:40:49AM -0500, Jason Merrill via Gcc-patches
> > > wrote:
> > > > The C++ committee
In filter_memfn_lookup, we weren't correctly recognizing and matching up
member functions introduced via a non-dependent using-decl. This caused
us to crash in the below testcases in which we correctly pruned the
overload set for the non-dependent call ahead of time, but then at
instantiation
On Wed, Feb 09, 2022 at 03:38:32PM +, Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 15:24, Jakub Jelinek wrote:
> >
> > On Wed, Feb 09, 2022 at 09:40:49AM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > The C++ committee just updated the values of these macros to reflect some
> > >
We weren't streaming a C++20 dependent explicit-specifier.
gcc/cp/ChangeLog:
* module.cc (trees_out::core_vals): Stream explicit specifier.
(trees_in::core_vals): Likewise.
* pt.cc (store_explicit_specifier): No longer static.
(tsubst_function_decl): Clear
On Wed, 9 Feb 2022 at 15:24, Jakub Jelinek wrote:
>
> On Wed, Feb 09, 2022 at 09:40:49AM -0500, Jason Merrill via Gcc-patches wrote:
> > The C++ committee just updated the values of these macros to reflect some
> > late C++20 papers that we implement but others don't yet; see PR103891.
> >
> >
Hi!
On Tue, Feb 08, 2022 at 03:29:48PM -0600, Bill Schmidt wrote:
> Due to a pasto error in the documentation, vec_replace_unaligned was
> implemented with the same function prototypes as vec_replace_elt. It was
> intended that vec_replace_unaligned always specify output vectors as having
> type
On Wed, Feb 09, 2022 at 09:40:49AM -0500, Jason Merrill via Gcc-patches wrote:
> The C++ committee just updated the values of these macros to reflect some
> late C++20 papers that we implement but others don't yet; see PR103891.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
So, shouldn't we
Excessively enthusiastic refactoring. I expect to rewrite most of this as
part of the work I'm starting now for GCC13 stage1.
On Wed, Feb 9, 2022 at 2:43 AM Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++
> wrote:
> >
> > This issue was observed as a
On Wed, Feb 09, 2022 at 03:41:23PM +0100, Richard Biener wrote:
> On Wed, 9 Feb 2022, Jakub Jelinek wrote:
>
> > On Wed, Feb 09, 2022 at 11:19:25AM +0100, Richard Biener wrote:
> > > That does look like bogus abstraction though - I'd rather have
> > > the target be specific w/o option checks and
On Wed, 9 Feb 2022 at 14:40, Jason Merrill wrote:
>
> The C++ committee just updated the values of these macros to reflect some
> late C++20 papers that we implement but others don't yet; see PR103891.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Nice! I'll test the corresponding libstdc++
On 2/9/22 03:30, Richard Biener wrote:
On Tue, Feb 8, 2022 at 11:38 PM Jason Merrill via Gcc-patches
wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling-pointer when the argument is used
to
The following adjusts the earlier change to still allow an
uncritical replacement.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2022-02-09 Richard Biener
PR middle-end/104464
* gimple-isel.cc (gimple_expand_vec_cond_expr): Postpone
throwing
On Wed, 9 Feb 2022, Jakub Jelinek wrote:
> On Wed, Feb 09, 2022 at 11:19:25AM +0100, Richard Biener wrote:
> > That does look like bogus abstraction though - I'd rather have
> > the target be specific w/o option checks and replace
> > targetm.zero_addres_valid uses with a wrapper (like you do
The C++ committee just updated the values of these macros to reflect some
late C++20 papers that we implement but others don't yet; see PR103891.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Update values
of
On Tue, 8 Feb 2022, Michael Matz wrote:
> Hello,
>
> On Tue, 8 Feb 2022, Richard Biener wrote:
>
> > > int state = 2, *p, camefrom1 = 0;
> > > for (;;) switch (state) {
> > > case 1:
> > > case 2: ;
> > > int i;
> > > if (state != 1) { p = i = 0; }
> > > if (state == 1) {
On Wed, Feb 09, 2022 at 11:19:25AM +0100, Richard Biener wrote:
> That does look like bogus abstraction though - I'd rather have
> the target be specific w/o option checks and replace
> targetm.zero_addres_valid uses with a wrapper (like you do for
> flag_delete_null_pointer_checks), if we think
On 2/9/22 03:45, Richard Biener wrote:
On Tue, Feb 8, 2022 at 9:58 PM Andrew MacLeod wrote:
On 2/8/22 03:32, Richard Biener wrote:
On Tue, Feb 8, 2022 at 2:33 AM Andrew MacLeod via Gcc-patches
wrote:
On 2/7/22 09:29, Andrew MacLeod wrote:
I have a proposal for PR 104288.
ALL patches (in
Hey,
On Tue, 8 Feb 2022, Joseph Myers wrote:
> On Tue, 8 Feb 2022, Richard Biener via Gcc-patches wrote:
>
> > which I think is OK? That is, when the abstract machine
> > arrives at 'int i;' then the previous content in 'i' goes
> > away? Or would
>
> Yes, that's correct. "If an
Hi!
OK to push (now, or in next development stage 1?) the attached
"Consider 'TDF_UID', 'TDF_NOUID' in 'print_node_brief', 'print_node'",
or should that be done differently -- or, per the current state (why?)
not at all?
This does work for my current debugging task, but I've not yet run
'make
On Wed, 9 Feb 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > This adds a missing check to epilogue reduction re-use, namely
> > that we can do hi/lo extracts from the vector when demoting it
> > to the epilogue vector size.
> >
> > I've chosen to add a can_vec_extract helper to
Richard Biener writes:
> This adds a missing check to epilogue reduction re-use, namely
> that we can do hi/lo extracts from the vector when demoting it
> to the epilogue vector size.
>
> I've chosen to add a can_vec_extract helper to optabs-query.h,
> in the future we might want to simplify the
On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++
wrote:
>
> This issue was observed as a deadloack in
> 29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
> "laundered" (e.g. type T* does not suffice as a waitable address for the
> platform's native waiting primitive),
On Wed, 9 Feb 2022, Jakub Jelinek wrote:
> On Wed, Feb 09, 2022 at 10:03:02AM +0100, Richard Biener wrote:
> > I see there are still targets doing sth like
> >
> > static void
> > msp430_option_override (void)
> > {
> > /* The MSP430 architecture can safely dereference a NULL pointer. In
> >
This adds a missing check to epilogue reduction re-use, namely
that we can do hi/lo extracts from the vector when demoting it
to the epilogue vector size.
I've chosen to add a can_vec_extract helper to optabs-query.h,
in the future we might want to simplify the vectorizers life by
handling
On Wed, Feb 09, 2022 at 10:03:02AM +0100, Richard Biener wrote:
> I see there are still targets doing sth like
>
> static void
> msp430_option_override (void)
> {
> /* The MSP430 architecture can safely dereference a NULL pointer. In
> fact,
> there are memory mapped registers there. */
On Feb 09 2022, Segher Boessenkool wrote:
> Hi Andreas,
>
> On Tue, Feb 08, 2022 at 06:36:57PM +0100, Andreas Schwab wrote:
>> On Feb 08 2022, Peter Bergner wrote:
>> > Can you please clarify one thing for me. Do you think it's possible
>> > that we can come up with some type of configure patch
On Wed, Feb 9, 2022 at 10:03 AM liuhongt wrote:
>
> ix86_expand_vector_init expects vals to be a parallel containing
> values of individual fields which should be either element mode of the
> vector mode, or a vector mode with the same element mode and smaller
> number of elements.
>
> But in the
The following avoids merging a vector compare with EH with a
VEC_COND_EXPR. We should be able to do fallback expansion and if
we really are for the optimization we need quite some shuffling
to arrange for the proper EH redirection in all cases, IMHO not
worth it.
Bootstrapped and tested on
This guards shift builtin folding to do nothing when there is
no LHS, similar to what other foldings do.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed as obvious.
2022-02-09 Richard Biener
PR target/104453
* config/i386/i386.cc (ix86_gimple_fold_builtin): Guard
ix86_expand_vector_init expects vals to be a parallel containing
values of individual fields which should be either element mode of the
vector mode, or a vector mode with the same element mode and smaller
number of elements.
But in the expander ashlv16qi3, the second operand is SImode which
can't
ix86_expand_vector_init expects vals to be a parallel containing
values of individual fields which should be either element mode of the
vector mode, or a vector mode with the same element mode and smaller
number of elements.
But in the expander ashlv16qi3, the second operand is SImode which
can't
On Wed, 9 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> The 3 ubsan -fsanitize={null,{,returns-}nonnull-attribute} sanitizers were
> setting implicitly -fno-delete-null-pointer-exceptions, so that
> optimizations don't optimize away its checks whether some pointers are NULL.
> Unfortunately by doing
Hi Michael,
on 2022/2/9 上午11:27, Michael Meissner via Gcc-patches wrote:
> Reset -mpower8-fusion for power9 inlining power8 functions, PR 102059.
>
> This patch is an attempt to make a much simpler patch to fix PR target/102059
> than the previous patch.
>
> It just fixes the issue that if a
Hi Andreas,
On Tue, Feb 08, 2022 at 06:36:57PM +0100, Andreas Schwab wrote:
> On Feb 08 2022, Peter Bergner wrote:
> > Can you please clarify one thing for me. Do you think it's possible
> > that we can come up with some type of configure patch that automatically
> > sets the long double default
Hi!
The following testcase ICEs, because when creating PAREN_EXPR for
__builtin_assoc_barrier the FE doesn't do the usual tweaks for
EXCESS_PRECISION_EXPR or C_MAYBE_CONST_EXPR. I believe that the
declared effect of the builtin is just association barrier, so
e.g. excess precision should be
Hi!
The 3 ubsan -fsanitize={null,{,returns-}nonnull-attribute} sanitizers were
setting implicitly -fno-delete-null-pointer-exceptions, so that
optimizations don't optimize away its checks whether some pointers are NULL.
Unfortunately by doing that there is no way to find out if
On Tue, Feb 8, 2022 at 9:58 PM Andrew MacLeod wrote:
>
> On 2/8/22 03:32, Richard Biener wrote:
> > On Tue, Feb 8, 2022 at 2:33 AM Andrew MacLeod via Gcc-patches
> > wrote:
> >> On 2/7/22 09:29, Andrew MacLeod wrote:
> >>> I have a proposal for PR 104288.
> >>>
> >>> ALL patches (in sequence)
On Wed, Feb 9, 2022 at 8:16 AM Eugene Rozenfeld via Gcc-patches
wrote:
>
> AutoFDO tries to promote and inline all indirect calls that were promoted
> and inlined in the original binary and that are still hot. In the included
> test case, the promotion results in a direct call that is a recursive
On Wed, Feb 9, 2022 at 12:20 AM Roger Sayle wrote:
>
>
> This patch resolves PR tree-optimization/104420, which is a P1 regression
> where, as observed by Jakub Jelinek, the conditions for constant folding
> x*0.0 are incorrect (following my patch for PR tree-optimization/96392).
> The
On Tue, Feb 8, 2022 at 11:38 PM Jason Merrill via Gcc-patches
wrote:
>
> On 2/8/22 16:59, Martin Sebor wrote:
> > Transforming a by-value arguments to by-reference as GCC does for some
> > class types can trigger -Wdangling-pointer when the argument is used
> > to store the address of a local
95 matches
Mail list logo
