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
Snapshot gcc-10-20201017 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20201017/
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=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.
On Fri, Oct 2, 2020 at 6:21 AM H.J. Lu wrote:
>
> On Wed, Sep 16, 2020 at 10:07 PM H.J. Lu wrote:
> >
> > On Wed, Aug 19, 2020 at 6:09 AM H.J. Lu wrote:
> > >
> > > On Tue, May 19, 2020 at 5:14 AM H.J. Lu wrote:
> > > >
> > > > On Tue, May 19, 2020 at 1:48 AM Uros Bizjak wrote:
> > > > >
> >
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
On Fri, 16 Oct 2020 at 13:02, Jonathan Wakely wrote:
>
> On 16/10/20 10:26 +0300, Ville Voutilainen via Libstdc++ wrote:
> >Tested on Linux-PPC64. I haven't tested this with clang yet,
> >Jonathan, can you help with that? The previous implementation
> >indeed made an if-constexpr branch invalid
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|
On Sat, 17 Oct 2020 at 20:30, Stephan Bergmann wrote:
> Clang (with -std=c++17/20) now complains about
>
> > include/c++/11.0.0/variant:1032:10: error: no matching constructor for
> > initialization of 'std::__nonesuch'
> > return __nonesuch{};
> >^
On 08/10/2020 16:27, Jonathan Wakely via Gcc-patches wrote:
On 05/10/20 22:35 +0300, Ville Voutilainen via Libstdc++ wrote:
On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
wrote:
The patch is borked, doesn't pass tests, fixing...
Unborked, ok for trunk if full testsuite passes?
Assuming it
Early *ping*.
> Gesendet: Sonntag, 11. Oktober 2020 um 21:09 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR libfortran/97063 - Wrong result for vector (step size is
> negative) * matrix
>
> PR libfortran/97063 - Wrong result for vector (step size is negative)
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
I eventually would like to propose the following resolution.
For multi-key containers I kept the same resolution build the node first
and compute has code from the node key.
For unique-key ones I change behavior when I can't find out hash functor
argument type. I am rather using the iterator
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
---
On Fri, Oct 16, 2020 at 11:29 AM H.J. Lu wrote:
>
> On Fri, Oct 16, 2020 at 11:17 AM Jakub Jelinek wrote:
> >
> > On Fri, Oct 16, 2020 at 10:58:34AM -0700, H.J. Lu wrote:
> > > Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
> > > if there is an extra assembly input file
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)
{
On October 16, 2020 8:46:39 PM GMT+02:00, Martin Jambor wrote:
>Hi,
>
>in PR 97456, IPA-SRA triggers a bug in tree-complex.c where it
>converts:
>
>
> a$_M_value_21 = COMPLEX_EXPR ;
>
>(where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set,
>which is why it only happens with
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
43 matches
Mail list logo
