[Bug lto/91078] [10 regression] All LTO tests FAIL: SIGBUS in lto1 (lto_file_finalize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Liška --- I've just sent a patch to ML: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00330.html
[Bug tree-optimization/91063] [10 Regression] ICE in set_vinfo_for_stmt, at tree-vectorizer.c:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91063 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Jul 4 07:25:28 2019 New Revision: 273041 URL: https://gcc.gnu.org/viewcvs?rev=273041&root=gcc&view=rev Log: PR tree-optimization/91063 * tree-vect-stmts.c (vect_init_vector): Call gsi_remove to remove stmt from stmts sequence before calling vect_init_vector_1. Formatting fix. * gcc.dg/gomp/pr91063.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr91063.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #28 from Thomas Koenig --- (In reply to Jerry DeLisle from comment #27) > (In reply to Thomas Koenig from comment #26) > > Jerry, you are working on a Linux box, right? What does > > > > stat -f -c %b . > > > > tell you? > > 13429330 So we cannot really take the values from the file system for the buffer size at face value, at least not for determining the buffer size for this particular case. Last question (grasping at straws here): Are the values from comment #24 reproducible, do you always get this big jump for block size 6553? If they are indeed reproducible, I would suggest using an approach slightly modified from the attached patch: For formatted files, chose the value that the user supplied via an environment variable, or 8192 otherwise. (Formatted is so slow that we might as well save the memory). For formatted files, chose the value that the user supplied via an environment variable. If the user supplied nothing, then - query the recommended block size via calling fstat and evaluating st_blksize. - If st_blksize is less than 8192, use 8192 (current behavior) - if st_blksize is more than 32768, use 32768 - otherwise use st_blksize How does that sound?
[Bug tree-optimization/91063] [10 Regression] ICE in set_vinfo_for_stmt, at tree-vectorizer.c:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91063 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/91074] [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Hopefully fixed.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8/9/10 Regression] g++ |[7/8/9 Regression] g++ ICE |ICE in convert_move, at |in convert_move, at |expr.c:218 on i686 and |expr.c:218 on i686 and |s390x |s390x --- Comment #13 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug c++/91082] Reference to function binds to pointer to function when given a template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91082 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-04 Ever confirmed|0 |1
[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
ygal klein changed:
What|Removed |Added
CC||ygalklein at gmail dot com
--- Comment #4 from ygal klein ---
The following code presents a difference (!) between gfortran 8.2 and gfortran
9.1:
program test
implicit none
integer, parameter :: length = 2
real(8), dimension(length) :: a, b
integer :: i
type point
real(8) :: x
end type point
type points
type(point), dimension(:), pointer :: np=>null()
end type points
type stored
integer :: l
type(points), pointer :: nfpoint=>null()
end type stored
type(stored), dimension(:), pointer :: std=>null()
allocate(std(1))
allocate(std(1)%nfpoint)
allocate(std(1)%nfpoint%np(length))
std(1)%nfpoint%np(1)%x = 0.3d0
std(1)%nfpoint%np(2)%x = 0.3555d0
do i = 1, length
write(*, "('std(1)%nfpoint%np(',i1,')%x = ',1e22.14)") i,
std(1)%nfpoint%np(i)%x
end do
do i = 1, length
write(*, "('std(1)%nfpoint%np(1:',i1,')%x = ',2e22.14)") i,
std(1)%nfpoint%np(1:i)%x
end do
a = std(1)%nfpoint%np(1:2)%x
b = [std(1)%nfpoint%np(1)%x, std(1)%nfpoint%np(2)%x]
if (norm2(a - b) .gt. 1d-3) then
write(*,*) 'failure'
else
write(*, *) 'success'
end if
end program test
Running with gfortan-8.2 results with 'success' and running with gfortran-9.1
results with 'failure'.
Removing the integer variable 'l' from the type 'stored' makes both versions
(8.2 and 9.1) end with 'success'
Thanks.
[Bug c++/91006] [10 Regression] Several test suite fails on *darwin* after r272618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91006 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #7 from Martin Jambor --- (In reply to Jan Hubicka from comment #2) > Martin, > I also guess an interesting question is why extra MEM_REF prevents > ipa-sra from considering the function argument dead? > I'm not entirely sure I understand the question correctly but if you're asking why A::A and A::~A are left untouched in testsuite/g++.dg/opt/flifetime-dse2.C (on x86_64-linux), that is because they are not local (the eipa_sra dump even says so). On a related note, I believe that new IPA-SRA with -flto would also remove them. It should not be terribly difficult to move/copy clobbers from a single predecessor of the exit BB to the caller though.
[Bug c++/91083] New: inconsistent -Wsign-compare warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91083
Bug ID: 91083
Summary: inconsistent -Wsign-compare warnings
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: karol.wozniak at linuxmail dot org
Target Milestone: ---
following code sample
template
struct numeric_limits;
template<>
struct numeric_limits
{
static constexpr long
max() noexcept { return 0x7fffL; }
};
int main() {
return 42ul > numeric_limits::max();
}
compiled with: g++-9 prog.cc -Wall -Wextra
raises sign-compare warning (https://wandbox.org/permlink/zW28qdCjM3hHPtMd)
but...
- adding optimization: g++-9 prog.cc -Wall -Wextra -O2 -march=native
removes the warning (https://wandbox.org/permlink/Z0GpP3JvunbpKqwO)
- creating helper value to store numeric_limit turns on warning once again in
optimized code (https://wandbox.org/permlink/94s4PEuJLlhKviye)
int main() {
auto m = numeric_limits::max();
return 42ul > m;
}
- making helper value const... removes warning
(https://wandbox.org/permlink/Z0GpP3JvunbpKqwO)
warning was not raised in gcc-8 (https://wandbox.org/permlink/3yKmF2OVJ3FBIPye)
[Bug middle-end/90899] [8/9/10 Regression] ICE in add_to_same_comdat_group, at symtab.c:459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90899 --- Comment #5 from Martin Liška --- Author: marxin Date: Thu Jul 4 09:03:40 2019 New Revision: 273073 URL: https://gcc.gnu.org/viewcvs?rev=273073&root=gcc&view=rev Log: Backport r272992 2019-07-04 Martin Liska Backport from mainline 2019-07-03 Martin Liska PR middle-end/90899 * multiple_target.c (create_dispatcher_calls): Add to comdat group only if set for ifunc. 2019-07-04 Martin Liska Backport from mainline 2019-07-03 Martin Liska PR middle-end/90899 * gcc.target/i386/pr90899.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr90899.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/multiple_target.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892 --- Comment #6 from Martin Liška --- Author: marxin Date: Thu Jul 4 09:03:56 2019 New Revision: 273074 URL: https://gcc.gnu.org/viewcvs?rev=273074&root=gcc&view=rev Log: Backport r272993 2019-07-04 Martin Liska Backport from mainline 2019-07-03 Martin Liska PR tree-optimization/90892 * builtins.c (inline_expand_builtin_string_cmp): Handle '\0' in string constants. 2019-07-04 Martin Liska Backport from mainline 2019-07-03 Martin Liska PR tree-optimization/90892 * gcc.dg/pr90892.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr90892.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/builtins.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.1.1 Resolution|--- |FIXED Known to fail|9.1.0 | --- Comment #7 from Martin Liška --- Fixed on all active branches.
[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 --- Comment #2 from Segher Boessenkool --- Currently full lower_subreg runs only after the first splitter pass. This is much too late to be effective for this testcase. Running it before combine (I put it immediately after loop2) works, for all powerpc configs (32/64, BE/LE, old and new ABI). It will need more thorough testing, of course. It also should probably be configurable when the full lower_subreg patch is run (you cannot run it twice, that generate worse code), I think some ports want it as late as it is currently?
[Bug other/91084] New: download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 Bug ID: 91084 Summary: download_prerequisites fails on OpenBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- It fails with sha512sum: not found (This can be tested on gcc220.fsffrance.org at the moment).
[Bug middle-end/90899] [8/9/10 Regression] ICE in add_to_same_comdat_group, at symtab.c:459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90899 --- Comment #6 from Martin Liška --- Author: marxin Date: Thu Jul 4 09:24:32 2019 New Revision: 273075 URL: https://gcc.gnu.org/viewcvs?rev=273075&root=gcc&view=rev Log: Backport r272992 2019-07-04 Martin Liska Backport from mainline 2019-07-03 Martin Liska PR middle-end/90899 * multiple_target.c (create_dispatcher_calls): Add to comdat group only if set for ifunc. 2019-07-04 Martin Liska Backport from mainline 2019-07-03 Martin Liska PR middle-end/90899 * gcc.target/i386/pr90899.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr90899.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/multiple_target.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/90899] [8/9/10 Regression] ICE in add_to_same_comdat_group, at symtab.c:459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90899 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED Known to fail|8.3.0 | --- Comment #7 from Martin Liška --- Fixed on all active branches.
[Bug other/91085] New: fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
Bug ID: 91085
Summary: fixincludes breaks
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target Milestone: ---
Target: *-*-linux*
fixincludes applies a bad change to from glibc 2.30.
@@ -26,7 +35,7 @@
/* Use "" to work around incorrect macro expansion of the
__has_include argument (GCC PR 80005). */
-#if __glibc_has_include ("linux/stat.h")
+#if __glibc_has_include ("__linux__/stat.h")
# include "linux/stat.h"
# ifdef STATX_TYPE
# define __statx_timestamp_defined 1
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #14 from Mike Hommey --- If I apply the patch on 6.4, I'm getting a different ICE: internal compiler error: in emit_block_move_hints, at expr.c:1099 [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - static void exec_ops(const Op* ops, const void** args, [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - ^~~~ [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - 0x8d20b5 emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods, unsigned int, long, unsigned long, unsigned long, unsigned long) [task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/expr.c:1099 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0x8d210f emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods) [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/expr.c:1158 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 emit_partition_copy [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:220 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 insert_part_to_rtx_on_edge [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:388 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 elim_create [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:702 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 eliminate_phi [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:760 [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - 0xbad521 expand_phi_nodes(ssaexpand*) [task 2019-07-04T09:48:09.108Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/tree-outof-ssa.c:937 [task 2019-07-04T09:48:09.109Z] 09:48:09 INFO - 0x7fedb9 execute [task 2019-07-04T09:48:09.109Z] 09:48:09 INFO - ../../gcc-6.4.0/gcc/cfgexpand.c:6317
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.2
[Bug tree-optimization/91074] [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #15 from Jakub Jelinek --- 6.x isn't supported, you are on your own. That said, possible related changes that I remember include e.g. PR90139 and PR78643.
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 Richard Biener changed: What|Removed |Added Host||openbsd --- Comment #1 from Richard Biener --- case $OS in "Darwin"|"FreeBSD"|"DragonFly") chksum='shasum -a 512 --check' ;; *) chksum='sha512sum -c' ;; esac probably OpenBSD needs similar treatment?
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 --- Comment #2 from Jonathan Wakely --- I already suggested that on the cfarm list. Thomas, it would be helpful if you could try that.
[Bug lto/91078] [10 regression] All LTO tests FAIL: SIGBUS in lto1 (lto_file_finalize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078 --- Comment #4 from Martin Liška --- Author: marxin Date: Thu Jul 4 11:38:28 2019 New Revision: 273077 URL: https://gcc.gnu.org/viewcvs?rev=273077&root=gcc&view=rev Log: Fix loading of lto_section on strict alignment targets (PR lto/91078). 2019-07-04 Martin Liska PR lto/91078 * lto-common.c (lto_file_finalize): Use memcpy to set file_data->lto_section_header. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-common.c
[Bug lto/91078] [10 regression] All LTO tests FAIL: SIGBUS in lto1 (lto_file_finalize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #8 from Alan Modra --- Created attachment 46555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46555&action=edit assembler command line fixes I'll happily handle the assembler command line problems. Here's a lightly tested patch.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #9 from Alan Modra --- Created attachment 46556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46556&action=edit more assembler command line fixes Another one for targets that default to altivec.
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 --- Comment #11 from Martin Liška --- (In reply to Martin Jambor from comment #10) > Created attachment 46544 [details] > WIP patch > > I have written another patch that removes the edges from the vector at > the time speculation is resolved rather than preventing creation of > the edges in the first place. > > Unfortunately, the patch still trips over the added assert when LTO > bootstrapping D. So we'll have to look into it and find out where the > edges get deleted other than in check_speculations before figuring out > whether this is the right approach or not. Life cycle for edge->callee is: Hardware watchpoint 5: *$2 Old value = New value = symbol_table::create_edge (this=0x7733a100, caller=, callee=, call_stmt=0x0, count=..., indir_unknown_callee=true) at ../../gcc/cgraph.c:867 867 edge->prev_caller = NULL; (gdb) bt #0 symbol_table::create_edge (this=0x7733a100, caller=, callee=, call_stmt=0x0, count=..., indir_unknown_callee=true) at ../../gcc/cgraph.c:867 #1 0x009d0a32 in cgraph_node::create_indirect_edge (this=, call_stmt=0x0, ecf_flags=0, count=..., compute_indirect_info=false) at ../../gcc/cgraph.c:955 #2 0x009ecf92 in cgraph_edge::clone (this= -> )>, n=, call_stmt=0x0, stmt_uid=4, num=..., den=..., update_original=true) at ../../gcc/cgraphclones.c:113 #3 0x009ee828 in cgraph_node::create_clone (this=, new_decl=, prof_count=..., update_original=true, redirect_callers=..., call_duplication_hook=true, new_inlined_to=, args_to_skip=0x0, suffix=0x0) at ../../gcc/cgraphclones.c:502 #4 0x01eb48ea in clone_inlined_nodes (e= -> )>, duplicate=true, update_original=true, overall_size=0x3233d30 <_ZL12overall_size>) at ../../gcc/ipa-inline-transform.c:221 #5 0x01eb4996 in clone_inlined_nodes (e= -> )>, duplicate=true, update_original=true, overall_size=0x3233d30 <_ZL12overall_size>) at ../../gcc/ipa-inline-transform.c:236 #6 0x01eb4996 in clone_inlined_nodes ( e= -> )>, duplicate=true, update_original=true, overall_size=0x3233d30 <_ZL12overall_size>) at ../../gcc/ipa-inline-transform.c:236 #7 0x01eb4996 in clone_inlined_nodes ( e= -> )>, duplicate=true, update_original=true, overall_size=0x3233d30 <_ZL12overall_size>) at ../../gcc/ipa-inline-transform.c:236 #8 0x01eb4996 in clone_inlined_nodes (e= -> )>, duplicate=true, update_original=true, overall_size=0x3233d30 <_ZL12overall_size>) at ../../gcc/ipa-inline-transform.c:236 #9 0x01eb4996 in clone_inlined_nodes (e= -> )>, duplicate=true, update_original=true, overall_size=0x3233d30 <_ZL12overall_size>) at ../../gcc/ipa-inline-transform.c:236 #10 0x01eb55f3 in inline_call (e= -> )>, update_original=true, Python Exception There is no member or method named m_vecpfx.: new_edges=0x7fffdad0, overall_size=0x3233d30 <_ZL12overall_size>, update_overall_summary=true, callee_removed=0x0) at ../../gcc/ipa-inline-transform.c:477 #11 0x01ea6a68 in inline_small_functions () at ../../gcc/ipa-inline.c:2085 #12 0x01ea85c0 in ipa_inline () at ../../gcc/ipa-inline.c:2547 #13 0x01ea945f in (anonymous namespace)::pass_ipa_inline::execute (this=0x32978f0) at ../../gcc/ipa-inline.c:2955 #14 0x00f0ddff in execute_one_pass (pass=) at ../../gcc/passes.c:2473 #15 0x00f0ed7a in execute_ipa_pass_list (pass=) at ../../gcc/passes.c:2913 #16 0x008cbf7a in do_whole_program_analysis () at ../../gcc/lto/lto.c:456 #17 0x008cc2a6 in lto_main () at ../../gcc/lto/lto.c:628 #18 0x01073ff8 in compile_file () at ../../gcc/toplev.c:456 #19 0x01076c7a in do_compile () at ../../gcc/toplev.c:2209 #20 0x01076f5a in toplev::main (this=0x7fffdf90, argc=1068, argv=0x3267250) at ../../gcc/toplev.c:2344 #21 0x01fd06b9 in main (argc=30, argv=0x7fffe098) at ../../gcc/main.c:39 (gdb) c Continuing. Hardware watchpoint 5: *$2 Old value = New value = cgraph_edge::set_callee (this= -> )>, n=) at ../../gcc/cgraph.h:3140 3140} (gdb) bt #0 cgraph_edge::set_callee (this= -> )>, n=) at ../../gcc/cgraph.h:3140 #1 0x009d15c4 in cgraph_edge::make_direct (this= -> )>, callee=) at ../../gcc/cgraph.c:1254 #2 0x00d3da66 in ipa_make_edge_direct_to_target (ie= -> )>, target=, speculative=false) at ../../gcc/ipa-prop.c:2977 #3 0x00d3eef6 in try_make_edge_direct_virtual_call (ie= -> )>, jfunc=0x7fffc6ab4468, ctx=...) at ../../gcc/ipa-prop.c:3397 #4 0x00d3f1af in update_indirect_edges_after_inlining (cs= -> )>, node=, Python Exception There is no member or method named m_vecpfx.: new_edges=0x7fffdad0) at ../../gcc/ipa-prop.c:3462 #5 0x00d3f553 in propagate_info_to_inlined_callees (cs= -> )>, node=, Python Exception There is no member or method named m_vecpfx.: new_edges=0x7fffdad0) at ../../gcc/ipa-prop.c:3555 #6 0x00d3f58a in prop
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #32 from dave.anglin at bell dot net --- On 2019-07-03 9:08 p.m., elowe at elowe dot com wrote: > This macro only seems to control whether you use ltoffx or ltoff. > > I can confirm I am using bash, and #define HAVE_AS_LTOFFX_LDXMOV_RELOCS 1 in > gcc/config.h My lack of knowledge about ia64 is showing... A ia64-hpux cross from hppa-linux generates the same failing code for the hello world program. Thus, I don't think this is a bootstrap compiler problem. It should be possible to bisect tree and find the change which broke ia64. gcc -v should show the configure options used to build original working gcc.
[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077 --- Comment #5 from Dominique d'Humieres --- The failure of the test in comment 4 is a different issue, likely caused/exposed by revision r269962.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #16 from Mike Hommey --- Similar ICE with 7.3.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90911, which changed state. Bug 90911 Summary: [10 Regression] 456.hmmer regression with r272239 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90911 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90911] [10 Regression] 456.hmmer regression with r272239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90911 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/90911] [10 Regression] 456.hmmer regression with r272239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90911 --- Comment #3 from Richard Biener --- Author: rguenth Date: Thu Jul 4 13:55:15 2019 New Revision: 273082 URL: https://gcc.gnu.org/viewcvs?rev=273082&root=gcc&view=rev Log: 2019-07-04 Richard Biener PR tree-optimization/90911 * tree-vectorizer.h (_loop_vec_info::scalar_loop_scaling): New field. (LOOP_VINFO_SCALAR_LOOP_SCALING): new. * tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Initialize scalar_loop_scaling. (vect_transform_loop): Scale scalar loop profile if needed. * tree-vect-loop-manip.c (vect_loop_versioning): When re-using the loop copy from if-conversion adjust edge probabilities and scale the vectorized loop body profile, queue the scalar profile for updating after peeling. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug ipa/91062] gcc.dg/ipa/ipa-pta-1.c dump contains garbage when gcc was configured with --enable-checking=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Jul 4 13:56:12 2019 New Revision: 273083 URL: https://gcc.gnu.org/viewcvs?rev=273083&root=gcc&view=rev Log: 2019-07-04 Richard Biener PR ipa/91062 * tree-pass.h (execute_all_ipa_transforms): Add a flag parameter whether to disable GC collection. * passes.c (execute_one_ipa_transform_pass): Likewise, and honor it. (execute_all_ipa_transforms): Likewise and pass it down. * cgraph.c (cgraph_node::get_body): Do not invoke garbage collection from applying IPA transforms. * cgraphunit.c (cgraph_node::expand): Allow garbage collection from applying IPA transforms. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraphunit.c trunk/gcc/passes.c trunk/gcc/tree-pass.h
[Bug ipa/91062] gcc.dg/ipa/ipa-pta-1.c dump contains garbage when gcc was configured with --enable-checking=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062 Richard Biener changed: What|Removed |Added Known to work||10.0 Known to fail||9.1.0 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/91086] New: std namespace symbols can get their visibility degraded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086
Bug ID: 91086
Summary: std namespace symbols can get their visibility
degraded
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
Created attachment 46557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46557&action=edit
g++ -fPIC -fvisibility=hidden -E t.cpp
gcc version 9.1.1 20190611 [gcc-9-branch revision 272147] (SUSE Linux)
» cat t.cpp
#include
class __attribute__((visibility("hidden"))) H {};
class __attribute__((visibility("default"))) V {};
int main()
{
std::make_shared();
std::make_shared();
}
» g++ -fPIC -shared -fvisibility=hidden -o t.so t.cpp
Observed behavior: The two instances of _Sp_ebo_helper::_S_get have
different visibility.
» nm -C t.so | grep _S_get
582d t std::_Sp_ebo_helper<0, std::allocator,
true>::_S_get(std::_Sp_ebo_helper<0, std::allocator, true>&)
5810 W std::_Sp_ebo_helper<0, std::allocator,
true>::_S_get(std::_Sp_ebo_helper<0, std::allocator, true>&)
Expected behavior: That the two instances of _S_get have same visibility
(either both t or both W)
» nm -C t.so | grep _S_get
582d W std::_Sp_ebo_helper<0, std::allocator,...
5810 W std::_Sp_ebo_helper<0, std::allocator,...
_S_get (t.i:25368) is inside a template struct _Sp_ebo_helper (t.i:25361) which
is inside a "namespace std __attribute__ ((__visibility__ ("default")))"
(t.i:25008), so I would anticipate that the ebo_helper functions are both
global. (Or, if there is a reason I do not see, both local. But never dependent
upon the visibility of a template argument.)
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #29 from David Edelsohn --- > For formatted files, chose the value that the user supplied > via an environment variable. If the user supplied nothing, then > > - query the recommended block size via calling fstat and evaluating > st_blksize. > - If st_blksize is less than 8192, use 8192 (current behavior) > - if st_blksize is more than 32768, use 32768 > - otherwise use st_blksize I assume that you meant UNformatted files. Why are you opposed to the larger 65536 or 131072 as a default? The benefit at that level is reproducible, _even for filesystems with smaller block size_. Why propose another default value that restricts GNU FORTRAN performance when given the opportunity to fix this and make GNU FORTRAN performance look very good "out of the box". Few people will bother to read the documentation to look for environment variables or even realize that unformatted I/O performance is the bottleneck.
[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #14 from Wilco --- (In reply to Jeffrey A. Law from comment #13) > Author: law > Date: Tue Jul 2 23:01:53 2019 > New Revision: 272949 > > URL: https://gcc.gnu.org/viewcvs?rev=272949&root=gcc&view=rev > Log: > PR tree-optimization/90883 > * g++.dg/tree-ssa/pr90883.c: Add -Os. Check dse2 for the > deleted store on some targets. > > Modified: > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/g++.dg/tree-ssa/pr90883.C This test still fails on Arm and AArch64, final code is still inefficient: _Z4slowv: .LFB0: .cfi_startproc sub sp, sp, #16 .cfi_def_cfa_offset 16 mov x1, 0 str wzr, [sp] strhwzr, [sp, 4] strbwzr, [sp, 6] ldr x0, [sp] add sp, sp, 16 .cfi_def_cfa_offset 0 ret
Re: Complaint about webpage
On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote: >On 7/3/19 8:02 PM, Tara Hamilton wrote: >>I’ve just been looking at your website and I came across this webpage: >>... >> >>Unfortunately, when I click the link ‘...’ it redirects me to a payday >>loan site. Every time these links show up in an email message they get archived and amplified for posterity. I wonder if that wasn't the actual intent of the OP given the template-like nature of their messages. A couple showed up to system accounts on sourceware.org too. If this needs to be discussed further then I'd suggest not including the actual links in future followups.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #30 from Thomas Koenig --- > Why are you opposed to the larger 65536 or 131072 as a default? Please look at Jerry's numbers from comment #24. They show a severe regression (for his system) for blocksizes > 32768.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #31 from David Edelsohn --- What is the PAGESIZE on the Ryzen system? On the POWER systems, the PAGESIZE is 64K. Maybe the optimal buffer size (write size) allows the filesystem to perform double-buffering at the PAGESIZE.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #10 from Peter Bergner --- (In reply to Alan Modra from comment #8) > Created attachment 46555 [details] > assembler command line fixes > > I'll happily handle the assembler command line problems. Here's a lightly > tested patch. This fixes the issue Anton was seeing (mentioned offline), correct? So not related to -mdejagnu-cpu=... not affecting the -m assembler option? At least I don;t see how your patches could fix that without touching asm_cpu spec. That bug I know how to fix, but it doubles the size of that table because *all* -mdejagnu-cpu entries in that table have to be able to override all of the -mcpu entries and I'd like to see that table be smaller rather than double in size, so I'm trying to think of a different way to fix it. Ideas welcome! :-) Maybe it would help to have a rs6000_rewrite_cpu function like arm and aarch64 have?
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #32 from David Edelsohn --- If the performance measured by Jerry is hitting limits of the 4 x 32KiB L1 D-Cache of the Ryzen 2500U, then the system has bigger problems than FORTRAN I/O buffer size. What is the target audience / market for GNU FORTRAN? FORTRAN primarily is used for numerically intensive computing and HPC. This issue was discovered through an experiment by an organization that perform huge HPC simulations and inquired about the performance of GNU FORTRAN. I suggest that GNU FORTRAN implement defaults appropriate for HPC systems if it wants to increase adoption in large-scale commercial environments. If we can find some heuristics that allow GNU FORTRAN to distinguish between consumer and commercial systems, that would be ideal.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #33 from Jerry DeLisle --- Well, I am not opposed to it. What we do not want is to pessimize older smaller machines where it does matter a lot. However if Thomas strategy above is adjusted from 32768 to 65536 then out of the box it will work for your system which is the very first one like this we have encountered (it appears unique from my perspective). We are simply trying to strike the balance across a population for which we have a microscopic sample size shown in this PR. We came up with the 8192 before from also a small sample size. I have another machine here where it makes no difference either way and another where it does really good most of the time at 1024 (believe it or not). Thomas approach is an attempt at the heuristic. Now your idea of a page size angle I need to exlore a bit here and see what this thing is doing. I doubt the HPC users are the majority in number but they are certainly highly important. I know many users around here where I am that use gfortran on there office workstations for preliminary testing and development before they go to the big iron to finalize. With the above said, I think your specific needs at 65536 can be satisfied and we do appreciate the data and testing from you. I do wonder if we need to make "Optimizing I/O" a blatently obvious topic right at the TOP of all our documentation on web page as well as docs.
[Bug middle-end/78884] [7/8/9/10] ICE when gimplifying VLA in OpenMP SIMD region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884 Alexander Monakov changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|ICE when gimplifying VLA in |[7/8/9/10] ICE when |OpenMP SIMD region |gimplifying VLA in OpenMP ||SIMD region --- Comment #6 from Alexander Monakov --- (fails the same way on trunk) Let's re-add the regression marker, since an older release properly diagnosed an unsupported construct, while newer releases simply segfault. I am unsure whether OpenMP standard intends private VLAs to be supported in simd regions, or invalid.
[Bug middle-end/78884] [7/8/9/10] ICE when gimplifying VLA in OpenMP SIMD region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884 --- Comment #7 from Jakub Jelinek --- We should accept it, but of course it is completely fine to force not to vectorize it (i.e. force safelen(1)), there is no hope that we'd actually vectorize it at least in the not too distant future.
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 --- Comment #2 from Jan Hubicka --- Hi, the reason is that type "struct C264" has DECL_ASSEMBLER_NAME (TYPE_NAME (type)) set to which makes LTO to consider this type to be C++ type conforming ODR rule. I am not really fluent with d. Does d have something like ODR? If it doesn't then we need to arrange free_lang data to not consider d types to be C++ ODR types. The type seems to not be seen by free lang data which by itself is confusing. Honza
[Bug c++/91086] std namespace symbols can get their visibility degraded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- No. The dependency on the template argument is correct. If another shared library defines a class H with the visibility of hidden and the loader decides to choose the wrong symbol for the shared library then things go bad.
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #3 from Jan Hubicka ---
Hi,
this patch triggers another confusion in ipa-devirt.
It tries to build type inheritnace graph but since D frotnend produces
only functions with DECL_VIRTUAL but no BINFOs and other things it
segfaults eventually.
Working around it makes it to work. So this adds new question why D
frontend needs to set DECL_VIRTUAL?
Honza
Index: tree.c
===
--- tree.c (revision 273084)
+++ tree.c (working copy)
@@ -6140,6 +6142,11 @@ find_decls_types_in_var (varpool_node *v
void
assign_assembler_name_if_needed (tree t)
{
+ /* D frontend sets assembler name of TYPE_DECLs.
+ We later use them to maintain ODR infrmation for C++, but these
+ names are always computed by decl_assembler_name call below. */
+ if (TREE_CODE (t) == TYPE_DECL)
+SET_DECL_ASSEMBLER_NAME (t, NULL);
if (need_assembler_name_p (t))
{
/* When setting DECL_ASSEMBLER_NAME, the C++ mangler may emit
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #11 from Segher Boessenkool --- Such a rewrite function would be great I think. I don't want the -mdejagnu-cpu thing to need any deeper code changes, but this attacks the one problem the simple -mcpu override did not: specs. (I cannot find where these rewrite functions are defined for arm/aarch64, huh.)
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #12 from Segher Boessenkool --- Ah, common/config/aarch64/aarch64-common.c .
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 --- Comment #3 from Thomas Koenig --- ~/trunk $ svn diff contrib/ Index: contrib/download_prerequisites === --- contrib/download_prerequisites (revision 273019) +++ contrib/download_prerequisites (working copy) @@ -50,6 +50,9 @@ "Darwin"|"FreeBSD"|"DragonFly") chksum='shasum -a 512 --check' ;; + "OpenBSD") +chksum="sha512 -c" + ;; *) chksum='sha512sum -c' ;; ~/trunk $ contrib/download_prerequisites (SHA512) gmp-6.1.0.tar.bz2: OK (SHA512) mpfr-3.1.4.tar.bz2: OK (SHA512) mpc-1.0.3.tar.gz: OK (SHA512) isl-0.18.tar.bz2: OK tar: input compressed with bzip2; use the -j option to decompress it error: Cannot extract package from gmp-6.1.0.tar.bz2 *sigh*
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #4 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
--- contrib/download_prerequisites (revision 273019)
+++ contrib/download_prerequisites (working copy)
@@ -45,11 +45,16 @@
verify=1
force=0
OS=$(uname)
+tar=tar
case $OS in
"Darwin"|"FreeBSD"|"DragonFly")
chksum='shasum -a 512 --check'
;;
+ "OpenBSD")
+chksum="sha512 -c"
+tar="tar -j"
+ ;;
*)
chksum='sha512sum -c'
;;
@@ -243,7 +248,7 @@
package="${ar%.tar*}"
if [ ${force} -gt 0 ]; then rm -rf "${directory}/${package}"; fi
[ -e "${directory}/${package}" ]
\
-|| ( cd "${directory}" && tar -xf "${ar}" )
\
+|| ( cd "${directory}" && ${tar} -xf "${ar}" )
\
|| die "Cannot extract package from ${ar}"
unset package
done
~/trunk $ contrib/download_prerequisites
(SHA512) gmp-6.1.0.tar.bz2: OK
(SHA512) mpfr-3.1.4.tar.bz2: OK
(SHA512) mpc-1.0.3.tar.gz: OK
(SHA512) isl-0.18.tar.bz2: OK
bzip2: (stdin) is not a bzip2 file.
tar: End of archive volume 1 reached
tar: Sorry, unable to determine archive format.
error: Cannot extract package from mpc-1.0.3.tar.gz
Maybe somebody who actually knows a little about BSD utilities
could take it from here.
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #5 from Jonathan Wakely ---
This is not a BSD problem, it's just a case of writing a portable shell script.
This should work:
--- a/contrib/download_prerequisites
+++ b/contrib/download_prerequisites
@@ -241,9 +241,15 @@ unset ar
for ar in $(echo_archives)
do
package="${ar%.tar*}"
+decompress_flag=
+case $ar:$OS in
+ *.tar.gz:OpenBSD) decompress_flag=-z ;;
+ *.tar.bz2:OpenBSD) decompress_flag=-j ;;
+ *:OpenBSD) die "Unknown format: ${ar#*.tar}" ;;
+esac
if [ ${force} -gt 0 ]; then rm -rf "${directory}/${package}"; fi
[ -e "${directory}/${package}" ]
\
-|| ( cd "${directory}" && tar -xf "${ar}" )
\
+|| ( cd "${directory}" && tar $decompress_flag -xf "${ar}" )
\
|| die "Cannot extract package from ${ar}"
unset package
done
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #6 from Jonathan Wakely ---
Or without the overlong line:
--- a/contrib/download_prerequisites
+++ b/contrib/download_prerequisites
@@ -241,9 +241,15 @@ unset ar
for ar in $(echo_archives)
do
package="${ar%.tar*}"
+decompress_flag=
+case $ar:$OS in
+ *.tar.gz:OpenBSD) decompress_flag=-z ;;
+ *.tar.bz2:OpenBSD) decompress_flag=-j ;;
+ *:OpenBSD) die "Unknown format: ${ar#*.tar}" ;;
+esac
if [ ${force} -gt 0 ]; then rm -rf "${directory}/${package}"; fi
[ -e "${directory}/${package}" ]
\
-|| ( cd "${directory}" && tar -xf "${ar}" )
\
+|| ( cd "${directory}" && tar $decompress_flag -xf "${ar}" )
\
|| die "Cannot extract package from ${ar}"
unset package
done
[Bug other/91084] download_prerequisites fails on OpenBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 --- Comment #7 from Jonathan Wakely --- Or you could always just download the packages and untar them by hand. The script isn't mandatory, it's just a convenience.
[Bug middle-end/78884] [7/8/9/10] ICE when gimplifying VLA in OpenMP SIMD region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 46558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46558&action=edit gcc10-pr78884.patch Untested fix.
[Bug gcov-profile/91087] New: g++.dg/gcov/pr16855.C fails everywhere on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087 Bug ID: 91087 Summary: g++.dg/gcov/pr16855.C fails everywhere on Darwin. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- I don't think the test has ever passed on Darwin. FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 21: is #:should be 1 FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 45: is #:should be 1 (and corresponding fails on other std++ versions) The analysis is this: Darwin *does* run the DTORs, but they run before the profile DTORs, and therefore are not recorded in the output. Darwin does not support contractor priorities (well. not between TUs unless LRTO ins enabled). So two things come into play. 1. The DTOR the c++ class is run before the __attribute__((__destructor__)) ^ See below this is a Darwin ABI issue, I think, not a GCC one. 2. Because Darwin is marked as ! SUPPORTS_INIT_PRIORITY, the CTOR and DTOR priority for the profile are set to default. so we get this: .mod_init_func .long __ZL12ctor_defaultv <<== calls the attribute ctor case. .long __GLOBAL__sub_I_pr16855.C <<== calls __Z41__static_initialization_and_destruction_0ii (which registers the static c++ DTOR onto cxa-atexit.) .long __GLOBAL__sub_I_65535_0_pr16855.C <<== calls gcov_init and this... in constructor(()) In Test::Test >> profile CTOR In main In foo >> profile DTOR in destructor(()) In Test::~Test So it happens that the statics for the first two vars are incremented *and it's not obvious that the profile CTOR hasn't run then* but the DTOR (which writes the output) runs before the static DTORs. = So SysV ABI says: This (SysV spec) is not the current situation on Darwin-based systems, where it appears that the __DATA,__mod_term_.func functions are executed _before_ the ones registered via atexit. I have asked on the Darwin dev list, and directly to the Apple ABI chap if there's a written statement of the ABI for Darwin - posix seems to be silent about the relationship between atexit and other static DTORs. = In the meantime. (a) If the profile code depends on SUPPORTS_INIT_PRIORITY for correct operation, there's no point in setting it to DEFAULT_INIT_PRIORITY for targets that don't support between TUs - we might as well leave it at the intended - and at least it will get correct ordering within one TU. (b) If I do (a) and build the code with -fno-use-cxa-atexit, then Darwin passes the test .. but I need an answer on the formal ABI. ** back in the Darwin9 day, with Apple gcc-4.x, the nesting of CTOR/DTOR was as expected, so I'm not sure
Re: [Bug other/91084] download_prerequisites fails on OpenBSD
On 04.07.2019 12:21, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 > > Richard Biener changed: > >What|Removed |Added > >Host||openbsd > > --- Comment #1 from Richard Biener --- > case $OS in > "Darwin"|"FreeBSD"|"DragonFly") > chksum='shasum -a 512 --check' > ;; > *) > chksum='sha512sum -c' > ;; > esac > > probably OpenBSD needs similar treatment? > This looks strange as shasum seems to be coming from Perl. Please include for NetBSD: "cksum -a SHA512 -c" sha512sum is GNU specific. signature.asc Description: OpenPGP digital signature
[Bug gcov-profile/91087] g++.dg/gcov/pr16855.C fails everywhere on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087 Iain Sandoe changed: What|Removed |Added Keywords||ABI Target||*-*-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-04 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0, 7.4.1, 8.3.1, 9.1.1
[Bug gcov-profile/91087] g++.dg/gcov/pr16855.C fails everywhere on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087 --- Comment #1 from Iain Sandoe --- sorry about the typos. a) I meant to say that priorities would work in the case of single TU or LTO, because that does the same thing. b) the SysV spec says: "Termination functions specified by users via the atexit mechanism must be executed before any termination functions of shared objects.” (I can't find anything in the atexit doc for Posix that makes any such comment, hence the question about the ABI).
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #33 from EML --- Could the problem be with "AS"? Maybe that assembler is technically ok, but AS is generating bad machine code?
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #34 from dave.anglin at bell dot net --- On 2019-07-04 4:43 p.m., elowe at elowe dot com wrote: > Could the problem be with "AS"? > > Maybe that assembler is technically ok, but AS is generating bad machine code? That's easy to check. You can dump the assembler output generated by gcc with "-S" option. I'm pretty sure the faulting gprel instruction is from gcc. You can compare .o files generated by new and working compiles with cmp. You can disassemble .o and executables with "objdump -d". You can link .o file generated with new compiler with old compiler. You can also test using HP and GNU tools. Use "gcc -save-temps -v" to capture intermediate files and commands. I think the issue is more likely with ld than as.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #34 from Thomas Koenig --- There is another point to consider. I suppose not very many people use big-endian data formats these days. Little-endian dominates these days, and people who require that conversion on a regular basis (why does HPC need that, by the way?) are probably few and far between. Another question is if people who do serious HPC work do a lot of stuff (without conversion) like write(10) x(1::2) which would actually use the buffers, instead of write (10) x where the whole buffering discussion does not apply. Jerry, if you use strides in writing, without conversion, what result would you get for different block sizes? If that is reasonably fast, then I am now leaning towards making the default buffer much larger for unformatted. Formatted default can stay as it is (adjustable via environment variable), making the buffers larger there would just be a waste of memory because of the large CPU load in converting floating point numbers (unless somebody can show a reasonable benchmark demonstrating otherwise).
[Bug middle-end/78884] [7/8/9/10] ICE when gimplifying VLA in OpenMP SIMD region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Jul 4 21:41:49 2019 New Revision: 273096 URL: https://gcc.gnu.org/viewcvs?rev=273096&root=gcc&view=rev Log: PR middle-end/78884 * gimplify.c (struct gimplify_omp_ctx): Add add_safelen1 member. (gimplify_bind_expr): If seeing TREE_ADDRESSABLE VLA inside of simd loop body, set ctx->add_safelen1 instead of making it GOVD_PRIVATE. (gimplify_adjust_omp_clauses): Add safelen (1) clause if ctx->add_safelen1 is set. * gcc.dg/gomp/pr78884.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr78884.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #35 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #34) > There is another point to consider. > > I suppose not very many people use big-endian data formats > these days. Little-endian dominates these days, and people > who require that conversion on a regular basis (why does > HPC need that, by the way?) are probably few and far between. > > Another question is if people who do serious HPC work do > a lot of stuff (without conversion) like > > write(10) x(1::2) > > which would actually use the buffers, instead of > > write (10) x > > where the whole buffering discussion does not apply. > > Jerry, if you use strides in writing, without conversion, > what result would you get for different block sizes? > Disregard my previous data. If I run the tests manually outside of the script you provided I get consistent results: $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=1024 ./a.out 2.7986080646514893 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=4096 ./a.out 2.5836510658264160 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=8192 ./a.out 2.5744562149047852 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=16384 ./a.out 2.4813480377197266 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=32768 ./a.out 2.5214788913726807 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=65536 ./a.out 2.4661610126495361 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=131072 ./a.out 2.4065649509429932 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=262144 ./a.out 2.4941890239715576 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=524288 ./a.out 2.3842790126800537 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=1048576 ./a.out 2.4531490802764893 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=2097152 ./a.out 2.5236811637878418 So there is a sweet spot at the 131072 point on this particular machine, so I agree we should be able to go higher (that inconsistency I reported earlier was bugging me enough to experiment and I discovered this, Ryzen 2500U). Strides without conversion: $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=65536 ./a.out 1.8322470188140869 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=65536 ./a.out 1.8337209224700928 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=131072 ./a.out 1.8346250057220459 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=262144 ./a.out 1.8497080802917480 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=524288 ./a.out 1.8243398666381836 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=1048576 ./a.out 1.7886412143707275 $ GFORTRAN_BUFFER_SIZE_UNFORMATTED=2097152 ./a.out 1.8285851478576660 All things considered I would say go for the higher value and the users can set the environment variable lower if they need to.
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #17 from Mike Hommey --- (In reply to Mike Hommey from comment #16) > Similar ICE with 7.3. And 7.4 (and to be clear, this is similar ICE as comment 14)
[Bug libstdc++/78747] Duplicate _S_empty_rep_storage causes crash when STV_HIDDEN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78747
Jan Engelhardt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Jan Engelhardt ---
>So, are version-scripts with local:* basically incompatible with C++?
Answering myself: yes.
Symbols from library headers (inlines, typeinfos) can be spill-duplicated into
one's own program, such is the nature of contemporary C++ compilation.
Due to ODR, linkers need to collapse duplicate symbols. Only ELF global symbols
participate.
-fvisibility=hidden changes the default symbol visibility. A proper library
header therefore declares __attribute__((visibility("default"))) for its
exports; this way, the visibility of those spilled library symbols will stay
correct even if one's program is built with -fvisibility=hidden.
Version scripts however have the power to force-downgrade the visibility of
symbols in one's program, inhibiting the required collapse. So probably avoid
local:* when linking a C++ lib.
[Bug c++/91086] std namespace symbols can get their visibility degraded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086 --- Comment #2 from Jonathan Wakely --- Yes, I think G++ used to not to this, and it was changed to the current behaviour to avoid such problems.
[Bug c++/91086] std namespace symbols can get their visibility degraded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Yes, I think G++ used to not to this, and it was changed to the current > behaviour to avoid such problems. Just to be clear, my "yes" was intended to mean I agree with Andrew's comment. It wasn't a contradiction of his "no" :-)
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #35 from Jim Wilson --- I never had access to ia64 hpux unfortunately. I did ask them for a copy once, but they couldn't figure out why I wanted it, and so they wouldn't give it to me. Steve Ellcey was working for HP at the time and maintaining the ia64-hpux support. You could try asking him. I think the ia64-hpux support was always poor. Too many things done differently than ia64-linux, requiring inconvenient hacks on our side to make our tools work on their system. I don't know if the binutils support was ever usable. The gcc support was usable at one time, but I don't know the details.
Re: Complaint about webpage
On 7/4/19 11:08 PM, Christopher Faylor wrote: On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote: On 7/3/19 8:02 PM, Tara Hamilton wrote: Every time these links show up in an email message they get archived and amplified for posterity. I wonder if that wasn't the actual intent of the OP given the template-like nature of their messages. A couple showed up to system accounts on sourceware.org too. Yes, I mentioned in another thread that this might be an SEO attempt, and that the right solution is to report them as bad actors to the search engines, but I don't know offhand how to do that. Jim
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #36 from dave.anglin at bell dot net --- On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > The non-working .s file does this: > > .LC0: > stringz "Hellos World" > > > > movl r36 = @gprel(.LC0) > ;; > add r36 = r1, r36 It seems to me that the gprel instruction would fault if the gp (r1) isn't properly initialized correctly before main is started.
Re: Complaint about webpage
On 7/5/19 9:24 AM, Jim Wilson wrote: On 7/4/19 11:08 PM, Christopher Faylor wrote: On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote: Yes, I mentioned in another thread that this might be an SEO attempt, and that the right solution is to report them as bad actors to the search engines, but I don't know offhand how to do that. I found the right google page and reported them, pointing at both of the threads that I saw. Jim
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #37 from EML --- I wonder if is this patch is related: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02193.html "Before the patch generated code uses .GOT entry: addl r14 = @ltoffx(a#), r1 ld8.mov r14 = [r14], a# After the patch generated code uses static gprel relocation: movl r14 = @gprel(a#) add r14 = r1, r14 "
[Bug ipa/91088] New: IPA-cp cost evaluation is too conservative for "if (f(param) cmp const_val)" condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91088
Bug ID: 91088
Summary: IPA-cp cost evaluation is too conservative for "if
(f(param) cmp const_val)" condition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Current IPA-cp only detects conditional statement like "if (param cmp
const_val)", and gives a reasonable cost evaluation used in function
versioning. But beyond this form, any generalized form as f(param), a function
on the parameter, which involves extra operations and constant values, will be
conservatively treated, have not use in cost computation.
The following is an example, compiled with "-O3 -fno-inline".
The value "5" is propagated into callee(), for "if (v < 3)", ipa-cp can
deduce that "true branch" will not be executed, and benefit for function
versioning is large. And for "if (v * 2 < 6)", ipa-cp can not handle that, and
conservatively takes cost of "true branch" into account, so get a "no need to
clone function" conclusion.
int foo();
int callee(int v)
{
// if (v < 3) // will make a constprop copy with v = 5
// if (v * 2 < 6) // will no make a constprop copy
{
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
}
else
return 1;
}
int caller()
{
return callee (5);
}
[Bug c++/89976] missing uninitialized warning: laundering via passing object through a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976 --- Comment #1 from Eric Gallager --- could you be a bit more specific about which lines exactly you're expecting the warnings to go on?
[Bug ipa/91089] New: IPA-cp does setup proper cost model for switch default case in function versioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91089
Bug ID: 91089
Summary: IPA-cp does setup proper cost model for switch default
case in function versioning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
IPA-cp always adds execution cost of switch default case into cost evaluation
for other switch case, which might miss opportunities of function versioning
when only certain case is proved to be executed after constant propagation.
The following is an example, compiled with "-O3 -fno-inline".
It is reasonable to make a function versioning for callee when "v=1", but
actually it does not happen. And if we replace "default" with "case = 4",
it clones the function as we expect.
In some situations, we can deduce a relative small execution predicate
for default case. If all switch cases are in a continuous value range, we
can use compare to range low and high bound to mark default switch case.
Additionally, range analysis can also give us more information to simplify
the predicate.
int foo();
int callee(int v)
{
int i = 0;
switch (v)
{
case 1:
i = 3;
break;
case 2:
i = 9;
break;
default:
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
foo();
}
return i;
}
int caller()
{
return callee (1);
}
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #38 from The Written Word --- I rebuilt 8.3.0 with minimal patches and am seeing the same failure as before. From /ia64-hp-hpux11.31/libstdc++-v3/config.log: configure:7964: checking for ANSI C header files configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g conftest.c >&5 configure:7984: $? = 0 configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g conftest.c >&5 configure:8057: $? = 0 configure:8057: ./conftest /opt/build/china/gcc-8.3.0/libstdc++-v3/configure: line 1940: 18830 Segmentation fault (core dumped) ./conftest$ac_exeext If I compile the conftest.c program between gcc-4.9.4 and the 8.3.0 stage 1 compiler: --- gcc-4.9.4/conftest.s 2019-07-05 04:50:23 + +++ /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/conftest.s 2019-07-05 04:50:13 + @@ -27,42 +27,26 @@ ;; ld4 r14 = [r14] ;; - addp4 r14 = 0,r14 - ;; cmp.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L3 addl r14 = @ltoffx(__SB_masks#), r1 ;; ld8.mov r14 = [r14], __SB_masks# ;; ld4 r14 = [r14] - ;; - addp4 r14 = 0,r14 ld4 r15 = [r34] ;; shladd r15 = r15, 2, r0 ;; add r14 = r15, r14 ;; - addp4 r14 = 0,r14 + addp4 r14 = r14, r0 ;; ld4 r14 = [r14] ;; and r14 = 64, r14 ;; cmp4.ne p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L4 br .L5 ;; @@ -73,33 +57,15 @@ mov r14 = r8 ;; cmp4.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L5 .L4: ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 ld4 r14 = [r34] ;; cmp4.lt p6, p7 = 122, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 .L5: addl r14 = @ltoffx(__SB_masks#), r1 @@ -108,42 +74,26 @@ ;; ld4 r14 = [r14] ;; - addp4 r14 = 0,r14 - ;; cmp.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L7 addl r14 = @ltoffx(__SB_masks#), r1 ;; ld8.mov r14 = [r14], __SB_masks# ;; ld4 r14 = [r14] - ;; - addp4 r14 = 0,r14 ld4 r15 = [r34] ;; shladd r15 = r15, 2, r0 ;; add r14 = r15, r14 ;; - addp4 r14 = 0,r14 + addp4 r14 = r14, r0 ;; ld4 r14 = [r14] ;; and r14 = 64, r14 ;; cmp4.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L8 br .L9 ;; @@ -154,33 +104,15 @@ mov r14 = r8 ;; cmp4.ne p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L9 .L8: ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L9 ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 122, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 .L9: ld4 r36 = [r34] @@ -190,22 +122,10 @@ ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L10 ld4 r14 = [r34] ;; cmp4.lt p6, p7 = 122, r14 -
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #39 from The Written Word
---
(In reply to EML from comment #25)
> I have applied the patch and tried your other suggestions, still the stage1
> compiler has the same problems generating executables.
>
> In analyzing the intermediate files between working (gcc 4.93) and not
> (bootstrap 8.3), the intermediate files seem similar until the "mach" stage
>
> The problem seems to be in out the compiler decides to reference a string in
> the source.
>
> My program is:
>
> #include
>
> int main()
> {
> printf("Hellos World\n");
> return 0;
> }
>
> The generated .s file for Working does this:
>
> .LC0:
> stringz "Hellos World"
>
>
>
> addl r36 = @ltoffx(.LC0), r1
> ;;
> ld8.mov r36 = [r36], .LC0
>
> The non-working .s file does this:
>
> .LC0:
> stringz "Hellos World"
>
>
>
> movl r36 = @gprel(.LC0)
> ;;
> add r36 = r1, r36
>
>
> If I replace those 3 lines and run the assembler+linker by hand - the
> non-working foo.s will run correctly
I can now duplicate what you're seeing:
$ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
--- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
@@ -1,5 +1,6 @@
.file "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+ .section.text, "ax", "progbits"
.section.rodata,"a","progbits"
.align 8
.LC0:
@@ -19,9 +20,9 @@
mov r32 = b0
mov r35 = r1
.body
- addl r36 = @ltoffx(.LC0), r1
+ movl r36 = @gprel(.LC0)
;;
- ld8.mov r36 = [r36], .LC0
+ add r36 = r1, r36
br.call.sptk.many b0 = puts#
mov r1 = r35
mov r14 = r0
$ grep LTOFF /gcc/config.status
D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"
[Bug tree-optimization/91090] New: A suspicious code in tree-ssa-dom.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91090
Bug ID: 91090
Summary: A suspicious code in tree-ssa-dom.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
Find code snippet in simplify_stmt_for_jump_threading ():
if (vr->kind () == VR_RANGE)
{
size_t i, j;
find_case_label_range (switch_stmt, vr->min (), vr->max (), &i, &j);
if (i == j)
{
tree label = gimple_switch_label (switch_stmt, i);
tree singleton;
if (CASE_HIGH (label) != NULL_TREE
? (tree_int_cst_compare (CASE_LOW (label), vr->min ()) <= 0
&& tree_int_cst_compare (CASE_HIGH (label), vr->max ()) >=
0)
: (vr->singleton_p (&singleton)
&& tree_int_cst_equal (CASE_LOW (label), singleton)))
return label;
if (i > j)
return gimple_switch_label (switch_stmt, 0);
}
}
The conditional "if (i > j)" should be outside of "if (i == j)"?
[Bug tree-optimization/91091] New: [missed optimization] Missing aliasing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
Bug ID: 91091
Summary: [missed optimization] Missing aliasing optimization
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksey.covacevice at gmail dot com
Target Milestone: ---
Consider the following:
struct s { int x; };
struct t { int x; };
void swap(struct s* p, struct t* q) {
p->x = q->x;
q->x = p->x;
}
Aliasing rules forbid `p` and `q` to point to the same object; yet, GCC 5.4 and
most subsequent versions produce (-O3):
swap(s*, t*):
mov eax, DWORD PTR [rsi]
mov DWORD PTR [rdi], eax
mov DWORD PTR [rsi], eax // Possible alias between p and q
ret
whereas GCC versions 4.5.3 to 5.3 and versions 8.1 to 8.2 correctly produce:
swap(s*, t*):
mov eax, DWORD PTR [rsi]
mov DWORD PTR [rdi], eax
ret
All versions produce the correct code if __restrict__ is used on any pointer.
This behavior can be verified on Godbolt: https://godbolt.org/z/WYMoFI
[Bug ipa/91088] IPA-cp cost evaluation is too conservative for "if (f(param) cmp const_val)" condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91088 --- Comment #1 from Marc Glisse --- I am surprised we don't have a match.pd transformation for v * 2 < 6 with undefined overflow. But that's only a side remark, not important for your report.
[Bug tree-optimization/10980] vararg functions are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980
Alejandro Colomar changed:
What|Removed |Added
CC||colomar.6.4.3 at gmail dot com
--- Comment #13 from Alejandro Colomar ---
static inline void TELL(const char *fmt, ...)
__attribute__((format(printf, 1, 2), always_inline));
static inline void TELL(const char *fmt, ...)
{
va_list ap;
va_start(ap,fmt);
vsyslog(LOG_NOTICE,_(fmt),ap);
va_end(ap);
}
The compiler should be able to see that it is a varargs
function with printf-like format, and that the only reason
for `va_list` to exist is to pass the varargs and not to use
them.
It is trivial to see that an inlined version would be
simplified to a call to `syslog`.
Example:
void foo(void)
{
char *world = "world";
char newline = '\n';
TELL("Hello %s%c%c", world, '!', newline);
}
could be inlined to the following code:
void foo(void)
{
char *world = "world";
char newline = '\n';
syslog(LOG_NOTICE, "Hello %s%c%c", world, '!', newline);
}
The same should happen with `vprintf`->`printf` and all those
families of functions.
