[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 --- Comment #26 from Iain Sandoe --- Author: iains Date: Sat Jun 13 07:55:05 2015 New Revision: 224451 URL: https://gcc.gnu.org/viewcvs?rev=224451&root=gcc&view=rev Log: gcc: PR bootstrap/66448 * passes.c (rest_of_decl_compilation): Do not register globals for early debug if they are declared in built-ins. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c
[Bug fortran/66528] New: unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66528 Bug ID: 66528 Summary: unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- May be related to PR 66175 ig25@linux-fd1f:~/Krempel/Tree> gfortran -fmax-errors=1 unbal.f90 unbal.f90:5:5: end 1 Error: END IF-Anweisung bei (1) erwartet Kompilierung wegen -fmax-errors=1 beendet. *** Error in `/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951': free(): invalid pointer: 0x01cfefa8 *** === Backtrace: = /lib64/libc.so.6(+0x7364f)[0x7fb028db564f] /lib64/libc.so.6(+0x78eae)[0x7fb028dbaeae] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951(_Z17diagnostic_finishP18diagnostic_context+0x5c)[0x126b11c] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951(_Z30diagnostic_action_after_outputP18diagnostic_context12diagnostic_t+0x1a2)[0x126bf12] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951(_Z15gfc_error_checkv+0x6c)[0x63fb0c] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x687e48] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x689741] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x68ba0d] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x68c431] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x68ca07] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951(_Z14gfc_parse_filev+0x848)[0x68e168] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x6ce643] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0xbca44f] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951(_ZN6toplev4mainEiPPc+0x73d)[0x61033d] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951(main+0x2a)[0x6126ea] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fb028d63be5] /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/f951[0x612ad5] === Memory map:
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||ebotcazou at gcc dot gnu.org
Resolution|--- |WORKSFORME
--- Comment #1 from Eric Botcazou ---
> consider the following code snippet (c++):
>
> void ampamp(int x, int y) {
> if (x < 3 && y > 10 )
> printf("%d%d", x, y);
> }
>
> void amp(int x, int y) {
> if ((x < 3) & (y > 10) )
> printf("%d%d", x, y);
> }
>
>
> the assembly code generated by g++ (all versions I tested with optimization
> flag `-O3'), is not optimal (see the link on the bottom of this message).
> Basically, for both methods, the generated assembly code is identical.
An optimizing compiler should generate the same code in both cases, either with
or without branches, whatever form is deemed the fastest for the target, since
there are no side-effects involved in the evaluation of the comparisons.
> As a side note: the code by intel's compiler (ICC) is however generating
> optimal code for such scenarios, at least for versions icc13, and icc15 that
> I've tested.
One of the forms is necessarily not optimal (unless they are equivalent).
[Bug fortran/66528] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66528 --- Comment #1 from Thomas Koenig --- Much better with a test case, of course. program main read (*,*) n if (n<0) then print *,foo end print *,bar end program main
[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66528 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||5.1.0 Keywords||error-recovery Last reconfirmed||2015-06-13 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Summary|unbalanced IF/ENDIF with|[6 Regression] unbalanced |-fmax-errors=1 causes |IF/ENDIF with |invalid free|-fmax-errors=1 causes ||invalid free Known to fail||6.0 --- Comment #2 from Dominique d'Humieres --- > Much better with a test case, of course. Indeed!-) Revision r223447 (2015-05-20) gives Error: END IF statement expected at (1) compilation terminated due to -fmax-errors=1. Revision r223694 (2015-05-26) gives compilation terminated due to -fmax-errors=1. f951(2326,0x7fff7bef0300) malloc: *** error for object 0x1412fd9a8: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug (null):0: confused by earlier errors, bailing out f951(2326,0x7fff7bef0300) malloc: *** error for object 0x142002200: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Usual suspect r223677 (pr66082).
[Bug bootstrap/66508] Attempt to Compile gcc-6.0 on OSX 10.9.4 cause segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66508 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- (In reply to Fan You from comment #3) > (In reply to Dominique d'Humieres from comment #2) > > Duplicate of pr66448? Which revision are you using? > > Just updated and tried again, get the same result. > > Revision: 224410 > > After changing > > get similar error as pr66448 > > /Users/jieyuandai/src/gcc/gcc/dwarf2out.c:5693:1: error: ‘void > check_die(dw_die_ref)’ defined but not used [-Werror=unused-function] > check_die (dw_die_ref die) > ^ > cc1plus: all warnings being treated as errors I think that should have been fixed by 224431, and Darwin bootstrap (pr66448) should be OK as of r224451. Let us know if problems persist
[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66528 Thomas Koenig changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #2) > Usual suspect r223677 (pr66082). I don't believe that a change to trans-array.c can cause a parsing failure. I would rather suspect r223614 . Here is the first error reported by valgrind: ==1154== Invalid free() / delete / delete[] / realloc() ==1154==at 0x4C28ADC: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1154==by 0x126B11B: diagnostic_finish(diagnostic_context*) (diagnostic.c:230) ==1154==by 0x126BF11: diagnostic_action_after_output(diagnostic_context*, diagnostic_t) (diagnostic.c:566) ==1154==by 0x63FB0B: gfc_error_check() (error.c:1384) ==1154==by 0x687E47: decode_statement() (parse.c:554) ==1154==by 0x689740: next_statement() (parse.c:1048) ==1154==by 0x68BA0C: parse_executable(gfc_statement) (parse.c:4593) ==1154==by 0x68C430: parse_executable(gfc_statement) (parse.c:3519) ==1154==by 0x68CA06: parse_progunit(gfc_statement) (parse.c:4976) ==1154==by 0x68E167: gfc_parse_file() (parse.c:5424) ==1154==by 0x6CE642: gfc_be_parse_file() (f95-lang.c:215) ==1154==by 0xBCA44E: compile_file() (toplev.c:560) ==1154== Address 0x1cfefa8 is 8 bytes inside data symbol "_ZL12error_buffer"
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Iain Sandoe --- fixed
[Bug tree-optimization/66522] handle casts in nr of iterations in try_transform_to_exit_first_loop_alt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66522 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, patch --- Comment #2 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00965.html
[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168 --- Comment #13 from Patrick Palka --- Author: ppalka Date: Sat Jun 13 16:11:15 2015 New Revision: 224455 URL: https://gcc.gnu.org/viewcvs?rev=224455&root=gcc&view=rev Log: Emit -Waddress warnings for comparing address of reference against NULL gcc/c-family/ChangeLog: PR c++/65168 * c-common.c (c_common_truthvalue_conversion): Warn when converting an address of a reference to a truth value. gcc/cp/ChangeLog: PR c++/65168 * typeck.c (cp_build_binary_op): Warn when comparing an address of a reference against NULL. gcc/testsuite/ChangeLog: PR c++/65168 g++.dg/warn/Walways-true-3.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Walways-true-3.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66065] ICE on assignment to deferred-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66065 --- Comment #3 from Dominique d'Humieres --- > Do you know if anyone is working on fixing this bug? Nobody as far as know. > Would it be worthwhile for me to mail the gfortran developers list for an > update? see my answer at https://gcc.gnu.org/ml/fortran/2015-06/msg00047.html (I did my best to remain nice!-).
[Bug ada/66529] New: terminals.c: sizeof pointer memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66529 Bug ID: 66529 Summary: terminals.c: sizeof pointer memaccess Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: pini_os at yahoo dot fr Target Milestone: --- Compiling Ada frontend with -Wsizeof-pointer-memaccess reports a warning because the bzero call in function 'child_static_tty' in gcc/ada/terminals.c is: bzero(&s, sizeof (&s)); but it should be: bzero(&s, sizeof (s));
[Bug ada/65490] terminals.c:1266:21: warning: argument to ‘sizeof’ in ‘bzero’ call is the same expression as the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65490 Pierre-Nicolas Clauss changed: What|Removed |Added CC||pini_os at yahoo dot fr --- Comment #4 from Pierre-Nicolas Clauss --- *** Bug 66529 has been marked as a duplicate of this bug. ***
[Bug ada/66529] terminals.c: sizeof pointer memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66529 Pierre-Nicolas Clauss changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Pierre-Nicolas Clauss --- Duplicate entry *** This bug has been marked as a duplicate of bug 65490 ***
[Bug debug/63623] Lots of functions get -fvar-tracking silently turned off unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63623 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug libstdc++/66530] New: libstdc++ testsuite links to incorrect shared libstdc++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530 Bug ID: 66530 Summary: libstdc++ testsuite links to incorrect shared libstdc++ library Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jy38 at zips dot uakron.edu Target Milestone: --- Host: x86_64-pc-cygwin Target: x86_64-pc-cygwin Build: x86_64-pc-cygwin While running the testsuite for libstdc++, I noticed that the generated test programs do not appear to be linking to the "correct" libstdc++ shared library (that is, the libstdc++ that was generated in the build tree). As a result, the testsuite generates erroneous test results even though I have modified various files in the local source tree so that it should not. Here's an excerpt from libstdc++.log containing the command-line used to generate test program "hexfloat" (27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc) and its subsequent failure: extra_tool_flags are: -std=gnu++11 Executing on host: /cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc/xg++ -shared-libgcc -B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc -nostdinc++ -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem /usr/local/x86_64-pc-cygwin/include -isystem /usr/local/x86_64-pc-cygwin/sys-include -B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include -I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/libsupc++ -I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/include/backward -I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/util /cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc -std=gnu++11 ./libtestc++.a -Wl,--gc-sections -liconv -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/filesystem/.libs -o ./hexfloat.exe(timeout = 600) spawn /cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc/xg++ -shared-libgcc -B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc -nostdinc++ -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem /usr/local/x86_64-pc-cygwin/include -isystem /usr/local/x86_64-pc-cygwin/sys-include -B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include -I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/libsupc++ -I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/include/backward -I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/util /cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc -std=gnu++11 ./libtestc++.a -Wl,--gc-sections -liconv -L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/filesystem/.libs -o ./hexfloat.exe PASS: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/gcc:/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs::/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/gcc:/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs spawn [open ...] assertion "os && std::stod(os.str()) == d" failed: file "/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc", line 53, function: void test01() FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test I've confirmed that the problem persists even with a separate test program outside of the testsuite (compiled and run with pretty much the same flags and LD_LIBRARY_PATH seen above). More tellingl
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520
--- Comment #2 from Fisnik ---
(In reply to Eric Botcazou from comment #1)
> > consider the following code snippet (c++):
> >
> > void ampamp(int x, int y) {
> > if (x < 3 && y > 10 )
> > printf("%d%d", x, y);
> > }
> >
> > void amp(int x, int y) {
> > if ((x < 3) & (y > 10) )
> > printf("%d%d", x, y);
> > }
> >
> >
> > the assembly code generated by g++ (all versions I tested with optimization
> > flag `-O3'), is not optimal (see the link on the bottom of this message).
> > Basically, for both methods, the generated assembly code is identical.
>
> An optimizing compiler should generate the same code in both cases, either
> with or without branches, whatever form is deemed the fastest for the
> target, since
> there are no side-effects involved in the evaluation of the comparisons.
>
> > As a side note: the code by intel's compiler (ICC) is however generating
> > optimal code for such scenarios, at least for versions icc13, and icc15 that
> > I've tested.
>
> One of the forms is necessarily not optimal (unless they are equivalent).
I do not quite agree. If the first operand is "always" true, than the version
with double ampersand `&&' is faster. But if probability of the first operand
being true is around 0.5, then the version with single `&' is faster, given
that the compiler generates the correct assembly, i.e., a single jump. The
reason for this is the branch misprediction penalty, which is severe at
probabilities around 0.5.
I already did experiments with both methods `&', and `&&', and varying
probabilities for predicates being true.
The difference (in speed) is around factor 2.3, as the selectivity of the first
predicate approaches 0.5, (i.e., the probability of the first operand being
true -> 0.5).
That is, the method with single ampersand with beat clearly the method with
double ampersand.
The predicates I used were simple, but for more expensive predicates the
difference is even worse.
If still not convinced, read the paper: "Conjunctive selection conditions in
main memory" by K.Ross.
There should be at least some flag available, such that we can set such a flag
and have the compiler generate only a single jump for the method with single
ampersand.
[reply] [-] Comment 4
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #14 from Jim Wilson --- Created attachment 35775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35775&action=edit A possibly better patch, to modify ARM port to stop changing signed HI/QI to unsigned. This would require performance testing to see what the effect is. This is a simpler patch than trying to change the out-of-ssa pass.
[Bug c/66532] New: Source file deleted when we use gcc compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66532 Bug ID: 66532 Summary: Source file deleted when we use gcc compile Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yongjin.ohn at lge dot com Target Milestone: --- Hello guys. I'm newbie about the GCC compiler. Also, my english skill is poor, please understand it. Actually, When I compile using below command, my source are deleted. gcc -o mysource.c mysource I know this command is wrong. but I think that this is a problem. because user can make a mistake. Also user can't recover his source code everything. So, I think that If user input the like upper commend, we can change the parameter order or backup the source file. If you agree this situation, I'll try upload the patch.
[Bug c/29192] gcc will delete the c_source_file.c without any alarm!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29192 Andreas Schwab changed: What|Removed |Added CC||yongjin.ohn at lge dot com --- Comment #2 from Andreas Schwab --- *** Bug 66532 has been marked as a duplicate of this bug. ***
[Bug c/66532] Source file deleted when we use gcc compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66532 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 29192 ***
