[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- See http://www.gnu.org/software/make/manual/html_node/Overriding.html#Overriding Either use make STAGE1_CFLAGS=blah or use make -e to take values from the environment.
[Bug c++/59032] [4.8 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032 --- Comment #9 from vries at gcc dot gnu.org --- Author: vries Date: Mon Dec 2 08:37:23 2013 New Revision: 205584 URL: http://gcc.gnu.org/viewcvs?rev=205584root=gccview=rev Log: Handle vector increment/decrement in build_unary_op 2013-11-27 Tom de Vries t...@codesourcery.com Marc Glisse marc.gli...@inria.fr PR c++/59032 * c-typeck.c (build_unary_op): Allow vector increment and decrement. * typeck.c (cp_build_unary_op): Allow vector increment and decrement. * c-c++-common/pr59032.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr59032.c Modified: branches/gcc-4_8-branch/gcc/c/ChangeLog branches/gcc-4_8-branch/gcc/c/c-typeck.c branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/typeck.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/59037] [4.8/4.9 Regression] ICE when accessing invalid element (nelts + 1) of vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Mon Dec 2 08:37:09 2013 New Revision: 205583 URL: http://gcc.gnu.org/viewcvs?rev=205583root=gccview=rev Log: Don't create out-of-bounds BIT_FIELD_REF. 2013-11-27 Tom de Vries t...@codesourcery.com Marc Glisse marc.gli...@inria.fr PR middle-end/59037 * semantics.c (cxx_fold_indirect_ref): Don't create out-of-bounds BIT_FIELD_REF. * fold-const.c (fold_indirect_ref_1): Don't create out-of-bounds BIT_FIELD_REF. * gimplify.c (gimple_fold_indirect_ref): Same. * c-c++-common/pr59037.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr59037.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/semantics.c branches/gcc-4_8-branch/gcc/fold-const.c branches/gcc-4_8-branch/gcc/gimplify.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/59032] [4.8 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from vries at gcc dot gnu.org --- Fixed on trunk and 4.8 branch.
[Bug middle-end/59037] [4.8/4.9 Regression] ICE when accessing invalid element (nelts + 1) of vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from vries at gcc dot gnu.org --- Fixed on trunk and 4.8 branch.
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 djfd at mail dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from djfd at mail dot ru --- (In reply to Jonathan Wakely from comment #3) See http://www.gnu.org/software/make/manual/html_node/Overriding.html#Overriding Either use make STAGE1_CFLAGS=blah or use make -e to take values from the environment. Hi Jonathan well, your approach to the problem solving is a few better: rm -rf bld/gcc mkdir bld/gcc 2/dev/null ; cd bld/gcc export STAGE1_CFLAGS=--sysroot=/ export STAGE1_CXXFLAGS=--sysroot=/ ../../gcc-4.8.2/configure \ --prefix=$PFX \ --with-gmp=$PFX \ --with-mpfr=$PFX\ --with-mpc=$PFX \ make STAGE1_CFLAGS=$STAGE1_CFLAGS STAGE1_CXXFLAGS=$STAGE1_CXXFLAGS ^C find -name config.status -print0 | xargs -0 egrep 'C(XX)?FLAGS' ./config.status:S[CXXFLAGS]=-g -O2 ./config.status:S[CFLAGS]=-g -O2 ./libiberty/config.status:S[CFLAGS]=--sysroot=/ ./lto-plugin/config.status:S[CFLAGS]=--sysroot=/ ./gcc/config.status:S[CXXFLAGS]=--sysroot=/ ./gcc/config.status:S[CFLAGS]=--sysroot=/ ./intl/config.status:S[CFLAGS]=--sysroot=/ The only thing. pls note on upper two string of search results. Still default -g O2. ie, instead of just specifying CFLAGS/CXXFLAGS to be used at all process stages, including the congigure pass (by either of means: prefixed to configure, passed to make directly or via -e swithch) I will need to have C(XX)?FLAGS set (for configure purposes, otherwise it wont work) and for stage1 STAGE1_C(XX)?FLAGS, that is doubling [my] configuration efforts. Seems to be a few illogical, but it is ok. I have already found my way of handling that, namely: sed -ri 's/^(stage1_cflags=-g)$/\1 $CFLAGS/' configure Was it funny? Certainly. So why am I trying to prevent others from doing same?? Best Regards
[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added Version|4.9.0 |4.8.3 --- Comment #5 from Stupachenko Evgeny evstupac at gmail dot com --- It is still reproduced on 4.8 compiler. Do you have a patch on this?
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- You might need also BUILD_CXXFLAGS/BUILD_CFLAGS set too. Then again the easier way of fixing this is just set CC to include the option you need like: CC=gcc --sysroot=/ CXX=g++ --sysroot=/ This allows for better control of the first stage compiler than setting the weird options for the other stages. What options are you really trying to pass to the first stage compiler?
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 djfd at mail dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #6 from djfd at mail dot ru --- Well, I can use CC=gcc --sysroot=/ approach too. And did try it. But at some stage it stop working too. Sorry, I cannot recall what exactly was wrong with this method, and too lazy to reproduce it. It seems some parts are using g++ for linking in which case compilation flags are dropped off somehow (but I am unsure, so may be wrong). Just FYI. Current behaviour is unexpected. User passing the flags globally does expect they will be propagated down and not stopped at high (top level configure) level. I did spent a day trying to see why the flags passed do not work. And there will be probaly only 1/1000 user faced to this. Hopefully he will have enough sklls to see what is going wrong. I am trying to pass exactly sysroot switch and a few associated switches. Why? Just because --with-sysroot option works, at my opinion, not so good. eg. if I have --with-sysroot set, then, say, --with-gmp switch is enough to be set as --with-gmp==relative/to/sysroot but it does not work at configure stage (cannot find gmp.h, because configure gcc calls are not affected by that --with-sysroot). If I set an absolute paths for --with-gmp along with the --with-sysroot then configure stage works fine, but I got a linker error like this: cannot find /sysroot/lib/some-lib.so within /syroot/lib/sysroot/lib (like this, just from memory).
[Bug tree-optimization/59362] [4.9 Regression] Abort in fini_object_sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31345 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31345action=edit gcc49-pr59362.patch The problem is that the new stmt folding in the objsz pass can create new SSA_NAMEs and the code wasn't prepared for that.
[Bug bootstrap/59199] [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- In fact we have the same without LTO ... _31 = aloopD.38206_74-numD.37604; ... # DEBUG ptrD.42029 = aloopD.38206 but checking doesn't catch it. Which is because get_expr_operands () has an early out on ADDR_EXPRs which are is_gimple_min_invariant. In the specific LTO case it doesn't work because decl_address_invariant_p doesn't return true as DECL_CONTEXT is different from current_function_decl. We input a non-prevailing function body it seems, which isn't really supported as we've already munged trees enough to confuse all sorts of predicates. Why do we need stmts at all here? Isn't it enough to input the CFG? Honza?
[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 --- Comment #4 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #3) print *, a I have not yet completely understood why, but the call gfc_conv_expr_descriptor yields a unit stride. We have a choice here: (i) We use the 'span' variable that is used for pointers to some useful effect. Ideally, this should be accompanied by passing of the 'span' variable to pointer formal arguments in function calls. That way, even if kludgy we would have a full implementation of the F95(!) standard (see for example PR40737 + others that I cannot find right now); or (ii) That we attach 'span' to pointer array descriptors; or (iii) We recognised one the the ASSOCIATE todos, which is the make a temporary when needed and write the selector result to that temporary. This is also required for SELECT TYPE. Examples are where the selector is a function call. (ii)Would cause a diversion from the array descriptor reform but are we really in a position to implement that? Both Tobias and I are taken by daytime work for the foreseeable future. It certainly would be a clean way to proceed. (iii) Must be done sometime... soon. It could be used to fix this case using write-in/write-out but would not fix the F95 problems. I am prepared to make this my next gfortran job. I would suggest (i) or (ii) followed by (iii). Cheers Paul
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #1 from Markus Trippelsdorf octoploid at yandex dot com --- Created attachment 31346 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31346action=edit preprocessed file Testcase.
[Bug bootstrap/59199] [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31347action=edit fixed patch In testing.
[Bug c++/59366] New: A friend function template defined in a class is found without ADL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59366
Bug ID: 59366
Summary: A friend function template defined in a class is found
without ADL
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Reduced test:
struct X
{
//friend void f(int) {} // #1
template class T friend void f(T) {} // #2
};
int main()
{
f(5); // #3
}
The function in #1 is correctly not found at #3. The template
at #2 is, which shouldn't happen since such a friend should be
found by ADL only, and there's no ADL going on here.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #2 from Markus Trippelsdorf octoploid at yandex dot com ---
22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
22211 {
22212 xpparam_t xpp = {0};
22213 xdemitconf_t xecfg = {0};
22214 xdemitcb_t ecb = {((void *)0)};
22215
22216 xpp.flags = xdl_opts;
22217 xecfg.ctxlen = ctxlen;
22218 xecfg.hunk_func = hunk_func;
22219 ecb.priv = cb_data;
0 return xdi_diff(file_a, file_b, xpp, xecfg, ecb);
1 }
2
xdemitconf_t xecfg = {0}; is the problematic line.
If I leave the variable uninitialized the issue goes away.
The difference of:
cc -S -c -O2 -march=native blame.i
cc -S -c -O2 blame.i
@@ -256,38 +256,36 @@
.LCOLDB5:
.text
.LHOTB5:
- .p2align 5,,31
+ .p2align 4,,15
.type diff_hunks, @function
diff_hunks:
.LFB104:
.cfi_startproc
- subq$88, %rsp
- .cfi_def_cfa_offset 96
+ pushq %rbx
+ .cfi_def_cfa_offset 16
+ .cfi_offset 3, -16
+ movq%rdi, %r11
+ movq%rcx, %rbx
xorl%eax, %eax
-.L31:
- movl%eax, %r9d
- addl$32, %eax
- cmpl$32, %eax
- movq$0, 32(%rsp,%r9)
- movq$0, 40(%rsp,%r9)
- movq$0, 48(%rsp,%r9)
- movq$0, 56(%rsp,%r9)
- jb .L31
- leaq32(%rsp), %r10
- movq%rdx, 32(%rsp)
- movq%rcx, 72(%rsp)
- addq%r10, %rax
+ movl$6, %ecx
+ subq$80, %rsp
+ .cfi_def_cfa_offset 96
+ leaq32(%rsp), %rdi
movq%r8, 16(%rsp)
- movq%rsp, %rdx
- movq$0, (%rax)
- movq$0, 8(%rax)
leaq16(%rsp), %r8
- movslq xdl_opts(%rip), %rax
- movq%r10, %rcx
movq$0, 24(%rsp)
+ rep stosq
+ movslq xdl_opts(%rip), %rax
+ leaq32(%rsp), %rcx
+ movq%rdx, 32(%rsp)
+ movq%r11, %rdi
+ movq%rsp, %rdx
+ movq%rbx, 72(%rsp)
movq%rax, (%rsp)
callxdi_diff
- addq$88, %rsp
+ addq$80, %rsp
+ .cfi_def_cfa_offset 16
+ popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 --- Comment #7 from djfd at mail dot ru --- just noticed. there is ./config/mt-ospace file with the contents # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os it is resulting to next lines in Makefile: host and target specific makefile fragments come in here. CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os ### BUT at that moment we have already C(XX)?FLAGS_for target set earlier: CFLAGS_FOR_TARGET = -g --sysroot=/ CXXFLAGS_FOR_TARGET = -g --sysroot=/ thus, when we choose to optimize target libraries for size, our custom flags will be overwritten. Maybe it would be better to have ./config/mt-ospace like this: # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET += -g -Os CXXFLAGS_FOR_TARGET += -g -Os (append instead of replace)
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to djfd from comment #7) just noticed. there is ./config/mt-ospace file with the contents That is a prebuilt target config. You can do the same for you need too. FOR_TARGET is the target libraries options that are used. GCC Makefile options are different from most Makefiles due to not all options supplied work for the first or later stages. Think you start with something besides GCC which don't take say -fmyoption but the new GCC does. You cannot simply set CFLAGS to -fmyoption as that won't work. The other way around is the same issue. This is why CFLAGS is only done for host libraries. # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os it is resulting to next lines in Makefile: host and target specific makefile fragments come in here. CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os ### BUT at that moment we have already C(XX)?FLAGS_for target set earlier: CFLAGS_FOR_TARGET = -g --sysroot=/ CXXFLAGS_FOR_TARGET = -g --sysroot=/ thus, when we choose to optimize target libraries for size, our custom flags will be overwritten. Maybe it would be better to have ./config/mt-ospace like this: # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET += -g -Os CXXFLAGS_FOR_TARGET += -g -Os (append instead of replace)
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- Marking as works for me as it is working as documented.
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Full runtime testcase:
__attribute__((noinline, noclone)) int
foo (int *x, int y)
{
int z = *x;
if (y z y = 16)
while (y z)
z *= 2;
return z;
}
int
main ()
{
int i;
for (i = 1; i 17; i++)
{
int j = foo (i, 16);
int k;
if (i = 8 i = 15)
k = 16 + (i - 8) * 2;
else if (i = 4 i = 7)
k = 16 + (i - 4) * 4;
else if (i == 3)
k = 24;
else
k = 16;
if (j != k)
__builtin_abort ();
j = foo (i, 7);
if (i = 7)
k = i;
else if (i = 4)
k = 8 + (i - 4) * 2;
else if (i == 3)
k = 12;
else
k = 8;
if (j != k)
__builtin_abort ();
}
return 0;
}
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r188776 or r188780.
[Bug tree-optimization/59356] [4.9 regression] ACATS C52102A and C52102C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59356 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|ada |tree-optimization --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Recategorizing.
[Bug tree-optimization/59356] [4.9 regression] ACATS C52102A and C52102C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59356 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Dec 2 11:20:14 2013 New Revision: 205585 URL: http://gcc.gnu.org/viewcvs?rev=205585root=gccview=rev Log: PR tree-optimization/59356 * tree-dfa.h (get_addr_base_and_unit_offset_1) case ARRAY_REF: Do the offset computation using the precision of the index type. Added: trunk/gcc/testsuite/gnat.dg/opt30.adb Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dfa.h
[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365 djfd at mail dot ru changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #10 from djfd at mail dot ru --- (In reply to Andrew Pinski from comment #8) (In reply to djfd from comment #7) just noticed. there is ./config/mt-ospace file with the contents That is a prebuilt target config. You can do the same for you need too. FOR_TARGET is the target libraries options that are used. GCC Makefile options are different from most Makefiles due to not all options supplied work for the first or later stages. Think you start with something besides GCC which don't take say -fmyoption but the new GCC does. You cannot simply set CFLAGS to -fmyoption as that won't work. The other way around is the same issue. This is why CFLAGS is only done for host libraries. # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os it is resulting to next lines in Makefile: host and target specific makefile fragments come in here. CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os ### BUT at that moment we have already C(XX)?FLAGS_for target set earlier: CFLAGS_FOR_TARGET = -g --sysroot=/ CXXFLAGS_FOR_TARGET = -g --sysroot=/ thus, when we choose to optimize target libraries for size, our custom flags will be overwritten. Maybe it would be better to have ./config/mt-ospace like this: # Build libraries optimizing for space, not speed. CFLAGS_FOR_TARGET += -g -Os CXXFLAGS_FOR_TARGET += -g -Os (append instead of replace) Well, that is fine. Beside the options I am using ( btw, these are understandable by both compilers, working one and the one to be built), conceptual question still remains. Is it ok if some prebuilt target config *destroys* already established (it does not matter what way was used: prepending to configure, passing to make, using -e option) flags and assigns new ones -g -Os? If user set some C(XX)?FLAGS then it means he knows what he is doing and he is required in these options. But configure script considers user's approach is wrong and assigns own flags )) that is good!
[Bug tree-optimization/59356] [4.9 regression] ACATS C52102A and C52102C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59356 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks for reporting the problem.
[Bug driver/59321] -fuse-ld has no effect on -print-prog-name nor on --with-ld=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321 --- Comment #17 from maemarcus at gmail dot com --- Works as a charm! Many thanks! $ manual-gcc -print-prog-name=ld /media/scratch/manual/binutils-2.24.51/build32_glibc/install/bin/manual-ld $ manual-gcc -fuse-ld=bfd -print-prog-name=ld /media/scratch/manual/binutils-2.24.51/build32_glibc/install/bin/manual-ld.bfd $ manual-gcc -fuse-ld=gold -print-prog-name=ld /media/scratch/manual/binutils-2.24.51/build32_glibc/install/bin/manual-ld.gold
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com --- It turned out that proposed fix does not help trunk compilers since now another huge routine is inlined firstly (read_input) and for perdida we got the following message: not inlinable: iztaccihuatl/17 - perdida.constprop/122, --param large-function-growth limit reached Note that passing --param large-function-growth=130 will restore performance. I assume that additional heuristics must be designed to inline once called functions which are called inside inner loop.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #5 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 31348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31348action=edit test-case to reproduce It need to be compiled with -Ofast -flto options to reproduce.
[Bug rtl-optimization/59340] [4.9 Regression] LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org --- Bootstrap works again with r205541. Thanks!
[Bug tree-optimization/59362] [4.9 Regression] Abort in fini_object_sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Blocks||59125, 54570
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-* Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I will have a looksee.
[Bug tree-optimization/59359] [4.9 Regression] Segmentation fault in thread_through_all_blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59359 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-02 CC||law at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|Segmentation fault in |[4.9 Regression] |thread_through_all_blocks |Segmentation fault in ||thread_through_all_blocks Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/59355] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fno-devirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59355 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |4.9.0
[Bug driver/59321] -fuse-ld has no effect on -print-prog-name nor on --with-ld=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321 --- Comment #18 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00061.html
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 --- Comment #3 from gcc-bugzilla-f5d8 at theblacksun dot eu --- Created attachment 31349 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31349action=edit Second failing testcase. Triggers in -O1 and -O2 too
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Please show the output of cc -v -S -c -O2 -march=native blame.i so that it can be reproduced.
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 gcc-bugzilla-f5d8 at theblacksun dot eu changed: What|Removed |Added Target||sh4-unknown-linux-gnu --- Comment #4 from gcc-bugzilla-f5d8 at theblacksun dot eu --- Using the second testcase the compiler also misbehaves: $ sh4-unknown-linux-gnu-g++ -Wall -Wextra -static -o testcase2_O2 -O2 testcase2.cpp $ sh4-unknown-linux-gnu-g++ -Wall -Wextra -static -o testcase2_O1 -O1 testcase2.cpp $ sh4-unknown-linux-gnu-g++ -Wall -Wextra -static -o testcase2_O0 -O0 testcase2.cpp $ sh4-unknown-linux-gnu-g++ -Wall -Wextra -static -o testcase2_Os -Os testcase2.cpp $ qemu-sh4 ./testcase2_00 flag1 is true... flag2?: 0 $ qemu-sh4 ./testcase2_01 flag1 is true... flag2?: 0 flag2 is true $ qemu-sh4 ./testcase2_02 flag1 is true... flag2?: 0 flag2 is true $ qemu-sh4 ./testcase2_0s flag1 is true... flag2?: 0 flag2 is true
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #4 from Markus Trippelsdorf octoploid at yandex dot com --- git % cc -v -S -c -O2 -march=native blame.i Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/gcc Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-initfini-array --with-gold --enable-secureplt --disable-multilib --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-boot-ldflags=-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterations=3 --enable-version-specific-runtime-libs --disable-libstdcxx-pch --enable-libstdcxx-time=yes --with-build-config=bootstrap-lto Thread model: posix gcc version 4.9.0 20131129 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-S' '-c' '-O2' '-march=native' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -fpreprocessed blame.i -march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -msse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet -dumpbase blame.i -auxbase blame -O2 -version -o blame.s GNU C (GCC) version 4.9.0 20131129 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 4.9.0 20131129 (experimental), GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.0 20131129 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 4.9.0 20131129 (experimental), GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3b47e15390e8cb82192637cabb8398ab COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-S' '-c' '-O2' '-march=native'
[Bug bootstrap/59199] [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #7) Created attachment 31347 [details] fixed patch In testing. It doesn't work for me: 0xdbb0f6 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /export/gnu/import/git/gcc/gcc/tree.c:9362 0x5688df contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /export/gnu/import/git/gcc/gcc/tree.h:2816 0xd1f96c execute_update_addresses_taken() /export/gnu/import/git/gcc/gcc/tree-ssa.c:1659 0xa2c6d1 execute_function_todo /export/gnu/import/git/gcc/gcc/passes.c:1824 0xa2ba61 do_per_function /export/gnu/import/git/gcc/gcc/passes.c:1573 0xa2c87d execute_todo /export/gnu/import/git/gcc/gcc/passes.c:1877 0xa2cda0 execute_one_ipa_transform_pass /export/gnu/import/git/gcc/gcc/passes.c:2062 0xa2ce9f execute_all_ipa_transforms() /export/gnu/import/git/gcc/gcc/passes.c:2093 0x70fb68 expand_function /export/gnu/import/git/gcc/gcc/cgraphunit.c:1756 0x710059 expand_all_functions /export/gnu/import/git/gcc/gcc/cgraphunit.c:1868 0x7109b2 compile() /export/gnu/import/git/gcc/gcc/cgraphunit.c:2203 0x710b2b finalize_compilation_unit() /export/gnu/import/git/gcc/gcc/cgraphunit.c:2280 0x58a688 c_write_global_declarations() /export/gnu/import/git/gcc/gcc/c/c-decl.c:10397 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.
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 31350
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31350action=edit
gcc49-pr59358.patch
Untested fix. The problem is with:
Meeting
[-INF, y_5(D) + -1] EQUIVALENCES: { z_4 } (1 elements)
and
[-INF(OVF), 30]
to
[-INF(OVF), y_5(D) + -1] EQUIVALENCES: { } (0 elements)
Found new range for z_1: [-INF(OVF), y_5(D) + -1]
Because one of the maximum is symbolic, y_5(D) + -1 and 30 are effectively
uncomparable (operand_less_p doesn't return 1 for either order of those).
Apparently union_ranges implicitly assumes certain ordering based on earlier
tests, like from
else if ((maxeq || operand_less_p (vr1max, *vr0max) == 1)
(mineq || operand_less_p (*vr0min, vr1min) == 1))
being false it assumes that if
else if ((operand_less_p (vr1min, *vr0max) == 1
|| operand_equal_p (vr1min, *vr0max, 0))
operand_less_p (*vr0min, vr1min) == 1
is true then operand_less_p (*vr0max, vr1max) == 1, but that is not guaranteed.
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Meeting
[-INF, y_6(D) + -1] EQUIVALENCES: { z_5 } (1 elements)
and
[-INF(OVF), 30]
to
[-INF(OVF), y_6(D) + -1] EQUIVALENCES: { } (0 elements)
Found new range for z_1: [-INF(OVF), y_6(D) + -1]
is obviously wrong. We run into
else if ((operand_less_p (*vr0min, vr1max) == 1
|| operand_equal_p (*vr0min, vr1max, 0))
operand_less_p (vr1min, *vr0min) == 1)
{
/* ( [ ) ] or ( )[ ] */
if (*vr0type == VR_RANGE
vr1type == VR_RANGE)
*vr0min = vr1min;
where -INF 30 and -INF(OVF) -INF. But we have vr0max and vr1max unordered.
Thus we fail to verify that, assuming we've catched this case via
else if ((maxeq || operand_less_p (vr1max, *vr0max) == 1)
(mineq || operand_less_p (*vr0min, vr1min) == 1))
{
/* [ ( ) ] or [( ) ] or [ ( )] */
...
else if ((maxeq || operand_less_p (*vr0max, vr1max) == 1)
(mineq || operand_less_p (vr1min, *vr0min) == 1))
{
/* ( [ ] ) or ([ ] ) or ( [ ]) */
Fixing that does
Meeting
[-INF, y_6(D) + -1] EQUIVALENCES: { z_5 } (1 elements)
and
[-INF(OVF), 30]
to
VARYING
optimally we'd be able to extract a conservative integer range from
the symbolic range - [-INF, +INF - 1] in this case - and meet them
to [-INF(OVF), +INF - 1] (assuming that y_6 did not overflow).
[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Stupachenko Evgeny from comment #4) Not reproduced on trunk(4.9) any more. Still reproduced on 4.8. You can bisect trunk to see which checkin fixes it. Is this a regression on 4.8 branch?
[Bug c++/59329] Using `assert(...)` is not allowed in constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59329 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- At least it should be supported in c++1y mode, where several constexpr restrictions had been lifted by the core language (but it currently isn't, not even in the 4.9.0 trunk).
[Bug c/59367] New: Syntax error with #pragma message before else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367
Bug ID: 59367
Summary: Syntax error with #pragma message before else
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.abecassis at gmail dot com
Using #pragma message before else triggers a syntax error:
pragma_message.c: In function 'main':
pragma_message.c:4:9: note: #pragma message: foo
#pragma message foo
^
pragma_message.c:5:5: error: 'else' without a previous 'if'
else {}
^
See attached file for source.
Preprocessed .i file:
# 1 pragma_message.c
# 1 command-line
# 1 /usr/include/stdc-predef.h 1 3 4
# 30 /usr/include/stdc-predef.h 3 4
# 1 /usr/include/x86_64-linux-gnu/bits/predefs.h 1 3 4
# 31 /usr/include/stdc-predef.h 2 3 4
# 1 command-line 2
# 1 pragma_message.c
int main()
{
if (1) {}
# 4 pragma_message.c
#pragma message foo
# 4 pragma_message.c
else {}
}
[Bug c/59367] Syntax error with #pragma message before else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59367 --- Comment #1 from Felix Abecassis felix.abecassis at gmail dot com --- Created attachment 31351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31351action=edit Source file
[Bug target/59174] [avr] Suboptimal multiplication when indexing an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59174 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-02 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Confirmed with the trunk. This is an issue of cost computation in the avr backend. If you compile with -O2 -mmcu=atmega2560 -mlog=rtx_costs you will see avr_rtx_costs[test:combine(206)]=true (speed) total=36, outer=set: (mult:HI (reg:HI 47 [ D.1460 ]) (const_int 10 [0xa])) ... avr_rtx_costs[test:combine(206)]=true (speed) total=32, outer=set: (plus:HI (ashift:HI (reg:HI 47 [ D.1460 ]) (const_int 3 [0x3])) (ashift:HI (reg:HI 47 [ D.1460 ]) (const_int 1 [0x1]))) thus the MULT variant is taken as more costly that the ASHIFT + PLUS version.
[Bug bootstrap/59199] [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Dec 2 15:13:52 2013 New Revision: 205587 URL: http://gcc.gnu.org/viewcvs?rev=205587root=gccview=rev Log: 2013-12-02 Richard Biener rguent...@suse.de * tree-ssa-operands.c (opf_implicit): Remove. (opf_address_taken): New flag. (get_expr_operands): Remove early out, pass down opf_address_taken for ADDR_EXPRs, add a use operand only for non-opf_address_taken bases. (get_indirect_ref_operands): Rename to ... (get_mem_ref_operands): ... this. (get_asm_expr_operands): Rename to ... (get_asm_stmt_operands): ... this. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-operands.c
[Bug tree-optimization/59139] [4.7/4.8/4.9 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59139 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Dec 2 15:43:01 2013 New Revision: 205588 URL: http://gcc.gnu.org/viewcvs?rev=205588root=gccview=rev Log: 2013-12-02 Richard Biener rguent...@suse.de PR tree-optimization/59139 * tree-ssa-loop-niter.c (chain_of_csts_start): Properly match code in get_val_for. (get_val_for): Use gcc_checking_asserts. * gcc.dg/torture/pr59139.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59139.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/59139] [4.7 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59139 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.3, 4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] internal |internal compiler error: in |compiler error: in |get_val_for, at |get_val_for, at |tree-ssa-loop-niter.c:2267 |tree-ssa-loop-niter.c:2267 Known to fail|4.9.0 | --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for 4.8.3 sofar.
[Bug tree-optimization/59139] [4.7/4.8/4.9 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59139 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Dec 2 15:43:47 2013 New Revision: 205589 URL: http://gcc.gnu.org/viewcvs?rev=205589root=gccview=rev Log: 2013-12-02 Richard Biener rguent...@suse.de PR tree-optimization/59139 * tree-ssa-loop-niter.c (chain_of_csts_start): Properly match code in get_val_for. (get_val_for): Use gcc_checking_asserts. * gcc.dg/torture/pr59139.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59139.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-loop-niter.c
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #5 from Markus Trippelsdorf octoploid at yandex dot com ---
(In reply to Markus Trippelsdorf from comment #2)
22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
22211 {
22212 xpparam_t xpp = {0};
22213 xdemitconf_t xecfg = {0};
22214 xdemitcb_t ecb = {((void *)0)};
22215
22216 xpp.flags = xdl_opts;
22217 xecfg.ctxlen = ctxlen;
22218 xecfg.hunk_func = hunk_func;
22219 ecb.priv = cb_data;
0 return xdi_diff(file_a, file_b, xpp, xecfg, ecb);
1 }
2
The problem seems to be that xecfg.hunk_func is empty even though
hunk_func is not.
So the assignment might get overwritten by the initialization.
...
(gdb) up
#5 0x004104df in diff_hunks (file_a=optimized out, file_b=optimized
out, ctxlen=ctxlen@entry=0, hunk_func=hunk_func@entry=0x411320
blame_chunk_cb,
cb_data=cb_data@entry=0x7fffd830) at builtin/blame.c:105
105 return xdi_diff(file_a, file_b, xpp, xecfg, ecb);
(gdb) l
100
101 xpp.flags = xdl_opts;
102 xecfg.ctxlen = ctxlen;
103 xecfg.hunk_func = hunk_func;
104 ecb.priv = cb_data;
105 return xdi_diff(file_a, file_b, xpp, xecfg, ecb);
106 }
107
108 /*
109 * Prepare diff_filespec and convert it using diff textconv API
(gdb) p hunk_func
$1 = (xdl_emit_hunk_consume_func_t) 0x411320 blame_chunk_cb
(gdb) p xecfg.hunk_func
$2 = (xdl_emit_hunk_consume_func_t) 0x0
[Bug bootstrap/59368] New: [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 Bug ID: 59368 Summary: [4.9 Regression] libsanitizer spec file installed in the wrong place Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com When GCC is configured with --enable-version-specific-runtime-libs, spec files for libgomp, libitm, etc. are installed in the compiler-specific directory ($libdir/gcc/$target/$version). But libsanitizer, somehow, stands out from this scheme - libsanitizer.spec appears in $libdir/gcc/$target. It seems to be a bug. GCC 4.9.0 20131201 (r205574).
[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- CC'ing the libsanitizer maintainer. This is like the libvtv bug 58441 or libcilkrts bug 59094...
[Bug tree-optimization/59359] [4.9 Regression] Segmentation fault in thread_through_all_blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59359 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Confirmed duplicate. *** This bug has been marked as a duplicate of bug 59322 ***
[Bug tree-optimization/59322] [4.9 Regression] ICE with segfault on valid code at -O1, -O2, and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59322 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||antoine.balestrat at gmail dot com --- Comment #3 from Jeffrey A. Law law at redhat dot com --- *** Bug 59359 has been marked as a duplicate of this bug. ***
[Bug c++/59370] aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370 --- Comment #1 from john2.718281828459045235360287 at gmail dot com --- Created attachment 31353 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31353action=edit Output of g++ -v
[Bug c++/59370] aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370 --- Comment #2 from john2.718281828459045235360287 at gmail dot com --- Created attachment 31354 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31354action=edit generated assem
[Bug c++/59370] aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370 --- Comment #3 from john2.718281828459045235360287 at gmail dot com --- Created attachment 31355 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31355action=edit Source file
[Bug sanitizer/59369] New: c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 Bug ID: 59369 Summary: c-c++-common/asan/pr59063-[1,2].c fails on darwin Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org The new c-c++-common/asan/pr59063-1.c and c-c++-common/asan/pr59063-2.c test cases fail at all optimization levels on x86_64-apple-darwin13 due to the absence of monotonic clock support or librt on darwin. The failures are of the form... Executing on host: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0-lm -m32 -o ./pr59063-1.exe(timeout = 300) spawn /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -lm -m32 -o ./pr59063-1.exe^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:4:26: error: unknown type name 'clockid_t'^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c: In function 'main':^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: error: 'clock_gettime' undeclared (first use in this function)^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: note: each undeclared identifier is reported only once for each function it appears in^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:10:23: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)^M compiler exited with status 1 output is: /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:4:26: error: unknown type name 'clockid_t'^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c: In function 'main':^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: error: 'clock_gettime' undeclared (first use in this function)^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: note: each undeclared identifier is reported only once for each function it appears in^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:10:23: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)^M FAIL: c-c++-common/asan/pr59063-1.c -O0 (test for excess errors) Excess errors: /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:4:26: error: unknown type name 'clockid_t' /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: error: 'clock_gettime' undeclared (first use in this function) /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:10:23: error: 'CLOCK_MONOTONIC' undeclared (first use in this function) UNRESOLVED: c-c++-common/asan/pr59063-1.c -O0 compilation failed to produce executable
[Bug c++/59370] New: aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370
Bug ID: 59370
Summary: aggressive-loop-optimizations causes infinite loop due
to integer overflow within loop body
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john2.718281828459045235360287 at gmail dot com
Created attachment 31352
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31352action=edit
Preprocessed source file.
// This creates an infinite loop under -O2.
#include iostream
int main (int, char*[])
{
for (int i = 0; i 4; ++i){
int q = i * static_castint(10u);
std::cout q std::endl;
}
return 0;
}
[Bug c/59351] ICE on empty compound literal with -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c/59351] ICE on empty compound literal with -pedantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59351 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-02 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Even 4.0.2 fails, gcc34 does not. Mine for now.
[Bug target/59371] New: Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
Bug ID: 59371
Summary: Performance regression in GCC 4.8 and later versions.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sje at gcc dot gnu.org
Target: mips*-*-*
If I compile this program with -O2 on MIPS:
int foo(int *p, unsigned short c)
{
signed short i;
int x = 0;
for (i = 0; i c; i++) {
x = x + *p; p++;
}
return x;
}
With GCC 4.7.* or earlier I get loop code that looks like:
$L3:
lw$5,0($4)
addiu$3,$3,1
seh$3,$3
addu$2,$2,$5
bne$3,$6,$L3
addiu$4,$4,4
With GCC 4.8 and later I get:
$L3:
lw$7,0($4)
addiu$3,$3,1
seh$3,$3
slt$6,$3,$5
addu$2,$2,$7
bne$6,$0,$L3
addiu$4,$4,4
This loop has one more instruction in it and is slower.
A version of this bug appears in EEMBC 1.1. If I change the loop
index to be unsigned then I get the better code but I can't change
the benchmark I am testing so I am trying to figure out what changed
in GCC and how to generate the faster code.
[Bug tree-optimization/59322] [4.9 Regression] ICE with segfault on valid code at -O1, -O2, and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59322 --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Thanks for the bug report. It hits a hunk of code which I've looked at a few times in the last couple months and haven't been able to convince myself it's correct or desirable. In create_edge_and_update_destination_phis, we clone a jump threading path onto the newly created edge. That path has a reference to an edge that later gets removed. Then we look at the path and fault.
[Bug target/58115] testcase gcc.target/i386/intrinsics_4.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115 --- Comment #9 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Mon Dec 2 18:00:47 2013 New Revision: 205593 URL: http://gcc.gnu.org/viewcvs?rev=205593root=gccview=rev Log: 2013-11-03 Bernd Edlinger bernd.edlin...@hotmail.de PR target/58115 * function.c (invoke_set_current_function_hook): Call targetm.set_current_function after setting this_fn_optabs. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #6 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com --- I wasn't able to reproduce the problem, though I got the same asm-files as you showed. However, the both asms look correct to me, and equivalent to each other. Could the problem be in function xdi_diff? Maybe it's compiled with some different flags? Though, I might miss something - I'll continue digging into the problem.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #7 from Markus Trippelsdorf octoploid at yandex dot com --- Antoine Pelisse explained the control flow: http://thread.gmane.org/gmane.comp.version-control.git/238629/focus=238631
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #8 from Markus Trippelsdorf octoploid at yandex dot com --- To reproduce the issue: % git clone https://github.com/git/git % cd git % vim Makefile (add -march=amdfam10 to CFLAGS and point CC to gcc trunk) % make % ./git-blame Makefile (crash)
[Bug c/56600] loop goes indefinite when non-loop integer variable overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56600 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch Resolution|INVALID |DUPLICATE --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** This bug has been marked as a duplicate of bug 56463 ***
[Bug c++/59370] aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat dot ethz ||.ch Resolution|--- |DUPLICATE --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Duplicate bug, more details in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 *** This bug has been marked as a duplicate of bug 56463 ***
[Bug c/56463] infinite loop when having integer overflow in a simple accumulator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||john2.718281828459045235360 ||287 at gmail dot com --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** Bug 59370 has been marked as a duplicate of this bug. ***
[Bug c/56463] infinite loop when having integer overflow in a simple accumulator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||mskyeong at naver dot com --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** Bug 56600 has been marked as a duplicate of this bug. ***
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- Steps to reproduce this bug on Intel Core i7 processors: 1. Checkout GCC revision 203886. 2. Configure GCC with --with-arch=corei7 --with-tune=amdfam10 3. Bootstrap/install GCC. 4. Checkout git 1.8.4.4. 5. Configure git with CC=GCC-203886/bin/gcc CXX=GCC-203886/bin/g++ ./configure 6. Build/install git. 7. Run git blame gcc/tree-object-size.c in GCC revision 203886 tree.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-02 Ever confirmed|0 |1
[Bug middle-end/59257] usan/*san: Dpcumentation oddness of -fsanitize= / -fsanitize=shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59257 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED! Manuel: Thanks for the suggestion/patchlet of comment 2.
[Bug middle-end/59257] usan/*san: Dpcumentation oddness of -fsanitize= / -fsanitize=shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59257 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Dec 2 19:54:29 2013 New Revision: 205598 URL: http://gcc.gnu.org/viewcvs?rev=205598root=gccview=rev Log: 2013-12-02 Tobias Burnus bur...@net-b.de Manuel López-Ibáñez m...@gcc.gnu.org PR middle-end/59257 * doc/invoke.texi: Add missing @opindex. (-fsanitize=): Use @gcctabopt instead of @itemize. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- valgrind reports: ==13971== Memcheck, a memory error detector ==13971== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13971== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13971== Command: ./git-blame Makefile ==13971== ==13971== Jump to the invalid address stated on the next line ==13971==at 0x0: ??? ==13971==by 0x50AE88: xdl_emit_hunk_hdr (xutils.c:460) ==13971==by 0x50B566: xdl_emit_diff (xemit.c:237) ==13971==by 0x5094DC: xdl_diff (xdiffi.c:601) ==13971==by 0x5038E4: xdi_diff (xdiff-interface.c:136) ==13971==by 0x41035E: diff_hunks (blame.c:104) ==13971==by 0x41296B: cmd_blame (blame.c:815) ==13971==by 0x405EF4: handle_internal_command (git.c:291) ==13971==by 0x4056E0: main (git.c:551) ==13971== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==13971== ==13971== ==13971== Process terminating with default action of signal 11 (SIGSEGV) ==13971== Bad permissions for mapped region at address 0x0 ==13971==at 0x0: ??? ==13971==by 0x50AE88: xdl_emit_hunk_hdr (xutils.c:460) ==13971==by 0x50B566: xdl_emit_diff (xemit.c:237) ==13971==by 0x5094DC: xdl_diff (xdiffi.c:601) ==13971==by 0x5038E4: xdi_diff (xdiff-interface.c:136) ==13971==by 0x41035E: diff_hunks (blame.c:104) ==13971==by 0x41296B: cmd_blame (blame.c:815) ==13971==by 0x405EF4: handle_internal_command (git.c:291) ==13971==by 0x4056E0: main (git.c:551) ==13971== ==13971== HEAP SUMMARY: ==13971== in use at exit: 4,584,430 bytes in 4,375 blocks ==13971== total heap usage: 7,936 allocs, 3,561 frees, 36,653,925 bytes allocated ==13971== ==13971== LEAK SUMMARY: ==13971==definitely lost: 162 bytes in 8 blocks ==13971==indirectly lost: 0 bytes in 0 blocks ==13971== possibly lost: 3,016 bytes in 2 blocks ==13971==still reachable: 4,581,252 bytes in 4,365 blocks ==13971== suppressed: 0 bytes in 0 blocks ==13971== Rerun with --leak-check=full to see details of leaked memory ==13971== ==13971== For counts of detected and suppressed errors, rerun with: -v ==13971== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) [1]13971 segmentation fault valgrind ./git-blame Makefile | /tmp/1
[Bug sanitizer/59353] -fsanitize=return is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59353 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Dec 2 20:39:25 2013 New Revision: 205601 URL: http://gcc.gnu.org/viewcvs?rev=205601root=gccview=rev Log: PR sanitizer/59353 * doc/invoke.texi: Document -fsanitize=return. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug sanitizer/59353] -fsanitize=return is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59353 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c++/59372] New: accepts-invalid with constexpr function pointer variable as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59372
Bug ID: 59372
Summary: accepts-invalid with constexpr function pointer
variable as non-type template argument
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Consider:
void f() {}
templatevoid (*)() struct X {};
templatevoid ()() struct Y {};
constexpr void (*p)() = f;
Xp a;
constexpr void (*h())() { return f; }
Xh() b;
constexpr void (q)() = f;
Xq c;
constexpr void (i())() { return f; }
Xi() d;
GCC correctly rejects the types of 'b', 'c', and 'd', but fails to reject 'a'.
All four are ill-formed by 14.3.2/1. In particular, a non-type template
argument for a parameter of pointer type must be either a null pointer, the
name of a non-type template-parameter, or an expression of the form '
id-expression', and the '' can only be omitted if the id-expression names a
function or array. (See also the discussion for core issue 1570, where this
direction was reaffirmed.)
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
A testcase:
[hjl@gnu-6 pr59363]$ cat x.h
typedef struct s_mmbuffer {
char *ptr;
long size;
} mmbuffer_t;
typedef struct s_mmfile {
char *ptr;
long size;
} mmfile_t;
typedef struct s_xpparam {
unsigned long flags;
} xpparam_t;
typedef long (*find_func_t)(const char *line, long line_len, char *buffer, long
buffer_size, void *priv);
typedef int (*xdl_emit_hunk_consume_func_t)(void);
typedef struct s_xdemitconf {
long ctxlen;
long interhunkctxlen;
unsigned long flags;
find_func_t find_func;
void *find_func_priv;
xdl_emit_hunk_consume_func_t hunk_func;
} xdemitconf_t;
typedef struct s_xdemitcb {
void *priv;
int (*outf)(void *, mmbuffer_t *, int);
} xdemitcb_t;
extern int xdi_diff(xpparam_t const *xpp,
xdemitconf_t const *xecfg, xdemitcb_t *ecb);
extern int diff_hunks(long ctxlen, xdl_emit_hunk_consume_func_t hunk_func,
void *cb_data);
[hjl@gnu-6 pr59363]$ cat x.c
#include x.h
int
xdi_diff(xpparam_t const *xpp,
xdemitconf_t const *xecfg, xdemitcb_t *ecb)
{
if (xecfg-hunk_func == 0)
__builtin_abort ();
return 0;
}
int hunk_func (void)
{
return 0;
}
int
main ()
{
return diff_hunks (1, hunk_func, (void *) 0);
}
[hjl@gnu-6 pr59363]$ cat y.c
#include x.h
int diff_hunks(long ctxlen, xdl_emit_hunk_consume_func_t hunk_func,
void *cb_data)
{
xpparam_t xpp = {0};
xdemitconf_t xecfg = {0};
xdemitcb_t ecb = {((void *)0)};
xpp.flags = 0;
xecfg.ctxlen = ctxlen;
xecfg.hunk_func = hunk_func;
ecb.priv = cb_data;
return xdi_diff(xpp, xecfg, ecb);
}
[hjl@gnu-6 pr59363]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mtune=amdfam10 -c -o x.o
x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mtune=amdfam10 -c -o y.o
y.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mtune=amdfam10 -o x x.o
y.o
./x
make: *** [all] Aborted
[hjl@gnu-6 pr59363]$
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369
--- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu ---
From
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x,
the following code would work on darwin, but I'm not sure if the test is still
valid...
/* { dg-do run } */
#ifdef __MACH__
#define CLOCK_MONOTONIC 0
#include sys/time.h
static int weak_gettime (int clk_id, struct timespec *tp)
__attribute__((__weakref__(clock_gettime)));
int clock_gettime(int clk_id, struct timespec* tp) {
struct timeval now;
int rv = gettimeofday(now, NULL);
if (rv) return rv;
tp-tv_sec = now.tv_sec;
tp-tv_nsec = now.tv_usec * 1000;
return 0;
}
#else
#include time.h
static int weak_gettime (clockid_t clk_id, struct timespec *tp)
__attribute__((__weakref__(clock_gettime)));
#endif
int main() {
if (!clock_gettime)
return 0;
struct timespec ts;
return weak_gettime(CLOCK_MONOTONIC, ts);
}
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
Smaller testcase:
[hjl@gnu-6 pr59363]$ cat x.h
typedef struct s_xdemitconf {
long ctxlen;
long interhunkctxlen;
unsigned long flags;
unsigned long find_func;
void *find_func_priv;
unsigned long hunk_func;
} xdemitconf_t;
extern int xdi_diff(xdemitconf_t const *xecfg);
extern int diff_hunks(unsigned long hunk_func);
[hjl@gnu-6 pr59363]$ cat x.c
#include x.h
int
xdi_diff(xdemitconf_t const *xecfg)
{
if (xecfg-hunk_func == 0)
__builtin_abort ();
return 0;
}
int
main ()
{
return diff_hunks (20);
}
[hjl@gnu-6 pr59363]$ cat y.c
#include x.h
int diff_hunks(unsigned long hunk_func)
{
xdemitconf_t xecfg = {0};
xecfg.hunk_func = hunk_func;
return xdi_diff(xecfg);
}
[hjl@gnu-6 pr59363]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mtune=amdfam10 -c -o x.o
x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mtune=amdfam10 -c -o y.o
y.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mtune=amdfam10 -o x x.o
y.o
./x
make: *** [all] Aborted
[hjl@gnu-6 pr59363]$
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Attachment #31346|0 |1 is obsolete|| --- Comment #13 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31356 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31356action=edit A patch for GCC testsuite Here is a patch for GCC testsuite.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #14 from Markus Trippelsdorf octoploid at yandex dot com ---
Further reduced:
markus@x4 tmp % cat test.i
typedef struct {
int ctxlen;
long interhunkctxlen;
int flags;
long find_func;
void *find_func_priv;
int hunk_func;
} xdemitconf_t;
__attribute__((noinline))
int xdi_diff(xdemitconf_t *xecfg) {
if (xecfg-hunk_func == 0)
__builtin_abort();
return 0;
}
int main() {
xdemitconf_t xecfg = {0};
xecfg.hunk_func = 1;
return xdi_diff(xecfg);
}
markus@x4 tmp % gcc -O2 -mtune=amdfam10 test.i ./a.out
[1]2079 abort ./a.out
markus@x4 tmp % gcc -O2 test.i ./a.out
markus@x4 tmp %
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||harsha.jagasia at amd dot com
--- Comment #15 from H.J. Lu hjl.tools at gmail dot com ---
It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2.
there are
(insn 24 23 26 4 (set (mem/c:DI (plus:DI (reg:DI 0 ax [85])
(const_int 8 [0x8])) [2 xecfg+32 S8 A128])
(const_int 0 [0])) z.i:12 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax [85])
(nil)))
(insn 26 24 28 4 (set (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 40 [0x28])) [3 xecfg.hunk_func+0 S4 A64])
(const_int 1 [0x1])) z.i:13 86 {*movsi_internal}
(nil))
(insn 28 26 29 4 (set (reg:DI 5 di)
(reg/f:DI 7 sp)) z.i:14 85 {*movdi_internal}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -48 [0xffd0]))
(nil)))
z.i.234r.sched2 has
(insn 26 28 22 4 (set (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 40 [0x28])) [3 xecfg.hunk_func+0 S4 A64])
(const_int 1 [0x1])) z.i:13 86 {*movsi_internal}
(nil))
(insn:TI 22 26 24 4 (set (mem/c:DI (reg:DI 0 ax [85]) [2 xecfg+32 S8 A128])
(const_int 0 [0])) z.i:12 85 {*movdi_internal}
(nil))
(insn 24 22 29 4 (set (mem/c:DI (plus:DI (reg:DI 0 ax [85])
(const_int 8 [0x8])) [2 xecfg+32 S8 A128])
(const_int 0 [0])) z.i:12 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax [85])
(nil)))
insn 24 is moved after insn 26, which clears xecfg.hunk_func
set by insn 26.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #16 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to H.J. Lu from comment #15) It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2. there are The question comes down to if the aliasing oracle says if they are conflicting ones.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #17 from Markus Trippelsdorf octoploid at yandex dot com --- (In reply to H.J. Lu from comment #15) It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2. there are BTW -mtune=opteron is also affected.
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #26 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to janus from comment #25) The relevant quote for the above error message is F08:12.4.2.2, which says: Good pointer, though I am not sure whether it is relevant. Another one is 12.4.3.6 Procedure declaration statement which is relevant for the interface declaration part of the proc-pointer. * * * With some digging I found 09-166 - but according to the m188 notes no further action is done. And a bit less fitting but with passed J3/WG5, one has: 09-171r1, which got revised as 09-217 and passed the ballot as Interpretation Request F03-0130. See: http://j3-fortran.org/doc/year/09/09-217.txt and http://j3-fortran.org/doc/year/10/10-006T5r1.txt. From F03-0130: Q: When one of these procedures [i.e. the specific intrinsic procedures listed in 13.6 and not marked with a bullet] is associated with a dummy procedure or procedure pointer, does it still have the elemental property? A: The specific intrinsic procedure itself retains the elemental property (so a reference using its own name can be elemental), but the dummy procedure or procedure pointer associated with it is not elemental and so cannot be used to reference the specific intrinsic procedure elementally. * * * As far as I can see, it seems to be valid to have: intrinsic :: sin procedure(real), pointer :: pp1 = sin procedure(sin), pointer :: pp2 = sin ! valid per C1216 interface pure function sin_like(x) real, intent(in) :: x end function sin_like end interface procedure(sin_like), pointer :: pp3 = sin But in all cases, the proc-pointer is not elemental. It doesn't seem to be valid to have: interface pure ELEMENTAL function sin_like(x) real, intent(in) :: x end function sin_like end interface procedure(sin_like), pointer :: pp4 = sin But is is valid to have a non-proc-pointer PROCEDURE statement like: procedure(sin_like) :: external_sin_like_function For the latter two, the following applies: C1218 (R1211) If a proc-interface describes an elemental procedure, each procedure-entity-name shall specify an external procedure. [Side note: We should also check that dummy arguments are correctly handled.]
[Bug c++/59372] accepts-invalid with constexpr function pointer variable as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59372 --- Comment #1 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- (In reply to Richard Smith from comment #0) Xq c; Xi() d; Sorry, transcription error, these should be 'Y', not 'X'.
[Bug libstdc++/59373] New: Table 92 is unreadable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373 Bug ID: 59373 Summary: Table 92 is unreadable Product: gcc Version: 4.9.0 URL: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen /a00445.html#ad72dc61561f4420b36f9e626b4426433 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: giecrilj at stegny dot 2a.pl Is: Table 92, adapted here, gives the relation between openmode combinations and the equivalent fopen() flags. (NB: lines app, in|out|app, in|app, binary|app, binary|in|out|app, and binary|in|app per DR 596) +———+ | ios_base Flag combination stdio equivalent | |binary in out trunc app | +———+ | + w | | + + a | | + a | | + + w | | + r | | + + r+ | | + + + w+ | | + + + a+ | | + + a+ | +———+ | + + wb | | + + + ab | | + + ab | | + + + wb | | + + rb | | + + + r+b | | + + + + w+b | | + + + + a+b | | + + + a+b | +———+ I beg your pardon? It is not only unreadable, it is undecipherable because white space is collapsed. (Workaround: URL: file:///usr/share/doc/packages/libstdc++46-doc/html/ext/lwg-defects.html#596 )
[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59326 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Dec 2 22:39:12 2013 New Revision: 205606 URL: http://gcc.gnu.org/viewcvs?rev=205606root=gccview=rev Log: PR lto/59326 * gcc.target/i386/i386.exp (check_effective_target_avx2): Move to... * lib/target-supports.exp (check_effective_target_avx2): ... here. (check_effective_target_vect_simd_clones): New. * gcc.dg/vect/vect-simd-clone-1.c: Add dg-require-effective-target vect_simd_clones. * gcc.dg/vect/vect-simd-clone-2.c: Likewise. * gcc.dg/vect/vect-simd-clone-3.c: Likewise. * gcc.dg/vect/vect-simd-clone-4.c: Likewise. * gcc.dg/vect/vect-simd-clone-5.c: Likewise. * gcc.dg/vect/vect-simd-clone-6.c: Likewise. * gcc.dg/vect/vect-simd-clone-7.c: Likewise. * gcc.dg/vect/vect-simd-clone-8.c: Likewise. * gcc.dg/vect/vect-simd-clone-9.c: Likewise. * gcc.dg/vect/vect-simd-clone-10.c: Likewise. * gcc.dg/vect/vect-simd-clone-11.c: Likewise. * gcc.dg/vect/vect-simd-clone-12.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-10.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-11.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-2.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-3.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-4.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-5.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-6.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-7.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-8.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-9.c trunk/gcc/testsuite/gcc.target/i386/i386.exp trunk/gcc/testsuite/lib/target-supports.exp
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Dec 2 22:41:23 2013 New Revision: 205607 URL: http://gcc.gnu.org/viewcvs?rev=205607root=gccview=rev Log: PR tree-optimization/59358 * tree-vrp.c (union_ranges): To check for the partially overlapping ranges or adjacent ranges, also compare *vr0max with vr1max. * gcc.c-torture/execute/pr59358.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr59358.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Dec 2 22:44:05 2013 New Revision: 205608 URL: http://gcc.gnu.org/viewcvs?rev=205608root=gccview=rev Log: PR tree-optimization/59358 * tree-vrp.c (union_ranges): To check for the partially overlapping ranges or adjacent ranges, also compare *vr0max with vr1max. * gcc.c-torture/execute/pr59358.c: New test. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vrp.c
[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixing on SPARC. Ugh. Linux and Solaris disagree on the values of the FE_* macros so we will need to have OS-dependent code in the sparc_atomic_assign_expand_fenv hook if we call __atomic_feraiseexcept (I wonder if the same issue exists for x86/x86-64). The feupdateenv implementation for SPARC in glibc calls feraiseexcept at the end (like the x86 implementation), but it does so only for the old exceptions. Yet the manpage seems to indicate that old and new exceptions play a symmetrical role: The feupdateenv() function installs the floating-point environment rep- resented by the object *envp, except that currently raised exceptions are not cleared. After calling this function, the raised exceptions will be a bitwise OR of those previously set with those in *envp. As before, the object *envp must be known to be valid. The implementation for PowerPC does not call feraiseexcept at the end and instead merges the exceptions in a symmetrical way. Rainer, can you briefly describe the implementation of feupdateenv in the libm of OpenSolaris?
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #18 from H.J. Lu hjl.tools at gmail dot com ---
emit_memset generates
(insn 22 21 23 (set (mem/c:DI (reg:DI 85) [2 xecfg+32 S8 A128])
(reg:DI 86)) z.i:12 -1
(nil))
(insn 23 22 24 (parallel [
(set (reg:DI 85)
(plus:DI (reg:DI 85)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) z.i:12 -1
(nil))
(insn 24 23 25 (set (mem/c:DI (reg:DI 85) [2 xecfg+32 S8 A128])
(reg:DI 86)) z.i:12 -1
(nil))
Both addresses are pointing to xecfg+32. gen_strset is expanded
to
(set (mem:DI (match_operand:P 1 register_operand 0))
(match_operand:DI 2 register_operand a))
(set (match_operand:P 0 register_operand =D)
(plus:P (match_dup 1)
(const_int 8)))
The destination register is incremented by 8 bytes. But we failed
to adjust its address. This patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index aa221df..d395a99 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -22806,6 +22806,8 @@ emit_memset (rtx destmem, rtx destptr, rtx
promoted_val,
if (piece_size = GET_MODE_SIZE (word_mode))
{
emit_insn (gen_strset (destptr, dst, promoted_val));
+ dst = adjust_automodify_address_nv (dst, move_mode, destptr,
+ piece_size);
continue;
}
changes the expansion to
(insn 22 21 23 (set (mem/c:DI (reg:DI 85) [2 xecfg+32 S8 A128])
(reg:DI 86)) z.i:12 -1
(nil))
(insn 23 22 24 (parallel [
(set (reg:DI 85)
(plus:DI (reg:DI 85)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) z.i:12 -1
(nil))
(insn 24 23 25 (set (mem/c:DI (reg:DI 85) [2 xecfg+40 S8 A64])
(reg:DI 86)) z.i:12 -1
(nil))
The second address is now xecfg+40 and the testcase works.
[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59326 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59358] [4.8/4.9 Regression] Infinite loop generated with =O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
