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 W
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=92484
Romain Geissler changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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=95674
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
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: S
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=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=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
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: ice-on-invalid-co
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: fortran
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: bootst
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
Regardle
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=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=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&b is only used once, and gcc only transforms (a&b)^b to
b&~a if this is the only use of a&b. Yes, this heuri
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&&b.
* Even for (a | !b) && (!(!a & b) && a) we don't complet
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 from
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 pro
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/legac
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&b)
We don't optimize !(!a && !b) && !(!a && b) && !(a && !b) (we keep several
branches), but we do optimize if I manually replace en
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: Sa
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=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=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
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95828
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
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
/usr/gcc-9.3.1-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95826
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
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 WEAK
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
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #3 from David Edelsohn ---
{ target { le } }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95936
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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 must
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 --whole-arc
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 differ
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 d
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 algorithm
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 e.
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=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, ppa
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: nor
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=95938
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937
Marek Polacek changed:
What|Removed |Added
Keywords||error-recovery
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #30 fr
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=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 DSPEmitter::M_SDSP_r_s
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=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 &str);
void string_vappendf (std::string &str, const char
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 m
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
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=95880
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957
prop_design at protonmail dot com changed:
What|Removed |Added
CC||prop_design at protonm
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=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=77510
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
Last reconf
60 matches
Mail list logo
