[Bug other/45686] New: Building rev. 164285 fails with --enable-checking=all
I've configured GCC with following options: ../gcc-current/configure --prefix=/home/artem/testing/gcc46 --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls --verbose --with-arch=athlon64 --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux --disable-multilib --enable-checking=all The build fails with this error: /home/artem/testing/gcc-build/./prev-gcc/xgcc -B/home/artem/testing/gcc-build/./prev-gcc/ -B/home/artem/testing/gcc46/x86_64-slackware-linux/bin/ -B/home/artem/testing/gcc46/x86_64-slackware-linux/bin/ -B/home/artem/testing/gcc46/x86_64-slackware-linux/lib/ -isystem /home/artem/testing/gcc46/x86_64-slackware-linux/include -isystem /home/artem/testing/gcc46/x86_64-slackware-linux/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-current/gcc -I../../gcc-current/gcc/. -I../../gcc-current/gcc/../include -I../../gcc-current/gcc/../libcpp/include -I../../gcc-current/gcc/../libdecnumber -I../../gcc-current/gcc/../libdecnumber/bid -I../libdecnumber -I/usr/include/libelf ../../gcc-current/gcc/fold-const.c -o fold-const.o ../../gcc-current/gcc/fold-const.c: In function 'fold_checksum_tree': ../../gcc-current/gcc/fold-const.c:13663:10: error: to be safe all intermediate pointers in cast from 'void **' to 'const void **' must be 'const' qualified [-Werror=cast-qual] cc1: all warnings being treated as errors If --enable-checking=release is used instead of =all, then the build completes successfully. -- Summary: Building rev. 164285 fails with --enable-checking=all Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: x86_64-slackware-linux GCC host triplet: x86_64-slackware-linux GCC target triplet: x86_64-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45686
[Bug c/45687] New: possible wrong code bug
I don't think there's anything wrong with the testcase. The -O2 result is
wrong.
[reg...@gamow ~]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r164319-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r164319-install
--program-prefix=r164319- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100915 (experimental) (GCC)
[reg...@gamow ~]$ current-gcc -O1 small.c -o small
[reg...@gamow ~]$ ./small
1
[reg...@gamow ~]$ current-gcc -O2 small.c -o small
[reg...@gamow ~]$ ./small
0
[reg...@gamow ~]$ cat small.c
int printf(const char *format, ...);
static int g_7;
static int *volatile g_6 = g_7;
static int func_53(int *p_58)
{
return *p_58;
}
int main(void)
{
*g_6 = 1;
printf(%d\n, func_53(g_7));
return 0;
}
--
Summary: possible wrong code bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-16 07:06 --- I believe that there are related PRs that I have to find. pr40472 comment #21 for SPREAD: REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON , JLON=1,720) /) , DIM=2, NCOPIES=360 ) print *, size(ZLON_MASK), ZLON_MASK(720,360) end The tests in pr42359 also give ICE at fortran/trans-array.c, but at different locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug tree-optimization/45653] [4.6 Regression] ICE: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1241 with -fno-early-inlining -fno-ipa-cp -fno-ipa-pure-const
--- Comment #2 from zsojka at seznam dot cz 2010-09-16 07:20 --- (In reply to comment #0) Tested revisions: r164228 - crash r163636 - crash r161659 - crash typo, r161659 doesn't crash (thus it's a 4.6 regression) 4.5 r163761 compiles fine as well -- zsojka at seznam dot cz changed: What|Removed |Added Known to fail||4.6.0 Known to work||4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45653
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #10 from mh+gcc at glandium dot org 2010-09-16 07:43 --- (In reply to comment #9) Created an attachment (id=21806) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21806action=view) [edit] testcase Here you go. This passes at -O0 but fails at -O2. Note that the testcase requires = 7 args to the test function, to force the last arg to spill onto the stack; also an inner (non-inlined) function call, to force that single stack arg to be zero-extended to word size and overwrite the flags. Another way to achieve the test without relying on the compiler optimization would be to use int or size_t arguments, but pass bools through ffi_call. This may not work on all architectures, though. Also, interestingly, the original patch doesn't trigger any testsuite failure. Maybe the various cls tests should be extended to get a first dummy argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug c/45687] possible wrong code bug
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 08:13 --- Broken by http://gcc.gnu.org/viewcvs?root=gccview=revrev=164135 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-16 08:13:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687
[Bug c/45687] possible wrong code bug
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-16 08:27 --- Seems ipa_modify_call_arguments creates incorrect MEM_REF here. base is correctly ADDR_EXPR of a, with int * type for the ADDR_EXPR, but offset has int ** type instead of int *. At RTL level this results in alias set 3 being used for the memory read (int *) instead of 2 (int). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-16 08:50 --- (I have not regtested this yet.) The (second) patch in comment #2 fixes the pr without regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug c++/45605] Missed devirtualization
--- Comment #10 from rguenther at suse dot de 2010-09-16 08:50 --- Subject: Re: Missed devirtualization On Wed, 15 Sep 2010, hubicka at ucw dot cz wrote: --- Comment #9 from hubicka at ucw dot cz 2010-09-15 22:39 --- Subject: Re: Missed devirtualization We fold a stmt only if it is propagated to (by ccp, copyprop, forwprop, dom or by inlining). Well, since fold_stmt is stornger than what fe does, I guess we should fold each stmt at least once. No we shouldn't. We do fold some stmts during gimplification. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c/45687] possible wrong code bug
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-16 08:55 ---
--- ipa-prop.c.jj 2010-09-14 15:24:45.0 +0200
+++ ipa-prop.c 2010-09-16 10:47:14.0 +0200
@@ -2185,7 +2185,8 @@ ipa_modify_call_arguments (struct cgraph
if (TREE_CODE (base) == ADDR_EXPR
DECL_P (TREE_OPERAND (base, 0)))
-off = build_int_cst (reference_alias_ptr_type (base),
+off = build_int_cst (reference_alias_ptr_type (TREE_OPERAND (base,
+ 0)),
adj-offset / BITS_PER_UNIT);
else if (TREE_CODE (base) != ADDR_EXPR
POINTER_TYPE_P (TREE_TYPE (base)))
seems to fix this, but even the else { } block a few lines below looks very
questionable. In particular, the
if (TREE_CODE (base) == ADDR_EXPR)
base = TREE_OPERAND (base, 0);
without remembering anywhere whether it was ADDR_EXPR or not and so what level
of indirection we need.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687
[Bug bootstrap/45686] Building rev. 164285 fails with --enable-checking=all
-- 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|UNCONFIRMED |ASSIGNED Component|other |bootstrap Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-16 09:17:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45686
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 09:30 --- With seeing .clone in fn names I suppose this is ipa-cp or ipa-sra. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org, jamborm at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085
[Bug bootstrap/45686] Building rev. 164285 fails with --enable-checking=all
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 09:35 --- Subject: Bug 45686 Author: jakub Date: Thu Sep 16 09:35:02 2010 New Revision: 164330 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164330 Log: PR bootstrap/45686 * fold-const.c (fold_checksum_tree): Change slot from const void ** to void **, use CONST_CAST_TREE to store into *slot. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45686
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-09-16 09:43 --- Subject: Re: [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208 Thanks! Paul On Thu, Sep 16, 2010 at 9:06 AM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from dominiq at lps dot ens dot fr 2010-09-16 07:06 --- I believe that there are related PRs that I have to find. pr40472 comment #21 for SPREAD: REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON , JLON=1,720) /) , DIM=2, NCOPIES=360 ) print *, size(ZLON_MASK), ZLON_MASK(720,360) end The tests in pr42359 also give ICE at fortran/trans-array.c, but at different locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-16 10:17 --- DECL_ALIGN of d is set to 128 (but appearantly it isn't ensured it'll end up that way). DECL_ALIGN is adjusted here: Old value = 32 New value = 128 expand_one_stack_var_at (decl=0x75ae90a0, offset=-16) at /space/rguenther/src/svn/trunk/gcc/cfgexpand.c:739 739 DECL_USER_ALIGN (decl) = 0; so on trunk get_object_alignment of the MEM_REF will return 128 and thus we do not run into unaligned move expansion here: if (mode != BLKmode (unsigned) align GET_MODE_ALIGNMENT (mode) /* If the target does not have special handling for unaligned loads of mode then it can use regular moves for them. */ ((icode = optab_handler (movmisalign_optab, mode)) != CODE_FOR_nothing)) manually setting alignment back to 32 in gdb results in ok asm. movlps (%esp), %xmm0 movhps 8(%esp), %xmm0 mulps .LC4, %xmm0 instead of mulps (%esp), %xmm0 Appearantly stack alignment code doesn't work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-16 10:18 --- Created an attachment (id=21809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809action=view) patch to fix half STRICT_ALIGNMENT targets memcpy folding Might need this patch to fix as well. i?86 / x86_64 isn't really !STRICT_ALIGNMENT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug web/45688] New: Typo in __attribute__((version-id)) docs
HP-UX system header files may use version level functioning for some system calls. This is a very amusing (what I assume to be) typo in the documentation of function-level versioning. Not sure this is the right bug tracker but this is one that I know... -- Summary: Typo in __attribute__((version-id)) docs Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dascandy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
[Bug web/45688] Typo in __attribute__((version-id)) docs
--- Comment #1 from dascandy at gmail dot com 2010-09-16 10:23 --- http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes The link where the typo is to be found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-16 10:40 --- Re: #c4, shouldn't there be srcvar = NULL_TREE; somewhere for the STRICT_ALIGNMENT non-aligned case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug fortran/45689] New: CSHIFT and EOSHIFT are not in the make-164314p7m1.log list
While playing with modifications of PR4581, I tried
module m
implicit none
type t
integer :: i
end type t
type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /)
type(t), dimension(2), parameter :: d = cshift ( a1, 1 )
end module m
and got
pr45081_red.f90:7.43:
type(t), dimension(2), parameter :: d = cshift ( a1, 1 )
1
Error: transformational intrinsic 'cshift' at (1) is not permitted in an
initialization expression
The F2003 standard says:
(5) A reference to a transformational standard intrinsic function other than
NULL, where each argument is an initialization expression,
and the F2008 version adds:
(6) a reference to a transformational standard intrinsic function other than
COMMAND ARGUMENT -COUNT, NULL, NUM IMAGES, THIS IMAGE, where each argument is a
constant expression,
This is fixed by the following patch:
--- ../_clean/gcc/fortran/expr.c2010-09-09 21:06:18.0 +0200
+++ gcc/fortran/expr.c 2010-09-16 12:24:49.0 +0200
@@ -2329,7 +2329,7 @@ check_transformational (gfc_expr *e)
};
static const char * const trans_func_f2003[] = {
-all, any, count, dot_product, matmul, null, pack,
+all, any, count, cshift, dot_product, eoshift, matmul,
null, pack,
product, repeat, reshape, selected_char_kind, selected_int_kind,
selected_real_kind, spread, sum, transfer, transpose,
trim, unpack, NULL
but then I am back to PR45081!-(even with the Paul's patch).
--
Summary: CSHIFT and EOSHIFT are not in the make-164314p7m1.log
list
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug fortran/45689] CSHIFT and EOSHIFT are not in the trans_func_f2003 list
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 10:42 --- pasto!-( -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|CSHIFT and EOSHIFT are not |CSHIFT and EOSHIFT are not |in the make-164314p7m1.log |in the trans_func_f2003 list |list| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 10:50 --- Missing some else indeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug tree-optimization/45623] [4.5/4.6 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-09-16 11:06 --- Subject: Bug 45623 Author: rguenth Date: Thu Sep 16 11:06:25 2010 New Revision: 164333 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164333 Log: 2010-09-16 Richard Guenther rguent...@suse.de PR tree-optimization/45623 * tree-ssa-structalias.c (get_constraint_for_ptr_offset): Adjust. (get_constraint_for_component_ref): If computing a constraint for the rhs handle type punning through unions. (get_constraint_for_address_of): Adjust. (get_constraint_for_1): Likewise. (get_constraint_for): Likewise. (get_constraint_for_rhs): New function. (do_structure_copy): Adjust. (make_constraint_to): Likewise. (handle_const_call): Likewise. (find_func_aliases): Likewise. (process_ipa_clobber): Likewise. (create_variable_info_for): Likewise. * gcc.dg/torture/pr45623.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr45623.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug tree-optimization/45623] [4.5 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-09-16 11:07 --- Fixed for trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression] GCC|[4.5 Regression] GCC |4.5.[01] breaks our ffi on |4.5.[01] breaks our ffi on |Linux64. ABI break? |Linux64. ABI break? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug fortran/45689] CSHIFT and EOSHIFT are not in the trans_func_f2003 list
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 --- They are not, as there, afaik, are no simplifiers yet. Hence, with your patch they will be accepted, but you'd end up with wrong code at the end, as the functions are not properly simplified and thus not constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug web/45688] Typo in __attribute__((version-id)) docs
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2010-09-16 11:42:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #11 from laurent at guerby dot net 2010-09-16 11:49 --- With --with-arch=armv5te --with-tune=xscale I get the comparison failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-16 11:57 --- For the ix86/x86_64 alignment issue, I believe the problem here is that max_align = MAX (crtl-max_used_stack_slot_alignment, PREFERRED_STACK_BOUNDARY); is fine for !SUPPORTS_STACK_ALIGNMENT targets, but for ix86/x86_64 if max_used_stack_slot_alignment is really small, we might end up with deciding to use a smaller alignment. Perhaps for SUPPORTS_STACK_ALIGNMENT we should use here instead max_align = MAX (crtl-max_used_stack_slot_alignment, INCOMING_STACK_BOUNDARY); and if the align we compute is bigger than crtl-max_used_stack_slot_alignment ensure we will keep using that alignment (e.g. by bumping also crtl-stack_align_needed/estimated). If INCOMING_STACK_BOUNDARY is 128 bits aligned, I think using 128 bit alignment shouldn't cost us anything extra. The problem with using INCOMING_STACK_BOUNDARY is that it is on ix86/x86-64 computed only too late (in expand_stack_alignment by targetm.calls.update_stack_boundary (); ). The comment above it says it is computed again, but I can't actually find another call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug lto/45375] [meta-bug] Mozilla does not build with LTO
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-16 12:09 --- PR 45679 also reproduce during -O3 build. I am testing patch for it now. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||45679 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-16 12:10 --- (In reply to comment #3) Thanks for the quick fix! Well, it was *your* fix, so *I* should thank *you* :) Anyway, I think the patch in comment #2 qualifies as obvious, and has no regressions, as noted by Dominique. Will commit soon. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-09-15 13:57:41 |2010-09-16 12:10:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug c++/45605] Missed devirtualization
--- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25 --- Hmm, so do you have any idea where folding should be added for this particular case? It always seemed to me that it would make sense to add verifier that all statements are folded (locally, not by looking at SSA graph) at optimization pass boundaries. Tried it in the past and found a lot of issues that got fixed, but we never got into agreeing on any policy here. Missing optimizations just because we are stupid enough to forget call fold when updating something seems bad IMO. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-16 12:25:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45605] Missed devirtualization
--- Comment #12 from rguenther at suse dot de 2010-09-16 12:31 --- Subject: Re: Missed devirtualization On Thu, 16 Sep 2010, hubicka at gcc dot gnu dot org wrote: --- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25 --- Hmm, so do you have any idea where folding should be added for this particular case? It always seemed to me that it would make sense to add verifier that all statements are folded (locally, not by looking at SSA graph) at optimization pass boundaries. Tried it in the past and found a lot of issues that got fixed, but we never got into agreeing on any policy here. Missing optimizations just because we are stupid enough to forget call fold when updating something seems bad IMO. I'm lost in this PR - for what testcase what statement needs folding (and what pending patches do I need to apply to see that)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45605] Missed devirtualization
--- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 --- Subject: Re: Missed devirtualization I'm lost in this PR - for what testcase what statement needs folding (and what pending patches do I need to apply to see that)? PR is tracking missed optimization in the testcase in comment 0. There are two issues 1) OBJ_TYPE_REF folding should handle it. For that we seem to need to evern call fold on OBJ_TYPE_REF(D.2210_2;d.D.2108-0) (d.D.2108); this you can see on mainline 2) generic folding should work it out the hard way. I.e. for: MEM[(struct B *)d]._vptr.B = _ZTV1B[2]; d.D.2108._vptr.B = _ZTV1D[2]; D.2210_2 = _ZTV1D[2]; OBJ_TYPE_REF(D.2210_2;d.D.2108-0) (d.D.2108); there is nothing that prevents us to resolve _ZTV1D[2] into pointer to Run (by looking into initializer of vtable variable) and then take OBJ_TYPE_REF away since it is pointless when first operand is known function. With patch http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01190.html we closer in a way that .vpr1 dump has: MEM[(struct B *)d]._vptr.B = _ZTV1B[2]; d.D.2078._vptr.B = _ZTV1D[2]; D.2179_1 = _ZTV1D[2]; D.2180_2 = (int (*__vtbl_ptr_type) (void)) Run; OBJ_TYPE_REF(D.2180_2;d.D.2078-0) (d.D.2078); Somewhere I have patch that adds OBJ_TYPE_REF folding into CCP (so when first argument is function pointer, we just fold into direct call). I will update it and submit after http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01190.html is resolved. Then still there is problem that resolution comes late since we need FRE to fold d.D.2078._vptr.B = _ZTV1D[2]; D.2179_1 = d.D.2078._vptr.B and FRE is not run early (and we should devirutalize everything early to get inlining) 1) is priority IMO (at moment we make amazingly little devirtualization at Mozilla, about 20 calls). 2) is just side effect of my attempt to get folding working that I run into while looking into kernel poor man C vtables (and ours targhooks). Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45605] Missed devirtualization
--- Comment #14 from rguenther at suse dot de 2010-09-16 12:51 --- Subject: Re: Missed devirtualization On Thu, 16 Sep 2010, hubicka at ucw dot cz wrote: --- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 --- Subject: Re: Missed devirtualization I'm lost in this PR - for what testcase what statement needs folding (and what pending patches do I need to apply to see that)? PR is tracking missed optimization in the testcase in comment 0. There are two issues 1) OBJ_TYPE_REF folding should handle it. For that we seem to need to evern call fold on OBJ_TYPE_REF(D.2210_2;d.D.2108-0) (d.D.2108); this you can see on mainline 2) generic folding should work it out the hard way. I.e. for: MEM[(struct B *)d]._vptr.B = _ZTV1B[2]; d.D.2108._vptr.B = _ZTV1D[2]; D.2210_2 = _ZTV1D[2]; OBJ_TYPE_REF(D.2210_2;d.D.2108-0) (d.D.2108); there is nothing that prevents us to resolve _ZTV1D[2] into pointer to Run (by looking into initializer of vtable variable) and then take OBJ_TYPE_REF away since it is pointless when first operand is known function. With patch http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01190.html we closer in a way that .vpr1 dump has: MEM[(struct B *)d]._vptr.B = _ZTV1B[2]; d.D.2078._vptr.B = _ZTV1D[2]; D.2179_1 = _ZTV1D[2]; D.2180_2 = (int (*__vtbl_ptr_type) (void)) Run; OBJ_TYPE_REF(D.2180_2;d.D.2078-0) (d.D.2078); Somewhere I have patch that adds OBJ_TYPE_REF folding into CCP (so when first argument is function pointer, we just fold into direct call). I will update it and submit after http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01190.html is resolved. Then still there is problem that resolution comes late since we need FRE to fold d.D.2078._vptr.B = _ZTV1D[2]; D.2179_1 = d.D.2078._vptr.B and FRE is not run early (and we should devirutalize everything early to get inlining) 1) is priority IMO (at moment we make amazingly little devirtualization at Mozilla, about 20 calls). 2) is just side effect of my attempt to get folding working that I run into while looking into kernel poor man C vtables (and ours targhooks). 1) should be fixed by using fold_stmt in gimplify_call instead of just fold_call_expr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #8 from hjl dot tools at gmail dot com 2010-09-16 13:02 ---
This also failed:
---
typedef float V __attribute__ ((vector_size (16)));
V g;
float d[4] = { 4, 3, 2, 1 };
int
main ()
{
V e;
__builtin_memcpy (e, d, sizeof (d));
V f = { 5, 15, 25, 35 };
e = e * f;
g = e;
return 0;
}
---
Program received signal SIGSEGV, Segmentation fault.
0x0804837e in main () at foo.c:11
11e = e * f;
Missing separate debuginfos, use: debuginfo-install glibc-2.12.1-2.0.f13.i686
(gdb) disass
Dump of assembler code for function main:
0x08048374 +0: push %ebp
0x08048375 +1: mov%esp,%ebp
0x08048377 +3: movaps 0x8048470,%xmm0
= 0x0804837e +10:mulps 0x8049644,%xmm0
0x08048385 +17:movaps %xmm0,0x8049670
0x0804838c +24:mov$0x0,%eax
0x08048391 +29:pop%ebp
0x08048392 +30:ret
End of assembler dump.
(gdb) q
There is no stack involved. Somehow we failed to align
array of float properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #20 from dominiq at lps dot ens dot fr 2010-09-16 13:03 --- The test in comment #0 now gives (with/without -std=g95) pr25104.f90:3.5: CASE(MAXLOC(K,1)) 1 Error: transformational intrinsic 'maxloc' at (1) is not permitted in an initialization expression for 4.4.4, 4.5.0, and trunk. I think this wrong without -std=f95 (see pr45689). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #9 from hjl dot tools at gmail dot com 2010-09-16 13:05 --- If __builtin_memcpy generates instructions which require bigger alignment than alignments of source or destination, it should increase the alignment of source or destination. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug fortran/45689] [F2003] Missing transformational intrinsic in the trans_func_f2003 list
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-16 13:09 --- MAXLOC and MINLOC are also missing (see pr25104). They are not, as there, afaik, are no simplifiers yet. Hence, with your patch they will be accepted, but you'd end up with wrong code at the end, as the functions are not properly simplified and thus not constant. I have seen that, and also in gcc/fortran/simplify.c /* FIXME: Returning here avoids a regression in array_simplify_1.f90. Replace NULL with gcc_unreachable() after implementing gfc_simplify_cshift(). */ Am I correct to understand that the current situation (i.e. the error message) is a temporary fix for some missing gfc_simplify_*? -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|CSHIFT and EOSHIFT are not |[F2003] Missing |in the trans_func_f2003 list|transformational intrinsic ||in the trans_func_f2003 list http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-16 13:10 --- When __builtin_memcpy increases the alignment of source or destination, it should update needed stack alignment if source or destination is on stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-16 13:13 --- Subject: Bug 45674 Author: janus Date: Thu Sep 16 13:12:59 2010 New Revision: 164338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164338 Log: 2010-09-16 Janus Weil ja...@gcc.gnu.org PR fortran/45674 * interface.c (compare_parameter): Create vtab for actual argument, instead of formal (if needed). 2010-09-16 Janus Weil ja...@gcc.gnu.org PR fortran/45674 * gfortran.dg/class_dummy_2.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_dummy_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug fortran/45674] [OOP] Undefined references for extended types
--- Comment #7 from janus at gcc dot gnu dot org 2010-09-16 13:14 --- Fixed with r164338. Closing. Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-16 13:14 --- (1) The patch in comment #7 fixes this pr without regression. (2) If I replace type(t), dimension(1), parameter :: a1 = (/ t(1) /) type(t), dimension(1), parameter :: a = reshape ( (/ a1 /), (/ 1 /) ) with type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /) type(t), dimension(2), parameter :: c = spread ( a1(1), 1, 1 ) I still get the same ICE. (3) I have opened pr45689 for transformational intrinsics I think are missing for initializations. (4) The only common point between this pr and those given in comment #8 is that the ICEs come from the same source file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-16 13:21 --- This code: if (TREE_CODE (srcvar) == ADDR_EXPR var_decl_component_p (TREE_OPERAND (srcvar, 0)) tree_int_cst_equal (TYPE_SIZE_UNIT (srctype), len) (!STRICT_ALIGNMENT || !destvar || src_align = TYPE_ALIGN (desttype))) srcvar = fold_build2 (MEM_REF, destvar ? desttype : srctype, srcvar, off0); does float d[4]; __m128 *p = (__m128 *) d; and treats p as properly aligned. I don't see how it can ever work with SSE. It has nothing to do with stack alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #12 from hjl dot tools at gmail dot com 2010-09-16 13:32 --- (In reply to comment #4) Created an attachment (id=21809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809action=view) [edit] patch to fix half STRICT_ALIGNMENT targets memcpy folding Might need this patch to fix as well. i?86 / x86_64 isn't really !STRICT_ALIGNMENT. We need a HARD_ALIGNMENT which depends on type for x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-16 13:39 --- (In reply to comment #12) (In reply to comment #4) Created an attachment (id=21809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809action=view) [edit] patch to fix half STRICT_ALIGNMENT targets memcpy folding Might need this patch to fix as well. i?86 / x86_64 isn't really !STRICT_ALIGNMENT. We need a HARD_ALIGNMENT which depends on type for x86. With that patch the assignment generated from memcpy doesn't need more that int alignment, but still cfgexpand.c sets DECL_ALIGN of the decl to 128 so expand uses aligned instructions. cfgexpand.c should not increase alignment and not set 'needs stack alignment' then, based on your comment #10. So this _is_ about stack alignment (but maybe not exclusively). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #12 from bernds at gcc dot gnu dot org 2010-09-16 13:50 --- (In reply to comment #6) So stage1 chooses adds but stage2 and stage3 choose lsls for of the lower half of a long long. Since the behaviour of a stageN xgcc depends on both the gcc source code and the compiler used to build it, I have to suspect a source code ambiguity (e.g. evaluation order dependence) that the bootstrap compiler (gcc-4.4.4 in my case) resolves differently from post-r162417 4.6. I think it's likely there really is a miscompilation. I've not been able to get very far trying to set up a native compiler to run on qemu, so it would help if you could try to narrow it down a bit further. IIUC, stage1 and stage2 produce different output for some output files, such as expr.o. You could try to copy object files from stage1 to stage2, then rebuild the stage2 compiler with these objects, until these differences go away. In that way, you can determine which file is being miscompiled by stage1. The next step would be to find code generation differences for that file between r162417 and r162418. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #14 from jakub at gcc dot gnu dot org 2010-09-16 13:54 --- The reason why cfgexpand does increase the alignment is that it believes that the base slot will be at least PREFERRED_STACK_BOUNDARY bytes aligned, which is true on all targets but i?86/x86-64, which apparently sometimes chooses even smaller alignment for the stack base. So, we can either use there MAX (..., STACK_BOUNDARY); for STACK_ALIGNMENT_SUPPORTED instead, which might penalize some code though, or use INCOMING_STACK_BOUNDARY there (after making sure we compute it before) and bump needed alignment to whatever we pick there up. During expansion expanders of course make use of the DECL_ALIGN info cfgexpand provides, after all that's why we do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #15 from hjl dot tools at gmail dot com 2010-09-16 13:54 --- Created an attachment (id=21810) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21810action=view) A patch This patch adds HARD_ALIGNMENT_MODE_P and works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #16 from hjl dot tools at gmail dot com 2010-09-16 13:59 --- (In reply to comment #13) With that patch the assignment generated from memcpy doesn't need more that int alignment, but still cfgexpand.c sets DECL_ALIGN of the decl to 128 so expand uses aligned instructions. cfgexpand.c should not increase alignment and not set 'needs stack alignment' then, based on your comment #10. So this _is_ about stack alignment (but maybe not exclusively). When we do float d[4]; __m128 *p = (__m128 *) d; all bets are off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug c++/45690] New: broken debuginfo with dwarf4?
hi, on the recent 4.5 branch i have a problems with dwarf4 and pretty printers. here's steps to reproduce: $ make /local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++ t.cpp -gdwarf-3 -g2 -o t-dw3 /local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++ t.cpp -gdwarf-4 -g2 -o t-dw4 $ gdb ./t-dw3 (gdb) r Breakpoint 1, main () at t.cpp:4 4 std::string s( foo ); (gdb) n 5 s.size(); (gdb) p s $1 = foo $ gdb ./t-dw4 (gdb) r Breakpoint 1, main () at t.cpp:4 4 std::string s( foo ); (gdb) n 5 s.size(); (gdb) p s $1 = Traceback (most recent call last): File /local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/share/gcc-4.5.2/python/libstdcxx/v6/printers.py, line 547, in to_string reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer () RuntimeError: No type named std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_Rep. $ readelf --debug-dump=pubtypes t-dw3 Contents of the .debug_pubtypes section: Length: 443 Version: 2 Offset into .debug_info section: 0x0 Size of area in .debug_info section: 13545 Offset Name 2d ptrdiff_t 3f size_t 6bf __FILE 6ca __va_list_tag 709 wint_t 770 mbstate_t fa4 char_traits 121c__pthread_internal_list 1243__pthread_list_t 12ed__compar_fn_t b99 tm 161c__gthread_mutex_t 1627_Atomic_word 163a__pool_base 17c5__pool 1998__mt_alloc_base 1a8e__common_pool 1adb__common_pool_base 1b2f__common_pool_policy 1b57__mt_alloc 1c62allocator 1cf0lconv 1e5c__numeric_traits_integer 1eccbasic_string 3293_Rep_base 32c4_Rep $ readelf --debug-dump=pubtypes t-dw4 Contents of the .debug_pubtypes section: Length: 394 Version: 2 Offset into .debug_info section: 0x0 Size of area in .debug_info section: 3926 Offset Name 2d ptrdiff_t 3f size_t 41e __FILE 25 __va_list_tag 42b wint_t 43e mbstate_t 34 char_traits 25 __pthread_internal_list b7f __compar_fn_t 25 tm 34 __pool_base 34 __pool 34 __mt_alloc_base 34 __common_pool 34 __common_pool_base 34 __common_pool_policy 34 __mt_alloc 34 allocator 25 lconv 34 __numeric_traits_integer 25 rebind 34 basic_string 34 _Rep_base 34 _Rep as you can see few types have the same offset 34. looks like a bug. -- Summary: broken debuginfo with dwarf4? Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: x86_64-gnu-linux GCC host triplet: x86_64-gnu-linux GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690
[Bug c++/45690] broken debuginfo with dwarf4?
--- Comment #1 from pluto at agmk dot net 2010-09-16 14:01 --- Created an attachment (id=21811) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21811action=view) source, makefile and precompiled binaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
--- Comment #10 from pluto at agmk dot net 2010-09-16 14:04 --- (In reply to comment #9) Are you sure you haven't modified your GCC sources? i'm testing gcc-4.5 from svn branch, with gdb-7.2 and binutils-2.20.51.0.11. filled as PR45690. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #17 from jakub at gcc dot gnu dot org 2010-09-16 14:08 --- That's true. But many expanders can make use of DECL_ALIGN information, e.g. to choose faster code. If cfgexpand keeps doing what it does now, namely bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY even when in the end the stack block doesn't end up being aligned that way, then it lies to the expander and that will hit us again and again. On x86-64/i686, I don't think we want to prevent memcpy folding as your patch does, at least not for CPUs where movu* is fast. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-16 14:13 --- (In reply to comment #16) (In reply to comment #13) With that patch the assignment generated from memcpy doesn't need more that int alignment, but still cfgexpand.c sets DECL_ALIGN of the decl to 128 so expand uses aligned instructions. cfgexpand.c should not increase alignment and not set 'needs stack alignment' then, based on your comment #10. So this _is_ about stack alignment (but maybe not exclusively). When we do float d[4]; __m128 *p = (__m128 *) d; all bets are off. ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #19 from hjl dot tools at gmail dot com 2010-09-16 14:17 --- (In reply to comment #17) That's true. But many expanders can make use of DECL_ALIGN information, e.g. to choose faster code. If cfgexpand keeps doing what it does now, namely bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY even when in the end the stack block doesn't end up being aligned that way, then it lies to the expander The problem isn't limited to stack. and that will hit us again and again. On x86-64/i686, I don't think we want to prevent memcpy folding as your patch does, at least not for CPUs where movu* is fast. That is true. Whatever we do, we can't lie about alignment, on stack or not. Once we fix that, the rest shouldn't be too hard to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-09-16 14:22 --- The patch in comment #4 makes memcpy folding not lie about alignment. cfgexpand still lies about alignment though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse
--- Comment #21 from hjl dot tools at gmail dot com 2010-09-16 14:30 --- (In reply to comment #20) The patch in comment #4 makes memcpy folding not lie about alignment. X86 only cares about alignment for vector modes. Can we combine 2 patches into one? cfgexpand still lies about alignment though. Let's open a new bug and fix it separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug middle-end/45687] [4.6 Regression] possible wrong code bug
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||wrong-code Summary|possible wrong code bug |[4.6 Regression] possible ||wrong code bug Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687
[Bug c++/45605] Missed devirtualization
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-09-16 14:55
---
Like
Index: gimplify.c
===
--- gimplify.c (revision 164333)
+++ gimplify.c (working copy)
@@ -2477,10 +2477,13 @@ gimplify_call_expr (tree *expr_p, gimple
gimplify_modify_expr. */
if (!want_value)
{
+ gimple_stmt_iterator gsi;
/* The CALL_EXPR in *EXPR_P is already in GIMPLE form, so all we
have to do is replicate it as a GIMPLE_CALL tuple. */
call = gimple_build_call_from_tree (*expr_p);
gimplify_seq_add_stmt (pre_p, call);
+ gsi = gsi_last (*pre_p);
+ fold_stmt (gsi);
*expr_p = NULL_TREE;
}
but gimple_fold_obj_type_ref_known_binfo returns NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45605] Missed devirtualization
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-16 16:00
---
(In reply to comment #15)
Like
Index: gimplify.c
===
--- gimplify.c (revision 164333)
+++ gimplify.c (working copy)
@@ -2477,10 +2477,13 @@ gimplify_call_expr (tree *expr_p, gimple
gimplify_modify_expr. */
if (!want_value)
{
+ gimple_stmt_iterator gsi;
/* The CALL_EXPR in *EXPR_P is already in GIMPLE form, so all we
have to do is replicate it as a GIMPLE_CALL tuple. */
call = gimple_build_call_from_tree (*expr_p);
gimplify_seq_add_stmt (pre_p, call);
+ gsi = gsi_last (*pre_p);
+ fold_stmt (gsi);
*expr_p = NULL_TREE;
}
Will this also work also for GIMPLE_CALLs with a LHS or do I have to
add something like the above also elsewhere?
but gimple_fold_obj_type_ref_known_binfo returns NULL.
cgraph_function_flags_ready needs to be added to the conjunction
(!node-analyzed !node-in_other_partition) and then it is folded.
I'll prepare a patch tomorrow.
Thanks, Martin
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-09-16 12:25:30 |2010-09-16 16:00:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug c++/45605] Missed devirtualization
--- Comment #17 from rguenther at suse dot de 2010-09-16 16:06 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, jamborm at gcc dot gnu dot org wrote:
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-16 16:00
---
(In reply to comment #15)
Like
Index: gimplify.c
===
--- gimplify.c (revision 164333)
+++ gimplify.c (working copy)
@@ -2477,10 +2477,13 @@ gimplify_call_expr (tree *expr_p, gimple
gimplify_modify_expr. */
if (!want_value)
{
+ gimple_stmt_iterator gsi;
/* The CALL_EXPR in *EXPR_P is already in GIMPLE form, so all we
have to do is replicate it as a GIMPLE_CALL tuple. */
call = gimple_build_call_from_tree (*expr_p);
gimplify_seq_add_stmt (pre_p, call);
+ gsi = gsi_last (*pre_p);
+ fold_stmt (gsi);
*expr_p = NULL_TREE;
}
Will this also work also for GIMPLE_CALLs with a LHS or do I have to
add something like the above also elsewhere?
Yes.
but gimple_fold_obj_type_ref_known_binfo returns NULL.
cgraph_function_flags_ready needs to be added to the conjunction
(!node-analyzed !node-in_other_partition) and then it is folded.
I'll prepare a patch tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
[Bug middle-end/44763] [4.4/4.5/4.6 regression] SEGV in allocno_priority_compare_func on Solaris 8
--- Comment #3 from ro at gcc dot gnu dot org 2010-09-16 16:37 --- Subject: Bug 44763 Author: ro Date: Thu Sep 16 16:37:01 2010 New Revision: 164341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164341 Log: Record PR middle-end/44763 in ChangeLog. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44763
[Bug middle-end/44763] [4.4/4.5/4.6 regression] SEGV in allocno_priority_compare_func on Solaris 8
--- Comment #4 from ro at gcc dot gnu dot org 2010-09-16 16:43 --- Fixed for 4.6.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||09/msg00035.html Known to fail|4.4.5 4.5.1 4.6.0 |4.4.5 4.5.1 Known to work|3.4.6 |3.4.6 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44763
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-09-16 16:54 --- (In reply to comment #12) I think it's likely there really is a miscompilation. I've not been able to get very far trying to set up a native compiler to run on qemu, so it would help if you could try to narrow it down a bit further. IIUC, stage1 and stage2 produce different output for some output files, such as expr.o. You could try to copy object files from stage1 to stage2, then rebuild the stage2 compiler with these objects, until these differences go away. In that way, you can determine which file is being miscompiled by stage1. The next step would be to find code generation differences for that file between r162417 and r162418. You might also narrow down the source of the problem by comparing the dump files from using the two compilers -- the time at which the dumps start to diverge will be a strong indicator of the point at which the problem was introduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-09-16 16:56 --- (In reply to comment #4) (In reply to comment #2) http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug. That's true. Interesting is that by doing preprocessed source out of it, result is correct. Just within compiler it makes troubles, as here garbage collector gets raised, which cleans up with store reference, as a root element for preprocessor tokens is missing to keep it alive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug c/45691] New: Floating point comparison failure
After upgrading to gcc 4.5.0 from 3.3.4, some of my floating point code fails.
Searched for and could not find a matching bug. It boils down to this very
simple example:
#include stdio.h
#define MY_PI 3.14159265358979323846
int main()
{
double z = MY_PI;
puts(z == MY_PI ? == : !=);
return 0;
}
If this is compiled gcc -o bug -Wall bug.c it works: there is equality.
Doesn't matter if optimization is used or not (-g, -O, -O2 all give same
results).
But if compiled with -ansi or -std=c99, then the equality fails, again
regardless of optimization!!
The preprocessed code looks as expected:
int main()
{
double z = 3.14159265358979323846;
puts(z == 3.14159265358979323846 ? == : !=);
return 0;
}
Cannot see how this is correct behavior since the exact same expression was
used to initialize the variable and to test for equality. Do not see anything
in my ANSI/ISO C reference that sheds any light.
I can work around this by using actual double constants instead of preprocessor
expressions (double my_pi_2 = MY_PI_2 and setting/testing with my_pi_2, etc),
but this should work as is!
--
Summary: Floating point comparison failure
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at macky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug c/45691] Floating point comparison failure
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 17:02 --- pr323? As a general rule: never compare floating points for equality, use abs(a-b)epsilon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-16 17:04 --- (In reply to comment #4) (In reply to comment #2) http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug. I think this is covered by: blockquoteThe only excuses to not send us the preprocessed sources are (i) if you've found a bug in the preprocessor,/blockquote A testcase is always nice, even if not preprocessed. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-16 17:04:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug c/45691] Floating point comparison failure
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-16 17:08 --- As an even more general rule, remember to always specify your target: in this case, for example, I can't reproduce at all the behavior on x86_64 -m64, only with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug c/45691] Floating point comparison failure
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 --- *** This bug has been marked as a duplicate of 323 *** *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 --- *** Bug 45691 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at macky dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c/45691] Floating point comparison failure
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-16 17:13 ---
i?86 is a FLT_EVAL_METHOD 2 target, so for strict C compliance all floating
operations and constants are supposed to be evaluated in the precision
of long double. The assignment of the constant to a double var or explicit
cast to double cause rounding to happen, so your testcase is evaluated as:
int main()
{
double z = 3.14159265358979323846L;
puts((long double) z == 3.14159265358979323846L ? == : !=);
return 0;
}
and of course (double) 3.14159265358979323846L != 3.14159265358979323846L.
You can use -fexcess-precision=fast (the default unless -std=c99/-std=c89
is requested) for the old behavior, or you can add explicit cast,
z == (double) M_PI, or (as usually a good idea) avoid floating point
equality/non-equality comparisons, instead check whether difference is
smaller than some epsilon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug c/45691] Floating point comparison failure
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-16 17:15 --- Thanks Jakub. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug bootstrap/45680] [4.6 regression] cc1 fails to link on Solaris 9/x86 with Sun as: min_insn_size missing
--- Comment #4 from spop at gcc dot gnu dot org 2010-09-16 17:19 --- Subject: Bug 45680 Author: spop Date: Thu Sep 16 17:19:25 2010 New Revision: 164345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164345 Log: Fix PR45680. 2010-09-16 Reza Yazdani reza.yazd...@amd.com PR bootstrap/45680 * config/i386/i386.c (min_insn_size): Moved out of the ASM_OUTPUT_MAX_SKIP_PAD ifdef. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45680
[Bug bootstrap/45680] [4.6 regression] cc1 fails to link on Solaris 9/x86 with Sun as: min_insn_size missing
--- Comment #5 from spop at gcc dot gnu dot org 2010-09-16 17:21 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45680
[Bug tree-optimization/45453] [4.6 Regression] ICE: verify_cgraph_node failed: inlined_to pointer set for noninline callers with -O2 -fno-early-inlining
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-16 17:36 --- Hmm, the problem is that foo is virtual self recursive function. We inline it and then indirect inlining decide that it can devirtualize the self recursive call since it knows the operand has proper type. At that time we already removed the function from callgraph since all direct calls was resolved, it is COMDAT and corresponding vtable is elsehwere. We have options: 1) Prevent devirtualization in this case 2) Special case COMDAT virtual functions in inliner and prevent them from being removed early 3) Make inliner to re-invent nodes for those functions. All solutions are sort of wrong. I am leaning towards 2) with extra code keeping virtual COMDAT till inlining stage (similarly as we do with extern inlines) so possible indirect calls can be resolved. Will give this a try. Proper solution here is probably introduction of may edges... Martin: Can we devirtualize the recursive call always based on fact that we go to the function so it got to be of proper type? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45453
[Bug c/45691] Floating point comparison failure
--- Comment #6 from ian at macky dot net 2010-09-16 17:44 --- Subject: Re: Floating point comparison failure Thanks everyone. I usually do fuzzy floating-point comparison, except in certain special circumstances. I will switch to using double constants; I'm trying for a code that is maximally portable, so having to worry about what exact compiler switches to use is anathema. And might I add: you people are super-fast! I'm very impressed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
[Bug c++/39934] Union member incorrectly disallowed
--- Comment #11 from dherring at tentpost dot com 2010-09-16 18:54 --- FWIW, the example given in the C++ draft spec, section 9.5, fails to compile in g++, even under version 4.5 with the -std=c++0x flag. (This example has been there for a few years.) Coupled with requirements such as operator= must be a nonstatic member function, this restriction is a real annoyance. -- dherring at tentpost dot com changed: What|Removed |Added CC||dherring at tentpost dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934
[Bug testsuite/45692] New: FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32
Since the test objc/execute/exceptions/throw-nil.m has been introduced at revision 164024, it has failed on *-apple-darwin* with -m32, see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00816.html http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00835.html -- Summary: FAIL: objc/execute/exceptions/throw-nil.m execution on darwin with -m32 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
[Bug target/45693] New: [4.6 regression] All Tru64 UNIX EH tests fail
Between 20100607 and 20100624, all Tru64 UNIX V5.1B EH tests started to fail, e.g. FAIL: g++.old-deja/g++.mike/eh33.C execution test This testcase segfaults like this: Program received signal SIGSEGV, Segmentation fault. __cxa_call_unexpected (exc_obj_in=0x70) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/unwind-cxx.h:374 374 return (c 1); (gdb) where #0 __cxa_call_unexpected (exc_obj_in=0x70) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/unwind-cxx.h:374 #1 0x000120001a40 in foo () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/eh33.C:10 #2 0x000120001a80 in main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/eh33.C:15 I'll start a reghunt to identify the culprit patch. Rainer -- Summary: [4.6 regression] All Tru64 UNIX EH tests fail Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693
[Bug middle-end/45694] New: fortran host associated variables+optimization==failure?
Hi, (i first reported this to mingw32-w64's bug tracker: http://sourceforge.net/tracker/?func=detailaid=3067541group_id=202880atid=983354 and was forwarded here) The attached fortran program aborts() (a host associated variable changes value from host to hostee without asking) using gfortran -O1 -o fail fail.f90; ./fail on a 64bit windows 7 (mingw32-w64) platform. Very probably platform dependent as i can't reproduce this elsewhere. Also 32bit compile on the same platform works as does unoptimized compilation. On a larger application i see sevaral failures of the same kind, seems to depend also on the number and/or size of the local variables in the procedures.. Regards, Juha PS. I entered middle-end as the bugs 'component' as an optimization flag seems to be needed to trigger this... -- Summary: fortran host associated variables+optimization==failure? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jpr at csc dot fi GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug middle-end/45694] fortran host associated variables+optimization==failure?
--- Comment #1 from jpr at csc dot fi 2010-09-16 19:31 --- Created an attachment (id=21812) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21812action=view) failing fortran code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug c++/45690] broken debuginfo with dwarf4?
--- Comment #2 from pluto at agmk dot net 2010-09-16 21:02 --- ha, my gcc was built with: export CXXFLAGS=-O2; ./configure --disable-shared... and this CXXFLAGS afaics affects libstdc++.a debuginfo level. with CXXFLAGS=-O2 -g2 the python pretty printer works fine. testcase compiled with -gdwarf-4 -g2 and linked with stripped libstdc++.a ends with undebugable std::string. of course with -gdwarf-3 everything works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #26 from burnus at gcc dot gnu dot org 2010-09-16 21:30 --- Subject: Bug 43665 Author: burnus Date: Thu Sep 16 21:30:05 2010 New Revision: 164348 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164348 Log: 2010-09-16 Tobias Burnus bur...@net-b.de PR fortran/43665 * trans-types.c (create_fn_spec): New function. (gfc_get_function_type): Call it. 2010-09-16 Tobias Burnus bur...@net-b.de PR fortran/43665 * gfortran.dg/cray_pointers_2.f90: Disable inlining to avoid optimizations. * gfortran.dg/intent_optimize_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_optimize_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/cray_pointers_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug c/45695] New: -O1 wrong-code by cmove
FSF GDB HEAD by FSF GCC 4.5.HEAD errors on `print 0|0' with -O1 and higher.
source below compiles to:
00400455 f:
400455: 53 push %rbx
400456: 39 fa cmp%edi,%edx
400458: 0f 44 decmove %esi,%ebx
but $ebx is left uninitialized for not-equal comparison.
Compilation flags: -O1
it passes = exit code 0 = with -O0
it fails = exit code 1 = with -O1
PASS: gcc (GCC) 4.4.5 20100916 (prerelease)
FAIL: gcc (GCC) 4.5.2 20100916 (prerelease)
PASS: gcc (GCC) 4.6.0 20100916 (experimental)
FAIL: gcc-4.5.1-3.fc14.x86_64
not re-verified but PASS: gcc-4.5.1-1.fc14.x86_64
__attribute__((noinline, noclone)) void
g (int x)
{
asm volatile ();
}
__attribute__((noinline, noclone)) int
f (int a, int b, int d)
{
int r = -1;
b += d;
if (d == a)
r = b - d;
g (b);
return r;
}
int
main (void)
{
asm volatile (mov $42, %%rbx : : : rbx);
return f (0, 1, 4) == 42 ? 1 : 0;
}
--
Summary: -O1 wrong-code by cmove
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
[Bug c/45695] -O1 wrong-code by cmove
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 21:57 --- Caused by my http://gcc.gnu.org/viewcvs?root=gccview=revrev=163555 change, so will look into it tomorrow. http://gcc.gnu.org/bugzilla/attachment.cgi?id=21560action=view doesn't break it, only the version that tries harder and tries it the other way around. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-16 21:57:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #8 from t7 at gmail dot com 2010-09-16 21:58 --- (In reply to comment #4) (In reply to comment #2) http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug. This is very odd, because I noticed, it could not produce this for example the 'just installed' gcc but the fault is only in xgcc. This can only means that something might not be correct in tree? or in the build process. However as it can show that this blocks the user 2 minutes from completing a GCC build. So why fail at the last minute... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, GC, ice-on-valid-code Summary|Dangling reference about|[4.6 Regression] Dangling |saved cpp_macro for push/pop|reference about saved |macro |cpp_macro for push/pop macro Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-16 22:00 --- GC issues normally don't show at different times depending on the layout of memory and such. Sometimes it depends on env variables being slightly different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #10 from t7 at gmail dot com 2010-09-16 22:03 --- Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cpp_macro (x_p=value optimized out) at gtype-desc.c:2078 2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).params[i0]))) : NULL; (gdb) bt #0 gt_ggc_mx_cpp_macro (x_p=value optimized out) at gtype-desc.c:2078 #1 0x004caee5 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:537 #2 0x004cb0c3 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:370 #3 0x004cbcc8 in gt_ggc_mx_c_binding (x_p=value optimized out) at ./gt-c-decl.h:103 #4 0x004cbcf2 in gt_ggc_mx_c_binding (x_p=value optimized out) at ./gt-c-decl.h:106 #5 0x004caea6 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:549 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #11 from t7 at gmail dot com 2010-09-16 22:06 --- But too bad this file 'gtype-desc.c' is automatically generated at build time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #12 from jakub at gcc dot gnu dot org 2010-09-16 22:28 --- Can you try compiling it with --param ggc-min-expand=0 --param ggc-min-heapsize=0 ? Perhaps you'll trigger it then more reliably... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #13 from t7 at gmail dot com 2010-09-16 22:33 --- (In reply to comment #12) Can you try compiling it with --param ggc-min-expand=0 --param ggc-min-heapsize=0 ? Perhaps you'll trigger it then more reliably... Without it: GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7ccff28a2de01cef50407f25bf137180 Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cpp_macro (x_p=value optimized out) at gtype-desc.c:2078 2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).params[i0]))) : NULL; (gdb) bt #0 gt_ggc_mx_cpp_macro (x_p=value optimized out) at gtype-desc.c:2078 With it: GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0 Compiler executable checksum: 7ccff28a2de01cef50407f25bf137180 Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_cpp_macro (x_p=value optimized out) at gtype-desc.c:2078 2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).params[i0]))) : NULL; (gdb) bt #0 gt_ggc_mx_cpp_macro (x_p=value optimized out) at gtype-desc.c:2078 #1 0x004caee5 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:537 #2 0x004cb0c3 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:370 #3 0x004cbcc8 in gt_ggc_mx_c_binding (x_p=value optimized out) at ./gt-c-decl.h:103 #4 0x004cbcf2 in gt_ggc_mx_c_binding (x_p=value optimized out) at ./gt-c-decl.h:106 #5 0x004caea6 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:549 #6 0x004cad62 in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:350 #7 0x004cb00d in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:413 #8 0x004caf8c in gt_ggc_mx_lang_tree_node (x_p=value optimized out) at ./gt-c-decl.h:393 I see no diff, do you mean compile the code that caused crash or compile the xgcc or gcc over again? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #49 from LpSolit at netscape dot net 2010-09-16 22:51 --- (In reply to comment #48) The current bugzilla has extra separating lines with the column names. The new installation does not. Yeah, it is so by design. Not something I'm going to reimplement. Note that we finally won't upgrade tomorrow. I have severe hardware failures with my PC, and I cannot reliably run the upgrade process under these conditions. It's a miracle when I can comment in a bug without seeing my PC shut down for no reason. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug rtl-optimization/45685] GCC optimizer for Intel x64 generates inefficient code
--- Comment #3 from ekuznetsov at divxcorp dot com 2010-09-16 23:08 --- Created an attachment (id=21813) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21813action=view) Output of gcc -v -O3 gcc-bug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
[Bug preprocessor/45696] New: Continuation character gets lost or not taken into account
Using gcc 4.6.0 20100915 trunk revision 164317 Using the preprocessor on following piece: --8-- error_identifiers: \ kErr_AlreadyWaitingForGDB(Already waiting for a GDB to connect) --8-- gcc -E gives me: --8-- # 1 test-preprocess.c # 1 built-in # 1 command-line # 1 test-preprocess.c error-identifiers: kErr_AlreadyWaitingForGDB(Already waiting for a GDB to connect) --8-- I.e. the continuation character got lost or was not taken into account. Either I expect it to survive the preprocessing, either it should have been taken into account like e.g. with gcc 4.1.2: --8-- # 1 test-preprocess.c # 1 built-in # 1 command line # 1 test-preprocess.c error-identifiers: kErr_AlreadyWaitingForGDB(Already waiting for a GDB to connect) --8-- -- Summary: Continuation character gets lost or not taken into account Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: John dot Tytgat at aaug dot net GCC build triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug c++/45697] New: __restrict__ inconsistent in presence of typedefs
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
typedef unsigned char uint8_t;
void f(uint8_t __restrict__ foo[]) {
// no warnings/errors
}
void f2(unsigned char __restrict__ foo[]) {
// doesn't compile::
// test.cc:6: error: __restrict__ qualifiers cannot be applied to unsigned
char
}
The two functions should be equivalent, I think -- both erroring or neither
erroring. Verbose details follow.
$ gcc -v -save-temps test.cc
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE test.cc
-D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -fpch-preprocess
-fstack-protector -o test.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/i486-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cc -mtune=generic -march=i486 -auxbase test -version
-fstack-protector -o test.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 35224f2c24023afb0a5be7befe8d5f3f
test.cc:6: error: __restrict__ qualifiers cannot be applied to unsigned
char
--
Summary: __restrict__ inconsistent in presence of typedefs
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: evan at chromium dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45697
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-16 23:55 --- C preprocessor is not a generic preprocessor. The continuation character is removed so the correct line number is used. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #2 from John dot Tytgat at aaug dot net 2010-09-17 00:04 --- I don't understand why the continuation character should be removed. For the C parser that character is not special (only for the C preprocessor it is), nor it confuses its line number accountancy. Or am I mistaken ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 00:06 --- (In reply to comment #2) I don't understand why the continuation character should be removed. For the C parser that character is not special (only for the C preprocessor it is), nor it confuses its line number accountancy. Or am I mistaken ? You are confused. It is removed so that the column information for the call to AlreadyWaitingForGDB is on the correct line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
