[Bug tree-optimization/65805] New: [5/6 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 Bug ID: 65805 Summary: [5/6 Regression] Chromium gets miscompiled Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Created attachment 35357 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35357action=edit unreduced testcase Program received signal SIGSEGV, Segmentation fault. 0x5836d9be in extensions::Manifest::HasPath(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const) const () (gdb) bt #0 0x5836d9be in extensions::Manifest::HasPath(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const) const () #1 0x5836e5a4 in extensions::ManifestHandlerRegistry::ValidateExtension(extensions::Extension const*, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorextensions::InstallWarning, std::allocatorextensions::InstallWarning *) () #2 0x5836c942 in extensions::file_util::ValidateExtension(extensions::Extension const*, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorextensions::InstallWarning, std::allocatorextensions::InstallWarning *) () #3 0x5836cc28 in extensions::file_util::LoadExtension(base::FilePath const, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, extensions::Manifest::Location, int, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar *) () #4 0x5836cd19 in extensions::file_util::LoadExtension(base::FilePath const, extensions::Manifest::Location, int, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar *) () #5 0x593aeaf2 in extensions::InstalledLoader::LoadAllExtensions() () #6 0x5938d3bf in ExtensionService::Init() () #7 0x59395f47 in extensions::ExtensionSystemImpl::Shared::Init(bool) () #8 0x5939707a in extensions::ExtensionSystemImpl::InitForRegularProfile(bool) () #9 0x5618d10f in ProfileManager::DoFinalInitForServices(Profile*, bool) () #10 0x5618e262 in ProfileManager::DoFinalInit(Profile*, bool) () #11 0x5618fb88 in ProfileManager::AddProfile(Profile*) () #12 0x5618fe08 in ProfileManager::CreateAndInitializeProfile(base::FilePath const) () #13 0x56190507 in ProfileManager::GetProfile(base::FilePath const) () #14 0x562729b8 in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() () #15 0x5627388a in ChromeBrowserMainParts::PreMainMessageLoopRun() () #16 0x589304af in content::BrowserMainLoop::PreMainMessageLoopRun() () #17 0x58a3464f in content::StartupTaskRunner::RunAllTasksNow() () #18 0x58935d3d in content::BrowserMainLoop::CreateStartupTasks() () #19 0x5873297c in content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const) () #20 0x5873236d in content::BrowserMain(content::MainFunctionParams const) () #21 0x56507ca9 in content::ContentMainRunnerImpl::Run() () #22 0x565063f1 in content::ContentMain(content::ContentMainParams const) () #23 0x55fecb1a in ChromeMain () #24 0x7619f6b0 in __libc_start_main () from /lib/libc.so.6 #25 0x55fec9b9 in _start () (gdb) disass Dump of assembler code for function _ZNK10extensions8Manifest7HasPathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE: 0x5836d9a0 +0: push %rbp 0x5836d9a1 +1: push %rbx 0x5836d9a2 +2: mov%rdi,%rbp 0x5836d9a5 +5: mov%rsi,%rbx 0x5836d9a8 +8: sub$0x18,%rsp 0x5836d9ac +12:movq $0x0,0x8(%rsp) 0x5836d9b5 +21:callq 0x5836d7d0 _ZNK10extensions8Manifest13CanAccessPathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 0x5836d9ba +26:test %al,%al 0x5836d9bc +28:je 0x5836d9cf _ZNK10extensions8Manifest7HasPathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+47 = 0x5836d9be +30:mov0x30(%rbp),%rdi 0x5836d9c2 +34:lea0x8(%rsp),%rdx 0x5836d9c7 +39:mov%rbx,%rsi 0x5836d9ca +42:callq 0x565b3e10 _ZN4base15DictionaryValue3GetERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPPNS_5ValueE 0x5836d9cf +47:add$0x18,%rsp 0x5836d9d3 +51:pop%rbx 0x5836d9d4 +52:pop%rbp 0x5836d9d5 +53:retq End of assembler dump. markus@x4 Release % g++ -MMD -MF obj/extensions/common/extensions_common.file_util.o.d -DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 -DDISABLE_NACL -DCHROMIUM_BUILD -DTOOLKIT_VIEWS=1 -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_ASH=1 -DUSE_PANGO=1 -DUSE_CAIRO=1
[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135 --- Comment #9 from lc289dafd7ybme05se at softbank dot ne.jp --- right. i don't know why, but templateclass is also needed, to invoke the error.
[Bug rtl-optimization/65805] [5/6 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- markus@x4 Release % g++ -S -fPIC -fvisibility=hidden -pthread -march=x86-64 -O2 -fno-exceptions -fno-rtti -std=gnu++11 -Wall -c file_util.ii -o ass_good markus@x4 Release % diff -u ass_good ass_bad --- ass_good2015-04-19 12:49:09.198287280 +0200 +++ ass_bad 2015-04-19 12:49:20.571371228 +0200 @@ -1,7 +1,7 @@ -.LCOLDB52: +.LCOLDB51: .text -.LHOTB52: - .p2align 4,,-1 +.LHOTB51: + .p2align 4,,15 .globl _ZN10extensions9file_util13LoadExtensionERKN4base8FilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS_8Manifest8LocationEiPSA_ .hidden _ZN10extensions9file_util13LoadExtensionERKN4base8FilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS_8Manifest8LocationEiPSA_ .type _ZN10extensions9file_util13LoadExtensionERKN4base8FilePathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS_8Manifest8LocationEiPSA_, @function @@ -21,43 +21,43 @@ pushq %r12 .cfi_def_cfa_offset 40 .cfi_offset 12, -40 - movq%rsi, %r12 + movq%rsi, %r13 pushq %rbp .cfi_def_cfa_offset 48 .cfi_offset 6, -48 pushq %rbx .cfi_def_cfa_offset 56 .cfi_offset 3, -56 - movq%rdi, %rbp + movq%rdi, %r12 movq%r9, %rdx - movq%r12, %rdi + movq%r13, %rdi movl%r8d, %r14d subq$56, %rsp .cfi_def_cfa_offset 112 movq_ZN10extensions17kManifestFilenameE@GOTPCREL(%rip), %rsi - movq%r9, %rbx + movq%r9, %rbp movl%ecx, 4(%rsp) call _ZN10extensions9file_util12LoadManifestERKN4base8FilePathEPKcPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE testq %rax, %rax - je .L614 - movq%rbx, %rdx + je .L622 + movq%rbp, %rdx movq%rax, %rsi - movq%r12, %rdi - movq%rax, %r13 + movq%r13, %rdi + movq%rax, %rbx call _ZN19extension_l10n_util17LocalizeExtensionERKN4base8FilePathEPNS0_15DictionaryValueEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@PLT testb %al, %al - jne .L615 -.L613: - movq$0, 0(%rbp) -.L609: - movq0(%r13), %rax - movq%r13, %rdi - call*8(%rax) + jne .L623 +.L621: + movq$0, (%r12) .L603: + movq(%rbx), %rax + movq%rbx, %rdi + call*8(%rax) +.L597: addq$56, %rsp .cfi_remember_state .cfi_def_cfa_offset 56 - movq%rbp, %rax + movq%r12, %rax popq%rbx .cfi_def_cfa_offset 48 popq%rbp @@ -73,66 +73,85 @@ ret .p2align 4,,10 .p2align 3 -.L615: +.L623: .cfi_restore_state leaq16(%rsp), %rax subq$8, %rsp .cfi_def_cfa_offset 120 - movq%r12, %rsi + movq%r13, %rsi movq%r15, %r9 movl%r14d, %r8d - movq%r13, %rcx + movq%rbx, %rcx movq%rax, 16(%rsp) - pushq %rbx + pushq %rbp .cfi_def_cfa_offset 128 movl20(%rsp), %edx - movq24(%rsp), %rdi + leaq64(%rsp), %rdi call _ZN10extensions9Extension6CreateERKN4base8FilePathENS_8Manifest8LocationERKNS1_15DictionaryValueEiRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPSF_@PLT - movq32(%rsp), %r12 + movq32(%rsp), %r13 popq%rax .cfi_def_cfa_offset 120 popq%rdx .cfi_def_cfa_offset 112 - testq %r12, %r12 - je .L613 + testq %r13, %r13 + je .L621 movq8(%rsp), %rdx - movq%rbx, %rsi - movq%r12, %rdi + movq%rbp, %rsi + movq%r13, %rdi movq$0, 16(%rsp) movq$0, 24(%rsp) movq$0, 32(%rsp) call _ZN10extensions9file_util17ValidateExtensionEPKNS_9ExtensionEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPSt6vectorINS_14InstallWarningESaISC_EE testb %al, %al - jne .L610 - movq8(%rsp), %rdi - movq$0, 0(%rbp) - call_ZNSt6vectorIN10extensions14InstallWarningESaIS1_EED1Ev - leaq8(%r12), %rdi + jne .L604 + movq$0, (%r12) +.L605: + movq24(%rsp), %r14 + movq16(%rsp), %rbp + cmpq%rbp, %r14 + je .L606 + .p2align 4,,10 + .p2align 3 +.L607: + movq%rbp, %rdi + addq$96, %rbp + call_ZN10extensions14InstallWarningD1Ev@PLT + cmpq%rbp, %r14 + jne .L607 + movq16(%rsp), %r14 +.L606: + testq %r14, %r14 + je .L608 + movq%r14, %rdi + call_ZdlPv@PLT +.L608: + testq %r13, %r13 + je
[Bug libgcc/62097] mipsel-sde-elf build fails on OS X 10.7 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097 --- Comment #2 from Anders Montonen Anders.Montonen at iki dot fi --- Behaviour is the same with GCC 4.9.2 and GCC 5.0.1 RC-20150418, on OS X 10.10 with Xcode 6.3 tools (clang --version: Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn))
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-19 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from vries at gcc dot gnu.org --- Confirmed, I see the failure as well.
[Bug rtl-optimization/65805] [5/6 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-19
CC||vmakarov at gcc dot gnu.org
Component|tree-optimization |rtl-optimization
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Adding __attribute__ ((optimize(-fno-lra-remat))) to LoadExtension() fixes
the issue.
133170 __attribute__ ((optimize(-fno-lra-remat)))
133171 scoped_refptrExtension LoadExtension(const base::FilePath
extension_path,
133172const std::string extension_id,
133173Manifest::Location location,
133174int flags,
133175std::string* error) {
133176 scoped_ptrbase::DictionaryValue manifest(
133177 LoadManifest(extension_path, error));
133178 if (!manifest.get())
133179 return
133180 # 197 ../../extensions/common/file_util.cc 3 4
133181 __null
133182 # 197 ../../extensions/common/file_util.cc
133183 ;
133184 if (!extension_l10n_util::LocalizeExtension(
133185 extension_path, manifest.get(), error)) {
133186 return
133187 # 200 ../../extensions/common/file_util.cc 3 4
133188 __null
133189 # 200 ../../extensions/common/file_util.cc
133190 ;
133191 }
133192
133193 scoped_refptrExtension extension(Extension::Create(
133194 extension_path, location, *manifest, flags, extension_id, error));
133195 if (!extension.get())
133196 return
133197 # 206 ../../extensions/common/file_util.cc 3 4
133198 __null
133199 # 206 ../../extensions/common/file_util.cc
133200 ;
133201
133202 std::vectorInstallWarning warnings;
133203 if (!ValidateExtension(extension.get(), error, warnings))
133204 return
133205 # 210 ../../extensions/common/file_util.cc 3 4
133206 __null
133207 # 210 ../../extensions/common/file_util.cc
133208 ;
133209 extension-AddInstallWarnings(warnings);
133210
133211 return extension;
133212 }
133213
[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135 --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to lc289dafd7ybme05se from comment #7) 仮想継承の時もエラーになるみたいですね。 To save some clicking, Google translate said: It seems to be an error even when the virtual inheritance.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #5 from vries at gcc dot gnu.org ---
Before the patch series, at 011.cfg we had this representation:
...
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
D.2342 = cD.2333.gp_offsetD.5;
if (D.2342 = 48)
goto bb 4;
else
goto bb 3;
;;succ: 4 (TRUE_VALUE)
;;3 (FALSE_VALUE)
;; basic block 3, loop depth 0, count 0, freq 0, maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE)
;;pred: 2 (FALSE_VALUE)
D.2344 = cD.2333.reg_save_areaD.8;
D.2345 = cD.2333.gp_offsetD.5;
D.2346 = (sizetype) D.2345;
addr.0D.2339 = D.2344 + D.2346;
D.2347 = cD.2333.gp_offsetD.5;
D.2348 = D.2347 + 8;
cD.2333.gp_offsetD.5 = D.2348;
goto bb 5;
;;succ: 5 (FALLTHRU)
;; basic block 4, loop depth 0, count 0, freq 0, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE)
;;pred: 2 (TRUE_VALUE)
D.2349 = cD.2333.overflow_arg_areaD.7;
addr.0D.2339 = D.2349;
D.2350 = D.2349 + 8;
cD.2333.overflow_arg_areaD.7 = D.2350;
;;succ: 5 (FALLTHRU)
;; basic block 5, loop depth 0, count 0, freq 0, maybe hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE)
;;pred: 3 (FALLTHRU)
;;4 (FALLTHRU)
d.1D.2351 = MEM[(intD.9 * * {ref-all})addr.0D.2339];
dD.2334 = d.1D.2351;
eD.2335 = dD.2334;
__asm__( : =d eD.2335);
[LP 1] # USE = anything
# CLB = anything
m_fn1D.2327 (aD.2330);
;;succ: 9 (EH)
;;6 (FALLTHRU)
...
There's no exception connected to the whole va_arg sequence.
So the question is: should ifn_va_arg have ECF_NOTHROW?
[Bug rtl-optimization/65805] [5/6 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Sun Apr 19 23:48:24 2015 New Revision: 23 URL: https://gcc.gnu.org/viewcvs?rev=23root=gccview=rev Log: 2015-04-19 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/65805 * lra-eliminations.c (lra_eliminate_regs_1): Add new assert. Don't use difference of offset and previous offset if update_sp_offset is non-zero. (eliminate_regs_in_insn): Ditto. * lra-spills.c (remove_pseudos): Exchange 4th and 6th args in lra_eliminate_regs_1 call. * lra-constraints.c (get_equiv_with_elimination): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-eliminations.c trunk/gcc/lra-spills.c
[Bug rtl-optimization/65805] [5/6 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- It is clearer to see the issue if one compiles the whole file with -fno-lra-remat: markus@x4 Release % g++ -S -fno-lra-remat -fPIC -fvisibility=hidden -pthread -march=x86-64 -O2 -fno-exceptions -fno-rtti -std=gnu++11 -Wall -c file_util.ii -o out_good markus@x4 Release % g++ -S -fPIC -fvisibility=hidden -pthread -march=x86-64 -O2 -fno-exceptions -fno-rtti -std=gnu++11 -Wall -c file_util.ii -o out_bad markus@x4 Release % diff -u out_good out_bad ... @@ -4616,7 +4616,7 @@ pushq %rbp .cfi_def_cfa_offset 128 movl20(%rsp), %edx - movq24(%rsp), %rdi + leaq64(%rsp), %rdi call _ZN10extensions9Extension6CreateERKN4base8FilePathENS_8Manifest8LocationERKNS1_15DictionaryValueEiRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPSF_@PLT movq32(%rsp), %r13 popq%rax When I change leaq 64(%rsp), %rdi back to movq 24(%rsp), %rdi chromium runs fine.
[Bug other/62279] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 jon.turney at dronecode dot org.uk changed: What|Removed |Added CC||jon.turney at dronecode dot org.uk --- Comment #2 from jon.turney at dronecode dot org.uk --- See also the corresponding GDB bug https://sourceware.org/bugzilla/show_bug.cgi?id=17066
[Bug target/65810] New: powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
Bug ID: 65810
Summary: powerpc64 libgfortran alignment issue?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Testsuite results between two identical powerpc64-linux builds, except for the
source path name, differ.
+FAIL: gfortran.dg/fmt_en.f90 -O0 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O1 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O1 scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O2 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O2 scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops
scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer scan-file All kinds
rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -g execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -g scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -Os execution test
+FAIL: gfortran.dg/fmt_en.f90 -Os scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer execution
test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test
+FAIL: gfortran.dg/quad_2.f90 -O0 execution test
+FAIL: gfortran.dg/quad_2.f90 -O1 execution test
+FAIL: gfortran.dg/quad_2.f90 -O2 execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test
+FAIL: gfortran.dg/quad_2.f90 -Os execution test
Both compilers configured with
CC=gcc -m64 CXX=g++ -m64 \
${gcc_src}/configure --build=powerpc64-linux \
--with-cpu=power7 \
--disable-nls --enable-__cxa_atexit --enable-secureplt \
--with-long-double-128 --enable-gnu-indirect-function \
--enable-languages=all,go --enable-lto
In one case gcc_src=/home/amodra/src/gcc-5-virgin
the other gcc_src=/home/amodra/src/gcc-5-vir
Running the testcases by hand with different LD_LIBRARY_PATH show the problem
is in libgfortran, not the testcase code. valgrind doesn't show any
uninitialized accesses.
Looking at quad_2.f90 under gdb, I see the abort is due to str3 having an extra
leading space.
[Bug c/65808] New: -pedantic -std=gnu11 results in warning for transparent_union usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808
Bug ID: 65808
Summary: -pedantic -std=gnu11 results in warning for
transparent_union usage
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: equinox-gccbugs at diac24 dot net
Created attachment 35359
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35359action=edit
test program, compile with -std=gnu11 -pedantic
Trying to use a transparent_union results in a warning when -pedantic is used,
even though -std=gnu11 is specified.
Test program is this:
(gcc -std=gnu11 -pedantic -c /tmp/uniontest.c)
struct a { int a; };
struct b { int b; };
__extension__ union ab {
struct a *pa;
struct b *pb;
} __attribute__ ((transparent_union));
extern void func1 (union ab arg);
__extension__ extern void func2 (union ab arg);
void test(void)
{
struct a sa = { 1 };
func1(sa); /* warning */
__extension__ func1(sa); /* no warning */
func2(sa); /* warning */
}
Expected behaviour: no warning at all, or some way to put __extension__ on the
union or the function prototype.
Actual behaviour: __extension__ must be used on each and every individual
function call, or a warning occurs:
/tmp/uniontest.c: In function ‘test’:
/tmp/uniontest.c:15:2: warning: ISO C prohibits argument conversion to union
type [-Wpedantic]
func1(sa); /* warning */
^
/tmp/uniontest.c:17:2: warning: ISO C prohibits argument conversion to union
type [-Wpedantic]
func2(sa); /* warning */
^
[Bug debug/65809] New: FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 Bug ID: 65809 Summary: FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, jakub at gcc dot gnu.org Host: x86_64-apple-darwin14.3 Target: x86_64-apple-darwin14.3 Build: x86_64-apple-darwin14.3 On x86_64-apple-darwin14.3.0, I see FAIL: gcc.dg/debug/pr65771.c -gstabs+ -O (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gstabs+ -O3 (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gstabs+1 -O (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gstabs+1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gstabs+3 -O (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gstabs+3 -O3 (test for excess errors) on 5.0.1 20150418 (prerelease) and trunk (r14). The test has been introduced in revision r222166. The excess error is ld: warning: can't find atom for N_GSYM stabs a:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16) in /var/folders/... I see the warning with revision r211698, but not with r211105.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #4 from vries at gcc dot gnu.org ---
The assert triggering is:
...
(gdb)
#5 0x011325fe in redirect_eh_edge_1 (edge_in=0x764af4d0,
new_bb=0x764ae4e0, change_region=true) at src/gcc/tree-eh.c:2335
2335 gcc_assert (lookup_stmt_eh_lp (throw_stmt) == old_lp_nr);
...
Indeed the comparison fails:
...
(gdb) p old_lp_nr
$1 = 1
(gdb) p lookup_stmt_eh_lp (throw_stmt)
$2 = 0
...
And lookup_stmt_eh_lp (throw_stmt) is 0, because throw_stmt is NULL, which
presumably is not intended to be NULL here:
...
(gdb) p throw_stmt
$3 = (gimple) 0x0
...
throw_stmt is initialized here:
...
2334 throw_stmt = last_stmt (edge_in-src);
...
In fact edge_in-src is an empty bb:
...
(gdb) call debug_bb (edge_in-src)
;; basic block 15, loop depth 0, count 0, freq 0, maybe hot
;; prev block 14, next block 3, flags: (NEW)
;; pred: 14 (FALLTHRU)
;; succ: 7 (EH)
;; 3 (FALLTHRU)
...
Before pass_lower_vaarg, we have this definition in bb2 definining for _6:
...
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
[LP 1] # .MEM_5 = VDEF .MEM_4(D)
# USE = anything
# CLB = anything
_6 = VA_ARG (cD.2333, 0B);
;;succ: 7 (EH)
;;3 (FALLTHRU)
...
After pass_lower_vaarg, it's spread over several basic blocks:
...
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 11, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
;;succ: 11 [100.0%] (FALLTHRU)
;; basic block 11, loop depth 0, count 0, freq 0, maybe hot
;;prev block 2, next block 12, flags: (NEW)
;;pred: 2 [100.0%] (FALLTHRU)
# VUSE .MEM_4(D)
_22 = cD.2333.gp_offsetD.5;
if (_22 = 48)
goto bb 13 (L6);
else
goto bb 12 (L5);
;;succ: 13 (TRUE_VALUE)
;;12 (FALSE_VALUE)
;; basic block 12, loop depth 0, count 0, freq 0, maybe hot
;;prev block 11, next block 13, flags: (NEW)
;;pred: 11 (FALSE_VALUE)
L5:
# VUSE .MEM_4(D)
_23 = cD.2333.reg_save_areaD.8;
# VUSE .MEM_4(D)
_24 = cD.2333.gp_offsetD.5;
_25 = (sizetype) _24;
addr.1_26 = _23 + _25;
# VUSE .MEM_4(D)
_27 = cD.2333.gp_offsetD.5;
_28 = _27 + 8;
# .MEM_29 = VDEF .MEM_4(D)
cD.2333.gp_offsetD.5 = _28;
goto bb 14 (L7);
;;succ: 14 (FALLTHRU)
;; basic block 13, loop depth 0, count 0, freq 0, maybe hot
;;prev block 12, next block 14, flags: (NEW)
;;pred: 11 (TRUE_VALUE)
L6:
# VUSE .MEM_4(D)
_30 = cD.2333.overflow_arg_areaD.7;
addr.1_31 = _30;
_32 = _30 + 8;
# .MEM_33 = VDEF .MEM_4(D)
cD.2333.overflow_arg_areaD.7 = _32;
;;succ: 14 (FALLTHRU)
;; basic block 14, loop depth 0, count 0, freq 0, maybe hot
;;prev block 13, next block 15, flags: (NEW)
;;pred: 12 (FALLTHRU)
;;13 (FALLTHRU)
# .MEM_20 = PHI .MEM_29(12), .MEM_33(13)
# addr.1_21 = PHI addr.1_26(12), addr.1_31(13)
L7:
# VUSE .MEM_20
_6 = MEM[(intD.9 * * {ref-all})addr.1_21];
;;succ: 15 (FALLTHRU)
;; basic block 15, loop depth 0, count 0, freq 0, maybe hot
;;prev block 14, next block 3, flags: (NEW)
;;pred: 14 (FALLTHRU)
;;succ: 7 (EH)
;;3 (FALLTHRU)
...
Before the expansion, the ifn_va_arg is the statement that could throw:
...
(gdb) call debug_bb_n (2)
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;; prev block 0, next block 3, flags: (NEW, REACHABLE)
;; pred: ENTRY (FALLTHRU)
[LP 1] # .MEM_5 = VDEF .MEM_4(D)
# USE = anything
# CLB = anything
_6 = VA_ARG (cD.2333, 0B);
;; succ: 7 (EH)
;; 3 (FALLTHRU)
$1 = (basic_block_def *) 0x764ae270
(gdb) call stmt_could_throw_p ( last_stmt ($1 ) )
$3 = true
...
But the last statement before bb15 cannot throw:
...
(gdb) call debug_bb_n (14)
;; basic block 14, loop depth 0, count 0, freq 0, maybe hot
;; prev block 13, next block 15, flags: (NEW)
;; pred: 12 (FALLTHRU)
;; 13 (FALLTHRU)
# .MEM_20 = PHI .MEM_29(12), .MEM_33(13)
# addr.1_21 = PHI addr.1_26(12), addr.1_31(13)
L7:
# VUSE .MEM_20
_6 = MEM[(intD.9 * * {ref-all})addr.1_21];
;; succ: 15 (FALLTHRU)
$4 = (basic_block_def *) 0x764aea90
(gdb) call stmt_could_throw_p ( last_stmt ($4 ) )
$5 = false
...
So it does not seem to be just a question of removing the last empty bb.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #3 from vries at gcc dot gnu.org --- This patch allows the example to pass: ... diff --git a/gcc/passes.def b/gcc/passes.def index ffa63b5..041197c 100644 --- a/gcc/passes.def +++ b/gcc/passes.def @@ -344,7 +344,6 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_tm_edges); POP_INSERT_PASSES () NEXT_PASS (pass_vtable_verify); - NEXT_PASS (pass_lower_vaarg); NEXT_PASS (pass_lower_vector); NEXT_PASS (pass_lower_complex_O0); NEXT_PASS (pass_asan_O0); @@ -352,6 +351,7 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_sanopt); NEXT_PASS (pass_cleanup_eh); NEXT_PASS (pass_lower_resx); + NEXT_PASS (pass_lower_vaarg); NEXT_PASS (pass_nrv); NEXT_PASS (pass_cleanup_cfg_post_optimizing); NEXT_PASS (pass_warn_function_noreturn); ... I have no knowledge of the exception handling implementation, so: 1. a proper root cause analysis would take me some time. 2. I have no idea whether the patch is actually correct. I'll try a bootstrap and reg-test though, that'll gives us at least more information.
[Bug rtl-optimization/65805] [5/6 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #3) It is clearer to see the issue if one compiles the whole file with -fno-lra-remat: markus@x4 Release % g++ -S -fno-lra-remat -fPIC -fvisibility=hidden -pthread -march=x86-64 -O2 -fno-exceptions -fno-rtti -std=gnu++11 -Wall -c file_util.ii -o out_good markus@x4 Release % g++ -S -fPIC -fvisibility=hidden -pthread -march=x86-64 -O2 -fno-exceptions -fno-rtti -std=gnu++11 -Wall -c file_util.ii -o out_bad markus@x4 Release % diff -u out_good out_bad ... @@ -4616,7 +4616,7 @@ pushq %rbp .cfi_def_cfa_offset 128 movl20(%rsp), %edx - movq24(%rsp), %rdi + leaq64(%rsp), %rdi call _ZN10extensions9Extension6CreateERKN4base8FilePathENS_8Manifest8LocationERKNS 1_15DictionaryValueEiRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPS F_@PLT movq32(%rsp), %r13 popq%rax When I change leaq 64(%rsp), %rdi back to movq 24(%rsp), %rdi chromium runs fine. Thanks. I reproduced the bug and started to work on it. The problem is in rematerialization when FP-SP offset is different at points of original insn and rematerialized insn. I hope the patch will be ready tomorrow.
[Bug libstdc++/65806] New: NetBSD's stdint.h expects __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65806 Bug ID: 65806 Summary: NetBSD's stdint.h expects __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Host: *-*-netbsd5.1 Target: *-*-netbsd5.1 Build: *-*-netbsd5.1 Contrary to the requirements of the C++ standard, stdint.h on NetBSD 5.1 only defines its helper macros conditionally: #if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS) #include machine/int_limits.h #endif #if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS) #include machine/int_const.h #endif This causes lots of test failures like: /home/jwakely/src/gcc/libstdc++-v3/include/ext/random.tcc:69:52: error: 'UINT32_C' was not declared in this scope Maybe we should make bits/c++config.h define those macros for targets that incorrectly think they are required.
[Bug target/65810] powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #3 from Alan Modra amodra at gmail dot com --- amodra@bns:~/build/gcc-5-virgin gcc/gfortran -v Using built-in specs. COLLECT_GCC=gcc/gfortran Target: powerpc64-linux Configured with: /home/amodra/src/gcc-5-virgin/configure --build=powerpc64-linux --with-cpu=power7 --disable-nls --enable-__cxa_atexit --enable-secureplt --with-long-double-128 --enable-gnu-indirect-function --enable-languages=all,go --enable-lto Thread model: posix gcc version 5.0.1 20150416 (prerelease) (GCC)
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added Attachment #35196|0 |1 is obsolete|| Attachment #35308|0 |1 is obsolete|| --- Comment #9 from Martin Sebor msebor at gcc dot gnu.org --- Created attachment 35360 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35360action=edit Proposed patch. The attached patch resolves all the Address Sanitizer test suite failures on powerpc64 except for those that are subject to pr65643. Tested on powerpc64*-*-*-* and x86_64.
[Bug target/65810] powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Could you post the output of: gfortran -v so we can confirm the version number. I am not seeing it show up on any of the automatic testers. I tried to access the Power7 machine I usually use and can't get in (comm problems).
[Bug target/65810] powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #2 from Peter Bergner bergner at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #1) I am not seeing it show up on any of the automatic testers. I tried to access the Power7 machine I usually use and can't get in (comm problems). There is the gcc110 GCC compiler farm power7 system.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- This changed with Paolo's r213776. These examples suggest that the change to constant handling WRT -Wnarrowing was a mistake.
[Bug target/65810] powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-20 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #4 from Alan Modra amodra at gmail dot com --- Here's the bad code 0x0fffb7f6c438 write_float+3736:addis r9,r2,-2 0x0fffb7f6c43c write_float+3740:li r27,0 0x0fffb7f6c440 write_float+3744:lfd f24,32760(r9) 0x0fffb7f6c444 write_float+3748:lfd f25,-32768(r9) It's from write_float.def:888 r *= 10; so is supposed to be loading up 10.0L but instead gets a completely bogus low double as seen in d below. __gcc_qmul (a=1, b=0, c=10, d=-7.3968712249802237e+209) So not something odd in libgfortran.. Hmm p/x $r2 $31 = 0xfffb7fa1bd8 So, gcc emits toc sections with alignment of 8 bytes, which the linker respects, leading to a toc pointer (r2) that can only be assumed to be 8 byte aligned. This completely breaks rs6000.c:offsettable_ok_by_alignment. My bug. Short term fix will be to limit offsettable_ok_by_alignment to 8 byte alignment. Longer term, modify the linker to increase r2 alignment.
[Bug target/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-19 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Confirmed. ==22109== Invalid read of size 8 ==22109==at 0x1026F524: lookup_page_table_entry (ggc-page.c:659) ==22109==by 0x1026F524: ggc_set_mark(void const*) (ggc-page.c:1540) ==22109==by 0x10390DB7: gt_ggc_mx_addr_table_entry_struct(void*) (gt-dwarf2out.h:515) ==22109==by 0x103904C7: gt_ggc_mxdw_attr_struct (vec.h:1098) ==22109==by 0x103904C7: gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) (gt-dwarf2out.h:288) ==22109==by 0x103905A7: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:594) ==22109==by 0x103905C7: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:596) ==22109==by 0x1015F84B: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:466) ==22109==by 0x1015E94F: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:540) ==22109==by 0x1015F45F: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:454) ==22109==by 0x1015E94F: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:540) ==22109==by 0x1015F44F: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:453) ==22109==by 0x1015F42F: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:451) ==22109==by 0x1015EA5F: gt_ggc_mx_lang_tree_node(void*) (gt-c-c-decl.h:275) ==22109== Address 0x8 is not stack'd, malloc'd or (recently) free'd
[Bug target/65807] New: [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 Bug ID: 65807 Summary: [5 Regression] ICE () on powerpc64le-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 35358 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35358action=edit preprocessed source seen with r222064 on powerpc64le-linux-gnu. trying to reduce using creduce 2.2.1, creduce expands the file to 230% instead of reducing. $ gcc -g -O -Wformat -Werror=format-security -Wall -Wextra -c stress-cpu.i stress-cpu.c: In function 'stress_cpu_int8': stress-cpu.c:772:1: internal compiler error: Segmentation fault stress_cpu_int(uint8_t, 8, \ ^ 0x10816cb3 crash_signal ../../src/gcc/toplev.c:383 0x102a9fb4 lookup_page_table_entry ../../src/gcc/ggc-page.c:659 0x102a9fb4 ggc_set_mark(void const*) ../../src/gcc/ggc-page.c:1540 0x103cae37 gt_ggc_mx_addr_table_entry_struct(void*) ./gt-dwarf2out.h:515 0x103cb13b gt_ggc_mx(dw_attr_struct) ./gt-dwarf2out.h:296 0x103ca537 void gt_ggc_mxdw_attr_struct(vecdw_attr_struct, va_gc, vl_embed*) ../../src/gcc/vec.h:1098 0x103ca537 gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) ./gt-dwarf2out.h:288 0x103ca5f7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:594 0x103ca617 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:596 0x103ca537 void gt_ggc_mxdw_attr_struct(vecdw_attr_struct, va_gc, vl_embed*) ../../src/gcc/vec.h:1098 0x103ca537 gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) ./gt-dwarf2out.h:288 0x103ca5f7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:594 0x103beae7 ggc_hasherdie_struct*::ggc_mx(die_struct*) ../../src/gcc/hash-table.h:321 0x103beae7 gt_ggc_mxblock_die_hasher ../../src/gcc/hash-table.h:1712 0x103beae7 gt_ggc_mx_hash_table_decl_die_hasher_(void*) ./gt-dwarf2out.h:244 0x104da947 ggc_mark_root_tab ../../src/gcc/ggc-common.c:81 0x104dac83 ggc_mark_roots() ../../src/gcc/ggc-common.c:98 0x102aa9a7 ggc_collect() ../../src/gcc/ggc-page.c:2199 Please submit a full bug report, with preprocessed source if appropriate. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/5/lto-wrapper Target: powerpc64le-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.1~rc1-0ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-ppc64el --with-arch-directory=ppc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8 --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=yes --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu Thread model: posix gcc version 5.0.1 20150419 (prerelease) [gcc-5-branch revision 222064] (Ubuntu 5.1~rc1-0ubuntu12)
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Bill Schmidt wschmidt at gcc dot gnu.org --- Work is complete.
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 --- Comment #11 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Sun Apr 19 16:53:22 2015 New Revision: 22 URL: https://gcc.gnu.org/viewcvs?rev=22root=gccview=rev Log: [gcc] 2015-04-18 Bill Schmidt wschm...@linux.vnet.ibm.com Jakub Jelinek ja...@redhat.com Backport from mainline r05 2015-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com Jakub Jelinek ja...@redhat.com PR target/65787 * config/rs6000/rs6000.c (rtx_is_swappable_p): Ensure that a subsequent SH_NONE operand does not overwrite an existing *special value. (adjust_extract): Handle case where a vec_extract operation is wrapped in a PARALLEL. [gcc/testsuite] 2015-04-18 Bill Schmidt wschm...@linux.vnet.ibm.com Backport from mainline r05 2015-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/65787 * gcc.target/powerpc/pr65787.c: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr65787.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/65806] NetBSD's stdint.h expects __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65806 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- It's fixed in NetBSD 7: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/stdint.h?rev=1.7content-type=text/x-cvsweb-markuponly_with_tag=MAIN
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 --- Comment #10 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Sun Apr 19 16:51:12 2015 New Revision: 21 URL: https://gcc.gnu.org/viewcvs?rev=21root=gccview=rev Log: [gcc] 2015-04-18 Bill Schmidt wschm...@linux.vnet.ibm.com Jakub Jelinek ja...@redhat.com Backport from mainline r05 2015-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com Jakub Jelinek ja...@redhat.com PR target/65787 * config/rs6000/rs6000.c (rtx_is_swappable_p): Ensure that a subsequent SH_NONE operand does not overwrite an existing *special value. (adjust_extract): Handle case where a vec_extract operation is wrapped in a PARALLEL. [gcc/testsuite] 2015-04-18 Bill Schmidt wschm...@linux.vnet.ibm.com Backport from mainline r05 2015-04-17 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/65787 * gcc.target/powerpc/pr65787.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr65787.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
