[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #1 from Alan Modra --- BTW, the linker error message doesn't identify the correct function, which is looking like a linker bug.
[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 Alan Modra changed: What|Removed |Added Target||powerpc64-linux Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-01 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug target/67417] New: powerpc64 bootstrap with -mcmodel=small results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 Bug ID: 67417 Summary: powerpc64 bootstrap with -mcmodel=small results in linker error Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- To test recent powerpc64 linker changes I attempted to bootstrap gcc-5 with -mcmodel=small, and ran into /home/amodra/gnu/powerpc64-linux/bin/ld: libbackend.a(sel-sched-ir.o): In function `loop_iterator::loop_iterator(loop**, unsigned int)': sel-sched-ir.c:(.text+0x116f0): call to `loop_iterator::loop_iterator(loop**, unsigned int)' lacks nop, can't restore toc; (-mcmodel=small toc adjust stub) On investigating, I see there really isn't a nop, and the call is to a group with a different toc pointer. This despite the destination being defined in the same file. However, it is weak and there's another definition. nm -o gcc/*.o | grep _ZN13loop_iteratorC1EPP4loopj gcc/ipa-inline-analysis.o:0420 W _ZN13loop_iteratorC1EPP4loopj gcc/sel-sched-ir.o:13e0 W _ZN13loop_iteratorC1EPP4loopj
[Bug testsuite/64430] Out-of-bounds array access in isl-ast-gen-if-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64430 Dimitar Dimitrov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dimitar Dimitrov --- Fixed with: * gcc.dg/graphite/isl-ast-gen-if.c (main): Increase size of a array to allow a[50] to be a valid location.
[Bug ada/67416] New: raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67416 Bug ID: 67416 Summary: raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:428 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: kendall at bellsoft dot net Target Milestone: --- Created attachment 36274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36274&action=edit sources compiled when received error gnatmake -gnatwa -gnatd.n bragi gcc-4.9 -c -gnatwa -gnatd.n bragi.adb /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/system.ads bragi.adb bragi.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/ada.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-string.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-strunb.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-strmap.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-charac.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-chlat1.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-finali.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-finroo.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-atocou.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-stwiun.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-stwima.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-contai.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-cobove.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-iteint.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-stream.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-cdlili.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stalib.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-unccon.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-exctab.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-unstyp.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-tags.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stoele.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stoele.adb /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-soflin.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-except.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-parame.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-traent.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stache.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-atocou.adb /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stratt.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-secsta.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stposu.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-stopoo.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-finmas.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-pooglo.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-ststop.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/s-string.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-uncdea.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-cobove.adb /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-cgarso.ads /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-cdlili.adb bragi.adb:23:23: warning: formal parameter "Word" is not referenced bragi.adb:103:29: warning: formal parameter "Self" is not referenced bragi.adb:108:29: warning: formal parameter "Word" is not referenced bragi.adb:119:23: warning: formal parameter "Code" is not referenced bragi.adb:120:07: warning: variable "Result" is read but never assigned bragi.adb:183:07: warning: formal parameter "Code" is not referenced bragi.adb:184:07: warning: formal parameter "Order" is not referenced bragi.adb:185:07: warning: variable "Result" is read but never assigned bragi.adb:204:17: warning: formal parameter "Self" is not referenced bragi.adb:205:17: warning: formal parameter "Word" is not referenced +===GNAT BUG DETECTED==+ | 4.9.2 (x86_64-linux-gnu) in gimplify_expr, at gimplify.c:8343| | Error detected around /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/a-cobove.ads:442:38| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.9 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). bragi.adb bragi.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:428 gnatmake: "bragi.adb" compilation error
[Bug c/67386] missing diagnostic on a use of an undeclared function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Sebor --- As noted in the discussion, the GCC behavior in the Description of this bug matches the intent (if not the words) of the C90 standard. Any change here would only serve to break existing programs that rely on it. Closing as invalid. (Adding a test to exercise this behavior might be worthwhile.)
[Bug regression/67415] [5.1/5.2 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415 --- Comment #1 from Bernhard Rosenkränzer --- Workaround: add -march=armv7-a to the command line as well
[Bug regression/67415] New: [5.1/5.2 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415 Bug ID: 67415 Summary: [5.1/5.2 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: Bernhard.Rosenkranzer at linaro dot org Target Milestone: --- If -mcpu=anything is specified on the gcc command line, -print-file-name stops looking in the compiler's armv7-a library subdirectories. $ gcc-5.2/bin/arm-linux-androideabi-gcc -print-file-name=libatomic.a /MYPREFIX/gcc-5.2/bin/../lib/gcc/arm-linux-androideabi/5.2.1/../../../../arm-linux-androideabi/lib/armv7-a/libatomic.a works as expected, but: $ gcc-5.2/bin/arm-linux-androideabi-gcc -mcpu=cortex-a9 -print-file-name=libatomic.a libatomic.a $ gcc-5.2/bin/arm-linux-androideabi-gcc -mcpu=generic-armv7-a -print-file-name=libatomic.a libatomic.a 4.9 behaves as expected, 5.1 and 5.2 don't find the library.
[Bug fortran/67414] [5 Regression] Error message on failed allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2015-08/msg01909.ht ||ml --- Comment #2 from Janne Blomqvist --- Patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01909.html
[Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #22 from Francois-Xavier Coudert --- (In reply to Joost VandeVondele from comment #21) > Since it is mostly a 'taste' issue when to emit a backtrace or not, I think > it makes sense to just make it an option flag, either never or always emit a > backtrace. The flag '-fbacktrace' already exists and it could imply generate > a backtrace on every 'error termination', run time error, or deadly signals. > > I would find that very useful. I strongly second that. Backtraces are useful for those informed, and can be turned off (or ignored) by the non expert. So, I think every error termination should print a backtrace. That is: any case where we call abort(), or call exit() with non-zero status. Except, possibly, user-specified non-zero status (like "STOP 42"). PS: Regarding the argument that many runtime errors already indicate the source file and line number for the error, well… a backtrace has much more indication since it indicates the entire code path for the error.
[Bug fortran/67414] [5 Regression] Error message on failed allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 CC||fxcoudert at gcc dot gnu.org, ||jb at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Janne Blomqvist --- Confirmed. I'd say this is a WONTFIX. The reason is that with the new libbacktrace-based backtrace code the backtrace is generated in the same process, whereas the old implementation forked a copy of addr2line which did the symbol lookup. So when the code fails due to bumping into the memory limit, generating the backtrace fails. However, as there are several benefits of the new libbacktrace way, I don't think we want to go back to the old addr2line way. That being said, I have a patch which 1) Improves the error message for backtracing failing 2) Fixes the root case for the segfault here. Fixing issue 2) actually makes the backtrace go away, so uh.. Well, that's more an issue for PR 53379 anyway.
[Bug libstdc++/67399] no match for istream::operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67399 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marc Glisse --- Thanks Daniel.
[Bug libstdc++/67399] no match for istream::operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67399
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
In C++ there never existed an operator== for istream. The reason, why your code
compiles in C++03 is because std::basic_ios had
operator void*() const;
which was considered in this context to compare void* against a null pointer
literal. This implicit conversion of iostream could lead to very subtle and
surprising valid expression. When C++11 became standardized the language had
introduced *explicit* conversion functions and the above member became replaced
by
explicit operator bool() const;
which doesn't support your kind of conversion example anymore. If you want to
write code that works in all currently existing C++ versions, you should better
replace
if (cin.getline(x, sizeof (x)) == 0) { .. }
by
if (!cin.getline(x, sizeof (x))) { .. }
In other words: This is an invalid bug report.
[Bug target/67032] [4.9/5/6 Regression] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #10 from H.J. Lu --- It is caused by r210520.
[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407 dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com --- Comment #4 from dank at kegel dot com --- Just ran into this in the stock ubuntu 14.04 compiler, gcc-4.8.4. Inserting : int before the attribute works around the problem. Can someone confirm the bug?
[Bug libstdc++/67403] std::regex is not matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67403 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #3 from Mikhail Maltsev --- Here is rather detailed explanation from Jonathan Wakely (he is the maintainer of libstdc++): https://stackoverflow.com/questions/12530406/is-gcc-4-7-and-gcc-4-8-buggy-about-regular-expressions/12665408
[Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #21 from Joost VandeVondele --- (In reply to Janne Blomqvist from comment #11) > Looking at the frontend, calls to runtime_error_at are generated from > gfc_trans_runtime_check() and gfc_trans_runtime_error(). I went through > calls to these functions, and IMHO they all look like serious errors worthy > of a backtrace, with the exception of ALLOCATE/DEALLOCATE failures when > STAT= is not specified. In that case F2008 specifies that the processor must > proceed with error termination, and printing a backtrace for this case would > be a bit inconsistent with other cases of error termination. actually, I just created PR67414 where I ask for a backtrace on a failed allocate if stat is not specified. Since it is mostly a 'taste' issue when to emit a backtrace or not, I think it makes sense to just make it an option flag, either never or always emit a backtrace. The flag '-fbacktrace' already exists and it could imply generate a backtrace on every 'error termination', run time error, or deadly signals. I would find that very useful.
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #17 from Vittorio Zecca --- I found it fixed in 5.2.0
[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 Vittorio Zecca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vittorio Zecca --- I found it fixed in 5.2.0 and maybe already in 4.8.2
[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 Vittorio Zecca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Vittorio Zecca --- I found it fixed in 5.2.0
[Bug fortran/50537] explicit interface required (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537 Vittorio Zecca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Vittorio Zecca --- I found it fixed in 5.2.0
[Bug fortran/50069] FORALL fails on a character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 --- Comment #5 from Vittorio Zecca --- Still on gfortran 5.2.0
[Bug fortran/67414] New: [5 Regression] Error message on failed allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414 Bug ID: 67414 Summary: [5 Regression] Error message on failed allocate Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- For 4.9 and earlier a gfortran compiled binary would print a clear error message if an allocate would fail like in: > cat test.f90 INTEGER, POINTER, DIMENSION(:) :: leak DO ALLOCATE(leak(1000)) leak=0 ENDDO END > gfortran -g test.f90 > ulimit -v 100 > ./a.out Operating system error: Cannot allocate memory Allocation would exceed memory limit With gcc 5 I get only part of the error, but also a backtrace (which is nice) : > ./a.out Operating system error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F610BCC0B87 #1 0x7F610BCBFD80 #2 0x3BA4A3269F #3 0x3BA4A2B38F #4 0x7F610BCC1A92 #5 0x7F610BCC1B80 #6 0x400786 in MAIN__ at test.f90:3 (discriminator 3) Segmentation fault With gcc 6, unfortunately, the backtrace is replace with an error message: > ./a.out Operating system error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Something went wrong while printing the backtrace: mmap Something went wrong while printing the backtrace: mmap Something went wrong while printing the backtrace: mmap Segmentation fault Ideally, we get both the clear error message and a backtrace.
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 --- Comment #3 from Francois-Xavier Coudert --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > I know, but only on Solaris 12. Also, there's > gfortran.dg/large_real_kind_2.F90 that fails at -O0 only. I still mean > to investigate what's going on there. CC me when you do: I'm the contact person for floating point and quad prec stuff in the Fortran team :)
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Francois-Xavier Coudert --- > (In reply to Rainer Orth from comment #0) >> It seems the old buggy Solaris /bin/sh is the culprit. According to the >> OpenSolaris sources, per default system(3C) uses /bin/sh, but if linked >> with values-xpg4.o (which isn't currently used, while the Studio c89 compiler >> does), /usr/xpg4/bin/sh is, which is a posix conformant shell and yields >> the correct exit code. >> >> I'm uncertain how best to handle this. > > In Fortran terms, this is really a corner case of the Fortran standard > interaction with the system. So I don't think it is a big deal, especially if > it is fixed on newer Solaris versions. > > I suggest simply XFAIL-ing the test case with a link to this PR. If that feels > OK to you, the patch is pre-approved. Thanks for reporting the issue! ok, will do. Besides, I still mean to revisit the values-xpg[46].o issue: maybe this will fix this bug as a side effect. > PS: I saw that sparc/sparcv9 test results show failures for > gfortran.dg/norm2_3.f90. If you find time at some point, could you open a PR > for it and CC me? I know, but only on Solaris 12. Also, there's gfortran.dg/large_real_kind_2.F90 that fails at -O0 only. I still mean to investigate what's going on there. Rainer
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert --- (In reply to Rainer Orth from comment #0) > It seems the old buggy Solaris /bin/sh is the culprit. According to the > OpenSolaris sources, per default system(3C) uses /bin/sh, but if linked > with values-xpg4.o (which isn't currently used, while the Studio c89 compiler > does), /usr/xpg4/bin/sh is, which is a posix conformant shell and yields > the correct exit code. > > I'm uncertain how best to handle this. In Fortran terms, this is really a corner case of the Fortran standard interaction with the system. So I don't think it is a big deal, especially if it is fixed on newer Solaris versions. I suggest simply XFAIL-ing the test case with a link to this PR. If that feels OK to you, the patch is pre-approved. Thanks for reporting the issue! PS: I saw that sparc/sparcv9 test results show failures for gfortran.dg/norm2_3.f90. If you find time at some point, could you open a PR for it and CC me?
[Bug c++/61753] poor diagnostic for constructor definition that starts with 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com
[Bug libstdc++/67403] std::regex is not matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67403 --- Comment #2 from Ryan Gonzalez --- (In reply to Andrew Pinski from comment #1) > Iirc regex was not implemented in 4.8.x. Try 4.9 and above. ...but then why are the functions present? I would've preferred a compile-time error if that is the case.
[Bug target/67400] -fno-plt doesn't work with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67400 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Another pointer bug: [hjl@gnu-6 pr18900]$ cat y.c extern void foo (void); typedef void (*func_p) (void); const func_p p1 = &foo; [hjl@gnu-6 pr18900]$ make y.o /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -B./ -O2 -fno-plt -c -o y.o y.c [hjl@gnu-6 pr18900]$ readelf -SW y.o There are 11 section headers, starting at offset 0x1e8: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 00 00 AX 0 0 1 [ 2] .data PROGBITS 40 00 00 WA 0 0 1 [ 3] .bss NOBITS 40 00 00 WA 0 0 1 [ 4] .rodata PROGBITS 40 08 00 A 0 0 8 [ 5] .rela.rodata RELA 000178 18 18 I 9 4 8 [ 6] .comment PROGBITS 48 2a 01 MS 0 0 1 [ 7] .note.GNU-stack PROGBITS 72 00 00 0 0 1 [ 8] .shstrtab STRTAB 000190 52 00 0 0 1 [ 9] .symtab SYMTAB 78 f0 18 10 8 8 [10] .strtab STRTAB 000168 0c 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) [hjl@gnu-6 pr18900]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -B./ -O2 -fno-plt -c -o y.o y.c -fpie [hjl@gnu-6 pr18900]$ readelf -SW y.o There are 11 section headers, starting at offset 0x1e8: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 00 00 AX 0 0 1 [ 2] .data PROGBITS 40 00 00 WA 0 0 1 [ 3] .bss NOBITS 40 00 00 WA 0 0 1 [ 4] .data.rel.ro PROGBITS 40 08 00 WA 0 0 8 [ 5] .rela.data.rel.ro RELA 000178 18 18 I 9 4 8 [ 6] .comment PROGBITS 48 2a 01 MS 0 0 1 [ 7] .note.GNU-stack PROGBITS 72 00 00 0 0 1 [ 8] .shstrtab STRTAB 000190 57 00 0 0 1 [ 9] .symtab SYMTAB 78 f0 18 10 8 8 [10] .strtab STRTAB 000168 0c 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) [hjl@gnu-6 pr18900]$ -fno-plt should use .data.rel.ro section, not .rodata section for function pointer.
[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r211188.
[Bug middle-end/67409] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 CC||mpolacek at gcc dot gnu.org Component|c++ |middle-end Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed even with trunk.
[Bug rtl-optimization/67413] New: Complex NOP expanded to several operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67413
Bug ID: 67413
Summary: Complex NOP expanded to several operations
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
_Complex unsigned f(_Complex int i){return i;}
yields
movl%edi, %eax
shrq$32, %rdi
salq$32, %rdi
orq %rdi, %rax
ret
I read somewhere that complex integers are a deprecated gcc extension, but gcc
only warns in pedantic mode, and it should not be too hard to improve the
generated code.
Note that tree optimizers currently also fail to optimize the corresponding
code:
long f(long x){
long y = x >> 32;
y <<= 32;
int z = x;
return z | y;
}
(using & CST instead of >> and << does not help)
[Bug c++/67411] [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411 --- Comment #1 from Marek Polacek --- Seems it started with r211084.
[Bug libfortran/67412] gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug libfortran/67412] New: gfortran.dg/execute_command_line_2.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67412 Bug ID: 67412 Summary: gfortran.dg/execute_command_line_2.f90 FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: fxcoudert at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.10 The new gfortran.dg/execute_command_line_2.f90 test FAILs on Solaris 10: FAIL: gfortran.dg/execute_command_line_2.f90 -O0 execution test FAIL: gfortran.dg/execute_command_line_2.f90 -O1 execution test FAIL: gfortran.dg/execute_command_line_2.f90 -O2 execution test FAIL: gfortran.dg/execute_command_line_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/execute_command_line_2.f90 -O3 -g execution test FAIL: gfortran.dg/execute_command_line_2.f90 -Os execution test both 32 and 64-bit. Solaris 11 and 12 are ok. In the log, I find spawn [open ...]^M sh: /nosuchfile: not found Program aborted. Backtrace: #0 0xfee7efdf Running the testcase under gdb reveals that the c == 0 check causes the abort. I notice that on Solaris 10, system exits with res = 256 (0x0100), while on Solaris 12 I get res = 32512 (0x7F00). Trying the essence of the test manually, I see * Solaris 10 /bin/sh: /nosuchfile => exit code 1 * Solaris 10 /bin/ksh: /nosuchfile => exit code 127 It seems the old buggy Solaris /bin/sh is the culprit. According to the OpenSolaris sources, per default system(3C) uses /bin/sh, but if linked with values-xpg4.o (which isn't currently used, while the Studio c89 compiler does), /usr/xpg4/bin/sh is, which is a posix conformant shell and yields the correct exit code. I'm uncertain how best to handle this. Rainer
[Bug c++/67411] New: [5/6 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:13473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411
Bug ID: 67411
Summary: [5/6 Regression] internal compiler error: in
tsubst_copy, at cp/pt.c:13473
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
#include
template
void invoke_lambda(functor_type &&functor)
{
functor();
}
template
void invoke_lambda(arg_type &&arg, functor_type &&functor)
{
functor(std::forward(arg));
}
class conn;
class ts {
public:
int timestamp;
};
void bar(conn *c, int timestamp)
{
}
void foo(conn *c, ts *t)
{
invoke_lambda([tuple_conn=std::make_tuple(c), timestamp=t->timestamp] {
invoke_lambda(tuple_conn, [&] (const auto &tuple_conn) {
invoke_lambda([=] { bar(std::get<0>(tuple_conn), timestamp); }); }); });
}
With 5/trunk I get:
t.C: In instantiation of ‘foo(conn*, ts*):: [with auto:1 = std::tuple]’:
t.C:30:43: required from ‘struct foo(conn*, ts*) [with auto:1 = std::tuple]::’
t.C:30:20: required from ‘foo(conn*, ts*) [with auto:1 = std::tuple]’
t.C:12:10: required from ‘void invoke_lambda(arg_type&&, functor_type&&)
[with functor_type = foo(conn*, ts*);
arg_type = const std::tuple&]’
t.C:30:73: required from here
t.C:28:73: internal compiler error: in tsubst_copy, at cp/pt.c:13473
invoke_lambda([tuple_conn=std::make_tuple(c), timestamp=t->timestamp] {
^
0x6480d4 tsubst_copy
/home/marek/src/gcc/gcc/cp/pt.c:13473
0x649542 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:16225
0x64afd3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:15250
0x64a294 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:16006
0x63c490 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:15031
0x643ab9 tsubst_decl
/home/marek/src/gcc/gcc/cp/pt.c:11958
0x6472ce tsubst_copy
/home/marek/src/gcc/gcc/cp/pt.c:13604
0x649542 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:16225
0x64b1d7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:15715
0x63c490 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:15031
0x63ce72 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:14442
0x63bc6b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:14614
0x63b993 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:14428
0x63bc6b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:14614
0x639f45 instantiate_decl(tree_node*, int, bool)
/home/marek/src/gcc/gcc/cp/pt.c:21158
0x67b188 instantiate_class_template_1
/home/marek/src/gcc/gcc/cp/pt.c:10161
0x67b188 instantiate_class_template(tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:10229
0x71aebb complete_type(tree_node*)
/home/marek/src/gcc/gcc/cp/typeck.c:138
0x64aa0d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:16345
0x64b1d7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marek/src/gcc/gcc/cp/pt.c:15715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c/67410] New: c/c-typeck.c references out of bounds array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67410
Bug ID: 67410
Summary: c/c-typeck.c references out of bounds array
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/*sanitizer message*/
/*gcc-5.2.0/gcc/c/c-typeck.c:8266:42: runtime error: load of address
0x7ffc8682b570 with insufficient space for an object of type 'long int'*/
/*gcc-5.2.0/gcc/c/c-typeck.c:8266:42: runtime error: store to address
0x7ffc8682b570 with insufficient space for an object of type 'long int'*/
/*offending source line "val[bitpos % HOST_BITS_PER_WIDE_INT]"
* val is dimensioned [2] but bitpos % HOST_BITS_PER_WIDE_INT == 8
* double check with "gcc_assert(bitpos % HOST_BITS_PER_WIDE_INT<2);"
* Target: x86_64-unknown-linux-gnu */
struct {
__CHAR16_TYPE__ S[1];
} a[] = { u"f" , [0].S[0] = u'x' };
[Bug c++/67409] New: tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409
Bug ID: 67409
Summary: tree-cfg.c dereferences a NULL pointer
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
//g++ 5.2.0 sanitizer detects dereferencing a NULL pointer
//gcc-5.2.0/gcc/tree-cfg.c:1342:38: runtime error: member access within null
pointer of type 'struct basic_block_def'
//must be compiled with -fpermissive
//pointer bb is null
//source line "tree main_label = label_for_bb[bb->index].label;"
//double check with "gcc_assert(bb);" immediately before
//Target: x86_64-unknown-linux-gnu
void f()
try
{
goto l2;
} catch (...)
{
l2:;
}
[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #59 from Francois-Xavier Coudert --- Author: fxcoudert Date: Mon Aug 31 14:02:43 2015 New Revision: 227347 URL: https://gcc.gnu.org/viewcvs?rev=227347&root=gcc&view=rev Log: PR libfortran/47571 * acinclude.m4 (LIBGFOR_GTHREAD_WEAK): Reinstate. * configure.ac: Call LIBGFOR_GTHREAD_WEAK again. * config.h.in: Regenerate. * configure: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac
[Bug tree-optimization/67381] genmatch does not honor the order of patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67381 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/67381] genmatch does not honor the order of patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67381 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Aug 31 14:00:16 2015 New Revision: 227344 URL: https://gcc.gnu.org/viewcvs?rev=227344&root=gcc&view=rev Log: 2015-08-31 Richard Biener PR middle-end/67381 * genmatch.c (dt_node::gen_kids): Also treat matches as barrier. Modified: trunk/gcc/ChangeLog trunk/gcc/genmatch.c
[Bug target/67405] ICE on invalid use of struct on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67405 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-31 Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 --- Comment #12 from Marek Polacek --- Author: mpolacek Date: Mon Aug 31 12:46:14 2015 New Revision: 227340 URL: https://gcc.gnu.org/viewcvs?rev=227340&root=gcc&view=rev Log: PR middle-end/67005 * tree-ssa-dce.c (remove_dead_stmt): Also schedule fixup if removing an entry into an irreducible region. * gcc.dg/torture/pr67005.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67005.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-dce.c
[Bug c++/67407] [6 regression] ice in friend_accessible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/67407] [6 regression] ice in friend_accessible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407
--- Comment #2 from Markus Trippelsdorf ---
markus@x4 tmp % cat b.ii
template class A;
template struct B;
template struct B >
{
static int
check ()
{
A a;
a.m_class->m_object;
}
};
template class A
{
public:
template bool operator== (const X &) const;
T *m_class;
};
template
template
bool
A::operator== (const X &) const
{
B::check;
}
class C
{
protected:
template friend struct B;
void *m_object;
};
class F : virtual C
{
};
class G : virtual public C
{
};
class H : F, public G
{
};
class D
{
void onBusMessage (const A &);
A m_pipeline;
};
void
D::onBusMessage (const A &p1)
{
p1 == m_pipeline;
}
markus@x4 tmp % g++ -c b.ii
b.ii: In instantiation of ‘static int B >::check() [with X = H]’:
b.ii:23:3: required from ‘bool A<
>::operator==(const X&) const [with X = A; T = int]’
b.ii:48:9: required from here
b.ii:9:5: internal compiler error: in friend_accessible_p, at cp/search.c:847
a.m_class->m_object;
^
0x75973d friend_accessible_p
../../gcc/gcc/cp/search.c:847
0x759703 friend_accessible_p
../../gcc/gcc/cp/search.c:839
0x7596c2 friend_accessible_p
../../gcc/gcc/cp/search.c:822
0x759942 dfs_accessible_post
../../gcc/gcc/cp/search.c:907
0x756f66 dfs_walk_once_accessible_r
../../gcc/gcc/cp/search.c:1872
0x75708c dfs_walk_once_accessible_r
../../gcc/gcc/cp/search.c:1863
0x75708c dfs_walk_once_accessible_r
../../gcc/gcc/cp/search.c:1863
0x7571cc dfs_walk_once_accessible
../../gcc/gcc/cp/search.c:1891
0x758c69 accessible_p(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/search.c:1015
0x5c5141 enforce_access(tree_node*, tree_node*, tree_node*, int)
../../gcc/gcc/cp/call.c:6091
0x76ea27 perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:337
0x758585 lookup_member(tree_node*, tree_node*, int, bool, int)
../../gcc/gcc/cp/search.c:1337
0x72f47b finish_class_member_access_expr(tree_node*, tree_node*, bool, int)
../../gcc/gcc/cp/typeck.c:2782
0x643920 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16098
0x635a40 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15031
0x636422 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:14442
0x634f43 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:14428
0x63521b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:14614
0x6334f5 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:21158
0x678689 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:21275
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #11 from vries at gcc dot gnu.org --- Resubmitted at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01867.html
[Bug fortran/67174] [6 regression] gfortran.dg/do_iterator.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67174 --- Comment #4 from paul.richard.thomas at gmail dot com --- Dear Rainer, I am not so sure that it is a kernel bug but, rather, it could be a gcc bug that is affected by differences in the kernel. It seems to me that this has crept in since the gfortran error.c was completely reworked to use the gcc error reporting mechanisms. There is now a flag, which determines whether or not the line where the error occurs is displayed or not. I suspect that something is causing this flag to be set or reset. I might not have time today but will certainly test this in the next day or two. Regards Paul On 31 August 2015 at 13:36, ro at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67174 > > Rainer Orth changed: > >What|Removed |Added > > Status|WAITING |RESOLVED > Resolution|--- |INVALID > > --- Comment #3 from Rainer Orth --- > (In reply to Paul Thomas from comment #1) > >> If you run the testcase outside of the testsuite does the error appear but >> without the offending line? I have been plagued by such a problem with an >> F2008 patch that I have prepared. > > It does indeed. It occured to me that this might be the same problem which > causes > > FAIL: gcc.dg/unroll-2.c (test for warnings, line 24) > > on Solaris 11 only (S10 and S12 are both fine). This seems to be a kernel bug > causing truncation of pty output. > > I might xfail both testcases to avoid the noise if this can be confirmed. > > Rainer > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #9 from İsmail Dönmez --- Looks like on MinGW putenv has to be used instead of setenv/unsetenv, dmalcolm can you please have a look? I know MinGW is a Tier-NotSupported platform but it was at least compiling before this change.
[Bug other/65737] [5/6 Regression] ICE (Aborted in crash_signal) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65737 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Matthias Klose --- can't reproduce it anymore. closing.
[Bug fortran/67174] [6 regression] gfortran.dg/do_iterator.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67174 Rainer Orth changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Rainer Orth --- (In reply to Paul Thomas from comment #1) > If you run the testcase outside of the testsuite does the error appear but > without the offending line? I have been plagued by such a problem with an > F2008 patch that I have prepared. It does indeed. It occured to me that this might be the same problem which causes FAIL: gcc.dg/unroll-2.c (test for warnings, line 24) on Solaris 11 only (S10 and S12 are both fine). This seems to be a kernel bug causing truncation of pty output. I might xfail both testcases to avoid the noise if this can be confirmed. Rainer
[Bug c++/67407] [6 regression] ice in friend_accessible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 CC||trippels at gcc dot gnu.org Summary|ice in friend_accessible_p |[6 regression] ice in ||friend_accessible_p Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r227023, reducing.
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 --- Comment #11 from Marek Polacek --- (In reply to Richard Biener from comment #10) > Can you please backport to GCC 5 as well? Sure.
[Bug libstdc++/67408] New: assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
Bug ID: 67408
Summary: assumes that __gthread_mutex_t
and__gthread_recursive_mutex_t are the same types
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The problem is in in:
[...]
#if _GTHREAD_USE_MUTEX_TIMEDLOCK
template
class __timed_mutex_impl
{
[...]
auto __mutex = static_cast<_Derived*>(this)->native_handle();
return !__gthread_mutex_timedlock(__mutex, &__ts);
Here I get this for example:
In file included from
libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:26:0:
libstdc++-v3/include/mutex: In instantiation of 'bool
std::__timed_mutex_impl<_Derived>::_M_try_lock_until(const
std::chrono::time_point&) [with
_Duration = std::chrono::duration
>; _Derived = std::recursive_timed_mutex]':
libstdc++-v3/include/mutex:242:55: required from 'bool
std::__timed_mutex_impl<_Derived>::_M_try_lock_until(const
std::chrono::time_point<_Clock, _Duration>&) [with _Clock =
std::chrono::_V2::steady_clock; _Duration = std::chrono::duration >; _Derived = std::recursive_timed_mutex]'
libstdc++-v3/include/mutex:217:55: required from 'bool
std::__timed_mutex_impl<_Derived>::_M_try_lock_for(const
std::chrono::duration<_Rep, _Period>&) [with _Rep = long long int; _Period =
std::ratio<1ll>; _Derived = std::recursive_timed_mutex]'
libstdc++-v3/include/mutex:332:39: required from 'bool
std::recursive_timed_mutex::try_lock_for(const std::chrono::duration<_Rep1,
_Period1>&) [with _Rep = long long int; _Period = std::ratio<1ll>]'
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:39:54:
required from here
libstdc++-v3/include/mutex:234:37: error: cannot convert
'_Mutex_recursive_Control*' to '__gthread_mutex_t* {aka _Mutex_Control*}' for
argument '1' to 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const
__gthread_time_t*)'
return !__gthread_mutex_timedlock(__mutex, &__ts);
^
[Bug other/65737] [5/6 Regression] ICE (Aborted in crash_signal) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65737 Yvan Roux changed: What|Removed |Added CC||yroux at gcc dot gnu.org --- Comment #5 from Yvan Roux --- Can't reproduce with today's gcc-5-branch head (r227328)
[Bug c++/66786] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66786 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 CC||jason at gcc dot gnu.org Summary|[6 Regression] ICE: |[5/6 Regression] ICE: |Segmentation fault |Segmentation fault Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r214396.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 İsmail Dönmez changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from İsmail Dönmez --- (In reply to Rainer Orth from comment #7) > Fixed for gcc 6. Your patch didnt fix the mingw part. Reopening.
[Bug c++/67407] New: ice in friend_accessible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407 Bug ID: 67407 Summary: ice in friend_accessible_p Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 36273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36273&action=edit gzipped C++ source code The attached code, when compiled by gcc trunk dated 20150829, does this /home/dcb/rpmbuild/BUILD/qt-gstreamer-1.2.0/src/QGst/../QGlib/refpointer.h:48:43 : internal compiler error: in friend_accessible_p, at cp/sea rch.c:847 return self.m_class->m_object == other.m_class->m_object; ^ 0x787fab friend_accessible_p ../../src/trunk/gcc/cp/search.c:847 0x787f72 friend_accessible_p ../../src/trunk/gcc/cp/search.c:839 0x787d6c friend_accessible_p ../../src/trunk/gcc/cp/search.c:822 0x788382 dfs_accessible_post ../../src/trunk/gcc/cp/search.c:907 cp/search.c:847 is gcc_checking_assert (!is_friend (type, scope));
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Rainer Orth --- Fixed for gcc 6.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #6 from Rainer Orth --- Author: ro Date: Mon Aug 31 11:19:42 2015 New Revision: 227337 URL: https://gcc.gnu.org/viewcvs?rev=227337&root=gcc&view=rev Log: Avoid strndup in gcc.c (PR bootstrap/67363) PR bootstrap/67363 * gcc.c (env_manager::xput): Replace strndup by xstrndup. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Rainer Orth changed: What|Removed |Added Assignee|dmalcolm at redhat dot com |ro at gcc dot gnu.org --- Comment #5 from Rainer Orth --- Mine.
[Bug c/67386] missing diagnostic on a use of an undeclared function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386 --- Comment #4 from joseph at codesourcery dot com --- On Fri, 28 Aug 2015, msebor at gcc dot gnu.org wrote: > My reading was that the implicit declaration is intended to be in effect only > for the call to the otherwise undeclared function, but GCC and the other > compilers I've tried let it persist (at least) until the end of the scope and Yes (remember, two scopes are the same if they end at the same point; saying what block the declaration appears in is the same as saying where it ends). > I think Clang and IBM xlc are both wrong since the reference to abs on line 8 > should clearly be diagnosed. The C90 words aren't completely clear about > where > in the innermost block the extern int identifier(); declaration is supposed to > appear but it stands to reason that it should appear where all other > declarations must appear in C90: before any executable code. So diagnosing > the In general, it's a mistake to interpret "X is equivalent to Y" statements in the C standard as referring to a textual substitution; there are plenty of other places where applying such a substitution goes wrong. Cf. cases where something is said to be equivalent to a particular sequence of declarations and statements and it must be implicitly understood that the variable names in those declarations and statements are not special in any way.
[Bug fortran/54833] Don't wrap __builtin_free(a) in if (a != NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54833 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED Assignee|tkoenig at gcc dot gnu.org |fxcoudert at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #3 from Francois-Xavier Coudert --- Fixed on trunk.
[Bug fortran/54833] Don't wrap __builtin_free(a) in if (a != NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54833 --- Comment #2 from Francois-Xavier Coudert --- Author: fxcoudert Date: Mon Aug 31 10:54:36 2015 New Revision: 227336 URL: https://gcc.gnu.org/viewcvs?rev=227336&root=gcc&view=rev Log: PR fortran/54833 * trans.c (gfc_call_free): Don't check if pointer is NULL. * trans.h (gfc_call_free): Adjust comment. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h
[Bug libfortran/48664] Use autoconf test instead of target blacklist to determine weak undefined reference support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48664 --- Comment #3 from Francois-Xavier Coudert --- The commit message went to PR47571 instead of this one: Author: fxcoudert Date: Mon Aug 31 10:37:30 2015 New Revision: 227335 URL: https://gcc.gnu.org/viewcvs?rev=227335&root=gcc&view=rev Log: PR libfortran/47571 * acinclude.m4 (LIBGFOR_GTHREAD_WEAK): Remove. (LIBGFOR_CHECK_WEAKREF): New test. * configure.ac: Call LIBGFOR_CHECK_WEAKREF instead of LIBGFOR_GTHREAD_WEAK. * config.h.in: Regenerate. * configure: Regenerate. * intrinsics/system_clock.c: Use SUPPORTS_WEAKREF instead of SUPPORTS_WEAK and GTHREAD_USE_WEAK. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/system_clock.c
[Bug libfortran/48664] Use autoconf test instead of target blacklist to determine weak undefined reference support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48664 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Francois-Xavier Coudert --- Fixed on trunk.
[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #58 from Francois-Xavier Coudert --- Author: fxcoudert Date: Mon Aug 31 10:37:30 2015 New Revision: 227335 URL: https://gcc.gnu.org/viewcvs?rev=227335&root=gcc&view=rev Log: PR libfortran/47571 * acinclude.m4 (LIBGFOR_GTHREAD_WEAK): Remove. (LIBGFOR_CHECK_WEAKREF): New test. * configure.ac: Call LIBGFOR_CHECK_WEAKREF instead of LIBGFOR_GTHREAD_WEAK. * config.h.in: Regenerate. * configure: Regenerate. * intrinsics/system_clock.c: Use SUPPORTS_WEAKREF instead of SUPPORTS_WEAK and GTHREAD_USE_WEAK. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/system_clock.c
[Bug target/67032] [4.9/5/6 Regression] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 Uroš Bizjak changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.9.4 Summary|Geode optimizations |[4.9/5/6 Regression] Geode |incorrectly return -NaN |optimizations incorrectly ||return -NaN Known to fail||6.0 --- Comment #9 from Uroš Bizjak --- gcc-4.8 does not generate MMX registers, which makes this PR a 4.9+ regression.
[Bug rtl-optimization/67396] [4.9/5/6 regression] Performance regression compiling variadic function with many arguments in RTL DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 Mikhail Maltsev changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |4.9.4 Summary|[4.9/5.0 regression]|[4.9/5/6 regression] |Performance regression |Performance regression |compiling variadic function |compiling variadic function |with many arguments |with many arguments in RTL ||DSE Known to fail||5.2.0
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-31 CC||ro at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Rainer Orth --- Right: using xstrndup instead of strndup is the right fix and matches other parts of the gcc directory. This patch also broke Solaris 10 bootstrap. I'll later commit that fix as obvious. Rainer
[Bug rtl-optimization/67396] [4.9/5.0 regression] Performance regression compiling variadic function with many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 Mikhail Maltsev changed: What|Removed |Added Target|x86_64-*-* | CC||miyuki at gcc dot gnu.org Version|5.2.0 |unknown Target Milestone|4.9.4 |--- Summary|[4.9/5/6 regression]|[4.9/5.0 regression] |Performance regression |Performance regression |compiling variadic function |compiling variadic function |with many arguments in RTL |with many arguments |DSE | --- Comment #7 from Mikhail Maltsev --- (In reply to Paul Pluzhnikov from comment #5) > for j in 500 1000 2000 3000; do perl ./gen_bz18872.pl $j > t.c ; (time > gcc-svn-r227326-rel/bin/gcc -c -O2 t.c) |& grep user; done > > user 0m1.488s > user 0m12.010s > user 1m40.353s > user 5m47.668s Rough fitting suggests that it is O(n^3). I did some profiling and it looks like we get rather deep recursion in alias analysis. Most time is spent in the following call chain: dse_step1 -> scan_insn -> record_store -> canon_true_dependence -> true_dependence1. It has 2 callees, which start deep recursion: memrefs_conflict_p and find_base_term (the latter is invoked twice, the profiler suggests that only the second call, i.e. rtx mem_base = find_base_term (true_mem_addr); is a hot spot). Then we start to recur via these 2 (interleaving) calls: f = val->locs; /* Temporarily reset val->locs to avoid infinite recursion. */ val->locs = NULL; for (l = f; l; l = l->next) if (GET_CODE (l->loc) == VALUE && CSELIB_VAL_PTR (l->loc)->locs && !CSELIB_VAL_PTR (l->loc)->locs->next && CSELIB_VAL_PTR (l->loc)->locs->loc == x) continue; else if ((ret = find_base_term (l->loc)) != 0) 1865else if ((ret = find_base_term (l->loc)) != 0) (gdb) p l->loc $6 = (rtx_def *) (plus:DI (value:DI 2:4321 @0x1abc518/0x1ab8a20) (const_int -8 [0xfff8])) and: /* Go ahead and find the base term for both operands. If either base term is from a pointer or is a named object or a special address (like an argument or stack reference), then use it for the base term. */ rtx base = find_base_term (tmp1); if (base != NULL_RTX && ((REG_P (tmp1) && REG_POINTER (tmp1)) || known_base_value_p (base))) return base; #1 0x0062b92a in find_base_term (x=) at /home/miyuki/gcc/src/gcc/alias.c:1917 1917rtx base = find_base_term (tmp1); (gdb) p tmp1 $7 = (rtx_def *) (value:DI 2:4321 @0x1abc518/0x1ab8a20) It's harder to say what happens in memrefs_conflict_p because it is tail-recursive. This function has ~20 calls of itself. Perhaps basic block profiling will tell more. P.S. The profiler shows an estimate: alias.c:get_addr is invoked ~3 times (that is for 1000 printf arguments).
[Bug tree-optimization/67381] genmatch does not honor the order of patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67381 --- Comment #5 from Richard Biener --- The related bug is PR64084 btw.
[Bug libgomp/67406] OMP SIMD cloning does not generate fma instruction for AVX2 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67406 --- Comment #3 from Jakub Jelinek --- No, you can only use -mfma and affect code generation for all the clones, not just one. Cilk+ has some processor clause or so which allows one to choose the ISA, but only the ISA and not actually further options.
[Bug libgomp/67406] OMP SIMD cloning does not generate fma instruction for AVX2 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67406 --- Comment #2 from vincenzo Innocente --- is there any mechanism to tell gcc to generate the AVX2 clone using fma? I understand it reduces portability still at the moment I have to support mostly Intel platforms. for AMD, gcc suggests to use avx128 so it would anyhow requires a different library to exploit fma4.
[Bug tree-optimization/67390] [6 regression] FAIL: g++.dg/torture/pr64312.C -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67390 Richard Biener changed: What|Removed |Added Target|m68k-*-*|m68k-*-*, arm* --- Comment #1 from Richard Biener --- Also seen on arm IIRC (not on x86_64).
[Bug rtl-optimization/67396] [4.9/5/6 regression] Performance regression compiling variadic function with many arguments in RTL DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Component|target |rtl-optimization Version|unknown |5.2.0 Target Milestone|--- |4.9.4 Summary|[4.9/5.0 regression]|[4.9/5/6 regression] |Performance regression |Performance regression |compiling variadic function |compiling variadic function |with many arguments |with many arguments in RTL ||DSE --- Comment #6 from Richard Biener --- I suppose this is a quite old quadraticness in RTL DSE (or rather find_base_term).
[Bug libgomp/67406] OMP SIMD cloning does not generate fma instruction for AVX2 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67406 --- Comment #1 from Jakub Jelinek --- -mfma is an independent ISA option, not part of -mavx2, there could be CPUs with AVX2, but without FMA, so it can't be enabled. As for AVX512 cloning, what ISAs we clone to is part of the ABI, and at the time when the support has been added the AVX512 support hasn't been there yet. Furthermore, even on the current trunk, the support for the integral masks is really bad, and the ABI says that the masks for AVX512 are passed in general purpose integral registers.
[Bug libgomp/67406] New: OMP SIMD cloning does not generate fma instruction for AVX2 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67406
Bug ID: 67406
Summary: OMP SIMD cloning does not generate fma instruction for
AVX2 target
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
CC: jakub at gcc dot gnu.org
Target Milestone: ---
given
at simdCloning.cc
#pragma omp declare simd notinbranch
float fma(float x,float y, float z) {
return x+y*z;
}
compiled with
c++ -S -fopenmp -Ofast -Wall simdCloning.cc; cat simdCloning.s
will generate the same code for AVX and AVX2 clones
__ZGVdN8vvv__Z3fmafff:
LFB3:
leaq8(%rsp), %r10
LCFI5:
andq$-32, %rsp
vmulps %ymm2, %ymm1, %ymm1
pushq -8(%r10)
pushq %rbp
vaddps %ymm0, %ymm1, %ymm0
while I would have expected
__ZGVdN8vvv__Z3fmafff:
LFB3:
leaq8(%rsp), %r10
LCFI5:
andq$-32, %rsp
vfmadd231ps %ymm2, %ymm1, %ymm0
pushq -8(%r10)
pushq %rbp
this last code has been obtained compiling with -mfma.
unfortunately in this case ALL clones uses avx2 instructions
(so again AVX and AVX2 clones are identical)
btw: is there any reason why the AVX512 clone is not generated?
I am using gcc version 6.0.0 20150801 (experimental) [trunk revision 226463]
(GCC)
