[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 07:58 --- (In reply to comment #3) > on the mainline I get an stack overflow in the GC. And I have a work around for that. But that is only a work around, we are creating too many varients of FUNCTION_TYPE which seems wrong. We really should be sharing these FUNCTION_TYPEs. This will greatly reduce the memory usage overall in all compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug c++/19523] [4.0 Regression] DBX_USE_BINCL support broken in the C++ compiler
-- What|Removed |Added CC||dpatel at apple dot com, ||zack at codesourcery dot ||com, austern at apple dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug c++/19523] [4.0 Regression] DBX_USE_BINCL support broken in the C++ compiler
-- What|Removed |Added Keywords||wrong-debug Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug c++/19523] New: [4.0 Regression] DBX_USE_BINCL support broken in the C++ compiler
The patch 2004-09-20 Matt Austern <[EMAIL PROTECTED]> Zack Weinberg <[EMAIL PROTECTED]> * c-common.c (fix_string_type): Build the unqualified array type unconditionally, then use c_build_qualified_type to get the proper const-qualified variant, and set its TYPE_MAIN_VARIANT to refer to the unqualified type. * c-lex.c (c_lex_return_raw_string): New global. (c_lex_with_flags): Honor it. * c-pragma.h: Declare it. cp: * decl.c (make_rtl_for_nonlocal_decl, start_preparsed_function): Apply lbasename to input_filename before passing to get_fileinfo. * semantics.c (begin_class_definition): Likewise. * lex.c (handle_pragma_interface): Apply get_fileinfo to the correct filename. Rename variables to be less confusing. (handle_pragma_implementation): Likewise. Disable "appears after file is included" diagnostic. * parser.c (struct cp_token): Add in_system_header fiag. (CP_TOKEN_BLOCK_NUM_TOKENS, struct cp_token_block) (CP_TOKEN_BUFFER_SIZE, cp_token_cache_push_token) (CPP_NONE, cp_lexer_read_token): Delete. (struct cp_lexer): Remove first_token, string_tokens, main_lexer_p fields. Clarify comments. (struct cp_token_cache): Now just a pair of pointers. (CP_LEXER_BUFFER_SIZE): New #define. (CPP_PURGED): New fake token type. (cp_lexer_new_from_token_array, cp_lexer_destroy) (cp_lexer_peek_token_emit_debug_info, cp_lexer_skip_purged_tokens) (cp_lexer_handle_pragma, cp_token_cache_new, cp_parser_string_literal): New functions. (cp_lexer_new_from_tokens): Now a simple wrapper around cp_lexer_new_from_token_array. (cp_lexer_set_source_position_from_token): Also update in_system_header. (cp_lexer_next_token, cp_lexer_prev_token, cp_lexer_advance_token): Don't wrap round. (cp_lexer_token_difference): Dont handle wrapping round. (cp_lexer_new_main): Enable pragma deferral and raw strings, read the entire translation unit through c_lex_with_flags into this lexer's buffer, then turn raw strings back off again. (cp_lexer_grow_buffer): Adjust for buffer no longer being circular. (cp_lexer_get_preprocessor_token): No need to handle not being the main lexer. Set token->in_system_header too. (cp_lexer_peek_token): Skip purged tokens. Feed pragma tokens to cp_lexer_handle_pragma. No need to call cp_lexer_read_token. (cp_lexer_peek_nth_token): Likewise. (cp_lexer_purge_token): Mark the token PURGED, don't shift all the other tokens down. (cp_lexer_purge_tokens_after): Likewise. (cp_lexer_save_tokens, cp_lexer_rollback_tokens): Don't worry about there being no tokens. (cp_lexer_print_token): Revise to give useful information on all tokens. (struct cp_parser): Add field translate_strings_p. (cp_parser_new): Initialize it. (cp_parser_translation_unit): Destroy the lexer when done. (cp_parser_parameter_declaration): Restructure saving of default arguments. (cp_parser_save_member_function_body): Likewise. (cp_parser_check_for_invalid_template_id) (cp_parser_nested_name_specifier_opt, cp_parser_template_id): Adjust calls to cp_lexer_advance_token. (cp_parser_skip_to_closing_parenthesis, cp_parser_declaration): No need to fiddle c_lex_string_translate. (cp_parser_primary_expression, cp_parser_linkage_specification) (cp_parser_asm_definition, cp_parser_asm_specification_opt) (cp_parser_asm_operand_list, cp_parser_asm_clobber_list) Use cp_parser_string_literal. (cp_parser_attribute_list): Save and restore parser->translate_strings_p not c_lex_string_translate. (cp_parser_cache_group): Delete. (cp_parser_cache_group_1): Rename cp_parser_cache_group. Do not take a cache argument. has broken DBX_USE_BINCL support for the C++ compiler: it doesn't emit pairs of N_BINCL/N_EINCL anymore. This is indirectly visible in the C++ PCH testsuite on platforms that don't eliminate unused debug info by default (so not on Darwin): FAIL: g++.dg/pch/externc-1.C -g assembly comparison FAIL: g++.dg/pch/externc-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/static-1.C -g assembly comparison FAIL: g++.dg/pch/static-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-1.C -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-2.C -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison FAIL: g++.dg/pch/uninst.C -g assembly comparison FAIL: g++.dg/pch/uninst.C -O2 -g assembly comparison FAIL: g++.dg/pch/wchar-1.C -g assembly comparison FAIL: g++.dg/pch/wchar-1.C -O2 -g assembly comparison e.g. sparc-sun-solaris2.6 and sparc
[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 07:38 --- on the mainline I get an stack overflow in the GC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug target/13891] [3.4/4.0 Regression] support for openbsd 3.4 nonexistent
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 07:29 --- (In reply to comment #4) > Removing target milestone; this is not release-critical. Does not matter this has now been fixed, I had forgot to close it, oops. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13891
[Bug target/13891] [3.4/4.0 Regression] support for openbsd 3.4 nonexistent
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 07:28 --- Removing target milestone; this is not release-critical. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13891
[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-19 07:27 --- Closing as you reported a successful C,C++,Obj-C,Java bootstrap. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
[Bug java/18796] [4.0 Regression] gcj imports wrong superclass
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 07:21 --- Java bugs are not showstoppers; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18796
[Bug tree-optimization/19522] Fix GCC so that a nonlocal label won't appear after local labels.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 06:55 --- (In reply to comment #3) ... like a waste. Since we are going to keep the BB's around for longer in 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
[Bug tree-optimization/19522] Fix GCC so that a nonlocal label won't appear after local labels.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 06:53 --- Yes that is it. Basically we have two computed GOTO's at the beginging of the BB which is okay really since there is no way otherwise since we just remove the other BB (unless you want to create a new BB which seems like a waste really). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
[Bug tree-optimization/19522] Fix GCC so that a nonlocal label won't appear after local labels.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 06:46 --- Actually I think the verifying patch is wrong, because we can have multiple computed lables at the begining of a BB because we moved it from a different BB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From law at redhat dot com 2005-01-19 06:46 --- Subject: Re: DSE is not doing its job for global variables On Wed, 2005-01-19 at 02:44 +, dje at gcc dot gnu dot org wrote: > --- Additional Comments From dje at gcc dot gnu dot org 2005-01-19 02:44 > --- > Steven's experiments seem to demonstrate that the current DSE implementation > is > not very effective. GCC 4.0 includes RTL optimizations that will catch most > if > not all of these cases, so it is not as if this will cause GCC to miss some > optimizations. Err, umm, wrong. I checked when I wrote the original code and I just double checked tonight. The tree DSE implementation as is stands right now, today, without any improvements, will catch things which the RTL optimizers will miss. And there are some pretty simple things that can be done to make it more effective, though to be really effective we need better alias analysis. The stuff we have now sucks badly. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug tree-optimization/19522] Fix GCC so that a nonlocal label won't appear after local labels.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 06:39 --- I think the problem is in remove_bb. This is the only place where we move lables around really. basically here: block_stmt_iterator new_bsi = bsi_start (new_bb); we should just skip over the first label if there is one. I will try to test this in a little bit. -- What|Removed |Added Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From amodra at bigpond dot net dot au 2005-01-19 06:28 --- The reason for the bus error is the __exchange_and_add decrement of _M_refcount. On powerpc, lwarx and stwcx. must have an aligned effective address. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC host triplet|powerpc-linux |powerpc*-linux GCC target triplet|powerpc-linux |powerpc*-linux Last reconfirmed|-00-00 00:00:00 |2005-01-19 06:28:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug c++/18604] [3.4/4.0 Regression] Strong using lookup conflicts
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 06:17 --- Jason, are you looking at this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From bje at au1 dot ibm dot com 2005-01-19 06:05 --- Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep On Tue, Jan 18, 2005 at 09:45:48AM -, pcarlini at suse dot de wrote: > In other terms, as far as this PR is concerned, basic_string seems > ok, just you cannot create a basic_string object in memory > aligned one, as happens in ext/array_allocator/2.cc, which therefore > should be fixed. Does this behaviour seem a little bit unusual to you? You said: "You cannot create a basic_string object in memory aligned one". That is rather counter-intuitive to a user of libstdc++ who has no understanding of the implementation details of basic_string. Ben -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug tree-optimization/19522] New: Fix GCC so that a nonlocal label won't appear after local labels.
Fix GCC so that a nonlocal label won't appear after local labels. In other words, the following addition to tree_verify_flow_info should not introduce regressions. http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01191.html -- Summary: Fix GCC so that a nonlocal label won't appear after local labels. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From schlie at comcast dot net 2005-01-19 05:26 --- (In reply to comment #8) Never mind, as it's likely not worth the bother as the behavor is undefined anyway, and the existing proposal is simpler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From schlie at comcast dot net 2005-01-19 05:17 --- Actually wonder if a better solutions would be to and (&) the rhs shift count by Log2(rhs-mode-size) bit mask, thereby the resulting value will always be within 0 >= shift <= (N-1), resulting effectivly a shift modulo N, which is more similar to what hardware and would guess most machines actually do, or am I mistaken? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19511] [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-18 21:18:28 |2005-01-19 05:08:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19511
[Bug ada/19519] GNAT Bug Box when reading a program with UTF-8 encoded enumeration literals
--- Additional Comments From giovannibajo at libero dot it 2005-01-19 04:30 --- Would you please add the testcase to this bug as a file attachment? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19519
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 03:41 --- Well I think there is wrong reloc somewhere or a reloc being resolved wrongly because foo binds locally in x.c otherwise the protect is visibility is really useless otherwise (except maybe to make sure that it does not get overridden). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 03:31 --- So help out here, which is more correct the GOT or the GOTOFF?(In reply to comment #7) > Please take a closer look at the testcase. It is different from > bug 10908. Basically, main executable and DSO see different > function pointer values for the SAME function. From the linker That comment is only for the PPC bfd so it cannot apply to x86 :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 03:11 --- The difference between non protected and protected functions is the following in the asm: movl[EMAIL PROTECTED](%ebx), %eax leal[EMAIL PROTECTED](%ebx), %eax but really add -fPIC to m.c make this work, so again this looks like an ld bug (maybe it is keeping the symbol protected or something). Or gcc is doing: cmpl$foo, -4(%ebp) which is not wrong in the non pic case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-19 02:44 --- Steven's experiments seem to demonstrate that the current DSE implementation is not very effective. GCC 4.0 includes RTL optimizations that will catch most if not all of these cases, so it is not as if this will cause GCC to miss some optimizations. If the concern is performance impact, then I think that we should consider adding adding some aggressive optimizations instead of retaining DSE. Even if DSE is very fast, what does GCC gain by fewer iterations of an optimization pass that has almost no benefit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug ada/19381] ACATS c954a03 raises storage error at runtime on s390-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 02:40 --- (In reply to comment #1) > Also fails on ppc-linux with ZCX. But passes on ppc-darwin with ZCX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19381
[Bug debug/19521] [4.0 Regression] omitted stab for gcov initialization function
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-19 02:35 --- So the bug is the end stab without the start stab? Or do you think that this bit of code that corresponds not at all to any user code should have full stabs? If the later, why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 02:11 --- G++ 4.0 is correct. This declaration gives only a signed 9-bit type, independent of the ABI. Since +128 is not representable in 9 signed bits, it wraps to -128. The same issue explains the other tests. AFAICT, G++ 4.0 is following the ABI. The bump of the default ABI version (to 2) is the cause because we fixed this for version 2 of the ABI. The same goes for the empty class change. Therefore, I'm marking this as INVALID. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19 02:05 --- Created an attachment (id=7988) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7988&action=view) test case with script I get the following output from running the attached script using compilers I built before and after each of the patches listed in the previous comment. --- define with 3.2.3 use with2003-04-29 21:28 UTC PASSED define with 2003-04-29 21:28 UTC use with3.2.3 PASSED --- define with 2003-04-29 21:28 UTC use with2003-04-29 21:28 UTC PASSED --- define with 2003-04-29 21:28 UTC use with2003-04-29 21:30 UTC ./pr19448-2.sh: line 116: 26808 Aborted a.out define with 2003-04-29 21:30 UTC use with2003-04-29 21:28 UTC PASSED --- define with 2003-04-29 21:30 UTC use with2003-04-29 21:30 UTC ./pr19448-2.sh: line 118: 26832 Aborted a.out --- define with 2003-12-23 16:53 UTC use with2003-12-23 16:53 UTC ./pr19448-2.sh: line 120: 26852 Aborted a.out --- define with 2003-12-23 16:53 UTC use with2003-12-23 16:55 UTC ./pr19448-2.sh: line 122: 26872 Aborted a.out define with 2003-12-23 16:55 UTC use with2003-12-23 16:53 UTC PASSED --- define with 2003-12-23 16:55 UTC use with2003-12-23 16:55 UTC PASSED --- define with 2003-12-23 16:55 UTC use with3.4.3 PASSED define with 3.4.3 use with2003-12-23 16:55 UTC PASSED --- define with 3.2.3 use with3.4.3 ./pr19448-2.sh: line 128: 26940 Aborted a.out define with 3.4.3 use with3.2.3 ./pr19448-2.sh: line 128: 26944 Aborted a.out --- In file included from pr19448_define.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type bc.h:1: warning: the offset of `bc::m1' may not be ABI-compliant and may change in a future version of GCC In file included from pr19448_use.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type bc.h:1: warning: the offset of `bc::m1' may not be ABI-compliant and may change in a future version of GCC In file included from pr19448_define.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type In file included from pr19448_use.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type define with 3.2.3 with -Wabi use with3.4.3 with -fabi-version=1 ./pr19448-2.sh: line 131: 26964 Aborted a.out define with 3.4.3 with -fabi-version=1 use with3.2.3 with -Wabi PASSED --- -- What|Removed |Added ---
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19 02:01 --- There are two changes that affect this binary incompatibility: one changes the layout of the class, and the other changes how the bitfield is accessed. Mark, did this change on purpose and is it covered by the C++ ABI? The first change is: --- gcc/gcc/cp/ChangeLog --- 2003-04-29 Mark Mitchell <[EMAIL PROTECTED]> PR c++/10549 * class.c (layout_class_type): Mark overlong bitfields as having the maximum size permitted by their type, after layout. The second change is: --- gcc/gcc/ChangeLog --- 2003-12-23 Mark Mitchell <[EMAIL PROTECTED]> * c-common.c (flag_abi_version): Default to 2. * c-cppbuiltin.c (c_cpp_builtins): Define __GXX_ABI_VERSION uniformly for versions above 2. * doc/invoke.texi: Update documentation for -fabi-version. --- gcc/gcc/cp/ChangeLog --- 2003-12-23 Mark Mitchell <[EMAIL PROTECTED]> * cp-lang.c (cp_expr_size): Return zero for empty classes. * cp-tree.h (warn_if_uknown_interface): Remove unused function. * decl2.c (warn_if_unknown_interface): Likewise. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From hjl at lucon dot org 2005-01-19 01:47 --- Please take a closer look at the testcase. It is different from bug 10908. Basically, main executable and DSO see different function pointer values for the SAME function. From the linker /* Will references to this symbol always reference the symbol in this object? STV_PROTECTED is excluded from the visibility test here so that function pointer comparisons work properly. Since function symbols not defined in an app are set to their .plt entry, it's necessary for shared libs to also reference the .plt even though the symbol is really local to the shared lib. */ On many architectures, the function pointer != the address of the function body. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug ada/19385] ACATS c974012 fails at runtime on ppc-linux/darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 01:45 --- on ppc-darwin with ZCX enabled this passes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19385
[Bug java/19368] GCJ doesn't build working "hello world" on OS X
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 01:43 --- This was fixed on somewhere between the 10th and 11th. By one of the patches listed in: http://gcc.gnu.org/ml/gcc-regression/2005-01/txt00012.txt The current time for Hello World is: Hello! 0.760u 0.110s 0:01.53 56.8% 0+0k 1+1io 0pf+0w -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19368
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From law at redhat dot com 2005-01-19 01:43 --- Subject: Re: DSE is not doing its job for global variables On Wed, 2005-01-19 at 01:34 +, steven at gcc dot gnu dot org wrote: > --- Additional Comments From steven at gcc dot gnu dot org 2005-01-19 > 01:34 --- > DSE2 also does almost nothing, so I just went ahead and posted a proposal > to just disable DSE: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01183.html DSE is reasonably fast. How about we just disable one pass rather than disabling it completely. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19 01:34 --- DSE2 also does almost nothing, so I just went ahead and posted a proposal to just disable DSE: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01183.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug debug/19521] [4.0 Regression] omitted stab for gcov initialization function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 01:16 --- (In reply to comment #2) > This is a regression from 3.3; I think the cause is this line in cgraphunit.c > (cgraph_build_static_cdtor): (approximately line 1847) > > DECL_IGNORED_P (decl) = 1; DECL_IGNORED_P was added with: 2004-07-01 Richard Henderson <[EMAIL PROTECTED]> * cgraph.h (cgraph_build_static_cdtor): Declare. * cgraphunit.c (cgraph_build_static_cdtor): New. * c-objc-common.c (build_cdtor): Use it. * coverage.c (create_coverage): Likewise. * libfuncs.h (LTI_gcov_init, gcov_init_libfunc): Remove. * optabs.c (init_optabs): Don't set gcov_init_libfunc. I don't think IGNORED should be set on this decl as it was not set before the patch above -- What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|powerpc-apple-darwin| GCC host triplet|powerpc-apple-darwin| Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2005-01-19 01:16:15 date|| Summary|omitted stab for gcov |[4.0 Regression] omitted |initialization function |stab for gcov initialization ||function Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug debug/19521] omitted stab for gcov initialization function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 01:06 --- Does -gfull make this work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug bootstrap/19517] --enable-languages=c,ada enables Ada twice, and possibly breaks gcc/options.h in the build directory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:57 --- Not a gcc bug so closing. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19517
[Bug target/10908] Addresses of protected symbols don't work right on ia32
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:56 --- *** Bug 19520 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10908
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:56 --- protected always binds local as you cannot override it so the bug is in the linker/asm. *** This bug has been marked as a duplicate of 10908 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug bootstrap/19517] --enable-languages=c,ada enables Ada twice, and possibly breaks gcc/options.h in the build directory
--- Additional Comments From bauhaus at futureapps dot de 2005-01-19 00:50 --- Argh, yes. There was another ada subdirectory, my fault, sorry. After removing it, options.h now looks good, no more duplicates. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19517
[Bug debug/19521] omitted stab for gcov initialization function
--- Additional Comments From stuart at apple dot com 2005-01-19 00:49
---
This is a regression from 3.3; I think the cause is this line in cgraphunit.c
(cgraph_build_static_cdtor): (approximately line 1847)
DECL_IGNORED_P (decl) = 1;
Deleting this line "fixes" the symptom, but I believe the right fix lies in
dbxout.c.
The start-function stab comes from dbxout.c(dbxout_symbol), near line 2346:
/* Ignore nameless syms, but don't ignore type tags. */
if ((DECL_NAME (decl) == 0 && TREE_CODE (decl) != TYPE_DECL)
|| DECL_IGNORED_P (decl))
DBXOUT_DECR_NESTING_AND_RETURN (0);
This check causes the omission of the start-function stab. The corresponding
end-function stab comes from dbxout.c (dbxout_function_end), near line 465:
#ifdef DBX_OUTPUT_NFUN
DBX_OUTPUT_NFUN (asm_out_file, lscope_label_name, current_function_decl);
#else
=>fprintf (asm_out_file, "%s\"\",%d,0,0,", ASM_STABS_OP, N_FUN);
assemble_name (asm_out_file, lscope_label_name);
putc ('-', asm_out_file);
assemble_name (asm_out_file, XSTR (XEXP (DECL_RTL (current_function_decl), 0),
0));
fprintf (asm_out_file, "\n");
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:47 --- This is really a dup of bug 10908. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From hjl at lucon dot org 2005-01-19 00:41 --- They aren't the same. It is function pointer vs. function. The other looks like a linker bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug debug/19521] omitted stab for gcov initialization function
--- Additional Comments From stuart at apple dot com 2005-01-19 00:40 --- Created an attachment (id=7986) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7986&action=view) gcov-1.c testcase Attaching the testcase for convenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug debug/19521] New: omitted stab for gcov initialization function
gcov support entails an initialization function named "__GLOBAL__I_0_noop".
GCC omits function-begin stab for this function.
Here is the commandline:
[morris:/Volumes/sandbox/stuart] hasting2%
\/Volumes/sandbox/stuart/gcc.fsf.obj/gcc/xgcc -B
\/Volumes/sandbox/stuart/gcc.fsf.obj/gcc -g gcov.c -fprofile-arcs \
-ftest-coverage -S
Given the .s file from the above, here is a check of the output:
[morris:/Volumes/sandbox/stuart] hasting2% egrep 'noop|main' gcov.s
.globl _noop
_noop:
.stabs "noop:F(0,1)=(0,1)",36,0,7,_noop
.stabs "",36,0,0,Lscope0-_noop
.globl _main
_main:
bl _noop
.stabs "main:F(0,2)=r(0,2);-2147483648;2147483647;",36,0,11,_main
.stabn 192,0,0,_main
.stabs "",36,0,0,Lscope1-_main
__GLOBAL__I_0_noop:
.stabs "",36,0,0,Lscope2-__GLOBAL__I_0_noop
.long __GLOBAL__I_0_noop
.long __GLOBAL__I_0_noop
[morris:/Volumes/sandbox/stuart] hasting2%
The 'stabs "",36' record seems to signify the end-of-the __GLOBAL__I_0_noop
function. The matching start-function record is missing; compare with the noop
and main functions.
The testcase is from the GCC testsuite: gcc/testsuite/gcc.misc-tests/gcov-1.c
gcov.c
Since it's short, here is the testcase:
/* Test Gcov basics. */
/* { dg-options "-fprofile-arcs -ftest-coverage" } */
/* { dg-do run { target native } } */
void noop ()
{
}
int main ()
{
int i;
for (i = 0; i < 10; i++) /* count(11) */
noop ();/* count(10) */
return 0; /* count(1) */
}
/* { dg-final { run-gcov gcov-1.c } } */
--
Summary: omitted stab for gcov initialization function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin
GCC host triplet: powerpc-apple-darwin
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From hjl at lucon dot org 2005-01-19 00:35 --- The same bug also happen on i686-pc-linux-gnu: gcc -fPIC -c -o x.o x.c gcc -shared -o libx.so x.o gcc -o foo m.c libx.so -Wl,-rpath,. ./foo called from main foo_p: 0x80483e4 called from shared foo: 0x111524 shared foo: 0x111524 shared foo: 0x111524 called from shared foo_p: 0x80483e4 shared foo: 0x111524 shared foo: 0x111524 called from main foo: 0x80483e4 got from main foo: 0x111524 Function pointer `foo' are't the same in DSO and main -- What|Removed |Added GCC target triplet|x86_64-unknown-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:34 --- Isn't this just binutils ld/584? http://sources.redhat.com/bugzilla/show_bug.cgi?id=584 Alan M. claims this is a ld bug rather than a gcc bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From hjl at lucon dot org 2005-01-19 00:27 --- Created an attachment (id=7985) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7985&action=view) A testcase With the new linker, I got [EMAIL PROTECTED] x86_64-3]$ make gcc -fPIC -c -o x.o x.c gcc -shared -o libx.so x.o /usr/local/bin/ld: x.o: relocation R_X86_64_PC32 against `foo' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [libx.so] Error 1 With the old linker, I got [EMAIL PROTECTED] x86_64-3]$ make CC="gcc -B/usr/bin/" gcc -B/usr/bin/ -fPIC -c -o x.o x.c gcc -B/usr/bin/ -shared -o libx.so x.o gcc -B/usr/bin/ -o foo m.c libx.so -Wl,-rpath,. ./foo called from main foo_p: 0x400610 called from shared foo: 0x2a9566d8d8 shared foo: 0x2a9566d8d8 shared foo: 0x2a9566d8d8 called from shared foo_p: 0x400610 shared foo: 0x2a9566d8d8 shared foo: 0x2a9566d8d8 called from main foo: 0x400610 got from main foo: 0x2a9566d8d8 Function pointer `foo' are't the same in DSO and main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19520] New: protected function pointer doesn't work right
Protected function pointer doesn't work right. For pointer to protected function, gcc should treat it as if it is normal. -- Summary: protected function pointer doesn't work right Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bernie at develer dot com 2005-01-19 00:18
---
(In reply to comment #3)
A quick informal review.
> if (GET_CODE (operands[2]) == CONST_INT)
> {
> int k;
>
> if (!len)
> len = &k;
> !
This line contains spurious whitespace.
> ! if ( (INTVAL(operands[2]) < 0) || (INTVAL(operands[2]) > 7) )
The coding standard requires a space between INTVAL and the
opening parenthesis.
Also remember to replace "<" with "<="!
> !{ /* illegal shift count */
> ! *len = 0;
> ! return "";
> !}
The comment should stay on its own line, with
capitalized initial, a full stop (".") at the
end, followed by *two* whitespaces.
This also applies to the other hunks.
> const char *
> lshrhi3_out (rtx insn, rtx operands[], int *len)
> {
> if (GET_CODE (operands[2]) == CONST_INT)
> ! {
> int scratch = (GET_CODE (PATTERN (insn)) == PARALLEL);
> int ldi_ok = test_hard_reg_class (LD_REGS, operands[0]);
> int k;
This hunk adds spurious whitespace after the opening brace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug ada/19519] New: GNAT Bug Box when reading a program with UTF-8 encoded enumeration literals
The following program triggers the bug box when encoded as UTF-8. It runs fine when used with Latin-1 characters. The compiler can test the robustness of your system if you use iconv to encode the source text in EUC-JP and then try to compile with -gnatiw -gnatWe. (I guess that the characters below aren't used very frequently in EUC-JP coded Ada source but still something seems to be looping and consuming lots of memory in this case.) with Ada.Text_IO; use Ada.Text_IO; --with Ada.Wide_Text_IO; use Ada.Wide_Text_IO; -- same effect procedure oeaeue is type People is (Späherin, -- a umlaut -- Pförtner, -- o umlaut -- Schüler, -- u umlaut -- Spieß, -- sharp s Jedermann ); package People_IO is new Enumeration_IO(People); begin for p in People'range loop People_IO.put(p); new_line; end loop; end oeaeue; cd /tmp/ gnatmake -gnatiw -gnatW8 oeaeue.adb gcc-3.4 -c -gnatiw -gnatW8 oeaeue.adb +===GNAT BUG DETECTED==+ | 3.4.2 (Debian 3.4.2-2) (i486-pc-linux-gnu) Constraint_Error s-wchcnv.adb:150 explicit raise| | Error detected at oeaeue.adb:13:4| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-3.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. oeaeue.adb list may be incomplete compilation abandoned gnatmake: "oeaeue.adb" compilation error Compilation exited abnormally with code 4 at Wed Jan 19 01:02:43 I've got the same results using GNAT 3.15p, and GNAT 4.0.0. (20041203) Linux strudel 2.4.18 #1 Fri May 2 17:22:29 CEST 2003 i686 GNU/Linux -- Summary: GNAT Bug Box when reading a program with UTF-8 encoded enumeration literals Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19519
[Bug middle-end/19329] [3.4 Regression] Bitfield operations cause shifts with 0-count to slip through backends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:12 --- (In reply to comment #8) > The shift with zero comes from regmove. Well I did figure out where the shift with zero came from see above but why it comes about I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug middle-end/19329] [3.4 Regression] Bitfield operations cause shifts with 0-count to slip through backends
--- Additional Comments From bernie at develer dot com 2005-01-19 00:11 --- I'm no longer in charge for this bug. -- What|Removed |Added AssignedTo|bernie at develer dot com |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bernie at develer dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-15 05:53:55 |2005-01-19 00:09:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 00:07 --- This is basically PR 18191 but for unions this time, the struct/array part has been fixed. Note I think the following patch caused it: 2004-01-28 Richard Henderson <[EMAIL PROTECTED]> PR opt/13798 -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug middle-end/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bernie at develer dot com 2005-01-19 00:06 --- Oops, I forgot this bug should stay open until someone figures out why GCC 3.4 leaks through insns with a 0 shift count. I've reclassified the bug as affecting the middle-end. -- What|Removed |Added Status|RESOLVED|REOPENED Component|target |middle-end Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bernie at develer dot com 2005-01-19 00:04 --- *** Bug 19329 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bernie at develer dot com 2005-01-19 00:03 --- (In reply to comment #11) > By the way at #19293, you will also find a patch suggestion that should be > eaysily adapted to all of the present shifting problems. I agree PR19293 is a superset of this bug, so I'll close it and withdraw my (already approved) patch. Could you update your patch with a test for <= 0? Please post it in gcc-patches, with me and Marek Michalkiewicz <[EMAIL PROTECTED]> in Cc. I will take care to install your patch in CVS as soon as it gets approved. *** This bug has been marked as a duplicate of 19293 *** -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 00:02:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
-- What|Removed |Added Attachment #7984|text/x-csrc |text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug pending/19514] bogus warning about complex "integer" types from typedef
--- Additional Comments From joseph at codesourcery dot com 2005-01-18 23:52 --- Subject: Re: bogus warning about complex "integer" types from typedef On Tue, 18 Jan 2005, stevenj at fftw dot org wrote: > Okay, I guess I see what you mean. "double" in "double _Complex" is > arguably not a "type", but rather a type-specifier as defined in 6.7.2, > and the "each list of type-specifiers shall be one of the following sets", > a prescribed list of combinations that does not include typedefs. Yes, that's my point. "double _Complex" is one valid list of type specifiers. "typedef name" is another, listed separately - a single type specifier, not part of any valid combinations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug libgcj/19512] Optional JNI error checking
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-18 23:50:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19512
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 23:49 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug tree-optimization/19516] missed optimization (bool)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 23:47 --- Confirmed, the issue is that DOM does not recognizes that b = *a; if(b) ... c = *a; if (c) ... can be changed (note the lacking of the != 0 which would be required for int/char, etc.). -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||alias, missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-01-18 23:47:47 date|| Summary|missed optimization |missed optimization (bool) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19516
[Bug target/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-01-18 23:43 --- Sorry for this: In my posting above, I have misspelled the bug number. I wanted to refer you to bug #19293 (and not #19239, luckyly the number of possible permutations is countable). By the way at #19293, you will also find a patch suggestion that should be eaysily adapted to all of the present shifting problems. Yours again, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug bootstrap/19517] --enable-languages=c,ada enables Ada twice, and possibly breaks gcc/options.h in the build directory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 23:42 --- This works for me also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19517
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-18 23:37 --- I looked at the constructor gimplification stuff recently. Lemme see if there's an easy fix I can figure out. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug target/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-01-18 23:35 --- I have the impression that Bug #19329 is the same as bug #19239 (as one might think already when looking at the similarity of the numbers :-) ) 19239, howeverr so far has addressed the issue of *negative* and other really illegal shift counts. In a patch treating both problems correctly, one should possibly implement both: Treatment of negative and other illegal shift counts and positive shift counts. Yours, Björn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug bootstrap/19517] --enable-languages=c,ada enables Ada twice, and possibly breaks gcc/options.h in the build directory
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-18 23:34 --- Just to be sure: check that you don't have 2 ada subdirectories in srcdir/gcc. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19517
[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
--- Additional Comments From falk at debian dot org 2005-01-18 23:34 --- Created an attachment (id=7984) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7984&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug target/19518] New: [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
gcc version 4.0.0 20050116 (experimental) % gcc -O2 fbmmx.c -c -c fbmmx.c: In function 'fbCompositeSolid_nxmmx': fbmmx.c:56: error: unrecognizable insn: (insn 332 125 128 3 (set (reg:V4HI 4 $4) (const_vector:V4HI [ (const_int 255 [0xff]) (const_int 255 [0xff]) (const_int 255 [0xff]) (const_int 255 [0xff]) ])) -1 (nil) (nil)) fbmmx.c:56: internal compiler error: in extract_insn, at recog.c:2020 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I'm not quite sure why this happens. Maybe the builtin folding from PR 18836 would help, but I'm too tired to try right now... -- Summary: [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug bootstrap/19517] New: --enable-languages=c,ada enables Ada twice, and possibly breaks gcc/options.h in the build directory
In a fresh directory, I did ../src/gcc/configure --prefix=/opt/GCC/4-01 \ --disable-nls \ --enable-languages=ada,c This gives ... checking for MPFR... yes The following languages will be built: c,ada,ada *** This configuration is not supported in the following subdirectories: ... Note the duplication of "ada". Might this have to do with the new_enable_languages in configure? make boostrap builds a stage1 compiler. The stage1 compiler stops with an error, in options.h. In options.h, CL_Ada is defined twice: #define CL_Ada(1 << 0) #define CL_Ada(1 << 1) #define CL_C (1 << 2) #define CL_CXX(1 << 3) #define CL_ObjC (1 << 4) #define CL_ObjCXX (1 << 5) There is a repeated warning during the build of the stage1 compiler. As warnings are treated as errors later, this (luckily?) stops the build process. (options.h announces to have been generated by opts.sh, which I couldn't find. Is that o.K.?) CC is gcc-3.4.2 on Debian testing, with Ada enabled. -- Summary: --enable-languages=c,ada enables Ada twice, and possibly breaks gcc/options.h in the build directory Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19517
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-01-18 23:27 --- Hi, I have just stepped over a patch suggested by Bernardo Innocenti in order to treat the case of "shift_count == 0" correctly. My presently suggested patch (above) only treats the case of negative shift counts. I did not realize that the case of "0" also is buggy. So for treating the shifting problem comprehensively, one should combine both. This could be done by replacing the checks for "< 0" in my patch by checks for "<= 0". Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18
23:23 ---
Hmm, the gimplifier is messing up (again, there was another bug like this).
Here is the reduced testcase which shows the problem:
typedef union {
char a2[8];
}aun;
void abort (void);
int main(void)
{
aun a = {{0}};
if (a.a2[2] != 0)
abort ();
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-01-18 23:23:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug pending/19514] bogus warning about complex "integer" types from typedef
--- Additional Comments From stevenj at fftw dot org 2005-01-18 23:15 --- Subject: Re: bogus warning about complex "integer" types from typedef Okay, I guess I see what you mean. "double" in "double _Complex" is arguably not a "type", but rather a type-specifier as defined in 6.7.2, and the "each list of type-specifiers shall be one of the following sets", a prescribed list of combinations that does not include typedefs. What an annoyance; one has to define R via the preprocessor, then, in order to use consistent floating-point precisions everywhere in a program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-18 23:12 --- > This is a midde-end problem (investing further) > but we end up with an empty CONSTRUTOR and the middle-end is not expanding it > correctly for the union. Right, the 3.4.x back-end used to zero the whole aggregate if the constructor was lacking elements. And this is really critical according to the criterion. -- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 23:06 --- This is a midde-end problem (investing further) but we end up with an empty CONSTRUTOR and the middle-end is not expanding it correctly for the union. -- What|Removed |Added Severity|critical|normal Component|c |middle-end Keywords||wrong-code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug pending/19514] bogus warning about complex "integer" types from typedef
--- Additional Comments From stevenj at fftw dot org 2005-01-18 22:56 --- Subject: Re: bogus warning about complex "integer" types from typedef On Tue, 18 Jan 2005, joseph at codesourcery dot com wrote: >> typedef double R; >> typedef R _Complex C; > > This is not valid code; you can't use _Complex together with a typedef, > only together with "float", "double" or "long double" in one of the forms > listed in C99. My copy of the C99 draft standard states (sec. 6.7.7): "A typedef declaration does not introduce a new type, only a synonym for the type so specified." According to this, "R complex" should be a synonym for "double complex", and therefore should be valid code. What justification do you have for claiming otherwise? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug pending/19514] bogus warning about complex "integer" types from typedef
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 22:52 --- Invalid based on JSM's comment. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
--- Additional Comments From ch at csh-consult dot dk 2005-01-18 22:32 --- Yes I have, but I was lazy and wrote it in C#. I've put them up for download here: http://212.242.245.122/100files.tar.gz (2.5MB) There is also the command to invoke gcc (run.bat) No -O flag is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug tree-optimization/19507] missed tree-optimization
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-18 22:29 --- Done. PR19516. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19507
[Bug tree-optimization/19516] New: missed optimization
Actually a side-bug of 19507. The testcase
void bar(void);
void foo(const _Bool *flag)
{
if (*flag)
bar();
if (*flag)
bar();
}
Should be transformed to (at the tree level):
if (!*flag)
return;
bar();
if (*flag)
bar();
this is only done at the RTL level at the moment.
Andrew Pinski reports this works, if we exchange _Bool
for int/short/char.
--
Summary: missed optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19516
[Bug pending/19514] bogus warning about complex "integer" types from typedef
--- Additional Comments From joseph at codesourcery dot com 2005-01-18 22:20 --- Subject: Re: New: bogus warning about complex "integer" types from typedef On Tue, 18 Jan 2005, gcc-bugzilla at gcc dot gnu dot org wrote: > When compiling the following two lines: > > typedef double R; > typedef R _Complex C; This is not valid code; you can't use _Complex together with a typedef, only together with "float", "double" or "long double" in one of the forms listed in C99. The misleading diagnostic is a bug, which has been fixed in mainline: you now get the error t.c:2: error: two or more data types in declaration specifiers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug c/19515] New: [4.0 Regression] Violation of C99 6.7.8 §21
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long upad64_t;
typedef struct _pthread_mutex {
struct {
uint16_t__pthread_mutex_flag1;
uint8_t __pthread_mutex_flag2;
uint8_t __pthread_mutex_ceiling;
uint16_t__pthread_mutex_type;
uint16_t__pthread_mutex_magic;
} __pthread_mutex_flags;
union {
struct {
uint8_t __pthread_mutex_pad[8];
} __pthread_mutex_lock64;
struct {
uint32_t __pthread_ownerpid;
uint32_t __pthread_lockword;
} __pthread_mutex_lock32;
upad64_t __pthread_mutex_owner64;
} __pthread_mutex_lock;
upad64_t __pthread_mutex_data;
} pthread_mutex_t;
void foo(void)
{
pthread_mutex_t tmp = {{0, 0, 0, 0, 0x4d58}, {{{0}}}, 0};
}
On SPARC64 at -O0:
sth %g0, [%fp+2007]
stb %g0, [%fp+2009]
stb %g0, [%fp+2010]
sth %g0, [%fp+2011]
sethi %hi(19456), %g1
or %g1, 344, %g1
sth %g1, [%fp+2013]
stb %g0, [%fp+2015]
stx %g0, [%fp+2023]
On AMD64 at -O0:
movw$0, -32(%rbp)
movb$0, -30(%rbp)
movb$0, -29(%rbp)
movw$0, -28(%rbp)
movw$19800, -26(%rbp)
movb$0, -24(%rbp)
movq$0, -16(%rbp)
Note the 'b' on the last but one line in both cases: __pthread_mutex_pad is not
initialized according to the ISO C99 rules. This is critical on Solaris 64-bit
as it affects POSIX thread support.
The C++ and Objective-C compilers are also affected.
--
Summary: [4.0 Regression] Violation of C99 6.7.8 §21
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-18 22:05 --- Subject: Bug 13470 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-18 22:05:08 Modified files: gcc/ada: ChangeLog a-stunau.adb Log message: PR ada/13470 * a-stunau.adb (Get_String): Don't return U.Reference, but Ret that is set to the new string. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.428.2.15&r2=1.428.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-stunau.adb.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.5&r2=1.5.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug ada/19456] [4.0 regression] ada bootstrap failure on alpha-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 22:03 --- Can you try it now that PR 13470 is fixed on the mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19456
[Bug pending/19514] New: bogus warning about complex "integer" types from typedef
NOTE: Defaulting component because reported component no longer exists When compiling the following two lines: typedef double R; typedef R _Complex C; with the flags -std=c99 -pedantic, gcc gives the bogus warning: foo.c:2: warning: ISO C does not support complex integer types (Code based on the above definitions seems to work, however.) Environment: System: Linux ab-initio 2.4.25 #1 SMP Fri Jul 9 17:11:47 EDT 2004 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../configure --prefix=/usr/local/gcc-3.4 --enable-languages=c,c++,f77 How-To-Repeat: Create a file foo.c with the above two lines, and compile with gcc -std=c99 -pedantic -c foo.c --- Additional Comments From stevenj at ab-initio dot mit dot edu 2005-01-18 22:02 --- Fix: Simply ignoring the warning seems to work okay. -- Summary: bogus warning about complex "integer" types from typedef Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: stevenj at ab-initio dot mit dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 22:02 --- Do you have a program which generates those files? Also is this at -O0 or -O2? -- What|Removed |Added Keywords||memory-hog Summary|High memory usage when |[IMA] High memory usage when |compiling multiple files at |compiling multiple files at |a time |a time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug tree-optimization/19507] missed tree-optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 22:00 --- (In reply to comment #4) > Subject: Re: missed tree-optimization > > this is done at RTL level, but not at tree level. I should file a > separate bug for this one, really. Yes because if we change flag to be int/short/char it works which is a little werid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19507
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-18 22:00 --- Subject: Bug 13470 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-18 22:00:13 Modified files: gcc/ada: ChangeLog a-stunau.adb Log message: PR ada/13470 * a-stunau.adb (Get_String): Don't return U.Reference, but Ret that is set to the new string. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.626&r2=1.627 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-stunau.adb.diff?cvsroot=gcc&r1=1.5&r2=1.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug c/19513] New: High memory usage when compiling multiple files at a time
Passing 250 or so files from a larger software project (about 3MB of
sourcecode) to gcc at a time makes gcc use more than 400MB of memory. Possible
more as I had to stop the compilation.
I created a much simpler example. 100 equal .c files each containing:
static void mainX() {}
where X varies from 1 to 1. This gives me a slightly different behaviour.
Compiling only one of the files consumes about 60MB memory. Compiling all of
the 100 files consumes up to 142MB of memory. Then gcc crashes.
If I'm understanding how gcc compiles multiple files at the same time
correctly, then gcc should release most of the memory used for compiling one
file before it begins compiling the next. Is this correct? If so, then I would
expect overall memory usage during compilation of the 100 equal .c files to be
not much more than 60MB.
Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
Let me know if you need more information.
--
Summary: High memory usage when compiling multiple files at a
time
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ch at csh-consult dot dk
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug target/19511] [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-18 21:52 --- (In reply to comment #4) > Confirmed, reduced testcase (20 lines :) ): One more thing, the options to reproduce this with a normaly compiled compiler: -march=pentium3 -O1 -m32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19511
[Bug libgcj/19512] Optional JNI error checking
--- Additional Comments From mark at gcc dot gnu dot org 2005-01-18 21:51 --- Some other things that could be checked: - Using wrongly formatted JNI descriptor strings in Get[Static](Field|Method)ID() (note '.' is not allowed, must be '/'). - Using a JNIEnv in another thread. - LocalReferences that are used after a native method returns. - Leaking strings/chars gotten from GetString(UTF)Chars (or JCL_jstring_to_cstring in libclasspath) - Using non-existing Field or Method ids -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19512
[Bug libstdc++/19510] [4.0 regression] Warning using list iterators
--- Additional Comments From pcarlini at suse dot de 2005-01-18 21:50 --- > So the patch is ABI-neutral. Great! (many thanks for the interesting explanation, Gaby) Therefore, if Volker is willing to regtest the complete fix and post it... P.S. Too bad that only -O3 triggers the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19510
[Bug libstdc++/19510] [4.0 regression] Warning using list iterators
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-18 21:46 --- Subject: Re: [4.0 regression] Warning using list iterators "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | > I think your patch is OK and should be applied. | | First blush, I agree. Is it 100% safe wrt the ABI? (I remember tricky details | only about copy constructor and assignment, actually) Careless addition of constructors or destructors can indeed change an ABI. However in the specific case at hand, the addition is that of a non-copy default constructor whose only potential impact is that of changing a POD to non-POD. However, both _List_iterator and _List_const_iterator are already non-POD as they have a constructor to convert from a _List_node_base*. So the patch is ABI-neutral. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19510
[Bug debug/16261] [3.4 regression] ICE: output_die, at dwarf2out.c:6628
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-18 21:41 --- Patch applied. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16261
[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-01-18 21:40 ---
Indeed the problem seems to be related to a problem during the reload pass. I
now think, that I have found a solution for the original problem that needs a
tiny change in the back-end.
DJ Delorie wrote me:
>avr bug - GENERAL_REGS allows $r24 to contain a DImode, but you cannot
>access the 5th byte of it via a subreg, because HARD_REGNO_MODE_OK
>doesn't permit QImodes in $r29. This disqualifies GENERAL_REGS.
Since anyway any useful function using long longs will require the frame
pointer, there is (in my opinion) no use for DI objects in the upper register
range. The following patch restricts DI objects to registers with smaller
indices. When using this patch, I succeed in building the gcc-4.0.0 snapshot
dating from the 12th of december 04 without problems. This snapshot previously
did not compile with the symptoms mentioned above.
For a later head revision, unfortunately something else and independent seems
to be broken. I'll check today's head this evening and report on this, as soon
as I have analyzed this more in detail.
Patch that needs to be applied to /gcc/config/avr/avr.c
Reported differences are differences against the 4.0.0-20041212 snapshot.
--- avr.c.old 2005-01-18 22:24:44.942273520 +0100
+++ avr.c.new 2005-01-18 22:19:19.0 +0100
@@ -5116,40 +5116,47 @@
register number REGNO. On the enhanced core, anything larger than
1 byte must start in even numbered register for "movw" to work
(this way we don't have to check for odd registers everywhere). */
int
avr_hard_regno_mode_ok (int regno, enum machine_mode mode)
{
/* Bug workaround: recog.c (peep2_find_free_register) and probably
a few other places assume that the frame pointer is a single hard
register, so r29 may be allocated and overwrite the high byte of
the frame pointer. Do not allow any value to start in r29. */
if (regno == REG_Y + 1)
return 0;
/* Reload can use r28:r29 for reload register and for frame pointer
in one insn. It's wrong. We must disable it. */
if (mode != Pmode && reload_in_progress && frame_pointer_required_p ()
&& regno <= REG_Y && (regno + GET_MODE_SIZE (mode)) >= (REG_Y + 1))
return 0;
+ if (mode == DImode)
+ { if ( (regno < 20) && (!(regno & 1)) )
+ return 1;
+ else
+ return 0;
+ }
+
if (mode == QImode)
return 1;
/* if (regno < 24 && !AVR_ENHANCED)
return 1;*/
return !(regno & 1);
}
/* Returns 1 if X is a valid address for an I/O register of size SIZE
(1 or 2). Used for lds/sts -> in/out optimization. Add 0x20 to SIZE
to check for the lower half of I/O space (for cbi/sbi/sbic/sbis). */
int
avr_io_address_p (rtx x, int size)
{
return (optimize > 0 && GET_CODE (x) == CONST_INT
&& INTVAL (x) >= 0x20 && INTVAL (x) <= 0x60 - size);
}
/* Returns nonzero (bit number + 1) if X, or -X, is a constant power of 2. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
