[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||mrs at gcc dot gnu.org --- Comment #15 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-03-01 08:07:08 UTC --- I don't think this is waiting on anything anymore. It would be nice if someone would check in the patch an unbreak the build, as it used to build.
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #6 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-03-01 08:09:51 UTC --- Please be sure to tag the changelog entries with the PR numbers, then the work will be automatically linked to the PRs.
[Bug libfortran/47938] New: libgfortran symbol version node bumped unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47938 Summary: libgfortran symbol version node bumped unnecessarily Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org As pointed out by Janus Weil at http://gcc.gnu.org/ml/fortran/2011-02/msg00298.html in 4.5 we have symbol version 1.2. The new symbols for 4.6 should thus be in version node 1.3. However, for some reason 4.6 has added both 1.3 and 1.4, which is unnecessary. We should remove the 1.4 node and merge the symbols into the 1.3 node. OTOH this change would mean that people would need to recompile code compiled with the pre-release 4.6.
[Bug c++/5026] __attribute__ ((unused) seems misdocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5026 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution||FIXED --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-01 08:51:32 UTC --- (In reply to comment #19) GCC documentation has been changed. __attribute__((unused)) on labels can be used in C++ code since GCC version 4.5.0. This PR should be closed probably. The less, the merrier. Thanks! (If you get a gcc.gnu.org account, you can do bug management: http://gcc.gnu.org/svnwrite.html#authenticated)
[Bug c/47931] missing -Waddress warning for comparison with NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-01 09:05:13 UTC --- PR 36299 asks to not warn for (a == 0). Ideally, we should allow users to workaround the warning by using a pointer cast on the variable but warn for (void *)0. I think this would be a reasonable middle-ground. But at the end, someone has to dig in the code and implement whatever he can. This part of the C FE is not very pretty.
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-01 09:14:27 UTC --- (In reply to comment #3) The documentation should be improved anyway (the word suspicious is very subjective). Please propose a patch. You should be able to work-around the macro case by casting the array to (char *) or perhaps casting to (void *) ? Yes, this makes sense. Perhaps this should be documented. Is it working? I meant to say ideally one should be able to do this but I don't think it is working right now (and probably there are not testcases testing this). How about something like __extension__, e.g. __no_warnings__ would disable the warnings for the following statement or expression? If expression, one could There was a patch floating around in gcc-patches to implement that but since GCC location info is far from perfect (especially on macro expansions), I think it won't work well in practice. Moreover, the preferred way is to use the existing diagnostic pragmas. http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
[Bug debug/47939] New: Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939
Summary: Missing DW_TAG_typedef for qualified types
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
typedef const struct _George { int dummy; } George_t;
George_t george;
lacks a DW_TAG_typedef for George_t. Compare that to
typedef struct _George { int dummy; } George_t;
George_t george;
where a DW_TAG_typedef for George_t appears.
[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46911 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 09:45:09 UTC --- Author: rguenth Date: Tue Mar 1 09:45:05 2011 New Revision: 170588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170588 Log: 2011-03-01 Richard Guenther rguent...@suse.de PR lto/46911 * lto-streamer-in.c (lto_input_ts_decl_common_tree_pointers): Do not stream DECL_ABSTRACT_ORIGIN. (lto_input_ts_block_tree_pointers): Nor BLOCK_SOURCE_LOCATION, BLOCK_NONLOCALIZED_VARS or BLOCK_ABSTRACT_ORIGIN. * lto-streamer-out.c (lto_output_ts_decl_common_tree_pointers): Do not stream DECL_ABSTRACT_ORIGIN. (lto_output_ts_block_tree_pointers): Nor BLOCK_SOURCE_LOCATION, BLOCK_NONLOCALIZED_VARS or BLOCK_ABSTRACT_ORIGIN. * gfortran.dg/lto/pr46911_0.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/lto/pr46911_0.f Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog
[Bug lto/47924] [4.6 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47924 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 09:46:22 UTC --- Author: rguenth Date: Tue Mar 1 09:46:19 2011 New Revision: 170589 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170589 Log: 2011-03-01 Richard Guenther rguent...@suse.de PR lto/47924 * lto-streamer.c (lto_record_common_node): Also register the canonical type. * gcc.dg/lto/pr47924_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr47924_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer.c trunk/gcc/testsuite/ChangeLog
[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46911 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 09:46:36 UTC --- Fixed.
[Bug lto/47924] [4.6 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47924 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 09:46:57 UTC --- Fixed.
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-01 10:00:01 UTC --- The regression appeared between revisions 158105 and 159105.
[Bug c++/47940] New: can call a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940
Summary: can call a pure virtual from a constructor/destructor
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@yandex.ru
A colleague of mine have been examining a crash that
boils down to the following:
--hellobug.cpp--
class Base {
public:
Base() { usefunc(); }
virtual void func()=0;
void usefunc() { func(); }
};
class Derived: public Base {
public:
virtual void func() {}
};
int main() {
Derived d;
return 0;
}
--eof--
$ g++ -Wall -Wextra hellobug.cpp
{just nothing}
$ ./a.out
pure virtual method called
terminate called without an active exception
Aborted
That is, you asked for it, you got it [1].
==
[1] from Real Programmers Don't
==
A variation:
==byebug.cpp==
#include stdio.h
class Base {
public:
~Base() { usefunc(); }
virtual void func()=0;
void usefunc() { func(); }
};
class Derived: public Base {
public:
virtual void func() {}
};
int main() {
Derived d;
printf(life is good\n);
return 0;
}
==eof==
$ g++ -Wall -Wextra byebug.cpp
{again nothing}
$ ./a.out
life is good
pure virtual method called
terminate called without an active exception
Aborted
I have to note that in a big software project,
the mistake is not so obvious.
But what can be done?
Functions that call pure virtual functions cannot
be called from constructors and destructors.
This may be discovered at compile-time, and the above
text makes a good error/warning message.
WHAT I GET: no warning
WHAT I WOULD EXPECT: a warning or an error message:
Functions that call pure virtual functions cannot
be called from constructors and destructors
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --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 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
[Bug libfortran/47938] libgfortran symbol version node bumped unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47938 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-01 10:10:12 UTC --- I'd say this is too late to change it now, the benefit isn't that big and the pain that would be caused by it is large.
[Bug c++/47940] can call a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-03-01 10:13:57 UTC --- This is hard to detect really. Basically what the function usefunc needs to marked as calling a virtual function. If the call was direct to func instead, it would be better.
[Bug c/47931] missing -Waddress warning for comparison with NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 10:16:45 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:16:45 UTC --- Confirmed.
[Bug c/47932] __typeof__ prevents VLA from being evaluated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47932 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:18:51 UTC --- Fixed in 4.5.
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||d.g.gorbachev at gmail dot ||com --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:20:47 UTC --- *** Bug 47934 has been marked as a duplicate of this bug. ***
[Bug lto/47934] LTO: function with attribute used is emitted under the wrong name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47934 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:20:47 UTC --- dup *** This bug has been marked as a duplicate of bug 43038 ***
[Bug c++/5026] __attribute__ ((unused) seems misdocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5026 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.0
[Bug rtl-optimization/47918] [4.6 Regression] noreturn discovery broke non local gotos on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org Summary|[4.6 regression] noreturn |[4.6 Regression] noreturn |discovery broke non local |discovery broke non local |gotos on m68k |gotos on m68k
[Bug lto/47936] [4.6 Regression] Missed optimization with LTO due to strict aliasing issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47936 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 10:28:51 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:28:51 UTC --- Confirmed. This one happens because we merge struct S and struct T for TBAA purposes (they get the same TYPE_CANONICAL). This is by design to allow cross-language (and slightly invalid) code to not fall over TBAA issues too easily.
[Bug lto/47936] [4.6 Regression] Missed optimization with LTO due to strict aliasing issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47936 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:30:12 UTC --- IMHO WONTFIX. Eventually we could add a -fvery-strict-aliasing, but it's probably not worth it. Leaving open to eventually document this fact somewhere.
[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:36:33 UTC --- I'm testing this variant.
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-01
10:39:21 UTC ---
(In reply to comment #3)
-std=f95 no longer generates the error that it should:
logical, parameter :: buf(3) = [(any(sc(i) ==nc), i = 1, 3)]
1
Error: transformational intrinsic 'any' at (1) is not permitted in an
initialization expression
Ignoring the issue of [ ] vs. (/ /) which kicks in first: gfortran 4.4
diagnoses this, 4.5/4.6 do not.
I think one reason that the error no longer is shown is the change with regards
to constant vs. initialization expression. Fortran 2003 merged the two concepts
to the name initialization expressions (which were renamed to constant
expressions in F2008) - but in Fortran 95 not every constant expression was an
initialization expression and some places mandated an initialization
expression. F95 had:
7.1.6.1 Constant expression
A constant expression is an expression in which each operation is intrinsic
and each primary is [...] (5) A transformational intrinsic function reference
where each argument is a constant
expression,
In the same section, initialization expressions are defined, which do not
allows the transformational function NULL - and no other one.
Thus, it might be that the missing diagnosis is a side effect of the
F2003/F2008 support. (I think one needs to revamp that area as there are
several bugs; unfortunately, it is a tedious task.)
* * *
Regarding the simplification, I tried the following patch, but that fails due
to the above mentioned bug/mess with gfortran's implementation of init-expr vs.
const-expr.
In particular: The gfc_is_constant_expr(e) returns false as e-value.op.op1 is
EXPR_VARIABLE (of attr.flavor FL_PARAMETER) and that function simply returns
0 if it encounters EXPR_VARIABLE.
I sincerely believe the we do not want to touch the const/init-expr mess when
the 4.6 release is imminent.
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -231,9 +231,17 @@ is_constant_array_expr (gfc_expr *e)
if (e == NULL)
return true;
- if (e-expr_type != EXPR_ARRAY || !gfc_is_constant_expr (e))
+ if (!gfc_is_constant_expr (e))
return false;
+ if (e-expr_type != EXPR_ARRAY)
+{
+ if (gfc_simplify_expr (e,1) != SUCCESS)
+ return false;
+ if (e-expr_type != EXPR_ARRAY)
+ return false;
+}
+
for (c = gfc_constructor_first (e-value.constructor);
c; c = gfc_constructor_next (c))
if (c-expr-expr_type != EXPR_CONSTANT
[Bug lto/47799] LTO debug info for early inlined functions missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47799 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 10:45:01 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 10:45:01 UTC --- The situation has been intentionally made worse with 2011-03-01 Richard Guenther rguent...@suse.de PR lto/46911 * lto-streamer-in.c (lto_input_ts_decl_common_tree_pointers): Do not stream DECL_ABSTRACT_ORIGIN. (lto_input_ts_block_tree_pointers): Nor BLOCK_SOURCE_LOCATION, BLOCK_NONLOCALIZED_VARS or BLOCK_ABSTRACT_ORIGIN. * lto-streamer-out.c (lto_output_ts_decl_common_tree_pointers): Do not stream DECL_ABSTRACT_ORIGIN. (lto_output_ts_block_tree_pointers): Nor BLOCK_SOURCE_LOCATION, BLOCK_NONLOCALIZED_VARS or BLOCK_ABSTRACT_ORIGIN. a proper solution will involve streaming of the effect of that debug hook (via early debug info). The guality test passes now as the variable appears as if it was a local one (but breaking on the inlined foo is no longer possible).
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||franke.daniel at gmail dot ||com --- Comment #6 from Paul Thomas pault at gcc dot gnu.org 2011-03-01 10:48:46 UTC --- (In reply to comment #4) The regression appeared between revisions 158105 and 159105. (In reply to comment #4) The regression appeared between revisions 158105 and 159105. In the above revision range r158253 looks by far the most likely candidate for this regression. It carrys the handles jvdeli...@gcc.gnu.org and franke.dan...@gmail.com. I have CC'd Daniel as the principal author. Paul
[Bug c++/47940] can call a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940 --- Comment #2 from mlg mlg7 at yandex dot ru 2011-03-01 11:34:30 UTC --- Yes it _is_ hard to detect. My colleague was suspecting a build system bug/feature at first (hours for a full rebuild). If it was a direct call, there would be a linker error. If the call was direct to func instead, it would be better. Unfortunately or fortunately, refactoring a huge real world application to make bugs easier for the compiler to detect is not an option.
[Bug tree-optimization/47404] gcc.dg/pr46909.c FAILs on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47404 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2011-03-01 11:48:34 UTC --- Seems so: the test passes since 20110222. *** This bug has been marked as a duplicate of bug 47835 ***
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #8 from Rainer Orth ro at gcc dot gnu.org 2011-03-01 11:48:34 UTC --- *** Bug 47404 has been marked as a duplicate of this bug. ***
[Bug libfortran/47938] libgfortran symbol version node bumped unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47938 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 2011-03-01 11:50:33 UTC --- Yes, I'm leaning that way as well. FWIW, from looking at commit logs and old mails, it seems 1.4 was added due to some confusion with symbol versioning and ABI compatibility. In any case, closing as wontfix. If anyone comes up with a convincing argument why this should be fixed, please reopen (and, be quick about it as 4.6 is going to be released quite soon I think, and after that we certainly can't remove a symbol node in a released branch).
[Bug c++/47940] warn about calls to a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Summary|can call a pure virtual |warn about calls to a pure |from a |virtual from a |constructor/destructor |constructor/destructor --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-01 12:19:40 UTC --- (In reply to comment #2) If it was a direct call, there would be a linker error. Not if the pure virtual has a definition, and not with all compilers. G++ does warn about that case though. None of the compilers I tested issued a diagnostic about indirectly making a virtual call to a pure virtual function.
[Bug c++/47940] warn about calls to a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-01
12:30:06 UTC ---
(In reply to comment #0)
Functions that call pure virtual functions cannot
be called from constructors and destructors.
This may be discovered at compile-time, and the above
text makes a good error/warning message.
I'm not sure it makes a good diagnostic, consider:
struct abc {
abc(bool nasal_demons) { if (nasal_demons) fly(); }
void fly() { doFly(); }
virtual void doFly() = 0;
};
Ideally the diagnostic for this would say may call a pure virtual for cases
where it can't be determined.
But then I don't really like the current diagnostic for direct calls either:
warning: abstract virtual 'virtual void abc::doFly()' called from constructor
I don't like the duplication of the word virtual and I don't like the term
abstract virtual - the class is abstract, the function is pure virtual.
[Bug c++/47940] warn about calls to a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-01 12:32:19 UTC --- (In reply to comment #4) abstract virtual - the class is abstract, the function is pure virtual. I forgot I already changed that ;) http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00437.html
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2011-03-01 12:45:34 UTC --- (In reply to comment #5) (In reply to comment #3) -std=f95 no longer generates the error that it should: logical, parameter :: buf(3) = [(any(sc(i) ==nc), i = 1, 3)] 1 Error: transformational intrinsic 'any' at (1) is not permitted in an initialization expression Ignoring the issue of [ ] vs. (/ /) which kicks in first: gfortran 4.4 diagnoses this, 4.5/4.6 do not. I think one reason that the error no longer is shown is the change with regards to constant vs. initialization expression. Fortran 2003 merged the two concepts to the name initialization expressions (which were renamed to constant expressions in F2008) - but in Fortran 95 not every constant expression was an initialization expression and some places mandated an initialization expression. F95 had: Well regardless of the evolution of the standard, I expect that -std=f95 would know the difference between the two. Cheers Paul
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #8 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-03-01 12:46:39 UTC --- The problem is that statics need to be mangled, so they persist as i.1234 instead. Really refering to a local symbol in asm is going to be difficult with LTO (any global or other static symbol with name i will cause a non-resolvable conflict). One solution is to introduce a new attribute, say nomangle, and shift responsibility for possible conflicts on a user.
[Bug tree-optimization/47896] wrong code with -O -fno-early-inlining -fipa-pta -fno-tree-dominator-opts -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47896 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||alias --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 12:50:35 UTC --- This is a failure to handle return-slot-optimization in IPA-PTA properly. For D.2098 = foo (); [return slot optimization] we have to make foos return function part point to D.2098. That requires some re-org, making the function result varinfo always a pointer, making sure to use *result for result-decl uses (if not DECL_BY_REFERENCE). I have a patch, but as this bug only affects IPA-PTA I'm defering it to 4.7 as the patch also touches non-IPA parts.
[Bug lto/47941] New: [4.6 Regression] FAIL: gcc.dg/guality/vla-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47941 Summary: [4.6 Regression] FAIL: gcc.dg/guality/vla-2.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: rgue...@gcc.gnu.org On Linux/ia32, revision 170589 gave FAIL: gcc.dg/guality/vla-2.c -O2 -flto line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 -flto line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 -flto -flto-partition=none line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 -flto -flto-partition=none line 25 sizeof (a) == 6 * sizeof (int) Revision 170587 is OK. It is caused by either revision 170588 or http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg9.html revision 170589: http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg8.html
[Bug c++/47942] New: Not possible to initialize a shared_ptr with a class defined in function scope, inheriting from a global scope base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47942
Summary: Not possible to initialize a shared_ptr with a class
defined in function scope, inheriting from a global
scope base class
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: skagge...@gmail.com
Here's some code reproducing the problem:
#include memory
struct Base {
virtual ~Base() {}
};
typedef std::tr1::shared_ptrBase BasePtr;
BasePtr GetImpl() {
struct InlineImpl : Base{
};
return BasePtr(new InlineImpl);
}
int main() {
BasePtr ptr = GetImpl();
}
The result is:
In function 'BasePtr GetImpl()':
Line 13: error: no matching function for call to
'std::tr1::shared_ptrBase::shared_ptr(GetImpl()::InlineImpl*)'
If I change from shared_ptrBase to Base* it works as expected. It also works
as expected if I do return Base(reinterpret_castBase*(new InlineImpl)).
Best regards,
Johan Andersson
[Bug lto/47943] New: PRE fails to move a load before a loop with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47943 Summary: PRE fails to move a load before a loop with LTO Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org When compiling the provided testcase with LTO, PRE fails to hoist the load of reg-node from the loop. Though this slows down the testcase only marginally, it has a substantial performance impact for 462.libquantum from SPEC 2006. When compiling the test case without LTO, PRE does move the load before the loop. Observed at least with trunk revision 170357 (2011-02-21), compiling at -Ofast with and without -flto.
[Bug lto/47943] PRE fails to move a load before a loop with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47943 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-01 13:11:23 UTC --- Created attachment 23499 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23499 Testcase The testcase.
[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 13:18:29 UTC --- Author: rguenth Date: Tue Mar 1 13:18:25 2011 New Revision: 170593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170593 Log: 2011-03-01 Richard Guenther rguent...@suse.de PR tree-optimization/47890 * tree-vect-loop.c (get_initial_def_for_induction): Set related stmt properly. * gcc.dg/torture/pr47890.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47890.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/47890] [4.5 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] internal |internal compiler error: in |compiler error: in |vect_get_vec_def_for_stmt_c |vect_get_vec_def_for_stmt_c |opy, at |opy, at |tree-vect-stmts.c:1186 |tree-vect-stmts.c:1186 Known to fail|4.6.0 | --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 13:18:53 UTC --- Fixed on trunk sofar.
[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47923 --- Comment #6 from Mirko mirko.chioldin at iside dot bcc.it 2011-03-01 13:20:17 UTC --- Hello, I have tried to compile with XLC. I set the variables with the following lines: export LDR_CNTRL=MAXDATA=0x5000 export LDR_CNTRL=MACDATA=0x3000 export PATH=/usr/vac/bin:/usr/vacpp/bin:$PATH. export CXX=/usr/vac/bin/xlc export LD=/usr/vac/bin/xlc export LIBPATH=/usr/vac/lib:/usr/vacpp/lib:/usr/lib: export LD_LIBRARY_PATH=$LIBPATH export PATH=/users/app/gcc/bin:$PATH:. I run these command: ../gcc-4.5.2/configure --enable-languages=c,c++ --prefix=/users/app/gcc-4.5.2 --mandir=/users/app/gcc/man --infodir=/users/app/gcc/share/info --enable-version-specific-runtime-libs --disable-nls --host=powerpc-ibm-aix6.1.0.0 --enable-static --enable-threads=aix --enable-shared make CFLAGS='-O0' CXXFLAGS='-O0' LIBCFLAGS='-O0' LIBCXXFLAGS='-O0 -fno-implicit-templates' bootstrap But the compilation stops anyway. What can I do? Mirko
[Bug fortran/47844] Array stride ignored for pointer-valued function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|I/O: data transfer |Array stride ignored for |statement: Array stride |pointer-valued function |ignored for pointer-valued |results |function results| --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-01 13:20:28 UTC --- Does not only affect I/O but also assignment; cf. example below. integer, target :: tgt(5) = [1,2,3,4,5] integer :: var(3) var = f(tgt) ! should assign 1 3 5 print *, ptr ! butprints 1 2 3 contains function f(x) integer, target :: x(:) integer, pointer :: f(:) f = x(::2) end function f end
[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47923 --- Comment #7 from Mirko mirko.chioldin at iside dot bcc.it 2011-03-01 13:20:54 UTC --- Created attachment 23500 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23500 Test with XLC
[Bug lto/47941] [4.6 Regression] FAIL: gcc.dg/guality/vla-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47941 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 13:24:55 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 13:24:55 UTC --- Confirmed. The regression is by design. And really a dup of PR47799. (gdb) p sizeof a $5 = 0
[Bug c++/47942] Not possible to initialize a shared_ptr with a class defined in function scope, inheriting from a global scope base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47942 --- Comment #1 from Johan Andersson skagget77 at gmail dot com 2011-03-01 13:28:26 UTC --- I might add that this bug is also present in gcc (Debian 4.4.5-11) 4.4.5.
[Bug lto/47943] PRE fails to move a load before a loop with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47943 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.01 13:34:01 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 13:34:01 UTC --- I think this is a dup of PR47924 as I now get bb 7: pretmp.8_39 = reg_3(D)-node; pretmp.10_19 = 1 control2_20(D); pretmp.10_42 = 1 control1_10(D); pretmp.10_43 = pretmp.10_19 | pretmp.10_42; bb 3: # i_17 = PHI i_37(10), 0(7)
[Bug c++/47942] Not possible to initialize a shared_ptr with a class defined in function scope, inheriting from a global scope base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47942 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-01 13:37:25 UTC --- 1) GCC 4.1.2 is ancient and unmaintained 2) your example code doesn't compile (should #include tr1/memory) 3) in C++03 you cannot use a type without linkage as a template argument 4) You should not use reinterpret_cast, static_cast is correct Your options are either to use C++0x mode (classes without linkage can be used as template arguments in C++0x) or to upcast the pointer
[Bug tree-optimization/47944] New: Several graphite tests SEGV on Solaris 10/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47944 Summary: Several graphite tests SEGV on Solaris 10/x86 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: s...@gcc.gnu.org Host: i386-pc-solaris2.10 Target: i386-pc-solaris2.10 Build: i386-pc-solaris2.10 I've recently started trying to bootstrap/test mainline with graphite. I'm using ppl-0.11.1 built with g++ 4.4.2 (-g -O2) or g++ 4.5.2 (-g3 -O0) on Solaris 9/x86 and cloog-parma-0.16.1 built with g++ 4.4.2 (-g -O2). All support libraries (ppl, cloog, gmpxx) are built statically. Unfortunately, several graphite tests SEGV in this configuration, e.g. FAIL: gcc.dg/graphite/id-14.c (internal compiler error) FAIL: gcc.dg/graphite/id-14.c (test for excess errors) I get $ cc1 id-14.i -quiet -O2 -fgraphite-identity /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/graphite/id-14.c: In function 'foo': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/graphite/id-14.c:7:1: internal compiler error: Segmentation Fault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] Parma_Polyhedra_Library::Constraint_System::insert (this=0x804705c, c=...) at /vol/gcc/src/ppl/ppl-0.11.1/src/Constraint_System.cc:244 244 if (topology() == c.topology()) (gdb) where #0 Parma_Polyhedra_Library::Constraint_System::insert (this=0x804705c, c=...) at /vol/gcc/src/ppl/ppl-0.11.1/src/Constraint_System.cc:244 #1 0x08ab5991 in Parma_Polyhedra_Library::Constraint_System::add_low_level_constraints (this=0x804705c, topol=Parma_Polyhedra_Library::NECESSARILY_CLOSED, num_dimensions=1, kind=Parma_Polyhedra_Library::UNIVERSE) at /vol/gcc/src/ppl/ppl-0.11.1/src/Constraint_System.inlines.hh:184 #2 Polyhedron (this=0x804705c, topol=Parma_Polyhedra_Library::NECESSARILY_CLOSED, num_dimensions=1, kind=Parma_Polyhedra_Library::UNIVERSE) at /vol/gcc/src/ppl/ppl-0.11.1/src/Polyhedron_nonpublic.cc:63 #3 0x08a79668 in C_Polyhedron (pph=0x9021fe8, d=1, empty=0) at ../../src/ppl.hh:38014 #4 Pointset_Powerset (pph=0x9021fe8, d=1, empty=0) at ../../src/ppl.hh:14498 #5 ppl_new_Pointset_Powerset_C_Polyhedron_from_space_dimension ( pph=0x9021fe8, d=1, empty=0) at ppl_c_Pointset_Powerset_C_Polyhedron.cc:76 #6 0x08936db4 in find_scop_parameters (scop=0x9021fd0) at /vol/gcc/src/hg/trunk/local/gcc/graphite-sese-to-poly.c:951 #7 build_poly_scop (scop=0x9021fd0) at /vol/gcc/src/hg/trunk/local/gcc/graphite-sese-to-poly.c:3285 #8 0x0891efcc in graphite_transform_loops () at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:268 #9 0x085ad427 in graphite_transforms () at /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-loop.c:256 #10 0x08411fa4 in execute_one_pass (pass=0x8e60d20) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1556 #11 0x084122bd in execute_pass_list (pass=0x8e60d20) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1611 #12 0x084122d0 in execute_pass_list (pass=0x8e60d60) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1612 #13 0x084122d0 in execute_pass_list (pass=0x8e60ee0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1612 #14 0x084122d0 in execute_pass_list (pass=0x8e605e0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1612 #15 0x0851997a in tree_rest_of_compilation (fndecl=0xfedf3500) at /vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422 #16 0x086e20e6 in cgraph_expand_function (node=0xfed76540) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1576 #17 0x086e4c95 in cgraph_expand_all_functions () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1635 #18 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1899 #19 0x086e52d5 in cgraph_finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1096 #20 0x08139df8 in c_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/c-decl.c:9872 #21 0x084bba55 in compile_file (argc=5, argv=0x80475c4) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:591 #22 do_compile (argc=5, argv=0x80475c4) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1900 #23 toplev_main (argc=5, argv=0x80475c4) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1963 #24 0x08b9542b in main (argc=5, argv=0x80475c4) at /vol/gcc/src/hg/trunk/local/gcc/main.c:36 The problem is that Parma_Polyhedra_Library::Constraint_System::insert is called with c = NULL. Roberto Bagnara gave the essential hint: before the SEGV, there are two calls to ppl_initialize #0 ppl_initialize () at /vol/gcc/src/ppl/ppl-0.11.1/interfaces/C/ppl_c_implementation_common.cc:182 #1 0x0891ee96 in graphite_initialize () at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:206 #2 graphite_transform_loops () at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:252 #3
[Bug c++/47942] Not possible to initialize a shared_ptr with a class defined in function scope, inheriting from a global scope base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47942 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-01 13:45:26 UTC --- (In reply to comment #2) Your options are either to use C++0x mode (classes without linkage can be used as template arguments in C++0x) or to upcast the pointer It seems that the change to allow local types as template args (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm for the proposal) was implemented in GCC 4.5, so you can't rely on that in 4.4 So the best option is: return BasePtr(static_castBase*(new InlineImpl));
[Bug c++/47942] Not possible to initialize a shared_ptr with a class defined in function scope, inheriting from a global scope base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47942 --- Comment #4 from Johan Andersson skagget77 at gmail dot com 2011-03-01 13:58:00 UTC --- Thanks for the quick reply and advice to use static_cast, the reinterpret_cast was a temporary memory lapse! The old GCC version was because I used a web-interface to verify the problem. I'm normally on Windows and Visual C++. (In reply to comment #3) (In reply to comment #2) Your options are either to use C++0x mode (classes without linkage can be used as template arguments in C++0x) or to upcast the pointer It seems that the change to allow local types as template args (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm for the proposal) was implemented in GCC 4.5, so you can't rely on that in 4.4 So the best option is: return BasePtr(static_castBase*(new InlineImpl));
[Bug libfortran/47945] New: REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 Summary: REAL(8) output conversion error on MinGW32 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The last digits of REAL(8) numbers are converted inaccurately on output. For instance, the output of: real(8) :: r8 real(16) :: r16 r8 = .14285714285714286d0 r16 = r8 write(*, '(f35.32)') r8 write(*, '(f35.32)') r16 end is: 0.142857142857142849218750 0.14285714285714284921269268124888 but the expected output is: 0.14285714285714284921269268124888 0.14285714285714284921269268124888 because the internal 64-bit representation of .14285714285714286 is approximately equal to 0.14285714285714284921269268124888... Arguably, an output of 0.14285714285714285000 would equally be acceptable, because it is the shortest decimal representation of the same internal value. (This is in fact what the GCC C Compiler on mingw32 does)
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #1 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-01 14:01:32 UTC --- Created attachment 23501 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23501 Test case
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-01 14:01:56 UTC --- Created attachment 23502 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23502 C test case
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 14:11:28 CC||jsm28 at gcc dot gnu.org Component|debug |c Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 14:11:28 UTC --- Happens because when finishing the TYPE_DECL if (is_naming_typedef_decl (decl)) /* We want that all subsequent calls to lookup_type_die with TYPE in argument yield the DW_TAG_typedef we have just created. */ equate_type_number_to_die (type, type_die); returns false. Which is because is_cxx () is returning false. The VAR_DECL itself is not using the type-def id: var_decl 0x75b49000 george type record_type 0x75b2a498 _George readonly type_0 SI size integer_cst 0x77ed36e0 constant 32 unit size integer_cst 0x77ed33e8 constant 4 align 32 symtab -172776352 alias set -1 canonical type 0x75b2a498 fields field_decl 0x75b36130 dummy type integer_type 0x77ee6498 int SI file t.c line 1 col 36 size integer_cst 0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4 align 32 offset_align 128 offset integer_cst 0x77ed3410 constant 0 bit offset integer_cst 0x77ed3b68 constant 0 context record_type 0x75b2a3f0 _George context translation_unit_decl 0x77efca10 D.1588 readonly asm_written public static common SI file t.c line 2 col 10 size integer_cst 0x77ed36e0 32 unit size integer_cst 0x77ed33e8 4 align 32 context translation_unit_decl 0x77efca10 D.1588 (mem/s/u/c:SI (symbol_ref:DI (george) var_decl 0x75b49000 george) [0 george+0 S4 A32]) already grokdeclarator creates this by re-applying qualifiers via if (!flag_gen_aux_info (TYPE_QUALS (element_type))) type = TYPE_MAIN_VARIANT (type); type_quals = ((constp ? TYPE_QUAL_CONST : 0) | (restrictp ? TYPE_QUAL_RESTRICT : 0) | (volatilep ? TYPE_QUAL_VOLATILE : 0) | ENCODE_QUAL_ADDR_SPACE (address_space)); and 6010type = c_build_qualified_type (type, type_quals); thereby stripping all uses of typedef ids. Thus, it doesn't seem to distinguish between qualifiers applied at the declaration and qualifiers that are part of the typedef. c_build_qualified_type would handle choosing a variant with the same name just fine - but we feed it the main variant instead of the original type. Index: gcc/c-decl.c === --- gcc/c-decl.c(revision 170589) +++ gcc/c-decl.c(working copy) @@ -6007,7 +6007,7 @@ grokdeclarator (const struct c_declarato /* An uninitialized decl with `extern' is a reference. */ int extern_ref = !initialized storage_class == csc_extern; - type = c_build_qualified_type (type, type_quals); + type = c_build_qualified_type (declspecs-type, type_quals); /* C99 6.2.2p7: It is invalid (compile-time undefined behavior) to create an 'extern' declaration for a fixes this particular testcase. Joseph?
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2011-03-01 14:27:54 UTC --- 0.142857142857142849218750 is still within the accuracy of IEEE double. All numbers map to the same IEEE double.
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01
14:31:35 UTC ---
The lack of knowledge of George_t is the worst side-effect of this bug.
/* { dg-do run } */
/* { dg-options -g } */
typedef struct _Harry { int dummy; } Harry_t;
Harry_t harry; /* { dg-final { gdb-test 12 ((Harry_t *)harry)-dummy 0 } }
*/
typedef const struct _George { int dummy; } George_t;
George_t george; /* { dg-final { gdb-test 12 ((George_t *)george)-dummy 0
} } */
typedef const Harry_t Michael_t;
Michael_t michael; /* { dg-final { gdb-test 12 ((Michael_t *)michael)-dummy
0 } } */
int main()
{
return 0;
}
currently George_t and Michael_t using tests are UNSUPPORTED (error in
processing the command).
The patch has weird side-effects on diagnostics, it only shows a possible
hint as to what the reason is we drop the TYPE_NAME.
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 14:36:31 UTC --- Better patch, I'm giving that a quick test. Index: c-decl.c === --- c-decl.c(revision 170589) +++ c-decl.c(working copy) @@ -5038,7 +5038,7 @@ grokdeclarator (const struct c_declarato error_at (loc, conflicting named address spaces (%s vs %s), c_addr_space_name (as1), c_addr_space_name (as2)); - if (!flag_gen_aux_info (TYPE_QUALS (element_type))) + if (!flag_gen_aux_info type != element_type (TYPE_QUALS (element_type))) type = TYPE_MAIN_VARIANT (type); type_quals = ((constp ? TYPE_QUAL_CONST : 0) | (restrictp ? TYPE_QUAL_RESTRICT : 0)
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-01 14:44:54 UTC --- (In reply to comment #3) 0.142857142857142849218750 is still within the accuracy of IEEE double. All numbers map to the same IEEE double. This is technically correct; however a program should also observe portability and usability rules and not just pick any number from a valid range, but the number which is the most useful to the program user: either the one most common across platforms and other compilers (0.14285714285714284921269268124888) or the shortest one (0.14285714285714285000). It is very hard to compare long numeric result listings obtained on different platforms/compilers if some digits (however insignificant) never match.
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 14:49:43 UTC --- That said, specifying -aux-info /dev/null also fixes this bug. Huh.
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299 --- Comment #5 from Vincent Lefèvre vincent at vinc17 dot org 2011-03-01 15:05:19 UTC --- Under Debian, I can no longer reproduce the problem with GCC 4.5.2: $ gcc-4.5 -Wall warn-nulladdress.c $ gcc-4.5 -Waddress warn-nulladdress.c $ gcc-4.4 -Wall warn-nulladdress.c warn-nulladdress.c: In function ‘main’: warn-nulladdress.c:14: warning: the address of ‘a’ will never be NULL $ gcc-4.4 -Waddress warn-nulladdress.c warn-nulladdress.c: In function ‘main’: warn-nulladdress.c:14: warning: the address of ‘a’ will never be NULL So, I assume that it has been fixed anyway. Do you confirm?
[Bug debug/47946] New: Dwarf uses 64-bits to refer to a structure offset unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946 Summary: Dwarf uses 64-bits to refer to a structure offset unnecessarily Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: harihar...@picochip.com Created attachment 23503 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23503 The source code Hello, In the attached testcase, our dwarf reader reports the structure as Abbrevation 2: DW_TAG_structure_type [has children] DW_AT_nameDW_FORM_string DW_AT_byte_size DW_FORM_data1 DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_sibling DW_FORM_ref4 Abbrevation 3: DW_TAG_member DW_AT_nameDW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_typeDW_FORM_ref4 DW_AT_byte_size DW_FORM_data1 DW_AT_bit_sizeDW_FORM_data1 DW_AT_bit_offset DW_FORM_data1 DW_AT_data_member_locationDW_FORM_block1 Abbrevation 4: DW_TAG_member DW_AT_nameDW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_typeDW_FORM_ref4 DW_AT_byte_size DW_FORM_data1 DW_AT_bit_sizeDW_FORM_data1 DW_AT_bit_offset DW_FORM_data8 DW_AT_data_member_locationDW_FORM_block1 Note that the first element (c1) takes a DW_FORM_data1 to represent the offset, whereas the second (i) uses DW_FORM_data8. I am fairly certain it doesn't need 64-bits to represent the offset, so something is wrong here. I tested this with picochip port in the mainline GCC (as of 03-feb-2011).
[Bug debug/47946] Dwarf uses 64-bits to refer to a structure offset unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946 --- Comment #1 from hariharans at picochip dot com 2011-03-01 15:31:47 UTC --- Created attachment 23504 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23504 The assembly code
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774
--- Comment #7 from Adam Butcher dev.lists at jessamine dot co.uk 2011-03-01
15:34:40 UTC ---
(In reply to comment #6)
Yep, this is fixed too.
*** This bug has been marked as a duplicate of bug 46472 ***
The attached program demonstrated instances of the bug with various member
types. It still fails on two cases when using array members. I don't think
they are errors. Running
sh constexpr-ctor-templ.cpp
with 4.6.0 20110301 now yields the following (output compressed for legibility
[snip] = -c constexpr-ctor-templ.cpp -std=c++0x).
+ g++ [snip] -DPLAIN_T -DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DPLAIN_T -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
+ g++ [snip] -DPLAIN_T -DGIVE_X_EXPLICIT_NONCONST_CTOR
+ g++ [snip] -DPLAIN_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
constexpr-ctor-templ.cpp: In constructor ‘constexpr XT::X() [with T =
ncbool]’:
constexpr-ctor-templ.cpp:148:14: instantiated from here
constexpr-ctor-templ.cpp:103:24: error: ‘ncbool::ncbool(bool)’ is not
‘constexpr’
+ g++ [snip] -DPLAIN_T_ARRAY -DGIVE_X_EXPLICIT_NONCONST_CTOR
+ g++ [snip] -DFLAG_T-DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DFLAG_T-DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
+ g++ [snip] -DFLAG_T-DGIVE_X_EXPLICIT_NONCONST_CTOR
+ g++ [snip] -DFLAG_T_ARRAY -DUSE_SYNTHESIZED_X_CTOR
+ g++ [snip] -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_CONSTEXPR_CTOR
constexpr-ctor-templ.cpp: In constructor ‘constexpr XT::X() [with T =
ncbool]’:
constexpr-ctor-templ.cpp:148:14: instantiated from here
constexpr-ctor-templ.cpp:103:24: error: ‘constexpr flagBoolType::flag(bool)
[with BoolType = ncbool]’ is not ‘constexpr’
+ g++ [snip] -DFLAG_T_ARRAY -DGIVE_X_EXPLICIT_NONCONST_CTOR
Failed 2
The failing invocations occur when an array of a type that cannot be used to
construct compile-time constants is used as a member of X when X is given a
constexpr constructor. With the new compiler, the result comments become:
--- constexpr-ctor-templ.cpp 2011-03-01 14:57:22.0 +
+++ constexpr-ctor-templ.cpp 2011-03-01 14:58:55.0 +
@@ -113,11 +113,11 @@
#if PLAIN_T
T mem;// doesn't fail in any mode
#elif FLAG_T
- flagT mem; // fails only with synthesized ctor
+ flagT mem; // doesn't fail in any mode now
#elif PLAIN_T_ARRAY
T mem[7]; // fails only with GIVE_X_EXPLICIT_CONSTEXPR_CTOR
#elif FLAG_T_ARRAY
- flagT mem[7]; // fails unless GIVE_X_EXPLICIT_NONCONST_CTOR
+ flagT mem[7]; // fails only with GIVE_X_EXPLICIT_CONSTEXPR_CTOR
#endif
};
I.e. The plain array member still fails as it did before and the flagT array
member now fails in the same way as the plain array member (which is a change
from how it failed before).
Since the failures are now purely array related, a simplified program with no
macro configuration that reproduces the problem is:
struct ncbool
{
ncbool(bool b = false) : b(b) {}
bool b;
};
template typename BoolType
struct flag
{
constexpr flag(BoolType b = false) : b(b) {}
BoolType b;
};
template typename T
struct array
{
constexpr array() : mem() {}
T mem[7];
};
int main(int argc, char**)
{
// The following are not declared constexpr
// so shouldn't result in constexpr errors.
arrayncbool array_of_plain_ncbool;
arrayflagncbool array_of_flag_ncbool;
}
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-01 15:37:25 UTC --- (In reply to comment #5) So, I assume that it has been fixed anyway. Do you confirm? I think the intention is to warn, at least for a == (void *)0, since the address of a cannot be zero or null. So I would say that this is a regression.
[Bug fortran/43829] Scalarization of reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #33 from Dominique d'Humieres dominiq at lps dot ens.fr
2011-03-01 15:41:36 UTC ---
(In reply to comment #32)
Created attachment 23268 [details]
More up-to-date patch
Although this patch is probably not suitable for stage 4, I have it in my tree
for some time without any problem. It would be interesting to know if it still
improves 465.tonto. My only remark is about the test in comment #31 for which
the dg-warning in
if (any(1+eid(sum(a,2))+ay+neid2
(sum(a,2) ! { dg-warning Creating array temporary }
)+1 /= 3*ay+2))call abort
should be moved to the line above:
Warning: Creating array temporary at (1)
pr43829_7.f90:116.34:
if (any(1+eid(sum(a,2))+ay+neid2
1
Warning: Creating array temporary at (1)
and the block
if (any(sum(
a(sum(onesx(:,:),1),
sum(onesy(:,:),1),
sum(onesz(:,:),1)),
1) /= ax)) call abort
that generates
pr43829_7.f90:94.10:
a(sum(onesx(:,:),1),
1
Warning: Creating array temporary at (1)
pr43829_7.f90:94.28:
a(sum(onesx(:,:),1),
1
Warning: Creating array temporary at (1)
pr43829_7.f90:95.28:
sum(onesy(:,:),1),
1
Warning: Creating array temporary at (1)
Also reshape((/ (i*i,i=1,size(a)) /), shape(a)), generates a warning:
pr43829_7.f90:82.8:
reshape((/ (i*i,i=1,size(a)) /), shape(a)),
1
Warning: Creating array temporary at (1)
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 15:41:53 UTC --- The patch bootstrapped and tested ok. Removing if (!flag_gen_aux_info (TYPE_QUALS (element_type))) type = TYPE_MAIN_VARIANT (type); unconditionally breaks gcc.dg/array-quals-2.c (but nothing else). Whether that is a bug or such radical fix is wrong remains to be determined. Changing types based on flag_gen_aux_info definitely looks wrong. Probably a better general approach would be to make c_build_qualified_type also take a desired name as argument instead of using TYPE_NAME.
[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 15:53:23 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-01 15:53:23 UTC --- The patch in comment #1 fixes the ICE, but I am not sure to understand comment #2.
[Bug fortran/45797] ICE (segfault): Invalid read in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45797 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.01 15:57:58 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-01 15:57:58 UTC --- The patch in comment #2 fixes the ICE, but yields several more errors: [macbook] f90/bug% gfc pr45797.f90 pr45797.f90:10.10: type foo 1 Error: PROCEDURE attribute of 'foo' conflicts with DERIVED attribute at (1) pr45797.f90:12.5: end type 1 Error: Expecting END MODULE statement at (1) pr45797.f90:14.11: type(foo) function constructor() 1 Error: PROCEDURE attribute of 'foo' conflicts with DERIVED attribute at (1) pr45797.f90:15.4: constructor%bar = 1 1 Error: Unclassifiable statement at (1) pr45797.f90:14.2: type(foo) function constructor() 1 Error: The type for function 'constructor' at (1) is not accessible pr45797.f90:19.13: type(foo) :: f 1 Error: PROCEDURE attribute of 'foo' conflicts with DERIVED attribute at (1) pr45797.f90:21.9: if (f%bar /= 1) call abort () 1 Error: Syntax error in IF-expression at (1) pr45797.f90:23.9: if (f%bar /= 2) call abort () 1 Error: Syntax error in IF-expression at (1) pr45797.f90:25.9: if (f%bar /= 22) call abort () 1 Error: Syntax error in IF-expression at (1) pr45797.f90:22.8: f = foo(2) 1 Error: There is no specific function for the generic 'foo' at (1) pr45797.f90:24.8: f = foo(bar=22) 1 Error: There is no specific function for the generic 'foo' at (1) pr45797.f90:37.15: interface bar 1 Error: DERIVED attribute of 'bar' conflicts with PROCEDURE attribute at (1) pr45797.f90:38.4: procedure constructor 1 Error: Unclassifiable statement at (1) pr45797.f90:39.5: end interface 1 Error: Expecting END MODULE statement at (1) pr45797.f90:57.16: use foo_module 1 Fatal Error: Can't open module file 'foo_module.mod' for reading at (1): No such file or directory compared to pr45797.f90:10.10: type foo 1 Error: PROCEDURE attribute of 'foo' conflicts with DERIVED attribute at (1) pr45797.f90:12.5: end type 1 Error: Expecting END MODULE statement at (1) pr45797.f90:14.11: type(foo) function constructor() 1 Error: PROCEDURE attribute of 'foo' conflicts with DERIVED attribute at (1) f951: internal compiler error: Segmentation fault
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #34 from Mikael Morin mikael at gcc dot gnu.org 2011-03-01
16:26:53 UTC ---
The hack in comment 32 compiles correctly comment 24, but rejects the following
variant (with the type-bound call in a subroutine) with:
use mod2
1
Error: Name 'my_get' at (1) is an ambiguous reference to 'my_get' from module
'mod2'
module mod1
type :: t1
contains
procedure, nopass :: get = my_get
end type
contains
subroutine my_get()
print *,my_get (mod1)
end subroutine
end module
module mod2
contains
subroutine my_get()! must have the same name as the function in mod1
print *,my_get (mod2)
end subroutine
end module
use mod2
use mod1! order of use statements is important
type(t1) :: a
call call_get
contains
subroutine call_get
call a%get()
end subroutine call_get
end
The reason is that the following code in resolve_call reloads the procedure
symbol from the current namespace. This could be disabled with a flag, but it
would just make the hack uglier.
if (csym gfc_current_ns-parent csym-ns != gfc_current_ns)
{
gfc_symtree *st;
gfc_find_sym_tree (csym-name, gfc_current_ns, 1, st);
sym = st ? st-n.sym : NULL;
if (sym csym != sym
sym-ns == gfc_current_ns
sym-attr.flavor == FL_PROCEDURE
sym-attr.contained)
{
sym-refs++;
if (csym-attr.generic)
c-symtree-n.sym = sym;
else
c-symtree = st;
csym = c-symtree-n.sym;
}
}
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-03-01 16:39:23 UTC --- On Tue, 1 Mar 2011, d.g.gorbachev at gmail dot com wrote: The problem is that statics need to be mangled, so they persist as i.1234 instead. Really refering to a local symbol in asm is going to be difficult with LTO (any global or other static symbol with name i will cause a non-resolvable conflict). One solution is to introduce a new attribute, say nomangle, and shift responsibility for possible conflicts on a user. The original LTO proposal included assembler changes to allow multiple local symbols with the same name in the output. You could resurrect that, though allowing references to the multiple local symbols from asm imposes extra requirements on what the assembler interface must look like (directives to say which versions are being referred to by asms in a particular part of the input?).
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 16:42:26 UTC --- (In reply to comment #9) On Tue, 1 Mar 2011, d.g.gorbachev at gmail dot com wrote: The problem is that statics need to be mangled, so they persist as i.1234 instead. Really refering to a local symbol in asm is going to be difficult with LTO (any global or other static symbol with name i will cause a non-resolvable conflict). One solution is to introduce a new attribute, say nomangle, and shift responsibility for possible conflicts on a user. The original LTO proposal included assembler changes to allow multiple local symbols with the same name in the output. You could resurrect that, though allowing references to the multiple local symbols from asm imposes extra requirements on what the assembler interface must look like (directives to say which versions are being referred to by asms in a particular part of the input?). I think we settled on the idea to delay mangling of local symbols until after we composed ltrans units (so we can also compose units in a way to avoid the need to mangle local symbols with a used attribute). It shouldn't be too difficult to implement but sofar nobody has done the work (and it will likely be easier with a global symbol table which we hopefully will get for 4.7).
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-03-01 16:52:37 UTC --- On Tue, 1 Mar 2011, rguenth at gcc dot gnu.org wrote: The patch bootstrapped and tested ok. Removing if (!flag_gen_aux_info (TYPE_QUALS (element_type))) type = TYPE_MAIN_VARIANT (type); unconditionally breaks gcc.dg/array-quals-2.c (but nothing else). The point of the logic removing qualifiers here is as described in the comment /* Now figure out the structure of the declarator proper. Descend through it, creating more complex types, until we reach the declared identifier (or NULL_TREE, in an absolute declarator). At each stage we maintain an unqualified version of the type together with any qualifiers that should be applied to it with c_build_qualified_type; this way, array types including multidimensional array types are first built up in unqualified form and then the qualified form is created with TYPE_MAIN_VARIANT pointing to the unqualified form. */ to ensure consistency in TYPE_MAIN_VARIANT for array types; see http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02180.html. Probably a better general approach would be to make c_build_qualified_type also take a desired name as argument instead of using TYPE_NAME. In general it's a desired name for an intermediate type at some level of array derivation, not for the type being constructed by c_build_qualified_type. I suppose you could pass both the name and the particular type that should have that name, or otherwise indicate the qualifiers and level of array nesting where the name should be used if possible. If you have typedef const int T[1]; T array[2][3]; then const is being applied to int [2][3][1], and it's the intermediate type const int [1] that you'd like to get the name T.
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:01:38 UTC --- (In reply to comment #6) On Tue, 1 Mar 2011, rguenth at gcc dot gnu.org wrote: The patch bootstrapped and tested ok. Removing if (!flag_gen_aux_info (TYPE_QUALS (element_type))) type = TYPE_MAIN_VARIANT (type); unconditionally breaks gcc.dg/array-quals-2.c (but nothing else). The point of the logic removing qualifiers here is as described in the comment /* Now figure out the structure of the declarator proper. Descend through it, creating more complex types, until we reach the declared identifier (or NULL_TREE, in an absolute declarator). At each stage we maintain an unqualified version of the type together with any qualifiers that should be applied to it with c_build_qualified_type; this way, array types including multidimensional array types are first built up in unqualified form and then the qualified form is created with TYPE_MAIN_VARIANT pointing to the unqualified form. */ to ensure consistency in TYPE_MAIN_VARIANT for array types; see http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02180.html. Probably a better general approach would be to make c_build_qualified_type also take a desired name as argument instead of using TYPE_NAME. In general it's a desired name for an intermediate type at some level of array derivation, not for the type being constructed by c_build_qualified_type. I suppose you could pass both the name and the particular type that should have that name, or otherwise indicate the qualifiers and level of array nesting where the name should be used if possible. If you have typedef const int T[1]; T array[2][3]; then const is being applied to int [2][3][1], and it's the intermediate type const int [1] that you'd like to get the name T. I see. There is an alternative way to stripping qualifiers - build an unqualified variant like with Index: gcc/c-decl.c === --- gcc/c-decl.c(revision 170594) +++ gcc/c-decl.c(working copy) @@ -5038,8 +5038,8 @@ grokdeclarator (const struct c_declarato error_at (loc, conflicting named address spaces (%s vs %s), c_addr_space_name (as1), c_addr_space_name (as2)); - if (!flag_gen_aux_info (TYPE_QUALS (element_type))) -type = TYPE_MAIN_VARIANT (type); + if (TYPE_QUALS (element_type)) +type = c_build_qualified_type (type, 0); type_quals = ((constp ? TYPE_QUAL_CONST : 0) | (restrictp ? TYPE_QUAL_RESTRICT : 0) | (volatilep ? TYPE_QUAL_VOLATILE : 0) or alternatively using build_qualified_type directly to not strip qualifiers recursively at this point. That would preserve the type-names but also introduce a unqualified variants with that name if it doesn't exist already. To avoid the latter in c_build_qualified_type we could pass TYPE_MAIN_VARIANT to the build_qualified_type calls. I don't know if I'm the correct person to try fixing this (I'm certainly new to this part of the code), but at least the flag_gen_aux_info checking looks suspicious and should be removed.
[Bug tree-optimization/47890] [4.5 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:04:32 UTC --- Author: rguenth Date: Tue Mar 1 17:04:26 2011 New Revision: 170595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170595 Log: 2011-03-01 Richard Guenther rguent...@suse.de Backport from mainline 2011-03-01 Richard Guenther rguent...@suse.de PR tree-optimization/47890 * tree-vect-loop.c (get_initial_def_for_induction): Set related stmt properly. * gcc.dg/torture/pr47890.c: New testcase. 2010-12-01 Richard Guenther rguent...@suse.de PR tree-optimization/46723 * tree-vect-loop.c (get_initial_def_for_induction): Strip conversions from the induction evolution and apply it to the result instead. * tree-vect-stmts.c (vect_get_vec_def_for_operand): Handle assigns for induction defs. * gcc.dg/torture/pr46723.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr46723.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47890.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-vect-loop.c branches/gcc-4_5-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/46723] [4.5 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:04:32 UTC --- Author: rguenth Date: Tue Mar 1 17:04:26 2011 New Revision: 170595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170595 Log: 2011-03-01 Richard Guenther rguent...@suse.de Backport from mainline 2011-03-01 Richard Guenther rguent...@suse.de PR tree-optimization/47890 * tree-vect-loop.c (get_initial_def_for_induction): Set related stmt properly. * gcc.dg/torture/pr47890.c: New testcase. 2010-12-01 Richard Guenther rguent...@suse.de PR tree-optimization/46723 * tree-vect-loop.c (get_initial_def_for_induction): Strip conversions from the induction evolution and apply it to the result instead. * tree-vect-stmts.c (vect_get_vec_def_for_operand): Handle assigns for induction defs. * gcc.dg/torture/pr46723.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr46723.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47890.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-vect-loop.c branches/gcc-4_5-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/46723] [4.5 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:04:58 UTC --- Fixed.
[Bug tree-optimization/47890] [4.5 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:04:43 UTC --- Fixed.
[Bug tree-optimization/47639] [4.5 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fstack-check=generic -fexceptions -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:06:45 UTC --- Author: rguenth Date: Tue Mar 1 17:06:41 2011 New Revision: 170596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170596 Log: 2011-03-01 Richard Guenther rguent...@suse.de Backport from mainline 2011-02-08 Richard Guenther rguent...@suse.de PR middle-end/47639 * tree-vect-generic.c (expand_vector_operations_1): Update stmts here ... (expand_vector_operations): ... not here. Cleanup EH info and the CFG if required. * g++.dg/opt/pr47639.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/opt/pr47639.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-vect-generic.c
[Bug debug/47946] Dwarf uses 64-bits to refer to a structure offset unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #2 from Michael Matz matz at gcc dot gnu.org 2011-03-01 17:06:42 UTC --- Due to the definition of dwarf2/3 these offsets are negative on little-endian machines. This was fixed in dwarf4, see http://dwarfstd.org/ShowIssue.php?issue=081130.1type=closed3 GCC doesn't yet support this part of dwarf4. But even for dwarf2 we could emit this signed number as sleb128, not as unsigned number (that is what causes us to use FORM_data8).
[Bug tree-optimization/47639] [4.5 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fstack-check=generic -fexceptions -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47639 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-01 17:07:17 UTC --- Fixed.
[Bug c++/47940] warn about calls to a pure virtual from a constructor/destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47940
--- Comment #6 from mlg mlg7 at yandex dot ru 2011-03-01 17:23:41 UTC ---
(In reply to comment #4)
(In reply to comment #0)
Functions that call pure virtual functions cannot
be called from constructors and destructors.
This may be discovered at compile-time, and the above
text makes a good error/warning message.
I'm not sure it makes a good diagnostic, consider:
struct abc {
abc(bool nasal_demons) { if (nasal_demons) fly(); }
void fly() { doFly(); }
virtual void doFly() = 0;
};
That is the most dangerous situation: the crashing call is
buried [deep] in the control flow.
The deeper it is buried, the more valuable a warning/error
message would be.
Ok, a pure virtual function may be called indirectly
from a constructor/destructor
Ideally the diagnostic for this would say may call a pure virtual for cases
where it can't be determined.
Probably you are right, a kind of I know what I'm doing
pragma would be useful as well.
I also want to note that the top-level function may be virtual:
[NOTE: usefunc() is virtual here]
==byebug2.cpp==
#include stdio.h
class Base {
public:
~Base() { usefunc(); }
virtual void func()=0;
virtual void usefunc() { func(); }
};
class Derived: public Base {
public:
virtual void func() {}
};
int main() {
Derived d;
printf(life is good\n);
return 0;
}
==eof==
$ g++ -Wall -Wextra byebug2.cpp
$ ./a.out
life is good
pure virtual method called
terminate called without an active exception
Aborted
[Bug c/47947] New: Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 Summary: Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkar...@us.ibm.com CC: meiss...@linux.vnet.ibm.com Created attachment 23505 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23505 Tarfile for recreating the bug When copying one vector double variable to another vector double variable, for some variables the lower half of the variable is zeroed out. The zeroing results in incorrect computations. This happens for all -O optimization levels. A small testcase is provided to recreate the bug. In the testcase a simple vector addition with vec_add() results in an incorrect result due to incorrect copy. Here is the ouptut from the testcase: $ ./gccBugTest_GCC DEBUG:: u_in0 = 1.00,2.00,3.00,4.00 DEBUG:: u_in1 = 5.00,6.00,7.00,8.00 DEBUG::foo:: l_temp0 = 1.00,2.00,3.00,4.00 DEBUG::foo:: l_temp1 = 5.00,6.00,7.00,8.00 DEBUG::foo:: in0 HI = 1.00,0.00 DEBUG::foo:: in0 LO = 3.00,0.00 DEBUG::foo:: in1 HI = 5.00,0.00 DEBUG::foo:: in1 LO = 7.00,0.00 DEBUG::foo:: l_result HI = 6.00,0.00 DEBUG::foo:: l_result LO = 10.00,12.00 DEBUG::foo:: result:: l_temp2 = 6.00,0.00,10.00,12.00 DEBUG:: u_out = 6.00,0.00,10.00,12.00 $ The last DEBUG line should be DEBUG:: u_out = 6.00,8.00,10.00,12.00
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-03-01 17:27:00
UTC ---
Another one:
[hjl@gnu-6 ilp32-26]$ cat x.c
typedef union rtunion_def {
struct rtx_def *rtx;
} rtunion;
typedef struct rtx_def {
unsigned short code;
rtunion fld[1];
} *rtx;
extern rtx recog_operand[];
extern rtx *recog_operand_loc[];
extern int reload_n_operands;
extern void find_dummy_reload (int, int);
extern int asm_noperands (rtx);
extern int n_occurrences (char **);
char operands_match[10][10];
void find_reloads (rtx insn, int n_alternatives, int commutative)
{
register int i, j;
int noperands;
char *constraints[10];
int address_reloaded[10];
int this_alternative[10];
char this_alternative_win[10];
int this_alternative_matches[10];
int this_alternative_number;
rtx body = ((insn)-fld[3].rtx);
int operand_mode[10];
if (body-code == 1)
{
reload_n_operands = noperands = asm_noperands (body);
n_alternatives = n_occurrences (constraints);
}
for (this_alternative_number = 0;
this_alternative_number n_alternatives;
this_alternative_number++)
for (i = 0;
i noperands;
i++)
{
register char *p = constraints[i];
register int win = 0;
int badop = 1;
int c;
register rtx operand = recog_operand[i];
int force_reload = 0;
this_alternative_win[i] = 0;
this_alternative[i] = 1;
while (*p (c = *p++) != ',')
switch (c)
{
case '4':
c -= '0';
this_alternative_matches[i] = c;
if ((c != commutative
|| i != commutative + 1)
operands_match[c][i])
win = this_alternative_win[c];
else
find_dummy_reload (operand_mode[i], this_alternative[c]);
if (! win || force_reload)
for (j = 0; j i; j++)
if (this_alternative_matches[j]
== this_alternative_matches[i])
badop = 1;
break;
case '':
if (operand-code == 2
! address_reloaded[i]
operand-fld[0].rtx-code == 3)
win = 1;
}
}
}
[hjl@gnu-6 ilp32-26]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O x.c
x.c: In function ‘find_reloads’:
x.c:72:1: error: insn does not satisfy its constraints:
(insn 173 171 174 21 (set (reg:SI 0 ax [169])
(plus:SI (plus:SI (reg:SI 44 r15 [175])
(subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 240 [0xf0])) 0))
(const_int -96 [0xffa0]))) x.c:67 251 {*lea_1_x32}
(nil))
x.c:72:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 ilp32-26]$
[Bug target/47926] [x32] nested function pointer doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47926 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-03-01 17:31:35 UTC --- Author: hjl Date: Tue Mar 1 17:31:31 2011 New Revision: 170598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170598 Log: Use movl to load trampoline address for x32. 2011-03-01 H.J. Lu hongjiu...@intel.com PR target/47926 * config/i386/i386.c (ix86_trampoline_init): Use movl instead of movabs for x32. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/config/i386/i386.c
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #11 from Jan Hubicka hubicka at ucw dot cz 2011-03-01 17:41:48 UTC --- The original LTO proposal included assembler changes to allow multiple local symbols with the same name in the output. You could resurrect that, though allowing references to the multiple local symbols from asm imposes extra requirements on what the assembler interface must look like (directives to say which versions are being referred to by asms in a particular part of the input?). Hmm, doing that would imply need to refer to the static in some global way anyway. When it is referenced from regular code and two static variables from two different units might end up in the same instruction. Not too hard to implement I guess. I think we settled on the idea to delay mangling of local symbols until after we composed ltrans units (so we can also compose units in a way to avoid the need to mangle local symbols with a used attribute). It shouldn't be too difficult to implement but sofar nobody has done the work (and it will likely be easier with a global symbol table which we hopefully will get for 4.7). I do not like much the idea of improsing new artificial limits on the partitioning. Once we start doing fancy stuff at the ltrans time, we will have hard time partitioning the important stuff into single partition. Those extra requirements would just make it harder I probably like most the variant with extending the asm syntax for inputs/outputs at toplevel statements (like Sun compiler seems to do already) and declaring direct references to statics not LTO compatible. It seems much cleaner to me to declare that variable is used at the place it is actually used rather than annotating the declaration. Also it avoid the need for asm statement to be aware of target mangling rules (i.e. prefixing with _) Honza
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
--- Comment #6 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-03-01
18:08:11 UTC ---
The first difference between x86_64 and s390x appears in 004t.gimple since
s390x returns complex numbers in memory:
x86_64:
foo ()
{
float D.2684;
C D.2685;
C f;
D.2684 = REALPART_EXPR f;
f = COMPLEX_EXPR D.2684, 0.0;
D.2685 = f;
return D.2685;
}
s390x:
foo ()
{
float D.2702;
C f;
D.2702 = REALPART_EXPR f;
f = COMPLEX_EXPR D.2702, 0.0;
retval = f;
return retval;
}
The assignment to the imaginary part is introduced by cplxlower:
foo ()
{
float f$real;
C f;
float D.2702;
bb 2:
f$real_2 = f$real_6(D);
f_3 = COMPLEX_EXPR f$real_2, 0.0;
REALPART_EXPR retval = f$real_2;
IMAGPART_EXPR retval = 0.0;
return retval;
}
expand_complex_operations_1 is invoked for gimple stmt:
# .MEM_5 = VDEF .MEM_4(D)
retval = f_3;
the code falls through to the default label and invokes emit_complex_move in
tree-complex.c:1459
Since retval is no SSA_NAME emit_complex_move falls through to the code in
tree-complex.c:826 which splits the complex move to:
REALPART_EXPR retval = f$real_2;
IMAGPART_EXPR retval = 0.0;
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #7 from Jing Yu jingyu at google dot com 2011-03-01 18:08:57 UTC --- I am on leave from 02/01/2011 to 05/30/2011. I may not reply your email during this period. If you have Android toolchain questions/issues/requests, please contact Doug (dougk...@google.com) or my manager Bhaskar (bjanakira...@google.com). Thanks, Jing
[Bug debug/47946] Dwarf uses 64-bits to refer to a structure offset unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-01 18:39:17 UTC --- Created attachment 23506 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23506 gcc46-pr47946.patch Untested fix.
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org 2011-03-01 19:07:36 UTC --- Created attachment 23507 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23507 patch I am testing Hi, the problem is with thunks referring thunks or aliases. lto-symtab is wrong here and when moving thunksaliases associated with one node to the other node, it overwrites thunk.alias by the destination node. It consequently turns thunk referring another thunk into thunk referring the functoin itself. I fixed this by adding extra loop setting alias decl to prevailing decl. Richi, perhaps there is better place to put this? I don't like it being in the loop redirecting thunksaliases from one node to another because 1) I think that loop is not quite correct. When one function is prevailed by another, local static thunk from the first function should not be redirected to another. That happens correctly and is harmless (we end up with dead thunk) 2) It may happen that thunks get prevailed other way than nodes they are aliased with. We use comdat groups that prevents this from happening, but I would rather not 100% rely on this on all targets since not all targets implements comdat groups. So I think it is more robust to simply merge the decls in alias field like we merge other decls. Fixing this problem cause different problem with streaming. When we have alias A referring function F and alias B referring alias A and we are unlucky with prevailing and other things, we might end up streaming alias B before alias A. This leads us to call cgraph_same_body_alias on decl of A before A is added to cgraph as an alias. Consequently cgraph_same_body_alias does nothing later when we try to create alias A itself, because the node already exists. This patch fixes it by adding node pointer into the cgraph_same_body_alias and cgraph_add_thunk so the thunksaliases can be added in random order w/o problems as long as the function they are associated with is already in cgraph. I am testing patch now.
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org 2011-03-01 19:09:36 UTC --- mine, obviously ;) Still have no simple testcase...
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-03-01 19:21:21 UTC --- Author: hjl Date: Tue Mar 1 19:21:18 2011 New Revision: 170599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170599 Log: Add PLUS bas support to ix86_simplify_base_disp. gcc/ 2011-03-01 H.J. Lu hongjiu...@intel.com PR target/47744 * config/i386/i386.c (ix86_simplify_base_disp): Add PLUS base support. (ix86_decompose_address): Updated. gcc/testsuite/ 2011-03-01 H.J. Lu hongjiu...@intel.com PR target/47744 * gcc.dg/torture/pr47744-3.c: New. Added: branches/x32/gcc/testsuite/gcc.dg/torture/pr47744-3.c Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/config/i386/i386.c branches/x32/gcc/testsuite/ChangeLog.x32
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Priority|P4 |P3 Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #19 from Uros Bizjak ubizjak at gmail dot com 2011-03-01 19:29:19 UTC --- (In reply to comment #18) Fixed. Unfortunately, the same failure now happens on ia64-suse-linux-gnu [1] Again, the bug can be triggered with a crosscompiler: ~/gcc-build-xxx/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/home/uros/gcc-build-xxx/gcc/xgcc Target: ia64-suse-linux-gnu Configured with: ../gcc-svn/trunk/configure --target=ia64-suse-linux-gnu --enable-languages=c,c++ Thread model: posix gcc version 4.6.0 20110301 (experimental) [trunk revision 170594] (GCC) ~/gcc-build-xxx/gcc/cc1plus -O2 -gdwarf-2 -quiet pr47283.C pr47283.C: In member function ‘virtual void E::f10()’: pr47283.C:58:1: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1083 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I have reopend the PR with P3, since this is now a failure on secondary target. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg00057.html
[Bug tree-optimization/47447] [4.3/4.4 Regression] Unable to coalesce ssa_names x and y ICE in tree-ssa-coalesce.c when -O3 is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47447 --- Comment #8 from asharif at gcc dot gnu.org 2011-03-01 19:39:49 UTC --- Ping. Andrew or Richard, how can I rework my patch to address this issue? Thanks,
[Bug c/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-*-* Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2011.03.01 20:10:28 CC||dje at gcc dot gnu.org Host||powerpc-*-* Ever Confirmed|0 |1 Target Milestone|--- |4.6.0 Build||powerpc-*-*
[Bug libstdc++/47145] configure test for docbook-xsl-ns stylesheets uses hardcoded path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #22 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-03-01 21:31:57 UTC --- Here's a plan. Remove as per #4 -AC_CHECK_FILE([/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION], - [glibcxx_stylesheets=yes], [glibcxx_stylesheets=no]) replace with new _GLIBCXX_ENABLE_DOCS in acinclude.m4 that sets XSL_STYLE_DIR, SCHEMA_FLAGS and conditionally exports them in doc/Makefile.am as per #12, #18, #19 echo 'article/' | xsltproc --noout --nonet \ http://docbook.sourceforge.net/release/xsl-ns/current/xhtml-1_1/docbook.xsl - is the enable flag
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #20 from Steve Ellcey sje at cup dot hp.com 2011-03-01 21:50:38 UTC --- It is still working for me on ia64-hp-hpux11.23 in 32 and 64 bit modes but it is failing on my ia64-debian-linux-gnu system. I failed to notice that earlier.
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #1 from Pat Haugen pthaugen at gcc dot gnu.org 2011-03-01 21:51:09 UTC --- I checked to see if this is the same issue as PR47862, and it doesn't appear to be so. I was unable to duplicate the problem on Linux with trunk and ibm-4.5 branch, so looking AIX specific.
