[Bug c++/50233] Internal compiler error: in build_value_init_noctor, at cp/init.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-08-30 06:33:44 UTC --- Seems to be fixed in 4.7.0 (Tested with 4.7.0 20110820 (experimental))
[Bug fortran/50163] [4.4/4.5 Regression] ICE: initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50163 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 06:50:28 UTC --- Author: burnus Date: Tue Aug 30 06:50:22 2011 New Revision: 178280 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178280 Log: 2011-08-30 Tobias Burnus bur...@net-b.de PR fortran/50163 * check_init_expr (check_init_expr): Return when an error * occured. 2011-08-30 Tobias Burnus bur...@net-b.de PR fortran/50163 * gfortran.dg/initialization_28.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/initialization_28.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/expr.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-30 CC||bernds at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 07:24:54 UTC --- Confirmed. Misses some #ifdef (relies on optimization otherwise). Bernd, seems to be caused by your patch.
[Bug c/50236] compiler throws internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50236 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-08-30 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 07:26:40 UTC --- Please update to a compiler version that is still supported, which would be GCC 4.4.6 or newer. Also attach preprocessed source so the bug can be reproduced.
[Bug c++/50234] internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-30 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug target/50235] Wrong code with volatile bitfields and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50235 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-08-30 08:19:10 UTC --- Likely dup of PR48124 .
[Bug middle-end/29269] missing documentation for vcond (vector conditional operation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269 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 #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 08:54:23 UTC --- Mine.
[Bug tree-optimization/27460] Does not vectorize statements with mixed type COND_EXPRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460 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 #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 08:54:42 UTC --- Mine.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30 09:12:23 UTC --- Thanks, Marc! We can (and eventually should) fix anything in libstdc++ that incorrectly relies on this bug. Gthreads might be a little harder, but we could probably overload on language linkage if necessary, so the existing interfaces are preserved. I'll try your patch and see what, if anything, can be changed safely in libstdc++ right away.
[Bug c++/50233] Internal compiler error: in build_value_init_noctor, at cp/init.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-30 09:14:25 UTC --- Good. 4_6-branch behaves the same. Do we agree that GCC is correct in rejecting this (without ICE-ing of course)?
[Bug c++/50233] Internal compiler error: in build_value_init_noctor, at cp/init.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-08-30 09:30:48 UTC ---
(In reply to comment #2)
Good. 4_6-branch behaves the same. Do we agree that GCC is correct in
rejecting
this (without ICE-ing of course)?
I think that gcc is right rejecting it. The case is similar to the following
one:
int main()
{
constexpr int i{};
constexpr const int* p = i;
}
This program is ill-formed, because i is a variable without static storage
duration, and thus does not allow for forming an address-constant expression.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #22 from Marc Glisse marc.glisse at normalesup dot org 2011-08-30 09:32:24 UTC --- (In reply to comment #21) I'll try your patch and see what, if anything, can be changed safely in libstdc++ right away. Thanks :-) Note that some things are painful to do right with extern C. For instance, the __stoa helper takes as argument a pointer to a function with a type that depends on template arguments. As far as I can see, it is not possible to do that for extern C functions (I posted a question about that on clc++m yesterday), so that would mean rewriting this code differently. My guess is that making extern C functions usable would require a few DR, or extern C being part of the type will follow the example of export and be deprecated/removed (the second option is more likely, even if that's yet another change that hurts Oracle's compiler).
[Bug c++/50233] Internal compiler error: in build_value_init_noctor, at cp/init.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.2 Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-30 09:37:29 UTC --- Excellent.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-08-30 09:39:43 UTC ---
I believe I found a conforming usage of reinterpret_cast in constant
expressions useable in C++03:
//
struct X {
X* operator();
};
X x[2];
const bool p = (reinterpret_castX*(reinterpret_castchar(x[1]))
- reinterpret_castX*(reinterpret_castchar(x[0]))) == sizeof(X);
enum E { e = p }; // e should have a value equal to 1
//
Basically this program demonstrates the technique, the C++11 library function
addressof is based on and thus excluding reinterpret_cast *unconditionally*
from constant expressions in the core language would render this useful program
invalid and would make it impossible to declare addressof as a constexpr
function.
[Bug c++/25137] Warning missing braces around initializer causing problems with tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-30 09:41:23 UTC --- Maybe Dodji is interested in working on this?!? Can be quite annoying with tr1::array and std::array in C++11, of course.
[Bug c++/50233] Internal compiler error: in build_value_init_noctor, at cp/init.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-08-30 09:52:19 UTC --- I just notice that the current exclusion of reinterpret_cast in constant expressions would make it impossible to define addressof as a constexpr function. C++11 currently invalidates the special portable language rule of reinterpret_cast, addressof is based on, see also the recent example given in bug 49171, comment 2.
[Bug libstdc++/50160] vectorbool comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|vectorbool comparison |vectorbool comparison |very slow (no |very slow (no overload) |specialisation) | --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-30 10:29:14 UTC --- To be precise, we are talking about overloading not specializing. The issue, in general, reminds me the way we overload std::fill and std::copy for ranges of deque::iterator, but then in detail, there are the difficulties pointed out by Marc. I'm certainly available for patch reviews, anyway.
[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164 Ilya Enkovich enkovich.gnu at gmail dot com changed: What|Removed |Added Attachment #25083|0 |1 is obsolete|| --- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-30 10:40:50 UTC --- Created attachment 25138 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25138 Fixed reproducer
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #23 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30
10:46:51 UTC ---
(In reply to comment #22)
Note that some things are painful to do right with extern C. For instance,
the __stoa helper takes as argument a pointer to a function with a type that
depends on template arguments. As far as I can see, it is not possible to do
that for extern C functions (I posted a question about that on clc++m
yesterday), so that would mean rewriting this code differently.
I think you can do it with a alias-declaration in an extern C block:
extern C {
templatetypename T
using func_type = T (*)();
}
extern C void c() { }
templatetypename T
void f( func_typeT p ) { p(); }
int main()
{
f(c);
}
But yes, it's a bit of a hole in the type system that language linkage is part
of the type but can only be specified in some contexts and can't be deduced by
templates. We could solve it with an alternative syntax for language linkage
using attributes:
void f( [[extern(C)]] void (*p)() );
could be equivalent to:
extern C { typedef void (*func_type)(); }
void f( func_type p );
so we could say:
templatetypename T, typename U
void g( [[extern(C)]] T (*p)(U));
Without alias-declarations, the tedious way to fix __stoa would be write an
extern C++ forwarding function for each of the strtol, stroul, vsnprintf etc.
functions we need, and pass that forwarding function to the helper function
templates. That could be done with macros, and would still be simpler than
re-implementing the __stoa error-checking logic in each one. Anyway, that is
probably straying off-topic for this PR.
My guess is
that making extern C functions usable would require a few DR, or extern C
being part of the type will follow the example of export and be
deprecated/removed (the second option is more likely, even if that's yet
another change that hurts Oracle's compiler).
Clang++ and VC++ also implement this bug. If it's fixed in G++ it would need
to be controlled by a switch, maybe with the current behaviour as the default
(but issuing a warning) for a couple of releases. As I said in c13, it could
break a lot of code, plenty of people don't even know that they shouldn't be
able to pass extern C++ functions to C library APIs.
[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164 --- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-30 10:50:44 UTC --- I attached a fixed reproducer. It is closer to the original test and has higher registers pressure then the previous version. It has the same problem as the first reproducer. Reproduced with GCC 4.7.0 20110828 and options -O2 -m32 -march=atom. Code becomes faster on both Atom (~10%) and Core (~35%) if I use just -O2 -m32.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30 10:49:27 UTC --- (In reply to comment #23) I think you can do it with a alias-declaration in an extern C block: But that might have only worked when I tested it because Clang++ doesn't overload on language linkage either, I'm not sure if it's actually valid.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #25 from Marc Glisse marc.glisse at normalesup dot org 2011-08-30
11:28:48 UTC ---
(In reply to comment #23)
I think you can do it with a alias-declaration in an extern C block:
extern C {
templatetypename T
using func_type = T (*)();
}
extern C void c() { }
templatetypename T
void f( func_typeT p ) { p(); }
int main()
{
f(c);
}
But yes, it's a bit of a hole in the type system that language linkage is part
of the type but can only be specified in some contexts and can't be deduced by
templates.
Yes, I thought about the alias, but it doesn't deduce the type. I really don't
think your example works unless you call fthetype(c) as aliases are not
supposed to be deduced.
We could solve it with an alternative syntax for language linkage
using attributes:
void f( [[extern(C)]] void (*p)() );
Is that where attributes go? That must be inconvenient for functions returning
function pointers. Or does it have some kind of scope?
could be equivalent to:
extern C { typedef void (*func_type)(); }
void f( func_type p );
so we could say:
templatetypename T, typename U
void g( [[extern(C)]] T (*p)(U));
Yes, that would be nice.
My guess is that we are supposed to use extern C functions very rarely and
only in very specific contexts where it doesn't matter so much if you can't do
all the meta-programming stuff.
Anyway, that is probably straying off-topic for this PR.
Finding reasons to ask for the removal of this feature from the next standard
is kind of relevant ;-)
Clang++ and VC++ also implement this bug. If it's fixed in G++ it would
need
to be controlled by a switch, maybe with the current behaviour as the default
(but issuing a warning) for a couple of releases. As I said in c13, it could
break a lot of code, plenty of people don't even know that they shouldn't be
able to pass extern C++ functions to C library APIs.
Oracle's compiler implements it as different types, which already breaks a bit
of code (but it also means that a number of large projects have been fixed for
it), but it still allows many kinds of conversions between them, so most code
only gives warnings.
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 --- Comment #2 from Bernd Schmidt bernds at gcc dot gnu.org 2011-08-30 11:31:34 UTC --- Ugh, code prettyfication gone wrong. Will fix. However, you'll probably also want to add return patterns to PA for optimization.
[Bug tree-optimization/48571] [4.5/4.6/4.7 Regression] Missed data-dependence for (bogus?) reconstructed array-refs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-30 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 11:42:59 UTC --- Mine.
[Bug fortran/50163] [4.4/4.5/4.6/4.7 Regression] ICE: initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50163 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.6.2 |4.5.4 Summary|[4.4/4.5 Regression] ICE: |[4.4/4.5/4.6/4.7 |initialization expression |Regression] ICE: ||initialization expression --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 12:09:19 UTC --- FIXED on the trunk (4.7) and on the 4.5 and 4.6 branches. As mere ice-on-invalid-code bug, I decided not to backport it to 4.4. Anyone who wants to have it also in 4.4: Feel free to either backport it yourself or to tell us. Thanks for the bug report!
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #26 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30
12:17:47 UTC ---
(In reply to comment #25)
(In reply to comment #23)
We could solve it with an alternative syntax for language linkage
using attributes:
void f( [[extern(C)]] void (*p)() );
Is that where attributes go? That must be inconvenient for functions returning
function pointers. Or does it have some kind of scope?
I probably have the syntax wrong, I wanted that attribute to apply to the
parameter p, but for a function poiner maybe it should be:
void f( void (*p)() [[extern(C)]] );
And for a function pointer return type my attempt would be
void (* ugly(int)[[extern(C++)]] )() [[extern(C)]] ;
i.e.
extern C { typedef void (*c_func)() }
extern C++ { c_func ugly(int); }
Maybe.
My guess is that we are supposed to use extern C functions very rarely and
only in very specific contexts where it doesn't matter so much if you can't do
all the meta-programming stuff.
I did suggest to the POSIX C++ WG that there should be extern C++ overloads
of pthread_create, pthread_atfork etc. just as we have overloads of qsort and
bsearch taking pointers to extern C++ functions, which would allow existing
code that relies on this bug to just work without changes. I was going to
submit a proposal along those lines, but that WG seemed to fizzle out and I
never finished the paper. I probably still have it on an old hard drive on a
shelf somewhere.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #27 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30 12:19:23 UTC --- this is DR13 btw http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13 I don't know if that's been reconsidered now we have attributes
[Bug fortran/50231] Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 12:24:26 UTC --- Mark as WAITING. For the questions, see second part of comment 3.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #28 from Marc Glisse marc.glisse at normalesup dot org 2011-08-30 12:34:20 UTC --- (In reply to comment #27) this is DR13 btw http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13 I don't know if that's been reconsidered now we have attributes Gah, I looked for it, and once again forgot to look outside of the active list :-( Yes, this is exactly this DR, thanks for digging it up.
[Bug libstdc++/50143] Doxygen API documentation is invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143 --- Comment #22 from Christopher Yeleighton giecrilj at stegny dot 2a.pl 2011-08-30 13:10:38 UTC --- (In reply to comment #21) (In reply to comment #20) Please publish your result (just one page will do). I've deleted it now, you can see for yourself using the (about 10 lines in total) examples in my doxygen bug report The result of the bug, html/namespacefoo.html, is perfectly legible in Konqueror, so I still cannot reproduce (a valid unreadable document is needed).
[Bug bootstrap/50237] New: [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Bug #: 50237 Summary: [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org Host: x86_64-suse-linux Target: x86_64-suse-linux Build: x86_64-suse-linux I have had a bootstrap comparison failure for days on x86-64/Linux: libcpp/lex.o differs It turns out that stage3 has 6 .init_array 0008 3d20 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA but stage2 has 6 .ctors0008 3d20 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA That isn't surprising because HAVE_INITFINI_ARRAY isn't uniform: eric@hermes:~/build/gcc/native grep HAVE_INITFINI_ARRAY stage1-gcc/auto-host.h /* #undef HAVE_INITFINI_ARRAY */ eric@hermes:~/build/gcc/native grep HAVE_INITFINI_ARRAY prev-gcc/auto-host.h #define HAVE_INITFINI_ARRAY 1 i.e. despite http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00659.html the check is still applied to the host compiler, not to the target. The base compiler is the system compiler on OpenSuSE 11.0 and the check doesn't pass for it: eric@hermes:~/build/gcc/native gcc -o t t.c eric@hermes:~/build/gcc/native ./t Aborted The compiler is configured with eric@hermes:~/build/gcc/native gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-suse-linux Configured with: /home/eric/svn/gcc/configure x86_64-suse-linux --prefix=/home/eric/install/gcc --with-as=/home/eric/build/binutils/native/gas/as-new --with-ld=/home/eric/build/binutils/native/ld/ld-new --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-checking=yes,rtl --enable-__cxa_atexit --disable-nls --disable-libmudflap Thread model: posix gcc version 4.7.0 20110830 (experimental) [trunk revision 178287] (GCC) A workaround would be to get rid of the __attribute__((constructor)) in lex.c but someone should sit down and write a correct HAVE_INITFINI_ARRAY check.
[Bug fortran/45045] Named COMMON with different size: No warning with -fwhole-file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45045 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 13:24:46 UTC --- Is really the same as PR 45044. *** This bug has been marked as a duplicate of bug 45044 ***
[Bug fortran/45044] Different named COMMON block size: No warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044 Bug 45044 depends on bug 45045, which changed state. Bug 45045 Summary: Named COMMON with different size: No warning with -fwhole-file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45045 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 13:24:47 UTC --- *** Bug 45045 has been marked as a duplicate of this bug. ***
[Bug libstdc++/50143] Doxygen API documentation is invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143 --- Comment #23 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30 13:25:17 UTC --- Did you alter the Doxyfile as I described in Comment 20 here? Otherwise you're not getting valid XHTML, and you're not getting the treeview that caused the problem when I tested it. I've reported the doxygen bug, I've shown you how to run doxygen. I've described how to change the Doxyfile to avoid the bug, I've tested it in Konqueror, so far all you've done is ask me to do everything, even when it only involves running three simple shell commands. I have better things to do. Feel free to debug it and suggest fixes yourself, but don't expect me to spend any more time showing you how to run doxygen etc.
[Bug fortran/45044] Different named COMMON block size: No warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30
13:26:23 UTC ---
Simple patch to print also a warning if a smaller named common block follows a
larger one.
TODO: Print the location of the other COMMON block. One can recover the line
number via DECL_SOURCE_FILE and DECL_SOURCE_LINE, but one still lacks the
column and the source-line string (cf. gfc_linebuf).
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -392,4 +392,10 @@ build_common_decl (gfc_common_head *com, tree union_type,
bool is_init)
tree size = TYPE_SIZE_UNIT (union_type);
+
+ if (!tree_int_cst_equal (DECL_SIZE_UNIT (decl), size)
+ strcmp (com-name, BLANK_COMMON_NAME))
+ gfc_warning (Named COMMON block '%s' at %L shall be of the
+same size, com-name, com-where);
+
if (tree_int_cst_lt (DECL_SIZE_UNIT (decl), size))
-{
+ {
/* Named common blocks of the same name shall be of the same size
@@ -397,5 +403,2 @@ build_common_decl (gfc_common_head *com, tree union_type,
bool is_init)
blank common blocks may be of different sizes. */
- if (strcmp (com-name, BLANK_COMMON_NAME))
- gfc_warning (Named COMMON block '%s' at %L shall be of the
-same size, com-name, com-where);
DECL_SIZE (decl) = TYPE_SIZE (union_type);
[Bug libstdc++/50143] Doxygen API documentation is invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-30 13:27:37 UTC --- (In reply to comment #23) Did you alter the Doxyfile as I described in Comment 20 here? Comment 18, rather
[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50185 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-30 13:28:26 UTC --- Author: hjl Date: Tue Aug 30 13:28:21 2011 New Revision: 178302 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178302 Log: Rename avx2-vmovmskb-2.c to avx2-vpmovmskb-2.c. 2011-08-30 Kirill Yukhin kirill.yuk...@intel.com PR testsuite/50185 * gcc.target/i386/avx2-vmovmskb-2.c: Rename to ... * gcc.target/i386/avx2-vpmovmskb-2.c: ... this. Update. Added: trunk/gcc/testsuite/gcc.target/i386/avx2-vpmovmskb-2.c Removed: trunk/gcc/testsuite/gcc.target/i386/avx2-vmovmskb-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hjl at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-08-30 13:40:54 UTC --- HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature, independent of compiler. Which GCC does OpenSuSE 11.0 have?
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-08-30 13:50:28 UTC --- HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature, independent of compiler. AFAICS it doesn't, it compiles everything with the host compiler, which will use in particular the old binutils. See by contrast various tests in configure.ac that really check the features of the new binutils. Which GCC does OpenSuSE 11.0 have? Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux)
[Bug libstdc++/50143] Doxygen API documentation is invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143 --- Comment #25 from Christopher Yeleighton giecrilj at stegny dot 2a.pl 2011-08-30 13:51:39 UTC --- Well, the original documentation now shows up in Konqueror after a little delay, so the original failure might have been due do a network problem (e.g. a failed script download). While it is bad design to rely on scripts to make a page readable, it is obviously not your problem. Thanks for your help anyway.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-08-30 13:57:46 UTC --- (In reply to comment #2) HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature, independent of compiler. AFAICS it doesn't, it compiles everything with the host compiler, which will use in particular the old binutils. See by contrast various tests in configure.ac that really check the features of the new binutils. How is the different binutils in stage 1/2/3? Can you use the same binutils in stage 1/2/3?
[Bug tree-optimization/48571] [4.5/4.6/4.7 Regression] Missed data-dependence for (bogus?) reconstructed array-refs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 14:06:07 UTC --- Author: rguenth Date: Tue Aug 30 14:06:00 2011 New Revision: 178312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178312 Log: 2011-08-30 Richard Guenther rguent...@suse.de PR middle-end/48571 * gimple.h (maybe_fold_offset_to_address): Remove. (maybe_fold_offset_to_reference): Likewise. (maybe_fold_stmt_addition): Likewise. (may_propagate_address_into_dereference): Likewise. * tree-inline.c (remap_gimple_op_r): Do not reconstruct array references. * gimple-fold.c (canonicalize_constructor_val): Likewise. Canonicalize invariant POINTER_PLUS_EXPRs to invariant MEM_REF addresses instead. (may_propagate_address_into_dereference): Remove. (maybe_fold_offset_to_array_ref): Likewise. (maybe_fold_offset_to_reference): Likewise. (maybe_fold_offset_to_address): Likewise. (maybe_fold_stmt_addition): Likewise. (fold_gimple_assign): Do not reconstruct array references but instead canonicalize invariant POINTER_PLUS_EXPRs to invariant MEM_REF addresses. (gimple_fold_stmt_to_constant_1): Likewise. * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise. * gimplify.c (gimplify_conversion): Likewise. (gimplify_expr): Likewise. * gcc.c-torture/execute/pr48571-1.c: New testcase. * gcc.dg/tree-ssa/ssa-ccp-25.c: Remove. * gcc.dg/tree-ssa/ssa-ccp-26.c: Likewise. * gcc.dg/pr36902.c: XFAIL. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr48571-1.c Removed: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-25.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple.h trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/tree-inline.c trunk/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/48571] [4.5/4.6 Regression] Missed data-dependence for (bogus?) reconstructed array-refs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.0 Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] Missed |Missed data-dependence for |data-dependence for |(bogus?) reconstructed |(bogus?) reconstructed |array-refs |array-refs Known to fail|4.7.0 | --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 14:07:03 UTC --- Fixed for 4.7. There is not much chance in backporting.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-30 14:09:08 UTC --- Only stage2/3 binutils need to be the same and those are relevant for feature tests.
[Bug c++/50234] internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-08-30 14:23:05 UTC --- (In reply to comment #4) Only stage2/3 binutils need to be the same and those are relevant for feature tests. How does stage 2 binutils fail the test?
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 --- Comment #3 from dave.anglin at bell dot net 2011-08-30 14:29:10 UTC --- On 8/30/2011 7:31 AM, bernds at gcc dot gnu.org wrote: However, you'll probably also want to add return patterns to PA for optimization. I don't think the conditions required to define a return pattern are met. Possibly, a simple_return pattern could be defined. Is this what you are suggesting? Dave
[Bug middle-end/49328] [4.5 Regression] Internal compiler error due to explicit array bounds in contained routine argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49328 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Component|fortran |middle-end --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 14:34:21 UTC --- Move to component: middle-end. Summary: Works with 4.4, fails with 4.5, works again since 4.6. Only ICEs (cf. comment 0) with optimization. I have not tried to trace down the regression-causing patch but only the one which fixed the issue on the 4.6 trunk: FAILING: 20100418 158491 OK: 20100419 158501 Thus, the commit fixing this issue was Rev. 158496: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00602.html see also: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01131.html
[Bug c++/50220] [C++0x] [4.7 Regression] ICE when capturing a by-reference template function argument in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 Regression]|Internal compiler error |Internal compiler error |free_expr0 at expr.c:3709 |free_expr0 at expr.c:3709 |via gfc_done_2 |via gfc_done_2 | --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 14:43:20 UTC --- I removed the regression marker as the regression (cf. comment 7 to comment 12) has been fixed for the affected 4.6 branch and the 4.7 trunk. I leave the PR open in case someone wants to backport (to 4.5 and/or 4.4) the original patch (comment 5) with the follow-up patch (comment 11). The original bug is about an ice-on-valid-code issue.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-08-30 15:00:54 UTC --- How does stage 2 binutils fail the test? It doesn't. Let me explain: - during stage1, the check is made with the host compiler, i.e. the base compiler, so the old binutils are used and the check fails, that's why we have /* #undef HAVE_INITFINI_ARRAY */ in stage1-gcc/auto-host.h. This means that the stage1 compiler doesn't have the support. Since this compiler is used to compile stage2 libcpp/lex.o, the file gets the .ctors section. - during stage2, the check is made with the host cmpiler, i.e. the stage 1 compiler, so the new binutils (--with-as=, --with-ld) are used and the check succeeds, that's why we have #define HAVE_INITFINI_ARRAY 1 in stage2-gcc/auto-host.h. This means that the stage2 compiler has the support. Since this compiler is used to compile stage3 libcpp/lex.o, the file gets the .init_array section. The fix is to turn the check into a target check, i.e. test the target binutils. See configure.ac:1884 and below.
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 --- Comment #4 from Bernd Schmidt bernds at gcc dot gnu.org 2011-08-30 15:06:05 UTC --- Surely the PA has some kind of return instruction? Most ports define a return pattern with an insn condition that requires that the epilogue is empty. In that case, jumps to the end of the function will be replaced by return instructions. Also, the return pattern can in this case emit either a return or a simple_return rtx; they are equivalent if there is no epilogue. You can define a simple_return pattern, but it will only gain anything once the final shrink-wrapping bits are in.
[Bug c++/50220] [C++0x] [4.7 Regression] ICE when capturing a by-reference template function argument in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 15:28:44 UTC --- Author: jason Date: Tue Aug 30 15:28:40 2011 New Revision: 178326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178326 Log: PR c++/50220 * semantics.c (add_capture): Call complete_type for copy. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-50220.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50234] internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 15:28:35 UTC --- Author: jason Date: Tue Aug 30 15:28:30 2011 New Revision: 178325 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178325 Log: PR c++/50234 * semantics.c (cxx_eval_component_reference): Handle value-initialization for omitted initializers. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-value3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50234] internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |4.6.2 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 15:30:33 UTC --- Fixed.
[Bug c++/50220] [C++0x] [4.7 Regression] ICE when capturing a by-reference template function argument in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 15:29:09 UTC --- Author: jason Date: Tue Aug 30 15:29:04 2011 New Revision: 178328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178328 Log: PR c++/50220 * semantics.c (add_capture): Call complete_type for copy. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-50220.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/50220] [C++0x] [4.7 Regression] ICE when capturing a by-reference template function argument in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 15:29:59 UTC --- Fixed.
[Bug c++/50234] internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 15:28:57 UTC --- Author: jason Date: Tue Aug 30 15:28:55 2011 New Revision: 178327 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178327 Log: PR c++/50234 * semantics.c (cxx_eval_component_reference): Handle value-initialization for omitted initializers. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-value3.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #29 from kargl at gcc dot gnu.org 2011-08-30 15:34:06 UTC --- Author: kargl Date: Tue Aug 30 15:34:01 2011 New Revision: 178329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178329 Log: 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * trans-stmt.c (gfc_trans_allocate): Evaluate the substring. 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * gfortran.dg/allocate_with_source_2.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50238] New: configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238 Bug #: 50238 Summary: configure: error: GNU Fortran is not working Classification: Unclassified Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: silvio.filipe@gmail.com Hi, I'm trying to install gcc-4.3.4 and is giving the following error: configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /home/silvio/Downloads/gcc-4.3.4/x86_64-unknown-linux-gnu/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/home/silvio/Downloads/gcc-4.3.4' make: *** [all] Error 2 Will someone help me? I am working on Fedora 15 64-bit. Thaks, Silvio Filipe
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-30 15:40:49 UTC --- On Tue, 30 Aug 2011, ebotcazou at gcc dot gnu.org wrote: The fix is to turn the check into a target check, i.e. test the target binutils. See configure.ac:1884 and below. And a proper target check should not be testing execution of the generated code to work properly with cross compilation. The following are unconditionally safe: * Testing the target triplet. In particular, use ACX_ELF_TARGET_IFELSE (config/elf.m4) to eliminate non-ELF targets. * Testing uses of the assembler and linker, and using target objdump (when using GNU binutils) to examine the result, as long as the linker uses do not require any target libraries to be present. * Examining target headers (see the code checking for glibc versions in $target_header_dir/features.h). The first two should be able to tell if the assembler and linker have all the required features. init_array and fini_array are standard ELF features so I think the default should be to assume they will work on the target (if ELF) unless a reason arises to blacklist particular targets.
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-08-30 15:55:51 UTC --- The main issue is mixing input .ctors sections with .init_array sections to generate the single output .init_array section. Not all linkers support it even if they support .init_array section. How should we properly test this?
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2011-08-30 15:56:45 UTC --- In the meantime, you can use --enable-initfini-array/--disable-initfini-array to work around this.
[Bug c++/50239] New: compiled program segfault when -O0 is used to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239 Bug #: 50239 Summary: compiled program segfault when -O0 is used to compile Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ev...@mail.ru Original thread: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/591819 When I compile my code, if I compile it -O2, it compiles and runs fine. if I compile it with -O0, it segfaults while rendering text with FTGL. I've made no changes to anything in between compiles. Same FTGL code works fine in win32 (vs2010).
[Bug fortran/50238] configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 16:35:41 UTC --- Most of the time it indicates that your MPFR or GMP libary is wrongly installed, which is not a GCC problem. a) How do you configure GCC? b) Check for the actual error in /home/silvio/Downloads/gcc-4.3.4/x86_64-unknown-linux-gnu/libgfortran/config.log - or attach it as suggested. * * * I am working on Fedora 15 64-bit. Is there a special reason that you want to build GCC 4.3.4 instead of using the GCC/gfortran which is shipped with Fedora 15? (Namely, GCC 4.6.x.) By the way, for x86_64-unknown-linux-gnu there are unofficial builds available at http://gcc.gnu.org/wiki/GFortranBinaries - the nightly 4.7 version but also snapshot builds for 4.3 to 4.7.
[Bug c++/50239] compiled program segfault when -O0 is used to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-08-30 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-30 16:38:22 UTC --- Please follow the normal bug reporting instructions: http://gcc.gnu.org/bugs/#report
[Bug bootstrap/50237] [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-08-30 16:39:39 UTC --- On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote: The main issue is mixing input .ctors sections with .init_array sections to generate the single output .init_array section. Not all linkers support it even if they support .init_array section. How should we properly test this? Is it not possible to link (with -r, maybe) objects and examine the output with target objdump to see if .ctors sections are still present?
[Bug fortran/50238] configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238 --- Comment #2 from Silvio Filipe silvio.filipe.ubi at gmail dot com 2011-08-30 16:49:27 UTC --- Created attachment 25139 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25139 x86_64-unknown-linux-gnu/libgfortran/config.log
[Bug fortran/50238] configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238 --- Comment #3 from Silvio Filipe silvio.filipe.ubi at gmail dot com 2011-08-30 16:56:57 UTC --- (In reply to comment #1) Most of the time it indicates that your MPFR or GMP libary is wrongly installed, which is not a GCC problem. When I installed the GMP and MPFR has not given me any problems. a) How do you configure GCC? ./configure --prefix=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local b) Check for the actual error in /home/silvio/Downloads/gcc-4.3.4/x86_64-unknown-linux-gnu/libgfortran/config.log - or attach it as suggested. I've added the file. * * * I am working on Fedora 15 64-bit. Is there a special reason that you want to build GCC 4.3.4 instead of using the GCC/gfortran which is shipped with Fedora 15? (Namely, GCC 4.6.x.) MATLAB supports only up to this release. By the way, for x86_64-unknown-linux-gnu there are unofficial builds available at http://gcc.gnu.org/wiki/GFortranBinaries - the nightly 4.7 version but also snapshot builds for 4.3 to 4.7.
[Bug testsuite/50240] New: [4.7 Regression] ERROR: (DejaGnu) proc ^s does not exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50240 Bug #: 50240 Summary: [4.7 Regression] ERROR: (DejaGnu) proc ^s does not exist Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 178322 gave ERROR: (DejaGnu) proc ^s does not exist. Revision 178309 is OK.
[Bug fortran/50238] configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-30 16:58:32 UTC --- That log file clearly shows that this is a user error: symbol lookup error: /home/silvio/Downloads/gcc-4.3.4/host-x86_64-unknown-linux-gnu/gcc/f951: undefined symbol: mpfr_get_z_exp That symbol got renamed in mpfr, but mpfr.h has the corresponding #define, so you are most likely compiling/linking against one mpfr version (some older one, why?) but running the binaries against a newer mpfr version (assuming the system mpfr in Fedora 15). BTW, gcc 4.3 is no longer supported.
[Bug fortran/50238] configure: error: GNU Fortran is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50238 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 17:08:14 UTC --- (In reply to comment #3) ./configure --prefix=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local I want to add to the comments of Jakub that building GCC in-tree is not supported. That is: ./configure is wrong. You should create a separate directory, go to this directory and invoke configure from there. For instance: cd .. mkdir gcc-build cd gcc-build ../gcc-4.3.4/configure ... MATLAB supports only up to this release. Interesting to know. Hopefully, the start supporting newer versions soon, given that the currently supported releases are 4.4, 4.5 and 4.6 (4.7 is currently developed). Thus, 4.3 is no longer supported and 4.4 will likely become unsupported in half a year. (As written, you could also try the existing unofficial builds at http://gcc.gnu.org/wiki/GFortranBinaries ; for x86-64 Linux there are 4.3 snapshots available.)
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #12 from janus at gcc dot gnu.org 2011-08-30 17:09:22 UTC --- (In reply to comment #11) And indeed it seems to fix the segfault. ... and regtests cleanly. Unfortunately, there is one more complication: When compiling the two files from comment #1 one after the other, one gets a linker error: gfortran-4.7 -c module.f90 gfortran-4.7 program.f90 /tmp/ccU0pMIF.o: In function `MAIN__': program.f90:(.text+0x16): undefined reference to `__g_nodes_MOD___vtab_g_nodes_T0' program.f90:(.text+0x87): undefined reference to `__g_nodes_MOD___vtab_g_nodes_T1' Note: This seems to happen with trunk and 4.6, while it works with 4.5. I was hoping we had gotten rid of those for good (cf. e.g. PR44065 and PR45674).
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-30 17:24:31 UTC --- gfortran-4.7 -c module.f90 gfortran-4.7 program.f90 What about gfortran-4.7 program.f90 module.o? AFAIK there is not object in the *.mod files.
[Bug testsuite/50240] [4.7 Regression] ERROR: (DejaGnu) proc ^s does not exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50240
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||tocarip.intel at gmail dot
||com
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-08-30 17:49:14
UTC ---
It is caused by revision 178311:
http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01329.html
gcc.target/i386/fma-compile.c has
/* { dg-final { scan-assembler-times vfmadd[^s]..ps 2 } } */
/* { dg-final { scan-assembler-times vfmsub[^s]..ps 2 } } */
/* { dg-final { scan-assembler-times vfnmadd...ps 2 } } */
/* { dg-final { scan-assembler-times vfnmsub...ps 2 } } */
/* { dg-final { scan-assembler-times vfmaddsub...ps 2 } } */
/* { dg-final { scan-assembler-times vfmsubadd...ps 2 } } */
/* { dg-final { scan-assembler-times vfmadd[^s]..pd 2 } } */
/* { dg-final { scan-assembler-times vfmsub[^s]..pd 2 } } */
/* { dg-final { scan-assembler-times vfnmadd...pd 2 } } */
/* { dg-final { scan-assembler-times vfnmsub...pd 2 } } */
/* { dg-final { scan-assembler-times vfmaddsub...pd 2 } } */
/* { dg-final { scan-assembler-times vfmsubadd...pd 2 } } */
/* { dg-final { scan-assembler-times vfmadd[^s]..ss 1 } } */
/* { dg-final { scan-assembler-times vfmsub[^s]..ss 1 } } */
/* { dg-final { scan-assembler-times vfnmadd...ss 1 } } */
/* { dg-final { scan-assembler-times vfnmsub...ss 1 } } */
/* { dg-final { scan-assembler-times vfmadd[^s]..sd 1 } } */
/* { dg-final { scan-assembler-times vfmsub[^s]..sd 1 } } */
/* { dg-final { scan-assembler-times vfnmadd...sd 1 } } */
/* { dg-final { scan-assembler-times vfnmsub...sd 1 } } */
Those [^s] are wrong.
[Bug ada/18762] Illegal program not detected, RM 6.3.1(7), 8.5.4(5), 13.14(3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18762 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-30 17:54:23 UTC --- Gcc 4.6.1 does not detect the problem either.
[Bug testsuite/50240] [4.7 Regression] ERROR: (DejaGnu) proc ^s does not exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50240 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-08/msg02479.htm ||l Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-08-30 17:56:07 UTC --- Fixed by [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02479.html
[Bug ada/40185] Segmentation fault on program with typo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40185 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #2 from nicolas.boulenguez at free dot fr 2011-08-30 18:09:57 UTC --- GCC 4.6.1 does not crash and successfully reports the type size mismatch.
[Bug libgcj/50241] Building from the current branch - 178337 fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50241 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|classpath |libgcj Version|unspecified |4.7.0 Product|classpath |gcc Severity|blocker |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-30 18:43:36 UTC --- ./configure Building in the source directory is not well supported or tested.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #30 from Damian Rouson damian at rouson dot net 2011-08-30 18:46:42 UTC --- Just out curiosity, what's the reason for the real::rnd line in the helloworld testcase? I don't see rnd used anywhere. Damian On Tue, Aug 30, 2011 at 8:34 AM, kargl at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #29 from kargl at gcc dot gnu.org 2011-08-30 15:34:06 UTC --- Author: kargl Date: Tue Aug 30 15:34:01 2011 New Revision: 178329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178329 Log: 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * trans-stmt.c (gfc_trans_allocate): Evaluate the substring. 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * gfortran.dg/allocate_with_source_2.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/50114] ICE with declaration inside for statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added Attachment #25134|0 |1 is obsolete|| --- Comment #29 from Marc Glisse marc.glisse at normalesup dot org 2011-08-30 18:57:16 UTC --- Created attachment 25140 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25140 remember linkage of a function type (2) New version that works with typedefs (I was forgetting extern C in the canonical type...). The patch also includes a workaround for __stoa. There seems to still be an issue with argument deduction. For some reason, -fpermissive already allows all conversions :-)
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #31 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-30 19:31:25 UTC --- On Tue, Aug 30, 2011 at 06:46:42PM +, damian at rouson dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #30 from Damian Rouson damian at rouson dot net 2011-08-30 18:46:42 UTC --- Just out curiosity, what's the reason for the real::rnd line in the helloworld testcase? I don't see rnd used anywhere. Damian When I changed the testcase from the PR into something suitable for the testsuite, I missed removing the declaration.
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 --- Comment #8 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-08-30 19:33:42 UTC --- I built a cross-compiler on gcc10.fsffrance.org that exhibits the problem: $ cd /home/wschmidt/src/416.gamess $ /home/wschmidt/gcc/build/gcc-mainline-base/gcc/f951 chgpen.fppized.f -g -O3 -fprofile-generate -ffast-math -funroll-loops -mcpu=power7 -mtune=power7 -m64 -o chgpen.fppized.s -fdump-rtl-vartrack -quiet $ sed -n '/^(note/,/^$/p' chgpen.fppized.f.214r.vartrack | grep -i unspec (const:DI (unspec:DI [ ] UNSPEC_TOCREL (const:DI (unspec:DI [ ] UNSPEC_TOCREL))) [23 S8 A8]) [0 MEM[base: D.8938_616, offset: 0B]+0 S4 A32])) (const:DI (unspec:DI [ ] UNSPEC_TOCREL (const:DI (unspec:DI [ ] UNSPEC_TOCREL (const:DI (unspec:DI [ ] UNSPEC_TOCREL (high:DI (const:DI (unspec:DI [ ] UNSPEC_TOCREL) (const:DI (unspec:DI [ ] UNSPEC_TOCREL))) (const:DI (unspec:DI [ ] UNSPEC_TOCREL (high:DI (const:DI (unspec:DI [ ] UNSPEC_TOCREL) (const:DI (unspec:DI [ ] UNSPEC_TOCREL (high:DI (const:DI (unspec:DI [ ] UNSPEC_TOCREL) (const:DI (unspec:DI [ ] UNSPEC_TOCREL With this version of the compiler, the funky debug_insn looks like this after 179r.combine: (debug_insn 9141 9147 9146 5 (var_location:DI D#142 (mem/u/c:DI (lo_sum:DI (reg/f:DI 2232) (const:DI (unspec:DI [ (symbol_ref/u:DI (*.LC8) [flags 0x2]) ] UNSPEC_TOCREL))) [23 S8 A8])) -1 (nil)) In case you need to rebuild, the compiler was built with the following configuration based on r178337: $ /home/wschmidt/gcc/gcc-mainline-base/configure --target=powerpc64-linux --host=x86_64-linux --build=x86_64-linux --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,fortran,objc,obj-c++ --enable-checking=yes --with-gmp=/opt/cfarm/gmp --with-mpfr=/opt/cfarm/mpfr --with-mpc=/opt/cfarm/mpc --with-libelf=/opt/cfarm/libelf-0.8.12 --prefix=/home/wschmidt/gcc/install/gcc-mainline-base --with-cpu=default64 --with-as=/home/wschmidt/binutils-cross/build/gas/as-new --with-ld=/home/wschmidt/binutils-cross/build/ld/ld-new --enable-cross --with-sysroot=/home/wschmidt/ppc-sysroot (The make fails trying to build the target libraries, but that's of no consequence for reproducing this problem.) Please let me know if you have any trouble accessing the files; permissions should be set properly but I might have missed something.
[Bug c++/50089] [C++0x] ICE when calling a qualified base class member function within a lambda expr without this-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50089 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.2
[Bug c++/50242] New: __attribute__((naked)) is ignored on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242
Bug #: 50242
Summary: __attribute__((naked)) is ignored on IA32 (x86)
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: congru...@yahoo.co.uk
Given the follow c++ file:
---(start)---
__attribute__((naked)) void test(int a)
{
asm(//Do stuff);
asm(ret $4);
};
struct myclass
{
__attribute__((naked)) ~myclass()
{
asm(//Do stuff);
asm(ret);
}
virtual void virt() { };
};
void testmyclass()
{
myclass x;
}
---(end)---
The compiler will give the following complaints:
testnaked.cpp:1:39: warning: 'naked' attribute directive ignored
testnaked.cpp:9:34: warning: 'naked' attribute directive ignored
Additionally, prolog and epilog code is generated. The relevant parts of the
assembler output with added commentary follow:
---(start)---
__Z4testi: //test(int)
/APP
# 3 testnaked.cpp 1
//Do stuff
# 0 2
# 4 testnaked.cpp 1
ret $4
# 0 2
/NO_APP
ret // This ret shouldn't be here.
...(snip)...
__ZN7myclassD1Ev: //myclass::~myclass()
movl4(%esp), %eax // Destructor prolog that restores the vtable.
movl$__ZTV7myclass+8, (%eax) // These 2 lines shouldn't be present.
/APP
# 11 testnaked.cpp 1
//Do stuff
# 0 2
# 12 testnaked.cpp 1
ret
# 0 2
/NO_APP
ret // This ret shouldn't be here.
---(end)---
My apologies for the ATT syntax, but that's what -S yields.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #12 from Matt Hargett matt at use dot net 2011-08-30 20:30:15 UTC --- Can you determine which release introduced the regression?
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #30 from Marc Glisse marc.glisse at normalesup dot org 2011-08-30
20:32:57 UTC ---
(In reply to comment #29)
New version that works with typedefs (I was forgetting extern C in the
canonical type...). The patch also includes a workaround for __stoa. There
seems to still be an issue with argument deduction.
Also need to fix strip_typedefs (I am not uploading a new patch right now):
--- gcc/cp/tree.c(revision 178336)
+++ gcc/cp/tree.c(working copy)
@@ -1151,8 +1151,8 @@
}
else
{
-result = build_function_type (type,
- arg_types);
+result = build_function_type2 (type, arg_types,
+TYPE_MINVAL (t) != 0);
result = apply_memfn_quals (result, type_memfn_quals (t));
}
[Bug target/50242] __attribute__((naked)) is ignored on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-30 20:36:42 UTC --- naked is a target specific attribute which has not been added for x86 yet. Is there a reason why you want the naked attribute?
[Bug c++/50234] internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 --- Comment #4 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-08-30 20:48:22 UTC --- HA! You rule, thanks.
[Bug c++/50243] New: vtable for pure abstract class (interface) shouldn't be emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50243
Bug #: 50243
Summary: vtable for pure abstract class (interface) shouldn't
be emitted
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: congru...@yahoo.co.uk
Note: this is probably easier to do if ‘Bug 34949 - Dead code in empty
destructors.’ is done.
Consider the following class:
class iface
{
protected:
~iface() { }
public:
virtual void a() = 0;
virtual void b() = 0;
virtual void c() = 0;
};
This class cannot be instantiated, so a, b and c cannot be called from outside.
The only possible call site for them would be the destructor ~iface() but from
the fact that a, b and c are pure and the fact that it compiles, we know that
this doesn't happen. So the vtable for this class shouldn't be emitted.
But it is:
__ZTV5iface:
.long0
.long0
.long___cxa_pure_virtual
.long___cxa_pure_virtual
.long___cxa_pure_virtual
To make matters worse, it's needlessly referenced in destructors of derived
classes:
__ZN4impl1cEv:
pushl%ebx
subl$8, %esp
movl16(%esp), %ebx
testl%ebx, %ebx
jeL3
movl$__ZTV4impl+8, (%ebx) --- Strictly speaking unnecessary
call__Z7dostuffv
movl$__ZTV5iface+8, (%ebx)--- OOPS
movl%ebx, 16(%esp) What follows is the inlined
addl$8, %espdestructor of iface, the
popl%ebxiface vtable isn't needed.
jmp__ZdlPv
For this example I deliberately used a small interface, but I have found that
in larger software projects the unnecessary vtables can add up.
For reference, the rest of code used to demonstrate the problem follows:
void dostuff();
class impl : public iface
{
private:
~impl() { dostuff(); }
public:
void a() { dostuff(); }
void b() { dostuff(); }
void c() { delete this; }
};
void test()
{
iface * y = new impl();
y-a();
y-b();
y-c();
}
[Bug c++/50243] vtable for pure abstract class (interface) shouldn't be emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50243 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-30 20:54:34 UTC --- The vtable is required by the ABI IIRC.
[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183 --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-08-30 21:07:03 UTC --- Here's the relevant gimple following 103t.copyprop5: == bb 39: err2 = 0.0; err2_lsm.820_567 = err2; bb 40: # n_33 = PHI 1(39), n_223(44) # err2_lsm.820_313 = PHI err2_lsm.820_567(39), err2_lsm.820_573(44) D.6172_213 = (integer(kind=8)) n_33; D.6219_214 = D.6172_213 * 12; bb 41: # m_27 = PHI 1(40), m_221(42) # err2_lsm.820_353 = PHI err2_lsm.820_313(40), err2.395_219(42) D.6218_212 = (integer(kind=8)) m_27; D.6220_215 = D.6218_212 + D.6219_214; D.6221_216 = D.6220_215 + -13; D.6242_217 = s[D.6221_216]; err2.395_219 = D.6242_217 + err2_lsm.820_353; m_221 = m_27 + 1; if (m_27 == 12) goto bb 43; else goto bb 42; bb 42: goto bb 41; bb 43: # err2.395_561 = PHI err2.395_219(41) # err2_lsm.820_573 = PHI err2.395_219(41) n_223 = n_33 + 1; if (n_33 == 12) goto bb 45; else goto bb 44; bb 44: goto bb 40; bb 45: # err2.395_571 = PHI err2.395_561(43) # err2_lsm.820_574 = PHI err2_lsm.820_573(43) err2 = err2_lsm.820_574; D.6247_225 = ABS_EXPR err2.395_571; if (D.6247_225 1.3643219731549774157916554706559963960899e-10) goto bb 46; else goto bb 54; == At the time of the verify_ssa failure, this has been changed to: == bb 39: bb 74: # .MEM_352 = VDEF .MEM_351 err2 = 0.0; # VUSE .MEM_352 err2_lsm.820_567 = err2; # .MEM_170 = VDEF .MEM_352 Commutative_Associative_Reduction.822[0] = err2_lsm.820_567; bb 40: # n_33 = PHI 1(74), n_223(44) # .MEM_291 = PHI .MEM_170(74), .MEM_575(44) D.6172_213 = (integer(kind=8)) n_33; D.6219_214 = D.6172_213 * 12; bb 41: # m_27 = PHI 1(40), m_221(42) # .MEM_292 = PHI .MEM_291(40), .MEM_575(42) # VUSE .MEM_292 err2_lsm.820_353 = Commutative_Associative_Reduction.822[0]; D.6218_212 = (integer(kind=8)) m_27; D.6220_215 = D.6218_212 + D.6219_214; D.6221_216 = D.6220_215 + -13; # VUSE .MEM_292 D.6242_217 = s[D.6221_216]; err2.395_219 = D.6242_217 + err2_lsm.820_353; # .MEM_575 = VDEF .MEM_292 Commutative_Associative_Reduction.822[0] = err2.395_219; m_221 = m_27 + 1; if (m_27 == 12) goto bb 43; else goto bb 42; bb 42: goto bb 41; bb 43: bb 73: n_223 = n_33 + 1; if (n_33 == 12) goto bb 45; else goto bb 44; bb 44: goto bb 40; bb 45: # err2_lsm.820_574 = PHI err2.395_561(73) # VUSE .MEM_575 D.6815_562 = Commutative_Associative_Reduction.822[0]; err2.395_571 = D.6815_562; bb 72: # .MEM_569 = VDEF .MEM_575 err2 = err2_lsm.820_574; D.6247_225 = ABS_EXPR err2.395_571; if (D.6247_225 1.3643219731549774157916554706559963960899e-10) goto bb 46; else goto bb 54; == The PHI in block 45 is left without a definition.
[Bug c++/50084] [C++0x] ICE: decltype + remove_reference + new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50084 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 21:27:39 UTC --- Author: jason Date: Tue Aug 30 21:27:36 2011 New Revision: 178340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178340 Log: PR c++/50084 * cp-tree.h (cp_decl_specifier_seq): Rename user_defined_type_p to type_definition_p. * parser.c (cp_parser_set_decl_spec_type): Likewise. * decl.c (grokdeclarator): Check it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50089] [C++0x] ICE when calling a qualified base class member function within a lambda expr without this-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50089 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 21:27:31 UTC --- Author: jason Date: Tue Aug 30 21:27:27 2011 New Revision: 178339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178339 Log: PR c++/50089 * semantics.c (finish_id_expression): Use current_nonlambda_class_type for qualified-ids. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-qualified.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50114] ICE with declaration inside for statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 21:27:23 UTC --- Author: jason Date: Tue Aug 30 21:27:18 2011 New Revision: 178338 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178338 Log: PR c++/50114 * decl.c (poplevel): Disable for scope compatibility hack in C++11 mode. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-for.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/forscope2.C
[Bug fortran/45044] Different named COMMON block size: No warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45044 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-30 21:33:18 UTC --- I was thinking of using: gfc_gsymbol *gsym; gsym = gfc_get_gsymbol (com-name); gcc_assert (gsym-type == GSYM_COMMON); gfc_warning (Named COMMON block '%s' at %L shall be of the same size as at %L (%lu vs %lu bytes), com-name, com-where, gsym-where, But that won't work reliably: a) The byte size changes, while the position of (2) remains the same, e.g: Warnung: Named COMMON block 'xx' at (1) shall be of the same size as at (2) (24 vs 4 bytes) Warnung: Named COMMON block 'xx' at (1) shall be of the same size as at (2) (8 vs 24 bytes) b) One get's even strange results if one has 4 bytes, 30 bytes, 4 bytes as then (1) and (2) have the same bytes size but the error message claims that one is 4 and the other is 30 bytes wide. I defer this and now only print the byte-size, cf. http://gcc.gnu.org/ml/fortran/2011-08/msg00254.html
[Bug libfortran/50192] Wrong character comparision with wide strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50192 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-30 21:36:53 UTC --- Author: tkoenig Date: Tue Aug 30 21:36:48 2011 New Revision: 178341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178341 Log: 2011-08-30 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR libfortran/50192 * intrinsics/string_intrinsics.c (memcmp_char4): New function. * intrinsics/string_intrinsics_inc.c: New macro MEMCMP, either set to memcmp or memcmp_char4. (compare_string): Use MEMCMP, with correct size for it. * libgfortran.h: Add prototype for memcmp_char4. 2011-08-30 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR libfortran/50192 * gfortran.dg/widechar_compare_1.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/widechar_compare_1.f90 Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/libgfortran/ChangeLog branches/gcc-4_5-branch/libgfortran/intrinsics/string_intrinsics.c branches/gcc-4_5-branch/libgfortran/intrinsics/string_intrinsics_inc.c branches/gcc-4_5-branch/libgfortran/libgfortran.h
