[Bug tree-optimization/52081] Missed tail merging with pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52081 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from vries at gcc dot gnu.org 2012-04-14 06:04:03 UTC --- Fixed in r186447.
[Bug c/52977] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52977
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de, rguenth at gcc dot
||gnu.org
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-04-14 06:24:34 UTC ---
Started with rev.185458.
% cat test.i
fn1 ()
{
(int __attribute__((__vector_size__(8 0L;
}
or
% cat test.ii
typedef int __m64 __attribute__ ((__vector_size__ (8)));
__m64 a = (__m64) 0LL;
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2012-04-14 07:07:05 UTC --- Link changed now that it has been voted into the working paper: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1288 should it be un-suspended?
[Bug c++/52978] Inherit from Template with specified type and override virtual function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52978 --- Comment #6 from Benedikt Schmidt benediktibk at aon dot at 2012-04-14 08:37:00 UTC --- Now it is clear, even to me. My personal conclusion from this is: Prefer T const instead of const T. Thank you, Benedikt Schmidt
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #50 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-14
10:53:25 UTC ---
(In reply to comment #49)
Created attachment 27155 [details]
fix overload carets
The patch that I am currently bootstrapping. I made a small change to the
output. It looks like this now:
It bootstraps but, of course, there are a lot of failures. This one:
note: candidates are:
I can remove in prune.exp but this:
note: candidate expects 0 arguments, 1 provided
We probably want to match in messages. I am pretty sure there is a way to add a
new { dg-notes-2 note1 note2 } which passes a regexp such as
[^\n]*note1[^\n]*\n[^\n]*note2[^\n]* to process-message, but my Tcl foo is
not strong enough.
[Bug middle-end/52985] New: Postincrement not applied after indexing ternary array expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52985
Bug #: 52985
Summary: Postincrement not applied after indexing ternary array
expression
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@benfold.com
Created attachment 27156
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27156
Preprocessed source
[Component=middle-end was a guess, apologies if it's wrong.]
The code below prints an infinite series of zeros, as if the iterator is never
incremented.
The problem goes away if:
* the ternary expression is replaced by either tableA or tableB
* 'flag' is set to true
* the iterator increment is performed in a separate statement
* the vector and iterators are replaced with an array and (int *)
* tableA and tableB are replaced by vectors.
If the result of the array indexing is actually used, e.g. printed to cerr,
then results are the same at -O1 and above, but I see a segfault with -O0.
#include iostream
#include vector
int main (int argc, char *argv[])
{
std::vectorint v(1);
int tableA[] = { 0 };
int tableB[] = { 0 };
bool flag = false;
for (std::vectorint::const_iterator it = v.begin(); it != v.end();)
{
(flag ? tableA : tableB)[*it++];
std::cerr (it - v.begin()) \n;
}
return 0;
}
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14 11:01:59 UTC --- Yep, thanks, Marc.
[Bug fortran/52673] implement -fheap-arrays in gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52673 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-14 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-04-14 11:36:57 UTC --- Confirmed, would be a good idea.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-14 12:10:13 UTC --- are against it). I don't think there is any GCC contributor that is paid to improve GCC's diagnostics (am I wrong?). Right, but partially because it is a hard thing to do improve and the ROI is low. It is not *technically* hard. Anyone that knows C and a bit of C++ can fix hundreds (if you know C++ well and have a some experience with the C++ parser, you can probably fix thousands of bugs on your own, each fix taking no more than a couple of hours of debugging and few minutes of programming). However, it is time-consuming because of all the bureaucracy: copyright assignment, setting up the environment, bootstrapping+testing, patch submission, patch review, communication delays, style nits, changelogs nits, and updating the testsuite. That is why even current contributors often don't bother with one-liners, because all the associated tasks can make a one minute change require days of effort. This is very different from Clang, where Chris obviously cares a great deal about Clang's diagnostics, and it seems to be supported by a team in Apple (and in Google?). Yes, and in Google, but do you know why? Because it is easy to improve their diagnostics and benefit can be quickly seen. But why is it easy? For example, the C++ FE, although I don't like many of its design decisions, is quite easy to hack. And I don't think this is the reason. GCC is obviously easy to hack for their current developers, but they focus on different things than the Clang/LLVM developers. The whole attitude is quite different, for better or worse, and in terms of popularity, the LLVM crowd wins (of course, the GCC crowd may say that this is not a popularity contest, but if you want to attract new developers, who now have a choice, then it is). However, there are a lot of them, and getting patches reviewed and accepted requires herculean amounts of perseverance. But probably you can share with me more about your (or Googlers) thoughts on the latter, since you have the experience of submitting the same project to both LLVM and GCC. Infrastructure makes a big difference here -- see more about this below. Indeed, but my point is that moving to C++ does little (in my opinion) to fix the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, patch submission is a pain, patch review is a bottleneck, no automatic style checks, useless obligatory changelogs, no marketing, poor documentation for beginners, poor coordination with other projects (binutils, gdb, glibc), etc. (and, worse, the expectation that new/non-paid contributors should take care of fixing these issues). Nothing of the above gets fixed by switching to C++ or by having a clearly defined AST... I think they are clearly related. In any case, I hope you are right, and the move to C++ helps. I imagine that it can help to attract more corporate contributors, who don't have to bother with legal paperwork and are paid to do also boring bits. For sporadic and/or non-paid contributors, there are other bigger issues to solve.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14 12:24:47 UTC --- (In reply to comment #7) It is not *technically* hard. Anyone that knows C and a bit of C++ can fix hundreds (if you know C++ well and have a some experience with the C++ parser, There's the problem. I know C++ very well but don't know the front end well enough to work on it, and don't have time to learn it. My main problem is that everything is a void* so I have no idea what I can do with a given tree or what type it is, so I just try something, it compiles (because there's no type checking) so I run it then debug an ICE and continue by trial and error. That's not productive. The bottleneck is not the bureaucracy for me. Indeed, but my point is that moving to C++ does little (in my opinion) to fix the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, Why should the wiki be maintained? If people want to add to it they can, why should there be a maintainer?
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-14 12:42:53 UTC --- (In reply to comment #8) (In reply to comment #7) It is not *technically* hard. Anyone that knows C and a bit of C++ can fix hundreds (if you know C++ well and have a some experience with the C++ parser, There's the problem. I know C++ very well but don't know the front end well enough to work on it, and don't have time to learn it. My main problem is that everything is a void* so I have no idea what I can do with a given tree or what type it is, so I just try something, it compiles (because there's no type checking) so I run it then debug an ICE and continue by trial and error. That's not productive. The bottleneck is not the bureaucracy for me. Thanks for sharing this. This broadens my perception of the issues contributors have with GCC. That said, it should be possible right now to use a C++ wrapper around tree, and use that in the C++ FE (and require C++ to bootstrap the C++ FE). What do you think about that? Indeed, but my point is that moving to C++ does little (in my opinion) to fix the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, Why should the wiki be maintained? If people want to add to it they can, why should there be a maintainer? Well, the wiki is just a minor example, but it is awfully slow, nobody has administrator login (I can access as Daniel Berlin and ban users, but little more), and it is a unsupported version with known security issues.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14
13:16:18 UTC ---
(In reply to comment #9)
(In reply to comment #8)
Thanks for sharing this. This broadens my perception of the issues
contributors
have with GCC. That said, it should be possible right now to use a C++ wrapper
around tree, and use that in the C++ FE (and require C++ to bootstrap the C++
FE). What do you think about that?
I think that would help me, I don't know about others.
This is probably more suitable for the mailing list not bugzilla but it would
certainly help me if a tree is a FIELD_DECL then pass in a field_decl wrapper
around a tree, if it's a TREE_LIST pass in a tree_list wrapper around a tree.
Then functions/accessors that work on a TREE_LIST could be overloaded to work
on the wrapper, so you can use the original accessor on the raw tree if you
know what you're doing, or the type-safe overload on the wrapper which will
only compile if it's a valid operation.
But that wouldn't work when a function parameter is a tree that could be either
one type or another. That would either require the function to be refactored
to take two parameters, or some other way to have a wrapper that could be more
than one thing e.g. make the wrapper a template parameterised on by an enum
bitmask
templatetree_code C
struct tree_wrapper
{
tree t;
explicit tree_wrapper(tree t) : t(t)
{ gcc_checking_assert ( code() C ); }
tree_code code() const { return TREE_CODE (t); }
};
typedef tree_wrapperTREE_LIST tree_list;
typedef tree_wrapperTARGET_EXPR target_expr;
typedef tree_wrapperCONSTRUCTOR constructor;
// etc.
void f( tree_list list );
void g( target_expr expr );
void h( tree_wrapperTREE_LIST|TARGET_EXPR tree )
{
if (tree.code() == TREE_LIST)
f( tree_list(tree.t) );
else
g( target_expr(tree.t) );
}
Well, the wiki is just a minor example, but it is awfully slow, nobody has
administrator login (I can access as Daniel Berlin and ban users, but little
more), and it is a unsupported version with known security issues.
Ah yes, I see what you mean now.
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #31 from Alan Modra amodra at gcc dot gnu.org 2012-04-14 13:24:48 UTC --- Author: amodra Date: Sat Apr 14 13:24:43 2012 New Revision: 186453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186453 Log: PR libstdc++/52839 * acinclude.m4 (_GLIBCXX_ATOMIC_BUILTINS): Do not depend on glibcxx_cv_atomic_long_long. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug c/52986] New: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986 Bug #: 52986 Summary: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: kallis...@unixzen.com Original bug report: http://dev.haiku-os.org/ticket/8470 Failure: gcc -c -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/home/kallisti5/Projects/buildtools/gcc/gcc -I/home/kallisti5/Projects/buildtools/gcc/gcc/. -I/home/kallisti5/Projects/buildtools/gcc/gcc/../include -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libcpp/include -I/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gmp -I/home/kallisti5/Projects/buildtools/gcc/gmp -I/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./mpfr -I/home/kallisti5/Projects/buildtools/gcc/mpfr -I/home/kallisti5/Projects/buildtools/gcc/mpc/src -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libdecnumber -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libdecnumber/dpd -I../libdecnumber/home/kallisti5/Projects/buildtools/gcc/gcc/haifa-sched.c -o haifa-sched.o gtype-desc.c:8868:18: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:8987:36: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9071:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9092:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9099:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9106:31: error: subscripted value is neither array nor pointer nor vector make[2]: *** [gtype-desc.o] Error 1 make[2]: *** Waiting for unfinished jobs rm cpp.pod gcc.pod fsf-funding.pod make[2]: Leaving directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc' make: *** [all] Error 2 ERROR: Building gcc failed. Environment: kallisti5@eris ~ :) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.7-20120407/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release Thread model: posix gcc version 4.7.0 20120407 (prerelease) (GCC)
[Bug c/52986] x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-14 14:01:33 UTC --- Already fixed; dup of Bug 51969.
[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
--- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-14
15:05:37 UTC ---
The following patch fixes both reduced test cases and appears to fix the SPEC
problems in PR52980 as well. Bootstrap/regression test in progress, and will
then do a complete set of SPEC builds to be sure.
The second problem involved a subtlety in the rank order of operands. When
introducing the calls to __builtin_powi, I needed to fiddle with the resulting
operand rank to ensure uses of the call result appear after the call.
Dominique, please let me know whether this cleans up all your polyhedron tests
without introducing new failures. Thanks!
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c(revision 186393)
+++ gcc/tree-ssa-reassoc.c(working copy)
@@ -544,6 +544,28 @@ add_repeat_to_ops_vec (VEC(operand_entry_t, heap)
reassociate_stats.pows_encountered++;
}
+/* Add an operand entry to *OPS for the tree operand OP, giving the
+ new entry a larger rank than any other operand already in *OPS. */
+
+static void
+add_to_ops_vec_max_rank (VEC(operand_entry_t, heap) **ops, tree op)
+{
+ operand_entry_t oe = (operand_entry_t) pool_alloc (operand_entry_pool);
+ operand_entry_t oe1;
+ unsigned i;
+ unsigned max_rank = 0;
+
+ FOR_EACH_VEC_ELT (operand_entry_t, *ops, i, oe1)
+if (oe1-rank max_rank)
+ max_rank = oe1-rank;
+
+ oe-op = op;
+ oe-rank = max_rank + 1;
+ oe-id = next_operand_entry_id++;
+ oe-count = 1;
+ VEC_safe_push (operand_entry_t, heap, *ops, oe);
+}
+
/* Return true if STMT is reassociable operation containing a binary
operation with tree code CODE, and is inside LOOP. */
@@ -1200,6 +1222,7 @@ undistribute_ops_list (enum tree_code opcode,
dcode = gimple_assign_rhs_code (oe1def);
if ((dcode != MULT_EXPR
dcode != RDIV_EXPR)
+ || oe1-count != 1
|| !is_reassociable_op (oe1def, dcode, loop))
continue;
@@ -1243,6 +1266,8 @@ undistribute_ops_list (enum tree_code opcode,
oecount c;
void **slot;
size_t idx;
+ if (oe1-count != 1)
+continue;
c.oecode = oecode;
c.cnt = 1;
c.id = next_oecount_id++;
@@ -1311,7 +1336,7 @@ undistribute_ops_list (enum tree_code opcode,
FOR_EACH_VEC_ELT (operand_entry_t, subops[i], j, oe1)
{
- if (oe1-op == c-op)
+ if (oe1-op == c-op oe1-count == 1)
{
SET_BIT (candidates2, i);
++nr_candidates2;
@@ -3275,8 +3300,10 @@ attempt_builtin_powi (gimple stmt, VEC(operand_ent
gsi_insert_before (gsi, pow_stmt, GSI_SAME_STMT);
}
- /* Append the result of this iteration to the ops vector. */
- add_to_ops_vec (ops, iter_result);
+ /* Append the result of this iteration to the ops vector.
+ Give it a rank higher than all other ranks in the ops vector
+ so that all uses of it will be forced to come after it. */
+ add_to_ops_vec_max_rank (ops, iter_result);
/* Decrement the occurrence count of each element in the product
by the count found above, and remove this many copies of each
[Bug middle-end/52980] [4.8 Regression] Many benchmarks in SPEC CPU 2000/2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52980 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-14 15:11:43 UTC --- After further investigation, I'm indeed marking this as a duplicate of PR52976. Further information on fixes may be found there. *** This bug has been marked as a duplicate of bug 52976 ***
[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-14 15:11:43 UTC --- *** Bug 52980 has been marked as a duplicate of this bug. ***
[Bug c++/52987] New: bogus expected ; before for undeclared type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52987
Bug #: 52987
Summary: bogus expected ; before for undeclared type
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
void foo(void) {
x var;
}
manuel@gcc12:~/test2$ ~/trunk/186353/build/gcc/cc1plus ~/notdeclared.c
void foo()
/home/manuel/notdeclared.c:2:3: error: ‘x’ was not declared in this scope
x var;
^
/home/manuel/notdeclared.c:2:5: error: expected ‘;’ before ‘var’
x var;
^
manuel@gcc12:~/test2$ clang ~/notdeclared.c
/home/manuel/notdeclared.c:2:3: error: use of undeclared identifier 'x'
x var;
^
1 error generated.
The expected ; before var is bogus.
The following patch removes it in this case:
--- gcc/cp/parser.c (revision 186353)
+++ gcc/cp/parser.c (working copy)
@@ -5589,13 +5589,19 @@ cp_parser_postfix_expression (cp_parser
while (true)
{
if (idk == CP_ID_KIND_UNQUALIFIED
TREE_CODE (postfix_expression) == IDENTIFIER_NODE
cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_PAREN))
- /* It is not a Koenig lookup function call. */
- postfix_expression
- = unqualified_name_lookup_error (postfix_expression);
+ {
+ /* It is not a Koenig lookup function call. */
+ postfix_expression =
+ unqualified_name_lookup_error (postfix_expression);
+ /* It is better to skip the rest and return here, because at
+this point we don't know what this statement is. */
+ cp_parser_skip_to_end_of_statement (parser);
+ return error_mark_node;
+ }
/* Peek at the next token. */
token = cp_lexer_peek_token (parser-lexer);
switch (token-type)
Unfortunately, undeclared names can occur in many places besides statements, so
it fails for things like:
int foo(x var) {
}
I couldn't figure out how tell the context where we are called. :-(
[Bug libstdc++/52988] New: std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988 Bug #: 52988 Summary: std::async not executed on function returning nullptr_t Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: surfinthe...@yahoo.com Created attachment 27157 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27157 Sample code demonstrating bug and workaround. Given a function which returns a nullptr_t, the following appears to not call the function: futurenullptr_t fnp = async(returns_nullptr_t); fnp.get(); For a function which returns an int, the behavior is as expected. A workaround is to call fnp.wait() before fnp.get(). In that case, the function is indeed called (and its side-effects are observed). The attached file demonstrates the bug clearly. When executed, one should see the output: returns_nullptr_t returns_int but only the second line shows. If the workaround is applied, then both lines show.
[Bug middle-end/38299] internal error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299 David O'Shea david.oshea at emulex dot com changed: What|Removed |Added CC||david.oshea at emulex dot ||com --- Comment #7 from David O'Shea david.oshea at emulex dot com 2012-04-14 16:51:46 UTC --- In playing with the -O2 and -O flags, it would appear to be that the -fgcse subflag of the -O2 flags causes the failure. So you can substitute the following and get the compiler to build the library -O2 -no-gcse. This builds a less great (no Global Common Subexpression Elimination) library, but it builds on 3.2.1... The result is a larger library, but at least it builds.
[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976 --- Comment #8 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-14 16:54:02 UTC --- Patch bootstraps and passes regressions; all SPEC tests build cleanly. Will submit today to gcc-patches.
[Bug libstdc++/52988] std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-14 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14 17:06:21 UTC --- strange ... I'm looking into it
[Bug c++/52988] std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC||jason at gcc dot gnu.org
Component|libstdc++ |c++
Known to fail||4.6.3, 4.8.0
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14
17:29:52 UTC ---
Jason, could ou take a look at this please?
This looks like a G++ issue, doing something weird when nullptr_t is involved.
Possibly assuming that since all nullptr_t values are the same there's no point
calling a function to get one and it's valid to just return nullptr
immediately.
futureint::get() produces this:
_Res std::future_Res::get() [with _Res = int] (struct future * const this)
{
struct __basic_future * D.117159;
int D.117160;
struct __basic_future * D.117161;
struct _Result D.117162;
int D.117163;
type D.117164;
struct _Reset __reset;
try
{
D.117159 = this-D.52581;
std::__basic_futureint::_Reset::_Reset (__reset, D.117159);
try
{
D.117161 = this-D.52581;
D.117162 = std::__basic_futureint::_M_get_result (D.117161);
D.117163 = std::__future_base::_Resultint::_M_value (D.117162);
D.117164 = std::moveint (D.117163);
D.117160 = *D.117164;
return D.117160;
}
finally
{
std::__basic_futureint::_Reset::~_Reset (__reset);
}
}
finally
{
__reset = {CLOBBER};
}
}
But even though they're generated from the same template
futurenullptr_t::get() looks like this, with no call to _M_get_result()
before returning:
_Res std::future_Res::get() [with _Res = std::nullptr_t] (struct future *
const this)
{
struct __basic_future * D.117150;
Unknown tree: nullptr_type D.117151;
struct _Reset __reset;
try
{
D.117150 = this-D.52293;
std::__basic_futurestd::nullptr_t::_Reset::_Reset (__reset, D.117150);
try
{
D.117151 = 0;
return D.117151;
}
finally
{
std::__basic_futurestd::nullptr_t::_Reset::~_Reset (__reset);
}
}
finally
{
__reset = {CLOBBER};
}
}
[Bug c++/52988] std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-14
17:40:18 UTC ---
Slightly reduced testcase without iostream
#include future
using namespace std;
nullptr_t returns_nullptr_t()
{
__builtin_puts(returns_nullptr_t);
return nullptr;
}
int returns_int()
{
__builtin_puts(returns_int);
return 22;
}
int main()
{
futurenullptr_t fnp = async(returns_nullptr_t);
//fnp.wait(); // The workaround.
fnp.get();
futureint fi = async(returns_int);
fi.get();
return 0;
}
[Bug middle-end/38299] internal error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299 --- Comment #8 from David O'Shea david.oshea at emulex dot com 2012-04-14 17:58:31 UTC --- (In reply to comment #7) Spoke too soon. Things just compiled slower and it took longer to get to the same failure, I was fooled.As it is, you have to fall all the way back to the -O option, and then add in -fXXX options from the -O2 list. The problematic item is in one of: -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec And appears to be either or both of: -fschedule-insns or -fschedule-insns2 The -O2 items below were removed because ARM-ELF 3.2.1 does not understand them: (They are newer -O2 items as documented in newer GCC man page). -fcrossjumping -finline-small-functions -fipa-sra -freorder-functions -fstrict-overflow -ftree-switch-conversion -ftree-pre -ftree-vrp -findirect-inlining I'm getting success with the below. This turns of instruction reordering optimizations=speed (but still uses common subexpression elimination = size). CXXFLAGS= -g -O -fgcse -fgcse-lm -fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fexpensive-optimizations -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -frerun-cse-after-loop -fstrict-aliasing
[Bug other/52989] New: Installation error on OS X (arm-eabi) cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52989 Bug #: 52989 Summary: Installation error on OS X (arm-eabi) cross-compiler Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: eblot...@gmail.com While builing/installating GCC: the make install command fails to install two generated files - linux-crt0 - on OS X host, while building a cross-compiler version for ARM-EABI target. The message error looks like the following: install: /usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0/arm-eabi/lib/fpu/linux-crt0.o: No such file or directory although sometimes make simply exits with an Error 2 error message and no further info. I already encountered a similar issue with GCC 4.6.3, never with previous versions (4.6.0, 4.6.1 and 4.6.2 are ok) using the very same configure option switches on the very same host. With 4.6.3 however, there was no usable error message, so I give up trying to understand the issue. It seems that with 4.7.0, I can obtain a usable error message from the installation stage. On my system, the following directories are not created at installation stage, which in turn triggers the installation failure as make install attempts to copy the built linux-crt0.o files into non-existent destination directories: * prefix/gcc-arm-eabi/4.7.0/arm-eabi/lib/fpu * prefix/gcc-arm-eabi/4.7.0/arm-eabi/lib/fpu/interwork A simple workaround exists: creating the missing destination directories and restarting make install enables the installation stage to complete successfully. Host: Mac Book Pro Late 2008, Core 2 Duo 8 GiB, Lion 10.7.3 w/ 64 bits kernel $ uname -a Darwin arguel.eire 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 $ echo $SHELL /bin/bash $ echo $BASH_VERSION 3.2.48(1)-release configure:4034: /usr/bin/llvm-gcc --version 5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) configure:4034: /usr/bin/llvm-gcc -v 5 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Target: arm-eabi (not the linux EABI variant) Configure option switches: $ ../configure --prefix=/usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0 --target=arm-eabi --enable-shared --with-gnu-as --with-gnu-ld --with-newlib --enable-softfloat --disable-bigendian --disable-fpu --disable-underscore --enable-multilibs --with-float=soft --enable-interwork --enable-lto --enable-plugin --with-multilib-list=interwork --with-abi=aapcs --enable-languages=c,c++ --with-gmp=/usr/local/homebrew/Cellar/gmp/5.0.4 --with-mpfr=/usr/local/homebrew/Cellar/mpfr/3.1.0 --with-mpc=/usr/local/homebrew/Cellar/libmpc/0.9 --with-ppl=/usr/local/homebrew/Cellar/ppl/0.11.2 --with-cloog=/usr/local/homebrew/Cellar/cloog/0.17.0 --enable-cloog-backend=isl --disable-cloog-version-check --with-libelf=/usr/local/homebrew/Cellar/libelf/0.8.13 --with-gxx-include-dir=/usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0/arm-eabi/include --disable-debug --disable-__cxa_atexit Note: destination directory tree /usr/local/homebrew/* is R/W for the current user. /usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0 did not exist before building GCC. Let me know if you need more information
[Bug c++/52637] [4.7/4.8 regression] ICE producing debug info for c++11 code using local class as template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52637
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.6.3
Keywords||ice-on-valid-code
Last reconfirmed||2012-04-14
CC||jason at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Depends on||51650
Ever Confirmed|0 |1
Summary|ICE producing debug info|[4.7/4.8 regression] ICE
|for c++11 code using|producing debug info for
|templates/decltype/lambda |c++11 code using local
||class as template argument
--- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2012-04-14
21:22:53 UTC ---
Neither decltype nor lambda are needed for this bug, just use of a local type
as a template parameter:
template typename T
struct C { };
template typename V
void f(V v) {
struct B {};
CB c;
}
template typename T
void g(T t) {
struct A { } a;
f (a);
}
struct D {
void h() { g(0); }
};
This seems to be a result of the fix for PR 51650; we want to emit debug info
about CB, so B ends up on the limbo list. When we walk the limbo list we
decide to emit fA, so A ends up on the limbo list. But it gets added to the
beginning, so the list walk never sees it, and when we get around to emitting
the debug info for fA it can't find the A to refer to, and ICEs.
Before the patch for 51650 we didn't try to emit fA to be context for B.
[Bug target/52990] New: bootstrap ia64 cross-compiler gcc (static C-only) includes a broken libgcc.a due to libunwind dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52990
Bug #: 52990
Summary: bootstrap ia64 cross-compiler gcc (static C-only)
includes a broken libgcc.a due to libunwind
dependencies
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vap...@gentoo.org
CC: toolch...@gentoo.org
Target: ia64-linux-gnu
when building up a cross-compiler for ia64, we do:
- install binutils
- install kernel/C-library headers
- build a static C-only gcc compiler
- install glibc
- try to link a static ELF - failure
this is due to libgcc on ia64 being dependent on libunwind symbols. when
shared libs are disabled, the libgcc.a ends up referring to __libunwind_xxx
symbols which aren't provided in the non-shared case.
specifically, we have:
- ia64 forces t-unwind in config.gcc which adds -DUSE_LIBUNWIND_EXCEPTIONS
- gcc/unwind-compat.c has a bunch of extern __libunwind_xxx decls
- libgcc/Makefile.in adds unwind-compat.o to libgcc.a when enable_shared!=yes
- gcc/config/ia64/unwind-ia64.c defines __libunwind_xxx aliases when SHARED
- unwind-ia64.o is only added to libunwind.{a,so} and never libgcc.a
so, the end libgcc.a gets unwind-compat.o which refers to __libunwind_xxx, but
doesn't get unwind-ia64.o which could possibly define them, and even if it did,
the aliases aren't enabled for static objects.
looks like we could fix this in the t-glibc-libunwind file, when enable_shared
is disabled, add the ia64 unwind objects to libgcc.a. additionally, have
unwind-ia64.c key off of not just SHARED but also STATIC_ONLY for declaring the
symbols, and have the t-glibc-unwind file build unwind-ia64.o with that.
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-14 22:33:27 UTC --- Author: paolo Date: Sat Apr 14 22:33:22 2012 New Revision: 186456 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186456 Log: 2012-04-14 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52699 * include/bits/random.tcc (independent_bits_engine::operator()()) Avoid various overflows; use common_type on result_type and _RandomNumberEngine::result_type; avoid floating point computations; other smaller tweaks. * include/bits/random.tcc (uniform_int_distribution::operator()) Use common_type; assume _UniformRandomNumberGenerator::result_type unsigned; tidy. * include/bits/stl_algobase.h (__lg(unsigned), __lg(unsigned long), __lg(unsigned long long)): Add. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/include/bits/stl_algobase.h
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-15 02:14:45 UTC --- Author: paolo Date: Sun Apr 15 02:14:39 2012 New Revision: 186461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186461 Log: 2012-04-14 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52699 * include/bits/random.tcc (independent_bits_engine::operator()()) Avoid various overflows; use common_type on result_type and _RandomNumberEngine::result_type; avoid floating point computations; other smaller tweaks. * include/bits/random.tcc (uniform_int_distribution::operator()) Use common_type; assume _UniformRandomNumberGenerator::result_type unsigned; tidy. * include/bits/stl_algobase.h (__lg(unsigned), __lg(unsigned long), __lg(unsigned long long)): Add. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.tcc branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_algobase.h
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-15 02:15:17 UTC --- Fixed 4.7.1 and mainline.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #11 from davidxl xinliangli at gmail dot com 2012-04-15 04:09:53 UTC --- (In reply to comment #7) are against it). I don't think there is any GCC contributor that is paid to improve GCC's diagnostics (am I wrong?). Right, but partially because it is a hard thing to do improve and the ROI is low. It is not *technically* hard. Anyone that knows C and a bit of C++ can fix hundreds (if you know C++ well and have a some experience with the C++ parser, you can probably fix thousands of bugs on your own, each fix taking no more than a couple of hours of debugging and few minutes of programming). However, it is time-consuming because of all the bureaucracy: copyright assignment, setting up the environment, bootstrapping+testing, patch submission, patch review, communication delays, style nits, changelogs nits, and updating the testsuite. That is why even current contributors often don't bother with one-liners, because all the associated tasks can make a one minute change require days of effort. For many compiler hobbyists, the bureaucratic issues you mentioned don't exist yet before they start hacking on GCC FE. If the learning curve is steep and the interfaces are obscure, GCC will be less appealing to them. There is a difference between 'can do' and 'want to do'. This is very different from Clang, where Chris obviously cares a great deal about Clang's diagnostics, and it seems to be supported by a team in Apple (and in Google?). Yes, and in Google, but do you know why? Because it is easy to improve their diagnostics and benefit can be quickly seen. But why is it easy? For example, the C++ FE, although I don't like many of its design decisions, is quite easy to hack. Clang can be used to do lots of interesting stuff -- such as source code indexing (for semantic based code search), complicated automatic code refactoring etc. The Clang's design makes it possible because 1) source location information is well preserved; 2) information about macros are preserved; 3) there is no on the fly constant folding etc. And I don't think this is the reason. GCC is obviously easy to hack for their current developers, but they focus on different things than the Clang/LLVM developers. The whole attitude is quite different, for better or worse, and in terms of popularity, the LLVM crowd wins (of course, the GCC crowd may say that this is not a popularity contest, but if you want to attract new developers, who now have a choice, then it is). However, there are a lot of them, and getting patches reviewed and accepted requires herculean amounts of perseverance. But probably you can share with me more about your (or Googlers) thoughts on the latter, since you have the experience of submitting the same project to both LLVM and GCC. Infrastructure makes a big difference here -- see more about this below. Indeed, but my point is that moving to C++ does little (in my opinion) to fix the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, patch submission is a pain, patch review is a bottleneck, no automatic style checks, useless obligatory changelogs, no marketing, poor documentation for beginners, poor coordination with other projects (binutils, gdb, glibc), etc. (and, worse, the expectation that new/non-paid contributors should take care of fixing these issues). Nothing of the above gets fixed by switching to C++ or by having a clearly defined AST... I think they are clearly related. In any case, I hope you are right, and the move to C++ helps. I imagine that it can help to attract more corporate contributors, who don't have to bother with legal paperwork and are paid to do also boring bits. For sporadic and/or non-paid contributors, there are other bigger issues to solve. Moving to C++ itself won't do anything useful -- it is the new design as a result of moving to C++ that will make a difference. David
[Bug c/52991] New: attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Bug #: 52991
Summary: attribute packed broken on mingw32?
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sher...@netfarm.it
I've switched form mingw gcc 4.6.2 to 4.7.0 and I've noticed that attribute
packed does not work anymore as expected, simple testcase:
#include stdio.h
#include stdlib.h
#include inttypes.h
typedef struct st_tag
{
uint16_t head __attribute__ ((packed));
uint8_t type;
uint16_t flags __attribute__ ((packed));
} st;
int main(void)
{
st x;
printf(Structure packing got %u offset, expected 3\n,
(unsigned)((char*)x.flags - (char*)x));
return 0;
}
the generated asm is:
movl$4, 4(%esp)
movl$LC0, (%esp)
call_printf
the value is 3 in gcc 4.6.2
Using built-in specs.
COLLECT_GCC=c:\mingw\bin\gcc-4.7.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.7.0/configure --prefix=/mingw --disable-bootstrap
--enable-lto --with-pkgversion=Sherpya --with-bugurl=http://oss.netfarm.it/
--target=i686-pc-mingw32 --enable-targets=i686-pc-mingw32 --with-tune=generic
--with-cpu=i686 --disable-win32-registry --disable-shared --program-suffix=-4.7
--enable-version-specific-runtime-libs --enable-languages=c,c++
--disable-werror --enable-threads=win32 --with-dwarf2 --disable-nls
Thread model: win32
gcc version 4.7.0 (Sherpya)
I don't think save-temps output may be relevant
[Bug fortran/40973] Mark PRIVATE module functions as STATIC to faciliate optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-15 05:52:58 UTC --- Author: burnus Date: Sun Apr 15 05:52:51 2012 New Revision: 186464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186464 Log: 2012-04-14 Tobias Burnus bur...@net-b.de PR fortran/52916 PR fortran/40973 * gfortran.h (symbol_attribute): Add public_used. * interface.c (check_sym_interfaces, check_uop_interfaces, gfc_check_interfaces): Set it. * resolve.c (resolve_typebound_procedure): Ditto. * trans-decl.c (build_function_decl): Use it. 2012-04-14 Tobias Burnus bur...@net-b.de PR fortran/52916 PR fortran/40973 * gfortran.dg/public_private_module_3.f90: New. * gfortran.dg/public_private_module_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_3.f90 trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-15 05:52:58 UTC --- Author: burnus Date: Sun Apr 15 05:52:51 2012 New Revision: 186464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186464 Log: 2012-04-14 Tobias Burnus bur...@net-b.de PR fortran/52916 PR fortran/40973 * gfortran.h (symbol_attribute): Add public_used. * interface.c (check_sym_interfaces, check_uop_interfaces, gfc_check_interfaces): Set it. * resolve.c (resolve_typebound_procedure): Ditto. * trans-decl.c (build_function_decl): Use it. 2012-04-14 Tobias Burnus bur...@net-b.de PR fortran/52916 PR fortran/40973 * gfortran.dg/public_private_module_3.f90: New. * gfortran.dg/public_private_module_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_3.f90 trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
