a, b, c are same type as truncation type and has less precision than
extend type, the optimization is guarded under
flag_unsafe_math_optimizations.
Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify
a and b are same type as trunc type and has less precision than
extend type, the transformation is guarded by flag_finite_math_only.
Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify
Generate XXSPLTIDP for scalars on power10.
This patch implements XXSPLTIDP support for SF, and DF scalar constants.
The previous patch added support for vector constants. This patch adds
the support for SFmode and DFmode scalar constants.
I added 2 new tests to test loading up SF and DF scalar
Generate XXSPLTIDP for vectors on power10.
This patch implements XXSPLTIDP support for all vector constants. The
XXSPLTIDP instruction is given a 32-bit immediate that is converted to a vector
of two DFmode constants. The immediate is in SFmode format, so only constants
that fit as SFmode
Generate XXSPLTIW on power10.
This patch adds support to automatically generate the ISA 3.1 XXSPLTIW
instruction for V8HImode, V4SImode, and V4SFmode vectors. It does this by
adding support for vector constants that can be used, and adding a
VEC_DUPLICATE pattern to generate the actual XXSPLTIW
Add LXVKQ support.
This patch adds support to generate the LXVKQ instruction to load specific
IEEE-128 floating point constants.
Compared to the last time I submitted this patch, I modified it so that it
uses the bit pattern of the vector to see if it can generate the LXVKQ
instruction. This
Add new constant data structure.
This patch provides the data structure and function to convert a
CONST_INT, CONST_DOUBLE, CONST_VECTOR, or VEC_DUPLICATE of a constant) to
an array of bytes, half-words, words, and double words that can be loaded
into a 128-bit vector register.
The next patches
These patches are a refinement of the patches to add XXSPLTIDP support on
September 13th. These patches generate instructions that load up a VSX
register with certain constants instead of using PLXV to load the constant.
On the Power10:
* XXSPLTIDP is a prefixed instruction that takes a value
This is an expanded version of the patch for PR 101337 that Bernhard
sent out a few days ago with a request for me to finish it. Bernhard
did the part for operands and I added the pieces for procedure arguments
and intrinsics, along with fixing up the test cases that were previously
full of
> 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),
> because the extend will convert a signaling NaN to quiet (raising
> "invalid"), but copysign won't, so this transformation could result in a
>
Hi Qing,
on 2021/11/5 上午4:37, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know
On Thu, Nov 4, 2021 at 8:50 PM Xionghu Luo wrote:
> [PATCH] rs6000: Fix incorrect fusion constraint [PR102991]
>
> gcc/ChangeLog:
>
> * config/rs6000/fusion.md: Regenerate.
> * config/rs6000/genfusion.pl: Fix incorrect clobber constraint.
Okay.
Thanks, David
On 2021/11/4 09:59, David Edelsohn wrote:
> On Wed, Nov 3, 2021 at 9:46 PM Xionghu Luo wrote:
>>
>> On 2021/11/3 23:13, David Edelsohn wrote:
>>> Did you manually change fusion.md or did you regenerate it after
>>> fixing genfusion.pl?
>>>
>>> If you regenerated it, the ChangeLog entry should
On 10/31/21 8:13 AM, Daniil Stas wrote:
On Sun, 10 Oct 2021 23:10:20 +
Daniil Stas wrote:
This option is enabled by default when -Wformat option is enabled. A
user can specify -Wno-format-int-precision to disable emitting
warnings when passing an argument of an incompatible integer type
On Thu, 4 Nov 2021, Jeff Law wrote:
> Sometimes the language we're using in email is not as crisp as it should be.
> So
> just to be clear, the canonicalization I'm referring to is only in effect
> within
> a MEM. It does not apply to address calculations that happen outside a MEM.
> I
>
On 11/4/2021 3:04 PM, Maciej W. Rozycki wrote:
On Thu, 4 Nov 2021, Jeff Law wrote:
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
On Thu, 4 Nov 2021 at 11:30, Jonathan Wakely wrote:
>
>
> 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
This patch aims to fix PR 55227; two underlying bugs that have caused:
(1) Rejection of valid designated initialization of char array fields by
string literals (a) when enclosed in optional braces or (b) unbraced
when the string literal is shorter than the target char array field.
(2) Acceptance
Tested x86_64-linux, committed to trunk. Backport to gcc-11 to follow,
and maybe to other branches too.
Since std::tuple started using [[no_unique_address]] the tuple
member of std::unique_ptr has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:
On Linux/x86_64,
d70720c2382e687e192a9d666e80acb41bfda856 is the first bad commit
commit d70720c2382e687e192a9d666e80acb41bfda856
Author: Tamar Christina
Date: Thu Nov 4 17:32:09 2021 +
middle-end: convert negate + right shift into compare greater.
caused
FAIL: gcc.dg/signbit-2.c
On Thu, 4 Nov 2021, Jeff Law wrote:
> 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
On Wed, 3 Nov 2021 at 00:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> These functions have been deprecated since C++11, and were removed in
> C++17. The proposal P0323 wants to reuse the name std::unexpected for a
> class template, so we will need to stop defining the
For at least one target (Darwin) the platform convention is to
register static destructors (i.e. __attribute__((destructor)))
with __cxa_atexit rather than placing them into a list that is
run by some other mechanism.
This patch provides a target hook that allows a target to opt
into this and
For posterity: This was discussed briefly on IRC, and Segher approved with
some
simplifications and a request to implement a fail/retry check.
Thanks,
Bill
On 11/3/21 10:02 AM, Jonathan Wakely wrote:
> On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: Any feedback from POWER
> maintainers
Hi,
I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11 and
GCC12 (on the same X86 machine)
For gcc11:
wide int max elts =3
For gcc12:
wide int max elts =9
Does anyone know what’s the reason for this difference?
Thanks a lot for any help.
Qing
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
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 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[
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[
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.
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++.
*
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
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 (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
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
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:
> >>>
>
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
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
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
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
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),
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
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.")
> 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
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
"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
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.
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
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
> 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
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 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
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.
Thanks,
Martin
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
* 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
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
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
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
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
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
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 ++
>
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
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.
---
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
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
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
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
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
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.
> *
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
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
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
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
> > >
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
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
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
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
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:
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 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
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
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
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
+++
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 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
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
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
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
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
> > + 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 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
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
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.
> >>
>
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 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
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
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,
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,
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
1 - 100 of 128 matches
Mail list logo
