https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085
--- Comment #4 from Johel Ernesto Guerrero Peña ---
> GCC shouldn't even be trying to resolve `foo<42>()` until `G` has been
> instantiated.
That's right. I came across this bug report when reporting such an issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085
--- Comment #3 from Arthur O'Dwyer ---
Re comment 2: My original test code was "invalid-code", but here's one I
believe to be "valid-code" in C++20.
// https://godbolt.org/z/dqcWeq
template class A>
struct G {
template using B = A;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97477
Bug ID: 97477
Summary: g++ doesn't accept __restrict keyword inside array
function parameter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97476
Bug ID: 97476
Summary: Use of NTTP placeholder checked for CTAD before
instantiation
Product: gcc
Version: 11.0
URL: https://godbolt.org/z/ocWhn8
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
CC||johelegp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
Bug ID: 97475
Summary: An unnamed class with a typedef name for linkage
purposes having a method.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-10-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
--- Comment #1 from Andrew Pinski ---
This feels like an use after something goes out of scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Bug ID: 97474
Summary: Regression: optimization produces wrong code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449
--- Comment #3 from CVS Commits ---
The master branch has been updated by Ville Voutilainen :
https://gcc.gnu.org/g:1f65bf2aa65609c0cd88af1b83191d37d6729f46
commit r11-4024-g1f65bf2aa65609c0cd88af1b83191d37d6729f46
Author: Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97473
Bug ID: 97473
Summary: Spilled function parameters not aligned properly on
multiple non-x86 targets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94161
--- Comment #1 from Marek Polacek ---
This compiles since r11-86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97472
Bug ID: 97472
Summary: Another EVRP problem
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294
Maciej W. Rozycki changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97470
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #8 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #1)
> See https://gcc.gnu.org/bugs.html, you haven't provided either preprocessed
> source, nor gcc command line options.
> inline keyword itself is not a guarantee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #7 from Christophe Leroy ---
With get_order(), that's even worse: there are instances of it that are never
called:
c000f94c :
c005a7ac :
c005a9c4: 4b ff fd e9 bl c005a7ac
c005ab38: 4b ff fc 75 bl
mpiler returned: 1
GCC -v output :
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20201017/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
--- Comment #5 from Daniel Santos ---
Created attachment 49393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49393=edit
Patch for musl compatibility
The root problem is that musl defines off64_t and loff_t as preprocessor
macros. These
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97470
Bug ID: 97470
Summary: ICE when using aggregate initialization of a
particular layout with non trivial type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156
--- Comment #3 from Michał Urbański ---
I confirm that attached test files reproduce the bug for me - same error
messages. Thanks Pavel, never expeced someone to manage to reproduce this
problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380
--- Comment #4 from federico ---
I've attached another program that perhaps highlights the problem better.
Even just *accessing* a polymorphic array with an array causes wrong output
with gfortran 9.2.0:
The attached program sends elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380
--- Comment #3 from federico ---
Created attachment 49392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49392=edit
Other test program highlights issue in accessing polymorphic arrays with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
Daniel Santos changed:
What|Removed |Added
CC||daniel.santos at pobox dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469
--- Comment #1 from Sergei Trofimovich ---
Reading
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
it's not very clear if __attribute__((__target__("..."))) should throw away all
existing -m*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469
Bug ID: 97469
Summary: __attribute__ ((__target__ ("..."))) resets -mcmodel=
values, breaks grub compilation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #4 from Thomas Koenig ---
Here's a complete program for benchmarks on x86_64, using Jakub's
functions (so they are indeed correct):
#include
#include
#include
#include
#include
#include
unsigned r3_128u_v2 (__uint128_t n)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156
Павел Тюнин changed:
What|Removed |Added
CC||pavel51tunin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97468
Bug ID: 97468
Summary: gcc crashes when using __may_alias__ attribute
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
compression algorithms: zlib
gcc version 11.0.0 20201017 (experimental) [master revision
56e4eee935c:ba026021eaa:f476a9fe912132abf06c2832a1bb9abe6c1a1bb1] (GCC)
[595] %
[595] % gcctk -O1 small.c
[596] %
[596] % gcctk -Os small.c
during GIMPLE pass: evrp
small.c: In function ‘main’:
small.c:13:1: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452
--- Comment #3 from Iain Sandoe ---
(In reply to David Ledger from comment #2)
> I'm happy to use this thread for the issue, I can just repost my link to the
> same issue here.
>
> My reporting of the issue is here, but Lewis Bakers example is
34 matches
Mail list logo
