This patch to libgo avoids using == for string equality in C code.
This is a backport of https://golang.org/cl/300993. This is for GCC
PR 99553. Bootstrapped and ran gotools testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
eb7eb29c37b1326bd4c8af7e5c35439a5d4521d4
diff --git
ChangeLog:
2021-03-12 Eugene Rozenfeld
* MAINTAINERS (Write After Approval): Add myself.
0001-MAINTAINERS-Add-myself-for-write-after-approval.patch
Description: 0001-MAINTAINERS-Add-myself-for-write-after-approval.patch
I have updated the patch as you suggested, to filter the
"-fvtable-verify=std" out of AM_CXXFLAGS, and I have verified that it
passes the testsuite with no regressions and fixes the reported bug.
Is this OK to commit now?
-- Caroline Tice
cmt...@google.com
libstdc++-v3/ChangeLog
2021-03-12
On Fri, Mar 12, 2021 at 07:52:16PM +0100, Uros Bizjak via Gcc-patches wrote:
> > I can test it on avx512{bw,vl,dq} hw tonight if you want.
>
> I'm testing the patch on avx2 hw, which is not representative of this
> change. So if you can spare a few cycles, that would be awesome.
Passed
On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote:
> Hi, Kees,
>
> I am looking at the structure padding initialization issue. And also have
> some questions:
>
>
> > On Feb 24, 2021, at 10:41 PM, Kees Cook wrote:
> >
> > It looks like there is still some issues with padding and
Hi, Kees,
I am looking at the structure padding initialization issue. And also have some
questions:
> On Feb 24, 2021, at 10:41 PM, Kees Cook wrote:
>
> It looks like there is still some issues with padding and pre-case
> switch variables. Here's the test output, FWIW:
>
>
>
> On Mar 11, 2021, at 6:46 PM, Kees Cook wrote:
>
> On Thu, Mar 11, 2021 at 03:47:17PM -0600, Qing Zhao wrote:
>> Hi, Kees,
>>
>> Sorry for the late reply (I have been busy with other work recently).
>>
>> Currently, I am working on the issue of flexible length array as the last
>> field
Dear all,
the addition of runtime checks for the SIZE intrinsic created a regression
that showed up for certain CLASS arguments to procedures. Paul did most of
the work (~ 99%), but asked me to dig into an issue with an inappropriately
selected error message. This actually turned out to be a
V pet., 12. mar. 2021 19:19 je oseba Jakub Jelinek napisala:
>
> On Fri, Mar 12, 2021 at 06:48:57PM +0100, Uros Bizjak wrote:
> > It is hidden in *vec_extractv4si pattern:
> >
> > (define_insn "*vec_extractv4si"
> > - [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,rm,Yr,*x,x,Yv")
> > +
This ICE was caused by a stray TREE_VISITED marker. The lookup
machinery was leaving it there due to the way I'd arranged for it to be
cleared. That was presuming the name_lookup::value field didn't change,
and that wasn't always true in the using-decl processing. I took the
opportunity
On Fri, Mar 12, 2021 at 06:48:57PM +0100, Uros Bizjak wrote:
> It is hidden in *vec_extractv4si pattern:
>
> (define_insn "*vec_extractv4si"
> - [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,rm,Yr,*x,x,Yv")
> + [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,rm,Yr,*x,Yw")
>
It's a bug in the SPARC back-end exposed by the recent LRA changes, whereby
the T constraint fails to behave properly when LRA is enabled (unlike when
reload is enabled, thanks for Vladimir for pinpoint it). The patch also gets
rid of the awkward W constraint, which is strictly equivalent to m
On Fri, Mar 12, 2021 at 6:32 PM Jakub Jelinek wrote:
>
> On Fri, Mar 12, 2021 at 06:05:34PM +0100, Uros Bizjak wrote:
> > Untested patch that introduces YW to some remaining pextr
> > instructions, fixes one case of 128bit vpsrldq and 128bit vpalignr w/o
> > AVX512VL.
>
> Not sure I can find the
This removes the new symbols added for the new futex-based
std::call_once implementation. These symbols were new on trunk, so not
in any released version. However, they are already present in some
beta distro releases (Fedora Linux 34) and in Fedora Linux rawhide. This
change can be locally
The new std::call_once implementation is not backwards compatible,
contrary to my intention. Because std::once_flag::_M_active() doesn't
write glibc's "fork generation" into the pthread_once_t object, it's
possible for glibc and libstdc++ to run two active executions
concurrently. This violates
On Fri, Mar 12, 2021 at 06:05:34PM +0100, Uros Bizjak wrote:
> Untested patch that introduces YW to some remaining pextr
> instructions, fixes one case of 128bit vpsrldq and 128bit vpalignr w/o
> AVX512VL.
Not sure I can find the vpsrldq change in there.
> @@ -21599,11 +21590,11 @@
>
On Fri, Mar 12, 2021 at 5:11 PM Uros Bizjak wrote:
>
> On Fri, Mar 12, 2021 at 4:28 PM Jakub Jelinek wrote:
> >
> > On Fri, Mar 12, 2021 at 03:34:09PM +0100, Uros Bizjak wrote:
> > > > (define_insn "*avx2_pmaddwd"
> > > > - [(set (match_operand:V8SI 0 "register_operand" "=x,v")
> > > > +
In addition to the existing check also ask the target whether a
replacement register may be accessed in a different mode than it was set
before.
Bootstrapped and regtested on IBM Z. Ok for mainline?
gcc/ChangeLog:
* regcprop.c (find_oldest_value_reg): Ask target whether
On Feb 24, 2021, at 1:10 AM, Alexandre Oliva wrote:
>
> On Feb 23, 2021, Jim Wilson wrote:
>> If we add default multilibs for you
>
> *nod*, it's a very familiar issue to me, I know where that's coming
> from, no worries.
So, what I'd do is if you have a triplet component that isn't used
On Feb 18, 2021, at 6:15 AM, Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Feb 17, 2021 at 01:46:37PM -0500, Nathan Sidwell wrote:
>> I'd missed that macros were allocated from GC storage, and that they can
>> become unattached from an identifier, and therefore not GC-reachable.
>>
On Fri, Mar 12, 2021 at 4:28 PM Jakub Jelinek wrote:
>
> On Fri, Mar 12, 2021 at 03:34:09PM +0100, Uros Bizjak wrote:
> > > (define_insn "*avx2_pmaddwd"
> > > - [(set (match_operand:V8SI 0 "register_operand" "=x,v")
> > > + [(set (match_operand:V8SI 0 "register_operand" "=Yw")
> >
> > I'm not
On Fri, Mar 12, 2021 at 03:34:09PM +0100, Uros Bizjak wrote:
> > (define_insn "*avx2_pmaddwd"
> > - [(set (match_operand:V8SI 0 "register_operand" "=x,v")
> > + [(set (match_operand:V8SI 0 "register_operand" "=Yw")
>
> I'm not sure contraction like this is correct. The prolbem is with vex
>
On Fri, Mar 12, 2021 at 2:38 PM Jakub Jelinek wrote:
>
> On Fri, Mar 12, 2021 at 09:35:00AM +0100, Uros Bizjak via Gcc-patches wrote:
> > Perhaps we can introduce another Y... constraint for AVX512BW and use
> > it here. I think they will be used in other places, too.
>
> Ok, added YW constraint
On Fri, Mar 12, 2021 at 09:04:33AM -0500, David Malcolm wrote:
> > from the start of the function and add is_gimple_call (stmt) &&
> > in tree-ssa-strlen.c.
>
> Maybe even make it convert it to taking a "const gcall *", so those
>
> if (is_gimple_call (stmt))
> {
>...
>if
On Fri, 2021-03-12 at 14:52 +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Mar 09, 2021 at 03:07:38PM -0700, Martin Sebor via Gcc-
> patches wrote:
> > The gimple_call_alloc_size() function is documented to "return null
> > when STMT is not a call to a valid allocation function" but the
> >
On 3/12/21 2:56 PM, David Malcolm wrote:
On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote:
Identified by my check that compares documentation of params
with content of --help=param output.
Pushed as obvious.
Martin
Thanks.
Which check is this, BTW? (presumably this is something I
On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote:
> Identified by my check that compares documentation of params
> with content of --help=param output.
>
> Pushed as obvious.
> Martin
Thanks.
Which check is this, BTW? (presumably this is something I should add
to my patch testing
On Tue, Mar 09, 2021 at 03:07:38PM -0700, Martin Sebor via Gcc-patches wrote:
> The gimple_call_alloc_size() function is documented to "return null
> when STMT is not a call to a valid allocation function" but the code
> assumes STMT is a call statement, causing the function to ICE when
> it
On Fri, Mar 12, 2021 at 09:35:00AM +0100, Uros Bizjak via Gcc-patches wrote:
> Perhaps we can introduce another Y... constraint for AVX512BW and use
> it here. I think they will be used in other places, too.
Ok, added YW constraint and used that for those mmx*{ins,ext}* as well
as _psadbw.
Here
Segher Boessenkool wrote:
On Wed, Mar 10, 2021 at 02:41:50AM -0300, Alexandre Oliva wrote:
ppc configurations that have -mstrict-align enabled by default fail
gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
MEM_REFs, which defeats the tested-for strlen optimization.
On Mon, Mar 08, 2021 at 07:37:46PM -0700, Martin Sebor via Gcc-patches wrote:
> Accesses to zero-length arrays continue to be diagnosed (except for
> trailing arrays of unknown objects), as are nonempty accesses to empty
> types.
>
> The warning message for (3) remains unchanged, i.e., for the
On Thu, Mar 11, 2021 at 11:21 PM Uros Bizjak wrote:
>
> On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
> >
> > Update 'P' operand modifier for -fno-plt to support inline assembly
> > statements. In 64-bit, we can always load function address with
> > @GOTPCREL. In 32-bit, we load function
Hi all,
This patch tweaks the Neoverse N2 tuning on the GCC 10 branch to have it in
line with GCC 8 and 9 to prefer AdvancedSIMD over SVE for auto-vectorisation.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to the branch.
Thanks,
Kyrill
gcc/ChangeLog:
*
On Thu, Mar 11, 2021 at 11:27 PM Uros Bizjak wrote:
>
> On Thu, Mar 11, 2021 at 11:22 PM H.J. Lu wrote:
> >
> > Update 'P' operand modifier for -fno-plt to support inline assembly
> > statements. In 64-bit, we can always load function address with
> > @GOTPCREL. In 32-bit, we load function
Hi,
the previous patch fixed issues with actual code left behind after
IPA-SRA removed a parameter but it might cause debug info regressions as
the patch only reset all affected debug bind statements. This one
updates them with expressions which can allow the debugger to print the
removed value
Hi,
PR 93385 reveals that if the user explicitely disables DCE, IPA-SRA
can leave behind statements which are useless because their results
are eventually not used but can have problematic side effects,
especially since their inputs are now bogus that useless parameters
were removed.
This patch
PING^2
On 3/1/21 1:07 PM, Martin Liška wrote:
PING
On 2/18/21 10:18 AM, Martin Liška wrote:
On 2/16/21 10:17 PM, Qing Zhao wrote:
Hello,
What’s the status of this patch now? Is there any major technical issue with
the patch?
Our company has been waiting for this patch for almost one year,
On Wed, Mar 10, 2021 at 03:20:42PM +0100, Tobias Burnus wrote:
> The C/C++ FE sets for an 'omp declare target' ... 'omp end declare target'
> the attribute 'omp declare target implicit'.
>
> That's later processed (for C++) in decl.c - which remove that attribute
> and either keeps and explicit
On Wed, Mar 10, 2021 at 03:20:51PM +0100, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/99514
> * resolve.c (resolve_symbol): Accept vars which are in DATA
> and hence (either) implicit SAVE (or in common).
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/99514
On Thu, Mar 11, 2021 at 02:44:38PM +0100, Tobias Burnus wrote:
> Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]
>
> gcc/ChangeLog:
>
> PR fortran/98858
> * gimplify.c (omp_add_variable): Handle NULL_TREE as size
> occuring for assumed-size arrays in
> Jakub reported that for glibc 2.34 (trunk, unreleased), Richard said it was
> working for glibc 2.33 (latest release), your commit says "Fix build
> breakage with latest glibc release" (which is 2.33). What is correct?
Both I guess, mine is just a bit more forward-looking. ;-)
> The symptom
>
ping.
YunQiang Su 于2021年2月28日周日 下午3:17写道：
>
> MIPS release 6 requires the lw/ld/sw/sd can work with
> unaligned address, while it can be implemented by
> full hardware or trap
>
> Since it is may be fully done by hardware, we add an
> option -m(no-)unaligned-access, the kernel may need it.
>
>
Jakub reported that for glibc 2.34 (trunk, unreleased), Richard said it was
working for glibc 2.33 (latest release), your commit says "Fix build breakage
with latest glibc release" (which is 2.33). What is correct?
The change also caused CI test failures in Debian and Ubuntu as seen at
Identified by my check that compares documentation of params
with content of --help=param output.
Pushed as obvious.
Martin
gcc/ChangeLog:
* doc/invoke.texi: Add missing param documentation.
---
gcc/doc/invoke.texi | 4
1 file changed, 4 insertions(+)
diff --git
On Fri, Mar 12, 2021 at 04:08:17AM +0100, David Lamparter wrote:
>
> The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> resulting in all information about the typedef's involvement getting
> lost. This drops necessary information for warnings and can make them
> confusing or
On Fri, Mar 12, 2021 at 8:59 AM Jakub Jelinek wrote:
>
> Hi!
>
> This is the final patch of the series started with
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566139.html
> and continued with
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566356.html
> This time, I went
That would be needed for removal of components which contain a ChangeLog.
Pushed to master.
Martin
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Allow deletion of ChangeLog
files.
* gcc-changelog/setup.cfg: Set line limit to 120 characters.
*
Hi!
For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into section, not sure for what
reason
Hi!
This is the final patch of the series started with
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566139.html
and continued with
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566356.html
This time, I went through all the remaining instructions marked
by gas as requiring both
49 matches
Mail list logo
