[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932 --- Comment #3 from graham.stott at btinternet dot com 2013-04-12 12:21:59 UTC --- ktietz. Access to a[250] is undefined as pointed out by andrew. Increase size of a to 251 to get the test passing. Graham
[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907
--- Comment #1 from graham.stott at btinternet dot com 2012-10-12 10:24:30 UTC
---
Not a bug p is modified twice without a seqence point the result is undefined
From: yangzhe1990 at gmail dot com
To: gcc-bugs@gcc.gnu.org
Sent: Friday, 12 October 2012, 11:10
Subject: [Bug c/54907] New: post increasing a value pointed by p in
subexpression of an expression modifying p saves the increased value in the
wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907
Bug #: 54907
Summary: post increasing a value pointed by p in subexpression
of an expression modifying p saves the increased value
in the wrong place
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yangzhe1...@gmail.com
#include
int main() {
char s[] = "ax";
char *p = s;
printf("s = %s in the beginning.\n"
"p is pointed at the %d-th char.\n", s, p - s);
//p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)
p += (*p)++ * 3 + 2 - 'a' * 3; // (2)
printf("p is moved ahead by %d steps\n", p - s);
printf("s = %s after the operation.\n", s);
return 0;
}
The expected result is "bx". But the output is "axbxxx".
Maybe in the wrong code, when it saves the value, it lookups the address again
by *p, but p is modified in the expression.
As discussed in stackoverflow,
http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top
most people think it's a bug of gcc.
Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct
result.
[Bug target/54106] OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 --- Comment #2 from graham.stott at btinternet dot com 2012-07-27 13:18:28 UTC --- No a GCC bug. The source and dest needs to be correctly aligned From: wolfgang.hauser.external at cassidian dot com To: gcc-bugs@gcc.gnu.org Sent: Friday, 27 July 2012, 12:57 Subject: [Bug target/54106] OMAP3: encountered a blocking structure assignment, occurring only on OMAP3 processors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54106 --- Comment #1 from wohauser 2012-07-27 11:57:04 UTC --- Created attachment 27881 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27881 Original source of the example
[Bug rtl-optimization/57189] [4.9 Regression] Vector register is spilled for vector extract pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189 --- Comment #2 from graham.stott at btinternet dot com --- From: rguenth at gcc dot gnu.org To: gcc-bugs@gcc.gnu.org Sent: Friday, 25 October 2013, 14:11 Subject: [Bug rtl-optimization/57189] [4.9 Regression] Vector register is spilled for vector extract pattern http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189 Richard Biener changed: What |Removed |Added Priority|P3 |P1
[Bug c++/86306] Initializing atomic qualified type with another atomic qualified type leads to assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86306 --- Comment #10 from graham.stott at btinternet dot com --- very poor bug reports they waste time for people they don't have Original message From: "zhonghao at pku dot org.cn" Date: 25/06/2018 12:37 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/86306] Initializing atomic qualified type with another atomic qualified type leads to assertion failure https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86306 --- Comment #9 from zhonghao at pku dot org.cn --- (In reply to zhonghao from comment #8) > (In reply to Jonathan Wakely from comment #7) > > (In reply to Jonathan Wakely from comment #6) > > > Because you are just blindly copying things from one bugzilla to the > > > other, > > > without making any effort to check if what you are reporting is sensible. > > > > For example, in Bug 86305 you said that g++ segfaults on the code. That's > > complete nonsense. You just took the title of the clang bug and changed > > "clang" to "g++" even though g++ does not segfault on the code. > > > > Do you really think that is helpful? > > As I said, I posted the original bug reports, hoping that they can provide > insights on why the recent gcc and clang handle the same piece of code > differently. Sometimes, I reuse the titles of the original bug reports, so I > can keep the links between them easier. If the titles are confusing, I will > try to use more informative titles. However, do the differences themselves > often reveal bugs? Furthermore, those code samples are not randomly > generated, and they come from your real users! They are not invented by me, > and they are real code! Your potential users report those code samples to your competitors, so your competitors can provide compilers of higher quality. I “steal” those code samples to you. I thought that you must appreciate me, but you threaten to ban me, intead. :(
[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025 --- Comment #19 from graham.stott at btinternet dot com --- JeffThere's trival error in gcc/config/mips/mti-linux.h which causes loads of warnings everytime it's includedThere's a missing space between a string and MACRO about line 28Graham Original message From: law at redhat dot com Date: 03/04/2019 06:00 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/81025] [8/9 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025Jeffrey A. Law changed: What |Removed |Added Priority|P3 |P2 Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |law at redhat dot com--- Comment #16 from Jeffrey A. Law ---In response to c#10 and c#11. I suspect you're not able to trigger thefailures because of something in auto-host.h. If I first configure & installbinutils for the target (mips-mti-linux-gnu), then configure gcc for the sametarget I can trigger the failures per the instructions in this BZ.What I'm unable to figure out is my own comment WRT FRAME_RELATED_P from lastyear. I don't see any evidence this is at all related to FRAME_RELATED_P insnsin delay slots.AFAICT we've done shrink wrapping on this case. ISTM there's multiple paths tothe epilogue, some save r16/r17 and adjust the stack pointer, others do not(according to my reading of the dwarf2cfi pass RTL dump). Thus triggering theCFI failure due to the inconsistency (not to mention bogus code).So of course the next thing to do is look at the prologue/epilogue dump andeverything looks fine there. Things also look fine at the .barriers dump. Then reorg comes along and mucks things up horribly.The bug here is in reorg and its legacy of trying to compensate for the lack ofa CFG. In particular it has a function skip_consecutive_labels. The idea (ofcourse) is to have jumps target the last label if there's several in a row. The code looks something like this: for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn)) if (LABEL_P (insn)) label = insn;THe loop termination condition allows the code to look through notes and otherrandom crud.Now imagine if we have(code_label 1)(barrier)(code_label 2)(more code)The BARRIER after a CODE_LABEL can occur due to __builtin_unreachable.If a jump targets code_label 1, it will be redirected to code_label 2. That'sfine from a runtime standpoint, but runs afoul of the CFI bits. Why?Consider if the jump which targeted label 1 did not have a prologue (we'reshrink wrapping) and "more code" section is a shrink wrapped epilogue.The original paths to code_label 2 will have one CFI state while the new pathsto code_label 1 will have a different CFI state and we trip the check.I'm spinning a fix overnight.
[Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #3 from graham.stott at btinternet dot com --- still fails predict.h needs updating prototype also Original message From: "hubicka at gcc dot gnu.org" Date: 17/04/2016 19:05 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/70706] [7 Regression] r235082 caused bootstrap failure https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70706 --- Comment #1 from Jan Hubicka --- Author: hubicka Date: Sun Apr 17 18:04:51 2016 New Revision: 235085 URL: https://gcc.gnu.org/viewcvs?rev=235085&root=gcc&view=rev Log: PR bootstrap/70706 * graphite.c (graphite_finalize): Update call to tree_estimate_probability. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 --- Comment #8 from graham.stott at btinternet dot com --- Original message From: "trippels at gcc dot gnu.org" Date: 17/04/2017 12:36 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
[Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025 --- Comment #5 from graham.stott at btinternet dot com --- Hi Doug I build both GCC and GLIBC daily but for mips-img-linux-gnu and hard-float the only prob. I see is ADA fails building one multilib config. I do all langs I'll give try hard-float mips-mti-linux-gnu. Graham ps My son now has British passport Original message From: "doug.gilmore at imgtec dot com" Date: 09/06/2017 09:12 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025 Doug Gilmore changed: What |Removed |Added CC| |rguenth at gcc dot gnu.org --- Comment #4 from Doug Gilmore --- Created attachment 41513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41513&action=edit cut down example via delta Sorry attachment for the last comment was dropped. I bisected the failure to r247049 using the cut down example, compiled via: $dir/xgcc -B$dir -O2 -msoft-float -mabi=32 delta_1.i -c -std=gnu11 -fgnu89-inline -O2 -fmerge-all-constants -fno-stack-protector -frounding-math -g For this bisect I configured with --disable-multilib. I'll look into this more tomorrow.
[Bug ipa/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 --- Comment #7 from graham.stott at btinternet dot com --- libjava has been removed from gcc 7 ?? Original message From: "hubicka at gcc dot gnu.org" Date: 05/02/2017 12:12 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 Jan Hubicka changed: What |Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2016-07-13 00:00:00 |2017-02-05 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jan Hubicka --- The ICE is signaling that we have declaration that is !binds_to_current_def but it is also marked as not externally visible. So something is probably wrong with the decl itself or way visibility is handled on hpux. Let me see if I can reproduce it on current tree.
[Bug tree-optimization/60502] New: 4.9 ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502
Bug ID: 60502
Summary: 4.9 ICE reassociation and vector types.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: graham.stott at btinternet dot com
gcc_unreacble abort in reassociation and vector types
If reassocation manages to simplify an expression which involves any VECTOR
type
it will trigger a gcc_unreachable abort.
On any target which has support for vector types.
typedef signed char v16i8 __attribute__ ((vector_size(16)));
v16i8 bug1(v16i8 op0)
{
v16i8 m1 = {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1};
return (op0 ^ m1) | (op0 & m1);
}
It hits a gcc_unreachable() in build_int_cst_wide.
bug.c:3:7: internal compiler error: in build_int_cst_wide, at tree.c:1200
v16i8 bug1(v16i8 op0)
^
0xb75583 build_int_cst_wide(tree_node*, unsigned long, long)
/gcc/gcc/gcc/tree.c:1200
0xaade63 eliminate_not_pairs
/gcc/gcc/gcc/tree-ssa-reassoc.c:810
0xaade63 optimize_ops_list
/gcc/gcc/gcc/tree-ssa-reassoc.c:1744
0xab0a99 reassociate_bb
/gcc/gcc/gcc/tree-ssa-reassoc.c:4436
0xab08a7 reassociate_bb
/gcc/gcc/gcc/tree-ssa-reassoc.c:4519
0xab311b do_reassoc
/gcc/gcc/gcc/tree-ssa-reassoc.c:4552
0xab311b execute_reassoc
/gcc/gcc/gcc/tree-ssa-reassoc.c:4634
0xab311b execute
/gcc/gcc/gcc/tree-ssa-reassoc.c:4676
[Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337 --- Comment #4 from graham.stott at btinternet dot com --- Original message From: "vladimir.fuka at gmail dot com" Date:02/09/2015 14:55 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337 --- Comment #3 from Vladimir Fuka --- The crash is at line 22: allocate(a(size(tmp)+1)%items(size(e)), source = e) ASAN:SIGSEGV = ==5902==ERROR: AddressSanitizer: SEGV on unknown address 0x60c0c08ef6b0 (pc 0x004086ed bp 0x7ffec4dcc6b0 sp 0x7ffec4dcc490 T0) #0 0x4086ec in __array_list_MOD_add_item /home/vf1r14/f/testy/stackoverflow/pr61337b.f90:22 #1 0x408ff4 in MAIN__ /home/vf1r14/f/testy/stackoverflow/pr61337b.f90:35 #2 0x4096d5 in main /home/vf1r14/f/testy/stackoverflow/pr61337b.f90:30 #3 0x7f898a67eb04 in __libc_start_main (/lib64/libc.so.6+0x21b04) #4 0x400e38 (/home/vf1r14/f/testy/stackoverflow/a.out+0x400e38) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/vf1r14/f/testy/stackoverflow/pr61337b.f90:22 __array_list_MOD_add_item ==5902==ABORTING
[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67438 --- Comment #8 from graham.stott at btinternet dot com --- Sent from Samsung Mobile on O2 Original message From: "afomin.mailbox at gmail dot com" Date:07/09/2015 13:35 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67438 --- Comment #7 from Alexander Fomin --- Looks like a cost model should be introduced to avoid such kind of transformations for targets with HW min/max implementation.
[Bug target/67733] elfdump and readelf in perl scripts should to use env vars ELFDUMP and READELF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67733 --- Comment #4 from graham.stott at btinternet dot com --- Sent from Samsung Mobile on O2 Original message From: "pinskia at gcc dot gnu.org" Date:27/09/2015 17:25 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug target/67733] elfdump and readelf in perl scripts should to use env vars ELFDUMP and READELF https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67733 --- Comment #3 from Andrew Pinski --- (In reply to Igor Kozhukhov from comment #2) > /usr/ccs links old and unused. > also - illumos != solaris and can use his own layout. > at this moment it's not easy try to move to 'illumos' platform definition > because autotools not ready to define and use it. Then do that first. Because ... > illumos is OpenSources platform, but oracle solaris is closed and illumos > binaries incompatible with solaris binaries now. of this, you need a new triplet. > will be more easy/better to use more universal gcc bootstrap process with > definition what can be using by env vars instead try to patch every gcc > bootstrap for every platform. This is a because Solaris is special. > these changes not depend on illumos or solaris because we can use tools > ELFDUMP & READELF from different locations and hardcode it is not a good way > for others platforms to use it and hack bootstrap process every time. This is all in Solaris specific code though which is why it is done that way.
[Bug fortran/69064] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when a variable is missing in "use *, only" list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 --- Comment #42 from graham.stott at btinternet dot com --- why the torrent of emails (spam)
[Bug c++/69215] Improve diagnostic for 'for(i : v)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69215
--- Comment #1 from graham.stott at btinternet dot com ---
Ok thats quick only 1 hour plus 2 hour car airport.
I been by train long time sleep on train in bed and by bus both 12 hrs if I
recall correctly.
Might be home now.
😍
Original message
From: rs2740 at gmail dot com
Date: 10/01/2016 05:11 (GMT+00:00)
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/69215] New: Improve diagnostic for 'for(i : v)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69215
Bug ID: 69215
Summary: Improve diagnostic for 'for(i : v)'
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Something like
#include
int main(){
std::vector v;
for(i : v) {}
}
produces a storm of not-very-enlightening errors on trunk:
prog.cc: In function 'int main()':
prog.cc:5:11: error: found ':' in nested-name-specifier, expected '::'
for(i : v) {}
^
prog.cc:5:9: error: 'i' has not been declared
for(i : v) {}
^
prog.cc:6:1: error: expected primary-expression before '}' token
}
^
prog.cc:6:1: error: expected ';' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token
prog.cc:6:1: error: expected ')' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token
in contrast to clang's:
prog.cc:5:9: error: range-based for loop requires type for loop variable
for(i : v) {}
^
Perhaps the code implementing N3994, removed by r229632, can be repurposed
instead to produce a better error message?
