[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #41 from Joost VandeVondele --- (In reply to Kostya Serebryany from comment #40) > Is there anything else left in this bug? > If not, please close this one and open another for the next problem(s) I'll close it as soon as libbacktrace is used with sanitizer in trunk (see comment #12), but if Jakob feels this is covered by e.g. PR59136, this one can be closed, indeed.
[Bug lto/50351] An internal compiler error when building gcc4.6 using "-flto -fuse-linker-plugin" on Win7 mingw64 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351 --- Comment #7 from xunxun --- (In reply to Kai Tietz from comment #6) > I rechecked reported issue with current trunk-version and didn't saw this > ICE anymore. Also with newer 4.7 version I can't reproduce issue. > > Could you please retest and tell me if issue is still reproducable for you? Thanks for your test. I will test a few days, later.
[Bug tree-optimization/59058] [4.7/4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058 --- Comment #13 from Richard Biener --- Author: rguenth Date: Fri Dec 6 09:23:07 2013 New Revision: 205730 URL: http://gcc.gnu.org/viewcvs?rev=205730&root=gcc&view=rev Log: 2013-12-06 Richard Biener PR tree-optimization/59058 * tree-vectorizer.h (struct _loop_vec_info): Add num_itersm1 member. (LOOP_VINFO_NITERSM1): New macro. * tree-vect-loop-manip.c (slpeel_tree_peel_loop_to_edge): Express the vector loop entry test in terms of scalar latch executions. (vect_do_peeling_for_alignment): Update LOOP_VINFO_NITERSM1. * tree-vect-loop.c (vect_get_loop_niters): Also return the number of latch executions. (new_loop_vec_info): Initialize LOOP_VINFO_NITERSM1. (vect_analyze_loop_form): Likewise. (vect_generate_tmps_on_preheader): Compute the number of vectorized iterations differently. * gcc.dg/torture/pr59058.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59058.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317 Robert Suchanek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Robert Suchanek --- Closing. Fixed on trunk. Thanks.
[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 #8 from Dominique d'Humieres --- > ... bug was introduced by r202567 ... I have checked that and fixing it with r205586 restores the timing of r202566. The reason why this is not seen on recent revisions is r203167 which introduces yet another parameter 'builtin-expect-probability' with a default value 90. Setting this parameter to 92 allows the run time for fatigue2 to go from 78.2s to 29.1s (26.6s with r202566). It does not look reasonable to control the inlining with at least three parameters: 'large-function-growth', 'max-inline-insns-auto', and 'builtin-expect-probability'. In top of that their documentation is scarce.
[Bug c++/59403] [4.8.2] Segmentation fault in crash_signal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59403 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Are you using precompiled headers?
[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 janus at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.4, 4.8.1 Summary|[OOP] ICE in|[4.7/4.9 Regression] [OOP] |free_pi_tree(): Unresolved |ICE in free_pi_tree(): |fixup - resolve_fixups does |Unresolved fixup - |not fixup component of |resolve_fixups does not |__class_bsr_Bsr_matrix |fixup component of ||__class_bsr_Bsr_matrix Known to fail||4.7.3, 4.9.0 --- Comment #10 from janus at gcc dot gnu.org --- Marking this one as a regression, since comment 6 seems to fail only with 4.7 and trunk.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #7 from Richard Biener --- (In reply to David Kredba from comment #6) > I "reduced" it to this: > > /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -pipe -march=native > -mtune=native -flto=4 -fuse-linker-plugin -Wnon-virtual-dtor -Wno-long-long > -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith > -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new > -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden > -fvisibility-inlines-hidden -Wl,--enable-new-dtags -Wl,--no-undefined -lc > -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb > -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -shared > -Wl,-soname,kigpart.so -o lib/kigpart.so > CMakeFiles/kigpart.dir/scripting/python_scripter.o -L/usr/lib64/qt4 > /usr/lib64/libkparts.so.4.11.4 /usr/lib64/libkutils.so.4.11.4 -lpython2.7 > /usr/lib64/libboost_python-2.7-mt.so /usr/lib64/libktexteditor.so.4.11.4 > /usr/lib64/libkemoticons.so.4.11.4 /usr/lib64/libkidletime.so.4.11.4 > /usr/lib64/libkcmutils.so.4.11.4 /usr/lib64/libkprintutils.so.4.11.4 > /usr/lib64/libkparts.so.4.11.4 /usr/lib64/libkio.so.5.11.4 > /usr/lib64/qt4/libQtNetwork.so /usr/lib64/qt4/libQtXml.so > /usr/lib64/libnepomukutils.so.4.11.4 /usr/lib64/libnepomuk.so.4.11.4 > /usr/lib64/libkdeui.so.5.11.4 /usr/lib64/qt4/libQtGui.so > /usr/lib64/qt4/libQtSvg.so -lsoprano /usr/lib64/libkdecore.so.5.11.4 > /usr/lib64/qt4/libQtCore.so -lpthread /usr/lib64/qt4/libQtDBus.so > -Wl,-rpath,/usr/lib64/qt4: -nostdlib > lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706 > > All othe object files removed not let the ICE away. When python_scripter.o > removed and other object files present on link command it did this: Good, if you now remove the -Wl,--no-undefined switch you should be able to remove all shared library inputs as well (fingers crossing). For the remaining object file inputs (AFAIK only python_scripter.o?) please attach preprocessed source from the compile-stage. The bug should then be reproducible by exchanging python_scripter.o for python_scripter.ii on the command-line and thus make the bug reproducible with just that file. Thanks, Richard.
[Bug fortran/59395] [4.8 Regression] internal compiler error (memory access error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.3
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #73 from Oleg Endo --- Author: olegendo Date: Fri Dec 6 10:46:53 2013 New Revision: 205734 URL: http://gcc.gnu.org/viewcvs?rev=205734&root=gcc&view=rev Log: PR target/51244 PR target/59343 * config/sh/sh.md (*cbranch_t): Check that there are no labels between the s1 insn and the testing insn. Remove REG_DEAD notefrom s1 insn. PR target/51244 PR target/59343 * gcc.target/sh/pr51244-19.c: Adjust test case. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sh.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/sh/pr51244-19.c
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 --- Comment #9 from Oleg Endo --- Author: olegendo Date: Fri Dec 6 10:46:53 2013 New Revision: 205734 URL: http://gcc.gnu.org/viewcvs?rev=205734&root=gcc&view=rev Log: PR target/51244 PR target/59343 * config/sh/sh.md (*cbranch_t): Check that there are no labels between the s1 insn and the testing insn. Remove REG_DEAD notefrom s1 insn. PR target/51244 PR target/59343 * gcc.target/sh/pr51244-19.c: Adjust test case. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sh.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/sh/pr51244-19.c
[Bug target/59405] New: Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 Bug ID: 59405 Summary: Incorrect FP<->MMX transition during call/ret Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kirill.yukhin at intel dot com Hello, Attached test reproduces the error: $ gcc -m32 -mmmx 1.c $ ./a.out Aborted (core dumped) Disassembly of the foo is: foo32x2_be: .LFB0: pushl %ebp# 22*pushsi2[length = 1] movl%esp, %ebp # 23*movsi_internal/1 [length = 2] subl$16, %esp # 24pro_epilogue_adjust_stack_si_add/1 [length = 3] movq%mm0, -8(%ebp) # 3 *movv2sf_internal/9 [length = 4] movl-4(%ebp), %eax # 7 *movsf_internal/4 [length = 3] movl%eax, -12(%ebp) # 14*movsf_internal/5 [length = 3] flds-12(%ebp) # 21*movsf_internal/1 [length = 3] leave # 27leave [length = 1] ret # 28simple_return_internal [length = 1] We're passing v2sf vector using MMX register, which aliased to x87 stack. Then we're trying to load FP to it, which leds to NaN. As far as I understand, we need `emms' instruction between last MMX use and before first x87 use. Reproduces everywhere, up to 4.7.2 (may be earlier, I have no such).
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #1 from Uroš Bizjak --- There is no testcase attached, but you need to *manually* insert _mm_empty (== emms) to switch from MMX to x87 state. The compiler does not automatically insert emms for you.
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #4 from Alexander Ivchenko --- This broke Android image build with trunk compiler (in addition to pr58585)..
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #2 from Yukhin Kirill --- Created attachment 31389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31389&action=edit Testcase
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #3 from Yukhin Kirill --- (In reply to Uroš Bizjak from comment #1) > There is no testcase attached, but you need to *manually* insert _mm_empty > (== emms) to switch from MMX to x87 state. > > The compiler does not automatically insert emms for you. Well, then problem is different, test as simple as empty call. I doubt we should emit wrong code here.
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 Joost VandeVondele changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Joost VandeVondele --- (In reply to Kostya Serebryany from comment #11) > planing next merge from llvm to gcc in ~1 week. Fixed in current trunk. Thanks!
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 --- Comment #5 from Markus Trippelsdorf --- (In reply to Alexander Ivchenko from comment #4) > This broke Android image build with trunk compiler (in addition to pr58585).. Yes. Many C++ projects that use multiple inheritance don't compile ATM: Chromium, KDE, etc.
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #4 from Uroš Bizjak ---
(In reply to Yukhin Kirill from comment #3)
> (In reply to Uroš Bizjak from comment #1)
> > There is no testcase attached, but you need to *manually* insert _mm_empty
> > (== emms) to switch from MMX to x87 state.
> >
> > The compiler does not automatically insert emms for you.
>
> Well, then problem is different, test as simple as empty call.
> I doubt we should emit wrong code here.
You need:
float
foo32x2_be (float32x2_t x)
{
__builtin_ia32_emms();
return x[1];
}
This is documented somewhere in Intel's ISA manual, so the testcase is probably
invalid.
[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-06 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to Kostya Serebryany from comment #1) > Thanks for the report, H.J. I'll try to respond properly on Monday (-ish). Can I check my patches into trunk to unblock x32 build and revert them after we find a better fix? > Long term, everyone would benefit if you could setup a public build bot > upstream. Can you find a machine with Ubuntu 13.04 or newer?
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #9 from Markus Trippelsdorf --- Jason, can you address Honza's questions from comment 8 please? This issue breaks many C++ projects and makes testing impossible.
[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 --- Comment #3 from Kostya Serebryany --- (In reply to H.J. Lu from comment #2) > (In reply to Kostya Serebryany from comment #1) > > Thanks for the report, H.J. I'll try to respond properly on Monday (-ish). > > Can I check my patches into trunk to unblock x32 build and revert them > after we find a better fix? You may, assuming other targets will not break. But I will not be able to do another merge until the two versions (upstream and GCC) are equivalent again. So, please don't close this bug until it's done. > > > Long term, everyone would benefit if you could setup a public build bot > > upstream. > > Can you find a machine with Ubuntu 13.04 or newer? No, sorry.
[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 #17 from Eric Botcazou ---
Author: ebotcazou
Date: Fri Dec 6 11:31:56 2013
New Revision: 205735
URL: http://gcc.gnu.org/viewcvs?rev=205735&root=gcc&view=rev
Log:
PR target/59316
* config/sparc/sparc.h (SPARC_LOW_FE_EXCEPT_VALUES): Define.
* config/sparc/sol2.h (SPARC_LOW_FE_EXCEPT_VALUES): Redefine.
* config/sparc/sparc.c (TARGET_INIT_BUILTINS): Move around.
(TARGET_BUILTIN_DECL): Define.
(TARGET_ATOMIC_ASSIGN_EXPAND_FENV): Likewise.
(sparc32_initialize_trampoline): Adjust call to gen_flush.
(enum sparc_builtins): New enumeral type.
(sparc_builtins): New static array.
(sparc_builtins_icode): Likewise.
(def_builtin): Accept a separate icode and save the result.
(def_builtin_const): Likewise.
(sparc_fpu_init_builtins): New function.
(sparc_vis_init_builtins): Pass the builtin code.
(sparc_init_builtins): Call it if TARGET_FPU.
(sparc_builtin_decl): New function.
(sparc_expand_builtin): Deal with SPARC_BUILTIN_{LD,ST}FSR.
(sparc_handle_vis_mul8x16): Use the builtin code.
(sparc_fold_builtin): Likewise. Deal with SPARC_BUILTIN_{LD,ST}FSR
and SPARC_BUILTIN_PDISTN.
(compound_expr): New helper function.
(sparc_atomic_assign_expand_fenv): New function.
* config/sparc/sparc.md (unspecv): Reorder values, add UNSPECV_LDFSR
and UNSPECV_STFSR.
(flush, flushdi): Merge into single pattern.
(ldfsr): New instruction.
(stfsr): Likewise.
Added:
trunk/gcc/testsuite/gcc.target/sparc/pdistn-2.c
trunk/gcc/testsuite/gcc.target/sparc/pdistn.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sol2.h
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/sparc/sparc.h
trunk/gcc/config/sparc/sparc.md
trunk/gcc/testsuite/ChangeLog
[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 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Eric Botcazou --- This should pass now.
[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 --- Comment #4 from H.J. Lu --- (In reply to Kostya Serebryany from comment #3) > (In reply to H.J. Lu from comment #2) > > (In reply to Kostya Serebryany from comment #1) > > > Thanks for the report, H.J. I'll try to respond properly on Monday (-ish). > > > > Can I check my patches into trunk to unblock x32 build and revert them > > after we find a better fix? > > You may, assuming other targets will not break. I will check in my patches. Since my patch is guarded with #if defined(__x86_64__) and #if defined(__x86_64__) && !defined(_LP64) they shouldn't break other targets. > But I will not be able to do another merge until the two versions > (upstream and GCC) are equivalent again. You can revert my patches before merging or apply my patches to llvm first. In any case, please don't break x32 before the merge. You can send me a patch before doing the merge. I can test it on x32. > So, please don't close this bug until it's done. > > > > > > > Long term, everyone would benefit if you could setup a public build bot > > > upstream. > > > > Can you find a machine with Ubuntu 13.04 or newer? You can try virtual machine. You only need to build GCC with C and C++ without bootstrap. Stage 1 build is sufficient. It shouldn't take more than a hour on a fast host. Thanks.
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #5 from Yukhin Kirill --- I see. So, it seems like a limitation to passing vectors as arguments in 32-bit mode. We may implement something similar to `vzerroupper' autogeneration or simply close the bug as `user misunderstanding.'
[Bug libstdc++/59406] New: functions labelled FNV-1a in tr1/functional_hash.h are not FNV-1a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
Bug ID: 59406
Summary: functions labelled FNV-1a in tr1/functional_hash.h are
not FNV-1a
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: g1pi at libero dot it
Created attachment 31390
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31390&action=edit
preprocessed program
As far as I know, the FNV and FNV-1a algorithms process octects, i.e. unsigned
chars. (see e.g. http://tools.ietf.org/html/draft-eastlake-fnv-03#section-2 )
The implementations in tr1/functional_hash.h work
on chars, instead, and their output is wrong (in architectures where char is
signed) when the input byte sequence includes bytes with the MSB set.
For example
std::tr1::_Fnv_hash_base<4>::hash("\x80", 1)
returns 83079839, instead of the correct value 2232128415.
The problem resides in the type cast:
template<>
struct _Fnv_hash_base<4>
{
template
static size_t
hash(const _Tp* __ptr, size_t __clength)
{
size_t __result = static_cast(2166136261UL);
>>> const char* __cptr = reinterpret_cast(__ptr);<<<
for (; __clength; --__clength)
{
__result ^= static_cast(*__cptr++);
__result *= static_cast(16777619UL);
}
return __result;
}
};
The highlighed line should read:
const unsigned char* __cptr = reinterpret_cast(__ptr);
Since the FNV primes were carefully chosen in order to minimize
collision rates and maximize dispersion, there might be consequences in
the performance of data structures that build on tr1::hash template,
perhaps tr1::unordered_map and tr1::unordered_set.
Here is a short program exposing the bug:
#include
#include
int main()
{
std::cout << std::tr1::_Fnv_hash_base<4>::hash("\x80", 1)
<< " computed, 2232128415 expected\n";
}
and here is the output of g++ -v ...:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --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.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
COLLECT_GCC_OPTIONS='-O' '-Wextra' '-Wall' '-ansi' '-pedantic' '-v'
'-save-temps' '-fno-strict-aliasing' '-fwrapv' '-shared-libgcc'
'-mtune=generic' '-march=i586'
/usr/lib/gcc/i486-linux-gnu/4.7/cc1plus -E -quiet -v -imultiarch
i386-linux-gnu -D_GNU_SOURCE fnv-bad.cc -mtune=generic -march=i586 -ansi
-Wextra -Wall -pedantic -fno-strict-aliasing -fwrapv -O -fpch-preprocess -o
fnv-bad.ii
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.7/../../../../i486-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.7
/usr/include/c++/4.7/i486-linux-gnu
/usr/include/c++/4.7/backward
/usr/lib/gcc/i486-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.7/include-fixed
/usr/include/i386-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O' '-Wextra' '-Wall' '-ansi' '-pedantic' '-v'
'-save-temps' '-fno-strict-aliasing' '-fwrapv' '-shared-libgcc'
'-mtune=generic' '-march=i586'
/usr/lib/gcc/i486-linux-gnu/4.7/cc1plus -fpreprocessed fnv-bad.ii -quiet
-dumpbase fnv-bad.cc -mtune=generic -march=i586 -auxbase fnv-bad -O -Wextra
-Wall -pedantic -ansi -version -fno-strict-aliasing -fwrapv -o fnv-bad.s
GNU C++ (Debian 4.7.2-5) version 4.7.2 (i486-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version
3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62264
GNU C++ (Debian 4.7.2-5) version 4.7.2 (i486-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version
3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62264
Compiler executable checksum: 62bfd556e00a93e3d7f66f6876d73826
COLLECT_GCC_OPTIONS='-O' '-Wextra' '-Wall' '-ansi' '-pedantic' '-v'
'-save-temps' '-fno-strict-aliasing' '-fwrapv' '-shared-libgcc'
'-mtune=generic' '-march=i586'
as -v --
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #6 from H.J. Lu --- I think this is a dup of PR48397.
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359 --- Comment #12 from Anatoly Sinyavin --- Does it mean that my solution is not accepted? If it's so I am going to think about two approaches - vectorizer should ignore that path (Richard Biener 2013-09-09 08:22:53 UTC) - replacing the GIMPLE_COND, leading to a block that contains only a call to __builtin_unreachable, with an ASSERT_EXPR, or range information on this SSA_NAME (now that we store it), or anything without control flow (Marc Glisse 2013-10-24 12:03:18 UTC)
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #7 from Uroš Bizjak --- (In reply to H.J. Lu from comment #6) > I think this is a dup of PR48397. No, this one happens due to missing interdependencies between x87 and MMX registers. We could make all MMX instructions dependant on st(0) register, but this would mean that no MMX instruction whatsoever will be reordered.
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #8 from Uroš Bizjak --- (In reply to Yukhin Kirill from comment #5) > I see. So, it seems like a limitation to passing vectors as arguments in > 32-bit mode. We may implement something similar to `vzerroupper' > autogeneration or simply close the bug as `user misunderstanding.' We already tried this. Please see PR19161. There is however, one problem - gcc warns about SSE vector argument without SSE on 32bit targets. I will fix type_natural_mode.
[Bug tree-optimization/59164] [4.7/4.8 Regression] ice: tree check: expected tree that contains ‘decl minimal’ structure, have ‘integer_cst’ in get_var_info, at tree-into-ssa.c:380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59164 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Dec 6 12:39:32 2013 New Revision: 205739 URL: http://gcc.gnu.org/viewcvs?rev=205739&root=gcc&view=rev Log: 2013-12-06 Richard Biener Backport from mainline 2013-11-27 Richard Biener PR tree-optimization/59288 * tree-vect-loop.c (get_initial_def_for_induction): Do not re-analyze the PHI but use STMT_VINFO_LOOP_PHI_EVOLUTION_PART. * gcc.dg/torture/pr59288.c: New testcase. 2013-11-19 Richard Biener PR tree-optimization/59164 * tree-vect-loop.c (vect_analyze_loop_operations): Adjust check whether we can create an epilogue loop to reflect the cases where we create one. * gcc.dg/torture/pr59164.c: New testcase. 2013-09-05 Richard Biener PR tree-optimization/58137 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Do not create vectors of pointers. * tree-vect-loop.c (get_initial_def_for_induction): Use proper types for the components of the vector initializer. * tree-cfg.c (verify_gimple_assign_binary): Remove special-casing allowing pointer vectors with PLUS_EXPR/MINUS_EXPR. * gcc.target/i386/pr58137.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59164.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59288.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr58137.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-cfg.c branches/gcc-4_8-branch/gcc/tree-vect-loop.c branches/gcc-4_8-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/58137] [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Dec 6 12:39:32 2013 New Revision: 205739 URL: http://gcc.gnu.org/viewcvs?rev=205739&root=gcc&view=rev Log: 2013-12-06 Richard Biener Backport from mainline 2013-11-27 Richard Biener PR tree-optimization/59288 * tree-vect-loop.c (get_initial_def_for_induction): Do not re-analyze the PHI but use STMT_VINFO_LOOP_PHI_EVOLUTION_PART. * gcc.dg/torture/pr59288.c: New testcase. 2013-11-19 Richard Biener PR tree-optimization/59164 * tree-vect-loop.c (vect_analyze_loop_operations): Adjust check whether we can create an epilogue loop to reflect the cases where we create one. * gcc.dg/torture/pr59164.c: New testcase. 2013-09-05 Richard Biener PR tree-optimization/58137 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Do not create vectors of pointers. * tree-vect-loop.c (get_initial_def_for_induction): Use proper types for the components of the vector initializer. * tree-cfg.c (verify_gimple_assign_binary): Remove special-casing allowing pointer vectors with PLUS_EXPR/MINUS_EXPR. * gcc.target/i386/pr58137.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59164.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59288.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr58137.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-cfg.c branches/gcc-4_8-branch/gcc/tree-vect-loop.c branches/gcc-4_8-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/59288] [4.7/4.8 Regression] ICE in get_initial_def_for_induction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Dec 6 12:39:32 2013 New Revision: 205739 URL: http://gcc.gnu.org/viewcvs?rev=205739&root=gcc&view=rev Log: 2013-12-06 Richard Biener Backport from mainline 2013-11-27 Richard Biener PR tree-optimization/59288 * tree-vect-loop.c (get_initial_def_for_induction): Do not re-analyze the PHI but use STMT_VINFO_LOOP_PHI_EVOLUTION_PART. * gcc.dg/torture/pr59288.c: New testcase. 2013-11-19 Richard Biener PR tree-optimization/59164 * tree-vect-loop.c (vect_analyze_loop_operations): Adjust check whether we can create an epilogue loop to reflect the cases where we create one. * gcc.dg/torture/pr59164.c: New testcase. 2013-09-05 Richard Biener PR tree-optimization/58137 * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Do not create vectors of pointers. * tree-vect-loop.c (get_initial_def_for_induction): Use proper types for the components of the vector initializer. * tree-cfg.c (verify_gimple_assign_binary): Remove special-casing allowing pointer vectors with PLUS_EXPR/MINUS_EXPR. * gcc.target/i386/pr58137.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59164.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59288.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr58137.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-cfg.c branches/gcc-4_8-branch/gcc/tree-vect-loop.c branches/gcc-4_8-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/58137] [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.3
[Bug tree-optimization/59058] [4.7/4.8 Regression] wrong code at -O3 on x86_64-linux-gnu (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058 Richard Biener changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] wrong |wrong code at -O3 on|code at -O3 on |x86_64-linux-gnu (affecting |x86_64-linux-gnu (affecting |gcc 4.6 to trunk) |gcc 4.6 to trunk) --- Comment #14 from Richard Biener --- Fixed on trunk sofar.
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Oleg Endo --- (In reply to Oleg Endo from comment #9) > Author: olegendo > Date: Fri Dec 6 10:46:53 2013 > New Revision: 205734 > > URL: http://gcc.gnu.org/viewcvs?rev=205734&root=gcc&view=rev > Log: > PR target/51244 > PR target/59343 > * config/sh/sh.md (*cbranch_t): Check that there are no labels between > the s1 insn and the testing insn. Remove REG_DEAD note from s1 insn. > > PR target/51244 > PR target/59343 > * gcc.target/sh/pr51244-19.c: Adjust test case. > > > Modified: > branches/gcc-4_8-branch/gcc/ChangeLog > branches/gcc-4_8-branch/gcc/config/sh/sh.md > branches/gcc-4_8-branch/gcc/testsuite/ChangeLog > branches/gcc-4_8-branch/gcc/testsuite/gcc.target/sh/pr51244-19.c Should be fixed on 4.8 now, too. If there are any further issues regarding T bit optimizations please drop a comment in PR 51244.
[Bug libstdc++/59406] functions labelled FNV-1a in tr1/functional_hash.h are not FNV-1a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406 --- Comment #1 from Jonathan Wakely --- We're not really making any non-critical changes to TR1 code now.
[Bug target/38134] [4.7/4.8/4.9 Regression] speed regression with many loop invariants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #23 from Richard Biener --- No longer working on this. Best hint sofar: fix postreload-gcse
[Bug target/58017] [SH] Use shift and test for unsigned compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58017 --- Comment #1 from Oleg Endo --- (In reply to Oleg Endo from comment #0) > > especially if the compared reg is dead after the comparison. ... and the constant is not shared with any other insn and the comparison is not in a (tight) loop. if such comparisons are found in loops, the constant load should be hoisted.
[Bug target/59407] gcc.target/i386/pr58218.c FAILs with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59407 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/59407] New: gcc.target/i386/pr58218.c FAILs with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59407 Bug ID: 59407 Summary: gcc.target/i386/pr58218.c FAILs with Sun as Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ubizjak at gmail dot com Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] The new gcc.target/i386/pr58218.c testcase FAILs on Solaris 10 and 11/x86 with Sun as: FAIL: gcc.target/i386/pr58218.c (test for excess errors) Excess errors: Assembler: pr58218.c "/var/tmp//cciHFIO7.s", line 3 : Section attributes do not match as chokes on .section.lbss,"aw",@nobits It turns out that as needs an explicit 'h' (for huge or large) flag here to set SHF_AMD64_LARGE. gas doesn't need that (sets SHF_AMD64_LARGE implicitly for the .l* sections prescribed by the AMD64 ABI to have that), but accepts an 'l' flag with the same semantics as 'h' here. Will look into how to get this into gcc. Rainer
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #7 from Kai Tietz --- duh. Yes, of course the '0 -' is wrong. We want to address backward. Does the patch with this change fixes your issue?
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #75 from Richard Biener --- On trunk with the reduced testcase and -O2 (no -g): ipa inlining heuristics : 9.85 ( 5%) usr 0.00 ( 0%) sys 9.93 ( 5%) wall 1448 kB ( 0%) ggc tree PTA: 161.26 (78%) usr 0.30 (45%) sys 162.00 (78%) wall 42484 kB ( 8%) ggc expand vars : 3.06 ( 1%) usr 0.01 ( 2%) sys 3.06 ( 1%) wall 16074 kB ( 3%) ggc integrated RA : 4.46 ( 2%) usr 0.11 (17%) sys 4.56 ( 2%) wall 87144 kB (17%) ggc TOTAL : 205.49 0.66 206.80 513245 kB -O3 is in the same ballpark. I'll look at this again.
[Bug go/59408] New: [4.9 regression] Many Go tests FAIL with notesleep not on g0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408 Bug ID: 59408 Summary: [4.9 regression] Many Go tests FAIL with notesleep not on g0 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* Between 20131104 and 20131114, many Go tests (both in gcc/testsuite/go.* and libgo) started to FAIL like fatal error: notesleep not on g0 goroutine 35 [running]: :0 :0 :0 :0 :0 :0 :0 net.TestMutexStress /var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libgo/gotest24280/test/fd_mutex_test.go:186 :0 :0 :0 goroutine 1 [chan receive]: main.main /var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libgo/gotest24280/test/_testmain.go:167 goroutine 38 [runnable]: net.$nested23 /var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libgo/gotest24280/test/fd_mutex_test.go:174 created by net.TestMutexStress /var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libgo/gotest24280/test/fd_mutex_test.go:135 FAIL: net This happens both for 32-bit and 64-bit tests, SPARC and x86, and constitues a regression from 4.8 where at least the 32-bit Go tests almost all PASSed on Solaris. Rainer
[Bug go/59408] [4.9 regression] Many Go tests FAIL with notesleep not on g0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59334] [4.9 Regression] r205486 caused many failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri Dec 6 14:14:34 2013 New Revision: 205741 URL: http://gcc.gnu.org/viewcvs?rev=205741&root=gcc&view=rev Log: 2013-12-06 Richard Biener Backport from mainline 2013-11-29 Richard Biener PR tree-optimization/59334 * tree-ssa-dce.c (eliminate_unnecessary_stmts): Fix bug in previous commit. 2013-11-28 Richard Biener PR tree-optimization/59330 * tree-ssa-dce.c (eliminate_unnecessary_stmts): Simplify and fix delayed marking of free calls not necessary. * gcc.dg/torture/pr59330.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59330.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-dce.c
[Bug middle-end/59330] [4.7/4.8 Regression] Crash in is_gimple_reg_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59330 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri Dec 6 14:14:34 2013 New Revision: 205741 URL: http://gcc.gnu.org/viewcvs?rev=205741&root=gcc&view=rev Log: 2013-12-06 Richard Biener Backport from mainline 2013-11-29 Richard Biener PR tree-optimization/59334 * tree-ssa-dce.c (eliminate_unnecessary_stmts): Fix bug in previous commit. 2013-11-28 Richard Biener PR tree-optimization/59330 * tree-ssa-dce.c (eliminate_unnecessary_stmts): Simplify and fix delayed marking of free calls not necessary. * gcc.dg/torture/pr59330.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59330.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-dce.c
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #76 from Richard Biener ---
There are a lot of calls with fnspec, almost all constraints look like
D.12770.0+16 = allalltmp
D.12770.64+128 = allalltmp
D.12770.192+64 = allalltmp
callarg = &READONLY
callarg = *callarg
callarg = callarg + UNKNOWN
CALLUSED = callarg
ESCAPED = &NONLOCAL
allalltmp = CALLUSED
allalltmp = NONLOCAL
D.12771.0+16 = allalltmp
D.12771.64+128 = allalltmp
D.12771.192+64 = allalltmp
callarg = &D.12770.0+16
callarg = *callarg
callarg = callarg + UNKNOWN
They get unified pretty quickly though.
Still we end up with many very large sets that include ESCAPED but also some
members of ESCAPED explicitely (that's redundant). I have some idea on how
to mitigate this which eventually should speed things up (or at least reduce
memory usage).
Like
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 205739)
+++ tree-ssa-structalias.c (working copy)
@@ -1600,6 +1600,14 @@ do_sd_constraint (constraint_graph_t gra
goto done;
}
+ /* If the solution of Y contains escaped then filter all bits from
+ that from the delta to reduce work. */
+ if (bitmap_bit_p (delta, escaped_id))
+{
+ bitmap_and_compl_into (delta, get_varinfo (find
(escaped_id))->solution);
+ flag |= bitmap_set_bit (sol, escaped_id);
+}
+
/* If we do not know at with offset the rhs is dereferenced compute
the reachability set of DELTA, conservatively assuming it is
dereferenced at all valid offsets. */
will check next week.
[Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 Bug ID: 59409 Summary: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On x32, r205737 gave Running 253.perlbmk ref peak lto default *** Miscompare of 850.5.19.18.1500.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x32/spec/benchspec/CINT2000/253.perlbmk/run/0004/850.5.19.18.1500.out.mis *** Miscompare of 957.12.23.26.1014.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x32/spec/benchspec/CINT2000/253.perlbmk/run/0004/957.12.23.26.1014.out.mis *** Miscompare of 2.550.15.24.23.100.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x32/spec/benchspec/CINT2000/253.perlbmk/run/0004/2.550.15.24.23.100.out.mis *** Miscompare of 704.12.26.16.836.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x32/spec/benchspec/CINT2000/253.perlbmk/run/0004/704.12.26.16.836.out.mis *** Miscompare of b.3.m.4.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x32/spec/benchspec/CINT2000/253.perlbmk/run/0004/b.3.m.4.out.mis *** Miscompare of 535.13.25.24.1091.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x32/spec/benchspec/CINT2000/253.perlbmk/run/0004/535.13.25.24.1091.out.mis It is compiled with -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin r205651 is OK.
[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 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #9 from Jan Hubicka --- I will look into it...
[Bug c++/58477] [4.9 Regression] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477
--- Comment #5 from Jan Hubicka ---
I am testing
Index: ../gcc/cgraphclones.c
===
--- ../gcc/cgraphclones.c (revision 205737)
+++ ../gcc/cgraphclones.c (working copy)
@@ -123,7 +123,10 @@ cgraph_clone_edge (struct cgraph_edge *e
{
tree decl;
- if (call_stmt && (decl = gimple_call_fndecl (call_stmt)))
+ if (call_stmt && (decl = gimple_call_fndecl (call_stmt))
+ /* When the call is speculative, we need to resolve it
+via cgraph_resolve_speculation and not here. */
+ && !e->speculative)
{
struct cgraph_node *callee = cgraph_get_node (decl);
gcc_checking_assert (callee);
The problem is that cgraph_clone_edge is too eager to turn the edge into a
direct edge because inliner managed to do the same resolution.
This fixes the ICE but we however ought to do this optimization at IPA level.
[Bug libstdc++/59406] functions labelled FNV-1a in tr1/functional_hash.h are not FNV-1a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
--- Comment #2 from g1pi at libero dot it ---
(In reply to Jonathan Wakely from comment #1)
> We're not really making any non-critical changes to TR1 code now.
Yet std::_Fnv_hash_bytes in non-TR1 code has the same problem (lines 116 and
161 of svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/libsupc++/hash_bytes.cc at
revision 205748). The following program emits 83079839 instead of the expected
FNV-1a result.
#include
#include
int main() {
std::cout << std::_Fnv_hash_bytes("\x80", 1, 2166136261UL) << '\n';
}
Don't know if those functions are used somewhere or are leftovers. The
comments in the file suggest that Murmur hash is used in the std::hash template
instead of FNV-1a.
[Bug target/59091] __builtin_trap calls abort for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59091 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ramana Radhakrishnan --- Fixed by Author: ibolton Date: Fri Dec 6 15:51:49 2013 New Revision: 205749 URL: http://gcc.gnu.org/viewcvs?rev=205749&root=gcc&view=rev Log: [ARM] Add __builtin_trap support for A32 Added: trunk/gcc/testsuite/gcc.target/arm/builtin-trap.c trunk/gcc/testsuite/gcc.target/arm/thumb-builtin-trap.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/types.md trunk/gcc/testsuite/ChangeLog
[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 #10 from Jan Hubicka --- OK, seems that the problem is with Fortran generating internally __builtin_expect to control various construct. I would make a lot more sense to use GIMPLE_PREDICT for those cases. With GIMPLE_PREDICT one can have more fine grained control over the hint and handle it as separate predicter. I wonder if some Fortran maintainer can look into this and update the lowering? c/c-typeck.c:add_stmt (build_predict_expr (PRED_CONTINUE, NOT_TAKEN)); cp/cp-gimplify.c: tree pred = build_predict_expr (PRED_CONTINUE, NOT_TAKEN); are examples how these are used. Unlike builtin_expect you do not add it into the expression, but you drop it on the unlikely code path. Honza
[Bug sanitizer/59410] New: Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Bug ID: 59410 Summary: Some tsan tests fail with 4GB RAM Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com 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 On a Linux/x86-64 machine with 4GB RAM, I got failures like: FAIL: c-c++-common/tsan/atomic_stack.c -O0 output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -O1 output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -O2 output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -O3 -fomit-frame-pointer output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -O3 -g output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -Os output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/atomic_stack.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/fd_pipe_race.c -O0 output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/fd_pipe_race.c -O1 output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FAIL: c-c++-common/tsan/fd_pipe_race.c -O2 output pattern test, is FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) I didn't get those on machines with >= 6GB RAM.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #1 from Jakub Jelinek --- BTW, the tsan.exp tests don't seem to be as cheap as was claimed during the patch submission, I'd prefer to at least throttle the torture options down to say -O0 and -O2 rather than so many different variants when the tests are really small and optimizations don't really affect them that much if at all.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #2 from Dmitry Vyukov --- It seems that this kernel has ASLR disabled, so kernel maps libraries at 0x55. Tsan does not support this ATM.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #3 from Kostya Serebryany --- (In reply to H.J. Lu from comment #0) > On a Linux/x86-64 machine with 4GB RAM, I got failures like: > > FAIL: c-c++-common/tsan/atomic_stack.c -O0 output pattern test, is FATAL: > ThreadSanitizer can not mmap the shadow memory (something is mapped at > 0x4000 < 0x7cf0) This warning is not about physical RAM, but about virtual RAM. This systems is not compatible with the tsan's shadow mapping. Can you show the /proc/self/maps of the process before it dies (just put a breakpoint on __tsan_init)? I assume that asan tests pass on this machine and you don't have strict rlimit on virtual memory.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #4 from Kostya Serebryany --- (In reply to Dmitry Vyukov from comment #2) > It seems that this kernel has ASLR disabled, so kernel maps libraries at > 0x55. Tsan does not support this ATM. BTW, the situation with tsan's shadow became worse after http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a3defbe5c337dbc6da911f8cc49ae3cc3b49b453 where I see "Based on original patch by H.J. Lu and Josh Boyer."
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #5 from Jakub Jelinek --- Have any attempt for saner tsan shadow memory mapping be done in the last year? I mean, there were some PRs or mailing list threads about it being worth to support also non-PIE executables etc., understandably it didn't happen for GCC 4.8, because there wasn't enough time for it, but do we have to live with that limitation forever?
[Bug fortran/59411] New: Problem with TYPE(C_PTR) constant initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411 Bug ID: 59411 Summary: Problem with TYPE(C_PTR) constant initialization Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Hi all, the attached code does not compile: gfortran -c cst.f90 cst.f90:6.31: type(c_ptr), parameter :: p2 = pp 1 Error: non-constant initialization expression at (1) However, as far as I can tell, the code is correct (ifort accepts it). gfortran --version GNU Fortran (GCC) 4.9.0 20130813 (experimental) module m use iso_c_binding implicit none type(c_ptr), parameter :: pp = c_null_ptr ! this works type(c_ptr), parameter :: p2 = pp ! this doesn't work end module m
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-06 Ever confirmed|0 |1 --- Comment #6 from H.J. Lu --- I got those failures on this machine: [hjl@gnu-ivb-1 ~]$ cat /proc/sys/kernel/randomize_va_space 0 [hjl@gnu-ivb-1 ~]$ free total used free sharedbuffers cached Mem: 392691626490841277832 0 259482142616 -/+ buffers/cache: 4805203446396 Swap: 25165820 35648 25130172 [hjl@gnu-32 ~]$ uname -a Linux gnu-32.sc.intel.com 3.11.10-200.fc19.x86_64 #1 SMP Sun Dec 1 07:47:10 PST 2013 x86_64 x86_64 x86_64 GNU/Linux [hjl@gnu-ivb-1 ~]$ They are OK on [hjl@gnu-32 ~]$ cat /proc/sys/kernel/randomize_va_space 0 [hjl@gnu-32 ~]$ free total used free sharedbuffers cached Mem: 610262442434681859156 0 4807282897048 -/+ buffers/cache: 8656925236932 Swap: 14335996 35768 14300228 [hjl@gnu-32 ~]$ uname -a Linux gnu-32.sc.intel.com 3.11.10-200.fc19.x86_64 #1 SMP Sun Dec 1 07:47:10 PST 2013 x86_64 x86_64 x86_64 GNU/Linux [hjl@gnu-32 ~]$ The only difference is 4GB RAM vs 6GB RAM.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #7 from H.J. Lu --- On failed machine: [hjl@gnu-ivb-1 ~]$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30583 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 4096 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30583 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited [hjl@gnu-ivb-1 ~]$ On working machine: [hjl@gnu-32 ~]$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47571 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 4096 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 47571 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited [hjl@gnu-32 ~]$
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Kostya Serebryany changed: What|Removed |Added Status|NEW |UNCONFIRMED Last reconfirmed|2013-12-06 00:00:00 | Ever confirmed|1 |0 --- Comment #8 from Kostya Serebryany --- (In reply to Jakub Jelinek from comment #5) > Have any attempt for saner tsan shadow memory mapping be done in the last > year? Nope. We don't want to add extra complexity w/o a strong reason; so far we did not see such reason. (If you want to continue discussing it, please let's not hijack this bug report)
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #9 from Kostya Serebryany --- (In reply to H.J. Lu from comment #6) > I got those failures on this machine: Admittedly, I never ran tsan tests on a 4Gb machine. Does clang's tsan also fail there? Can you show /proc/self/maps of the failing process?
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #10 from H.J. Lu --- (In reply to Kostya Serebryany from comment #3) > (In reply to H.J. Lu from comment #0) > > On a Linux/x86-64 machine with 4GB RAM, I got failures like: > > > > FAIL: c-c++-common/tsan/atomic_stack.c -O0 output pattern test, is FATAL: > > ThreadSanitizer can not mmap the shadow memory (something is mapped at > > 0x4000 < 0x7cf0) > > This warning is not about physical RAM, but about virtual RAM. > This systems is not compatible with the tsan's shadow mapping. > Can you show the /proc/self/maps of the process before it dies 4000-5000 r-xp 08:11 34221424 /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe 55755000-55756000 rw-p 1000 08:11 34221424 /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe 7d00-7d08 ---p 00:00 0 7d08-7d080001 rw-p 00:00 0 7d080001-7d0b ---p 00:00 0 7d0b-7d0c rw-p 00:00 0 7d0c-7d64 ---p 00:00 0 7d64-7d640002 rw-p 00:00 0 7d640002-7d67 ---p 00:00 0 7d67-7d68 rw-p 00:00 0 7d68-7e00 ---p 00:00 0 7e00-7e003000 rw-p 00:00 0 7400-7500 rw-p 00:00 0 75f1c000-75f31000 r-xp 08:05 1445037 /usr/lib64/libgcc_s-4.8.2-2013.so.1 75f31000-76131000 ---p 00015000 08:05 1445037 /usr/lib64/libgcc_s-4.8.2-2013.so.1 76131000-76132000 rw-p 00015000 08:05 1445037 /usr/lib64/libgcc_s-4.8.2-2013.so.1 76132000-7621e000 r-xp 08:11 34215160 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.20 7621e000-7641d000 ---p 000ec000 08:11 34215160 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.20 7641d000-76425000 r--p 000eb000 08:11 34215160 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.20 76425000-76427000 rw-p 000f3000 08:11 34215160 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.20 76427000-7643c000 rw-p 00:00 0 7643c000-7643f000 r-xp 08:05 1443711 /usr/lib64/libdl-2.17.so 7643f000-7663e000 ---p 3000 08:05 1443711 /usr/lib64/libdl-2.17.so 7663e000-7663f000 r--p 2000 08:05 1443711 /usr/lib64/libdl-2.17.so 7663f000-7664 rw-p 3000 08:05 1443711 /usr/lib64/libdl-2.17.so 7664-76656000 r-xp 08:05 1443800 /usr/lib64/libpthread-2.17.so 76656000-76855000 ---p 00016000 08:05 1443800 /usr/lib64/libpthread-2.17.so 76855000-76856000 r--p 00015000 08:05 1443800 /usr/lib64/libpthread-2.17.so 76856000-76857000 rw-p 00016000 08:05 1443800 /usr/lib64/libpthread-2.17.so 76857000-7685b000 rw-p 00:00 0 7685b000-76a1 r-xp 08:05 1443557 /usr/lib64/libc-2.17.so 76a1-76c0f000 ---p 001b5000 08:05 1443557 /usr/lib64/libc-2.17.so 76c0f000-76c13000 r--p 001b4000 08:05 1443557 /usr/lib64/libc-2.17.so 76c13000-76c15000 rw-p 001b8000 08:05 1443557 /usr/lib64/libc-2.17.so 76c15000-76c1a000 rw-p 00:00 0 76c1a000-76d1b000 r-xp 08:05 1443818 /usr/lib64/libm-2.17.so 76d1b000-76f1a000 ---p 00101000 08:05 1443818 /usr/lib64/libm-2.17.so 76f1a000-76f1b000 r--p 0010 08:05 1443818 /usr/lib64/libm-2.17.so 76f1b000-76f1c000 rw-p 00101000 08:05 1443818 /usr/lib64/libm-2.17.so 76f1c000-76fac000 r-xp 08:11 34216164 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/libtsan.so.0.0.0 76fac000-771ab000 ---p 0009 08:11 34216164 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/libtsan.so.0.0.0 771ab000-771ae000 rw-p 0008f000 08:11 34216164 /export/build/gnu/gcc-x32/build-x86_64-linux/x86_64-unknown-linux-gnu/libsanitizer/tsan/.libs/libtsan.so.0.0.0 771ae000-77ddc000 rw-p 00:00 0 77ddc000-77dfd000 r-xp 08:05 1443142 /usr/lib64/ld-2.17.so 77f64000-77f
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #8 from Andrew Church --- Yes, by replacing "0 - allocate" with "allocate" it seems to work fine. Sorry for not trying it out myself earlier.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #12 from H.J. Lu --- For some reason, tsan tests aren't run on 6GB machine.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #11 from Kostya Serebryany --- > 4000-5000 r-xp 08:11 34221424 > /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe So, the executable is loaded into 4000, which intersects with tsan's shadow. See tsan/rtl/tsan_platform.h, around "C++ linux memory layout". In our experience this happens when ASLR is off. And this is caused by the kernel patch I mentioned above. https://code.google.com/p/thread-sanitizer/wiki/CppManual?ts=1386348951&updated=CppManual#FAQ We have not seen other reason for such mapping, maybe you know one :)
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #13 from Dmitry Vyukov --- And what if you enable randomization? > Have any attempt for saner tsan shadow memory mapping be done in the last > year? No, there were no such attempts. But, yes, it would be nice if tsan supports no-ASRL/no-PIE/COMPAT mappings.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #8 from David Kredba ---
Thank you Richard.
This fails as before:
kig-4.11.4_build # /usr/bin/x86_64-pc-linux-gnu-g++ -save-temps -fPIC -O2 -ggdb
-pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin
-Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall
-W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS
-fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics
-fvisibility=hidden -fvisibility-inlines-hidden -Wl,--enable-new-dtags
-Wl,--no-undefined -lc -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4
-fuse-linker-plugin -r -o lib/kigpart.so
CMakeFiles/kigpart.dir/scripting/python_scripter.o -nostdlib
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
[Leaving LTRANS /tmp/cce03m0F.args]
[Leaving LTRANS kigpart.so.ltrans.out]
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
I have ii file but it won't compile this way:
/usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -pipe -march=native
-mtune=native -flto=4 -fuse-linker-plugin -Wnon-virtual-dtor -Wno-long-long
-Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
-Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common
-Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
-fvisibility-inlines-hidden -Wl,--enable-new-dtags -Wl,--no-undefined -lc
-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe
-march=native -mtune=native -flto=4 -fuse-linker-plugin -o lib/kigpart.so
./python_scripter.ii -r -nostdlib
In file included from /usr/include/qt4/QtCore/qvariant.h:50:0,
from /usr/include/qt4/QtCore/QVariant:1,
from /usr/include/kconfig.h:32,
from /usr/include/ksharedconfig.h:25,
from /usr/include/klocale.h:26,
from
/var/tmp/portage/kde-base/kig-4.11.4/work/kig-4.11.4/scripting/../objects/common.h:27,
from
/var/tmp/portage/kde-base/kig-4.11.4/work/kig-4.11.4/scripting/python_scripter.h:21,
from
/var/tmp/portage/kde-base/kig-4.11.4/work/kig-4.11.4/scripting/python_scripter.cc:24:
/usr/include/qt4/QtCore/qhash.h: In member function ‘void
QHashData::hasShrunk()’:
/usr/include/qt4/QtCore/qhash.h:175:39: error: exception handling disabled, use
-fexceptions to enable
} QT_CATCH(const std::bad_alloc &) {
I removed -fno-exceptions -DQT_NO_EXCEPTIONS and it compiles and crashes as
before :-).
/usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -pipe -march=native
-mtune=native -flto=4 -fuse-linker-plugin -Wnon-virtual-dtor -Wno-long-long
-Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
-Wformat-security -fno-check-new -fno-common -Woverloaded-virtual
-fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden
-Wl,--enable-new-dtags -Wl,--no-undefined -lc -Wl,--as-needed -Wl,-O1
-Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native
-mtune=native -flto=4 -fuse-linker-plugin -o lib/kigpart.so
./python_scripter.ii -r -nostdliblto1: internal compiler error: in
splice_child_die, at dwarf2out.c:4706
Going to attach ii file gzipped.
What can I do next please?
Thank you.
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.2/work/gcc-4.8.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-cloog --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --disable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=ht
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #9 from David Kredba --- Created attachment 31391 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31391&action=edit Preprocessed source file
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #14 from H.J. Lu --- (In reply to Kostya Serebryany from comment #11) > > 4000-5000 r-xp 08:11 34221424 > > /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe > > So, the executable is loaded into 4000, which intersects with > tsan's shadow. > See tsan/rtl/tsan_platform.h, around "C++ linux memory layout". > In our experience this happens when ASLR is off. > And this is caused by the kernel patch I mentioned above. > https://code.google.com/p/thread-sanitizer/wiki/ > CppManual?ts=1386348951&updated=CppManual#FAQ > > We have not seen other reason for such mapping, maybe you know one :) Kernel is free to load PIE at ANY address it wants. But you can specify where to load PIE via a linker switch -Ttext-segment 0x8500 to tell kernel to load PIE to a specific address.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #15 from Jakub Jelinek --- What I mean, unlike asan where the shadow memory shift and base is part of the ABI, in tsan, while performance sensitive, the MemToShadow is still library implementation detail. So, I think it shouldn't be that difficult to support it. Perhaps have a compilation mode, one most performant where you'd hardcode what you do right now and just give up if it can't be made to work, and another slightly slower one where some of the components (I guess the shift can remain hardcoded, but ored in constant can be variable, and perhaps some other operation can be added to the function too). Then during libtsan initialization it can just see if the default memory layout is viable and otherwise try some other one. I thought we've discussed it to some extent already, but don't remember where exactly.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #16 from Kostya Serebryany --- > Kernel is free to load PIE at ANY address it wants. But > you can specify where to load PIE via a linker switch > > -Ttext-segment 0x8500 > > to tell kernel to load PIE to a specific address. Hm. Interesting. What do I do wrong? % clang++ simple_race.cc -fsanitize=thread -Wl,-Ttext-segment=0x7d00 ; (setarch x86_64 -R ./a.out ) FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FATAL: Make sure to compile with -fPIE and to link with -pie. % clang++ simple_race.cc -fsanitize=thread ; (setarch x86_64 -R ./a.out ) FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 < 0x7cf0) FATAL: Make sure to compile with -fPIE and to link with -pie. % clang++ simple_race.cc -fsanitize=thread ; ( ./a.out ) == WARNING: ThreadSanitizer: data race (pid=6559)
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #17 from Kostya Serebryany --- > already, but don't remember where exactly. Please let's move the discussion about non-PIE here: https://code.google.com/p/thread-sanitizer/issues/detail?id=5
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Fri Dec 6 17:16:52 2013 New Revision: 205753 URL: http://gcc.gnu.org/viewcvs?rev=205753&root=gcc&view=rev Log: PR target/59405 * config/i386/i386.c (type_natural_mode): Properly handle size 8 for !TARGET_64BIT. testsuite/ChangeLog: PR target/59405 * gcc.target/i386/pr59405.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr59405.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #10 from Markus Trippelsdorf --- (In reply to David Kredba from comment #8) > Going to attach ii file gzipped. > > What can I do next please? You can now further reduce the single testfile by following the "Simple ICE reduction" section in the document I've linked to above. First try to minimize the gcc command line options that you use. Then write a simple test script, e.g.: $ cat chech.sh /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -ggdb -flto -r -nostdlib -Wfatal-errors test.ii -o /dev/null 2>&1 | grep 'internal compiler error: in splice_child_die' if ! test $? = 0; then exit 1 fi and run delta, multidelta or Creduce with it.
[Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #18 from H.J. Lu --- (In reply to Kostya Serebryany from comment #16) > > Kernel is free to load PIE at ANY address it wants. But > > you can specify where to load PIE via a linker switch > > > > -Ttext-segment 0x8500 > > > > to tell kernel to load PIE to a specific address. > > Hm. Interesting. What do I do wrong? > % clang++ simple_race.cc -fsanitize=thread -Wl,-Ttext-segment=0x7d00 > ; (setarch x86_64 -R ./a.out ) > FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped > at 0x4000 < 0x7cf0) > FATAL: Make sure to compile with -fPIE and to link with -pie. Please show the output of # readelf -lW a.out
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-06 Summary|Some tsan tests fail with |tsan tests fail with |address randomization |address randomization |disabled|disabled Ever confirmed|0 |1
[Bug target/59405] Incorrect FP<->MMX transition during call/ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Target Milestone|--- |4.7.4 --- Comment #10 from Uroš Bizjak --- The warning is fixed, the testcase without _mm_empty () is invalid.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #19 from H.J. Lu --- (In reply to H.J. Lu from comment #18) > (In reply to Kostya Serebryany from comment #16) > > > Kernel is free to load PIE at ANY address it wants. But > > > you can specify where to load PIE via a linker switch > > > > > > -Ttext-segment 0x8500 > > > > > > to tell kernel to load PIE to a specific address. > > > > Hm. Interesting. What do I do wrong? > > % clang++ simple_race.cc -fsanitize=thread -Wl,-Ttext-segment=0x7d00 > > ; (setarch x86_64 -R ./a.out ) > > FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped > > at 0x4000 < 0x7cf0) > > FATAL: Make sure to compile with -fPIE and to link with -pie. > > Please show the output of > > # readelf -lW a.out Your address must be sensible. Otherwise kernel will ignore it. Please try "-Ttext-segment 0x8500".
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #20 from Kostya Serebryany ---
> >
> > # readelf -lW a.out
>
> Your address must be sensible. Otherwise kernel will ignore it.
> Please try "-Ttext-segment 0x8500".
How is 0x8500 censible if it's beyond the address space?
(Or I miss something?)
Anyway, here is an experiment that proves that on my box
-Ttext-segment is ignored if ASLR is off.
% cat print_main.cc
#include
int main() {
printf("main: %p\n", &main);
}
% g++ print_main.cc -fPIE -pie -Wl,-Ttext-segment=0x6ABC5500 && ./a.out
main: 0x6abc5500072c
% g++ print_main.cc -fPIE -pie -Wl,-Ttext-segment=0x6ABC5500 && setarch
x86_64 -R ./a.out
main: 0x472c
% readelf -lW ./a.out
Elf file type is DYN (Shared object file)
Entry point 0x6abc55000630
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
PHDR 0x40 0x6abc5540 0x6abc5540 0x0001f8
0x0001f8 R E 0x8
INTERP 0x000238 0x6abc55000238 0x6abc55000238 0x1c
0x1c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x00 0x6abc5500 0x6abc5500 0x00091c
0x00091c R E 0x20
LOAD 0x000e00 0x6abc55200e00 0x6abc55200e00 0x000228
0x000238 RW 0x20
DYNAMIC0x000e28 0x6abc55200e28 0x6abc55200e28 0x000190
0x000190 RW 0x8
NOTE 0x000254 0x6abc55000254 0x6abc55000254 0x44
0x44 R 0x4
GNU_EH_FRAME 0x000848 0x6abc55000848 0x6abc55000848 0x2c
0x2c R 0x4
GNU_STACK 0x00 0x 0x 0x00
0x00 RW 0x8
GNU_RELRO 0x000e00 0x6abc55200e00 0x6abc55200e00 0x000200
0x000200 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .eh_frame_hdr
07
08 .ctors .dtors .jcr .dynamic .got
[Bug tree-optimization/59388] [4.7/4.8/4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388 --- Comment #5 from Jakub Jelinek --- Created attachment 31393 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31393&action=edit gcc48-pr59388.patch Untested 4.8.x patch.
[Bug tree-optimization/59388] [4.7/4.8/4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388 Jakub Jelinek 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 --- Created attachment 31392 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31392&action=edit gcc49-pr59388.patch Untested 4.9 fix.
[Bug libgcc/59412] New: __fixunsdfDI triggers wrong inexact exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412
Bug ID: 59412
Summary: __fixunsdfDI triggers wrong inexact exceptions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: aurelien at aurel32 dot net
__fixunsdfDI triggers an inexact exception even when converting an integer
number from double to long long, while it shouldn't. This is due to this part
of the code:
UDWtype
__fixunsdfDI (DFtype a)
{
/* Get high part of result. The division here will just moves the radix
point and will not cause any rounding. Then the conversion to integral
type chops result as desired. */
const UWtype hi = a / Wtype_MAXp1_F;
As said in the comment, the division just moves the radix, so it doesn't
triggers an inexact exception. However then the value then have some decimal
parts and the convertsion from double to int triggers the inexact exception.
This is reproducible for example on powerpc32 and causes errors in the glibc
testsuite.
[Bug tree-optimization/59413] New: wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
Bug ID: 59413
Summary: wrong code at -Os on x86_64-linux-gnu in both 32-bit
and 64-bit modes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk miscompiles the following code on x86_64-linux at -Os
(but not at the other optimization levels) in both 32-bit and 64-bit modes.
It is interesting that the typedef appears necessary to trigger the
miscompilation.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20131206 (experimental) [trunk revision 205734] (GCC)
$
$ gcc-trunk -O1 small.c; a.out
7
$ gcc-trunk -O2 small.c; a.out
7
$ gcc-4.8 -Os small.c; a.out
7
$
$ gcc-trunk -Os small.c; a.out
2
$
int printf (const char *, ...);
typedef unsigned int uint32_t;
uint32_t a;
int b;
int
main ()
{
uint32_t c;
for (a = 7; a <= 1; a++)
{
char d = a;
c = d;
b = a == c;
}
printf ("%d\n", a);
return 0;
}
[Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-06 CC||rguenther at suse dot de Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is caused by r205730. When the x32 perlbmk binary is running. it causes *** Error in `../0002/perlbmk_peak.lto': malloc(): memory corruption (fast): 0x00fcd640 ***
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #21 from H.J. Lu --- (In reply to Kostya Serebryany from comment #20) > > > > > > # readelf -lW a.out > > > > Your address must be sensible. Otherwise kernel will ignore it. > > Please try "-Ttext-segment 0x8500". > > How is 0x8500 censible if it's beyond the address space? > (Or I miss something?) > > Anyway, here is an experiment that proves that on my box > -Ttext-segment is ignored if ASLR is off. > > That is true. The kernel change was made to fix: https://bugzilla.kernel.org/show_bug.cgi?id=36372
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #22 from Kostya Serebryany --- > That is true. The kernel change was made to fix: > > https://bugzilla.kernel.org/show_bug.cgi?id=36372 Could you please explain the situation? What was fixed and in which kernel?
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #23 from H.J. Lu --- I opened: https://bugzilla.kernel.org/show_bug.cgi?id=66721
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #24 from H.J. Lu --- (In reply to Kostya Serebryany from comment #22) > > That is true. The kernel change was made to fix: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=36372 > > Could you please explain the situation? > What was fixed and in which kernel? The kernel bug is explained at https://bugzilla.redhat.com/show_bug.cgi?id=708563 https://bugzilla.kernel.org/show_bug.cgi?id=36372
[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 #11 from Jan Hubicka --- The inlining of perdida also happens with --param large-function-insns=10. perhaps it indicates we shoud bump this parameter up little bit. The reason why inlining order changed is iztaccihuatl that calls perdida. The function has 78 checks that leads to early exit (because of out of memory I believe). Before the __builtin_expect change we predicted them all with 0.01% probability to exit, while now we predict them with 0.1. Obviously 0.9^78 is a lot less than 0.99^78. Fortran fronend should probably stop using builtin_expect where we can derive the same info from noreturn (as it seems to be the case here), but it is not always. I wonder if we want to add optional probability argument to builtlin_expect? It is not completely trvial addition since expr_expected_value_1 does some propagation and it will need to be extended to handle the probablities, too. Honza
[Bug go/59408] [4.9 regression] Many Go tests FAIL with notesleep not on g0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri Dec 6 18:26:27 2013 New Revision: 205756 URL: http://gcc.gnu.org/viewcvs?rev=205756&root=gcc&view=rev Log: PR go/59408 runtime: Don't require g != m->g0 in sema notesleep. Modified: trunk/libgo/runtime/lock_sema.c
[Bug go/59408] [4.9 regression] Many Go tests FAIL with notesleep not on g0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- This problem should be fixed now. Sorry about that.
[Bug fortran/59414] New: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 Bug ID: 59414 Summary: Class array pointers: compile error on valid code (Different ranks in pointer assignment) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Created attachment 31394 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31394&action=edit OOP module implementing lists of arrays of objects Compiler errors like ObjectLists.f90:597.4: Item => L%ArrayItem(i) 1 Error: Different ranks in pointer assignment at (1) Code is a class array pointer to a function that returns a class array pointer: function ArrayItem(L, i) result(P) Class(TObjectList) :: L integer, intent(in) :: i Class(*), pointer :: P(:) select type (Point=> L%Items(i)%P) class is (object_array_pointer) P => Point%P class default stop 'TObjectList: item is not array item' end select end function ArrayItem ... class(*), pointer :: Item(:) Item => L%ArrayItem(i) Code is valid and works with the Intel compiler. Complete generic list module attached (from the widely-used but currently not gfortran-compiling CosmoMC parameter estimation package).
[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 #12 from Dominique d'Humieres --- > The inlining of perdida also happens with --param large-function-insns=10. > perhaps it indicates we shoud bump this parameter up little bit. The threshold is ~6000 (exactly 5941), i.e. more than twice the default value 2700.
[Bug testsuite/59043] [4.9 Regression] FAIL: (gcc|++).dg/pubtypes* scan-assembler long.*Length of Public Type Names Info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59043 --- Comment #2 from mrs at gcc dot gnu.org --- Author: mrs Date: Fri Dec 6 19:26:26 2013 New Revision: 205758 URL: http://gcc.gnu.org/viewcvs?rev=205758&root=gcc&view=rev Log: 2013-12-06 Dominique d'Humieres PR testsuite/59043 * g++.dg/pubtypes.C: Adjust the regular expression. * gcc.dg/pubtypes-1.c: Likewise. * gcc.dg/pubtypes-2.c: Likewise. * gcc.dg/pubtypes-3.c: Likewise. * gcc.dg/pubtypes-4.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pubtypes.C trunk/gcc/testsuite/gcc.dg/pubtypes-1.c trunk/gcc/testsuite/gcc.dg/pubtypes-2.c trunk/gcc/testsuite/gcc.dg/pubtypes-3.c trunk/gcc/testsuite/gcc.dg/pubtypes-4.c
[Bug middle-end/59399] ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399 --- Comment #3 from Marek Polacek --- On both x86_64 and ppc64, we have this identical SSA_NAME: unit size align 32 symtab 0 alias set -1 canonical type 0x7fb5a65a4690 precision 32 min max pointer_to_this > visited var def_stmt _3 = UBSAN_CHECK_ADD (j_1(D), i_2(D)); version 3> Now in expr.c we call get_rtx_for_ssa_name on it. On x86_64 the RTX is then (reg:SI 83 [ D.2423 ]) while on ppc64 the RTX is (reg:DI 123 [ D.2759+-4 ]), so we have a discrepancy here. And then the following is true on ppc64 if (REG_P (decl_rtl) && DECL_MODE (exp) != BLKmode && GET_MODE (decl_rtl) != DECL_MODE (exp)) because DECL_MODE (exp) is SImode, not DImode. And then we make our way to the block of code where we fail. Why get_rtx_for_ssa_name returns different rtx for the same SSA_NAME?
