[Bug web/96996] New: Missed optimzation for constant members of non-constant objects

Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- When a global class instance is const and initialized using constant arguments to a constexpr constructor, any member references are

[Bug c++/96996] Missed optimzation for constant members of non-constant objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #2 from Matthijs Kooijman --- > Replacing non_constant_test with a new object is possible, and allowed. But > the name "non_constant_test" cannot be used to refer to the new object, so > any calls to non_constant_ref() after the obj

[Bug c++/96996] Missed optimzation for constant members of non-constant objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #5 from Matthijs Kooijman --- > But isn't there const_cast<> to change the value of p? Yes, that makes it possible to write to a const object, but actually doing so is undefined behavior (see [dcl.type.cv] I quoted above). The spec

[Bug tree-optimization/80794] constant objects can be assumed to be immutable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794 --- Comment #10 from Matthijs Kooijman --- Also note that pr96996, that was marked as a duplicate of this report, talks about a notable subcase of the case presented in this report. While this report talks about constant complete objects (e.g. a

[Bug preprocessor/80753] __has_include and __has_include_next taints subsequent I/O errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug preprocessor/80753] __has_include and __has_include_next taints subsequent I/O errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753 --- Comment #4 from Matthijs Kooijman --- I looked a bit at the source, and it seems the the problem is (not surprisingly) that `__has_include` causes the header filename to be put into the cache, and an error message is only generated when the e

[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug target/92693] New: Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- Gcc defines a number of macros for types, which are used by stdint.h to define the corresponding typedefs. In particular, I'm lo

[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92693 --- Comment #3 from Matthijs Kooijman --- > I don't see why you should expect that, there's nothing in the standards > suggesting it should be the case. This is true, current behaviour is standards-compliant AFAICS. However, I expect that becau

[Bug tree-optimization/93359] New: Miscompile (loop check omitted) in function with missing return statement

: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- I came across a miscompile, where a missing return statement in a function resulted in a simple for loop never

[Bug target/56533] New: Linker problem on avr with lto and main function inside archive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Bug #: 56533 Summary: Linker problem on avr with lto and main function inside archive Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCON

[Bug target/56533] Linker problem on avr with lto and main function inside archive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 --- Comment #2 from Matthijs Kooijman 2013-03-05 12:55:47 UTC --- + /usr/bin/avr-gcc -v -mmcu=atmega328p -Os -flto -fwhole-program realmain.o main.a Using built-in specs. COLLECT_GCC=/usr/bin/avr-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/

[Bug target/56533] Linker problem on avr with lto and main function inside archive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 --- Comment #3 from Matthijs Kooijman 2013-03-05 13:06:18 UTC --- Seems I made a wrong observation in my original report: When I link main.o instead of main.a, the problem does _not_ go away. In fact, I can remove a few more flags then, wh

[Bug target/56533] Linker problem on avr with lto and main function inside archive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Matthijs Kooijman changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resoluti

[Bug target/56533] Linker problem on avr with lto and main function inside archive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56533 Matthijs Kooijman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug rtl-optimization/51447] [4.7 Regression] global register variable definition incorrectly removed as dead code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment

[Bug c++/78609] invalid member's visibility detection in constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78609 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug preprocessor/51259] no escape on control characters on linemarker lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51259 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745 --- Comment #14 from Matthijs Kooijman --- Thanks for the additional explanations!

[Bug other/60145] [AVR] Suboptimal code for byte order shuffling using shift and or

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145 --- Comment #3 from Matthijs Kooijman --- Thanks for digging into this :-D I suppose you meant https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242907 instead of the commit you linked (which is also nice btw, I noticed that extra sbiw in s

[Bug target/77326] [avr] Invalid optimization omits comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77326 --- Comment #6 from Matthijs Kooijman --- Thanks!

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 --- Comment #3 from Matthijs Kooijman --- Hmm, I don't think the gcc sources support that. AFAICT, they attempt to just find the shortest approach, without caring for speed. For example, look at avr.c, around line 1265, where it says:

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 --- Comment #5 from Matthijs Kooijman --- Ah, then the comments are a bit misleading, yes. Wouldn't it make sense to put this decision outside of avr_sp_immediate_operand, in the same area where the decision between the two options is made? Might

[Bug other/60145] New: [AVR] Suboptimal code for byte order shuffling using shift and or

Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl (Not sure what the component should be, just selected "other" for now) Using shifts and bitwise-or to compose multiple bytes into a bigger integer

[Bug target/60300] New: [avr] Suboptimal stack pointer manipulation for frame setup

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl For setting up the stack frame in the function prologue, gcc chooses between either directly manipulation the stack pointer with "rcall ." and "push&qu

[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 --- Comment #1 from Matthijs Kooijman --- I noticed I didn't use -O in the output I pasted, but I just confirmed that the results are the same with -Os and -O3.

[Bug tree-optimization/45791] Missed devirtualization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment

[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 --- Comment #9 from Matthijs Kooijman --- Created attachment 36499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36499&action=edit Second testcase, needs -Os to break

[Bug target/66511] New: [avr] whole-byte shifts not optimized away for uint64_t

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- When doing whole-byte shifts, gcc usually optimizes away the shifts and ends up moving data between registers instead. However, it seems this

[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 --- Comment #2 from Matthijs Kooijman --- So, IIUC, this is quite hard to fix? Either you use lib functions, which prevents the optimizer from just relabeling or coyping registers to apply shifting, or you don't and then more complex operations w

[Bug target/77326] New: [avr] Invalid optimization using varargs and a weak function

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- Created attachment 39483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39483&action=edit Preprocessed source generated by

[Bug target/77326] [avr] Invalid optimization using varargs and a weak function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77326 --- Comment #1 from Matthijs Kooijman --- The original reporter just added a comment that this does not occur anymore in gcc 6.1.0, though I haven't got anything newer than 5.1 available here to check.

[Bug target/100219] New: Arm/Cortex-M: Suboptimal code returning unaligned struct with non-empty stack frame

Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- Consider the program below, which deals with functions returning a struct of two members, either using a literal

[Bug tree-optimization/97997] New: Missed optimization: Multiply of extended integer cannot overflow

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- When an integer is extended and then multiplied by another integer of the original size, the resulting multiplication can

[Bug tree-optimization/97997] Missed optimization: Multiply of extended integer cannot overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997 --- Comment #5 from Matthijs Kooijman --- Awesome, thanks for the quick response and fix!

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #6 from Matthijs Kooijman --- Ah, IIUC your patch does not treat -fno-exceptions specially, but just adds a shortcut for the nothrow new version to skip calling regular new version if it has not been replaced. In a normal build, that

[Bug libstdc++/106477] New: With -fno-exception operator new(nothrow) aborts instead of returning null

: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: matthijs at stdin dot nl Target Milestone: --- The nothrow version of operator new is intended to return null on allocation failure. However, when libstdc++ is

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #1 from Matthijs Kooijman --- Created attachment 53382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53382&action=edit Testcase - main code

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #2 from Matthijs Kooijman --- Created attachment 53383 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53383&action=edit Testcase - startup code

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #3 from Matthijs Kooijman --- Created attachment 53384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53384&action=edit Testcase - linker script for ATSAMD21G18 (Arduino zero)

[Bug libstdc++/68210] nothrow operator fails to call default new

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl

[Bug middle-end/26724] __builtin_constant_p fails to recognise function with constant return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl