[Bug c++/91224] New: -Wsequence-point claims a defined value is undefined

2019-07-22 Thread john.boyer at tutanota dot com
Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- The following code: int value = (value = 5, ++value); Will produce the following warning: : In function 'void __static_initialization_and_destruction_0(int

[Bug c++/91760] New: Trailing return type breaks final specifier

2019-09-12 Thread john.boyer at tutanota dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- The following code: struct final; struct test { virtual auto foo() -> int final; }; Generates this error: error: two or more data types in declaration of 't

[Bug c++/91950] New: -Wreturn-type false positive due to CWG 1766

2019-10-01 Thread john.boyer at tutanota dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- Given the following code: enum class foo { bar, baz, }; int func(foo f) { switch (f) { case foo::bar: return 5; case foo::baz

[Bug c++/91950] -Wreturn-type false positive due to CWG 1766

2019-10-01 Thread john.boyer at tutanota dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91950 --- Comment #3 from John Boyer --- Actually, I believe Jonathan is correct. I misread the CWG. The "range" of an enum class has nothing to do with how many enumerators it has.

[Bug c++/89859] New: Addition of __restrict generates worse assembly

2019-03-27 Thread john.boyer at tutanota dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- With the following function signature (that is within a struct): void compute(int *__restrict x) { /* ... */ } Adding an additional __restrict for the this pointer as

[Bug middle-end/89859] Addition of __restrict generates worse assembly

2019-03-27 Thread john.boyer at tutanota dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89859 --- Comment #2 from John Boyer --- (In reply to Andrew Pinski from comment #1) > _ZN4test7computeEPi.isra.0: // non-restrict > .LFB2: > .cfi_startproc > ldr x3, [x0] > mov w4, 99 > ldr w2, [x0, 8] >

[Bug middle-end/89859] Addition of __restrict generates worse assembly

2019-03-27 Thread john.boyer at tutanota dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89859 --- Comment #4 from John Boyer --- (In reply to Andrew Pinski from comment #3) > (In reply to John Boyer from comment #2) > > Hey, what did you use to obtain that assembly? Also, is there anyway to > > display this in godbolt instead of the CISC

[Bug c++/89889] New: worse code compared to clang with alloca()

2019-03-29 Thread john.boyer at tutanota dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- Example: https://godbolt.org/z/MLZAA6. Why is the push/lea/leave necessary? Shouldn't modifying the stack pointer be enough?

[Bug c++/89949] New: Internal compiler error with lambda as template argument

2019-04-03 Thread john.boyer at tutanota dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- Since C++20 a template parameter type can be any LiteralType that has strong structural equality. Lambdas are classified as a LiteralType

[Bug c++/90284] New: -Wunused-value points to the wrong expression

2019-04-29 Thread john.boyer at tutanota dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- In the following code https://godbolt.org/z/0jTk3e, GCC warns about the second operand of a conditional expression having no effect, even though the second operand is

[Bug c++/89949] Internal compiler error with lambda as template argument

2019-04-29 Thread john.boyer at tutanota dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89949 John Boyer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/90304] New: -O3 vectorization gets worse when code is moved into main()

2019-05-01 Thread john.boyer at tutanota dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- The following code will get much better assembly if it is not in main(): for (int i = 0; i < 1024; ++i) result[i] = first[i] * sec