This code:
#include
#include
void
f (pthread_key_t key)
{
pthread_setspecific (key, MAP_FAILED);
}
Results in a warning:
t.c: In function ‘f’:
t.c:7:3: warning: ‘pthread_setspecific’ expecting 1 byte in a region of size 0
[-Wstringop-overread]
7 | pthread_setspecific (key, MAP_FAILED
On Thu, 28 Oct 2021 at 21:33, Martin Sebor wrote:
>
> On 10/28/21 2:59 AM, Prathamesh Kulkarni via Gcc-patches wrote:
> > On Fri, 22 Oct 2021 at 14:41, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Wed, 20 Oct 2021 at 15:05, Richard Sandiford
> >> wrote:
> >>>
> >>> Prathamesh Kulkarni writes:
>
Richard Biener writes:
> On Wed, 3 Nov 2021, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Mon, 1 Nov 2021, Jiufu Guo wrote:
>> >
>> >> PR101145 is supporting if the number of iterations can be calculated
>> >> for the 'until wrap' condition. Current test cases are checking if
>> >>
This updates the internals manual documentation of TARGET_MEM_REF
and amends MEM_REF. The former was seriously out of date.
Pushed to trunk.
2021-11-04 Richard Biener
* doc/generic.text: Update TARGET_MEM_REF and MEM_REF
documentation.
---
gcc/doc/generic.texi | 58 +
On Thu, Nov 4, 2021 at 7:45 AM liuhongt wrote:
>
> a and b are same type as the truncation type and has less precision
> than extend type.
>
> Bootstrapped and regtested on x86-64-pc-linux-gnu{-m32,}.
> Ok for trunk?
OK.
Richard.
> gcc/ChangeLog:
>
> PR target/102464
> * match.p
On Thu, 4 Nov 2021, Jiufu Guo wrote:
> Richard Biener writes:
>
> > On Wed, 3 Nov 2021, Jiufu Guo wrote:
> >
> >> Richard Biener writes:
> >>
> >> > On Mon, 1 Nov 2021, Jiufu Guo wrote:
> >> >
> >> >> PR101145 is supporting if the number of iterations can be calculated
> >> >> for the 'until w
The following avoids asserting in exact_int_to_float_conversion_p that
the argument is not constant which it in fact can be with
-frounding-math and inexact int-to-float conversions. Say so.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2021-11-04 Richard Biener
PR rtl-opt
On Thu, Nov 04, 2021 at 06:43:26AM +0100, Gerald Pfeifer wrote:
> On Tue, 2 Nov 2021, H.J. Lu wrote:
> > On Tue, Nov 2, 2021 at 5:11 AM Jakub Jelinek wrote:
> >> include/md5.h is a header we have control over, can't we just add to it
> >> something like:
> >> #ifdef USE_SYSTEM_MD5
> >> #include_ne
Hi Jakub,
As Thomas reported and submitted a patch a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2019-April/519932.html
https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522738.html
There's an issue with the Fortran front-end when mapping arrays: when
creating the data MEM_REF for the m
The RTL frontend makes sure that CONST_INTs use shared rtxes where
appropriate. We should do the same thing for CONST_VECTORs,
reusing CONST0_RTX, CONST1_RTX and CONSTM1_RTX. This also has
the effect of setting CONST_VECTOR_NELTS_PER_PATTERN and
CONST_VECTOR_NPATTERNS.
While looking at where to
Vector lane indices follow memory (array) order, so lane 0 corresponds
to the high element rather than the low element on big-endian targets.
This was causing quite a few execution failures on aarch64_be,
such as gcc.c-torture/execute/pr47538.c.
Tested on aarch64-linux-gnu and aarch64_be-elf. Ap
Prathamesh Kulkarni writes:
> On Wed, 20 Oct 2021 at 15:05, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Tue, 19 Oct 2021 at 19:58, Richard Sandiford
>> > wrote:
>> >>
>> >> Prathamesh Kulkarni writes:
>> >> > Hi,
>> >> > The attached patch emits a more verbose diagnost
Pushed to master, fixes:
g++.log: FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
g++.log: UNRESOLVED: g++.dg/asan/asan_test.C -O2 compilation failed to
produce executable
gcc/testsuite/ChangeLog:
* g++.dg/asan/asan_test.C: Disable one warning.
---
gcc/testsuite/g++.d
On Wed, 3 Nov 2021 21:00:41 +0100
Harald Anlauf via Fortran wrote:
> *PING*
>
> Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:
> > Dear Fortranners,
> >
> > when debugging the testcase, I noticed that a coarray declaration in
> > a COMMON statement wrongly set the dimension attribute i
This removes an always true parameter of vn_nary_op_insert_into and moves
valueization to the two callers of vn_nary_op_compute_hash instead of doing it
therein where this function name does not suggest such thing.
Also remove extra valueization from PRE phi-translation.
Bootstrapped and tested on
Tested powerpc64le-linux, pushed to trunk.
Prior to r12-4447 (implementing P2231R1 constexpr changes) we didn't
construct the correct member of the union in __variant_construct_single,
we just plopped an object in the memory occupied by the union:
void* __storage = std::addressof(__lhs._M_u);
Tested powerpc64le-linux, pushed to trunk.
By defining additional partial specializations of _Nth_type we can
reduce the number of recursive instantiations needed to get from N to 0.
We can also use _Nth_type in variant_alternative, to take advantage of
that new optimization.
By adding a static_
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/std/variant (__detail::__variant::__emplace): New
function template.
(_Copy_assign_base::operator=): Reorder conditions to match
bulleted list of effects in the standard. Use __emplace in
Hi!
When users don't use constexpr everywhere in initialization of namespace
scope non-comdat vars and the initializers aren't constant when FE is
looking at them, the FE performs dynamic initialization of those variables.
But after inlining and some constant propagation, we often end up with
just
Hi,
This should address the ubsan bootstrap build and big-endian testisms
reported against the last NEON load/store gimple lowering patch. I also
fixed a follow-up issue where the alias information was leading to a bad
codegen transformation. The NEON intrinsics specifications do not forbid
t
On 11/2/21 16:56, Sandra Loosemore wrote:
On 11/2/21 9:20 AM, Martin Liška wrote:
On 11/2/21 15:48, Sandra Loosemore wrote:
On 11/2/21 2:51 AM, Martin Liška wrote:
On 11/2/21 00:56, Sandra Loosemore wrote:
I'll wait a couple days before committing these patches, in case
anybody wants to give
On Tue, Jul 06, 2021 at 11:17:55AM +0100, Iain Sandoe wrote:
> >> The addition of the CTOR is the fix for the C++ compile fail in the PR,
> >> the conditional is
> >> only there because the same header is compiled by C and C++.
> >
> > Whoops sorry - I was confused. The patch looks OK to me if y
@Segher: PING
On 10/19/21 16:43, Martin Liška wrote:
On 10/19/21 16:23, Segher Boessenkool wrote:
On Fri, Oct 15, 2021 at 05:24:32PM +0200, Martin Liška wrote:
On 10/14/21 17:10, Bill Schmidt via Gcc-patches wrote:
Looks like you got your parentheses wrong here.
Whoops, thanks for the heads
The problem in this PR is an off-by-one bug. We should've allocated
num_ssa_names + 1. However, in fixing this, I noticed that
num_ssa_names can change between queries, so I have replaced the array
with an auto_vec and added code to grow the vector as necessary.
Tested on x86-64 Linux.
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
> on 2021/6/11 下午9:16, Kewen.Lin via Gcc-patches wrote:
>> Hi Segher,
>>
>> Thanks for the review!
>>
>> on 2021/6/10 上午4:17, Segher Boessenkool wrote:
>>> Hi!
>>>
>>>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580358.html
BR,
Kewen
>> on 2021/9/28 下午4:16, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> This patch follows the discussions here[1][2], where Segher
>>> pointed out the existing way to guard the extra penalized
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
One related patch [1] is ready to commit, whose test cases rely on
this patch if no changes are applied to them.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579658.html
BR,
Kewen
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
>
> on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As the discussion in PR102347, cu
On Thu, 4 Nov 2021, Jakub Jelinek wrote:
> Hi!
>
> When users don't use constexpr everywhere in initialization of namespace
> scope non-comdat vars and the initializers aren't constant when FE is
> looking at them, the FE performs dynamic initialization of those variables.
> But after inlining an
On Thu, Nov 4, 2021 at 11:05 AM Martin Liška wrote:
>
> On 11/2/21 16:56, Sandra Loosemore wrote:
> > On 11/2/21 9:20 AM, Martin Liška wrote:
> >> On 11/2/21 15:48, Sandra Loosemore wrote:
> >>> On 11/2/21 2:51 AM, Martin Liška wrote:
> On 11/2/21 00:56, Sandra Loosemore wrote:
> > I'll w
On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> From: yfeldblum
>
> The stdout stream is reserved for output intentionally produced by the
> application. Assertion failures and other forms of logging must be
> emitted to stderr, not to stdout.
>
> It is
On Tue, Oct 19, 2021 at 04:43:40PM +0200, Martin Liška wrote:
> On 10/19/21 16:23, Segher Boessenkool wrote:
> >On Fri, Oct 15, 2021 at 05:24:32PM +0200, Martin Liška wrote:
> >>On 10/14/21 17:10, Bill Schmidt via Gcc-patches wrote:
> >>>Looks like you got your parentheses wrong here.
> >>
> >>Whoo
On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches wrote:
> On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> Gcc-patches wrote:
> >
> > From: Bernhard Reutner-Fischer
> >
> > Bump required DejaGnu version to 1.5.3 (or later).
> > Ok for trunk?
>
> OK.
If we r
On Wed, 27 Oct 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > This refactors the main loop analysis part in vect_analyze_loop,
> > re-purposing the existing vect_reanalyze_as_main_loop for this
> > to reduce code duplication. Failure flow is a bit tricky since
> > we want to extract
> > + if (!TYPE_UNSIGNED (TREE_TYPE (orig_use_lhs)))
> > + return false;
> > + if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (orig_use_lhs))
> > + return false;
> > + if (EDGE_COUNT (phi_bb->preds) != 4)
> > + return false;
> > + if (!TYPE_UNSIGNED (TREE_TYPE (orig_use_lhs)))
> > +
On 11/4/21 12:55, Segher Boessenkool wrote:
On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches wrote:
On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
Gcc-patches wrote:
From: Bernhard Reutner-Fischer
Bump required DejaGnu version to 1.5.3 (or later).
Ok fo
On Thu, Nov 4, 2021 at 1:20 AM Jakub Jelinek wrote:
>
> On Thu, Nov 04, 2021 at 06:43:26AM +0100, Gerald Pfeifer wrote:
> > On Tue, 2 Nov 2021, H.J. Lu wrote:
> > > On Tue, Nov 2, 2021 at 5:11 AM Jakub Jelinek wrote:
> > >> include/md5.h is a header we have control over, can't we just add to it
>
I've now committed the patch to rework the vector costs hooks --
thanks to Richard for the review.
This patch moves more code into aarch64_vector_costs and reuses
some of the information that is now available in the base class.
I'm planing to significantly rework this code, with more hooks
into t
Sending the patch in a separate thread.
Ready for master?
Cheers,
Martin
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_override_options_after_change):
Do not set flag_rename_registers, it's already enabled with
EnabledBy(funroll-loops).
Use EnabledBy for unrol
On Thu, Nov 04, 2021 at 01:25:43PM +0100, Martin Liška wrote:
> diff --git a/libsanitizer/asan/asan_mapping.h
> b/libsanitizer/asan/asan_mapping.h
> index 4b0037fced3..e5a7f2007ae 100644
> --- a/libsanitizer/asan/asan_mapping.h
> +++ b/libsanitizer/asan/asan_mapping.h
> @@ -165,7 +165,7 @@ static
Hi Jakub,
> On 4 Nov 2021, at 10:05, Jakub Jelinek wrote:
>
> On Tue, Jul 06, 2021 at 11:17:55AM +0100, Iain Sandoe wrote:
The addition of the CTOR is the fix for the C++ compile fail in the PR,
the conditional is
only there because the same header is compiled by C and C++.
>>>
On 11/4/21 13:37, Jakub Jelinek wrote:
On Thu, Nov 04, 2021 at 01:25:43PM +0100, Martin Liška wrote:
diff --git a/libsanitizer/asan/asan_mapping.h b/libsanitizer/asan/asan_mapping.h
index 4b0037fced3..e5a7f2007ae 100644
--- a/libsanitizer/asan/asan_mapping.h
+++ b/libsanitizer/asan/asan_mapping.
On Thu, Nov 4, 2021 at 12:57 PM Segher Boessenkool
wrote:
>
> On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> wrote:
> > On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> > Gcc-patches wrote:
> > >
> > > From: Bernhard Reutner-Fischer
> > >
> > > Bump req
On Thu, Nov 04, 2021 at 12:39:34PM +, Iain Sandoe wrote:
> Bootstrap succeeded with Apple clang-503.0.40 (Xcode 5.1.1) on macOS 10.8
> which is the earliest version I expect to work (previous xcode impl. have more
> C++11 incompatibilities). So OK from a Darwin PoV.
>
> The other reported to
On 11/2/21 17:45, Richard Biener wrote:
On Tue, Nov 2, 2021 at 4:11 PM Martin Liška wrote:
On 11/2/21 15:33, Richard Biener wrote:
I think -gtoggle matches a Defered option and thus should be processed
in handle_common_deferred_options.
Well, that's quite problematic as I handle_common_defe
On Wed, Nov 3, 2021 at 2:29 PM Xionghu Luo wrote:
>
>
>
> On 2021/10/29 19:48, Richard Biener wrote:
> > I'm talking about the can_sm_ref_p call, in that context 'loop' will
> > be the outermost loop of
> > interest, and we are calling this for all stores in a loop. We're doing
> >
> > +bool
> >
On Wed, 3 Nov 2021, Tamar Christina wrote:
> Hi,
>
> I have addressed all the feedback and updated patch attached:
>
> Bootstrapped Regtested on aarch64-none-linux-gnu,
> x86_64-pc-linux-gnu and no regressions.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * match.pd: N
On Thu, Nov 4, 2021 at 1:51 PM Martin Liška wrote:
>
> On 11/2/21 17:45, Richard Biener wrote:
> > On Tue, Nov 2, 2021 at 4:11 PM Martin Liška wrote:
> >>
> >> On 11/2/21 15:33, Richard Biener wrote:
> >>> I think -gtoggle matches a Defered option and thus should be processed
> >>> in handle_comm
Hi All,
This test hopefully fixes all the remaining target specific test issues by
1: Unrolling all add testcases by 16 using pragma GCC unroll
2. On armhf use Adv.SIMD instead of MVE to test. MVE's autovec is too incomplete
to be a general test target.
3. Add appropriate vect_ and float guard
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 347682ea4637c57c386908d6e1aa52e4efaace53.
gcc/analyzer/ChangeLog:
* program-state.cc (sm_state_map::dump): Use default_tree_printer
as format decoder.
---
gcc/analyzer/program-state.cc | 1 +
1 file
On Thu, 4 Nov 2021, Tamar Christina wrote:
> Hi All,
>
> This test hopefully fixes all the remaining target specific test issues by
>
> 1: Unrolling all add testcases by 16 using pragma GCC unroll
> 2. On armhf use Adv.SIMD instead of MVE to test. MVE's autovec is too
> incomplete
>to be a
On Thu, 4 Nov 2021 at 12:42, Richard Biener via Gcc wrote:
>
> On Thu, Nov 4, 2021 at 12:57 PM Segher Boessenkool
> wrote:
> >
> > On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> > > Gcc-patc
Pushed.
Doing so, one can see:
$ git gcc-verify a50914d2111c72d2cd5cb8cf474133f4f85a25f6 -v
Checking a50914d2111c72d2cd5cb8cf474133f4f85a25f6: FAILED
ERR: unchanged file mentioned in a ChangeLog: "gcc/common.opt"
ERR: unchanged file mentioned in a ChangeLog (did you mean
"gcc/testsuite/g++.dg/p
Hi!
For -fstrong-eval-order (default for C++17 and later) we make sure to
gimplify arguments in the right order, but as the following testcase
shows that is not enough.
The problem is that some lvalues can satisfy the is_gimple_val / fb_rvalue
predicate used by gimplify_arg for is_gimple_reg_type
Hi,
this patch implements the (long promised) intraprocedural dataflow for
propagating eaf flags, so we can handle parameters that participate
in loops in SSA graphs. Typical example are acessors that walk linked
lists, for example.
I implemented dataflow using the standard iteration over BBs in R
On Wed, Oct 20, 2021 at 5:43 AM H.J. Lu wrote:
>
> When --enable-cet is used to configure GCC, enable Intel CET in libffi.
>
> * Makefile.am (AM_CFLAGS): Add $(CET_FLAGS).
> (AM_CCASFLAGS): Likewise.
> * configure.ac (CET_FLAGS): Add GCC_CET_FLAGS and AC_SUBST.
> *
v2: rebased
The --with-cpu/--with-arch configure option processing not only checks valid
arguments
but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This isn't
used
however since a --with-cpu is translated into a -mcpu option which is processed
as if
written on the command-lin
ping
From: Wilco Dijkstra
Sent: 02 June 2021 11:21
To: GCC Patches
Cc: Kyrylo Tkachov ; Richard Sandiford
Subject: [PATCH] AArch64: Improve address rematerialization costs
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get l
We already attempt to resolve the current path on entry to
find_paths_to_name(), so there's no need to do so again for each
exported range since nothing has changed.
Removing this redundant calculation avoids 22% of calls into the path
solver.
Tested on x86-64 and ppc64le Linux with the usual reg
We are currently calculating implicit PHI relations for all PHI
arguments. This creates unecessary work, as we only care about SSA
names in the import bitmap. Similarly for inter-path relationals. We
can avoid things not in the bitmap.
Tested on x86-64 and ppc64le Linux with the usual regstrap.
The range_of_expr method provides better caching than range_on_edge.
If we have a statement, we can just it and avoid the range_on_edge
dance. Plus we can use all the range_of_expr fanciness.
Tested on x86-64 and ppc64le Linux with the usual regstrap. I also
verified that the before and after nu
Check leal and addl for x32 to fix:
FAIL: gcc.target/i386/amxtile-3.c scan-assembler addq[ \\t]+\\$12
FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[ \\t]+4
FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[ \\t]+8
* gcc.target/i386/amxtile-3.c: Check leal/addl for x32.
---
gc
On Thu, Oct 28, 2021 at 9:57 PM jiawei wrote:
>
> Co-Authored-By: sinan
> ---
> gcc/config/riscv/arch-canonicalize | 1 +
> gcc/config/riscv/constraints.md| 3 ++-
> gcc/config/riscv/riscv.c | 15 +--
> 3 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git
Could you add the information about zdinx implied zfinx to riscv_implied_info_t?
Thanks!
On Thu, Oct 28, 2021 at 9:56 PM jiawei wrote:
>
> Co-Authored-By: sinan
> ---
> gcc/common/config/riscv/riscv-common.c | 6 ++
> gcc/config/riscv/riscv-opts.h | 6 ++
> gcc/config/riscv/ri
On 11/3/2021 2:15 AM, Richard Biener via Gcc-patches wrote:
On Tue, Nov 2, 2021 at 4:53 PM Jeff Law wrote:
I was wandering spec chasing down instances where we should be
generating bit-test, bit-set and bit-clear types of instructions for our
target when I ran across a generic missed optimi
On Thu, Nov 04, 2021 at 12:19:34PM +, Tamar Christina wrote:
> I'm not sure the precision matters since if the conversion resulted in not
> enough
> precision such that It influences the compare it would have been optimized
> out.
You can't really rely on other optimizations being performed.
On 11/4/21 14:09, Richard Biener wrote:
But we shouldn't start with the current global options but with ones
we saved for
optimize attribute/pragma processing, no?
We hit the issue when we combine cmdline and pragma optimize options.
Problem of -gtoggle is that it does not directly influenc
On 11/4/21 1:03 AM, Florian Weimer via Libc-alpha wrote:
This code:
#include
#include
void
f (pthread_key_t key)
{
pthread_setspecific (key, MAP_FAILED);
}
Results in a warning:
t.c: In function ‘f’:
t.c:7:3: warning: ‘pthread_setspecific’ expecting 1 byte in a region of size 0
[-Wstrin
On Thu, Nov 04, 2021 at 12:13:51PM +0100, Richard Biener wrote:
> As a general comment I wonder whether doing this fully in the C++
> frontend leveraging the constexpr support is a better approach, esp.
> before we end up putting all initializers into a single function ...
> even partly constexpr e
* Martin Sebor:
> Thanks for the reminder. I have not forgotten about this.
> I agreed in our discussion and in the GCC bug report where this
> came up (PR 101751) that the GCC logic here is wrong and should
> be relaxed. I consider it a GCC bug so I plan to make the change
> in the bug fixing s
It's been inconvenient that pretty-printing of PTRMEM_CST didn't display
what member the constant refers to.
Adding that is complicated by the absence of a langhook for CONSTANT_CLASS_P
nodes; the simplest fix for that is to use the tcc_exceptional hook for
tcc_constant as well.
Tested x86_64-pc-
On 11/4/21 15:12, Jan Hubicka via Gcc-patches wrote:
|Bootstrapped/regtested x86_64-linux, plan to commit after bit more testing.|
Can you please install the patch after the current MOD REF crashes are fixed?
It will help us with the future bisection.
Thanks,
Martin
Hi,
this patch workarounds ICE in gimple_static_chain_flags. I added a
sanity check that the nested function is never considered interposable
because such situation makes no sense: nested functions have no static
API and can not be safely merged across translation units.
It turns out however that
> On 11/4/21 15:12, Jan Hubicka via Gcc-patches wrote:
> > |Bootstrapped/regtested x86_64-linux, plan to commit after bit more
> > testing.|
>
> Can you please install the patch after the current MOD REF crashes are fixed?
> It will help us with the future bisection.
Sure, this is what I am doin
On Thu, Nov 04, 2021 at 05:13:41PM +0100, Jan Hubicka via Gcc-patches wrote:
> this patch workarounds ICE in gimple_static_chain_flags. I added a
> sanity check that the nested function is never considered interposable
> because such situation makes no sense: nested functions have no static
> API
> On Thu, Nov 04, 2021 at 05:13:41PM +0100, Jan Hubicka via Gcc-patches wrote:
> > this patch workarounds ICE in gimple_static_chain_flags. I added a
> > sanity check that the nested function is never considered interposable
> > because such situation makes no sense: nested functions have no stati
Hi,
On Wed, Nov 03 2021, Richard Biener wrote:
> On Mon, 1 Nov 2021, Martin Jambor wrote:
>
>> Hello,
>>
>> I'd like to ping this patch.
>>
>> Thanks,
>>
>> Martin
>>
>>
>> On Wed, Oct 13 2021, Martin Jambor wrote:
>> > Hi,
>> >
>> > in spring I added code eliminating any statements using par
Hello All,
I am badly stuck at custom float encode and decode, I humbly request your
assistance.
I am trying to incorporate in custom floats in RISCV-32 elf, I am encoding
and assigning to image at line 2985 in
https://github.com/riscv-collab/riscv-gcc/blob/5964b5cd72721186ea2195a7be8d40cfe655402
Outgoing range calculations were assuming an undefined operand produces
an undefined result. This is not true, as in the testcxase:
[0, 0] = UNDEFINED | b_9 tells us that b_9 is [0,0] and the rest
of the time, we only know its varying. Returning UNDEFINED for b_9 is
clearly wrong.
"Andre Vieira (lists)" writes:
> Hi,
>
> This should address the ubsan bootstrap build and big-endian testisms
> reported against the last NEON load/store gimple lowering patch. I also
> fixed a follow-up issue where the alias information was leading to a bad
> codegen transformation. The NEON
Richard Biener writes:
>> > [...]
>> > @@ -2898,43 +2899,63 @@ vect_joust_loop_vinfos (loop_vec_info
>> > new_loop_vinfo,
>> >return true;
>> > }
>> >
>> > -/* If LOOP_VINFO is already a main loop, return it unmodified. Otherwise
>> > - try to reanalyze it as a main loop. Return the lo
> On Thu, Nov 04, 2021 at 05:13:41PM +0100, Jan Hubicka via Gcc-patches wrote:
> > this patch workarounds ICE in gimple_static_chain_flags. I added a
> > sanity check that the nested function is never considered interposable
> > because such situation makes no sense: nested functions have no stati
On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") ca
Wilco Dijkstra writes:
> ping
Can you fold in the rtx costs part of the original GOT relaxation patch?
I don't think there's enough information here for me to be able to review
the patch though. I'll need to find testcases, look in detail at what
the rtl passes are doing, and try to work out wh
On Thu, 4 Nov 2021, liuhongt via Gcc-patches wrote:
> a and b are same type as the truncation type and has less precision
> than extend type.
Note that this is not safe with -fsignaling-nans, so needs to be disabled
for that option (if there isn't already logic somewhere with that effect),
beca
Tested powerpc64le-linux, committed to trunk.
This reduces the number of class template instantiations needed for code
using tuples, by reusing _Nth_type in tuple_element and specializing
tuple_size_v for tuple, pair and array (and const-qualified versions of
them).
Also define the _Nth_type pri
Tested powerpc64le-linux, committed to trunk.
Currently std::variant uses __index_of to find the first
occurence of a type in a pack, and __exactly_once to check
that there is no other occurrence.
We can reuse the __find_uniq_type_in_pack() function for
both tasks, and remove the recursive templ
With -fstack-check the stack probes emitted access memory below the
stack pointer.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
* config/s390/s390.h (STACK_CHECK_MOVING_SP): New macro
definition.
---
gcc/config/s390/s390.h | 5 +
1 file
On 10/31/2021 5:05 PM, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
contrib/ChangeLog:
* testsuite-management/validate_failures.py: 2to3
Please update the comments at the top of the file WRT Python 2.4. :-)
With those comments fixed, OK.
jeff
On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote:
> On 11/4/21 12:55, Segher Boessenkool wrote:
> >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> >wrote:
> >>On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> >>Gcc-patches wrote:
> >>>
> >>>From
Hi Bernhard,
Am 04.11.21 um 10:06 schrieb Bernhard Reutner-Fischer via Fortran:
On Wed, 3 Nov 2021 21:00:41 +0100
Harald Anlauf via Fortran wrote:
*PING*
Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when debugging the testcase, I noticed that a coarray declarat
GCC (currently) has an implementation of pre-compiled-headers, that relies
on being able to launch the compiler executable at the same address each
time. This constraint is not permitted by some system security models.
The facility is an optimisation; saving the output of parsing a covering
heade
Some hosts cannot (or do not wish to) support PCH with the
current constraint that the executables must disable ASLR.
This allows the configuration to disable support for PCH
while still accepting the command lines (to avoid existing
build recipes failing).
Signed-off-by: Iain Sandoe
gcc/c-fami
This takes account of the overall configuration for host PCH support
when deciding if we should build the libstdc++ PCH files.
We now require both the support is configured and that we are hosted.
A non-fatal configure warning is given if the user attempts to
--disable-host-pch-support --enable-li
This provides a --disable-host-pch-support configure flag
that is passed down to libcpp, gcc and libstdc++ where the
support for PCH is enacted.
Signed-off-by: Iain Sandoe
ChangeLog:
* Makefile.def: Pass host PCH support configuration
to libcpp, gcc and libstdc++.
* Make
This accepts --disable-host-pch-support (or equivalent) and
disables the step that finds PCH files in the pre-processor.
It also stubs-out the PCH code (since it's never called).
Signed-off-by: Iain Sandoe
libcpp/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
On Thu, Nov 4, 2021 at 3:44 PM H.J. Lu via Gcc-patches
wrote:
>
> Check leal and addl for x32 to fix:
>
> FAIL: gcc.target/i386/amxtile-3.c scan-assembler addq[ \\t]+\\$12
> FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[ \\t]+4
> FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[ \\t]+
On Thu, Nov 4, 2021 at 1:08 PM Uros Bizjak wrote:
>
> On Thu, Nov 4, 2021 at 3:44 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Check leal and addl for x32 to fix:
> >
> > FAIL: gcc.target/i386/amxtile-3.c scan-assembler addq[ \\t]+\\$12
> > FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[ \\
This patch implements P0849R8 which allows auto in a functional cast,
the result of which is a prvalue.
[expr.type.conv]/1 says that the type is determined by placeholder type
deduction. We only accept 'auto', not 'decltype(auto)' -- that the
type shall be auto comes from [dcl.type.auto.deduct].
On Thu, Nov 04, 2021 at 11:52:34AM -0400, Jason Merrill via Gcc-patches wrote:
> It's been inconvenient that pretty-printing of PTRMEM_CST didn't display
> what member the constant refers to.
>
> Adding that is complicated by the absence of a langhook for CONSTANT_CLASS_P
> nodes; the simplest fix
1 - 100 of 129 matches
Mail list logo
