[Bug c++/61040] [4.9/4.10 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3320
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61040 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-03 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.1 Summary|internal compiler error: in |[4.9/4.10 Regression] |gimplify_init_ctor_preeval, |internal compiler error: in |at gimplify.c:3320 |gimplify_init_ctor_preeval, ||at gimplify.c:3320 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r208027.
[Bug target/61026] sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Target||sh*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-03 CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/61002] Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 --- Comment #9 from Andreas Schwab sch...@linux-m68k.org --- It should use the same format as the warning messages. Division by zero at %L [-frange-check]
[Bug target/61026] sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat May 3 07:51:02 2014 New Revision: 210028 URL: http://gcc.gnu.org/viewcvs?rev=210028root=gccview=rev Log: PR target/61026 * config/sh/sh.c: Include stdlib headers before everything else. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug target/61026] sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat May 3 08:17:43 2014 New Revision: 210029 URL: http://gcc.gnu.org/viewcvs?rev=210029root=gccview=rev Log: Back port from mainline PR target/61026 * config/sh/sh.c: Include stdlib headers before everything else. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh.c
[Bug target/61026] sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat May 3 08:21:24 2014 New Revision: 210030 URL: http://gcc.gnu.org/viewcvs?rev=210030root=gccview=rev Log: Back port from mainline PR target/61026 * config/sh/sh.c: Include stdlib headers before everything else. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sh.c
[Bug target/61026] sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Fixed on trunk, 4.9 and 4.8.
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054
--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #8)
/home/manuel/test1/test-gfc-warning.f03:11:0:
arr = (/ INTEGER(KIND=4) :: HUGE(0_8) /) ! { dg-warning conversion from
}
1
Warning: Possible change of value in conversion from INTEGER(8) to
INTEGER(4) at (1) [-Wconversion]
Looks good to me at a glance. However, I have not yet applied the patch and
played around with it.
Thanks for working on this!
Also, is there any case where gcf_linebuf.file-filename !=
LOCATION_FILE(gcf_linebuf.location) ?
Seemingly not. I tried to use:
a) include some_file
b) #include some_file
and the latter using both -cpp and using the pre-processed output as input.
And it always worked.
Also looking at the code in scanner.c, it seems as if it is always set to the
correct value:
get_file (const char *name, enum lc_reason reason ATTRIBUTE_UNUSED)
...
f-filename = xstrdup (name);
...
linemap_add (line_table, reason, false, f-filename, 1);
Thus, on terms of the linebuffer, there should be no reason of having
filename at all. It seems to get used in scanner.c itself - where some of the
diagnostic by-passes the default diagnostic. Either by constructing the
file/line numbers manually or even by calling fprintf(stderr directly.
[One probably should do some clean up there as well… But having the 'proper'
diagnostic for the rest would be a start.]
So the only remaining major issue is the offset. It is not clear to me why
Fortran needs an explicit offset, don't you track locations when parsing
using line-map.c
Seemingly, we don't. The offset within a line is calculated using:
c1 = l1-nextc - l1-lb-line;
and in next_char one simply uses:
c = *gfc_current_locus.nextc++;
For the line map, we just use:
b-location
= linemap_line_start (line_table, current_file-line++, 120);
which gives the line but not the offset.
One might handle this in a more clever way, but can't you use in gfc_warning2,
gfortran's normal locus and use linemap_position_for_column() to map from the
offset to the column?
Another thing I wonder how to handle best is the case of having two locations
in the same line, e.g.
integer, allocatable :: v(:)
allocate (v(3), v(4))
end
that currently prints:
foo.f90:foo.f90:2.10-16:
allocate (v(3), v(4))
1 2
Error: Allocate-object at (1) also appears at (2)
or with line break (note the ):
allocate (v(3),
v(4))
as
foo.f90:foo.f90:2.10:
allocate (v(3),
1
foo.f90:foo.f90:3.10:
v(4))
2
Error: Allocate-object at (1) also appears at (2)
[Bug testsuite/61025] [4.10 regression] FAIL: gfortran.dg/coarray_lib_this_image_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61025 --- Comment #2 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat May 3 09:08:15 2014 New Revision: 210031 URL: http://gcc.gnu.org/viewcvs?rev=210031root=gccview=rev Log: 2014-05-03 Dominique d'Humieres domi...@lps.ens.fr PR fortran/61025 * gfortran.dg/coarray_lib_this_image_1.f90: Adjust the dg-final regexps for -m32. * gfortran.dg/coarray_lib_this_image_2.f90: Likewise. * gfortran.dg/coarray_poly_7.f90: Likewise. * gfortran.dg/coarray_poly_8.f90: Likewise. * gfortran.dg/coarray_poly_9.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_lib_this_image_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_lib_this_image_2.f90 trunk/gcc/testsuite/gfortran.dg/coarray_poly_6.f90 trunk/gcc/testsuite/gfortran.dg/coarray_poly_7.f90 trunk/gcc/testsuite/gfortran.dg/coarray_poly_8.f90
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 --- Comment #8 from Andrew Haley aph at gcc dot gnu.org --- (In reply to Jason Merrill from comment #7) (In reply to Jan Hubicka from comment #6) It is a bit questionable on how precisely define what type transitions are allowed by placement new. This is quite conservative definition except for the requirement that type needs to be large enough to contain the newly built type. We don't need to handle all non-PODs; arrays of (unsigned) char are special under the aliasing rules, so that you can construct any type of object in a char array and access the object representation of any type via a char pointer. You can't randomly change the object stored in a buffer of any other type. While it's true that we can play hardball on this one by insisting that only char arrays should be used with placement new, it wouldn't really do any good. I don't think it would make any real-world code more efficient. It makes sense to play safe by assuming that any object of a non-polymorphic type might be overwritten by placement new.
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054 --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #10) Looks good to me at a glance. However, I have not yet applied the patch and played around with it. Thanks for working on this! Thanks for looking at it. If you have a suggestion for a warning that doesn't use %L, I could produce a simpler but more complete proof-of-concept. Also, is there any case where gcf_linebuf.file-filename != LOCATION_FILE(gcf_linebuf.location) ? Seemingly not. I tried to use: It would simplify the work on this PR to remove it and use LOCATION_FILE() in gfortran. So the only remaining major issue is the offset. It is not clear to me why Fortran needs an explicit offset, don't you track locations when parsing using line-map.c Seemingly, we don't. The offset within a line is calculated using: c1 = l1-nextc - l1-lb-line; and in next_char one simply uses: c = *gfc_current_locus.nextc++; For the line map, we just use: b-location = linemap_line_start (line_table, current_file-line++, 120); which gives the line but not the offset. One might handle this in a more clever way, but can't you use in gfc_warning2, gfortran's normal locus and use linemap_position_for_column() to map from the offset to the column? You cannot insert new locations out of order in a line-map. Perhaps one could create a dummy line-map, but it would be easier if the diagnostics machinery handled arbitrary offsets, so I would favor that. Arbitrary offsets are useful also to other FEs for some special cases anyway. Of course, the two things are not incompatible: 1) gfortran could use the full linemaps for tracking column numbers, thus removing another duplication of code and 2) for particular cases, the diagnostic machinery could handle explicit offsets passed by gfortran. Another thing I wonder how to handle best is the case of having two locations in the same line, e.g. integer, allocatable :: v(:) allocate (v(3), v(4)) end that currently prints: foo.f90:foo.f90:2.10-16: allocate (v(3), v(4)) 1 2 Error: Allocate-object at (1) also appears at (2) or with line break (note the ): allocate (v(3), v(4)) as foo.f90:foo.f90:2.10: allocate (v(3), 1 foo.f90:foo.f90:3.10: v(4)) 2 Error: Allocate-object at (1) also appears at (2) To implement this, the diagnostic machinery should be able to handle two locations first. Then diagnostic_show_locus should handle two locations as well. The particular format used by gfortran will be achieved by playing with the prefix in gcf_diagnostic_starter. The major difficulty is in implementing the one with the line break. A possible solution would be to make diagnostic_build_prefix a hook that can be overriden by the FE and call it from diagnostic_show_locus for each extra line shown. It doesn't seem a lot of work in any case, so I think this is not a show-stopper. But I'd rather start with the simplest cases (for example, those warnings that don't use any explicit %L). However, I don't want to spend a lot of effort on this if there is no interest in the Fortran side. I'm happy to give guidance, to implement things in the common diagnostic machinery and to implement proof-of-concept patches for the Fortran side, but someone else needs to go over the list of Fortran warnings and update them, build and test one by one. As I said, the work can be done incrementally, but I don't have the time to do it all and I'd rather not start if no one on the Fortran side plans to continue it.
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054 --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- One might handle this in a more clever way, but can't you use in gfc_warning2, gfortran's normal locus and use linemap_position_for_column() to map from the offset to the column? You cannot insert new locations out of order in a line-map. Perhaps one could create a dummy line-map, but it would be easier if the diagnostics machinery handled arbitrary offsets, so I would favor that. Arbitrary offsets are useful also to other FEs for some special cases anyway. Of course, the two things are not incompatible: 1) gfortran could use the full linemaps for tracking column numbers, thus removing another duplication of code and 2) for particular cases, the diagnostic machinery could handle explicit offsets passed by gfortran. Or in other words: This PR can be fixed without gfortran tracking column-numbers using line-maps (just using an explicit offset), but you'll need that for fixing PR 53934.
[Bug lto/61043] New: LTO accumulates CPU requirements from all input objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043 Bug ID: 61043 Summary: LTO accumulates CPU requirements from all input objects Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: andysem at mail dot ru Created attachment 32726 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32726action=edit A test case to reproduce the problem I have a test case (attached) with several input files. main.cpp contains generic code that should run on any CPU, and add_sse2.c and add_avx2.c containing optimized code with SSE2 and AVX2 intrinsics, respectively. main.cpp detects CPU features in run time and invokes the optimized code when possible. The problem is when this test is compiled with LTO enabled, the resulting executable contains add_sse2 function with VEX-encoded instructions (i.e. with AVX-128 code instead of legacy SSE2). This does not happen when LTO is not enabled. My guess is that LTO computes the highest required CPU across all input object files (which is one with AVX2 in this case) and generates code for it instead of generating code for the CPU that was specified during the compilation stage. The expected behavior would be to record target-related compiler options for every function and use these options at LTO stage. To compile the test you can use compile.sh. To obtain disassembled code you can use disasm.sh. Look for add_sse2 code in the disassembly.
[Bug target/61044] New: Computed goto on AVR fails to use word-addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044
Bug ID: 61044
Summary: Computed goto on AVR fails to use word-addressing
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dinuxbg at gmail dot com
Created attachment 32727
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32727action=edit
Failed computed goto C example
The computed goto example taken straight from the GCC manual generates
incorrect code for AVR. When doing pointer arithmetic, the compiler fails to
mark labels with gs.
The following snippet from the attached test_fail C function:
static const int array[] = { foo - foo, bar - foo, hack - foo
};
will generate the following rodata:
array.1464:
.word 0
.word .L3-(.L2)
.word .L4-(.L2)
Note that straight labels without arithmetics work just fine (see test_good in
attached cg.c):
array.1472:
.word gs(.L2)
.word gs(.L3)
.word gs(.L4)
I've tested with avr-gcc 4.8.2 from debian sid. But I believe bug is also
present in top of tree.
[Bug target/61044] Computed goto on AVR fails to use word-addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #1 from Dimitar Dimitrov dinuxbg at gmail dot com --- The unofficial PRU GCC port (https://github.com/dinuxbg/gnupru) has the same bug. I haven't tested the following patch on AVR, but a similar change seems to fix the issue for PRU: --- a/gcc/config/avr/predicates.md +++ b/gcc/config/avr/predicates.md @@ -122,7 +122,7 @@ - (match_code code_label,label_ref,symbol_ref,plus,const) + (match_code code_label,label_ref,symbol_ref,plus,minus,const) @@ -133,6 +133,7 @@ case SYMBOL_REF : return SYMBOL_REF_FUNCTION_P (op); case PLUS : +case MINUS :
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Andrew Haley from comment #8) While it's true that we can play hardball on this one by insisting that only char arrays should be used with placement new, it wouldn't really do any good. I don't think it would make any real-world code more efficient. On the contrary, this bug is an example of making real code more efficient, just inappropriately because of the special status of char arrays. We really don't want to have to assume that any random object can invisibly change type, as that would make type-based optimizations pretty useless. As far as I know people always use char arrays for placement new anyway; at least all the examples I've ever seen do.
[Bug tree-optimization/61042] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61042 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-03 CC||jakub at gcc dot gnu.org, ||kyukhin at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|ICE on valid code at -O3 on |[4.10 Regression] ICE on |x86_64-linux-gnu|valid code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r209972.
[Bug testsuite/61025] [4.10 regression] FAIL: gfortran.dg/coarray_lib_this_image_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61025 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per http://gcc.gnu.org/ml/gcc-regression/2014-05/msg00024.html closing as FIXED.
[Bug tree-optimization/61045] New: Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045
Bug ID: 61045
Summary: Wrong constant folding
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
GCC 4.4.7 - 4.10.0 for x86_64 miscompiles the following code.
$ cat test.c
int main (void)
{
long a = 0;
long b = 0x7FFFL;
int t = (a - 2) (b - 1);
if (t != 0) { __builtin_abort(); };
return 0;
}
$ x86_64-unknown-linux-gnu-gcc-4.10.0 test.c -O2
$ ./a.out
Aborted (core dumped)
$ x86_64-unknown-linux-gnu-gcc-4.10.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-4.10.0
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-4.10.0/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/hassy/gcc/configure
--prefix=/usr/local/x86_64-tools/gcc-4.10.0/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib
--disable-nls --enable-languages=c
Thread model: posix
gcc version 4.10.0 20140502 (experimental) (GCC)
[Bug tree-optimization/61045] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Fold introduces signed overflow: long int a = 0; long int b = 9223372036854775807; int t = b + 1 a;
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |4.7.4 Summary|Wrong constant folding |[4.7/4.8/4.9/4.10 ||Regression] Wrong constant ||folding
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com --- Fails also with gcc 4.3.6, works with gcc 4.2.4 and 4.1.2.
[Bug c++/61046] New: [4.8/4.9/4.10 Regression] ICE in lookup_field_1, at cp/search.c:384
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61046
Bug ID: 61046
Summary: [4.8/4.9/4.10 Regression] ICE in lookup_field_1, at
cp/search.c:384
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
4.7 rejects this without an ICE, the ICE is seen on 4.8, 4.9 branches and
trunk.
$ cat tst.cc
#include array
const int i = 0;
std::arrayint, 1 bar = {
[i] = 0
};
$ g++-4.7 -Wall -std=gnu++0x tst.cc
tst.cc:5:3: error: 'std::arrayint, 1ul' has no non-static data member named
'i'
$ g++-4.8 -Wall -std=gnu++0x tst.cc
tst.cc:5:3: internal compiler error: in lookup_field_1, at cp/search.c:384
};
^
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I believe this started with addition of this folding in r117931, but didn't verify it.
[Bug rtl-optimization/61047] New: wrong code at -O1 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
Bug ID: 61047
Summary: wrong code at -O1 on x86_64-linux
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and 4.9.0 mis-compile the following code on x86_64-linux
at -O1 in both 32-bit and 64-bit modes.
This is a regression from 4.8.x and seems related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140503 (experimental) [trunk revision 210026] (GCC)
$
$ gcc-trunk -O0 small.c; a.out
$ gcc-trunk -Os small.c; a.out
$ gcc-4.8.2 -O1 small.c; a.out
$
$ gcc-trunk -O1 small.c
$ a.out
Segmentation fault (core dumped)
$ gcc-4.9.0 -O1 small.c
$ a.out
Segmentation fault (core dumped)
$
-
int a, c, d;
short b;
int
main ()
{
int e[1];
for (; b 2; b++)
{
a = 0;
if (b == 2837)
a = e[b];
if (!(d || b))
for (; c;)
;
}
return 0;
}
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #10 from Harald van Dijk harald at gigawatt dot nl --- (In reply to Jan Hubicka from comment #4) Mine, probably 4.9 regression, too. It is, and Jonathan Wakely's earlier reduction exposes it on 4.9 too. (In reply to Jan Hubicka from comment #6) Can you, please, double check that it fixes the Java issues? With 4.9.0, for me, IcedTea reliably hangs during the build process. I hadn't investigated the problem at all, but with 4.9.0 plus your patch, it builds successfully. What I had looked into was a segmentation fault in Qt (https://bugreports.qt-project.org/browse/QTBUG-38733) and Chromium, both using WebKit, also because of this. Chromium is still building, but for Qt, I can confirm it is also fixed by your patch. (In reply to Jason Merrill from comment #9) As far as I know people always use char arrays for placement new anyway; at least all the examples I've ever seen do. Or a structure containing (possibly indirectly) a character array as its first member, such as aligned_storage. But as long as a pointer to such a structure is indistinguishable from a pointer to the contained character array, that should not be a problem.
[Bug lto/61048] New: compiling with -fsanitize=address crashes GCC if pointers are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048
Bug ID: 61048
Summary: compiling with -fsanitize=address crashes GCC if
pointers are used
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: fab...@ritter-vogt.de
test.cpp:
include iostream
int main()
{
int *i = reinterpret_castint*(0xC100);
std::cout *i std::endl;
}
Compile with:
arm-none-eabi-g++ test.cpp -c -o test.o -fsanitize=address -flto
Link with:
arm-none-eabi-g++ test.o -o test -Wl,-flto
arm-none-eabi-g++ -v:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/opt/nspire/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/4.9.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.9.0/configure --target=arm-none-eabi
--prefix=/opt/nspire/Ndless/ndless-sdk/toolchain/install --enable-interwork
--enable-multilib --enable-languages=c,c++ --with-system-zlib --with-newlib
--with-headers=../newlib-2.0.0/newlib/libc/include --disable-shared
--with-gnu-as --with-gnu-ld --with-float=soft --disable-werror
Thread model: single
gcc version 4.9.0 (GCC)
Result:
lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1124
0x914191 streamer_get_builtin_tree(lto_input_block*, data_in*)
../../gcc-4.9.0/gcc/tree-streamer-in.c:1124
0x6f55d4 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc-4.9.0/gcc/lto-streamer-in.c:1265
0x6f57c1 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
../../gcc-4.9.0/gcc/lto-streamer-in.c:1193
0x50375e lto_read_decls
../../gcc-4.9.0/gcc/lto/lto.c:1879
0x504ef5 lto_file_finalize
../../gcc-4.9.0/gcc/lto/lto.c:2214
0x504ef5 lto_create_files_from_ids
../../gcc-4.9.0/gcc/lto/lto.c:2224
0x504ef5 lto_file_read
../../gcc-4.9.0/gcc/lto/lto.c:2264
0x504ef5 read_cgraph_and_symbols
../../gcc-4.9.0/gcc/lto/lto.c:2967
0x504ef5 lto_main()
../../gcc-4.9.0/gcc/lto/lto.c:3412
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper:
/opt/nspire/Ndless/ndless-sdk/toolchain/install/bin/arm-none-eabi-g++ returned
1 exit status
/opt/nspire/Ndless/ndless-sdk/toolchain/install/arm-none-eabi/bin/ld.real:
lto-wrapper failed
collect2: error: ld returned 1 exit status
It compiles fine if I remove -flto (disregarding undefined references)
[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539 --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have regression tested on x86_64 and the test in Comment #12 works now. Confirmed on x86_64-apple-darwin13.
[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539 --- Comment #22 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- One failure on NIST FM906.f
[Bug middle-end/61045] [4.7/4.8/4.9/4.10 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61045 --- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com --- According to my bisection it did start with r117931.
[Bug c++/61040] [4.9/4.10 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3320
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61040 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed by r209933.209933 *** This bug has been marked as a duplicate of bug 60951 ***
[Bug c++/60951] [4.9/4.10 Regression][C++11] ICE with braced-init-list assignment and constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||b.r.longbons at gmail dot com --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- *** Bug 61040 has been marked as a duplicate of this bug. ***
[Bug libfortran/61035] Crash in getcwd intrinsic due to stack overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61035 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-05/msg00157.htm ||l Last reconfirmed||2014-05-03 Ever confirmed|0 |1 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org --- Patch at http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00157.html
[Bug fortran/56919] [4.7/4.8 Regression] Wrong result for SYSTEM_CLOCK on Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Sat May 3 20:56:26 2014 New Revision: 210041 URL: http://gcc.gnu.org/viewcvs?rev=210041root=gccview=rev Log: PR 56919 Check _POSIX_MONOTONIC_CLOCK. 2014-05-03 Janne Blomqvist j...@gcc.gnu.org Backport from 4.9 PR libfortran/56919 * intrinsics/system_clock.c (GF_CLOCK_MONOTONIC): Check _POSIX_MONOTONIC_CLOCK as well. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/intrinsics/system_clock.c
[Bug fortran/56919] [4.7/4.8 Regression] Wrong result for SYSTEM_CLOCK on Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919 --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Sat May 3 21:03:10 2014 New Revision: 210042 URL: http://gcc.gnu.org/viewcvs?rev=210042root=gccview=rev Log: PR 56919 Check _POSIX_MONOTONIC_CLOCK. 2014-05-04 Janne Blomqvist j...@gcc.gnu.org Backport from 4.9 PR libfortran/56919 * intrinsics/system_clock.c (GF_CLOCK_MONOTONIC): Check _POSIX_MONOTONIC_CLOCK as well. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/intrinsics/system_clock.c
[Bug fortran/56919] [4.7/4.8 Regression] Wrong result for SYSTEM_CLOCK on Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org --- Backported the _POSIX_MONOTONIC_CLOCK check to 4.7/4.8, closing as fixed.
[Bug rtl-optimization/61047] wrong code at -O1 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-03 CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r203895.
[Bug target/60884] [SH] improve inlined strlen-like builtin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||christian.bruel at st dot com
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
With the following patch applied to current trunk (r210026)
Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc(revision 210037)
+++ gcc/config/sh/sh-mem.cc(working copy)
@@ -568,7 +568,7 @@
addr1 = adjust_automodify_address (addr1, SImode, current_addr, 0);
- /*start long loop. */
+ /* start long loop. */
emit_label (L_loop_long);
/* tmp1 is aligned, OK to load. */
@@ -589,29 +589,15 @@
addr1 = adjust_address (addr1, QImode, 0);
/* unroll remaining bytes. */
- emit_insn (gen_extendqisi2 (tmp1, addr1));
- emit_insn (gen_cmpeqsi_t (tmp1, const0_rtx));
- jump = emit_jump_insn (gen_branch_true (L_return));
- add_int_reg_note (jump, REG_BR_PROB, prob_likely);
+ for (int i = 0; i 4; ++i)
+{
+ emit_insn (gen_extendqisi2 (tmp1, addr1));
+ emit_move_insn (current_addr, plus_constant (Pmode, current_addr, 1));
+ emit_insn (gen_cmpeqsi_t (tmp1, const0_rtx));
+ jump = emit_jump_insn (gen_branch_true (L_return));
+ add_int_reg_note (jump, REG_BR_PROB, prob_likely);
+}
- emit_move_insn (current_addr, plus_constant (Pmode, current_addr, 1));
-
- emit_insn (gen_extendqisi2 (tmp1, addr1));
- emit_insn (gen_cmpeqsi_t (tmp1, const0_rtx));
- jump = emit_jump_insn (gen_branch_true (L_return));
- add_int_reg_note (jump, REG_BR_PROB, prob_likely);
-
- emit_move_insn (current_addr, plus_constant (Pmode, current_addr, 1));
-
- emit_insn (gen_extendqisi2 (tmp1, addr1));
- emit_insn (gen_cmpeqsi_t (tmp1, const0_rtx));
- jump = emit_jump_insn (gen_branch_true (L_return));
- add_int_reg_note (jump, REG_BR_PROB, prob_likely);
-
- emit_move_insn (current_addr, plus_constant (Pmode, current_addr, 1));
-
- emit_insn (gen_extendqisi2 (tmp1, addr1));
- jump = emit_jump_insn (gen_jump_compact (L_return));
emit_barrier_after (jump);
/* start byte loop. */
@@ -626,10 +612,9 @@
/* end loop. */
- emit_insn (gen_addsi3 (start_addr, start_addr, GEN_INT (1)));
-
emit_label (L_return);
+ emit_insn (gen_addsi3 (start_addr, start_addr, GEN_INT (1)));
emit_insn (gen_subsi3 (operands[0], current_addr, start_addr));
return true;
I get the following when compiling
unsigned int test (const char* x)
{
return __builtin_strlen (x);
}
with -O2 -m4:
_test:
movr4,r0
tst#3,r0
bf/s.L12
movr4,r1
mov#0,r3
.L4:
mov.l@r1+,r2
cmp/strr3,r2
bf.L4
add#-4,r1
mov.b@r1+,r2
tstr2,r2
bt.L2
mov.b@r1+,r2
tstr2,r2
bt.L2
mov.b@r1+,r2
tstr2,r2
mov#-1,r2
negcr2,r2
addr2,r1
.L2:
movr1,r0
rts
subcr4,r0
.align 1
.L12:
mov.b@r1+,r2
tstr2,r2
bf/s.L12
movr1,r0
rts
subcr4,r0
which is 5 insns shorter than the currently expanded sequence.
It seems that other optimizers are able to figure out that the 4th byte load is
not needed and eliminate it.
Moving the 'emit_insn (gen_addsi3 ...' after the return label allows it to
utilize the subc insn, which is difficult to get otherwise, as combine looks
only at one BB at a time.
Christian, what do you think? Any objections?
[Bug c/61050] New: OpenMP: wrong behavior of 'omp for' on corner cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61050 Bug ID: 61050 Summary: OpenMP: wrong behavior of 'omp for' on corner cases Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: guido at vanguardiasur dot com.ar Created attachment 32728 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32728action=edit example input Note: by infinite loop, we mean something of the form 'for (i=0; i=0; i++)', not considering overflow. #pragma omp for changes the behavior of empty/infinite loops. Some empty loops are entered once per thread, and some infinite loops are either not entered at all or entered once. An example is attached and more are found in [1]. In the attached example, this loop: char i; #pragma omp for for (i=100; i90; i--) printf(Hello %i %i\n, i, omp_get_thread_num()); is entered exactly once, with i = 100, when it should never be entered. There are no parallel directives. We believe this is caused by a miscalculation of the number of iterations, or a wrong empty loop check (or both). The calculated number of iterations (extracted from the assembly) for the previous example is 12, when it should probably be zero. Also, some loops give a negative loop count but are still entered (once). This happens on gcc 4.9.0, 4.8.2 and some older versions too. We've reproduced it easily. We checked the OpenMP specification and it does not mention an exception in these cases. Also note, this behavior does not seem to occur in fortran. gcc -v -save-temps output at http://sprunge.us/TfaC. [1] http://sprunge.us/TbWj http://sprunge.us/NCeA http://sprunge.us/PAZD http://sprunge.us/faTD http://sprunge.us/CIMN
[Bug c++/58582] [c++11] ICE defining and instantiating deleted template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58582 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug c++/58582] [c++11] ICE defining and instantiating deleted template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58582 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Sat May 3 22:44:22 2014 New Revision: 210043 URL: http://gcc.gnu.org/viewcvs?rev=210043root=gccview=rev Log: /cp 2014-05-03 Paolo Carlini paolo.carl...@oracle.com PR c++/58582 * decl.c (grokfndecl): Check duplicate_decls return value for error_mark_node. * pt.c (instantiate_decl): A deleted function is defined. /testsuite 2014-05-03 Paolo Carlini paolo.carl...@oracle.com PR c++/58582 * g++.dg/cpp0x/deleted4.C: New. * g++.dg/cpp0x/deleted5.C: Likewise. * g++.dg/cpp0x/deleted6.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted4.C trunk/gcc/testsuite/g++.dg/cpp0x/deleted5.C trunk/gcc/testsuite/g++.dg/cpp0x/deleted6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/61049] [4.9/4.10 Regression] NIST test FM906 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61049 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Also confirmed it is r208629. Simple fix is to revert that patch and reopen the original bug which is related to CTRL-D on stdin, PR46800
[Bug c++/59498] Pack expansion error in template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
--- Comment #1 from Roy Crihfield rscrihf at gmail dot com ---
Getting the same behavior on 4.9.0 as stable release.
Rewriting the code to use a struct succeeds:
template typename T, typename ...
struct alias { using type = T; };
template typename ...T
using variadic_alias = typename aliasT...::type;
[Bug lto/61043] LTO accumulates CPU requirements from all input objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org --- Yes LTO doesn't support different options for different files, and combines some of them (which happens in your case) and ignores some others. You could use tag the functions in the different file with __attribute__(target(...)) This will also allow automatic switching. Arguably gcc should do this automatically for LTO, but unfortunately it doesn't Or alternatively don't compile the file that needs the changed options with LTO
[Bug target/61051] New: Duplicated instructions in both conditional branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61051
Bug ID: 61051
Summary: Duplicated instructions in both conditional branches
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le-grtev4-linux-gnu
Source code:
extern int* foo1 ( long* );
extern int *foo2 ( long *, long *);
extern void foo3 (long, long);
void bar()
{
long d, f, x, s, r;
int *p;
d = 1;
if (foo1(r))
{
p = foo2( d, x);
if( x != *p )
s = 1;
else
s = 2;
if( r 0 )
f = 1 + d;
else
f = d;
foo3 (f, d);
*p = s;
}
}
Compile it with options -O2 -m64 -mcpu=power8, gcc generates:
bar:
0:addis 2,12,.TOC.-0b@ha
addi 2,2,.TOC.-0b@l
.localentrybar,.-bar
mflr 0
std 30,-16(1)
std 31,-8(1)
li 9,1
std 0,16(1)
stdu 1,-80(1)
addi 3,1,32
std 9,48(1)
bl foo1
nop
cmpdi 7,3,0
beq 7,.L1
addi 3,1,48
addi 4,1,40
bl foo2
nop
ld 10,40(1)
li 30,1
lwa 9,0(3)
mr 31,3
cmpd 7,9,10
beq 7,.L12 // C
ld 9,32(1) // A1
cmpdi 7,9,0 // A2
ble 7,.L4
.L13:
ld 4,48(1)
addi 3,4,1
.L5:
bl foo3
nop
stw 30,0(31)
.L1:
addi 1,1,80
ld 0,16(1)
ld 30,-16(1)
ld 31,-8(1)
mtlr 0
blr
.p2align 4,,15
.L12:
ld 9,32(1) // B1
li 30,2
cmpdi 7,9,0 // B2
bgt 7,.L13
.L4:
ld 3,48(1)
mr 4,3
b .L5
.long 0
.byte 0,0,0,1,128,2,0,0
.sizebar,.-bar
Instruction C is a conditional branch. In both branches A1 and B1 are same
instructions, they can be moved to before C. If we use a different conditional
register, instructions A2 and B2 can also be moved before C.
