https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86652
--- Comment #2 from Andrew Pinski ---
This seems like the const is applying to the function (not the function type
that it is returning).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86652
--- Comment #1 from zhonghao at pku dot org.cn ---
A related code sample:
class C { public: template int (*f())() const; };
int foo(C c) { return (*c.f())(); }
The messages from clang++:
error: pointer to function type cannot have 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86652
Bug ID: 86652
Summary: pointer to function type cannot have 'const' qualifier
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Eric Gallager changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #2 from The Written Word
---
(In reply to The Written Word from comment #1)
> I get a similar error with 8.1.0.
And with 5.5.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86448
kelvin at gcc dot gnu.org changed:
What|Removed |Added
CC||kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79501
eracpp at eml dot cc changed:
What|Removed |Added
CC||eracpp at eml dot cc
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #44 from Qing Zhao ---
> (In reply to wilco from comment #43)
will provide a simple patch for this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651
Bug ID: 86651
Summary: lto-wrapper.exe: fatal error:
simple_object_copy_lto_debug_sections not implemented:
Invalid argument
Product: gcc
Version: 8.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #11 from Qing Zhao ---
> to reply: Comment #10 from Martin Sebor —
thanks for the details.
However, I do not feel comfortable for the compiler to change an undefined
buggy code.
I think that it’s better to let the user to correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86649
Rainer Orth changed:
What|Removed |Added
Target|powerpc64*-*-* |powerpc*-*-*, i?86-*-*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86396
--- Comment #2 from joseph at codesourcery dot com ---
You can't fold atof ("3.14") with -frounding-math because the result
depends on the rounding mode, or with -ftrapping-math (which is the
default) because it should raise "inexact" (there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
--- Comment #11 from Jonathan Wakely ---
Author: redi
Date: Mon Jul 23 19:40:28 2018
New Revision: 262935
URL: https://gcc.gnu.org/viewcvs?rev=262935=gcc=rev
Log:
PR libstdc++/70940 optimize pmr::resource_adaptor for allocators using malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86650
Bug ID: 86650
Summary: -Warray-bounds missing inlining context
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #10 from Martin Sebor ---
The code is undefined so the return value doesn't really matter but
conservatively, I think any non-zero value would work. What to do is a
judgment call between letting the library call return some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86649
Bug ID: 86649
Summary: [9 regression] g++.dg/tree-ssa/pr19476-1.C fails
starting with r262928
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86648
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86648
Bug ID: 86648
Summary: [9 Regression] ICE on class template argument
deduction
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86647
Bug ID: 86647
Summary: Test on constant expression (unsigned) -1 < 0 triggers
a spurious -Wtype-limits warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224
--- Comment #13 from Jeffrey A. Law ---
Agreed. I don't see a lot of value in backporting this fix to the release
branches. One could argue that decision means this should move to CLOSED as
it's been fixed for gcc-8 and the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86646
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591
Carl Love changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86591
--- Comment #2 from Carl Love ---
Author: carll
Date: Mon Jul 23 16:16:41 2018
New Revision: 262934
URL: https://gcc.gnu.org/viewcvs?rev=262934=gcc=rev
Log:
gcc/testsuite/ChangeLog:
2018-07-23 Carl Love
PR 86591
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
--- Comment #7 from Chris Elrod ---
(In reply to Chris Elrod from comment #6)
> However, for column 23 (2944/128 = 23) with -O3 and column 25 for -O2 of the
> 32 columns of A
Correction: it was the 16x13 version that used stack data after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86516
--- Comment #2 from Paul Gotch ---
I can reproduce this at will with GCC 7.3 it does not reproduce with GCC 8
// Compile with g++ -c -Wextra -Wall -Werror -O3 test.cpp
#include
class Foo
{
public:
Foo() {}
virtual ~Foo()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #9 from Qing Zhao ---
> --- Comment #8 from Martin Sebor ---
> FWIW, it would be safer and more deterministic to fold these invalid calls to
> some non-zero value that it is to emit the invalid library call.
could you please provide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
--- Comment #6 from Chris Elrod ---
(In reply to Richard Biener from comment #3)
> If you see spilling on the manually unrolled loop register pressure is
> somehow an issue.
In the matmul kernel:
D = A * X
where D is 16x14, A is 16xN, and X is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
--- Comment #3 from Georg-Johann Lay ---
As a work-around -fno-tree-ter appears to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86636
--- Comment #2 from David Malcolm ---
Thanks for filing this.
Segfault happens here in optrecord_json_writer::location_to_json:
206 obj->set ("file", new json::string (LOCATION_FILE (loc)));
due to a NULL value for LOCATION_FILE (loc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
Georg-Johann Lay changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
--- Comment #5 from Chris Elrod ---
Created attachment 44424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44424=edit
Smaller avx512 kernel that still spills into the stack
This generated 18 total `vmovapd` (I think there'd ideally be 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
--- Comment #4 from Chris Elrod ---
Created attachment 44423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44423=edit
8x16 * 16x6 kernel for avx2.
Here is a scaled down version to reproduce most of the the problem for
avx2-capable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #4 from Michael Veksler ---
It is interesting to check the impact on numerical C++ benchmarks.
Fortran has a conceptual restrict on all its parameter arrays,
since aliasing is not allowed.
void f(int * __restrict__ v1, int *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #43 from Wilco ---
(In reply to qinzhao from comment #42)
> just checked in the patch for fixing the unsigned char issue as:
> https://gcc.gnu.org/viewcvs/gcc?view=revision=262907
That looks it is using unsigned char accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86646
Bug ID: 86646
Summary: Special member function 'cannot be defaulted' if type
alias is used
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
--- Comment #8 from Bernd Edlinger ---
Author: edlinger
Date: Mon Jul 23 13:23:51 2018
New Revision: 262933
URL: https://gcc.gnu.org/viewcvs?rev=262933=gcc=rev
Log:
gcc:
2018-07-23 Bernd Edlinger
PR c/86617
* genmatch.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
--- Comment #1 from Senthil Kumar Selvaraj ---
Created attachment 44422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44422=edit
pr86635.patch
Looks like ud_dce removes the insn that sets reg:SF r22 because the insn says
r22 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86645
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86645
Bug ID: 86645
Summary: [9 Regression] UBSAN error: tree-cfg.c:7874:26:
runtime error: load of value 4293224825, which is not
a valid value for type 'dump_flag'
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
--- Comment #4 from Steinar H. Gunderson ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Steinar H. Gunderson from comment #0)
> > Same issue with 4.9, so no regression. Clang has the same issue.
>
> That should have been your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
Jonathan Wakely changed:
What|Removed |Added
CC||eric at efcs dot ca
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77923
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
--- Comment #3 from Jonathan Wakely ---
(In reply to Steinar H. Gunderson from comment #0)
> Same issue with 4.9, so no regression. Clang has the same issue.
That should have been your first clue that the problem is at your end, not in
both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630
--- Comment #3 from The Written Word
---
(In reply to Richard Biener from comment #2)
> GCC assumes that inttypes.h contains PRIx64
It does. gcc/system.h has:
/* Define this so that inttypes.h defines the PRI?64 macros even
when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86513
Jonathan Wakely changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection,|
|needs-reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644
Bug ID: 86644
Summary: [9 Regression] UBSAN error:
tree-vect-patterns.c:225:17: runtime error: shift
exponent 64 is too large for 32-bit type 'int'
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #6 from rguenther at suse dot de ---
On Mon, 23 Jul 2018, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
>
> --- Comment #5 from Marc Glisse ---
> (In reply to Richard Biener from comment #4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
Steinar H. Gunderson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643
--- Comment #1 from Tobias Burnus ---
Culprit is r262474 - "P0935R0 Eradicating unnecessarily explicit default
constructors"
Looking closer at the example, it doesn't use std::basic_ostringstream as
advertised but:
std::ostringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #3 from rguenther at suse dot de ---
On Mon, 23 Jul 2018, mickey.veksler at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
>
> --- Comment #2 from Michael Veksler ---
> >> type-based alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092
Eric Gallager changed:
What|Removed |Added
CC||zfefm at gmx dot de
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86639
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86605
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86547
--- Comment #2 from Ilya Leoshkevich ---
I dug a bit deeper and found that this used to compile without errors on
gcc-4_8_5-release.
Bisect points to s390-specific commit 7b1bda1c, which first appeared in
gcc-4_9_0-release:
2013-06-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> Yeah, generally we can't associate because (x*y)*z may not overflow because
> x == 0 but x*(y*z) may because y*z overflows.
We can do it
- in the wrapping case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #2 from Michael Veksler ---
>> type-based alias analysis doesn't distinguish between int[2] and int[3].
Is it just the way GCC implements type-based alias analysis,
or is it defined that way in the C and C++ standards?
I suspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86643
Bug ID: 86643
Summary: [9 Regression] basic_ostringstream usage leads
to:undefined reference to
`std::__cxx11::basic_stringstream
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86638
--- Comment #3 from Tom de Vries ---
(In reply to Richard Biener from comment #2)
> Hmm, it sounds like DCE/DSE should insert
>
> # DEBUG x$a => x$a_11
>
> kind debug stmts. IIRC SRA does more than that, adding DECL_DEBUG_EXPRs
> with magic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
--- Comment #7 from Bernd Edlinger ---
Yes. Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
--- Comment #6 from rguenther at suse dot de ---
On Mon, 23 Jul 2018, bernd.edlinger at hotmail dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
>
> --- Comment #5 from Bernd Edlinger ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77923
--- Comment #1 from Eric Fiselier ---
Ping. I keep hitting this more and more.
GCC seems to be warning because the declaration includes the CXX scope
specifier "::foo". Removing the "::" seems to work. However, removing the "::"
causes the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642
Bug ID: 86642
Summary: Spurious return type warning with enable_if
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86641
Bug ID: 86641
Summary: Regression: non-ODR used auto class data members fail
to deduce.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86640
Bug ID: 86640
Summary: [8/9 regression] ICE in combine
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
--- Comment #5 from Bernd Edlinger ---
(In reply to Richard Biener from comment #3)
> but I guess that doesn't work because the counting is missing. OTOH
> two same SAVE_EXPRs () are not operand_equal_p but SAVE_EXPRs have
> TREE_SIDE_EFFECTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86620
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
--- Comment #4 from Bernd Edlinger ---
this comment in match.pd made me look at operand_equal_p:
/* Simplify x - x.
This is unsafe for certain floats even in non-IEEE formats.
In IEEE, it is unsafe because it does wrong for NaNs.
Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86638
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86626
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108
Richard Biener changed:
What|Removed |Added
CC||ketan.surender at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86639
Bug ID: 86639
Summary: building gcc from source fails with Mac OS 10.9
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630
--- Comment #2 from Richard Biener ---
GCC assumes that inttypes.h contains PRIx64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 121 matches
Mail list logo