Repeating section names in ELF binary
Hello, we are working on a project to make module debugging for the Linux kernel easier. We want to improve it in such a way that gdb automatically loads the symbols of modules. However, we are facing the following difficulties: gdb needs to know all section of the ELF files. We were told that gcc may produce multiple sections in an ELF binary with the same name (some of them might be empty). This has been observed on the PARISC architecture, however, we were told that it might happen on any architecture when using -ffunction-sections. We could not reproduce it in our tests on x86_64. So, our question is the following: does gcc under any architecture (besides PARISC) produce an ELF binary where the sections' names are not unique? Thanks!
Re: Repeating section names in ELF binary
On Sat, Apr 6, 2013 at 3:09 AM, Sebastian Wankerl sisew...@cip.cs.fau.de wrote: we are working on a project to make module debugging for the Linux kernel easier. We want to improve it in such a way that gdb automatically loads the symbols of modules. However, we are facing the following difficulties: gdb needs to know all section of the ELF files. We were told that gcc may produce multiple sections in an ELF binary with the same name (some of them might be empty). This has been observed on the PARISC architecture, however, we were told that it might happen on any architecture when using -ffunction-sections. We could not reproduce it in our tests on x86_64. So, our question is the following: does gcc under any architecture (besides PARISC) produce an ELF binary where the sections' names are not unique? Why do you care? To care whether there are duplicate section names suggests that you are doing something wrong. That said, since you mention Linux kernel modules I'm guessing that you are looking at objects linked using -r. Offhand I can't think of a way to get duplicate section names after linking with -r, because the linker will tend to agglomerate sections with the same name. Ian
Can -mno-big-switch be removed from the PA port?
Hello,
I'm trying to get to a point where the CFG is useable even in the
delay-slot filling pass (dbr_schedule) and I'm currently stuck on a
transformation that the PA port does if -mno-big-switch is in effect.
With !TARGET_BIG_SWITCH, the PA port explodes a JUMP_TABLE_DATA to
real code, i.e. actual jumps (see the example at the end of this
mail).
The problem is that the new code with the explicit jumps is not inside
a basic block: It's substituted in the place where the JUMP_TABLE_DATA
rtx was. It is important to maintain this exact order of the code
because the casesi0 jump_insn is not a jump to a label but a jump to
an absolute distance measured from the CODE_LABEL before the
JUMP_TABLE_DATA, so the length of the explicit jump_insns must be
constant.
I have no idea how to maintain the CFG and freeze the exploded code
to protect it from being changed by following passes. Having the code
not inside basic blocks breaks verify_flow_info, and hides the insns
that fill the delay slots from the DF machinery and from the analysis
code in sched-deps.c.
Exploding the jump tables only happens with !TARGET_BIG_SWITCH. The
reason to explode the jump table is because it makes the delay slots
of the explicit jump_insns visible to the dbr_schedule pass.
But TARGET_BIG_SWITCH has been the default since GCC 4.0, see
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02401.html
Are there any reasons against removing !TARGET_BIG_SWITCH support? It
would really help if this code can go away...
Ciao!
Steven
from the .expand dump:
(note 317 8 9 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn 9 317 10 4 (set (pc)
(mem:SI (plus:SI (mult:SI (reg:SI 97)
(const_int 4 [0x4]))
(label_ref 10)) [0 S4 A32])) t.c:15 -1
(nil)
- 10)
(code_label 10 9 11 4 [1 uses])
(jump_table_data 11 10 12 (addr_vec:DI [
(label_ref:SI 13)
(label_ref:SI 16)
(label_ref:SI 19)
(label_ref:SI 22)
(label_ref:SI 25)
(label_ref:SI 28)
(label_ref:SI 31)
...
(label_ref:SI 307)
(label_ref:SI 310)
]))
(barrier 12 11 13)
After the machine dependent reorg patch:
(note 317 8 9 [bb 3] NOTE_INSN_BASIC_BLOCK)
(jump_insn 9 317 10 (set (pc)
(mem:SI (plus:SI (mult:SI (reg:SI 26 %r26 [97])
(const_int 4 [0x4]))
(label_ref 10)) [0 S4 A32])) t.c:15 193 {casesi0}
(expr_list:REG_DEAD (reg:SI 26 %r26 [97])
(nil))
- 10)
(code_label 10 9 328 4 [1 uses])
(insn 328 10 329 (const_int 1 [0x1]) 212 {begin_brtab}
(nil))
(code_label 329 328 330 104 [1 uses])
(jump_insn 330 329 331 (parallel [
(set (pc)
(label_ref 13))
(const_int 0 [0])
]) 192 {short_jump}
(nil)
- 13)
(barrier 331 330 332)
(code_label 332 331 333 105 [1 uses])
(jump_insn 333 332 334 (parallel [
(set (pc)
(label_ref 16))
(const_int 0 [0])
]) 192 {short_jump}
(nil)
- 16)
(barrier 334 333 335)
...
(barrier 625 624 626)
(code_label 626 625 627 203 [1 uses])
(jump_insn 627 626 629 (parallel [
(set (pc)
(label_ref 310))
(const_int 0 [0])
]) 192 {short_jump}
(nil)
- 310)
(insn 629 627 628 (const_int 2 [0x2]) 213 {end_brtab}
(nil))
Re: Can -mno-big-switch be removed from the PA port?
On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: Are there any reasons against removing !TARGET_BIG_SWITCH support? It would really help if this code can go away... Yes, branch distances are limited to what can be encoded in a 17-bit pc relative offset. Large code will break with !TARGET_BIG_SWITCH. I think the answer is to move the jump table from the text to read- only data. This would require another instruction or two to load the label for the table. The HP compiler does this. Although this is unclear, I suspect there are situations where what we do now can cause TLB thrash. This occurs on machines with shared instruction and data TLBs. Would this help? Dave -- John David Anglin dave.ang...@bell.net
Re: Compiling gcc473-RC-20130404 with -Wextra
On Sat, Apr 6, 2013 at 6:51 AM, Дилян Палаузов dilyan.palau...@aegee.org wrote: Hello, I compile gcc473-RC-20130404 with CFLAGS='-pipe -O3 -march=native -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 -Wl,-z,relro -flto -Wall -Wextra' ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-threads=posix --enable-nls --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-libunwind --without-x make 2 stderr using gcc472 as compiler. According to my understandings, there shall be no warnings, when gcc is compiled, but there are some (see below). I suggest to release GCC, when compiling it with -Wextra using the previous most recent compiler does not produce any warnings. -Wextra has many controversial warnings, some of them get fixed in future releases. I don't think your proposal is a starter. -- Gaby
Re: Can -mno-big-switch be removed from the PA port?
On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote: On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: Are there any reasons against removing !TARGET_BIG_SWITCH support? It would really help if this code can go away... Yes, branch distances are limited to what can be encoded in a 17-bit pc relative offset. Large code will break with !TARGET_BIG_SWITCH. That would be a reason why !TARGET_BIG_SWITCH *can* go away ;-) TARGET_BIG_SWITCH i.e. -mbig-switch is the default for all hppa targets since your 2004 patch. !TARGET_BIG_SWITCH i.e. -mno-big-switch is not tested in the test suite and probably not used by anymore. And it's the -mno-big-switch that's causing me headaches. Ciao! Steven
Re: Can -mno-big-switch be removed from the PA port?
On 6-Apr-13, at 3:16 PM, Steven Bosscher wrote: On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote: On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: Are there any reasons against removing !TARGET_BIG_SWITCH support? It would really help if this code can go away... Yes, branch distances are limited to what can be encoded in a 17-bit pc relative offset. Large code will break with !TARGET_BIG_SWITCH. That would be a reason why !TARGET_BIG_SWITCH *can* go away ;-) TARGET_BIG_SWITCH i.e. -mbig-switch is the default for all hppa targets since your 2004 patch. !TARGET_BIG_SWITCH i.e. -mno-big-switch is not tested in the test suite and probably not used by anymore. And it's the -mno-big-switch that's causing me headaches. I was mixed up on which option was causing grief. -mno-big-switch can go. Probably, nobody will notice... Dave -- John David Anglin dave.ang...@bell.net
gcc-4.7-20130406 is now available
Snapshot gcc-4.7-20130406 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20130406/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 197545 You'll find: gcc-4.7-20130406.tar.bz2 Complete GCC MD5=f25c0aa9bb428999382a55b01a4e6c72 SHA1=5488ae88954e8e9aa06a256cd9a7452427ab12ab Diffs from 4.7-20130330 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug fortran/56852] [4.6/4.7/4.8/4.9 Regression] ICE on invalid: Bad array reference for an undeclared loop variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56852 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-06 Summary|ICE on invalid: Bad array |[4.6/4.7/4.8/4.9 |reference for an |Regression] ICE on invalid: |undeclared loop variable|Bad array reference for ||an undeclared loop variable Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-04-06 09:33:10 UTC --- Confirmed. Revision 164285 (2010-09-14) gives the error pr56852.f90:5.14: read(0) (a(i),i=1,4) 1 Error: Symbol 'i' at (1) has no IMPLICIT type without ICE. Revision 164728 (2010-09-29) gives the same error plus the ICE program test 1 Internal Error at (1): gfc_variable_attr(): Bad array reference Backtrace for revision 197238 #0 gfc_variable_attr (expr=0x141a141d0, ts=0x0) at ../../_clean/gcc/fortran/primary.c:2135 #1 0x0001000863b0 in gfc_expr_attr (e=value optimized out) at ../../_clean/gcc/fortran/primary.c:2267 #2 0x00010003c5f9 in gfc_check_vardef_context (e=0x141a141d0, pointer=false, alloc_obj=value optimized out, own_scope=value optimized out, context=0x100b3949f item in READ) at ../../_clean/gcc/fortran/expr.c:4706 #3 0x00010009cc2d in resolve_code (code=value optimized out, ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:8150 #4 0x00010009a90c in gfc_resolve_blocks (b=value optimized out, ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:8885 #5 0x00010009adc2 in resolve_code (code=value optimized out, ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:9557 #6 0x00010009a90c in gfc_resolve_blocks (b=value optimized out, ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:8885 #7 0x00010009adc2 in resolve_code (code=value optimized out, ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:9557 #8 0x00010009dab4 in resolve_codes (ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:14411 #9 0x00010008e1bd in gfc_resolve (ns=value optimized out) at ../../_clean/gcc/fortran/resolve.c:14439 #10 0x0001000825db in gfc_parse_file () at ../../_clean/gcc/fortran/parse.c:4399 #11 0x0001000c25c6 in gfc_be_parse_file () at ../../_clean/gcc/fortran/f95-lang.c:189 #12 0x00010076ce94 in compile_file () at ../../_clean/gcc/toplev.c:543 #13 0x00010076ef69 in toplev_main (argc=2, argv=0x7fff5fbfd7c8) at ../../_clean/gcc/toplev.c:1864 #14 0x00019b54 in start (pc=value optimized out, bases=0x0) at ../../../_clean/libgcc/config/unwind-dw2-fde-darwin.c:272
[Bug c++/56854] New: error: non-decl/MEM_REF LHS in clobber statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56854
Bug #: 56854
Summary: error: non-decl/MEM_REF LHS in clobber statement
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com
I just tried to compile the package openlierox-0.59-0.10
on gcc-4.9 trunk dated 20130403 on an AMD x86_64 box.
The compiler said
/home/dcb/rpmbuild/BUILD/OpenLieroX/src/game/Settings.h: In constructor
'FeatureSettingsLayer::FeatureSettingsLayer(const string)':
/home/dcb/rpmbuild/BUILD/OpenLieroX/src/game/Settings.h:49:2: error:
non-decl/MEM_REF LHS in clobber statement
FeatureSettingsLayer(const std::string debug_name_) :
debug_name(debug_name_) { makeSet(false); }
^
MEM[(struct ScriptVar_t *)this_1(D)].settings[_32]
# .MEM_113 = VDEF .MEM_85
MEM[(struct ScriptVar_t *)this_1(D)].settings[_32] ={v} {CLOBBER};
/home/dcb/rpmbuild/BUILD/OpenLieroX/src/game/Settings.h:49:2: internal compiler
error: verify_gimple failed
0xab89f9 verify_gimple_in_cfg(function*)
../../src/trunk/gcc/tree-cfg.c:4769
0x9efe17 execute_function_todo
../../src/trunk/gcc/passes.c:1963
0x9f0807 execute_todo
../../src/trunk/gcc/passes.c:1996
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Preprocessed source code attached. Flag -O2 required.
[Bug c++/56854] error: non-decl/MEM_REF LHS in clobber statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56854 --- Comment #1 from David Binderman dcb314 at hotmail dot com 2013-04-06 09:45:18 UTC --- Created attachment 29813 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29813 gzipped C++ source code
[Bug c/56851] Segmentation Error using -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56851 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-06 09:58:19 UTC --- Some important information was hidden in that attached zip file. First, the target is arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb, with the host being mingw32. Second, the version is wrong; it's not 4.7.0 but ARM/embedded-4_7-branch revision 196615 (I can't tell if it's vanilla or patched). However, I can reproduce the cc1 SEGV in a cross from x86_64-linux to arm-linux-gnueabi with gcc-4.7-20130330: /tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc -mcpu=cortex-m3 -mthumb -O3 -S sensors.i C:\Radio Control\OpenAero32\src\sensors.c: In function 'ACC_getADC': C:\Radio Control\OpenAero32\src\sensors.c:251:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Re-running under gdb shows: Program received signal SIGSEGV, Segmentation fault. 0x007f5baf in rename_use_op (op_p=0x77611330) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:55 55if (TREE_CODE (USE_FROM_PTR (op_p)) != SSA_NAME) Missing separate debuginfos, use: debuginfo-install glibc-2.15-58.fc17.x86_64 (gdb) bt #0 0x007f5baf in rename_use_op (op_p=0x77611330) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:55 #1 rename_variables_in_bb (bb=0x776103a8) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:95 #2 0x007f5bee in rename_variables_in_loop (loop=0x77551440) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:111 #3 0x007155aa in copy_loop_before (loop=0x77551330) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:182 #4 generate_loops_for_partition (copy_p=1 '\001', partition=0x12c4e30, loop=0x77551330) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:216 #5 generate_code_for_partition (copy_p=1 '\001', partition=0x12c4e30, loop=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:446 #6 ldist_gen (starting_vertices=0x12da6d0, rdg=0x1288840, loop=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1142 #7 distribute_loop (stmts=optimized out, loop=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1228 #8 distribute_loop (loop=optimized out, stmts=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1170 #9 0x00715b8d in tree_loop_distribution () at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1284 #10 0x00646f53 in execute_one_pass (pass=0x108ee20) at /tmp/gcc-4.7-20130330/gcc/passes.c:2084 #11 0x00647265 in execute_pass_list (pass=0x108ee20) at /tmp/gcc-4.7-20130330/gcc/passes.c:2139 #12 0x00647277 in execute_pass_list (pass=0x108ff00) at /tmp/gcc-4.7-20130330/gcc/passes.c:2140 #13 0x00647277 in execute_pass_list (pass=0x108f180) at /tmp/gcc-4.7-20130330/gcc/passes.c:2140 #14 0x0071cd16 in tree_rest_of_compilation (fndecl=0x7749c300) at /tmp/gcc-4.7-20130330/gcc/tree-optimize.c:422 #15 0x004d1aba in cgraph_expand_function (node=0x777a26c0) at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:1837 #16 0x004d320a in cgraph_expand_all_functions () at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:1904 #17 cgraph_optimize () at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:2218 #18 0x004d371a in cgraph_finalize_compilation_unit () at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:1344 #19 0x004195a0 in c_write_global_declarations () at /tmp/gcc-4.7-20130330/gcc/c-decl.c:10032 #20 0x006d73a1 in compile_file () at /tmp/gcc-4.7-20130330/gcc/toplev.c:573 #21 do_compile () at /tmp/gcc-4.7-20130330/gcc/toplev.c:1929 #22 toplev_main (argc=15, argv=0x7fffdae8) at /tmp/gcc-4.7-20130330/gcc/toplev.c:2005 #23 0x77a47735 in __libc_start_main () from /lib64/libc.so.6 #24 0x00408861 in _start () gcc 4.8-20130404 and 4.6-20130405 both successfully compile this test case.
[Bug target/56855] New: optab_handler (op=vashr_optab, mode=V4DImode) finds nothing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855
Bug #: 56855
Summary: optab_handler (op=vashr_optab, mode=V4DImode) finds
nothing
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
Hello,
we seem to be missing a vashrv4di3 expander. I noticed it because this code:
typedef long long vec __attribute__((vector_size(32)));
vec f(vec a, vec b){
vec m={1,2,3,4};
return am;
}
is lowered to scalar ops by the tree vector lowering pass even with -mavx2.
[Bug c++/56856] New: the location of -Wformat warnings point *after* the format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
Bug #: 56856
Summary: the location of -Wformat warnings point *after* the
format string
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
$ cc1plus gcc/testsuite/g++.dg/ext/builtin4.C -Wall
gcc/testsuite/g++.dg/ext/builtin4.C:9:14: warning: format ‘%d’ expects a
matching ‘int’ argument [-Wformat=]
printf(%d); // { dg-warning expects a matching }
^
Unfortunately, the format_tree we get at the time of the warning does not seem
to have a valid location either:
(gdb) p debug_tree(format_tree)
nop_expr 0x77567660
type pointer_type 0x7741d9d8
type integer_type 0x7741d930 char readonly string-flag QI
size integer_cst 0x773f7f80 constant 8
unit size integer_cst 0x773f7fa0 constant 1
align 8 symtab 0 alias set -1 canonical type 0x7741d930
precision 8 min integer_cst 0x773f7fe0 -128 max integer_cst
0x77414020 127
pointer_to_this pointer_type 0x7741d9d8
unsigned SI
size integer_cst 0x773f7dc0 constant 32
unit size integer_cst 0x773f7de0 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7741d9d8
pointer_to_this pointer_type 0x77420690
readonly constant
arg 0 addr_expr 0x77567640
type pointer_type 0x7755dbd0 type array_type 0x7755da80
unsigned SI size integer_cst 0x773f7dc0 32 unit size
integer_cst 0x773f7de0 4
align 32 symtab 0 alias set -1 canonical type 0x7755dbd0
readonly constant
arg 0 string_cst 0x77565990 type array_type 0x7755da80
readonly constant static %d\000
[Bug c++/56856] the location of Wformat warnings points *after* the format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Blocks||52952
Summary|the location of -Wformat|the location of Wformat
|warnings point *after* the |warnings points *after* the
|format string |format string
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-06
10:50:20 UTC ---
And this blocks PR52952 because with the *correct* offset, we get this in C++:
/home/manuel/test2/src/gcc/testsuite/g++.dg/ext/builtin4.C:9:16: warning:
format ‘%d’ expects a matching ‘int’ argument [-Wformat=]
printf(%d); // { dg-warning expects a matching }
^
which is even worse than without offset locations.
[Bug fortran/56852] [4.6/4.7/4.8/4.9 Regression] ICE on invalid: Bad array reference for an undeclared loop variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56852 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code CC||burnus at gcc dot gnu.org Known to work||4.5.3 Known to fail||4.6.3, 4.7.2, 4.8.0, 4.9.0 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-06 11:23:54 UTC --- In gfc_variable_attr, one has for a(i): expr-ref-type == REF_ARRAY and runs into the assert as: ref-u.ar.type == AR_UNKNOWN. The has no IMPLICIT type error is issued via: resolve_all_program_units - resolve_types - resolve_symbol The assert is reached via: resolve_all_program_units - resolve_codes - resolve_code - gfc_resolve_blocks - resolve_transfer - gfc_check_vardef_context - gfc_expr_attr - gfc_variable_attr.
[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||56818 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-06 11:46:37 UTC --- Also looks like something that we could include with the array descritor reform.
[Bug c/56851] Segmentation Error using -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56851 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-04-06 11:57:13 UTC --- The SEGV stopped on trunk with r195239 aka PR55964 fix.
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Attachment #28673|0 |1 is obsolete|| Attachment #28890|0 |1 is obsolete|| Status|REOPENED|NEW AssignedTo|jakub at gcc dot gnu.org|steven at gcc dot gnu.org --- Comment #24 from Steven Bosscher steven at gcc dot gnu.org 2013-04-06 12:38:54 UTC --- Created attachment 29814 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29814 Improve handling of BLOCK_FOR_INSN on notes This is what I'm testing now. Looks good so far, so attaching here in anticipation of success :-)
[Bug c++/56857] New: Crash in resolve_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56857 Bug #: 56857 Summary: Crash in resolve_args Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Created attachment 29815 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29815 Partially reduced testcase $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c++ --disable-bootstrap Thread model: posix gcc version 4.9.0 20130406 (experimental) [trunk revision 197540] (GCC) Testcase is partially reduced by delta from libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc $ ./xgcc -B. -std=gnu++11 ~/ice.ii snip /home/ryan/ice.ii:62:17: required from here /home/ryan/ice.ii:48:20: internal compiler error: Segmentation fault (__args) ...); ^ 0xa9722f crash_signal ../../gcc/toplev.c:332 0x4fc912 resolve_args ../../gcc/cp/call.c:3755 0x5150f7 build_new_function_call(tree_node*, vectree_node*, va_gc, vl_embed**, bool, int) ../../gcc/cp/call.c:3865 0x681632 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool, bool, int) ../../gcc/cp/semantics.c:2252 0x566b98 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:14099 0x56d13b tsubst_expr ../../gcc/cp/pt.c:13376 0x57af51 tsubst_decl ../../gcc/cp/pt.c:10759 0x5825e7 tsubst ../../gcc/cp/pt.c:11121 0x5825e7 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11106 0x57935b tsubst_copy ../../gcc/cp/pt.c:12180 0x564d3c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:14435 0x56d13b tsubst_expr ../../gcc/cp/pt.c:13376 0x581997 tsubst ../../gcc/cp/pt.c:11799 0x581997 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11106 0x581902 tsubst ../../gcc/cp/pt.c:11190 0x581902 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11106 0x57adef tsubst_decl ../../gcc/cp/pt.c:10658 0x5825e7 tsubst ../../gcc/cp/pt.c:11121 0x5825e7 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11106 0x56ebe3 tsubst_expr ../../gcc/cp/pt.c:12892 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/56857] Crash in resolve_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56857 Ryan Mansfield rmansfield at qnx dot com changed: What|Removed |Added Version|4.8.1 |4.9.0 --- Comment #1 from Ryan Mansfield rmansfield at qnx dot com 2013-04-06 15:12:09 UTC --- Meant 4.9.0
[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol __atomic_exchange_8 in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56841 --- Comment #5 from dave.anglin at bell dot net 2013-04-06 15:18:44 UTC --- --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-05 10:14:42 UTC --- Dave, does it work after rev 197512 ? Two thumbs up! Dave -- John David Anglindave.ang...@bell.net
[Bug libstdc++/56841] [4.9 Regression] ld: Unsatisfied symbol __atomic_exchange_8 in file /test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.a[eh_terminate.o]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56841 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-06 15:44:16 UTC --- Great, thanks
[Bug c++/51582] [4.6 Regression] ICE when using a class with a matrix of complex numbers in C++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-04-06 16:08:28 UTC --- Created attachment 29816 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29816 patch Here's a fix. I'm not going to apply it to the 4.6 branch because C++11 users really ought to move to a newer release, but I'm attaching it here in case it's useful to anyone.
[Bug target/56858] New: alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 Bug #: 56858 Summary: alpha looks for NOTE_INSN_EH_REGION notes that cannot exist Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ste...@gcc.gnu.org Via alpha.c:alpha_handle_trap_shadows(), the alpha_reorg pass looks for NOTE_INSN_EH_REGION_BEG and NOTE_INSN_EH_REGION_END notes. But those notes are created much later, and can never exist in the machine-dependent reorg pass.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Target||alpha-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-06 CC||rth at gcc dot gnu.org, ||uros at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2013-04-06 18:09:00 UTC --- From passes.c, the pass pipeline: NEXT_PASS (pass_machine_reorg); NEXT_PASS (pass_cleanup_barriers); NEXT_PASS (pass_delay_slots); NEXT_PASS (pass_split_for_shorten_branches); NEXT_PASS (pass_convert_to_eh_region_ranges); alpha's pass_machine_reorg looks for notes that pass_convert_to_eh_region_ranges creates.
[Bug c++/56857] Crash in resolve_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56857 --- Comment #2 from Ryan Mansfield rmansfield at qnx dot com 2013-04-06 18:42:07 UTC --- ICE started happening at rev196747 http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=196747
[Bug c++/56859] New: alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859
Bug #: 56859
Summary: alignas() fails in template
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@leicester.ac.uk
The alignas attribute fails when used with a template-dependent integer
constant, as in
templatetypename T
struct alignas(2*sizeof(T)) foo { /* ... */ };
when gcc complains that error: requested alignment is not an integer constant
(no problem with clang++ 3.2). In a non-templated context, this construct
compiles fine.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858
--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2013-04-06
21:55:57 UTC ---
Proposed fix:
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c(revision 197532)
+++ config/alpha/alpha.c(working copy)
@@ -8568,11 +8568,10 @@ static void
alpha_handle_trap_shadows (void)
{
struct shadow_summary shadow;
- int trap_pending, exception_nesting;
+ int trap_pending;
rtx i, n;
trap_pending = 0;
- exception_nesting = 0;
shadow.used.i = 0;
shadow.used.fp = 0;
shadow.used.mem = 0;
@@ -8582,25 +8581,9 @@ alpha_handle_trap_shadows (void)
{
if (NOTE_P (i))
{
- switch (NOTE_KIND (i))
- {
- case NOTE_INSN_EH_REGION_BEG:
- exception_nesting++;
- if (trap_pending)
- goto close_shadow;
- break;
-
- case NOTE_INSN_EH_REGION_END:
- exception_nesting--;
- if (trap_pending)
- goto close_shadow;
- break;
-
- case NOTE_INSN_EPILOGUE_BEG:
- if (trap_pending alpha_tp = ALPHA_TP_FUNC)
- goto close_shadow;
- break;
- }
+ if (NOTE_KIND (i) == NOTE_INSN_EPILOGUE_BEG
+ trap_pending alpha_tp = ALPHA_TP_FUNC)
+ goto close_shadow;
}
else if (trap_pending)
{
@@ -8683,7 +8666,7 @@ alpha_handle_trap_shadows (void)
}
}
- if ((exception_nesting 0 || alpha_tp = ALPHA_TP_FUNC)
+ if (alpha_tp = ALPHA_TP_FUNC
NONJUMP_INSN_P (i)
GET_CODE (PATTERN (i)) != USE
GET_CODE (PATTERN (i)) != CLOBBER
I can't test this because I have no access to alpha hardware.
[Bug c++/56857] Crash in resolve_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56857 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-06 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/56859] alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-06 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-06 22:24:43 UTC --- Confirmed. Note the testcase is missing an instantiation, like just fooint f;, required to show the problem.
[Bug other/56860] New: Texinfo bug in doc/cppopts.texi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56860 Bug #: 56860 Summary: Texinfo bug in doc/cppopts.texi Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: david.narv...@computer.org Could revision 192887 be backported to 4.7.2?
[Bug c++/56861] New: std::vector::reserve optimization bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56861 Bug #: 56861 Summary: std::vector::reserve optimization bug Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@doublewise.net std::vector::reserve has a few peculiarities currently, as far as the optimizer is concerned. In some cases, calling reserve with the final size of the vector doesn't improve performance at all, but calling reserve with room for one extra element does. In other cases, calling reserve with exactly the correct amount improves performance, but calling with one extra gives the same performance as no reserve at all. I don't know under what circumstances this happens, but it appears to be somewhat system dependent, and changes with otherwise insignificant changes to the code. This arose from a StackOverflow discussion at http://stackoverflow.com/questions/15707688/why-is-calling-vector-reserverequired-1-faster-than-vector-reserverequired That thread contains the code in the first post, which shows the reserve + 1 situation being fastest. The answer by smossen gives some simple changes that lead to the optimizer always working correctly or working correctly in different situations. Unfortunately, I do not know exactly what causes this, but it happens with and without LTO enabled, depending on the code. smossen believes it has to do with the architecture-specific cost model being misapplied in certain circumstances. Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
[Bug libstdc++/56862] New: std::complex constructor ambiguous overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56862
Bug #: 56862
Summary: std::complex constructor ambiguous overload
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cbc...@gmail.com
#include complex
struct number {
number() {}
operator std::complexdouble() const { return 0; }
operator int(); //OK if this line is commented out
};
int main() {
number const a; std::complexdouble ca(a); //OK
number b; std::complexdouble cb(b); //error: call of overloaded
'complex(number)' is ambiguous
std::complexdouble cc(number()); //OK
return 0;
}
/*
Ambiguous overload for all gcc versions I tried (4.5 to 4.8)
on all platforms I tried (linux amd64, mingw32, cygwin).
Not sure if the problem is in libstdc++'s complex or in g++.
*/
Re: [PATCH, combine] Fix host-specific behavior in simplify_compare_const()
2013/3/7 Chung-Ju Wu jasonw...@gmail.com: 2013/3/5 Eric Botcazou ebotca...@adacore.com: In other words, any 32-bit target with 'need_64bit_hwint=yes' in config.gcc is not able to have benefit from this optimization because it never passes the condition test. My solution is to use GET_MODE_MASK(mode) to filter out all bits not in target mode. The following is my patch: The patch is OK for 4.9 once stage #1 is open if it passes bootstrap/regtest. Thanks for the approval. I will wait for 4.9 stage1 opening. The following is the new patch according to your suggestions: Hi, Eric, Since now it is on 4.9 stage1, I would like to contribute this patch. The followings are previous discussion: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01247.html http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00169.html http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00280.html The attached patch has passed bootstrap/regression test on x86_64-unknown-linux-gnu with current main trunk. A plaintext gcc/ChangeLog is as below: 2013-04-06 Chung-Ju Wu jasonw...@gmail.com * combine.c (simplify_compare_const): Use GET_MODE_MASK to filter out unnecessary bits in the constant power of two case. On behalf of Andes Technology Co., we have signed FSF agreement. However, so far I don't have svn write access yet. Would you please help to commit this patch? Thanks again for the approval and I really appreciate your help. :) Best regards, jasonwucj gcc490-combine.svn.patch Description: Binary data
[RFA] [PATCH] Minor improvement to canonicalization of COND_EXPR for gimple
The tree combiner/forward propagator is missing opportunities to
collapse sequences like this:
_15 = _12 ^ _14;
if (_15 != 0)
Into:
if (_12 != _14)
The tree combiner/forward propagator builds this tree:
x ^ y
Then passes it to canonicalize_cond_expr_cond That is not suitable for
the condition in a gimple COND_EXPR. So canonicalize_cond_expr_cond
returns NULL. Thus combine_cond_expr_cond decides the tree it created
isn't useful and throws it away.
This patch changes canonicalize_cond_expr to rewrite x ^ y into x != y.
The net result being the tree combiner/forward propagator is able to
perform the desired simplification, eliminating the BIT_XOR_EXPR.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. As you
can see from the testcase, these kinds of sequences show up when
compiling gcc itself.
OK for the trunk?
commit 809408a4bde6dfbaf62c5bda9ab7ae6c4447d984
Author: Jeff Law l...@redhat.com
Date: Sat Apr 6 05:11:17 2013 -0600
* gimple.c (canonicalize_cond_expr_cond): Rewrite x ^ y into
x != y.
* gcc.dg/tree-ssa/forwprop-25.c: New test
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b8a6900..44797cc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-04-06 Jeff Law l...@redhat.com
+
+ * gimple.c (canonicalize_cond_expr_cond): Rewrite x ^ y into
+ x != y.
+
2013-04-03 Jeff Law l...@redhat.com
* Makefile.in (lra-constraints.o): Depend on $(OPTABS_H).
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 785c2f0..cdb6f24 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -2958,7 +2958,11 @@ canonicalize_cond_expr_cond (tree t)
t = build2 (TREE_CODE (top0), TREE_TYPE (t),
TREE_OPERAND (top0, 0), TREE_OPERAND (top0, 1));
}
-
+ /* For x ^ y use x != y. */
+ else if (TREE_CODE (t) == BIT_XOR_EXPR)
+t = build2 (NE_EXPR, TREE_TYPE (t),
+ TREE_OPERAND (t, 0), TREE_OPERAND (t, 1));
+
if (is_gimple_condexpr (t))
return t;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index dc0b745..601ca66 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2013-04-06 Jeff Law l...@redhat.com
+
+ * gcc.dg/tree-ssa/forwprop-25.c: New test
+
2013-04-03 Jeff Law l...@redhat.com
PR tree-optimization/56799
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-25.c
b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-25.c
new file mode 100644
index 000..cf0c504
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-25.c
@@ -0,0 +1,43 @@
+/* { dg-do compile } */
+/* { dg-options -O1 -fdump-tree-forwprop1 } */
+
+struct rtx_def;
+typedef struct rtx_def *rtx;
+typedef const struct rtx_def *const_rtx;
+enum machine_mode
+{
+ MAX_MACHINE_MODE,
+ NUM_MACHINE_MODES = MAX_MACHINE_MODE
+};
+extern const char *const mode_name[NUM_MACHINE_MODES];
+enum mode_class
+{ MODE_RANDOM, MODE_CC, MODE_INT, MODE_PARTIAL_INT, MODE_FRACT, MODE_UFRACT,
+MODE_ACCUM, MODE_UACCUM, MODE_FLOAT, MODE_DECIMAL_FLOAT, MODE_COMPLEX_INT,
+MODE_COMPLEX_FLOAT, MODE_VECTOR_INT, MODE_VECTOR_FRACT,
+MODE_VECTOR_UFRACT, MODE_VECTOR_ACCUM, MODE_VECTOR_UACCUM,
+MODE_VECTOR_FLOAT, MAX_MODE_CLASS };
+extern const unsigned char mode_class[NUM_MACHINE_MODES];
+extern const unsigned short mode_precision[NUM_MACHINE_MODES];
+struct rtx_def
+{
+ __extension__ enum machine_mode mode:8;
+};
+void
+convert_move (rtx to, rtx from, int unsignedp)
+{
+ enum machine_mode to_mode = ((enum machine_mode) (to)-mode);
+ enum machine_mode from_mode = ((enum machine_mode) (from)-mode);
+ ((void)
+ (!((mode_precision[from_mode] != mode_precision[to_mode])
+ || enum mode_class) mode_class[from_mode]) == MODE_DECIMAL_FLOAT) !=
+ (((enum mode_class) mode_class[to_mode]) ==
+ MODE_DECIMAL_FLOAT))) ?
+fancy_abort (/home/gcc/virgin-gcc/gcc/expr.c, 380, __FUNCTION__),
+0 : 0));
+}
+
+/* { dg-final { scan-tree-dump Replaced.*!=.*with.*!=.* forwprop1} } */
+/* { dg-final { cleanup-tree-dump forwprop1 } } */
+
+
+
[RFA][PATCH] Improve VRP of COND_EXPR_CONDs
Given something like this:
bb 6:
_23 = changed_17 ^ 1;
_12 = (_Bool) _23;
if (_12 != 0)
goto bb 10;
else
goto bb 7;
Assume _23 and changed_17 have integer types wider than a boolean, but
VRP has determined they have a range [0..1].
We should be turning that into:
bb 6:
_23 = changed_17 ^ 1;
_12 = (_Bool) _23;
if (_23 != 0)
goto bb 10;
else
goto bb 7;
Note the change in the conditional. This also makes the statement
_12 = (_Bool) _23 dead which should be eliminated by DCE.
This kind of thing happens regularly in GCC itself and is fixed by the
attached patch.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
OK for the trunk?
commit fd82eea6f208bb12646e0e0e307fb86f043c1649
Author: Jeff Law l...@redhat.com
Date: Sat Apr 6 06:46:58 2013 -0600
* tree-vrp.c (simplify_cond_using_ranges): Simplify test of boolean
when the boolean was created by converting a wider object which
had a boolean range.
* gcc.dg/tree-ssa/vrp87.c: New test
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 44797cc..d34ecde 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
2013-04-06 Jeff Law l...@redhat.com
+ * tree-vrp.c (simplify_cond_using_ranges): Simplify test of boolean
+ when the boolean was created by converting a wider object which
+ had a boolean range.
+
* gimple.c (canonicalize_cond_expr_cond): Rewrite x ^ y into
x != y.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 601ca66..6ed8af2 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,7 @@
2013-04-06 Jeff Law l...@redhat.com
+ * gcc.dg/tree-ssa/vrp87.c: New test
+
* gcc.dg/tree-ssa/forwprop-25.c: New test
2013-04-03 Jeff Law l...@redhat.com
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
new file mode 100644
index 000..7feff81
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
@@ -0,0 +1,81 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-tree-vrp2-details -fdump-tree-cddce2-details } */
+
+struct bitmap_head_def;
+typedef struct bitmap_head_def *bitmap;
+typedef const struct bitmap_head_def *const_bitmap;
+
+
+typedef unsigned long BITMAP_WORD;
+typedef struct bitmap_element_def
+{
+ struct bitmap_element_def *next;
+ unsigned int indx;
+ BITMAP_WORD bits[((128 + (8 * 8 * 1u) - 1) / (8 * 8 * 1u))];
+} bitmap_element;
+
+
+
+
+
+
+typedef struct bitmap_head_def
+{
+ bitmap_element *first;
+
+} bitmap_head;
+
+
+
+static __inline__ unsigned char
+bitmap_elt_ior (bitmap dst, bitmap_element * dst_elt,
+ bitmap_element * dst_prev, const bitmap_element * a_elt,
+ const bitmap_element * b_elt, unsigned char changed)
+{
+
+ if (a_elt)
+{
+
+ if (!changed dst_elt)
+ {
+ changed = 1;
+ }
+}
+ else
+{
+ changed = 1;
+}
+ return changed;
+}
+
+unsigned char
+bitmap_ior_into (bitmap a, const_bitmap b)
+{
+ bitmap_element *a_elt = a-first;
+ const bitmap_element *b_elt = b-first;
+ bitmap_element *a_prev = ((void *) 0);
+ unsigned char changed = 0;
+
+ while (b_elt)
+{
+
+ if (!a_elt || a_elt-indx == b_elt-indx)
+ changed = bitmap_elt_ior (a, a_elt, a_prev, a_elt, b_elt, changed);
+ else if (a_elt-indx b_elt-indx)
+ changed = 1;
+ b_elt = b_elt-next;
+
+
+}
+
+ return changed;
+}
+
+/* Verify that VRP simplified an if statement. */
+/* { dg-final { scan-tree-dump Folded into: if.* vrp2} } */
+/* Verify that DCE after VRP2 eliminates a dead conversion
+ to a (Bool). */
+/* { dg-final { scan-tree-dump Deleting.*_Bool.*; cddce2} } */
+/* { dg-final { cleanup-tree-dump vrp2 } } */
+/* { dg-final { cleanup-tree-dump cddce2 } } */
+
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 250a506..d76cead 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -8584,6 +8584,43 @@ simplify_cond_using_ranges (gimple stmt)
}
}
+ /* If we have a comparison of a SSA_NAME boolean against
+ a constant (which obviously must be [0..1]). See if the
+ SSA_NAME was set by a type conversion where the source
+ of the conversion is another SSA_NAME with a range [0..1].
+
+ If so, we can replace the SSA_NAME in the comparison with
+ the RHS of the conversion. This will often make the type
+ conversion dead code which DCE will clean up. */
+ if (TREE_CODE (op0) == SSA_NAME
+ TREE_CODE (TREE_TYPE (op0)) == BOOLEAN_TYPE
+ is_gimple_min_invariant (op1))
+{
+ gimple def_stmt = SSA_NAME_DEF_STMT (op0);
+ tree innerop;
+
+ if (!is_gimple_assign (def_stmt)
+ || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
+ return false;
+
+ innerop = gimple_assign_rhs1 (def_stmt);
+
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
+
Re: [RFA][PATCH] Improve VRP of COND_EXPR_CONDs
On Sat, Apr 6, 2013 at 2:48 PM, Jeff Law wrote:
Given something like this:
...and the other one from earlier today. Nice finds! :-)
+ /* If we have a comparison of a SSA_NAME boolean against
+ a constant (which obviously must be [0..1]). See if the
...be [0..1]), see if ...
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
I don't think the SSA_NAME_OCCURS_IN_ABNORMAL_PHI test is necessary,
get_value_range() will simply return a !VR_RANGE.
+ if (vr-type == VR_RANGE
+ operand_equal_p (vr-min, integer_zero_node, 0)
+ operand_equal_p (vr-max, integer_one_node, 0))
+ {
Better use range_int_cst_p(vr) followed by compare_tree_int instead of
operand_equal_p IMHO.
Print something to dump_file?
Ciao!
Steven
Re: functional and type_traits cleanup
On 5 April 2013 21:12, François Dumont wrote:
In fact my first attempt was a very simple one:
templatetypename _From, typename _To
class __is_convertible_helper_From, _To, false
{
templatetypename _To1
static true_type
__test(_To1);
templatetypename
static false_type
__test(...);
public:
typedef decltype(__test_To(std::declval_From())) type;
};
But some tests failed like:
In file included from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/move.h:57:0,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:59,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/utility:70,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:38,
from
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:55,
from
/home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:23:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::__is_convertible_helperconst
std::tuplestd::_Placeholder1 , std::_Placeholder1, false':
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1321:12:
required from 'struct std::is_convertibleconst
std::tuplestd::_Placeholder1 , std::_Placeholder1 '
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:111:12:
required from 'struct std::__and_std::is_convertibleconst
std::tuplestd::_Placeholder1 , std::_Placeholder1 '
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:400:40:
required from 'struct std::_Bindvoid (*(std::_Placeholder1))(int)'
/home/fdt/dev/gcc/src/libstdc++-v3/testsuite/20_util/bind/38889.cc:28:41:
required from here
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1316:30:
error: 'std::_Placeholder1' is an inaccessible base of
'std::tuplestd::_Placeholder1 '
typedef decltype(__test_To(std::declval_From())) type;
^
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/type_traits:1309:2:
error: initializing argument 1 of 'static std::true_type
std::__is_convertible_helper_From, _To, false::__test(_To1) [with _To1 =
std::_Placeholder1; _From = const std::tuplestd::_Placeholder1 ; _To
= std::_Placeholder1; std::true_type = std::integral_constantbool,
true]'
__test(_To1);
^
From my point of view this is an other example of use case for which gcc is
not SFINAE friendly enough, no ?
No, I don't think this is a GCC problem. In this code the
derived-to-base conversion does not happen in the context of the
function template argument deduction but happens afterwards, so the
access failure is not part of argument deduction and so is a hard
error not a substitution failure.
But the version with the default template parameter is fine and more
consistent with the other helpers implementation so, adopted! Here is an
other version of the patch for validation.
Daniel, I agree that inheritance with integral_constant is not as
obvious as before but it is still there and it is just what the compiler
need.
I assume Daniel's reply was an HTML mail and didn't make it to the
list, was there an objection to the change or a general comment?
I even hope that it also simplified a (very) little bit the job for
the compiler.
I don't know if the compiler's job is easier or not, but I think with
your change the template instantiation depth is increased by one, with
your change we get false_type instantiated by the instantiation of
is_convertible, rather than being done after it using its value
member.
Ok to commit ?
I'd like to hear Daniel's comment first, but if we don't hear from him
please commit it in 24 hours. Thanks.
[committed] Fix PR target/55487: Don't increment label nuses on NOTE_INSN_DELETED_LABEL notes
The fix is obvious. Tested on hppa64-hp-hpux11.11 and hppa-unknown- linux-gnu with no observed regressions. Committed to 4.8 and trunk. Dave -- John David Anglin dave.ang...@bell.net 2013-04-06 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/55487 * config/pa/pa.c (legitimize_pic_address): Before incrementing label nuses, make sure we have a label. Index: config/pa/pa.c === --- config/pa/pa.c (revision 197452) +++ config/pa/pa.c (working copy) @@ -792,7 +792,9 @@ /* Extract CODE_LABEL. */ orig = XEXP (orig, 0); add_reg_note (insn, REG_LABEL_OPERAND, orig); - LABEL_NUSES (orig)++; + /* Make sure we have label and not a note. */ + if (LABEL_P (orig)) + LABEL_NUSES (orig)++; } crtl-uses_pic_offset_table = 1; return reg;
[committed] Fix GCC bootstrap on hppa*-*-hpux* using HP cat
The patch fixes PR other/55274 and we now generate a non empty map file. As noted in the PR, this problem causes a hang when bootstrap is done using HP cat. Tested on hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. Committed to trunk and 4.8. Richard, would it be ok to apply to the 4.7 branch? This is a 4.7 regression. Dave -- John David Anglin dave.ang...@bell.net 2013-04-06 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR other/55274 * config/t-slibgcc-hpux (SHLIB_MAPFILES): Define. Index: config/t-slibgcc-hpux === --- config/t-slibgcc-hpux (revision 197540) +++ config/t-slibgcc-hpux (working copy) @@ -5,3 +5,4 @@ INSTALL_SHLIB = $(INSTALL_DATA) -m 555 SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk +SHLIB_MAPFILES = libgcc-std.ver
Re: functional and type_traits cleanup
2013/4/6 Jonathan Wakely jwakely@gmail.com But the version with the default template parameter is fine and more consistent with the other helpers implementation so, adopted! Here is an other version of the patch for validation. Daniel, I agree that inheritance with integral_constant is not as obvious as before but it is still there and it is just what the compiler need. I assume Daniel's reply was an HTML mail and didn't make it to the list, was there an objection to the change or a general comment? Yes, I got a reply that my response was not accepted due to html content. I hope this one gets into it. My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. I even hope that it also simplified a (very) little bit the job for the compiler. I don't know if the compiler's job is easier or not, but I think with your change the template instantiation depth is increased by one, with your change we get false_type instantiated by the instantiation of is_convertible, rather than being done after it using its value member. Ok to commit ? I'd like to hear Daniel's comment first, but if we don't hear from him please commit it in 24 hours. Thanks. Thanks Jonathan. The text above more or less reflects the content of my previous comment. I think I have no formal objection to the changes, but after they have been applied I would like to do a more rigorous test of the inheritance requirement. - Daniel
Re: functional and type_traits cleanup
On 6 April 2013 21:03, Daniel Krügler wrote: 2013/4/6 Jonathan Wakely jwakely@gmail.com But the version with the default template parameter is fine and more consistent with the other helpers implementation so, adopted! Here is an other version of the patch for validation. Daniel, I agree that inheritance with integral_constant is not as obvious as before but it is still there and it is just what the compiler need. I assume Daniel's reply was an HTML mail and didn't make it to the list, was there an objection to the change or a general comment? Yes, I got a reply that my response was not accepted due to html content. I hope this one gets into it. It did: http://gcc.gnu.org/ml/libstdc++/2013-04/msg00031.html My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. They should all do, because the types that used to define a 'value' member all now define a 'type' as a typedef for either true_type or false_type. Thanks Jonathan. The text above more or less reflects the content of my previous comment. I think I have no formal objection to the changes, but after they have been applied I would like to do a more rigorous test of the inheritance requirement. That wouldn't hurt, but I agree it shouldn't prevent the patch going in. François, please go ahead and commit it, thanks.
C: Add new warning -Wunprototyped-calls
This patch comes from Richard's SUSE GCC patch. There,
-Wunprototyped-calls is enabled for all RPM builds.
-Wunprototyped-calls prints a warning if one calls a function with an
argument with is declared without prototype. For instance:
gcc.dg/Wunprototyped-calls.c: In function ‘main’:
gcc.dg/Wunprototyped-calls.c:13:3: warning: call to function ‘g’ without
a real prototype [-Wunprototyped-calls]
g(1); /* { dg-warning call to function 'g' without a real prototype } */
^
gcc.dg/Wunprototyped-calls.c:7:6: note: ‘g’ was declared here
void g() { } /* { dg-message note: 'g' was declared here } */
To avoid too many warning, no warning is shows for KR procedures or if
no argument is passed to the function. (i.e. for those where the
programmer just forgot the (void).)
The warning can help finding argument-passing bugs and it is less
intrusive than -Wstrict-prototypes.
The patch activates the warning with -Wall, but one could also argue
that it should only be activated with -Wextra or only with
-Wunprototyped-calls.
Bootstrapped (C,ObjC,C++,ObjC++ only) and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
gcc/c-family/
2013-04-07 Richard Biener rguent...@suse.de
Tobias Burnus bur...@net-b.de
* c.opt (Wunprototyped-calls): New C/ObjC warning.
* c-opts.c (c_common_handle_option): Handle it.
gcc/c/
2013-04-07 Richard Biener rguent...@suse.de
* c-typeck.c (build_function_call_vec): Handle warning
warn_unprototyped_calls.
gcc/
2013-04-07 Tobias Burnus bur...@net-b.de
* doc/invoke.texi (-Wunprototyped-calls): Document it.
(-Wall): Add -Wunprototyped-calls to the list.
gcc/testsuite/
2013-04-07 Richard Biener rguent...@suse.de
Tobias Burnus bur...@net-b.de
* gcc.dg/cleanup-1.c: Update dg-warning.
* gcc.dg/Wunprototyped-calls.c: New.
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 4b6990a..a66e2a6 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -444,6 +444,10 @@ c_common_handle_option (size_t scode, const char *arg, int value,
warn_unknown_pragmas = value * 2;
break;
+case OPT_Wunprototyped_calls:
+ warn_unprototyped_calls = value;
+ break;
+
case OPT_ansi:
if (!c_dialect_cxx ())
set_std_c89 (false, true);
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 10ae84d..9c2de33 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -757,6 +757,10 @@ Wunused-local-typedefs
C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning EnabledBy(Wunused)
Warn when typedefs locally defined in a function are not used
+Wunprototyped-calls
+C ObjC Var(warn_unprototyped_calls) Warning LangEnabledBy(C ObjC,Wall)
+Warn about calls to unprototyped functions with at least one argument
+
Wunused-macros
C ObjC C++ ObjC++ Var(cpp_warn_unused_macros) Warning
Warn about macros defined in the main file that are not used
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index ddb6d39..26336b3 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -2833,6 +2833,19 @@ build_function_call_vec (location_t loc, tree function,
!check_builtin_function_arguments (fundecl, nargs, argarray))
return error_mark_node;
+ /* If we cannot check function arguments because a prototype is
+ missing for the callee, warn here. */
+ if (warn_unprototyped_calls
+ nargs 0 !TYPE_ARG_TYPES (fntype)
+ fundecl !DECL_BUILT_IN (fundecl) !C_DECL_IMPLICIT (fundecl)
+ !DECL_ARGUMENTS (fundecl))
+{
+ if (warning (OPT_Wunprototyped_calls,
+ call to function %qD without a real prototype, fundecl))
+ inform (DECL_SOURCE_LOCATION (fundecl), %qD was declared here,
+ fundecl);
+}
+
/* Check that the arguments to the function are valid. */
check_function_arguments (fntype, nargs, argarray);
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1652ebc..ee1a351 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -279,8 +279,8 @@ Objective-C and Objective-C++ Dialects}.
@gccoptlist{-Wbad-function-cast -Wmissing-declarations @gol
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs @gol
-Wold-style-declaration -Wold-style-definition @gol
--Wstrict-prototypes -Wtraditional -Wtraditional-conversion @gol
--Wdeclaration-after-statement -Wpointer-sign}
+-Wstrict-prototypes -Wunprototyped-calls -Wtraditional @gol
+-Wtraditional-conversion -Wdeclaration-after-statement -Wpointer-sign}
@item Debugging Options
@xref{Debugging Options,,Options for Debugging Your Program or GCC}.
@@ -3144,6 +3144,7 @@ Options} and @ref{Objective-C and Objective-C++ Dialect Options}.
-Wtrigraphs @gol
-Wuninitialized @gol
-Wunknown-pragmas @gol
+-Wunprototyped-calls @r{(only for C/ObjC)} @gol
-Wunused-function @gol
-Wunused-label @gol
-Wunused-value @gol
@@ -4455,6 +4456,15 @@ argument types. (An old-style function definition is permitted without
a warning if preceded by a declaration that specifies the argument
types.)
+@item
Re: C: Add new warning -Wunprototyped-calls
Tobias Burnus bur...@net-b.de writes: gcc.dg/Wunprototyped-calls.c:13:3: warning: call to function ‘g’ without a real prototype [-Wunprototyped-calls] What is a real prototype? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[patch] update documentation for SEQUENCE
Hello,
The existing documentation for SEQUENCE still states it is used for
DEFINE_EXPAND sequences. I think I wasn't even hacking GCC when that
practice was abandoned, and in the mean time some other uses of
SEQUENCE have appeared in the compiler. So, a long-overdue
documentation update.
OK for trunk?
Ciao!
Steven
* doc/rtl.texi (sequence): Rewrite documentation to match the
current use of SEQUENCE rtl objects.
* rtl.def (SEQUENCE): Likewise.
Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 197532)
+++ doc/rtl.texi(working copy)
@@ -3099,18 +3099,11 @@ side-effects.
@findex sequence
@item (sequence [@var{insns} @dots{}])
-Represents a sequence of insns. Each of the @var{insns} that appears
-in the vector is suitable for appearing in the chain of insns, so it
-must be an @code{insn}, @code{jump_insn}, @code{call_insn},
-@code{code_label}, @code{barrier} or @code{note}.
+Represents a sequence of insns. If a @code{sequence} appears in the
+chain of insns, then each of the @var{insns} that appears in the sequence
+must be suitable for appearing in the chain of insns, i.e. must satisfy
+the @code{INSN_P} predicate.
-A @code{sequence} RTX is never placed in an actual insn during RTL
-generation. It represents the sequence of insns that result from a
-@code{define_expand} @emph{before} those insns are passed to
-@code{emit_insn} to insert them in the chain of insns. When actually
-inserted, the individual sub-insns are separated out and the
-@code{sequence} is forgotten.
-
After delay-slot scheduling is completed, an insn and all the insns that
reside in its delay slots are grouped together into a @code{sequence}.
The insn requiring the delay slot is the first insn in the vector;
@@ -3123,6 +3116,19 @@ the effect of the insns in the delay slots. In su
the branch and should be executed only if the branch is taken; otherwise
the insn should be executed only if the branch is not taken.
@xref{Delay Slots}.
+
+Some back ends also use @code{sequence} objects for purposes other than
+delay-slot groups. This is not supported in the common parts of the
+compiler, which treat such sequences as delay-slot groups.
+
+DWARF2 Call Frame Address (CFA) adjustments are sometimes also expressed
+using @code{sequence} objects as the value of a @code{RTX_FRAME_RELATED_P}
+note. This only happens if the CFA adjustments cannot be easily derived
+from the pattern of the instruction to which the note is attached. In
+such cases, the value of the note is used instead of best-guesing the
+semantics of the instruction. The back end can attach notes containing
+a @code{sequence} of @code{set} patterns that express the effect of the
+parent instruction.
@end table
These expression codes appear in place of a side effect, as the body of
Index: rtl.def
===
--- rtl.def (revision 197533)
+++ rtl.def (working copy)
@@ -102,10 +102,24 @@ DEF_RTL_EXPR(EXPR_LIST, expr_list, ee, RTX_EXT
The insns are represented in print by their uids. */
DEF_RTL_EXPR(INSN_LIST, insn_list, ue, RTX_EXTRA)
-/* SEQUENCE appears in the result of a `gen_...' function
- for a DEFINE_EXPAND that wants to make several insns.
- Its elements are the bodies of the insns that should be made.
- `emit_insn' takes the SEQUENCE apart and makes separate insns. */
+/* SEQUENCE is used in late passes of the compiler to group insns for
+ one reason or another.
+
+ For example, after delay slot filling, branch instructions with filled
+ delay slots are represented as a SEQUENCE of length 1 + n_delay_slots,
+ with the branch instruction in XEXPVEC(seq, 0, 0) and the instructions
+ occupying the delay slots in the remaining XEXPVEC slots.
+
+ Another place where a SEQUENCE may appear, is in REG_FRAME_RELATED_EXPR
+ notes, to express complex operations that are not obvious from the insn
+ to which the REG_FRAME_RELATED_EXPR note is attached. In this usage of
+ SEQUENCE, the sequence vector slots do not hold real instructions but
+ only pseudo-instructions that can be translated to DWARF CFA expressions.
+
+ Some back ends also use SEQUENCE to group insns in bundles.
+
+ Much of the compiler infrastructure is not prepared to handle SEQUENCE
+ objects. Only passes after pass_free_cfg are expected to handle them. */
DEF_RTL_EXPR(SEQUENCE, sequence, E, RTX_EXTRA)
/* Represents a non-global base address. This is only used in alias.c. */
Re: functional and type_traits cleanup
Hi, On 04/06/2013 10:43 PM, Jonathan Wakely wrote: My response was more like a general comment: My apprehension is that I after these changes not all predicate type traits do satisfy the Library requirement anymore that they still derive from std::integral_constant. But I have not checked that individually. They should all do, because the types that used to define a 'value' member all now define a 'type' as a typedef for either true_type or false_type. When I saw the patch I had the same concern, but indeed the nice simplification seems worth the less transparent conformance. Personally, I would be much less nervous if for type_traits too we could have typedef checks for each and every trait (like we do for the tr1/type_traits). By the way, we should also check that the value_type operator is there... Thanks! Paolo.
[patch] PR middle-end/43631
Hello,
In this PR43631, var-tracking notes are inserted on basic block
boundaries and BB_HEAD/BB_END end up pointing to these notes. This
breaks verify_flow_info.
The problem is actually bigger than just the var-tracking notes. The
general problem is that there are no rules for whether or not notes
are part of a basic block or not. Some notes never appear inside a
basic block, some notes always must appear inside a basic block, and
some can appear virtually anywhere.
With this patch I've chosen to maintain the invariant that BB_END must
be an INSN, and never be a NOTE or BARRIER. The result is that
NOTE_INSN_EH_REGION_BEG notes can be inside a basic block while the
pairing NOTE_INSN_EH_REGION_END is outside the basic block. I don't
think this is a problem: The same thing already happens with jump
table data, barriers, etc.
The nice thing is that with this patch, *finally* I have
verify_flow_info pass after var-tracking. That's important because
officially the CFG is freed after this pass (pass_free_cfg runs after
pass_variable_tracking) but because verify_flow_info didn't pass after
var-tracking the CFG was already invalidated before it was freed
(BB_HEAD and BB_END would be incorrect). That has the effect that some
of the machine-reorg passes that use the CFG never really had a
correct CFG at all!
With this patch and a hack to call compute_bb_for_insn, I now can call
verify_flow_info in every pass up to final for the i386 port :-)
Bootstrappedtested on x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
PR middle-end/43631
* emit-rtl.c (link_insn_into_chain): New static inline function.
(add_insn): Use it.
(add_insn_before, add_insn_after): Factor insn chain linking code...
(add_insn_before_nobb, add_insn_after_nobb): ...here, new functions
using link_insn_into_chain.
(emit_note_after): Use nobb variant of add_insn_after if the note
should not be contained in a basic block.
(emit_note_before): Use nobb variant of add_insn_before if the note
should not be contained in a basic block.
* bb-reorder.c (insert_section_boundary_note): Remove hack to set
BLOCK_FOR_INSN to NULL manually for NOTE_INSN_SWITCH_TEXT_SECTIONS.
* jump.c (cleanup_barriers): Use reorder_insns_nobb to avoid making
the moved barrier the tail of the basic block it follows.
* var-tracking.c (pass_variable_tracking): Add TODO_verify_flow.
Index: emit-rtl.c
===
--- emit-rtl.c (revision 197536)
+++ emit-rtl.c (working copy)
@@ -3752,61 +3752,122 @@ make_call_insn_raw (rtx pattern)
return insn;
}
+/* Add INSN to the end of the doubly-linked list, between PREV and NEXT.
+ INSN may be any object that can appear in the chain: INSN_P and NOTE_P
objects,
+ but also BARRIERs and JUMP_TABLE_DATAs. PREV and NEXT may be NULL. */
+
+static inline void
+link_insn_into_chain (rtx insn, rtx prev, rtx next)
+{
+ PREV_INSN (insn) = prev;
+ NEXT_INSN (insn) = next;
+ if (prev != NULL)
+{
+ NEXT_INSN (prev) = insn;
+ if (NONJUMP_INSN_P (prev) GET_CODE (PATTERN (prev)) == SEQUENCE)
+ {
+ rtx sequence = PATTERN (prev);
+ NEXT_INSN (XVECEXP (sequence, 0, XVECLEN (sequence, 0) - 1)) = insn;
+ }
+}
+ if (next != NULL)
+{
+ PREV_INSN (next) = insn;
+ if (NONJUMP_INSN_P (next) GET_CODE (PATTERN (next)) == SEQUENCE)
+ PREV_INSN (XVECEXP (PATTERN (next), 0, 0)) = insn;
+}
+}
+
/* Add INSN to the end of the doubly-linked list.
INSN may be an INSN, JUMP_INSN, CALL_INSN, CODE_LABEL, BARRIER or NOTE. */
void
add_insn (rtx insn)
{
- PREV_INSN (insn) = get_last_insn();
- NEXT_INSN (insn) = 0;
-
- if (NULL != get_last_insn())
-NEXT_INSN (get_last_insn ()) = insn;
-
+ rtx prev = get_last_insn ();
+ link_insn_into_chain (insn, prev, NULL);
if (NULL == get_insns ())
set_first_insn (insn);
-
set_last_insn (insn);
}
/* Add INSN into the doubly-linked list after insn AFTER. This and
the next should be the only functions called to insert an insn once
delay slots have been filled since only they know how to update a
- SEQUENCE. */
+ SEQUENCE.
+ This function is internal to emit-rtl.c. Use add_insn_after outside
+ this file. */
-void
-add_insn_after (rtx insn, rtx after, basic_block bb)
+static void
+add_insn_after_nobb (rtx insn, rtx after)
{
rtx next = NEXT_INSN (after);
gcc_assert (!optimize || !INSN_DELETED_P (after));
- NEXT_INSN (insn) = next;
- PREV_INSN (insn) = after;
+ link_insn_into_chain (insn, after, next);
- if (next)
+ if (next == NULL)
{
- PREV_INSN (next) = insn;
- if (NONJUMP_INSN_P (next) GET_CODE (PATTERN (next)) == SEQUENCE)
- PREV_INSN (XVECEXP (PATTERN (next), 0, 0)) = insn;
+ if (get_last_insn () == after)
+ set_last_insn (insn);
+ else
+
Re: [PATCH, combine] Fix host-specific behavior in simplify_compare_const()
On 04/06/2013 01:42 AM, Chung-Ju Wu wrote: The attached patch has passed bootstrap/regression test on x86_64-unknown-linux-gnu with current main trunk. A plaintext gcc/ChangeLog is as below: 2013-04-06 Chung-Ju Wu jasonw...@gmail.com * combine.c (simplify_compare_const): Use GET_MODE_MASK to filter out unnecessary bits in the constant power of two case. On behalf of Andes Technology Co., we have signed FSF agreement. However, so far I don't have svn write access yet. Would you please help to commit this patch? Thanks again for the approval and I really appreciate your help. :) I'd suggest getting write access to the repository. See Authenticated access on this page: http://gcc.gnu.org/svnwrite.html List me as your sponsor. jeff
Re: [RFA][PATCH] Improve VRP of COND_EXPR_CONDs
On 04/06/2013 07:08 AM, Steven Bosscher wrote:
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
I don't think the SSA_NAME_OCCURS_IN_ABNORMAL_PHI test is necessary,
get_value_range() will simply return a !VR_RANGE.
It's not necessary -- the code was templated from an unsubmitted related
change to tree-ssa-forwprop where that test is needed. I'll remove it
from this change to tree-vrp.c
+ if (vr-type == VR_RANGE
+ operand_equal_p (vr-min, integer_zero_node, 0)
+ operand_equal_p (vr-max, integer_one_node, 0))
+ {
Better use range_int_cst_p(vr) followed by compare_tree_int instead of
operand_equal_p IMHO.
Seems reasonable.
Print something to dump_file?
Happens via existing machinery. You'll get a Folded into ... message in
the detail dumps. The testcase actually checks for this and also
verifies the following DCE pass kills the dead code.
jeff
RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Tuesday, March 26, 2013 4:33 PM To: 'Joern Rennecke' Cc: gcc-patches@gcc.gnu.org; 'Jeff Law' Subject: RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size -Original Message- From: Joern Rennecke [mailto:joern.renne...@embecosm.com] Sent: Monday, March 25, 2013 8:53 PM To: Bin Cheng Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size Quoting Bin Cheng bin.ch...@arm.com: During the work I observed passes before combine might interfere with CE pass, so this patch is enabled for ce2/ce3 after combination pass. It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk? There are bound to be target and application specific variations on which scaling factors work best. 2013-03-25 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. It would make more sense to pass in the scale factor as a an argument to if_convert. And get the respective values from a set of gcc parameters, so they can be tweaked by ports and/or by a user/ML learning framework (e.g. Milepost) supplying the appropriate --param option. I agree it would be more flexible to pass the factor as parameter, but not sure how useful to users it will be because: firstly it has already been target specific by the BRANCH_COST heuristic; for code size, the heuristic should be tuned to achieve an overall good results, I doubt to which extend it depends on specific target/application. Hi Jeff, This is based on your heuristic tuning in ifcvt, would you help us on this issue with some suggestions? Ping.
RE: [PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Monday, March 25, 2013 3:15 PM To: gcc-patches@gcc.gnu.org Subject: FW: [PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect Sorry for the wrong list. -Original Message- From: Bin Cheng [mailto:bin.ch...@arm.com] Sent: Monday, March 25, 2013 3:00 PM To: g...@gcc.gnu.org Subject: [PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect Hi, As reported in PR56124, IRA causes redundant reload by preferring to put pseudo which is target of loading in memory. Generally this is good but the case in which the src of loading has side effect. This patch fixes this issue by checking whether source of loading has side effect. I tested the patch on x86/thumb2. Is it OK? Thanks. 2013-03-25 Bin Cheng bin.ch...@arm.com PR target/56124 * ira-costs.c (scan_one_insn): Check whether the source rtx of loading has side effect. Ping.
