[Bug debug/39372] [4.3/4.4 Regression] Missing DW_AT_location for constructor static variable
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-06 09:46 --- Created an attachment (id=17404) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17404action=view) gcc44-pr39372.patch Patch I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39372
[Bug debug/39387] [4.4 Regression] Wrong DW_AT_decl_line on DW_TAG_imported* for using directives in C+ functions
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-06 09:48 --- Subject: Bug 39387 Author: jakub Date: Fri Mar 6 09:48:25 2009 New Revision: 144666 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144666 Log: PR debug/39387 * dwarf2out.c (dwarf2out_imported_module_or_decl_1): For IMPORTED_DECL take locus from its DECL_SOURCE_LOCATION instead of input_location. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39387
[Bug debug/39385] ICE in gen_type_die_with_usage
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-06 10:01 --- Indeed. 0 shouldn't match T U::* -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |debug Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2009-03-06 10:01:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39385
[Bug debug/39387] [4.4 Regression] Wrong DW_AT_decl_line on DW_TAG_imported* for using directives in C+ functions
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-06 10:31 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39387
[Bug c/39375] asm with a =X output overwrites the output
--- Comment #3 from balrogg at gmail dot com 2009-03-06 10:34 --- (In reply to comment #2) You need to use a memory clobber instead. =X (params[1]) says to GCC that the asm operand 0 should be stored to params[1], which it does (it allocates %eax to it). Note that =r doesn't produce the useless move. Neither does =X (params) if params is an integer. Note also that the documentation uses =X (sum) as an example of adding a dependency on the asm statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39375
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #9 from rob1weld at aol dot com 2009-03-06 11:07 --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #6) After the workaround we get 10 failures on i686 and 33 failures on x86_64 when compiling trunk revision 144629, results here: Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00511.html Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00598.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug tree-optimization/39367] [4.4 Regression] ICE at tree-inline.c:1042 with -O
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-06 12:48 ---
The problem is that mark_all_vars_used only marks blocks used by actual code,
but on the testcase the only reference to a one BLOCK is from TYPE_MAX_VALUE
(TYPE_DOMAIN (type)) containing a PLUS_EXPR with that BLOCK as TREE_BLOCK.
IMHO either we need to talk also types in
remove_unused_locals/mark_all_vars_used, or we should drop TREE_BLOCK stuff
from expressions referenced from types during gimplification (do we actually
ever care about TREE_BLOCK of expressions in TYPE_{MIN,MAX}_VALUE,
TYPE_SIZE{,_UNIT}, DECL_SIZE{,_UNIT} etc.?), or during inlining we should just
ignore remapping of blocks for these expressions. If a BLOCK isn't found for
them, no big deal, just drop it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39367
[Bug tree-optimization/39367] [4.4 Regression] ICE at tree-inline.c:1042 with -O
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-06 12:58 --- Yeah, we should drop TREE_BLOCK from anything not in stmts. Definitely for expressions in the types sizes and domains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39367
[Bug middle-end/39390] New: [4.4 regression] Bogus aliasing warning with std::set
Another problem with aliasing: The following code snippet triggers a bogus
warning when compiled on trunk with -O -Wall:
==
#includeset
struct A
{
A() : i() {}
int i;
};
struct B
{
bool operator() (const A x, const A y) const { return x.i y.i; }
};
void foo()
{
std::setA, B s;
s.insert(A());
}
==
bug.cc: In function 'void foo()':
bug.cc:11: warning: dereferencing pointer '__x.15' does break strict-aliasing
rules
.../gcc-4.4-20090305/include/c++/4.4.0/bits/stl_tree.h:530: note: initialized
from here
bug.cc:11: warning: dereferencing pointer '__x.15' does break strict-aliasing
rules
.../gcc-4.4-20090305/include/c++/4.4.0/bits/stl_tree.h:530: note: initialized
from here
This probably results in wrong code generation.
--
Summary: [4.4 regression] Bogus aliasing warning with std::set
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, diagnostic
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug middle-end/39390] [4.4 regression] Bogus aliasing warning with std::set
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug middle-end/39390] [4.4 regression] Bogus aliasing warning with std::set
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-03-06 13:10 --- Created an attachment (id=17405) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17405action=view) Partially reduced testcase Somewhat reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug middle-end/39390] [4.4 regression] Bogus aliasing warning with std::set
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-03-06 13:27 --- Oops, typo: I meant the bug is triggered with -O3 -Wall. The reduced testcase already triggers the warning with -O2 -Wall thanks to some additional inlines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug middle-end/39390] [4.4 regression] Bogus aliasing warning with std::set
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-06 13:36 ---
Confirmed with the reduced testcase only, at -O2 -Wall. The warning happens
after PTA triggered by SRA.
Relevant constraints:
__y_7 = s.64+64
D.2839_21 = __y_7
__x.8_43 = D.2839_21
and code:
D.2839_21 = __y_7-D.2545;
D.2832_22 ={v} 0B-D.2545;
if (D.2832_22 != 0B)
goto bb 6;
else
goto bb 4;
bb 4:
D.2888_42 = __y_7-D.2545;
if (D.2839_21 == D.2888_42)
goto bb 6;
else
goto bb 5;
bb 5:
__x.8_43 = (const struct _Rb_tree_node *) D.2839_21;
D.2878_45 = __x.8_43-_M_value_field;
which shows that the warning is for dead code. Thus this is not a
wrong-code problem.
VRP could figure out the equivalencies but doesn't. The next DOM
pass figures out the second but not the first non-equivalency - that
survives until the next forwprop pass.
In the end the problem is that VRP doesn't do a good job cleaning up
after itself (there are single-argument PHIs left after it as well as
non-simplified comparisons):
bb 3:
Invalid sum of incoming frequencies 900, should be 1
# __y_8 = PHI 0B(2)
# __y_18 = PHI __y_7(2)
...
bb 4:
Invalid sum of incoming frequencies 3900, should be 102
D.2837 = 1;
D.2839_21 = __y_18-D.2545;
D.2832_22 ={v} 0B-D.2545;
if (D.2832_22 != 0B)
goto bb 8;
else
goto bb 5;
bb 5:
D.2888_42 = __y_7-D.2545;
if (D.2839_21 == D.2888_42)
goto bb 8;
else
goto bb 6;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords|wrong-code |missed-optimization
Last reconfirmed|-00-00 00:00:00 |2009-03-06 13:36:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug c++/39391] New: argument dependant name lookup don't catch pointer to function
ref iec/iso c++ section 3.4.2 gcc correctly reports an error when the argument is one of the fundamental type and the associated namespace is empty. like the call to 'f' in the attached example. However if the argument is a pointer to function the associated name space should be the one associated with the function. So it seems to me that the call to 'h' should not generate an error. -- Summary: argument dependant name lookup don't catch pointer to function Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chrbr 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=39391
[Bug c++/39391] argument dependant name lookup don't catch pointer to function
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-03-06 14:05 --- Created an attachment (id=17406) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17406action=view) Example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39391
[Bug c++/39367] [4.4 Regression] ICE at tree-inline.c:1042 with -O
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-06 14:06 --- Normally TYPE_MAX_VALUE etc. shouldn't contain anything but constants or VAR_DECLs after gimplification, gimplify_type_sizes is supposed to take care of this. The problem here is that build_new_1 when it creates its VLAs by hand doesn't add DECL_EXPR and so for this type gimplify_type_sizes isn't called at all. I guess just adding a DECL_EXPR if vla_p would be sufficient. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Component|tree-optimization |c++ Last reconfirmed|2009-03-04 22:08:34 |2009-03-06 14:06:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39367
[Bug tree-optimization/39390] [4.4 regression] Bogus aliasing warning with std::set
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-03-06 14:16 --- Scheduling another pass_phi_only_cprop after VRP removes the single-argument PHI nodes (I think that really cfg-cleanup should do this, as they usually result from edge removal). While this is reasonably cheap it doesn't get rid of the conditionals but that would require a forwprop run which is not that cheap (it requires only the forward_propagate_into_gimple_cond () pieces, but has to run after removing single-argument PHIs, thus cannot run at VRP substitution time). Thus, the following would fix it: Index: passes.c === --- passes.c(revision 144665) +++ passes.c(working copy) @@ -611,6 +611,8 @@ init_optimization_passes (void) NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); + NEXT_PASS (pass_phi_only_cprop); + NEXT_PASS (pass_forwprop); NEXT_PASS (pass_dce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_tree_ifcombine); alternatively only adding pass_phi_only_cprop and calling forward_propagate_into_gimple_cond from pass_tree_ifcombine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug c/39383] sizeof object with zero-length array ignores initializer
--- Comment #6 from algrant at acm dot org 2009-03-06 14:44 --- Right. The existence of a statically initialized object whose size can be determined at compile-time to be larger than the (notional) type size, is specific to GCC. Here's another thing: the assembler output shows .type f1, %object .size f1, 4 f1: .word 1 .word 2 .word 3 .word 4 Whatever you think about sizeof(), surely the object's symbol should have its true size (16 in this case)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383
[Bug driver/39356] assembler isn't called
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-03-06 15:12 --- Well, the issues in driver seems to be related to pexecute in protoize.c. On a first glance, I noticed that here for pid's an 'int' type is used (btw in libiberty a 'long' is used for keeping the pids, which is for w64 incorrect, too). The problem is, that pid_t has to have a scalar size on w64 of 64-bits. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-06 15:12:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- Comment #48 from amylaar at gcc dot gnu dot org 2009-03-06 15:54
---
Created an attachment (id=17408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17408action=view)
patch to take POST_DEC and POST_MODIFY into account
The Copyright assignment issue has been resulved now.
This is the patch I've sent to Steven Bosscher in December.
It would be good if we had some benchmarks on different architectures
to check the merit of having the f{,no-}ivopts-post-inc and
f{,no-}ivopts-post-modify options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-06 17:24 ---
I think it is the new:
3384 if (TREE_STATIC (var) !TREE_ASM_WRITTEN (var))
3385{
3386 if (var_ann (var) referenced_var_check_and_insert (var))
3387cfun-local_decls = tree_cons (NULL_TREE, var,
3388 cfun-local_decls);
3389}
that causes this. Compared to add_referenced_var this doesn't do the:
/* Scan DECL_INITIAL for pointer variables as they may contain
address arithmetic referencing the address of other
variables.
Even non-constant initializers need to be walked, because
IPA passes might prove that their are invariant later on. */
if (DECL_INITIAL (var)
/* Initializers of external variables are not useful to the
optimizers. */
!DECL_EXTERNAL (var))
walk_tree (DECL_INITIAL (var), find_vars_r, NULL, 0);
part. So, either tree-inline.c needs to do the same, or it can't use
referenced_vars bit as a test whether it has been queued already onto
local_decls or not. Honza?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug c/39383] sizeof object with zero-length array ignores initializer
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-03-06 17:27 --- Reopening. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #9 from hubicka at ucw dot cz 2009-03-06 17:30 --- Subject: Re: [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563 part. So, either tree-inline.c needs to do the same, or it can't use referenced_vars bit as a test whether it has been queued already onto local_decls or not. Honza? Ah I see. Actually original version of patch added function to tree-dfa to check if variable is referenced and used this predicate followed by add_referenced_var if it was not, but then I noticed that referenced_var_check_and_insert is available to I decided to use it. OK, I will prepare this version of patch tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-06 17:53 --- To do the same the easiest would be probably change add_referenced_var to return bool, whatever referenced_var_check_and_insert returned, and use add_referenced_var instead of referenced_var_check_and_insert in expand_call_inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug c/39392] New: internal compiler error: in referenced_var_lookup
Trying to compile latest ffmpeg (ffmpeg-checkout-2009-03-06) Using mingw-w64-bin_i686-mingw_20090303 I get an ICE on mingw compiling for x64. $ make x86_64-pc-mingw32-gcc -DHAVE_AV_CONFIG_H -I. -I/c/ffmpeg-checkout-2009-03-06 -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fomit-frame-pointer -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -O3 -fno-math-errno -fno-signed-zeros -fPIC -DPIC -c -o libavcodec/h264.o libavcodec/h264.c cc1.exe: warning: -fPIC ignored for target (all code is position independent) libavcodec/h264.c:1: warning: -fPIC ignored for target (all code is position independent) libavcodec/h264.c: In function 'pred_direct_motion': libavcodec/h264.c:1046: warning: assignment from incompatible pointer type libavcodec/h264.c:1047: warning: assignment from incompatible pointer type libavcodec/h264.c: In function 'get_dct8x8_allowed': libavcodec/h264.c:4120: warning: dereferencing type-punned pointer will break strict-aliasing rules libavcodec/h264.c:4122: warning: dereferencing type-punned pointer will break strict-aliasing rules libavcodec/h264.c: In function 'filter_mb_dir': libavcodec/h264.c:6283: warning: initialization from incompatible pointer type libavcodec/h264.c:6284: warning: initialization from incompatible pointer type libavcodec/h264.c: In function 'decode_slice': libavcodec/h264.c:6662: warning: unknown conversion type character 't' in format libavcodec/h264.c:6662: warning: too many arguments for format In file included from libavcodec/h264.c:8139: libavcodec/svq3.c: In function 'svq3_decode_slice_header': libavcodec/svq3.c:721: warning: cast discards qualifiers from pointer target type libavcodec/svq3.c:724: warning: cast discards qualifiers from pointer target type libavcodec/h264.c: In function 'filter_mb_fast': libavcodec/h264.c:6267: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6266: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6265: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6264: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6260: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6259: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6256: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6243: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6230: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6230: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6230: warning: dereferencing pointer 'bSv' does break strict-aliasing rules libavcodec/h264.c:6226: note: initialized from here In file included from libavcodec/h264.c:8139: libavcodec/svq3.c: In function 'svq3_decode_frame': libavcodec/svq3.c:890: internal compiler error: in referenced_var_lookup, at tree-dfa.c:563 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [libavcodec/h264.o] Error 1 -- Summary: internal compiler error: in referenced_var_lookup Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkolb at wsi dot com GCC build triplet: x86_64-pc-mingw32 GCC host triplet: x86_64-pc-mingw32 GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
[Bug c/39392] internal compiler error: in referenced_var_lookup
--- Comment #1 from jkolb at wsi dot com 2009-03-06 18:00 --- Created an attachment (id=17409) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17409action=view) Offending Source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
[Bug c/39392] internal compiler error: in referenced_var_lookup
--- Comment #2 from jkolb at wsi dot com 2009-03-06 18:01 --- Created an attachment (id=17410) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17410action=view) #included by h264.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
[Bug c/39392] internal compiler error: in referenced_var_lookup
--- Comment #3 from jkolb at wsi dot com 2009-03-06 18:02 --- Created an attachment (id=17411) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17411action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
[Bug middle-end/39392] internal compiler error: in referenced_var_lookup
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-06 18:16 --- Most likely a duplicate of bug 39360. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-06 19:11 --- Created an attachment (id=17412) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17412action=view) gcc44-pr39360.patch Patch I'm bootstrapping/regtesting now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00407.html Status|NEW |ASSIGNED Last reconfirmed|2009-03-04 15:21:37 |2009-03-06 20:45:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug bootstrap/26539] make install fails in libcpp if bootstrap compiler got removed
--- Comment #9 from v dot merkatz at gmx dot net 2009-03-06 22:06 --- Works fine with gcc 4.3.2. -- v dot merkatz at gmx dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26539
[Bug c++/39367] [4.4 Regression] ICE at tree-inline.c:1042 with -O
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-06 22:47 --- Jason, if you think you can fix this by not using a VLA at all, please take this bug over. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39367
[Bug debug/39372] [4.3/4.4 Regression] Missing DW_AT_location for constructor static variable
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-06 22:49 --- Subject: Bug 39372 Author: jakub Date: Fri Mar 6 22:49:39 2009 New Revision: 144682 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144682 Log: PR debug/39372 * dwarf2out.c (add_abstract_origin_attribute): Return origin_die. (gen_variable_die): Emit DW_AT_location on abstract static variable's DIE, don't emit it if abstract origin already has it. * tree-cfg.c (remove_useless_stmts_bind): GIMPLE_BINDs with any BLOCK_NONLOCALIZED_VARS in its gimple_bind_block aren't useless. * g++.dg/debug/dwarf2/static-local-var-in-ctor.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/static-local-var-in-ctor.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39372
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-06 22:51 --- Subject: Bug 39360 Author: jakub Date: Fri Mar 6 22:51:28 2009 New Revision: 144683 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144683 Log: PR middle-end/39360 * tree-flow.h (add_referenced_var): Return bool instead of void. * tree-dfa.c (add_referenced_var): Return result of referenced_var_check_and_insert call. * tree-inline.c (expand_call_inline): Call add_referenced_var instead of referenced_var_check_and_insert. * gcc.c-torture/compile/pr39360.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39360.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug debug/39372] [4.3 Regression] Missing DW_AT_location for constructor static variable
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-06 22:52 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.3 4.4.0 |4.3.3 Known to work|4.1.2 4.2.3 |4.1.2 4.2.3 4.4.0 Summary|[4.3/4.4 Regression] Missing|[4.3 Regression] Missing |DW_AT_location for |DW_AT_location for |constructor static variable |constructor static variable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39372
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-06 22:53 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug c++/33492] [4.2/4.3/4.4 regression] Broken diagnostic: 'must_not_throw_expr' not supported by dump_expr
--- Comment #6 from paolo at gcc dot gnu dot org 2009-03-06 23:52 --- Subject: Bug 33492 Author: paolo Date: Fri Mar 6 23:52:02 2009 New Revision: 144686 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144686 Log: /cp 2009-03-06 Paolo Carlini paolo.carl...@oracle.com PR c++/33492 * error.c (dump_expr): Don't try to print THROW_EXPRs in full. /testsuite 2009-03-06 Paolo Carlini paolo.carl...@oracle.com PR c++/33492 * g++.dg/other/error32.C: New. Added: trunk/gcc/testsuite/g++.dg/other/error32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33492
[Bug c++/33492] [4.2/4.3 regression] Broken diagnostic: 'must_not_throw_expr' not supported by dump_expr
--- Comment #7 from paolo dot carlini at oracle dot com 2009-03-06 23:53 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression] Broken |Broken diagnostic: |diagnostic: |'must_not_throw_expr' not |'must_not_throw_expr' not |supported by dump_expr |supported by dump_expr Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33492
[Bug middle-end/39360] [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
--- Comment #14 from linuxl4 at sohu dot com 2009-03-07 00:12 --- thanks a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
[Bug c/39393] New: invalid instructions accepted in inline assembly language on 32 bit machines
On an x86_64 bit machine, if an attempt to compile code containing an invalid
instruction is attempted, an error will correctly occur:
cat /etc/testasm.c
int main(void)
{
asm(cpuid); /* Invalid on the i386 */
}
gcc -march=i386 -Wa,-march=i386 testasm.c
Error: `cpuid' is not supported on `i386'
However on a 32 bit machine, the error trap does not occur, and the invalid
instruction ends up producing an invalid binary file:
gcc -march=i386 -Wa,-march=i386 testasm.c
No error occurs and invalid opcodes are placed in the resultant binary.
--
Summary: invalid instructions accepted in inline assembly
language on 32 bit machines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markhobley at yahoo dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39393
[Bug inline-asm/39393] invalid instructions accepted in inline assembly language on 32 bit machines
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-07 01:01 --- Since this is an inline-asm, it gets processed by the assembler and not GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |inline-asm Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39393
[Bug inline-asm/39393] invalid instructions accepted in inline assembly language on 32 bit machines
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-07 01:31 ---
(In reply to comment #0)
On an x86_64 bit machine, if an attempt to compile code containing an invalid
instruction is attempted, an error will correctly occur:
cat /etc/testasm.c
int main(void)
{
asm(cpuid); /* Invalid on the i386 */
}
gcc -march=i386 -Wa,-march=i386 testasm.c
Error: `cpuid' is not supported on `i386'
However on a 32 bit machine, the error trap does not occur, and the invalid
instruction ends up producing an invalid binary file:
gcc -march=i386 -Wa,-march=i386 testasm.c
No error occurs and invalid opcodes are placed in the resultant binary.
I got
h...@gnu-9 tmp]$ gcc -march=i386 -Wa,-march=i386 a.c
/tmp/cciG1xw8.s: Assembler messages:
/tmp/cciG1xw8.s:17: Error: `cpuid' is not supported on `i386'
on Linux/ia32 with the current Linux binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39393
[Bug target/37520] NO_DOLLAR_IN_LABEL should be defined on x86 targets
--- Comment #20 from hjl at gcc dot gnu dot org 2009-03-07 01:47 --- Subject: Bug 37520 Author: hjl Date: Sat Mar 7 01:47:25 2009 New Revision: 144692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144692 Log: 2009-03-06 H.J. Lu hongjiu...@intel.com PR c++/37520 * cp-tree.h: Check NO_DOT_IN_LABEL before NO_DOLLAR_IN_LABEL when mangling symbols. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug target/37520] NO_DOLLAR_IN_LABEL should be defined on x86 targets
--- Comment #21 from hjl dot tools at gmail dot com 2009-03-07 01:48 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug inline-asm/39393] invalid instructions accepted in inline assembly language on 32 bit machines
--- Comment #3 from markhobley at yahoo dot co dot uk 2009-03-07 02:40 --- Subject: Re: invalid instructions accepted in inline assembly language on 32 bit machines --- On Sat, 7/3/09, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: I got h...@gnu-9 tmp]$ gcc -march=i386 -Wa,-march=i386 a.c /tmp/cciG1xw8.s: Assembler messages: /tmp/cciG1xw8.s:17: Error: `cpuid' is not supported on `i386' on Linux/ia32 with the current Linux binutils. Hmmm. There is definitely something weird going on. My machines do not error, even with the latest binutils. Maybe there is some problem with a library or with some configuration option that is not being made effective on my machine, causing the error trap to skip somehow. I am conducting further tests on this. Mark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39393
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30 --- OK, I've done a little test and I'd like to know, if it's results actually mean anything: I've compiled freeciv with CFLAGS=-O2 -finline-functions -fno-guess-branch-probability and it did not crash. Does the above confirm that the problem lies in -fguess-branch-probability ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
Re: [Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
Sent from my iPhone On Mar 6, 2009, at 8:30 PM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org wrote: --- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30 --- OK, I've done a little test and I'd like to know, if it's results actually mean anything: I've compiled freeciv with CFLAGS=-O2 -finline-functions -fno-guess-branch-probability and it did not crash. Does the above confirm that the problem lies in -fguess-branch- probability ? Not really because that option only generates information used by other optimazations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #17 from pinskia at gmail dot com 2009-03-07 04:35 --- Subject: Re: gcc 4.3.3 miscompiles when -finline-small-functions is used Sent from my iPhone On Mar 6, 2009, at 8:30 PM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org wrote: --- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30 --- OK, I've done a little test and I'd like to know, if it's results actually mean anything: I've compiled freeciv with CFLAGS=-O2 -finline-functions -fno-guess-branch-probability and it did not crash. Does the above confirm that the problem lies in -fguess-branch- probability ? Not really because that option only generates information used by other optimazations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug c/39394] New: gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9
gcc 4.4.0 20090307 segfaults at argp-help.c in glibc 2.7 and 2.9 cpu: athlon64 gcc version 4.4.0 20090307 -march=native and athlon64 used This is my first post. I have read http://gcc.gnu.org/bugs.html and I cannot or am still ingnorant of how to get a preprocessed file. I added -v -save-temps to my cflags and I get: command line option -.i not recognized... I entered cc -v -save-temps ../argp/argp-help.c argp-help.o and got the following: In file included from ../argp/argp-help.c:85: ../argp/argp-namefrob.h:80:21: error: mempcpy.h: No such file or directory ../argp/argp-namefrob.h:81:21: error: strcase.h: No such file or directory ../argp/argp-namefrob.h:82:23: error: strchrnul.h: No such file or directory ../argp/argp-namefrob.h:83:21: error: strndup.h: No such file or directory ../argp/argp-help.c:1717:4: warning: #warning No reasonable value to return gcc segfaults at argp-help.c It has been like that for about two weeks. This machine attempts to compile gcc-svn and glibc daily. Sometimes it works sometimes not. I tested with glibc 2.9 and gcc appears to still segfault. -- Summary: gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kdebugs at hotmail dot com GCC build triplet: pentium2-slackware-linux-gnu GCC host triplet: pentium2-slackware-linux-gnu GCC target triplet: pentium2-slackware-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
