Hi,
Thanks for your good suggestions!
This patch was remade and attached. Does the v2 patch look better?
Bootstrap and new testcase tested on aarch64 & x86 Linux platform.
Kaipeng Zhou
PR95854-v2.diff
Description: PR95854-v2.diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77510
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95944
Bug ID: 95944
Summary: Concept diagnostic has multiple copies of irrelevant
type and displays correct type incorrectly
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85541
Fred Krogh changed:
What|Removed |Added
CC||siteg at mathalacarte dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957
prop_design at protonmail dot com changed:
What|Removed |Added
CC||prop_design at
Snapshot gcc-10-20200627 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20200627/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
A rather straightforward issue (mis-)referencing the proper symbol name
in an error message.
OK for master / backport?
Thanks,
Harald
PR fortran/95880 - ICE in gfc_add_type, at fortran/symbol.c:2030
The fix for PR39695 did not properly distinguish between procedure names
and other symbols
On Sat, 2020-06-27 at 21:27 +0800, Shuai Wang via Gcc wrote:
> Dear Richard,
>
> Thanks for the info. My bad, I will need to append "\0" at the end of
> the
> string. Also, a follow-up question which I just cannot find an
> answer:
> typically in the plugin entry point:
>
> virtual unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95943
Bug ID: 95943
Summary: arc -mbig-endian "inappropriate arguments" error from
assembler
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Hi,
This is a enabler patch that enables a reasonable approach to
fixing 5 reported PRs (it doesn’t fix anything in its own right).
It has been tested on x86_64-linux, darwin, powerpc64-linux
OK for master / 10.2?
thanks
Iain
--
The standard describes a rewrite of the body of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #4 from Segher Boessenkool ---
Or even just { target le } yes. You can put that as the selector on just
the scan tests, and even do a separate BE version as well.
You can quote regexps with {} instead of "", that makes them much
On Sat, Jun 27, 2020 at 01:57:52AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 11:52:50AM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 01, 2020 at 03:53:37PM -0400, Michael Meissner wrote:
> > > Add tests for -mcpu=future that test the generation of PADDI (and PLI
> > > which
> >
On Sat, Jun 27, 2020 at 01:49:23AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 11:52:50AM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 01, 2020 at 03:53:37PM -0400, Michael Meissner wrote:
> > > Add tests for -mcpu=future that test the generation of PADDI (and PLI
> > > which
> >
On Sat, Jun 27, 2020 at 01:55:19AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 12:09:41PM -0500, Segher Boessenkool wrote:
> > On Thu, Jun 04, 2020 at 01:03:51PM -0400, Michael Meissner wrote:
> > > +/* { dg-final { scan-assembler-times {\mpaddi\M|\mpli|\mpla\M} 3 } } */
> >
> > Is
On Sat, Jun 27, 2020 at 01:50:48AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 12:18:42PM -0500, Segher Boessenkool wrote:
> > > +/* { dg-do compile } */
> > > +/* { dg-require-effective-target powerpc_prefixed_addr } */
> >
> > Is this test necessary anymore, does -mcpu=power10 not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82206
--- Comment #1 from Simon Marchi ---
Stumbled on this again in the GDB code. Here's another reproducer, probably
the same cause:
---
#include
#include
void add_line (const std::string );
void string_vappendf (std::string , const char *fmt,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
--- Comment #1 from Sergei Trofimovich ---
Original code looks is at
https://github.com/dolphin-emu/dolphin/blob/2e8d1dd1dbcca7095e9d842f1df037cbe76868e4/Source/Core/Core/DSP/Jit/x64/DSPEmitter.cpp#L476:
"""
...
Gen::OpArg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Bug ID: 95942
Summary: [11 regression] offsetof on an array: error: 'e' is
not a constant expression
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937
Marek Polacek changed:
What|Removed |Added
Keywords||error-recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
--- Comment #1 from Ville Voutilainen ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549030.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95941
Bug ID: 95941
Summary: Passing a struct by value wastes 16 bytes on the stack
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260
--- Comment #2 from niek ---
Dear Patrick,
Nope, I cannot reproduce it anymore.
It seems to be fixed!
PS apologies for my delayed response; this is one of my public 'spam
email addresses', just saw it now.
best,
Niek
On 22/06/2020 15:45,
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-10.1.0.sv.po', has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #15 from Jakub Jelinek ---
In the particular case we are talking about, security/non-security, it doesn't
make sense to do anything but optimize it into straight line code, any
__builtin_trap or similar will just hurt. If you feel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #14 from Jeffrey A. Law ---
The reason for turning the dereference into a trap is because we can clean up
ancillary computations -- the address computation, the RHS of a store, and the
like via standard dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #13 from Jeffrey A. Law ---
Marc,
Yes, absolutely. In fact, I think that falls out of the work Martin S is doing
in this space. Conceptually we're looking to generalize that code so that we
can route more cases where the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #13 from H.J. Lu ---
(In reply to Andi Kleen from comment #12)
> Okay. I only compared gcc-7 (working) vs gcc-9 (broken), but always with LTO.
>
> Looking at the kernel link it also uses --whole-archive. Perhaps that makes
> a
On Sat, 27 Jun 2020 at 17:53, Ville Voutilainen
wrote:
>
> On Fri, 26 Jun 2020 at 21:20, Jonathan Wakely wrote:
> > For these three tests I think this would be slightly better:
> >
> > // { dg-additional-options "-Wno-deprecated" { target c++17 } }
> >
> > That way we only ignore the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #12 from Andi Kleen ---
Okay. I only compared gcc-7 (working) vs gcc-9 (broken), but always with LTO.
Looking at the kernel link it also uses --whole-archive. Perhaps that makes a
difference?
I'll redo the test case with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #3 from Rich Felker ---
Yes,I'm aware m68k has FLT_EVAL_METHOD=2. That's not license for *functions* to
return excess precision. The language specification is very clear about where
excess precision is and isn't kept, and here it
On Fri, 26 Jun 2020 at 21:20, Jonathan Wakely wrote:
> For these three tests I think this would be slightly better:
>
> // { dg-additional-options "-Wno-deprecated" { target c++17 } }
>
> That way we only ignore the warning when actually needed.
Sure thing. The test run revealed some additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820
--- Comment #5 from Marek Polacek ---
*** Bug 95936 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95936
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
On Fri, 26 Jun 2020, Jeff Law via Gcc-patches wrote:
In theory yes, but there are cases where paths converge (like you've shown)
where
you may have evaluated to a constant on the paths, but it's not a constant at
the
convergence point. You have to be very careful using b_c_p like this and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #3 from David Edelsohn ---
{ target { le } }
Dear Richard,
Thanks for the info. My bad, I will need to append "\0" at the end of the
string. Also, a follow-up question which I just cannot find an answer:
typically in the plugin entry point:
virtual unsigned int execute(function *fun)
How do I know which C files I am instrumenting? Can I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:cb797c730dd37ffe88ed0b1d04aec01982feacb5
commit r9-8703-gcb797c730dd37ffe88ed0b1d04aec01982feacb5
Author: Harald Anlauf
On Sat, 2020-06-27 at 13:38 +0200, Marc Glisse wrote:
> On Sat, 27 Jun 2020, Ilya Leoshkevich via Gcc-patches wrote:
>
> > Is there something specific that a compiler user should look out
> > for?
> > For example, here is the kernel code, from which the test was
> > derived:
> >
> > static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #11 from H.J. Lu ---
(In reply to Andi Kleen from comment #9)
> I think the STB_SECONDARY stuff is only needed if ld -r is used, but not for
> ar
Linker won't search archive to resolve weak definition. Since SECONDARY is
between
On June 27, 2020 6:21:12 AM GMT+02:00, Shuai Wang via Gcc
wrote:
>Hello,
>
>I am writing the following statement to make a GIMPLE call:
>
> tree function_fn_type = build_function_type_list(void_type_node,
>void_type_node, integer_type_node, NULL_TREE);
> tree sancov_fndecl =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95826
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95828
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #10 from H.J. Lu ---
(In reply to Andi Kleen from comment #8)
> It works fine without LTO.
>
> Otherwise the Linux kernel wouldn't work. It relies on this behavior for its
> syscalls.
>
[hjl@gnu-cfl-2 pr95928]$ make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:d12079381e25571f2d5f7bb16eaef07ee89b361b
commit r10-8377-gd12079381e25571f2d5f7bb16eaef07ee89b361b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #9 from Andi Kleen ---
I think the STB_SECONDARY stuff is only needed if ld -r is used, but not for ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #8 from Andi Kleen ---
It works fine without LTO.
Otherwise the Linux kernel wouldn't work. It relies on this behavior for its
syscalls.
The test case is extracted from there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e
commit r11-1688-g3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923
--- Comment #1 from Marc Glisse ---
(With one variant I ended up with (a|b)&(a==b), which we don't optimize to a)
We don't optimize !(!a && !b) && !(!a && b) && !(a && !b) (we keep several
branches), but we do optimize if I manually replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
--- Comment #7 from H.J. Lu ---
(In reply to H.J. Lu from comment #6)
> It has nothing to do with LTO. You get the same behavior without LTO.
> This is how weak symbol works.
BTW, this is why I proposed STB_SECONDARY:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929
--- Comment #1 from Marc Glisse ---
Here gcc does optimize the first f to (a != 0) ^ (b != 0). However, for the
second f, it does indeed generate something that looks like the first f before
optimization... The optimization for the first f is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95924
--- Comment #1 from Marc Glisse ---
* If I replace ~a with !a, we manage to do everything with type bool. With ~a,
we don't, we stick to int.
* We don't handle a?b:false the same as a&
* Even for (a | !b) && (!(!a & b) && a) we don't
Ilya Leoshkevich via Gcc-patches writes:
> Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
> and s390x-redhat-linux.
Agree we should do this FWIW, but as a belt-and-braces fix, would it
make sense to define NULL to nullptr in system.h for all hosts?
Currently we have:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95926
--- Comment #1 from Marc Glisse ---
It is different to gcc because in the first case, tmp is used twice, while in
the second case, each a is only used once, and gcc only transforms (a)^b to
b&~a if this is the only use of a Yes, this heuristic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939
--- Comment #2 from David Binderman ---
(In reply to David Binderman from comment #1)
> I'll have a go at reducing the first.
Pointless. It is only a few lines of code anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939
--- Comment #1 from David Binderman ---
Same error in testsuite files gcc.dg/tree-ssa/pr23433.c
and gcc.target/aarch64/sve/reduc_strict_8.c.
I'll have a go at reducing the first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #12 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #10)
> __builtin_trap emits an actual trap into the instruction stream which halts
> the process immediately which is *much* better from a security standpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940
Bug ID: 95940
Summary: sparc64-linux bootstrap with gcc-9.3 broken
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Sat, 27 Jun 2020, Ilya Leoshkevich via Gcc-patches wrote:
Is there something specific that a compiler user should look out for?
For example, here is the kernel code, from which the test was derived:
static inline void atomic_add(int i, atomic_t *v)
{
#ifdef CONFIG_HAVE_MARCH_Z196_FEATURES
Hi Dominieque,
While investigating pr95538, I see several module files that were not
cleaned.
Several were cleaned by a patch I had in my working directory.
However new ones were not cleaned (e.g., gfortran.dg/pr95091.f90) due to
continuation lines.
This is now fixed with the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95939
Bug ID: 95939
Summary: ice with -O3 in compute_live_loop_exits
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938
Bug ID: 95938
Summary: ICE in synthesize_implicit_template_parm, at
cp/parser.c:44077
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937
Bug ID: 95937
Summary: ICE in finish_class_member_access_expr, at
cp/typeck.c:3133
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Hi!
This implements the fallback mentioned in
https://gcc.gnu.org/pipermail/gcc/2020-June/232874.html
Special cases for triangular loops etc. to follow later, also composite
constructs not supported yet (need to check the passing of temporaries around)
and lastprivate might not give the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505
--- Comment #7 from Iain Sandoe ---
(In reply to Michael Bruck from comment #6)
> Is it possible to point the user to include here like other parts of
> gcc do for standard library functions?
> i.e. name-lookup.c missing_std_header
That's also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505
--- Comment #6 from Michael Bruck ---
Is it possible to point the user to include here like other parts of gcc
do for standard library functions?
i.e. name-lookup.c missing_std_header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:37995960984ea346dd9d168d332cd6f7adf0
commit r11-1685-g37995960984ea346dd9d168d332cd6f7adf0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
On June 27, 2020 10:58:56 AM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>For lp64 targets and int off ... ptr[off + 1]
>is lowered in pointer_sum to *(ptr + ((sizetype) off + (sizetype) 1)).
>That is fine when signed integer wrapping is undefined (and is not done
>already if off has unsigned type),
Hi
This adds a diagnostic only,
tested on x86_64-linux,darwin powerpc64-linux,
applied to master as obvious,
thanks
Iain
-
If the user provides operator new and that is noexcept, this
implies that it can fail with a null return. At that point, we expect
to be able to call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95736
--- Comment #3 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:daaed0199ee57013ae011421a7e90b7bdd295373
commit r11-1684-gdaaed0199ee57013ae011421a7e90b7bdd295373
Author: Iain Sandoe
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95936
Bug ID: 95936
Summary: ICE in splice_late_return_type, at cp/pt.c:29114
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Hi!
For lp64 targets and int off ... ptr[off + 1]
is lowered in pointer_sum to *(ptr + ((sizetype) off + (sizetype) 1)).
That is fine when signed integer wrapping is undefined (and is not done
already if off has unsigned type), but changes behavior for -fwrapv, where
overflow is well defined.
Hi Harald,
here's another NULL pointer dereference on invalid code.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports where appropriate?
OK.
(Also would have classified as obvious and simple, I think).
Thanks for the patch
Regards
Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
Romain Geissler changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi Mark,
Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec.
A warning that the lower bound is being used for a mission dimension
is output unless suppressed by using -Wno-missing-index.
This is... seriously problematic. I forsee all sorts of not-so-funny
interactions with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #2 from Thomas Koenig ---
The problem is in the scans; the code runs fine.
Does anybody have the dejagnu-fu to run the scans only on little-endian
systems?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
Jonathan Wakely changed:
What|Removed |Added
CC|jwakely at redhat dot com |
--- Comment #7 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95934
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95934
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #2 from Andreas Schwab ---
The m68k backend generally does all floating point arithmethic in extended
precision for !TARGET_68040, setting FLT_EVAL_METHOD to 2.
88 matches
Mail list logo
