[Bug preprocessor/83492] New: [7 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be

2017-12-19 Thread michael at weiser dot dinsnail.net
: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: michael at weiser dot dinsnail.net Target Milestone: --- Created attachment 42920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42920&action=edit patch

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

2016-06-08 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372 Michael Weiser changed: What|Removed |Added CC||michael at weiser dot dinsnail.net

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

2016-06-08 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71053 Michael Weiser changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

2016-06-08 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71053 --- Comment #5 from Michael Weiser --- I think it's well estabilished and verified by now that this is an avr-target-specific regression (which I think is what Richard meant). Is anybody looking into this? Is more information needed? Can I do any

[Bug target/71053] [6/7 Regression] Volatile read optimized into endless loop

2016-05-11 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71053 --- Comment #2 from Michael Weiser --- Also happens with trunk r236113: # ~/bin/gcc-trunk-20160511-avr/bin/avr-g++ -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -Os t.c -o t.S -S -v Using built-in specs. Reading s

[Bug c++/71053] New: [6.1 regression] Volatile read optimized into endless loop

2016-05-10 Thread michael at weiser dot dinsnail.net
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michael at weiser dot dinsnail.net Target Milestone: --- avr-g++ of vanilla gcc 6.1.0 called with avr-g++ -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -Os t.c

[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

2015-09-08 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #6 from Michael Weiser --- Right. Thanks for the quick responses!

[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

2015-09-08 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #4 from Michael Weiser --- Okay, I can see this is headed for a WONTFIX. Can you please answer my questions before we chuck it? 1. How hard would it be or is there even some effort/patch to make gcc only compile in support for a sele

[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

2015-09-08 Thread michael at weiser dot dinsnail.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #2 from Michael Weiser --- (In reply to Andrew Pinski from comment #1) > >memory-constrained box > Those don't exist any more. Memory is cheap. Yeah they do. Please read: > embedded arm box And the RAM chips are soldered on.

[Bug c/67492] New: insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

2015-09-08 Thread michael at weiser dot dinsnail.net
Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: michael at weiser dot dinsnail.net Target Milestone: --- Created attachment 36305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36305&acti