[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Severity|normal |critical
[Bug fortran/51266] New: Pointer initialization in PARAMETER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51266 Bug #: 51266 Summary: Pointer initialization in PARAMETER Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 45290 The following program from http://groups.google.com/group/comp.lang.fortran/msg/38bbc52c641f4b13 is rejected with: TYPE(T), PARAMETER :: C = T(X) !!! 1 Error: Parameter 'x' at (1) has not been declared or is a variable, which does not reduce to a constant expression The check is wrong as one has a pointer initialization - and X is a valid REAL, TARGET, SAVE variable. Without PARAMETER, the initialization works. I think just the checking needs to be fixed. (Note this is a F2008 feature.) Variant: Use T() an in the derived type P = X. PROGRAM MAIN TARGET X DATA X/0.0/ TYPE T REAL, POINTER :: P END TYPE TYPE(T), PARAMETER :: C = T(X) !!! READ *, X CALL SUBR() CONTAINS SUBROUTINE SUBR REAL, PARAMETER :: Y = C%P !!! PRINT *, Y END SUBROUTINE END
[Bug tree-optimization/51074] No constant folding performed for VEC_PERM_EXPR, VEC_INTERLEAVE*EXPR, VEC_EXTRACT*EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 09:38:53 UTC --- Created attachment 25878 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25878 gcc47-pr51074-be.patch Big endian fix, untested.
[Bug c++/51143] [C++11][DR 1159] Alias template allows class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51143 --- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-22 09:49:12 UTC --- A candidate fix has been posted to http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02194.html.
[Bug target/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-11-22 10:19:40 UTC --- What about current 4.7 SVN?
[Bug rtl-optimization/50765] [4.7 Regression] ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50765 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 10:50:08 UTC --- Created attachment 25879 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25879 gcc47-pr50765-test.patch Fixed by part of my http://gcc.gnu.org/viewcvs?root=gccview=revrev=180932 change, in particular vectorizable_type_promotion has been mishandling ncopies 1 - vect_create_vectorized_promotion_stmts would always grow vec_oprnd[01] vectors if multi_step_cvt, but nothing would truncate them and we'd just replace the first element in those vectors, so for ncopies 2 (in this case) we have one extra element in the vectors to promote. I'll just add the testcase to the testsuite after regtesting it and then close this.
[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 --- Comment #6 from Greta Yorsh Greta.Yorsh at arm dot com 2011-11-22 10:56:41 UTC --- Thanks for fixing it, Paolo. Tested as follows. Successful cross-build of the patch version for arm-none-eabi target, configured as before. No regression on qemu for check-g++. The tests for g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C all pass. Can you see the patch committed to trunk, please? Thank you, Greta
[Bug debug/50827] [4.7 Regression] ICE: RTL check: expected elt 0 type 'e' or 'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50827 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 11:03:26 UTC --- Fixed.
[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|jb at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-22 11:24:10 UTC --- (In reply to comment #9) (In reply to comment #8) I thought that fork, exec, and pipe, which are necessary for starting and interacting with the addr2line process are not supported on mingw? I just asked Kai. _exec, _pipe and _dup2 are supported, but fork() is not. However, Kai suggests to use FILE *__cdecl _popen(const char *_Command,const char *_Mode) with _Mode = rb. One can then read from the stream. See also: http://msdn.microsoft.com/en-us/library/96ayss4b%28v=vs.80%29.aspx At least on POSIX popen() is not async-signal-safe, hence one cannot use it in a signal handler. In any case, unassigning myself, since I have neither the time nor the means to work on the remaining platform-specific parts of this PR.
[Bug tree-optimization/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-11-22
CC||irar at il dot ibm.com
Component|target |tree-optimization
Ever Confirmed|0 |1
--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-11-22 11:33:24
UTC ---
We can start here with something that hopefully resembles your original fortran
code:
--cut here--
double C[10][4], B[10][10], A[10][4];
void test (void)
{
int i = 0, j = 0, l = 0;
//for (; j 10; j += 2)
// for (; l 10; l++)
for (; i 4; i++)
{
C[j+0][i] = C[j+0][i] + A[l][i] * B[j+0][l];
C[j+1][i] = C[j+1][i] + A[l][i] * B[j+1][l];
}
}
--cut here--
gcc -O3 -ffast-math -mfma4 -mavx:
test:
vmovapd A(%rip), %ymm0
vbroadcastsdB(%rip), %ymm1
vfmaddpdC(%rip), %ymm1, %ymm0, %ymm1
vmovapd %ymm1, C(%rip)
vbroadcastsdB+80(%rip), %ymm1
vfmaddpdC+32(%rip), %ymm1, %ymm0, %ymm0
vmovapd %ymm0, C+32(%rip)
vzeroupper
ret
Nice.
Now uncomment the second loop (l index) and this kernel will break:
... lots of code deleted ...
.L3:
vmovupd (%r8,%rax), %xmm1
addl$1, %esi
vinsertf128 $0x1, 16(%r8,%rax), %ymm1, %ymm1
vfmaddpd%ymm0, %ymm5, %ymm1, %ymm0
vmovapd %ymm0, (%rbx,%rax)
vmovupd (%rcx,%rax), %xmm0
vinsertf128 $0x1, 16(%rcx,%rax), %ymm0, %ymm0
vfmaddpd%ymm0, %ymm4, %ymm1, %ymm0
vmovupd %xmm0, (%rcx,%rax)
vextractf128$0x1, %ymm0, 16(%rcx,%rax)
addq$32, %rax
cmpl%r10d, %esi
jb .L3
... lots of code deleted ...
This already happens in the tree optimizers (vectorizer), RTL is just following
this trail.
Confirmed as a vectorizer problem.
[Bug rtl-optimization/49054] useless cmp+jmp generated for switch when default: is unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code |missed-optimization CC||ebotcazou at gcc dot ||gnu.org Component|middle-end |rtl-optimization Host|x86-64 | Version|unknown |4.6.0 Build|x86-64 | Severity|normal |enhancement --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-22 11:37:38 UTC --- The CFG cleanup code should be enhanced to deal with this.
[Bug fortran/51267] New: loop optimization error using LOC function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267 Bug #: 51267 Summary: loop optimization error using LOC function Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: priv...@hotmail.fr Created attachment 25880 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25880 simple source file The small program attached fails using gfortran 4.6.1 (ubuntu oneiric built) using -O1 optimization level or higher (ok at -O0). It succeeds with gfortran 4.5.4 at all -O levels. It ends by printing a boolean value : T if the test is ok, F else. $ gfortran-4.5 -O1 -Wall -Wextra bug46_stat.f ; ./a.out tab( 1 )= -1 tab( 2 )= -1 tab( 3 )= -1 tab( 4 )= -1 tab( 5 )= -1 tab( 6 )= -1 T $ gfortran-4.6 -O1 -Wall -Wextra bug46_stat.f ; ./a.out tab( 1 )= 134520832 tab( 2 )=10813028 tab( 3 )= -1 tab( 4 )= 0 tab( 5 )=10870894 tab( 6 )= -1 F Ouput with '-v' : Driving: gfortran-4.6 -v -save-temps -O1 -Wall -Wextra prog_stat.F -l gfortran -l m -shared-libgcc Utilisation des specs internes. COLLECT_GCC=gfortran-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper Target: i686-linux-gnu Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Modèle de thread: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6.1/f951 prog_stat.F -ffixed-form -cpp=prog_stat.f90 -quiet -v -imultilib . -imultiarch i386-linux-gnu prog_stat.F -quiet -dumpbase prog_stat.F -mtune=generic -march=i686 -auxbase prog_stat -O1 -Wall -Wextra -version -fintrinsic-modules-path /usr/lib/gcc/i686-linux-gnu/4.6.1/finclude -o prog_stat.s GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (i686-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 heuristiques GGC: --param ggc-min-expand=81 --param ggc-min-heapsize=95876 le répertoire « /usr/local/include/i386-linux-gnu » est ignoré car inexistant le répertoire « /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../i686-linux-gnu/include » est ignoré car inexistant la recherche pour #include ... débute ici : la recherche pour #include ... débute ici: /usr/lib/gcc/i686-linux-gnu/4.6.1/finclude /usr/lib/gcc/i686-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/i686-linux-gnu/4.6.1/include-fixed /usr/include/i386-linux-gnu /usr/include Fin de la liste de recherche. GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (i686-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 heuristiques GGC: --param ggc-min-expand=81 --param ggc-min-heapsize=95876 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=i686' as --32 -o prog_stat.o prog_stat.s Lecture des spécification à partir de /usr/lib/gcc/i686-linux-gnu/4.6.1/libgfortran.spec renommé les specs lib à liborig COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=i686' COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-linux-gnu/4.6.1/collect2 --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crt1.o
[Bug fortran/51268] New: [Regression] A subroutine can not know anymore its own interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268 Bug #: 51268 Summary: [Regression] A subroutine can not know anymore its own interface Classification: Unclassified Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bard...@iram.fr Created attachment 25881 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25881 Declare a subroutine interface and use this interface in the subroutine This a regression which appeared in the last months: problem is in 4.7.0 2019 but not in 4.7.0 20110507 In the latest version, a subroutine can not know its own interface and an error is raised about duplicate symbols (see example attached): test.f90:15.6: use myinterfaces 1 Error: 'mysub' of module 'myinterfaces', imported at (1), is also the name of the current program unit From our developer point of view, this is a very annoying regression, since we are in charge of several libraries, with hundreds of subroutines in each. We made the choice to provide all the interfaces of all the subroutines to all of them, in order to ensure a correct use of the subroutines everywhere. For each library we thus have a dedicated interface module which is used everywhere. Forbidding a subroutine to know its own interface would imply to use the statement use only, which is definitely not well suited for large programs. Thanks for your help.
[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-11-22 12:59:59 UTC --- Andrew: no, the clobbers are needed also for the outer bind, in order to make inlining such functions just work (i.e. enable stack sharing between different inlined functions). Otherwise we'd have to add the clobbers in the inliner which is more difficult because the try/finally are already lowered. In this case it's clearly a problem in tree.c, just remove the superfluous break.
[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #10 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com 2011-11-22 13:17:38 UTC --- Created attachment 25882 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25882 Patch for new memset/memcpy implementation (In reply to comment #9) Regressions caused by the new memset/memcpy expansion are FAIL: 27_io/basic_filebuf/seekoff/wchar_t/1.cc execution test FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9874.cc execution test FAIL: 27_io/manipulators/basefield/char/1.cc execution test FAIL: 27_io/manipulators/basefield/wchar_t/1.cc execution test FAIL: 27_io/objects/wchar_t/12.cc execution test FAIL: 27_io/objects/wchar_t/13.cc execution test FAIL: events run FAIL: gcc.target/i386/cleanup-1.c execution test FAIL: gcc.target/i386/cleanup-2.c execution test FAIL: gcc.target/i386/pr34077.c (internal compiler error) FAIL: gcc.target/i386/pr34077.c (internal compiler error) FAIL: gcc.target/i386/pr34077.c (test for excess errors) FAIL: gcc.target/i386/pr34077.c (test for excess errors) FAIL: gfortran.fortran-torture/execute/arrayarg.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops With the attached patch fails on PR34077 and arrayarg.f90 are fixed, fails on cleanup-tests are probably caused by incorrect testcase (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503).
[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264 --- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-11-22 13:32:20 UTC --- Author: matz Date: Tue Nov 22 13:32:15 2011 New Revision: 181615 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181615 Log: PR c++/51264 * tree.c (iterative_hash_expr): Remove break after return. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[Bug tree-optimization/51269] New: Vectorization profitability threshold is not actually used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51269 Bug #: 51269 Summary: Vectorization profitability threshold is not actually used Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org Host: x86_64-linux-gnu Target: x86_64-linux-gnu Created attachment 25883 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25883 Testcase When analyzing performance of 410.bwaves from SPEC 2006 I've been compiling a slightly modified source and noticed that vectorizer generates only useless run-time checks for the Profitability threshold. It is observable when compiling the attached simple file with trunk revision 181552 with the following options: /path/to/compiler/gfortran -S -Ofast -g -funroll-loops -fpeel-loops -fno-prefetch-loop-arrays -march=bdver1 -mtune=bdver1 -mveclibabi=svml -DSPEC_CPU_LP64 test.f -fdump-tree-vect-details -fverbose-asm --param min-vect-loop-bound=8 The last parameters just forces the threshold to be 19, so that it is easier to spot in the IL than the original 2. And the IL part with the test looks like this: D.1883_6 = *nb_5(D); ... D.1962_99 = (character(kind=4)) D.1883_6; D.1963_100 = D.1962_99 = 19; if (D.1963_100 != 0) goto bb 17; else goto bb 18; bb 17: prologue_after_cost_adjust.24_101 = (character(kind=4)) D.1883_6; bb 18: Invalid sum of incoming frequencies 2800, should be 1400 # prologue_after_cost_adjust.24_102 = PHI prologue_after_cost_adjust.24_101(17), prolog_loop_niters.22_90(16) D.1965_103 = prolog_loop_niters.22_90 == 0; if (D.1965_103 != 0) goto bb 22; else goto bb 19; The thing is that prologue_after_cost_adjust.24_102 does not appear in the IL anywhere else (all occurrences of all SSA names of the variable are in the above snippet), the phi node is useless together with the condition and both are promptly removed by subsequent passes. I therefore think the vectorizer either should not generate this calculation at all or should do something with the result. Finally, the whole point of the examination was to explore ways of avoiding an expensive prologue when the number of iterations is small, because then the vectorizer actually makes the generated code much slower. It would therefore be great if we could avoid as much of the prologue as possible when the threshold is not exceeded.
[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264 --- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-11-22 14:18:35 UTC --- Fixed. Improving the situation with the clobbers should be tracked somewhere else.
[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #11 from Michael Matz matz at gcc dot gnu.org 2011-11-22 14:19:17 UTC --- .
[Bug rtl-optimization/50765] [4.7 Regression] ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50765 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 14:23:02 UTC --- Author: jakub Date: Tue Nov 22 14:22:56 2011 New Revision: 181617 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181617 Log: PR tree-optimization/50765 * gcc.dg/pr50765.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50765.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-22 CC||iains at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org 2011-11-22 14:37:23 UTC --- any progress on resolving this .. or any more input needed?
[Bug rtl-optimization/50765] [4.7 Regression] ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50765 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 14:40:49 UTC --- Fixed.
[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #11 from vries at gcc dot gnu.org 2011-11-22 14:51:37 UTC --- I can't reproduce the problem from the description with 4.7, but I can reproduce the problem from comment 4 with 4.7. Tentative patch for test-case from comment 4: ... Index: gcc/gimple-low.c === --- gcc/gimple-low.c (revision 181172) +++ gcc/gimple-low.c (working copy) @@ -680,6 +680,12 @@ block_may_fallthru (const_tree block) case CLEANUP_POINT_EXPR: return block_may_fallthru (TREE_OPERAND (stmt, 0)); +case DO_STMT: + /* DO_STMT is part of cp-tree.def, so this should be moved to a + cp-specific file. */ + /* If DO_BODY doesn't fall thru, then DO_STMT doesn't either. */ + return block_may_fallthru (TREE_OPERAND (stmt, 1)); + default: return true; } ... Perhaps we should file a separate bug for the test-case from comment 4.
[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125 --- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-11-22 14:56:03 UTC --- Author: matz Date: Tue Nov 22 14:55:58 2011 New Revision: 181619 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181619 Log: PR other/51125 * trans-mem.c (expand_block_tm): Ignore clobbers. Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-11-22 14:57:54 UTC --- Fixed. (As per http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02169.html an optimization opportunity remains)
[Bug middle-end/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-11-22 15:05:13 UTC ---
--- Comment #1 from Andrew Macleod amacleod at redhat dot com 2011-11-21
19:21:30 UTC ---
32 bit targets don't usually support 128 bit atomic operations natively, and
leave calls to be resolved by an external atomic library. There was some
issue with X32 support where 32 bit could support it under some circumstances.
Now gcc/testsuite/lib/target-supports.exp defines the testsuite check for
whether 128 bit is supported as:
proc check_effective_target_sync_int_128 { } {
if { ([istarget x86_64-*-*] || [istarget i?86-*-*])
![is-effective-target ia32] } {
return 1
} else {
return 0
}
}
I presume if 32 bit solaris isn't supporting 128 bit operations then this
needs
to be tweaked...
There's nothing Solaris-specific here, as I'm seeing the same issue on a
bi-arch i386-apple-darwin9.8.0 compiler for the 64-bit multilib. It
seems the 32-bit compiler doesn't generate the 128-bit atomic insns when
generating 64-bit code.
Rainer
[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-22 15:04:33 UTC --- Author: paolo Date: Tue Nov 22 15:04:27 2011 New Revision: 181620 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181620 Log: 2011-11-22 Paolo Carlini paolo.carl...@oracle.com PR c++/51196 * typeck.c (cp_build_binary_op, [case EQ_EXPR]): For targets having TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, do here the -Wzero-as-null-pointer-constant warning for pmf == 0. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51196 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22 15:06:34 UTC --- Thanks a lot Greta for testing, patch applied!
[Bug middle-end/51261] [4.7 Regression] -fcompare-debug with memset()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51261 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-22 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 15:19:53 UTC --- (In reply to comment #6) I suppose I don't really object to a workaround in libjava, but surely the sensible thing to do is fix isspace() not to throw. It can't, anyway: that would be in breach of its spec. Sorry, forgot about this PR. isspace is actually marked as not throwing, i.e. throw() in C++. In glibc 2.15+ it happens to be implemented as throw() inline function which calls another function (which is throw() too), the problem is that with -fnon-call-exceptions the compiler doesn't know the function pointer is always non-NULL and assumes the call instruction might throw on SIGSEGV/SIGILL etc. That will always work, but the compiler must assume it doesn't always, thus it needs -lsupc++ support with which libjava is not linked.
[Bug c++/51270] New: constness violation is accepted without any warning but leads to a required function call being eliminated during optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270 Bug #: 51270 Summary: constness violation is accepted without any warning but leads to a required function call being eliminated during optimization Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: michiel_dewi...@agilent.com Created attachment 25884 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25884 Standalone source file Bug summary: constness violation is accepted without any warning but leads to a required function call being eliminated during optimization The code itself has a problem in the function faulty_compiled_function: Feeding the return value of pass_through as argument to recast_reference violates const regulations. This error is never caught by at least g++ 4.4.2 and g++ 4.6.2 on x86_64. Far worse, when compiling with -O1 or bigger, the optimizer eliminates the call to pass_through and feeds invalid data into recast_reference. Proposed treatment: Either there must be an error keeping this code from compiling, or the optimization must be able to handle it properly. Bug triggered as follows: Compile using g++ -O faulty_optimization_of_invalid_const_usage.cpp Run ./a.out ; echo $0 This should return exit code 0. It returns exit code 1. Without optimization, there is no error. The error occurs at any nonzero optimization level, even when using -fno-strict-aliasing -fno-inline -fno-omit-stack-frame. $ gcc -v COLLECT_GCC=gcc_x86_64 COLLECT_LTO_WRAPPER=/gfs/belgium/gntnas01/d3/hped_build_gent/tools/gcc/4.6.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/hped/builds/tools/gcc/4.6.2 --enable-languages=c,c++ --with-gmp=/hfs/d1/local/dbjornba/btmp --with-mpfr=/hfs/d1/local/dbjornba/btmp --with-mpc=/hfs/d1/local/dbjornba/btmp Thread model: posix gcc version 4.6.2 (GCC)
[Bug c++/51270] constness violation is accepted without any warning but leads to a required function call being eliminated during optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270 --- Comment #1 from Michiel De Wilde michiel_dewilde at agilent dot com 2011-11-22 15:26:42 UTC --- Created attachment 25885 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25885 preprocessed source code (*.ii)
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-11-22
Summary|internal compiler error: in |[4.6/4.7 Regression] ICE in
|finish_decltype_type, at|finish_decltype_type, at
|cp/semantics.c:5244 |cp/semantics.c:5244
Ever Confirmed|0 |1
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22
15:37:17 UTC ---
Can be reduced to this, and seems a Regression:
struct Funny
{
int print3(int) const;
};
templatetypename X, X ff
void c();
templatetypename X, X ff, typename R, typename... A
void xx(A... args)
{
cdecltype(ff), ff();
}
int main()
{
xxint (Funny::*)(int) const, Funny::print3, int, int(3);
}
[Bug fortran/51267] loop optimization error using LOC function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-11-22 15:40:43 UTC --- (In reply to comment #0) Created attachment 25880 [details] simple source file The small program attached fails using gfortran 4.6.1 (ubuntu oneiric built) using -O1 optimization level or higher (ok at -O0). It succeeds with gfortran 4.5.4 at all -O levels. It ends by printing a boolean value : T if the test is ok, F else. $ gfortran-4.5 -O1 -Wall -Wextra bug46_stat.f ; ./a.out tab( 1 )= -1 tab( 2 )= -1 tab( 3 )= -1 tab( 4 )= -1 tab( 5 )= -1 tab( 6 )= -1 T $ gfortran-4.6 -O1 -Wall -Wextra bug46_stat.f ; ./a.out tab( 1 )= 134520832 tab( 2 )=10813028 tab( 3 )= -1 tab( 4 )= 0 tab( 5 )=10870894 tab( 6 )= -1 F Ouput with '-v' : Have you considered compiling the code with -fcheck=all? It shows that you have an array reference issue. troutmask:sgk[206] gfc4x -o z -fcheck=all -O bug46_stat.f troutmask:sgk[207] ./z At line 10 of file bug46_stat.f Fortran runtime error: Index '-7' of dimension 1 of array 'ius' below lower bound of 1
[Bug fortran/51266] [F08] Pointer initialization in PARAMETER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51266 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-22 15:44:34 UTC --- Hmm, I somehow have the feeling that encountered this bug already. See the thread starting at http://j3-fortran.org/pipermail/j3/2011-November/004840.html I think I concur with Malcolm that the code of comment 0 cannot be implemented (at least not without combining the linker with the front-end compiler, something no one wants to do): http://j3-fortran.org/pipermail/j3/2011-November/004851.html On the other hand, I think Bob right at http://j3-fortran.org/pipermail/j3/2011-November/004857.html that the current standard seems to have a loop hole. I probably should have realized the discussion earlier - on the other hand, Bob seems to insist (cf. link above) that the program is not only valid but should also be valid - otherwise, I presume, he wouldn't have posted it at comp.lang.fortran. (A PR might already exist for this thread.)
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot
|gnu.org |com
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22
15:46:04 UTC ---
On it. A tad simpler:
struct Funny
{
int print(int);
};
templatetypename X, X ff
void c();
templatetypename X, X ff
void xx()
{
cdecltype(ff), ff();
}
int main()
{
xxint (Funny::*)(int), Funny::print();
}
[Bug c++/51270] constness violation is accepted without any warning but leads to a required function call being eliminated during optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-22
15:47:45 UTC ---
If you want warnings then you should request them using -Wall etc.
Although doing so at -O2 gives this, which isn't actually very helpful:
e.cpp:67:60: warning: 'anonymous' is used uninitialized in this function
[-Wuninitialized]
There is no constness error, the argument to recast_reference creates a
temporary of type 'char const*' which binds to a reference-to-const to that
type:
You can rewrite it as:
int* faulty_compiled_function(char* val)
{
char const* tmp = pass_through(val);
return recast_reference(tmp);
}
pass_through and recast_reference are not needed, they simply serve to hide the
error in your code, which is that you return a reference to the temporary, and
use it in main() after the temporary has gone out of scope. Therefore the code
is invalid.
[Bug rtl-optimization/51271] New: ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 Bug #: 51271 Summary: ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: vr...@gcc.gnu.org Created attachment 25886 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25886 preprocessed res_hconf.c I ran into this ICE with a mips64el cross compiler build from r181586: ... res_hconf.c: In function 'skip_string': res_hconf.c:104:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2244 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ... compile line: ... mips64el-linux-gnu-gcc -mabi=n32 res_hconf.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-strict-prototypes -Wno-write-strings -Wstrict-prototypes -fexceptions -mabi=n32 ... configure line: ... /scratch/vries/b4/ref-mips64-ml-11-11-21/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=mips64el-linux-gnu --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-checking=yes,rtl --disable-multilib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --prefix=/opt/codesourcery --disable-libffi --disable-libquadmath --enable-languages=c --with-sysroot=/opt/codesourcery/mips64el-linux-gnu/libc --with-build-sysroot=/scratch/vries/b4/ref-mips64-ml-11-11-21/install/mips64el-linux-gnu/libc --with-gmp=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr --with-mpfr=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr --with-mpc=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr --with-ppl=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr --with-libelf=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/vries/b4/ref-mips64-ml-11-11-21/install/mips64el-linux-gnu/bin --with-build-time-tools=/scratch/vries/b4/ref-mips64-ml-11-11-21/install/mips64el-linux-gnu/bin ...
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22
15:48:12 UTC ---
Even:
struct Funny;
templatetypename X
void c();
templatetypename X
void xx()
{
cdecltype(ff)();
}
int main()
{
xxint(Funny::*)(int)();
}
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22 15:50:04 UTC --- oops, scratch the latter ;)
[Bug c++/51270] constness violation is accepted without any warning but leads to a required function call being eliminated during optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-22
15:50:33 UTC ---
If you eliminate the obfuscation you get this:
int* faulty_compiled_function(char* val)
{
char const* tmp = val;
return (int*)tmp;
}
char* input = (char*)0x1234;
int* output = (int*)0x1234;
int main(int argc, char* argv[])
{
return (faulty_compiled_function(input) == output ? 0 : 1);
}
Which correctly warns you about the problem even without -Wall
If there's a bug in GCC it's that it doesn't see through two layers of
functions to determine that you're returning a reference to a temporary.
[Bug c++/51270] constness violation is accepted without any warning but leads to a required function call being eliminated during optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-22
15:55:41 UTC ---
This variation is a bit closer to your original and doesn't get a warning:
int* faulty_compiled_function(char* val)
{
char const* const tmp = (const char*)val;
return (int*)tmp;
}
So maybe there is a missed warning bug. Other compilers miss it too.
[Bug middle-end/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258 --- Comment #4 from Andrew Macleod amacleod at redhat dot com 2011-11-22 16:07:52 UTC --- I built a compiler in my linux box with a target of i386-apple-darwin. during expanding an atomic_exchange it fails the call to can_compare_and_swap_p(TImode, true). It returns CODE_FOR_nothing for both cases: icode = direct_optab_handler (atomic_compare_and_swap_optab, mode); if (icode != CODE_FOR_nothing) return true; icode = optab_handler (sync_compare_and_swap_optab, mode); if (icode != CODE_FOR_nothing) return true; so something in the config/i386/sync.md file must be wrong for a 32 bit compiler which specifies -m64. It does not set up the optab table for a TI mode compare_and_swap.
[Bug tree-optimization/51074] No constant folding performed for VEC_PERM_EXPR, VEC_INTERLEAVE*EXPR, VEC_EXTRACT*EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074
--- Comment #8 from Richard Henderson rth at gcc dot gnu.org 2011-11-22
16:08:17 UTC ---
No, Jakub, vector elements are in memory order. There is no adjustment
to be made here.
Unfortunately ppc represents its interleave patterns non-standard, but
one can interpret. E.g. the ultimate implementation of
vec_interleave_low_v4si:
(define_insn altivec_vmrglw
[(set (match_operand:V4SI 0 register_operand =v)
(vec_merge:V4SI
(vec_select:V4SI (match_operand:V4SI 1 register_operand v)
(parallel [(const_int 2)
(const_int 0)
(const_int 3)
(const_int 1)]))
(vec_select:V4SI (match_operand:V4SI 2 register_operand v)
(parallel [(const_int 0)
(const_int 2)
(const_int 1)
(const_int 3)]))
(const_int 5)))]
By my reading that's { 4+0, 0, 4+1, 1 } if you consider op2 to be +4.
Which is ... argument reversed from the normal { 0, 4, 1, 5 } that we
expected, but certainly not the { 2, 6, 3, 7 } that you were going to
generate with that patch.
As for the swapped operands... that does seem to correlate with the
actual output quoted in comment #6. It seems like we need to dig and
figure out if the rtl is wrong, or if arguments got swapped along the
N stage path between vector.md and the ultimate altivec.md pattern.
[Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-22 16:09:19 UTC --- Well, that one now gets a diagnostic and didn't get one before is a change, but the question is whether it is a progression or a regression. NAG prints: Error: line 15: USE MYINTERFACES in program-unit MYSUB imports symbol MYSUB g95 prints: Module 'myinterfaces' at (1) redefines the current program unit 'mysub' pathf95 prints: MYSUB is the name of this program unit, therefore it must not be use associated from module MYINTERFACES. openf95 prints: MYSUB is the name of this program unit, therefore it must not be use associated from module MYINTERFACES. crayftn prints: MYSUB is the name of this program unit, therefore it must not be use associated from module MYINTERFACES. While ifort prints (only with -stand f95/f03): warning #7925: An interface-block in a subprogram shall not contain an interface-body for a procedure defined by that subprogram. [MYSUB] And pgf90 -Minfo=all and sunf95 -w0 simply silently accept the program. I think the program is indeed invalid - but if needed, I can check the standard. One could consider allowing it with a warning (as ifort does), but I am not sure one should.
[Bug tree-optimization/51074] No constant folding performed for VEC_PERM_EXPR, VEC_INTERLEAVE*EXPR, VEC_EXTRACT*EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074 --- Comment #9 from Pat Haugen pthaugen at gcc dot gnu.org 2011-11-22 16:15:09 UTC --- (In reply to comment #7) Created attachment 25878 [details] gcc47-pr51074-be.patch Big endian fix, untested. This patch fixes the issue on both my testcase and the cpu2000 benchmark.
[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 16:34:54 UTC --- (In reply to comment #10) Created attachment 25882 [details] Patch for new memset/memcpy implementation (In reply to comment #9) Regressions caused by the new memset/memcpy expansion are FAIL: 27_io/basic_filebuf/seekoff/wchar_t/1.cc execution test FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9874.cc execution test FAIL: 27_io/manipulators/basefield/char/1.cc execution test FAIL: 27_io/manipulators/basefield/wchar_t/1.cc execution test FAIL: 27_io/objects/wchar_t/12.cc execution test FAIL: 27_io/objects/wchar_t/13.cc execution test FAIL: events run FAIL: gcc.target/i386/cleanup-1.c execution test FAIL: gcc.target/i386/cleanup-2.c execution test FAIL: gcc.target/i386/pr34077.c (internal compiler error) FAIL: gcc.target/i386/pr34077.c (internal compiler error) FAIL: gcc.target/i386/pr34077.c (test for excess errors) FAIL: gcc.target/i386/pr34077.c (test for excess errors) FAIL: gfortran.fortran-torture/execute/arrayarg.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops With the attached patch fails on PR34077 and arrayarg.f90 are fixed, fails on cleanup-tests are probably caused by incorrect testcase (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503). Do you have a patch for those C++ and Java regressions?
[Bug c++/51270] missed warning about returning reference to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|constness violation is |missed warning about
|accepted without any|returning reference to
|warning but leads to a |temporary
|required function call |
|being eliminated during |
|optimization|
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-22
16:41:16 UTC ---
Very similar to my PR 49974.
Still no warning even without the (highly questionable) cast:
char const* const faulty_compiled_function(char* val)
{
char const* const tmp = (const char*)val;
return tmp;
}
N.B. Clang warns for that variation (but not the others):
faulty_optimization_of_invalid_const_usage.cpp:4:10: warning: returning
reference to local temporary object [-Wreturn-stack-address]
return tmp;
^~~
faulty_optimization_of_invalid_const_usage.cpp:3:22: note: binding reference
variable 'tmp' here
char const* const tmp = (const char*)val;
^
[Bug c++/51143] [C++11][DR 1159] Alias template allows class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51143 --- Comment #3 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-22 16:41:18 UTC --- Author: dodji Date: Tue Nov 22 16:41:10 2011 New Revision: 181626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181626 Log: PR c++/51143 - Alias template allows class definition gcc/cp PR c++/51143 * parser.c (cp_parser_alias_declaration): Don't allow type definition in templates. gcc/testsuite PR c++/51143 * g++.dg/cpp0x/alias-decl-16.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51143] [C++11][DR 1159] Alias template allows class definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51143 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-22 16:42:11 UTC --- This should be fixed in trunk (4.7) now.
[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #12 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com 2011-11-22 16:54:35 UTC --- Do you have a patch for those C++ and Java regressions? What regressions do you mean exactly? I managed to fix the bootstraps (with sse_loop enabled again), but there are still some fails, so I don't send the patch. Currently I don't have a fix that solves all the problems - the attached to previous letter patch fixes some of them, but there are other fails (in 27_io and in some specs2k). I'm continuing debugging and hope to finish fixes soon. On 22 November 2011 20:34, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 16:34:54 UTC --- (In reply to comment #10) Created attachment 25882 [details] Patch for new memset/memcpy implementation (In reply to comment #9) Regressions caused by the new memset/memcpy expansion are FAIL: 27_io/basic_filebuf/seekoff/wchar_t/1.cc execution test FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9874.cc execution test FAIL: 27_io/manipulators/basefield/char/1.cc execution test FAIL: 27_io/manipulators/basefield/wchar_t/1.cc execution test FAIL: 27_io/objects/wchar_t/12.cc execution test FAIL: 27_io/objects/wchar_t/13.cc execution test FAIL: events run FAIL: gcc.target/i386/cleanup-1.c execution test FAIL: gcc.target/i386/cleanup-2.c execution test FAIL: gcc.target/i386/pr34077.c (internal compiler error) FAIL: gcc.target/i386/pr34077.c (internal compiler error) FAIL: gcc.target/i386/pr34077.c (test for excess errors) FAIL: gcc.target/i386/pr34077.c (test for excess errors) FAIL: gfortran.fortran-torture/execute/arrayarg.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops With the attached patch fails on PR34077 and arrayarg.f90 are fixed, fails on cleanup-tests are probably caused by incorrect testcase (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503). Do you have a patch for those C++ and Java regressions?
[Bug tree-optimization/51074] No constant folding performed for VEC_PERM_EXPR, VEC_INTERLEAVE*EXPR, VEC_EXTRACT*EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22 16:57:39 UTC --- Author: jakub Date: Tue Nov 22 16:57:33 2011 New Revision: 181627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181627 Log: PR tree-optimization/51074 * fold-const.c (fold_binary_loc): Fix up VEC_INTERLEAVE_*_EXPR handling for BYTES_BIG_ENDIAN. * optabs.c (can_vec_perm_for_code_p): Likewise. * gcc.dg/vect/pr51074.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr51074.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-22
17:13:26 UTC ---
Your testcase doesn't ressemble the original, the inner for cycles need
clearing of the iteration variable.
double C[10][4], B[10][10], A[10][4];
void
test (void)
{
int i = 0, j = 0, l = 0;
for (l = 0; l 10; l++)
for (j = 0; j 10; j += 2)
for (i = 0; i 4; i++)
{
C[j + 0][i] = C[j + 0][i] + A[l][i] * B[j + 0][l];
C[j + 1][i] = C[j + 1][i] + A[l][i] * B[j + 1][l];
}
}
is IMHO just a matter whether graphite can -floop-interchange this or not.
If you swap manually the l and j for lines, the generated code looks better,
though for some reason we unroll even the l loop which increases register
pressure too much.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 17:21:38 UTC --- HJ, with binutils 2.22 now released, could you please work to get this fixed? IMO binutils releases need to work for bootstrapping gcc out of the box without any workarounds on the part of the installer. Thanks. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #21 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 17:52:52 UTC --- (In reply to comment #20) HJ, with binutils 2.22 now released, could you please work to get this fixed? IMO binutils releases need to work for bootstrapping gcc out of the box without any workarounds on the part of the installer. There is not much I can do when there are 2 binutils used.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 17:55:15 UTC --- But this is the common case: you cannot expect or require the bootstrap compiler to use the same linker as you configure with. This is a bootstrap failure which is going to get us much noise if not fixed. Rainer
[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888 --- Comment #8 from Andrew Haley aph at gcc dot gnu.org 2011-11-22 17:55:51 UTC --- (In reply to comment #7) isspace is actually marked as not throwing, i.e. throw() in C++. In glibc 2.15+ it happens to be implemented as throw() inline function which calls another function (which is throw() too), the problem is that with -fnon-call-exceptions the compiler doesn't know the function pointer is always non-NULL and assumes the call instruction might throw on SIGSEGV/SIGILL etc. That will always work, but the compiler must assume it doesn't always, thus it needs -lsupc++ support with which libjava is not linked. Thank you, all is now clear. I wonder if it might make sense to fix this in a more general way than simply not calling isspace(). Perhaps we could provide a weak __cxa_call_unexpected, or find some way of persuading g++ not to emit such a call.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 18:03:09 UTC --- (In reply to comment #22) But this is the common case: you cannot expect or require the bootstrap compiler to use the same linker as you configure with. This is a bootstrap failure which is going to get us much noise if not fixed. Have you tried the patch in comment 18?
[Bug c++/51270] missed warning about returning reference to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270 --- Comment #6 from Michiel De Wilde michiel_dewilde at agilent dot com 2011-11-22 18:20:44 UTC --- Hi Jonathan, thanks for the quick analysis. I did not realize that char * and char const * are not reference-compatible, leading to a temporary being introduced when initializing a char const * const reference from a char * . Therefore this is not a true gcc bug. It would be nice though to have a warning for this case, i.e. when only the different constnesses after pointer dereferencing are responsible for temporaries being created for const lvalue initializations from other lvalues. I understand this may be difficult. Improved tracking of the reference to the temporary would also be nice. Thanks, Michiel
[Bug tree-optimization/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2011-11-22 18:34:03 UTC --- Created attachment 25887 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25887 general code the more general code used to find the most efficient matrix multiply for sizes 4,10,10
[Bug tree-optimization/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2011-11-22 18:34:48 UTC --- (In reply to comment #3) is IMHO just a matter whether graphite can -floop-interchange this or not. If you swap manually the l and j for lines, the generated code looks better, though for some reason we unroll even the l loop which increases register pressure too much. Unfortunately, the issue is not just loop ordering or loop unrolling. I have a code generator which tries systematically all possible loop orderings, and all possible unroll factors. For this testcase (matrix sizes 4,10,10) the best cray output (this one) runs at 10.8 Gflops. The best gcc compiled version runs at 4.7 Gflops (smm_dnn_4_10_10_1_1_10_2). I attach the test code, which I use for testing.
[Bug target/50906] e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 --- Comment #17 from Kyle Moffett Kyle.D.Moffett at boeing dot com 2011-11-22 18:50:20 UTC --- Ok, a new kernel based on 3.2-rc1 resolved my crashing issues entirely. I wasn't too worried about my DDR clocks since I have ECC memory and EDAC never reported any errors. Using the gcc-4.6 fix on top of 4.6.2, I get the following diffs in the testsuite summary between 4.6.2-unpatched and 4.6.2-patched. I'm in the process of running a second build with BOOT_CFLAGS=-Os, but I'll be out of the office for Thanksgiving until next Monday and probably won't be able to check on it during that time. These appear to be EH bugs fixed by your changes: -FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test These are tests that shouldn't be run on e500/SPE as they build with -mcpu=power5. These tests fail with SIGILL while executing an lfd opcode; I'm not sure why they passed before: +FAIL: gcc.target/powerpc/ppc-fma-5.c execution test +FAIL: gfortran.dg/pr47614.f -O0 execution test +FAIL: gfortran.dg/pr47614.f -O1 execution test +FAIL: gfortran.dg/pr47614.f -O2 execution test +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer execution test +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-loops +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test +FAIL: gfortran.dg/pr47614.f -O3 -g execution test +FAIL: gfortran.dg/pr47614.f -Os execution test There's no other delta in the testsuite summary, so I feel pretty confident that there were no regressions introduced by this patch for e500 at least. Thanks again for your help! Cheers, Kyle Moffett
[Bug middle-end/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-11-22 18:52:56 UTC --- (In reply to comment #4) so something in the config/i386/sync.md file must be wrong for a 32 bit compiler which specifies -m64. It does not set up the optab table for a TI mode compare_and_swap. -mcx16 ?
[Bug other/51272] New: ld: Unsatisfied symbol _ITM_registerTMCloneTable in file /test/gnu/gcc/objdir/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51272
Bug #: 51272
Summary: ld: Unsatisfied symbol _ITM_registerTMCloneTable in
file /test/gnu/gcc/objdir/
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
In stage1 building libgomp:
configure:3688: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include-g -O2 conftest.c
5
ld: Unsatisfied symbol _ITM_registerTMCloneTable in file
/test/gnu/gcc/objdir/./gcc/crtbegin.o
ld: Unsatisfied symbol _ITM_deregisterTMCloneTable in file
/test/gnu/gcc/objdir/./gcc/crtbegin.o
2 errors.
collect2: error: ld returned 1 exit status
configure:3692: $? = 1
configure:3729: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU OpenMP Runtime Library
| #define PACKAGE_TARNAME libgomp
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU OpenMP Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgomp/;
| #define PACKAGE libgomp
| #define VERSION 1.0
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3735: error: in `/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libgomp':
configure:3738: error: C compiler cannot create executables
2011-11-21 Richard Henderson r...@redhat.com
* crtstuff.c (USE_TM_CLONE_REGISTRY): Default to 1 on ELF.
(__TMC_LIST__, __TMC_END__): New.
(__do_global_dtors_aux): Call _ITM_deregisterTMCloneTable.
(__do_global_dtors): Likewise.
(frame_dummy): Call _ITM_registerTMCloneTable.
(__do_global_ctors_1): Likewise.
[Bug c++/51270] missed warning about returning reference to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-22
18:56:37 UTC ---
I don't think the warning should be restricted to conversions that only involve
different const-ness.
Here's a simpler testcase for the missed warning:
const int f(long l)
{
const int i = l;
return i;
}
See also PR 51066
[Bug fortran/50981] [4.4/4.5/4.6/4.7 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2011-11-22 18:57:52 UTC --- I will take care of this one after mid-december.
[Bug fortran/51250] [4.7 Regression] Bug with SUM(,dim,mask)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51250 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org 2011-11-22 19:02:27 UTC --- I will take care of this one after mid-december. Beside the workaround proposed by Tobias, you can use a variable instead of a constant for SUM's DIM argument. Or you can patch gfc_inline_intrinsic_function_p (in trans-intrinsic.c) to return false in the SUM case.
[Bug testsuite/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Component|middle-end |testsuite
--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-11-22 19:22:54
UTC ---
It is a testsuite problem:
/* { dg-options -mcx16 { target { x86_64-*-* } } } */
Something is missing there ... ;)
[Bug testsuite/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
--- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2011-11-22 19:29:20
UTC ---
Can somebody please test following change:
--cut here--
Index: atomic-exchange-5.c
===
--- atomic-exchange-5.c (revision 181628)
+++ atomic-exchange-5.c (working copy)
@@ -2,7 +2,7 @@
values with each valid memory model. */
/* { dg-do run } */
/* { dg-require-effective-target sync_int_128 } */
-/* { dg-options -mcx16 { target { x86_64-*-* } } } */
+/* { dg-options -mcx16 { target { i?86-*-* x86_64-*-* } } } */
/* Test the execution of the __atomic_X builtin for a 16 byte value. */
--cut here--
[Bug testsuite/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258 --- Comment #8 from Andrew Macleod amacleod at redhat dot com 2011-11-22 19:34:03 UTC --- yes, presuming that it works, which I think it will, that will have to be applied to all the gcc.dg/atomic*-5.c files, as well as the gcc.dg/simulate-thread/atomic-*-int128.c files.
[Bug c++/51270] missed warning about returning reference to temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-22 Ever Confirmed|0 |1 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-22 19:39:27 UTC --- since at least one other compiler (clang) warns about the testcase in comment 7 I'm going to confirm this
[Bug middle-end/51273] New: ICE: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 with -O -fgnu-tm, transaction_safe and overloaded contructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51273 Bug #: 51273 Summary: ICE: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 with -O -fgnu-tm, transaction_safe and overloaded contructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: amacl...@redhat.com Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25888 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25888 reduced testcase Compiler output: $ gcc -O -fgnu-tm testcase.C testcase.C:13:1: internal compiler error: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r181609 - crash
[Bug fortran/51267] loop optimization error using LOC function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267
--- Comment #2 from Mathieu priv123 at hotmail dot fr 2011-11-22 20:22:15 UTC
---
Sure, and we are especially fans of -fbound-checks but we can not use it on
half of the code because of this usage.
For the story :
{
I reproduced here with this small code a part of the 1.e6 lines of our code
(see www.code-aster.org for more interest). It's 20 years old but it's always
evolving every week.
This usage (with an array allocated elsewhere and used in read/write using an
offset computed by LOC) allowed to simulate dynamic allocations and out-of-core
memory management in f77.
So if we are working to use current allocation management it requires to change
a lot of lines of code and the refactoring will be done part by part...
}
And just try this, it works :
c do 12 i=1,3*n
cius(iad+i) = -1
c 12 continue
but not the unrolled loop.
That's why I think that the optimizer fails on that loop (and probably only
when the array of dimension(1)).
Do you know what does change between 4.5 and 4.6 that can explain the
difference of behavior ?
Any option to tune the behavior ?
Thx
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-22 20:48:38 UTC --- Author: paolo Date: Tue Nov 22 20:48:33 2011 New Revision: 181638 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181638 Log: /cp 2011-11-22 Paolo Carlini paolo.carl...@oracle.com PR c++/51265 * semantics.c (finish_decltype_type): Handle PTRMEM_CST. /testsuite 2011-11-22 Paolo Carlini paolo.carl...@oracle.com PR c++/51265 * g++.dg/cpp0x/decltype36.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764 --- Comment #12 from vries at gcc dot gnu.org 2011-11-22 20:55:06 UTC --- Author: vries Date: Tue Nov 22 20:55:01 2011 New Revision: 181639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181639 Log: 2011-11-22 Tom de Vries t...@codesourcery.com PR rtl-optimization/50764 * sched-deps.c (sched_analyze_insn): Make sure frame-related insns are not moved past preceding jump. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764 --- Comment #13 from vries at gcc dot gnu.org 2011-11-22 20:55:13 UTC --- Author: vries Date: Tue Nov 22 20:55:10 2011 New Revision: 181640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181640 Log: 2011-11-22 Tom de Vries t...@codesourcery.com PR rtl-optimization/50764 * gcc.dg/pr50764.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50764.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/51267] loop optimization error using LOC function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-11-22 20:56:43 UTC --- According my archived builds r165415 (20101013) gives the result you expect r165758 (20101021) does not. Any option to tune the behavior ? -fno-tree-ds seems to do the trick: from the C manual http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options -ftree-dce Perform dead code elimination (DCE) on trees. This flag is enabled by default at -O and higher.
[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from vries at gcc dot gnu.org 2011-11-22 21:01:02 UTC --- Patch and test-case checked in, marking resolved fixed.
[Bug fortran/51267] loop optimization error using LOC function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-11-22 21:03:51 UTC --- -fno-tree-ds seems to do the trick: sorry, it is -fno-tree-dse and -ftree-dse Perform dead store elimination (DSE) on trees. A dead store is a store into a memory location which will later be overwritten by another store without any intervening loads. In this case the earlier store can be deleted. This flag is enabled by default at -O and higher. (it makes more sense;-).
[Bug tree-optimization/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-11-22 21:08:47 UTC --- ... I attach the test code, which I use for testing. Compiling the code with -O3 gives the following ICE pr51179_1.f90: In function 'tiny_find': pr51179_1.f90:3594:0: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:422 (if nobody beats me, I'll try to reduce the code and open a new pr). On a 2.5Ghz Core2Duo, I get 4.1Gflops with -O2 -ftree-vectorize.
[Bug libstdc++/51181] [4.7 regression] libstdc++.so __sync_sub_and_fetch_4 linkage error causing many test suite failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51181 Cesar Strauss cestrauss at gmail dot com changed: What|Removed |Added CC||cestrauss at gmail dot com --- Comment #10 from Cesar Strauss cestrauss at gmail dot com 2011-11-22 21:32:33 UTC --- *** Bug 51140 has been marked as a duplicate of this bug. ***
[Bug libstdc++/51140] libstdc++-v3/libsupc++/eh_tm.cc:48: undefined reference to `___sync_sub_and_fetch_4'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51140 Cesar Strauss cestrauss at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Cesar Strauss cestrauss at gmail dot com 2011-11-22 21:32:33 UTC --- (In reply to comment #3) I suppose this is a duplicate of PR51181 Indeed. The fix for PR51181 also fixed the build failure I reported here. Thanks, Cesar *** This bug has been marked as a duplicate of bug 51181 ***
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-22 21:37:27 UTC --- Author: paolo Date: Tue Nov 22 21:37:24 2011 New Revision: 181641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181641 Log: /cp 2011-11-22 Paolo Carlini paolo.carl...@oracle.com PR c++/51265 * semantics.c (finish_decltype_type): Handle PTRMEM_CST. /testsuite 2011-11-22 Paolo Carlini paolo.carl...@oracle.com PR c++/51265 * g++.dg/cpp0x/decltype36.C: New. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/decltype36.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/51265] [4.6/4.7 Regression] ICE in finish_decltype_type, at cp/semantics.c:5244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51265 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22 21:38:37 UTC --- Fixed for 4.6.3 and mainline.
[Bug ada/49084] [4.7 regression] bootstrap failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49084 --- Comment #9 from Cesar Strauss cestrauss at gmail dot com 2011-11-22 21:49:37 UTC --- (In reply to comment #7) Hmm, this is due usage of %lld in printf-formatter. Does following patch fix your issue? I did encounter the build failure reported in comment #6 (unknown conversion type character 'l' in format) on i386-pc-mingw32, and the patch given in comment #7 did fix this failure for me. A similar solution is also needed in gcc/ira-color.c (print_hard_regs_subforest), where %lld is also used. This allowed the build to continue to the point where I could reproduce the failure described in comment #8.
[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51222 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-22 Blocks|51185 | Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-22 21:50:48 UTC --- Confirmed indeed (and cleared Blocks field, PR51185 is fixed anyway).
[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218 --- Comment #20 from Harald Anlauf anlauf at gmx dot de 2011-11-22 21:56:32 UTC --- (In reply to comment #17) Untested patch: --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -3257,6 +3255,7 @@ pure_subroutine (gfc_code *c, gfc_symbol *sym) else if (gfc_pure (NULL)) gfc_error (Subroutine call to '%s' at %L is not PURE, sym-name, c-loc); + gfc_current_ns-proc_name-attr.implicit_pure = 0; } The patch works for the testcase in comment #16. It did not produce any regressions in my tests. (It also solves my original problem, which is a nice by-product.) Thanks, Harald
[Bug tree-optimization/51179] poor vectorization on interlagos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2011-11-22 22:00:36 UTC --- (In reply to comment #3) Your testcase doesn't ressemble the original, the inner for cycles need clearing of the iteration variable. Ah, indeed... fingers were too fast. One additional data point with -O2 -ftree-vectorize -mfma4 -mavx with all loops: movslq %r8d, %rax movl$C+32, %edx xorl%esi, %esi leaqB(,%rax,8), %rcx movl$C, %eax .L3: vmovsd 80(%rcx), %xmm1 addl$2, %esi vmovapd A(%rdi), %ymm0 vmovddup%xmm1, %xmm1 vbroadcastsd(%rcx), %ymm2 addq$160, %rcx vinsertf128 $1, %xmm1, %ymm1, %ymm1 vfmaddpd(%rax), %ymm2, %ymm0, %ymm2 vmovapd %ymm2, (%rax) addq$64, %rax vfmaddpd(%rdx), %ymm1, %ymm0, %ymm0 vmovapd %ymm0, (%rdx) addq$64, %rdx cmpl$10, %esi jne .L3 This could be just vbroadcastsd 80(%rcx), %ymm1. For some reason combine pass does not form it.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-22
22:33:43 UTC ---
return (a != b || a != c) ? b : c;
test_func_0_NG and test_func_1_NG cases are related with the target
implementation of cstoresi4.
The middle end expands a complex conditional jump to cstores and
a simple conditional jumps. For expression a != b, SH's cstoresi4
implementation uses sh.c:sh_emit_compare_and_set which generates
cmp/eq and movnegt insn, because we have no cmp/ne insn. Then we've
got the sequence
mov #-1,rn
negc rn,rm
tst #255,rm
which is essentially T_reg = T_reg. Usually combine catches such
situation, but negc might be too complex for combine.
For this case, replacing current movnegt expander by insn, splitter
and peephole something like
(define_insn movnegt
[(set (match_operand:SI 0 arith_reg_dest =r)
(plus:SI (reg:SI T_REG) (const_int -1)))
(clobber (match_scratch:SI 1 =r))
(clobber (reg:SI T_REG))]
#
[(set_attr length 4)])
(define_split
[(set (match_operand:SI 0 arith_reg_dest =r)
(plus:SI (reg:SI T_REG) (const_int -1)))
(clobber (match_scratch:SI 1 =r))
(clobber (reg:SI T_REG))]
reload_completed
[(set (match_dup 1) (const_int -1))
(parallel [(set (match_dup 0)
(neg:SI (plus:SI (reg:SI T_REG)
(match_dup 1
(set (reg:SI T_REG)
(ne:SI (ior:SI (reg:SI T_REG) (match_dup 1))
(const_int 0)))])]
)
(define_peephole2
[(set (match_operand:SI 1 ) (const_int -1))
(parallel [(set (match_operand:SI 0 )
(neg:SI (plus:SI (reg:SI T_REG)
(match_dup 1
(set (reg:SI T_REG)
(ne:SI (ior:SI (reg:SI T_REG) (match_dup 1))
(const_int 0)))])
(set (reg:SI T_REG)
(eq:SI (match_operand:QI 3 ) (const_int 0)))]
REGNO (operands[3]) == REGNO (operands[0])
peep2_reg_dead_p (3, operands[0])
peep2_reg_dead_p (3, operands[1])
[(const_int 0)]
)
the above useless sequence could be removed, though we will miss
the chance that the -1 can be CSE-ed when the cstore value is
used. This will cause a bit worse code for the loop like
int
foo (int *a, int x, int n)
{
int i;
int count;
for (i = 0; i n; i++)
count += (*(a + i) != x);
return count;
}
though it may be relatively rare.
BTW, OT, (a != b || a != c) ? b : c could be reduced to b, I think.
return a = 0 b = 0 ? c : d;
x = 0 is expanded to the sequence like
ra = not x
rb = -31
rc = ra (neg rb)
T = (rc == 0)
conditional jump
and combine tries to simplify it. combine simplifies b = 0
successfully into shll and bt but fails to simplify a = 0.
It seems that combine doesn't do constant propagation well and
misses the constant -31. In this case, a peephole like
(define_peephole2
[(set (match_operand:SI 0 arith_reg_dest )
(not:SI (match_operand:SI 1 arith_reg_operand )))
(set (match_operand:SI 2 arith_reg_dest ) (const_int -31))
(set (match_operand:SI 3 arith_reg_dest )
(lshiftrt:SI (match_dup 0) (neg:SI (match_dup 2
(set (reg:SI T_REG)
(eq:SI (match_operand:QI 4 arith_reg_operand )
(const_int 0)))
(set (pc)
(if_then_else (match_operator 5 comparison_operator
[(reg:SI T_REG) (const_int 0)])
(label_ref (match_operand 6 ))
(pc)))]
REGNO (operands[3]) == REGNO (operands[4])
peep2_reg_dead_p (4, operands[0])
(peep2_reg_dead_p (4, operands[3])
|| rtx_equal_p (operands[2], operands[3]))
peep2_regno_dead_p (5, T_REG)
[(set (match_dup 2) (const_int -31))
(set (reg:SI T_REG) (ge:SI (match_dup 1) (const_int 0)))
(set (pc)
(if_then_else (match_op_dup 7 [(reg:SI T_REG) (const_int 0)])
(label_ref (match_dup 6))
(pc)))]
{
operands[7] = gen_rtx_fmt_ee (reverse_condition (GET_CODE (operands[5])),
GET_MODE (operands[5]),
XEXP (operands[5], 0), XEXP (operands[5], 1));
})
will be a workaround. It isn't ideal, but better than nothing.
return a == b ? test_sub0 (a, b) : test_sub1 (a, b);
return a != b ? test_sub0 (a, b) : test_sub1 (a, b);
This case is intresting. At -Os, two calls are converted into
one computed goto. A bit surprisingly, the conversion is done
as a side effect of combine-stack-adjustments pass. That pass
calls
cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
and the cross jumping optimization merges two calls.
With -Os -fno-delayed-branch, the OK case is compiled to
test_func_3_OK:
mov r4,r1
cmp/eq r5,r1
mov.l .L4,r0
bf .L3
mov r1,r5
mov.l .L5,r0
bra .L3
nop
.L3:
jmp @r0
nop
and the NG case
test_func_3_NG:
mov r4,r1
cmp/eq r5,r1
bt .L2
mov.l .L4,r0
bra .L3
nop
.L2:
mov.l .L5,r0
mov r1,r5
.L3:
[Bug target/51274] New: Starting with GCC 4.5, powerpc generated different code for x != 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51274 Bug #: 51274 Summary: Starting with GCC 4.5, powerpc generated different code for x != 0. Classification: Unclassified Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org Host: powerpc64-linux power-linux Target: powerpc64-linux Build: powerpc64-linux In doing some investigation for optimizations of comparisons for power7, I noticed that starting with GCC 4.5, the compiler no longer generates the code it used to for setting x = (y != 0). In the rs6000.md file, these optimizations start with the insn ne0si. In the 4.4 time frame, for -m32 (and for -m32 -mpowerpc64, which is PR 36557), gcc would generate: addic 9,3,-1 subfe 0,9,3 However, it wouldn't generate this code for -m64. Starting with 4.5, it generates the code for !(x == 0), or: cntlzw 3,3 srwi 3,3,5 xori 3,3,1 We should either remove the insns in rs6000.md that no longer are matching, or fix them so they do match. I suspect that the longer code sequence is actually faster on the newer processors, since you don't need to track the carry between the two insns.
[Bug target/51274] Starting with GCC 4.5, powerpc generated different code for x != 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51274 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org 2011-11-22 23:12:43 UTC --- Created attachment 25889 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25889 Example test case
[Bug c++/51154] internal compiler error: gimplification failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51154 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #3 from Marc Glisse marc.glisse at normalesup dot org 2011-11-22 23:36:26 UTC --- This appears to be a 4.7 regression. I got the same create_tmp_var ICE message with a different code (3.5MB, I won't reduce it since there is already a very nice testcase attached to the bug :-)
[Bug tree-optimization/51275] New: CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 Bug #: 51275 Summary: CLOBBERS can be optimized if they are right before the return (or RESX) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org Created attachment 25890 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25890 Patch which optimizes the clobbers As mentioned in Bug #51264 comment #10, clobbers can be optimized but only after inlining. I attached a patch which does the optimization in fold_all_builtins. With this patch, most of the reason for adding -fno-exceptions to compiling GCC is gone (though inlining is still different).
[Bug debug/51276] New: ICE: in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51276 Bug #: 51276 Summary: ICE: in force_decl_die, at dwarf2out.c:19261 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: marc.gli...@normalesup.org Created attachment 25891 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25891 Compressed preprocessed testcase An uncompressed version (7.4M) is available from: http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/b.ii $ g++ -std=c++0x -g b.ii [...] internal compiler error: in force_decl_die, at dwarf2out.c:19261 The closest bug I could find is about -fenable-icf-debug (Bug 46132) but that option has been removed. I usually reduce testcases with delta before submitting them, but g++ got into an infinite loop apparently. Maybe ulimit would help work around that...
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602 --- Comment #10 from Andi Kleen andi-gcc at firstfloor dot org 2011-11-23 00:22:46 UTC --- FWIW the problem is still there and prevents any 32bit kernel LTO builds
[Bug c++/51154] internal compiler error: gimplification failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51154 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-23 00:26:23 UTC --- Richard, can you help triaging this?
[Bug tree-optimization/51275] CLOBBERS can be optimized if they are right before the return (or RESX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-23 00:40:40 UTC --- I think this patch has a bug in it when dealing with DEBUG_STMT's.
[Bug c++/51277] New: Feature request: C++ diagnostic for ambiguous overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51277
Bug #: 51277
Summary: Feature request: C++ diagnostic for ambiguous
overloads
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
I have a feature request regarding a compiler diagnostic.
When a call of an overloaded function is ambiguous, and some of the candidates
are declared in namespaces other than the namespace of the call site (or one
of its parent namespaces), it would be helpful if the compiler helped us
figure out why those candidates are visible in the namespace of the call site.
Specifically, it would be helpful if the compiler would say:
- whether the candidate is visible 1) because it was imported into the
namespace of the call site (or one of its parent namespaces) via a
using-declaration or a using-directive, OR 2) because it was found
using argument-dependent lookup
- in the first case, the location of the using-declaration or using-
directive (if there are several, any one of them should suffice)
- in the second case, the argument that triggered the argument-
dependent lookup and why
Examples:
/// EXAMPLE 1 ///
namespace n1
{
void foo(double);
}
using n1::foo;
void foo(float);
int main()
{
foo(0);
}
// Current diagnostic
test.cpp: In function 'int main()':
test.cpp:12:9: error: call of overloaded 'foo(int)' is ambiguous
test.cpp:12:9: note: candidates are:
test.cpp:3:10: note: void n1::foo(double)
test.cpp:8:6: note: void foo(float)
// What I would like to see
test.cpp: In function 'int main()':
test.cpp:12:9: error: call of overloaded 'foo(int)' is ambiguous
test.cpp:12:9: note: candidates are:
test.cpp:3:10: note: void n1::foo(double)
test.cpp:6:13: note: visible in global namespace because of using-declaration
located here
test.cpp:8:6: note: void foo(float)
/// EXAMPLE 2 ///
namespace n1
{
struct Bar {};
void foo(double, Bar);
}
void foo(float, n1::Bar);
int main()
{
foo(n1::Bar());
}
// Current diagnostic
test.cpp: In function 'int main()':
test.cpp:12:20: error: call of overloaded 'foo(int, n1::Bar)' is ambiguous
test.cpp:12:20: note: candidates are:
test.cpp:8:6: note: void foo(float, n1::Bar)
test.cpp:5:10: note: void n1::foo(double, n1::Bar)
// What I would like to see
test.cpp: In function 'int main()':
test.cpp:12:20: error: call of overloaded 'foo(int, n1::Bar)' is ambiguous
test.cpp:12:20: note: candidates are:
test.cpp:8:6: note: void foo(float, n1::Bar)
test.cpp:5:10: note: void n1::foo(double, n1::Bar)
test.cpp:3:14: note: found by argument-dependent lookup because second argument
is of type n1::Bar
//
Does this sound doable?
[Bug tree-optimization/46309] optimization a==3||a==1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46309 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-23 00:58:23 UTC --- FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.1, 1. and -.2, 2. and -.3, 3. and -.4, 4.[ ]* into 2 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.1, 1. and -.3, 3.[ ]* into 1 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.1, 1. and -.2, 2.[ ]* into 1 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.0, 31. and -.64, 95.[ ]* into 2 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.128, 159. and -.192, 223.[ ]* into 1 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc2 Optimizing range tests D.[0-9]*_[0-9]* -.0, 31. and -.128, 159.[ ]* into 1 On mips64-linux-gnu
[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271
--- Comment #1 from vries at gcc dot gnu.org 2011-11-23 01:18:18 UTC ---
minimal compile line:
...
$ mips64el-linux-gnu-gcc -O2 -g res_hconf.c
...
minimal example res_hconf.c:
...
extern __thread int *__libc_tsd_CTYPE_B;
int *
skip_string (int *str)
{
while (*str
__libc_tsd_CTYPE_B[*str]
*str != ',')
++str;
return str;
}
...
