[Bug tree-optimization/57755] Improve fold_binary_op_with_conditional_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57755 --- Comment #3 from Marc Glisse --- (In reply to Eric Gallager from comment #2) > (In reply to Marc Glisse from comment #1) > > This patch seems to help for the testcases in this PR and passes the > > testsuite (with one XPASS). I'll add some testcases and post it to > > gcc-patches later. > > ...how much later? (It's been 5 years...) It was posted on the very same day: https://gcc.gnu.org/ml/gcc-patches/2013-06/msg01624.html To find the replies (not the same month), it seems easier to have a look at https://patchwork.ozlabs.org/patch/255719/
[Bug c++/80496] missing diagnostic regarding noreturn mismatch in function pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80496 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug tree-optimization/42970] Missed unused function return value elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970 Eric Gallager changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Assignee|jamborm at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > Should Martin Jambor remain the assignee for this? No reply; moving from assignee to cc
[Bug tree-optimization/36281] vector code is not parallelized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36281
Eric Gallager changed:
What|Removed |Added
Blocks||53947
Assignee|spop at gcc dot gnu.org|unassigned at gcc dot
gnu.org
--- Comment #5 from Eric Gallager ---
(In reply to Eric Gallager from comment #4)
> (In reply to Sebastian Pop from comment #0)
> > The testcase of PR36181 should be parallelized after being vectorized.
> >
> > /* { dg-do compile } */
> > /* { dg-options "-O3 -ftree-parallelize-loops=2" } */
> >
> > int foo ()
> > {
> > int i, sum = 0, data[1024];
> >
> > for(i = 0; i<1024; i++)
> > sum += data[i];
> >
> > return sum;
> > }
> >
> > The fix for PR36181 was to disable the parallelization of a loop when
> > one of the phi nodes had a vector type. This testcase should also be
> > parallelized. See also the comments from the fix for PR36181:
> > http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01217.html
>
> Are you still working on this?
Guess not.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 Eric Gallager changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Richard Biener from comment #3) > > No, it's now possible to implement this optimization (but yes, nobody has > > done so sofar). It's on my TODO (with tons of other stuff, of course). > > > > Is that still the case? > Guess not.
[Bug target/54640] arm_adjust_block_mem: signed/unsigned comparison [-Werror=sign-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54640 Eric Gallager changed: What|Removed |Added Keywords||build, diagnostic CC||rearnsha at gcc dot gnu.org Assignee|rearnsha at gcc dot gnu.org|unassigned at gcc dot gnu.org Summary|arm_adjust_block_mem: |arm_adjust_block_mem: |signed/unsigned comparison |signed/unsigned comparison ||[-Werror=sign-compare] --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > (In reply to Jorn Wolfgang Rennecke from comment #2) > > I have reverted my patch because of an objection by Richard Earnshaw > > Is he still working on this? I guess not; moving from assignee to cc
[Bug rtl-optimization/11261] Weak code generated for JPEG compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261 Eric Gallager changed: What|Removed |Added CC||joern.rennecke at superh dot com Assignee|joern.rennecke at superh dot com |unassigned at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to Jorn Wolfgang Rennecke from comment #5) > > (In reply to comment #4) > > > This bug hasn't been modified in more than 18 months. What is the > > > current status of this bug? And is this not really a target specific > > > issue for SH with its silly r0, or can other targets also have this > > > problem?? > > > > The sh-elf libraries won't build because of PR 22258. > > Because we have sched1 enabled, the scheduling problem is currently > > non-existant; the values that are needed in r0 can be calculated > > in a different general purpose register, and moved into r0 in time for the > > indexed addressing. > > However, because of sched1 we now have too high register pressure for other > > benchmarks. Vlad proposed at the summit to postpone scheduling after reload > > to fix the register pressure issue. Unless his porposed register renaming > > schedme can handle this case and snarf the required registers too, we'll > > go back to square one. > > Are you still working on this? Guess not, moving from assignee to cc
[Bug c/64743] minor issue with the location of -Wlong-long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64743 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > (In reply to Eric Gallager from comment #2) > > Eh, I think gcc's current behavior makes sense, the 2nd long is the one that > > makes it a long long rather than just a long, since people type left to > > right. When typing in order, when you've typed just the 1st long, it won't > > have triggered -Wlong-long yet. > > If anyone still wants to change this, I'm putting this bug in WAITING for 3 > months; if there's no reply after that I'll close it as WONTFIX. No reply; closing as WONTFIX
[Bug c/87435] "Duplicate const" warning NOT emitted from typedef in -std=c90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87435 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80868, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53075, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66505 --- Comment #3 from Eric Gallager --- Might also be related to bug 53075 and/or bug 66505
[Bug c++/87407] Enhance -Wunused-function to handle also inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87407 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- (In reply to Andrew Pinski from comment #5) > Test the warning out on clang from a header file and you will see you get > the warning in the header too. As I said I actually ran into this while > working on the vpp project and cursed clang for having this warning turned > on. I think something similar happened with the gdb project; I'll try to find it later...
[Bug c++/87409] Implement -Wunused-private-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87409 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #6 from Eric Gallager --- Dup of bug 72789 *** This bug has been marked as a duplicate of bug 72789 ***
[Bug c++/72789] add -Wunused-private-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72789 Eric Gallager changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Eric Gallager --- *** Bug 87409 has been marked as a duplicate of this bug. ***
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 87409, which changed state. Bug 87409 Summary: Implement -Wunused-private-field https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87409 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52763, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78736, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69672 --- Comment #2 from Eric Gallager --- There are lots of open bugs that this could be a dup of, see for example: - bug 52763 - bug 78736 - bug 69672
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 87405, which changed state. Bug 87405 Summary: Implement -Wliteral-conversion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87405 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/87405] Implement -Wliteral-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87405 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Eric Gallager --- Dup of bug 55077 *** This bug has been marked as a duplicate of bug 55077 ***
[Bug c++/55077] implement and enable by default -Wliteral-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077 Eric Gallager changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #8 from Eric Gallager --- *** Bug 87405 has been marked as a duplicate of this bug. ***
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-30 CC||egallager at gcc dot gnu.org Depends on||72789, 80151, 71482, 55077, ||65213, 82100, 61864, 33715, ||67479, 81159, 84203, 62181, ||70065 Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > I think we should use a keyword for this one instead of a meta-bug as this > bug will always be open. Yeah, I mean, we already have the "diagnostic" keyword anyways, and this will just be a subset of that... keywords aren't clickable, though, so I'm gonna confirm this after all. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33715 [Bug 33715] Suggest -Wmemleak warning for C++ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077 [Bug 55077] implement and enable by default -Wliteral-conversion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864 [Bug 61864] -Wcovered-switch-default to identify "dead" default branch https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 [Bug 62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213 [Bug 65213] Extend -Wmissing-declarations to variables [i.e. add -Wmissing-variable-declarations] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67479 [Bug 67479] Support for -Wformat-pedantic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065 [Bug 70065] Split -Wparentheses warnings about operators priority into a separate warning flag, -Wprecedence https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482 [Bug 71482] Add -Wglobal-constructors warning option https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72789 [Bug 72789] add -Wunused-private-field https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151 [Bug 80151] Add a warning to catch implicit string to bool conversion (-Wstring-conversion) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159 [Bug 81159] New warning idea: -Wself-move https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82100 [Bug 82100] gcc does not warn about code that is unreachable due to conflicting conditions [subset of reviving -Wunreachable-code] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84203 [Bug 84203] add -Wsuggest-attribute=returns_nonnull
[Bug go/87470] New: [9 Regression] libgo/go/runtime/malloc.go failed to build with -mx32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87470 Bug ID: 87470 Summary: [9 Regression] libgo/go/runtime/malloc.go failed to build with -mx32 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: hjl.tools at gmail dot com CC: cmang at google dot com Target Milestone: --- Target: x86-64 On x86-64, r264546 caused: libtool: compile: /export/build/gnu/tools-build/gcc-x32-debug/build-x86_64-linux/./gcc/gccgo -B/export/build/gnu/tools-build/gcc-x32-debug/build-x86_64-linux/./gcc/ -B/usr/gcc-9.0.0-x32/x86_64-pc-linux-gnu/bin/ -B/usr/gcc-9.0.0-x32/x86_64-pc-linux-gnu/lib/ -isystem /usr/gcc-9.0.0-x32/x86_64-pc-linux-gnu/include -isystem /usr/gcc-9.0.0-x32/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -mx32 -I . -c -fgo-pkgpath=runtime -fgo-c-header=runtime.inc.raw -fgo-compiling-runtime /export/gnu/import/git/sources/gcc/libgo/go/runtime/alg.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/atomic_pointer.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/cgo_gccgo.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/cgocall.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/cgocheck.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/chan.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/compiler.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/cpuprof.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/cputicks.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/debug.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/env_posix.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/error.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/extern.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/fastlog2.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/fastlog2table.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/ffi.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/float.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/hash64.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/heapdump.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/iface.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/lfstack.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/lfstack_64bit.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/lock_futex.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/malloc.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/map.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/map_fast32.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/map_fast64.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/map_faststr.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mbarrier.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mbitmap.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mcache.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mcentral.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mem_gccgo.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mfinal.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mfixalloc.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgc.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgc_gccgo.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgclarge.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgcmark.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgcsweep.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgcsweepbuf.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mgcwork.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mheap.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mprof.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/msan0.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/msize.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mstats.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/mwbbuf.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/netpoll.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/netpoll_epoll.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/os_gccgo.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/os_linux.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/os_linux_noauxv.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/panic.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/print.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/proc.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/profbuf.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/proflabel.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/race0.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/rdebug.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/relax_stub.go /export/gnu/import/git/sources/gcc/libgo/go/runtime/runtime.go /export/gnu/import/git/sou
[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |rtl-optimization Version|8.0 |9.0 Target Milestone|--- |9.0 Summary|ice "wrong amount of branch |[9 Regression] ice "wrong |edges after conditional |amount of branch edges |jump in bb" |after conditional jump in ||bb"
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 H.J. Lu changed: What|Removed |Added Target|x86_64-*-* i?86-*-* |x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-29 Ever confirmed|0 |1 --- Comment #6 from H.J. Lu --- Fixed on trunk so far.
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 --- Comment #5 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Sep 29 21:59:59 2018 New Revision: 264716 URL: https://gcc.gnu.org/viewcvs?rev=264716&root=gcc&view=rev Log: i386: Use TImode for BLKmode values in 2 integer registers When passing and returning BLKmode values in 2 integer registers, use 1 TImode register instead of 2 DImode registers. Otherwise, V1TImode may be used to move and store such BLKmode values, which prevent RTL optimizations. gcc/ PR target/87370 * config/i386/i386.c (construct_container): Use TImode for BLKmode values in 2 integer registers. gcc/testsuite/ PR target/87370 * gcc.target/i386/pr87370.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr87370.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 --- Comment #33 from Murat Ursavaş --- One thing though. Would you accept this a regression and get back to 4.9 style? Yes, GCC is doing everything by the book but the result is not perfect (due to other undocumented issues not related to GNU team).
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 Murat Ursavaş changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #32 from Murat Ursavaş --- OK, dug down into Thumb-2 reference manual and verified. The code space shows correct instructions. For this line; strb.w r2,[r3,#0x54] It shows; 0xF883 0x2054 If I've read correctly, this is exactly what the disassembly says. I guess from GCC perspective, this is a perfectly valid situation and this ticket should be closed. If you have any additional ideas what could cause this, I'm all ears (Peripheral, Core, GDB). Otherwise, thanks for your time. It was enlightening for me to chase this issue.
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 --- Comment #31 from Murat Ursavaş --- (In reply to Murat Ursavaş from comment #28) > > Here's the disassembly of a problematic part: > > 4.9.3 > > 121 NVM_SPI->ROUTE = USART_ROUTE_TXPEN | USART_ROUTE_RXPEN | > USART_ROUTE_CLKPEN | NVM_SPI_LOCATION; > 00029e38: ldr r3,[pc,#0x4c] ; 0x29e84 > 00029e3a: ldr r2,[r3,#0x54] > 00029e3c: movsr2,#0x0 > 00029e3e: orr r2,r2,#0xb > 00029e42: str r2,[r3,#0x54] > > 7.3.1 > > 121 NVM_SPI->ROUTE = USART_ROUTE_TXPEN | USART_ROUTE_RXPEN | > USART_ROUTE_CLKPEN | NVM_SPI_LOCATION; > 572e: ldr r3,[pc,#0x70] ; 0x579c > 5730: ldrb.w r2,[r3,#0x54] > 5734: movsr2,#0x0 > 5736: orr r2,r2,#0xb > 573a: strb.w r2,[r3,#0x54] > 573e: ldrb.w r2,[r3,#0x55] > 5742: movsr2,#0x0 > 5744: strb.w r2,[r3,#0x55] > 5748: ldrb.w r2,[r3,#0x56] > 574c: movsr2,#0x0 > 574e: strb.w r2,[r3,#0x56] > 5752: ldrb.w r2,[r3,#0x57] > 5756: movsr2,#0x0 > 5758: strb.w r2,[r3,#0x57] My limited assembler knowledge says new one is byte by byte access and should set the register correctly, but somehow it's not. Could actual object code be different than what I see in the disassembly? I'll try to verify it via inspecting the code space.
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 --- Comment #30 from Murat Ursavaş --- OK, looks like it is possible like this: ldr r2, =0x000b Source: https://stackoverflow.com/questions/38689886/loading-32-bit-values-to-a-register-in-arm-assembly
[Bug inline-asm/63900] memory constrains needlessly doing memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900 --- Comment #8 from Segher Boessenkool --- It is not fixed in trunk, even. A better testcase removes the __volatile__: if this is properly optimised the whole asm disappears then, but in the case of MYSIZE 3 it does not with the current GCC.
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 --- Comment #29 from Murat Ursavaş --- And just out of curiosity, why the compiler loads zero to the register and then OR's with the value? 00029e3c: movsr2,#0x0 00029e3e: orr r2,r2,#0xb Why doesn't it load directly the necessary value? Like, 00029e3c: movsr2,#0xb I know ARM arch needs load/store mechanism for the RAM but why this additional task for a register?
[Bug target/87467] Incorrect function parameter for _mm512_abs_pd in `include/avx512fintrin.h`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87467 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed everywhere.
[Bug c++/65667] [5 Regression] FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++11 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65667 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Sep 29 17:17:09 2018 New Revision: 264715 URL: https://gcc.gnu.org/viewcvs?rev=264715&root=gcc&view=rev Log: 2018-09-29 Paul Thomas PR fortran/65667 * trans-expr.c (gfc_trans_assignment_1): If there is dependency fix the rse stringlength. 2018-09-29 Paul Thomas PR fortran/65667 * gfortran.dg/dependency_52.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_52.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/87467] Incorrect function parameter for _mm512_abs_pd in `include/avx512fintrin.h`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87467 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Sep 29 16:28:53 2018 New Revision: 264714 URL: https://gcc.gnu.org/viewcvs?rev=264714&root=gcc&view=rev Log: PR target/87467 * config/i386/avx512fintrin.h (_mm512_abs_pd, _mm512_mask_abs_pd): Use __m512d type for __A argument rather than __m512. * gcc.target/i386/avx512f-abspd-1.c (SIZE): Divide by two. (CALC): Use double instead of float. (TEST): Adjust to test _mm512_abs_pd and _mm512_mask_abs_pd rather than _mm512_abs_ps and _mm512_mask_abs_ps. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/avx512fintrin.h branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c
[Bug target/87467] Incorrect function parameter for _mm512_abs_pd in `include/avx512fintrin.h`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87467 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Sep 29 16:09:59 2018 New Revision: 264713 URL: https://gcc.gnu.org/viewcvs?rev=264713&root=gcc&view=rev Log: PR target/87467 * config/i386/avx512fintrin.h (_mm512_abs_pd, _mm512_mask_abs_pd): Use __m512d type for __A argument rather than __m512. * gcc.target/i386/avx512f-abspd-1.c (SIZE): Divide by two. (CALC): Use double instead of float. (TEST): Adjust to test _mm512_abs_pd and _mm512_mask_abs_pd rather than _mm512_abs_ps and _mm512_mask_abs_ps. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/avx512fintrin.h branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c
[Bug target/87467] Incorrect function parameter for _mm512_abs_pd in `include/avx512fintrin.h`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87467 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Sat Sep 29 16:04:09 2018 New Revision: 264711 URL: https://gcc.gnu.org/viewcvs?rev=264711&root=gcc&view=rev Log: PR target/87467 * config/i386/avx512fintrin.h (_mm512_abs_pd, _mm512_mask_abs_pd): Use __m512d type for __A argument rather than __m512. * gcc.target/i386/avx512f-abspd-1.c (SIZE): Divide by two. (CALC): Use double instead of float. (TEST): Adjust to test _mm512_abs_pd and _mm512_mask_abs_pd rather than _mm512_abs_ps and _mm512_mask_abs_ps. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 H.J. Lu changed: What|Removed |Added CC||ubizjak at gmail dot com Component|middle-end |target Target Milestone|--- |9.0 Summary|Regression in return struct |[7/8/9 Regression] |code|Inefficient return code of ||struct values
[Bug middle-end/87370] Regression in return struct code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 --- Comment #4 from H.J. Lu --- Created attachment 44769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44769&action=edit I am testing this patch
[Bug inline-asm/63900] memory constrains needlessly doing memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900 Christopher Head changed: What|Removed |Added CC||headch at gmail dot com --- Comment #7 from Christopher Head --- It seems to me that this is fixed in 8.2.0?
[Bug c++/87373] Packed structs are not handled properly on ARM architecture even with misaligned access is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87373 Murat Ursavaş changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #28 from Murat Ursavaş --- Hi, I've created the time and added 7.3.1 to my toolchain list. (It is really annoyingly hard to add a new toolchain in my configuration due to a bug in the IDE). Anyway right now I can compare 4.9.3 and 7.3.1 side by side and my application is not working with the 7 series. That is exactly how it started at the beginning. I've cleared some issues that could interfere with this issue but now I can reproduce the issue on my target. I'm not sure this is due to packed structs or not but I've found a difference which should not happen. Please bear with me on this. Here's the disassembly of a problematic part: 4.9.3 121 NVM_SPI->ROUTE = USART_ROUTE_TXPEN | USART_ROUTE_RXPEN | USART_ROUTE_CLKPEN | NVM_SPI_LOCATION; 00029e38: ldr r3,[pc,#0x4c] ; 0x29e84 00029e3a: ldr r2,[r3,#0x54] 00029e3c: movsr2,#0x0 00029e3e: orr r2,r2,#0xb 00029e42: str r2,[r3,#0x54] 7.3.1 121 NVM_SPI->ROUTE = USART_ROUTE_TXPEN | USART_ROUTE_RXPEN | USART_ROUTE_CLKPEN | NVM_SPI_LOCATION; 572e: ldr r3,[pc,#0x70] ; 0x579c 5730: ldrb.w r2,[r3,#0x54] 5734: movsr2,#0x0 5736: orr r2,r2,#0xb 573a: strb.w r2,[r3,#0x54] 573e: ldrb.w r2,[r3,#0x55] 5742: movsr2,#0x0 5744: strb.w r2,[r3,#0x55] 5748: ldrb.w r2,[r3,#0x56] 574c: movsr2,#0x0 574e: strb.w r2,[r3,#0x56] 5752: ldrb.w r2,[r3,#0x57] 5756: movsr2,#0x0 5758: strb.w r2,[r3,#0x57] 4.9.3 sets the ROUTE register as 0xB correctly. But 7.3.1 sets it as 0x30B. The correct value is 0xB (calculated from the bit values). This maps the USART to the wrong pins and makes the peripheral physically useless and also cripples other pins. Like I said, this may not be a bug, could be my error or vendor libraries but something doesn't look right. Please let me know if you need further info. I may need some guidance to collect more data. P.S: I'm trying to improve GCC, otherwise I'm just fine with 4.9.3.
[Bug c++/87469] New: ice in record_estimate, at tree-ssa-loop-niter.c:3271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87469
Bug ID: 87469
Summary: ice in record_estimate, at tree-ssa-loop-niter.c:3271
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ source code:
long a;
struct c {
void d(unsigned f) {
long e = f;
while (e & e - 1)
e &= e - 1;
a = e;
}
};
void g() {
c b;
b.d(4 + 2);
}
compiled by recent gcc trunk and compiler flag -O2, does this:
$ ~/gcc/results/bin/gcc -c -w -O2 bug466.cc
during GIMPLE pass: cunrolli
bug466.cc: In function ‘void g()’:
bug466.cc:10:6: internal compiler error: in record_estimate, at
tree-ssa-loop-niter.c:3271
10 | void g() {
| ^
0x10bc8da record_estimate
../../trunk/gcc/tree-ssa-loop-niter.c:3271
0x10c391b estimate_numbers_of_iterations(loop*)
../../trunk/gcc/tree-ssa-loop-niter.c:4122
0x10c4c0c estimate_numbers_of_iterations(function*)
../../trunk/gcc/tree-ssa-loop-niter.c:4342
0x109e88e tree_unroll_loops_completely
../../trunk/gcc/tree-ssa-loop-ivcanon.c:1424
The problem seems to first occur somewhere between revisions
261000 and 262000.
[Bug c/87468] ice "wrong amount of branch edges after conditional jump in bb"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468
--- Comment #1 from David Binderman ---
C source code is
a;
b() {
int c = 1;
for (; c <= 3;) {
int d = e() && !0;
switch (c)
case 1:
if (d)
case 2:
case 3:
f();
if (a)
c++;
}
}
[Bug c/87468] New: ice "wrong amount of branch edges after conditional jump in bb"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468 Bug ID: 87468 Summary: ice "wrong amount of branch edges after conditional jump in bb" Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- This C source code, when compiled by recent gcc trunk and flag -O2, does this: bug465.c: In function ‘b’: bug465.c:15:1: error: wrong amount of branch edges after conditional jump in bb 10 15 | } | ^ bug465.c:15:1: error: wrong number of branch edges after unconditional jump in bb 9 during RTL pass: outof_cfglayout bug465.c:15:1: internal compiler error: verify_flow_info failed 0x8c9c27 verify_flow_info() ../../trunk/gcc/cfghooks.c:265 0x8e4711 checking_verify_flow_info ../../trunk/gcc/cfghooks.h:198 0x8e4711 cfg_layout_finalize() ../../trunk/gcc/cfgrtl.c:4350 0x8e4884 execute ../../trunk/gcc/cfgrtl.c:3606 The bug seems to occur somewhere between revisions 264595 and 264662.
[Bug target/87467] Incorrect function parameter for _mm512_abs_pd in `include/avx512fintrin.h`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87467 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-29 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 44768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44768&action=edit gcc9-pr87467.patch Untested fix.
[Bug tree-optimization/87465] [8/9 Regression] Loop removal regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-29 Target Milestone|9.0 |8.3 Ever confirmed|0 |1
[Bug tree-optimization/87465] [8/9 Regression] Loop removal regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Summary|Loop removal regression |[8/9 Regression] Loop ||removal regression --- Comment #1 from Jakub Jelinek --- This changed with r255267, we don't peel/completely unroll the loop nest anymore. I'd say in this case it would be best done by a constexpr-like evaluation pass, where we'd just at compile time try to evaluate a few (hundreds) iterations of the loop at compile time and see if we can simply capture the whole outcome of the loop (final values, maybe some simple array stores). Until then, use C++14 constexpr evaluation if you want stuff to be evaluated at compile time.
[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156 --- Comment #4 from Paul Hua --- (In reply to Jan Hubicka from comment #3) > Does the attached patch fix the bootstrap? > Index: cgraphclones.c > === > --- cgraphclones.c (revision 264180) > +++ cgraphclones.c (working copy) > @@ -967,6 +967,8 @@ cgraph_node::create_version_clone_with_b >SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl)); >SET_DECL_RTL (new_decl, NULL); > > + DECL_VIRTUAL_P (new_decl) = 0; > + >/* When the old decl was a con-/destructor make sure the clone isn't. */ >DECL_STATIC_CONSTRUCTOR (new_decl) = 0; >DECL_STATIC_DESTRUCTOR (new_decl) = 0; Yes, fixed. Thanks.
