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 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
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
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
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
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.
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
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 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 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 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
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++.
*
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
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
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
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 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[
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
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
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].
"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
> 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
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
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[
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
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
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
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 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
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, 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
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
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
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
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
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
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
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
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
>
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
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 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
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
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
> 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
>
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),
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
> 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
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
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
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
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,
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
> >>
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
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
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.
---
Bootstrapped and regtested on x86-64-pc-linux-gnu{-m32,}.
Ready to push to trunk after first patch is approved.
gcc/ChangeLog:
PR target/101989
* config/i386/predicates.md (reg_or_notreg_operand): Rename to ..
(regmem_or_bitnot_regmem_operand): .. and extend to handle
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.
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
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
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
On Thu, Nov 4, 2021 at 9:50 AM Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> AVX512VNNI/AVXVNNI has vpdpwssd for HImode, vpdpbusd for QImode, so
> Adjust HImode sdot_prod expander and add QImode usdot_prod expander
> to enhance vectorization for dotprod.
>
> Bootstraped/regtested on
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?
gcc/ChangeLog:
PR target/102464
* match.pd: simplify (trunc)copysign((extend)a, (extend)b) to
.COPYSIGN (a,b)
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
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
> *
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
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
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
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
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.
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 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.
> >>
>
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);
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!
>>>
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
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
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
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
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
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 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
@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
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,
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 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
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
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
+++
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 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
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
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
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
> > + 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 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
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 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
1 - 100 of 128 matches
Mail list logo
